拆解，是子 Agent 的灵魂
上一节讲了子 Agent 是什么。这一节解决更关键的问题：怎么把一个复杂任务拆成合适的子任务。拆得好，一切顺利；拆得烂，比不拆还糟。
对 codex-review 来说尤其如此：评审任务的拆解，决定了评审的质量。 拆得清楚，每个评审子 Agent 都有明确的「审查范围」和「验收标准」；拆得含糊，三个子 Agent 会互相踩脚、漏审、重复审。
拆解的两个判断标准
拆出去之前，先问两个问题：
- 边界清晰吗？这个子任务有明确的目标和范围吗？
- 能独立验证吗？做完后，能清楚判断它做对没有吗？
两个都「是」，才值得拆。都「否」，别拆，直接让主会话做。
对评审场景，这两个标准要格外较真：
- 边界清晰：不只说「审逻辑」，要说清「审哪些文件、重点查什么（业务正确性 / 边界情况 / 异常处理）」。范围越具体，越不容易和别的子 Agent 抢。
- 可独立验证：不是「看一遍」，而是「能输出一份可勾选的结论清单」。比如「这个文件第 42 行的空值判断有遗漏」——这就叫可验证。笼统的「整体还行」不可验证。
一个正确的拆解示例
目标是「给项目加登录功能」。错误的拆法：
❌ 子任务A：写登录、子任务B：写注册、子任务C：写权限……
太碎、互相耦合，调度起来一团糟。
正确的拆法（按「数据库 / 后端 / 前端」横向分工，各自独立可验证）：
主会话：加登录功能
├─ Agent A：设计并建好用户表（数据库）
│ 可验证：建表脚本能跑，表结构符合设计
├─ Agent B：实现登录/注册后端接口（API）
│ 可验证：接口按接口文档返回正确结果
└─ Agent C：写前端登录页并接上接口（前端）
可验证：页面能调用接口、提示成功/失败
每个子任务都有「可验证」的产出，互相之间只有接口约定，没有纠缠。
把同一套思路套到 codex-review 的评审拆解上，正确的拆法不是「按文件」而是「按关注点」：
主会话：评审这次 30 个文件的改动
├─ Agent A：逻辑评审
│ 范围：src/ 下业务逻辑改动
│ 重点：分支逻辑、边界情况、异常处理、数据一致性
│ 可验证：输出「位置 + 问题 + 建议」，按三档归类
├─ Agent B：安全评审
│ 范围：所有涉及输入、权限、敏感信息的文件
│ 重点：SQL 注入、越权、硬编码密钥、日志泄密
│ 可验证：对每个疑似风险，给出触发路径和修复建议
└─ Agent C：风格与可维护性评审
范围：全部改动文件
重点：命名、格式、重复代码、注释
可验证：输出规范一致性问题清单
注意这里的关键：逻辑 / 安全 / 风格 是按「关注点」拆，不是按「文件」拆。 因为一个文件往往同时有逻辑、安全、风格三类问题，按文件拆会让每个子 Agent 都得通读全文，等于没拆。按关注点拆，每个子 Agent 带着专业视角扫全部改动，各审各的维度，才互不干扰。
拆解的维度
常见的有用拆分维度：
| 维度 | 例子 |
|---|---|
| 按模块 | 前端 / 后端 / 数据库 |
| 按阶段 | 分析 → 实现 → 测试 |
| 按对象 | 这个服务 / 那个服务 |
| 按横切 | 安全审查 / 性能检查（并行的旁路任务） |
同一任务可以按不同维度拆，选「子任务之间最独立」的那个。
对 codex-review 这类评审任务，最有用的两个维度是：
- 按关注点（横切）：逻辑 / 安全 / 风格。适合「跨文件、每个文件都可能有多种问题」的评审，是 codex-review 的主拆法。
- 按模块：审 A 模块 / 审 B 模块。适合「模块之间边界清晰、几乎没有交叉引用」的仓库。
实际项目里常常组合用：先按模块分，每个模块内部再按关注点分。拆出来的子 Agent 数不要贪多，一般 3~5 个就够，再多调度成本就上来了。
给子任务写清「交付要求」
拆出来后，每个子任务要附上明确的交付要求，否则子 Agent 不知道做到什么算完：
Agent B：实现登录接口
要求：POST /api/login，输入 {email,password}，
成功返回 {token, user}，失败返回 401；
遵循项目里已有的错误处理规范；完成后跑一遍接口测试。
范围 + 输入输出 + 规范 + 验收，缺一不可。
对评审子 Agent，交付要求要明确「输出什么格式、覆盖哪些范围、达到什么算合格」：
Agent A：逻辑评审
范围：src/ 下本次改动涉及的业务逻辑
要求：对每个改动点，输出「位置 + 问题 + 建议」；
按「必须改 / 建议改 / 可不改」三档归类；
必须覆盖：分支逻辑、边界情况、异常处理、数据一致性；
不必覆盖：命名格式（那是风格评审的活）。
注意最后一句「不必覆盖」很关键——它主动给子 Agent 划清了边界，避免它越界去管别的小 Agent 的事。
编排的顺序
子任务之间往往有依赖。常见的编排方式：
- 并行：互不依赖的，同时进行（最快）
- 串行：有依赖的，等前一个完成（A 建好表，B 才能写接口）
- 混合：先并行的部分 + 最后汇总
你在指令里把「哪个先、哪个后、最后怎么汇总」说清楚，主会话就按这个编排。
对 codex-review，评审的三个关注点（逻辑 / 安全 / 风格）通常互相独立、可以完全并行，最后汇总成一份报告即可。这是最省事的编排。但如果它们之间有关系（比如「安全子 Agent 发现的问题，会改变逻辑子 Agent 的结论」），就要考虑先并行的部分 + 一次汇总对账。
落地练习
② 怎么判断做对了：三个子 Agent 各有明确范围、没有互相抢同一类问题；每个都能输出「位置 + 问题 + 建议」的可勾选清单；汇总报告里没有「这个子 Agent 也在说那个子 Agent 该说的」的重复。
③ 卡住了怎么办：如果两个子 Agent 结论重复，说明「范围」写得不清楚，回去把「不必覆盖」写具体；如果某个子 Agent 审得太泛，就把它的「重点」从一项拆成几项更细的检查点。
常见坑：按「文件」拆评审，等于没拆
评审任务最大的拆解误区，就是按文件拆：「子 Agent A 审 a.js、B 审 b.js、C 审 c.js」。听起来分工明确，其实每个子 Agent 都得把文件从头读到尾、在脑子里同时处理逻辑 + 安全 + 风格三类问题——这跟让一个 Claude 审全部没本质区别，只是把工作切开堆给了三个 Claude。
为什么按关注点拆更对？因为同一段代码可能同时有逻辑、安全、风格三种问题，按文件拆会让这三个问题被塞进同一个子 Agent 的上下文里，它照样会「顾此失彼」；按关注点拆，每个子 Agent 只专注一种判断维度，上下文干净、判断更专业。
小结
- 拆解标准：边界清晰 + 可独立验证
- 按模块/阶段/对象等维度拆，选最独立的
- 评审任务建议按「关注点」拆（逻辑 / 安全 / 风格），并写清「不必覆盖」
- 每个子任务写清交付要求（范围+输入输出+规范+验收）
- 按依赖关系定编排顺序（并行/串行/混合）
下一节，动手练多 Agent 并行协作——把拆好的子任务真正同时跑起来。