Codex 多智能体怎么跑，上手前先确认这几件事

Codex 多智能体不是开一个开关就变快了，它的前提是任务本身能被拆成互不冲突的几块。上手前先确认三件事：这几块任务改的文件有没有交集、每个 Agent 有没有独立的工作区、审批级别设到哪一档。这三件事没定，开多个 Agent 只会带来覆盖冲突和更高的成本。

很多人期望多智能体「并行改同一个仓库的不同功能」，跑起来才发现两个 Agent 改到了同一个文件，后写的把先写的覆盖掉，还得人工回滚。这不是工具的问题，是任务拆分的问题。

本文给出三种可行的编排方式、一份最小配置示例、三个高频失败的修复方式，以及判断「该不该开多智能体」的具体标准。今天这篇文章，编程狮就把这条路径讲透。

先看结论

多智能体适合三种编排：按目录并行改不同模块、流水线式串行接力、写审分离的双角色模式。除此之外强行并行，收益通常覆盖不了成本。

判断标准是文件交集。两个任务改的文件集合没有交集，才值得并行；有交集就改成串行，或者先合并成一个任务。这条标准比任何参数都管用。

安装与插件这两块若不熟，可以先翻 Codex 安装 把基础环境准备好，再回来看编排。

一、先确认三件事

这三件事决定了并行能不能落地。

1.1 任务是否真的可并行

把每个任务要改的文件列出来，看有没有交集。有交集就不并行，这是硬标准。

1.2 工作区怎么隔离

最稳的做法是每个 Agent 用独立的工作目录或独立分支，改完再由人工或脚本合并。共用同一个工作目录时，写冲突几乎是必然的。

1.3 审批级别设到哪一档

配置文件里可以设定审批策略与沙箱模式。并行时建议保守一些，让可能改动文件的操作先经过确认。

# ~/.codex/config.toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"

上面这段配置做的是：把审批策略设为按请求确认，沙箱模式限定为只允许在工作区内写入。具体可选值以官方文档为准，这里是编辑推断，改之前先核对文档里的取值列表。

⚠️ 注意：沙箱模式放开到允许任意写入时，并行任务的风险会成倍放大。多智能体场景下宁可保守，也不要为了省一次确认而放开权限。

二、三种编排方式

按任务形态选，不要一套用到底。

2.1 按目录并行

适合给不同模块加同类改动，比如给几个独立模块各补一份单元测试。优点是冲突概率低、耗时接近单任务；代价是需要提前划清目录边界。

2.2 流水线串行

适合有依赖关系的任务，前一个的产出是后一个的输入。优点是每步结果可验证；代价是总耗时是各步之和，没有并行收益。

2.3 写审分离

一个 Agent 负责改代码，另一个只做审查不改代码。优点是能挡掉一部分明显问题；代价是审查意见需要人来最终判断，不能直接采信。

三、最小可跑示例：一次并行任务

下面给一条可执行的最小路径，每一步都有预期结果。

3.1 准备两个独立工作区

mkdir -p /tmp/w3cschool-agent-a /tmp/w3cschool-agent-b

上面这条命令做的是建两个独立目录，分别给两个 Agent 使用。预期结果（未执行，依据命令行语义）是生成两个空目录。目录分开是避免写冲突的第一步。

3.2 分别在各自目录里启动任务

codex --cd /tmp/w3cschool-agent-a "给 utils 模块补单元测试"
codex --cd /tmp/w3cschool-agent-b "给 parser 模块补单元测试"

上面两条命令做的是在两个独立目录里各跑一个任务，互不干扰。预期结果（未执行，依据命令行参数说明）是两个任务各自在目录内产出改动；若提示参数不存在，先核对文档里的参数写法。

3.3 合并前先各自验证

cd /tmp/w3cschool-agent-a && ls -R

上面这条命令做的是列出改动后的目录结构，用来确认改动范围是否符合预期。合并前的验证不能省，直接把两份改动合到一起再发现问题，回滚成本会高很多。

四、三个高频失败与修复

这三个占了并行场景里绝大多数的问题。

4.1 改动互相覆盖

原因是两个 Agent 写了同一个文件。修复方式是退回串行，或重新划分目录边界，确保文件集合没有交集。

4.2 风格不一致

原因是各 Agent 拿到的上下文不同，命名与结构各写一套。修复方式是在每个任务里显式说明要遵循的既有约定，而不是让它自由发挥。

4.3 成本失控

原因是并行任务数开得过多，或者单个任务陷入反复重试。修复方式是限制同时在跑的任务数，并给每个任务设明确的完成标准，达到就停。

💡 小提示：先从两个 Agent 开始。并行数从 2 往上加时，收益增长很快会变平，但排查成本会线性上升。

总结

Codex 多智能体的前提是任务能被拆成文件无交集的几块，工作区要隔离，审批级别要保守。三种编排里，按目录并行是收益最明显的一种，流水线串行的价值在可验证，写审分离的价值在二次把关。

要点带走：

• 判断能不能并行，看文件集合有没有交集；
• 每个 Agent 用独立目录或分支，共用工作区必然冲突；
• 并行数先从 2 开始，加数量不如先把任务拆干净。

下一步建议先拿两个独立模块做一次完整演练，确认合并流程顺了再扩大范围。能力边界这块可以顺着 Codex 插件 继续了解。

常见问题

Q：多智能体是不是一定比单个更快？

A：不一定。任务有文件交集时会互相覆盖，回滚的时间往往超过并行省下的时间。先拆任务，再谈并行。

Q：两个 Agent 改了同一个文件怎么办？

A：退回串行是最省事的处理。若必须并行，重新划分目录边界，让两个任务的文件集合彻底不相交。

Q：并行任务开多少个合适？

A：从两个开始。并行数增加带来的收益很快会变平，但排查与合并成本会持续上升。

Q：审查 Agent 给的意见能直接采纳吗？

A：不能。它给出的意见是参考，最终判断要由人来做，尤其是涉及接口变更和性能取舍的结论。

延伸学习

想把这条路走通，可以按这个顺序来：

1. 读一篇相关笔记 AI 编程助手横向对比，看同类工具的能力差异；
2. 想动手练，Python 配套课程 把工程基础补齐；
3. 概念想再展开，可以看 AI 编程技能教程。