Codex 子代理实战：并行提速而不污染主线程的工作方法
适合需要同时做代码检索、测试分析、文档核对或多方案比较的开发者。核心结论是：子代理不是“多开几个聊天窗口”，而是把边界清楚、彼此独立的工作流分出去，主线程只保留目标、决策与验收。
面对大型代码库，很多人会让 Codex 从头到尾串行完成：先找入口，再追调用链，然后跑测试、查文档、写补丁。结果常见两种：一是等待时间长，二是大量日志和搜索片段挤进主线程，真正的约束反而被淹没。子代理适合解决这类问题，但前提不是“任务越多越好”，而是拆分得足够清楚。
子代理真正解决什么问题
OpenAI 官方文档指出，ChatGPT Work 与 Codex 可以并行启动专门的子代理，再由主代理收集结果。它尤其适合代码库探索、多步骤功能计划等高度可并行的复杂任务。官方也提醒：每个子代理都要独立进行模型推理和工具调用，因此通常比单代理消耗更多 token。
它带来的价值主要有三点：
- 缩短等待时间。 多个互不依赖的调查可以同时开展。
- 隔离噪声。 搜索结果、测试日志和堆栈留在子线程，主线程只接收摘要。
- 引入独立视角。 同一变更可分别做规范审查、需求核对和风险分析，减少单一路径造成的遗漏。
所以，衡量是否该用子代理的标准不是任务“看起来很大”，而是能否切成几块，在共享少量输入后独立推进，最后通过明确接口合并结果。
第一步：先判断任务能不能并行
适合拆分的工作通常具备以下特征：输入边界固定、输出形式明确、分支之间几乎不互相写同一文件。例如：
- 子代理 A 追踪前端页面到后端接口的调用链；
- 子代理 B 检查数据库映射和历史数据风险；
- 子代理 C 阅读官方文档，确认当前 API 或配置约束；
- 主代理综合证据，提出方案并等待确认。
不适合并行的情况也很明确：下一步严重依赖上一步结论、多个代理必须修改同一片代码、任务只有一个短命令，或者合并成本高于执行成本。此时串行工作更快，也更容易审计。
一个实用判断题是：“如果其中一条分支晚十分钟返回，其他分支还能继续吗？”答案为“能”，通常值得并行；答案为“不能”，就应先完成共同的前置调查。
第二步：给每个子代理写清任务合同
模糊指令会制造重复劳动。不要只说“帮我看看这个项目”，而应交代五类信息：
- 目标： 最终要回答哪个具体问题；
- 范围： 允许读取哪些模块、目录或数据；
- 边界： 是否只读，能否修改文件，不能做什么；
- 交付物： 需要文件路径、行号、复现命令还是风险清单；
- 完成条件： 哪些证据齐全才算结束。
例如可以这样写：
请只读追踪“订单提交”从页面事件到数据库更新的完整路径。
范围：web、service、mapper 三个模块；不要修改文件。
输出：入口文件与行号、关键方法链、涉及的 SQL、仍需运行时验证的假设。
完成条件：每个结论都附可复查证据。这段任务合同让子代理知道“查到哪里停”，也让主代理能够用统一标准比较多个结果。
第三步：主线程只保留决策信息
官方文档把大量无关中间信息积累称为上下文污染或上下文衰退风险。实战中，主线程不应接收每条搜索输出，而应要求子代理返回压缩后的结果：结论、证据、风险、下一步。
建议统一使用以下回报格式：
结论：一句话回答分配的问题。
证据：文件路径、行号、命令结果或官方链接。
不确定项：哪些结论仍是静态推断。
建议：主代理下一步应验证或修改什么。主代理随后做三件事：检查不同分支是否冲突；区分“代码看起来如此”和“运行时已经证明”；把真正影响方案的分歧留给用户决策。子代理的摘要不是最终事实，仍需主代理交叉核对关键证据。
第四步：并行实现时隔离写入
如果任务进入编码阶段，最危险的做法是让多个代理同时改同一工作区、同一文件。更稳妥的方法是按模块或文件划分写入所有权；需要更强隔离时，使用独立 Git worktree。
OpenAI 的 Codex 文档将 Git worktree 作为开发环境能力单独说明。它允许同一仓库存在多个检出目录，每个目录对应独立分支，适合隔离并行实现。但 worktree 不是自动合并器：开始前仍要约定基线提交、目标分支和文件边界，结束后通过提交、差异审查与测试再合入。
安全流程可以概括为：先记录当前分支和未提交改动；为独立子任务创建独立 worktree；每个代理只在自己的目录工作；主线程审查提交差异；最后按依赖顺序合入并运行完整测试。不要为了“并行”跳过脏工作区检查，也不要让代理用覆盖式命令处理未知改动。
第五步：用统一验收收口
并行能缩短调查和实现时间，却会增加整合风险。收口时至少检查四项：
- 各分支是否基于同一需求和代码基线；
- 是否存在重复修改、接口假设冲突或遗漏依赖；
- 单元测试、集成测试和静态检查是否在合并后重新运行；
- 最终差异是否仍符合最初任务合同。
对子代理输出进行汇总时，最好保留“已验证”“静态推断”“待确认”三个状态。这样不会把一个代理的猜测在多次转述后变成貌似确定的结论。
三个常见误区
第一，代理数量越多越快。实际上，拆分、同步和审查都需要成本；两三个边界清楚的分支通常比十个微小分支更有效。第二，把同一问题交给多个代理却不说明比较维度，最后只得到措辞不同的重复答案。第三，只看子代理说“完成”，却不检查文件差异、测试结果和外部状态。
更好的原则是：只并行独立工作，只下发可验收任务，只合并有证据的结论。 对短小或强依赖任务，坚持单线程；对复杂但可拆分的任务，才让子代理承担探索与验证噪声，让主线程专注于决策。
总结
Codex 子代理的核心优势不是增加“人头”，而是管理上下文和等待时间。先判断依赖关系，再用任务合同明确边界，以结构化摘要回收证据；涉及写代码时隔离工作区，最后统一验收。做到这些，并行才会真正带来速度与质量，而不是把一个复杂任务变成多个难以收拾的半成品。