Codex Multi-Agent V2 实战：怎样拆任务、分模型、控成本

为什么需要多 Agent

单个 Agent 完成一项复杂任务，通常要依次读代码、查测试、确认边界、实现、再验证。问题不在于每一步都慢，而在于很多本来可以同时进行的调查，被迫排成一条队。

多 Agent 的第一项收益，是把互不依赖的等待重叠起来：一个 Scout 追调用链，另一个检查权限和测试缺口，主 Agent 仍能和用户确认范围。等证据回来，后续实现少走一次弯路。

但只要工作高度耦合，增加 Agent 就没有意义。下一步必须依赖上一步的结果、所有人都要修改同一段核心代码，或者最终答案只能整体判断时，单 Agent 往往更快。是否并行，取决于任务结构，不取决于工具栏里能开多少 Agent。

什么任务能拆

一个任务值得拆，至少要同时满足三项：子任务能独立推进，结果能独立验收，写入范围不会彼此打架。

例如给现有产品增加“导出 CSV”：查现有数据流、核对权限规则、寻找测试位置可以并行；但字段定义和权限契约必须先定下来。契约稳定后，后端接口、前端入口和测试才适合分别实现。若三个 Agent 同时修改共享类型和同一核心函数，并行带来的只是更早发生的冲突。

这里真正要导出的不是一句“去做导出功能”，而是每个子任务的目标、范围、交付物和验收条件。任务单写不清，说明边界还没画出来；此时继续拆，只会把模糊复制给更多 Agent。

分给什么模型

Eric Provencher 给出的最简单配置，是先保持同一模型家族，只调整 reasoning_effort。这样先把“任务难度”这一项变量调清楚，不必一开始就同时比较多个模型的能力、价格和输出习惯。

Light 并不等于能力差，它只是少花推理在狭窄发现任务上；High 也不等于更适合所有工作，它应该留给歧义、风险和系统耦合真正更高的部分。把每个定位文件的任务都交给 High，会把便宜的查找变成昂贵的深思；把架构冲突交给 Light，省下的推理又会在返工中补回来。

这张角色表是实用默认值，不是平台白名单。当前 GPT-5.6 家族还有 Terra、Luna 等可用选择，多 Agent 也可以委派给其他受支持模型。稳妥的做法是先用同一基线跑通，再拿真实任务比较不同模型与推理强度；不要把“配置最多”误当成“优化最好”。

Agent 怎样协调

任务拆开后，主 Agent 仍然是协调者：它负责避免重复调查、明确文件所有权、追踪依赖、整合结果，并继续与用户沟通。分出去的是具体工作，不是最终责任。

信息却不必层层上报。Scout 找到某个权限检查入口后，可以直接把文件路径和结论发给真正依赖它的 Worker；主 Agent只需知道依赖已经解除。这样能少一次转述，也避免协调者的上下文被每条中间消息塞满。

并发预算可以按线程配置。Eric 分享这套方法时，默认是四个 Agent，且包含协调者。最直接的组合是“一个协调者＋三个并行 Scout”，分别调查不同问题；也可以让一个 Smart worker 带一个 Scout 和一个 Worker，形成一支处理复杂子问题的小队。四个是当时的默认值，不是永久上限，更不是每次都应该用满的配额。

直接通信不等于去中心化失控。谁能改哪个文件、共享契约由谁决定、什么时候合并、最终由谁验收，仍然需要一个清楚的任务图。通信可以走最短路径，所有权不能含糊。

给它多少上下文

子 Agent 是否继承父对话，应该由它对既有决策的依赖决定。狭窄的只读调查往往适合 fork_turns: "none"：只给它当前问题、允许读取的范围、输出格式和验收标准。需要延续架构决定、兼容约束或用户偏好的 Worker，则应继承相关历史。

干净上下文不是空白任务单。此前对话里的工具范围、业务限制和“不要改什么”不会自动成为这次任务的说明，必须重新写进派发内容。反过来，继承太多历史也会带入无关讨论，甚至让叶子 Agent 误以为自己还应继续派生团队；这时要明确告诉它直接完成任务，不再委派。

Eric 给叶子 Agent 的边界提示很短，实际可以直接复用：

直接完成这项任务，不要再创建其他 Agent；你父级收到的委派规则只适用于父级。

还有一个常见误解：fork_turns: "none" 隔离的是聊天历史，不会取消平台的 sandbox 或 permission mode。任务上下文可以裁剪，系统安全边界仍然生效。

怎样固化成 Skill

一套分工只有反复有效，才值得写进 Skill。适合固化的不是“每次都创建三个 Agent”，而是那些容易被忘掉、又能跨任务复用的纪律：什么工作优先交给 Scout，什么时候升级推理，怎样避免重叠写入，叶子 Agent 能否继续委派，以及哪些动作必须由用户批准。

Skill 让协调者下次不必从零重述团队约定，但它不能替项目预先画好任务边界。代码结构、风险和模型能力发生变化后，默认值也要跟着真实结果调整。最好的 Skill 更像可修订的操作手册，而不是一段永远正确的自动化咒语。

Eric 已把这套约定整理成开源仓库 provencher/codex-skills，其中的 orchestrate/SKILL.md 就是一个很短的可运行版本。安装时把 orchestrate 目录复制到 ~/.codex/skills/，随后用 $orchestrate 调用。它最值得借鉴的不是某一句提示词，而是把“角色、推理强度、上下文、所有权和批准边界”一起写进可复用规则。

到底省了什么、付出什么

多 Agent 最容易被误解成“既更快又更省 Token”。实际是两本不同的账：独立工作重叠后，墙钟时间可能下降；但每个 Agent 都要读取材料、推理、调用工具和检查结果，总 Token 往往上升，还会增加协调、冲突与返工成本。

因此，多 Agent 优化的第一目标通常是缩短等待、提高探索覆盖或降低一次做错的风险，而不是减少总 Token。它也可能让主 Agent 的上下文更干净，但那只是把工作分散到了别处，并不等于系统总消耗变少。

评估时至少同时看四项：完成时间、重复调查、写入冲突和返工次数。先记录单 Agent 基线，再一次只改一个变量。Eric 建议重点实验四个旋钮：推理强度、上下文继承、委派权限、Agent 之间的协作方式。例如先只并行两个只读调查，或只把一个高歧义任务从 Medium 升到 High；没有真实对照，就不存在“最佳编排”。

最后可以把选择压缩成一句话：紧密耦合的工作留给一个 Agent；能独立推进、独立验收、低冲突的工作，才值得组成团队。 多 Agent 真正节省的是无效等待，而它付出的，是更多模型工作和更严格的协调纪律。