并行，是子 Agent 的提速点
前面学了解读、拆解。这一节动手做多 Agent 并行协作——让多个子 Agent 同时干活，这是子 Agent 相对「单线程对话」最大的优势。
对 codex-review 而言，并行就是它的命根子：一次评审 30 个文件，如果串行审，逻辑 → 安全 → 风格一个个来，时间全堆在排队上；并行审，三路同时跑，总时间取决于最慢的那一路。这就是「多 Agent 协作评审工作台」名字的由来。
为什么并行能快这么多
一个 Claude 只能「一件一件做」。多个子 Agent 并行时，A 在改前端的同时 B 就能查后端、C 就在做测试，总时间 ≈ 最慢的那个子任务，而不是所有任务之和。
适合并行的场景：
- 多文件重构：每个模块一个 Agent，互不干扰
- 横向检查：安全审查、性能检查、依赖扫描，同时跑
- 独立功能：几个互不依赖的功能点，同时做
评审是这个规律的完美应用：逻辑、安全、风格三个维度彼此独立，并行审完全可行。 串行审一份报告可能要 10 分钟，并行审可能 3 分钟就出齐，剩下的时间用来汇总和核对。
一个并行实操示例
假设你要在项目里同时推进「加注释 + 统一命名 + 检查安全」。这三个互不依赖，可以并行：
请并行启动三个子任务：
1. 给 src/utils/ 下的工具函数补充注释
2. 把 src/ 下命名不符合 camelCase 的变量统一
3. 检查 package.json 依赖是否有已知安全漏洞
最后把三份结果汇总，标出「已完成 / 有问题」。
主会话会同时派发三个子 Agent，收齐后汇总。
套到 codex-review，就是你上一节拆好的三路并行评审：
请并行启动三个评审子 Agent，对 src/ 本次改动做评审：
1. 逻辑评审：查业务正确性、边界情况、异常处理
2. 安全评审：查注入、越权、硬编码密钥、敏感信息
3. 风格评审：查命名、格式、重复代码、可读性
每路都要输出「必须改 / 建议改 / 可不改」三档清单，
最后把三份汇总成一份评审报告。
三路同时开工，你只需要等最慢的那一路。
并行的前提：子任务真的独立
并行最容易翻车的地方是假独立——两个子 Agent 改同一个文件，互相覆盖。
判断独立与否：
- 改同一文件？ → 不独立，合并或串行
- 有数据依赖？ → 不独立，等前置完成
- 改不同文件/不同区域？ → 独立，可并行
但评审有个特殊性：评审是「只读」的，子 Agent 通常不改文件、只出结论。 所以「改同一文件」这个冲突点，在评审里天然就不存在——三路子 Agent 都在读同一批文件、写各自的结论，互不覆盖。这也是为什么评审特别适合并行：只读任务几乎总是可以放心并行。
不过仍要留意两点「软冲突」：
- 都在抢同一批上下文：如果三路子 Agent 都要读 30 个文件，IO 和 token 成本会叠加，不算快得很夸张。此时可以考虑按模块进一步切分，或接受这个成本。
- 结论可能互相矛盾：并行完的汇总阶段要专门「对账」，否则「逻辑说该改、安全说别动」这种矛盾会漏掉。
处理并行的结果
并行完不是结束，要汇总和验收：
- 收集各子 Agent 的结果
- 检查有没有互相冲突的地方
- 有问题让对应子 Agent 修正
- 主会话做一次整体集成验证
汇总：
- 逻辑：发现 3 处边界未处理 ❌
- 安全：1 处硬编码密钥，需修复 ❌；2 处输入未校验 ⚠️
- 风格：5 处命名不规范，可不改 ⚠️
冲突对账：逻辑#2（建议把 X 提前返回）与安全#1（建议在 X 前加校验）不冲突，可一起改。
建议：先修安全 1 处 + 逻辑 3 处，再处理风格。
这是 codex-review 报告的核心形态：每路结论 + 冲突对账 + 修复优先级。千万别只把三份结论并排贴出来就算完，没对账的报告，等于没审透。
什么时候别用并行
- 子任务强耦合、改同一文件 → 别并行
- 任务太小，并行调度开销反超收益 → 别并行
- 你无法并行审查 → 串行更可控
并行是手段不是目的，可控 > 快。
对评审场景，两条要特别记住：
- 改动只有 1~2 个文件：拆三路并行，调度成本反超收益，直接单路审更快。
- 你要手动逐行把关：并行出的结论需要你逐条人工核对，串行反而让你能跟着思路走。此时可以只并行「探索性的旁路检查」，主路线保持串行。
落地练习
② 怎么判断做对了：能看到三路确实并行推进、结论相互独立；汇总报告里有专门的「冲突对账」一节；「必须改」项都有明确的「位置 + 问题 + 修复建议」，能直接照着改。
③ 卡住了怎么办：如果三路结论混成一大段、分不清谁是谁，让它「分别标注来源（逻辑/安全/风格）再汇总」；如果对账没做，直接补一句「请把三路结论里互相矛盾的地方单独列出来」。
常见坑：只拼三份结论，不「对账」
很多人并行审完，把三路子 Agent 的结论往报告里一贴就完事了。这是最典型的偷懒：逻辑说「这里应该提前 return」，安全说「这里之前要先校验」，两句话放在同一段代码上，到底哪个对？ 不放在一起对账，这个矛盾就永远发现不了。
对账不是「把三段拼一起」，而是专门检查不同子 Agent 的结论在「同一个代码位置」上是否冲突、能否合并执行。codex-review 工作台把这一步做成报告的固定一节，就是为了逼出这类矛盾。
小结
- 并行让总时间 ≈ 最慢子任务
- 判据：改不同文件 = 独立 = 可并行
- 评审是只读任务，天然适合并行；但仍要做冲突对账
- 并行后要汇总、查冲突、整体验证
- 强耦合或难审查时，别硬并行；小改动直接单路审
下一模块进入「计划模式」，动手前先把思路想清楚——这也将用来规划 codex-review 的评审流程。