Codex子Agent怎么用？把大型开发任务拆成并行执行

大型开发任务交给一个Codex会话后，常见问题不是模型不会写代码，而是任务链太长：它既要分析仓库、修改业务逻辑，又要补测试、检查风险和整理文档。随着日志、命令输出和中间判断不断堆积，主会话很容易被无关信息占满。

Codex子Agent的价值，就是把边界清楚、可以独立完成的工作从主任务中拆出去，让主Agent保留需求、约束和最终决策，再统一汇总各个子任务的结果。官方文档也将子Agent定位为处理探索、测试、分类等有明确边界工作的方式。

一、子Agent解决的不是速度，而是上下文污染

假设要完成一个“新增订单退款功能”的任务。

一个Agent串行执行时，可能需要：

• 查找订单与支付模块；

• 分析退款状态；

• 修改后端接口；

• 更新前端页面；

• 编写测试；

• 检查权限；

• 更新接口文档。

其中大量搜索结果、测试日志和错误堆栈都会进入主会话。真正重要的需求边界，反而容易被埋在中间输出中。

Codex官方把这种现象概括为上下文污染和上下文衰减：会话中的噪声越多，后续判断越可能受到干扰。子Agent可以把探索和执行过程留在独立线程，只把结论和必要证据返回主Agent。

所以，子Agent真正解决的是：

让不同任务拥有独立上下文，避免所有过程挤进同一个会话。

二、什么任务适合拆给子Agent？

适合子Agent的任务通常具备三个特点：

• 工作范围明确；

• 与其他任务依赖较少；

• 输出结果可以单独验收。

例如：

• 分析某个模块的调用关系；

• 查找与一个Bug相关的文件；

• 为已有实现补充测试；

• 检查代码是否存在安全风险；

• 汇总失败测试和错误日志；

• 更新与本次变更相关的文档；

• 对一个独立目录执行代码审查。

不适合直接并行的任务包括：

• 多个Agent同时设计同一个接口；

• 两个Agent修改同一组核心文件；

• 上游数据结构尚未确定，下游已经开始实现；

• 任务目标仍然模糊，需要持续讨论；

• 多个修改必须按严格顺序执行。

判断标准不是“任务够不够大”，而是：

这些工作能不能在较少沟通的情况下独立完成？

如果答案是否定的，强行拆分只会增加交接成本。

三、怎样让Codex使用子Agent？

在Codex应用、CLI或IDE会话中，可以直接要求主Agent把独立工作委派给子Agent。Codex也可以根据适用的AGENTS.md或Skill指令决定是否进行委派。应用会展示各子Agent线程，主会话最终收集并总结它们返回的结果；CLI中则可以使用/agent查看和切换线程。

例如可以输入：

分析当前项目的登录超时问题。
主任务负责确定根因和最终修改方案。
分配三个子Agent：

1. 检查前端请求与超时配置；

2. 检查后端接口和数据库调用；

3. 检查相关测试与最近提交。
   子Agent只分析，不修改代码。
   等三个结果返回后，再由主任务决定修改范围。

这里最重要的不是“启动三个Agent”，而是明确：

• 每个Agent检查什么；

• 是否允许修改；

• 最终必须返回什么；

• 哪个Agent负责做最后决定。

四、大型任务应该怎样拆分？

不要简单按照“前端、后端、测试”机械拆分。

更可靠的方式是按照依赖关系和交付物拆分。

以新增文件上传功能为例，可以分成：

探索子Agent

查找现有上传逻辑、存储配置和权限规则，只输出相关文件及潜在风险。

接口子Agent

在契约确定后，实现上传接口，不修改页面。

前端子Agent

根据已经确定的接口结构完成页面接入。

测试子Agent

针对最终Diff补测试并运行验证，不参与最初实现。

审查子Agent

检查是否扩大修改范围、是否泄露敏感信息，以及错误处理是否完整。

主Agent负责确定接口契约、协调执行顺序、解决冲突和决定最终交付。

这样的结构比“所有Agent同时开始”更稳，因为它区分了：

可以并行的任务，与必须等待上游结果的任务。

五、用AGENTS.md固定分工规则

如果团队经常使用子Agent，不要每次都重新解释测试命令和修改边界。

Codex会在开始工作前读取适用的AGENTS.md，并按照从全局到项目、再到具体目录的顺序组合指令；越靠近当前目录的规则，优先级越高。

可以在项目根目录写入：

# AGENTS.md ## 子Agent规则 - 探索任务默认只读，不修改文件。 - 实现Agent不得修改测试断言以绕过失败。 - 测试Agent只修改tests目录。 - 多个任务涉及同一接口时，先由主Agent确认契约。 - 所有子Agent必须返回修改文件、验证结果和剩余风险。 - 未经明确要求，不添加生产依赖。

如果某个目录有特殊规则，再在对应目录放置更具体的AGENTS.md或AGENTS.override.md。

例如支付模块可以增加：

不允许修改支付状态枚举；
不允许访问生产密钥；
必须运行支付模块集成测试。

官方也建议保持AGENTS.md精简，只保存需要长期重复执行的构建、测试和审查规则。

六、子Agent之间怎样避免重复修改？

子Agent最常见的问题，是两个任务都认为某个文件属于自己的范围。

开始前应为每个任务指定：

• 允许读取的范围；

• 优先修改的目录；

• 禁止修改的文件；

• 依赖的上游结果；

• 输出格式。

例如：

Agent A只修改src/api；
Agent B只修改src/pages；
Agent C暂不修改代码，只检查tests；
共享类型由主Agent统一处理。

如果多个子Agent确实需要修改同一个仓库，可以通过独立线程和Worktree隔离执行。Codex应用支持多个Agent在不同线程中并行工作，也支持通过Worktree让任务使用独立代码副本。

但要注意：

Worktree只能隔离执行环境，不能消除最终合并冲突。

真正避免重复修改的关键，仍然是提前划清文件和职责边界。

七、主Agent必须统一验收

子Agent完成任务后，不能直接把所有结果拼在一起提交。

主Agent至少要检查：

• 每个子任务是否完成目标；

• 不同结果是否使用同一需求；

• 是否修改了重复文件；

• 接口、类型和错误码是否一致；

• 测试结果是否来自最终代码；

• 是否存在未说明的风险；

• 合并顺序是否正确。

推荐要求每个子Agent按统一格式交付：

**任务结论：**完成了什么。
**修改范围：**涉及哪些文件。
**验证证据：**运行了哪些命令。
**未解决问题：**哪些内容仍需确认。
**建议动作：**可以合并、需要补测或应当停止。

主Agent收到结果后，再生成一份总报告，而不是简单重复每个子Agent的回复。

Codex的主线程会收集子Agent结果并形成最终响应，但开发者仍应检查各线程、Diff和验证记录。

八、不要为了并行而增加Agent

子Agent不是越多越好。

任务拆得过细会产生新的成本：

• 重复读取相同文件；

• 重复运行相同测试；

• 交接信息丢失；

• 多个Agent给出冲突建议；

• 主Agent花更多时间汇总；

• 用量增长，但实际进度没有增加。

对于一个明确的小Bug，一个Agent从分析到验证通常更高效。

只有在以下情况下，子Agent才真正有价值：

• 探索范围较大；

• 存在多个相互独立的模块；

• 测试和审查可以独立执行；

• 中间输出会明显污染主会话；

• 并行节省的时间高于协调成本。

正确目标不是启动更多Agent，而是：

让主Agent专注决策，让子Agent承担边界清楚的执行工作。

结语

Codex子Agent适合把大型开发任务拆成多个独立工作单元，但它不是简单的“多开几个AI”。

可靠流程应该是：

明确总目标
→ 分析任务依赖
→ 划分子Agent职责
→ 限制修改范围
→ 独立执行与验证
→ 主Agent统一审查
→ 人工确认最终交付

子Agent负责降低上下文噪声和并行处理独立工作，主Agent负责保存完整目标、解决冲突和汇总结果。

任务边界清楚时，多Agent可以显著提高大型项目的处理效率；边界不清时，Agent越多，重复修改和结果冲突反而越严重。