大型开发任务交给一个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：
检查前端请求与超时配置；
检查后端接口和数据库调用；
检查相关测试与最近提交。
子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越多，重复修改和结果冲突反而越严重。
