Codex子代理体验仍差

背景

随着 AI 编码助手（如 GitHub Copilot 的 Codex 模型）持续迭代，多代理协作架构逐渐成为提升复杂任务处理能力的关键设计。代理（Agent）被用于自动分解任务、调用工具、管理上下文，但不同系统的子代理调度机制差异显著。用户在实际使用中，对代理的行为模式——尤其是主代理与子代理之间的交互方式——有较高的体验预期。近期，有用户反馈新版 Codex（基于 GPT-5.6 模型）的子代理逻辑存在严重缺陷，与同类工具（如 OpenCode）形成鲜明对比。

核心内容

原文作者指出，GPT-5.6 以及新版 Codex 在子代理体验上依然没有改善，反而变得更差。具体表现为：

• 在之前的版本中，子代理至少不会自行派发子代理，所有任务都在主对话中完成，用户能直接看到交互过程。
• 现在，系统喜欢主动派发子代理来处理子任务，但主代理缺乏耐心——大约每隔一分钟就会检查工作区的改动，查看子代理的进度。这种频繁的“巡视”严重干扰了工作流，用户体验极其糟糕。
• 作者认为，Codex 应当学习 OpenCode 的子代理逻辑：在 OpenCode 中，子代理工作时，主会话会一直静静地等待，不会中途打断；同时，用户能够方便地查阅子代理的实时进度，了解工作状态。

关键要点

• 主代理过度干预：新版 Codex 主代理在子代理执行任务期间，频繁主动检查工作区改动（频率约每分钟一次），打断子代理工作，降低整体效率。
• 子代理失控派发：系统倾向于自行创建子代理，而不是在单一对话中完成，这种自动拆分任务的行为缺乏用户控制。
• 对比要点：OpenCode 采用主会话静默等待策略，子代理执行期间主代理不主动干预，用户可通过进度面板随时查看子代理状态，体验更流畅、可控。
• 用户期望：AI 编码工具的代理行为应更符合“发布并等待”模式，减少不必要的轮询和打断，同时提供透明的进度反馈。

意义与影响

这一反馈揭示了当前 AI 编码助手在多代理协作设计上的关键矛盾：自动化的程度与用户控制权之间的平衡。Codex 试图通过自动派发子代理来提升并行处理能力，但主代理的过度轮询不仅抵消了并行优势，还引入了额外的等待和干扰。相较之下，OpenCode 的静默等待方案更接近人类协作中的“分派并信任”模式，并可借助独立的进度界面实现透明监控，这对用户的心理模型和实际效率都更友好。

该问题的影响不限于个人体验，更关乎 AI 辅助开发工具在复杂项目中的实用性。如果主流模型（如 GPT-5.6 驱动的 Codex）不能优化子代理调度策略，用户可能会转向其他提供更可控代理行为的工具（如 OpenCode）。这也给其他 AI 代理系统设计者提出了启示：代理的调度模型应默认采用非侵入式等待，辅以异步进度查询接口，而非定时轮询。未来，随着多代理架构在编程、数据分析等领域的普及，子代理的等待策略和用户可见性将成为衡量 AI 工具成熟度的关键指标之一。