Codex Multi-Agent V2 实战：怎样拆任务、分模型、控成本
OpenAI Codex DX 团队的 Eric Provencher 分享了一套多 Agent 编排方法：先判断任务能否独立拆分，再配置模型、推理强度、通信与上下文，最后算清时间和 Token 两本账。
- 多 Agent 的价值是让独立工作重叠进行；高度耦合、必须串行或共同修改核心区域的任务通常不该拆。
- 先用独立完成、独立验收、低写入冲突三项判断能否并行，再按难度给 Scout、Worker、Smart worker 分配推理强度。
- 主 Agent 保留所有权与最终验收，依赖消息可以点对点直达；上下文按任务依赖裁剪，平台安全边界仍然存在。
- 多 Agent 可能缩短墙钟时间，但总 Token 和协调成本通常上升；必须用真实任务同时核对时间、重复、冲突与返工。
OpenAI Codex DX 团队的 Eric Provencher 最近发布了一篇多 Agent 实践说明，详细分享在 Codex 的 Multi-Agent V2 下，怎样把一个复杂任务拆给不同 Agent，又不让团队陷入重复调查、上下文膨胀和互相覆盖。
这份方法真正有价值的地方，不是教人“多开几个 Agent”，而是给出一套配置顺序：先判断工作能不能拆，再决定谁来做、用多少推理、带多少上下文，最后把有效规则固化成 Skill。核心原则也不是“换模型才省钱”，而是先减少不必要的推理，再用并行缩短必须等待的时间。
Codex 的 Ultra 模式会把 Agent 协调变成默认行为，适合歧义大、上下文分散或风险高的工作；普通任务不必一上来就用 Ultra。Eric 给出的另一条路，是留在 Sol Medium，用一段短 Prompt 或 Skill 明确编排规则：主 Agent 继续和用户沟通，把后台工作拆出去，只有真正困难的部分才提高推理强度。
- 1为什么需要多 Agent
- 2什么任务能拆
- 3分给什么模型
- 4Agent 怎样协调
- 5给它多少上下文
- 6怎样固化成 Skill
- 7省了什么、付出什么
为什么需要多 Agent
单个 Agent 完成一项复杂任务，通常要依次读代码、查测试、确认边界、实现、再验证。问题不在于每一步都慢，而在于很多本来可以同时进行的调查，被迫排成一条队。
时间结构
每一步并没有变快，能重叠的等待被叠在了一起
多 Agent 的第一项收益，是把互不依赖的等待重叠起来：一个 Scout 追调用链，另一个检查权限和测试缺口，主 Agent 仍能和用户确认范围。等证据回来，后续实现少走一次弯路。
但只要工作高度耦合，增加 Agent 就没有意义。下一步必须依赖上一步的结果、所有人都要修改同一段核心代码，或者最终答案只能整体判断时，单 Agent 往往更快。是否并行，取决于任务结构，不取决于工具栏里能开多少 Agent。