并行子 Agent
系列入口：如何使用 Agent。前置：Orchestrator-Worker 模式。
一、并行的收益来自「任务互不依赖」
当一个大任务能切成几块彼此不需要对方结果的子任务时，就可以同时派给多个子 Agent 并行执行。原本串行要跑 N 轮的活，时间上接近只跑一轮，这是子代理除了上下文隔离之外的第二大收益。
典型可并行场景：分别调研多个模块、给多个互不相关的文件补测试、为同一个需求生成多个候选方案、按页面分头实现。判断能不能并行，就问一句：这些子任务之间，有没有谁必须等另一个的产出？ 没有，就适合扇出。
二、让结果「汇总得起来」
并行最大的实操难点不在派出，而在收回。多个 Worker 各自交回时，如果格式不一、详略不同，主 Agent 很难拼合。对策：
- 派活时统一输出格式：明确每个 Worker 交回的结构（字段、路径、结论粒度），让结果天然可对齐。
- 主 Agent 做整合校验：检查各结果是否完整、有无矛盾或遗漏，而不是简单拼接。
- 需要时再补一轮：发现某个子任务没做对，可以只重派那一个，不必全部重来。
三、规避写竞态：别让它们同时改同一处
并行 Worker 如果都去写同一个文件或共享资源，就会产生竞态：后写入的覆盖先写入的、改动互相打架、结果不确定。规避原则：
- 读多写少的调研类任务最适合并行（它们只交结论，不抢着改文件）；
- 需要写代码时，按文件/模块把写边界切干净，确保每个 Worker 改的是不重叠的文件集合；
- 公共文件（配置、入口、生成的索引）由主 Agent 最后统一改，而不是多个 Worker 并行动；
- 实在无法避免对同一处的修改，就把那部分改成串行，别硬并行。
四、成本控制：并行不是越多越好
并行省下时间，但 token 消耗是各子任务之和，扇出太多还可能又慢又贵。几个控制手段：
- 模型分级：简单子任务用便宜模型，只给真正难的子任务派强模型（见子 Agent 配置）；
- 限制并发数量：一次扇出的 Worker 数保持在合理范围，过多的分批跑；
- 盯住失控信号：某个 Worker 反复重试、不断扩大范围，及时单独叫停，避免它在并行里悄悄烧钱（对应空转/发散纠偏）。
| 风险 | 表现 | 对策 |
|---|---|---|
| 结果拼不起来 | 格式各异、互相矛盾 | 统一格式 + 主 Agent 校验 |
| 写竞态 | 同文件互相覆盖 | 切干净写边界/公共部分串行 |
| 成本爆炸 | Worker 太多或失控 | 模型分级、限并发、及时叫停 |
五、一次完整实战：并行评估四个技术方案
来看一个适合并行的例子。任务是：「我们要选一个缓存方案，分别调研四个候选库，最后横向对比。」四个候选彼此独立，是标准的扇出场景。
- 切分：主 Agent 把任务切成四份，每个 Worker 调研一个缓存库。
- 统一格式：派活时规定每份调研必须包含同样的维度——性能特征、内存占用、社区活跃度、许可证、与现有技术栈的契合度、主要风险。格式统一，最后才好横向对比。
- 并行执行：四个 Worker 同时开跑，各自在隔离上下文里读文档、看数据，只交回结构化结论。
- 整合校验：主 Agent 把四份结果放进同一张对比表，检查各维度是否都填了、结论之间有没有口径不一致，再给出推荐。
- 按需补派：如果某个库的社区活跃度信息不足，只重派那一个 Worker 补全，其他三份不动。
最终你拿到的是一张干净、口径统一的对比表，而不是四篇风格各异、无法对齐的长文。并行省下了时间，统一格式和整合校验保证了质量。
六、判断与操作要点
- 先确认无依赖再扇出：只要有一个子任务要等另一个的产出，那部分就应串行。
- 读多写少的任务最放心并行；要写代码，必须把写边界按文件/模块切干净。
- 公共文件由主 Agent 统一收口，不要让多个 Worker 同时动。
- 并发数有上限、模型分级，并盯住在并行里悄悄失控烧钱的个别 Worker。
- 收回必须整合，不做简单拼接：矛盾和遗漏要在这一步暴露。
七、常见问题
Q：并行一定比串行快很多吗？ 时间上接近只跑一轮，但受限于实际并发能力和整合成本；无依赖的大批量调研收益最明显，强耦合任务则不适合。
Q：怎么避免两个 Worker 改同一个文件？ 按文件/模块切分写边界，确保集合不重叠；公共部分由主 Agent 最后统一改；无法切干净就改串行。
Q：并行跑了一堆，成本反而更高怎么办？ 检查是否简单子任务也用了强模型、并发是否过多、有无 Worker 在反复重试。用模型分级、限并发和及时叫停来控制。
七点五、并行的本质：用空间换时间，但要付协调税
理解并行子 Agent，最清楚的一个心智模型是「用空间换时间，但必须付一笔协调税」。把它想透，你就能预判并行什么时候划算、什么时候反而吃亏。
所谓「用空间换时间」，是指原本要串行跑 N 轮的任务，通过同时铺开 N 个执行者，在时间上压缩到接近一轮。这个收益非常实在，尤其在大批量、彼此独立的调研类任务上，提速常常是最直观的回报。但代价是，你要同时供养 N 个上下文（这是「空间」成本），还要额外付出一笔协调税——切分任务、统一格式、处理竞态、最后整合，这些工作在串行时往往不需要或更简单，在并行时却无法回避。
这笔协调税决定了一个临界点：当任务本身很重、且子任务清晰独立时，协调税相对于省下的时间很小，并行非常划算；而当任务偏小、或子任务之间关系复杂时，光是切分、对齐、处理冲突的协调成本，可能就吃掉甚至超过并行省下的时间，结果又慢又乱。所以判断要不要并行，不能只看「能不能同时跑」，还要估算「协调税划不划算」。
一个非常实用的经验是：读多写少、产出可结构化对齐的任务，协调税最低，最适合并行；需要大量写操作、子任务边界模糊的任务，协调税最高，应谨慎或串行。 当你开始下意识地估算这笔税，而不是见到任务就想扇出，就说明你对并行的理解成熟了。
七点六、整合环节为什么是并行成败的收口
很多人把注意力都放在「怎么把任务派出去」，却低估了收回后的整合环节。事实上，派出只是并行的开始，整合才是决定这次并行有没有产生价值的收口。
道理很简单：并行的 N 个执行者各自独立工作，天然带有「各自为政」的倾向——它们对同一概念可能用了不同口径、对共同背景可能有不同理解、个别执行者还可能遗漏或失误。如果主 Agent 在收回时只是把 N 份结果机械拼接，这些不一致就会原封不动地保留下来，你最终拿到的不是一个结论，而是一堆需要再人工对齐的半成品，并行省下的时间又在整合阶段被还了回去。
真正有效的整合，要主动做三件事：检查各份结果是否完整、有无遗漏；用统一口径对照它们之间是否矛盾；判断拼合起来能否回答最初的那个问题。发现某处不足，可以只重派那一个执行者，而不是全部重来。这个「校验—对齐—按需补派」的收口动作，把并行的分散努力真正凝聚成一个可靠结论。
所以，在设计一次并行时，就应该提前想好最后如何整合——需要哪些字段才能对齐、用什么标准判断一致性、由谁做收口。当整合被当作与「扇出」同等重要的一环来设计，并行带来的提速才会沉淀成质量，而不是转化成新的混乱。 这也是为什么本系列反复强调：任何并行，最终都必须由主 Agent 做整合校验，而不能一拼了之。
七点七、竞态的根源：共享了不该共享的东西
写竞态看似是并行特有的技术问题，但它的根源其实很朴素——多个执行者同时去动同一份它们本该互不共享的东西。 看清这个根源，预防竞态就不需要死记一堆规则，只需守住一个原则：让并行的执行者各自拥有不重叠的写入领地。
为什么调研类任务几乎不会遇到竞态？因为它们只读不写，交回的是各自的结论，本质上没有共享的可变资源，自然不存在「谁覆盖谁」。而一旦并行的 Worker 开始写文件、改配置、更新同一份索引，它们就触碰了共享资源：后写的人可能并不知道先写的人已经改过，于是用自己的版本覆盖，结果取决于执行顺序这种偶然因素，变得不可预测。这类问题最讨厌的地方在于它不稳定——同样的流程再跑一次可能结果又不同，因而极难复现和排查。
预防的思路顺着根源就很清晰：能只读并行就只读；必须写时，按文件或模块把写边界切到互不重叠；那些人人都可能要动的公共文件（入口、配置、汇总索引），不要让 Worker 们并行动，而应交给主 Agent 在最后统一收口；如果某处修改实在无法切分，那就老实把那一小段改成串行。核心不是消除所有共享，而是确保「同一时刻、同一处，只有一个写入者」。
七点八、成本失控往往是「悄悄」发生的
并行还有一个容易被忽视的风险——成本失控常常不是大张旗鼓地发生，而是在你盯着整体进度时，被某个角落里的个别 Worker 悄悄烧掉。理解这一点，你才会在并行中主动去盯成本，而不是等账单出来才吃惊。
为什么并行里更容易出现这种「悄悄烧钱」？因为你的注意力被摊在了多个执行者和最终汇总上，单个 Worker 的内部过程不像在单 Agent 时那样始终在你视野里。如果其中一个陷入了反复重试、或不断自行扩大检索范围、或在一个死胡同里打转，它会持续消耗 token，而这一切可能被其他几个正常完成的 Worker 所掩盖——表面上任务在推进，实际有一个环节正在空转。
应对这种隐性失控，靠的是几个低成本的机制：给整体设置步数或花费上限，超出就暴露；模型分级，让简单子任务即便多跑也不至于太贵；并发数量有节制，便于你真正照看得过来；以及在等待汇总时，留意有没有某个 Worker 长时间不返回、或反复发起类似动作，发现就单独叫停和检查，而不必牵动其他已经完成的部分。把「盯住个别异常者」变成并行时的固定动作，再配合上限和分级，你就能在享受提速的同时，不让成本在视野盲区里悄悄失控。
七点九、扇出数量：多少才算合适
决定并行后，一个非常具体的问题随之而来：一次到底派多少个 Worker 才算合适？这个数字并非越大越好，它受限于协调能力、实际并发条件和成本，需要一个务实的把握。
从收益侧看，当子任务确实独立时，增加 Worker 能让覆盖更广、总耗时更短，尤其在要调研的对象很多时。但从成本侧看，Worker 越多，你和主 Agent 要统一格式、核对结果、处理个别失败的协调负担就越重，而总 token 消耗几乎随数量线性上升。当数量大到你无法真正照看每个结果时，整合就会滑向表面化，矛盾和遗漏被放过，并行的质量开始下降。
一个实用原则是：一次扇出数量控制在你能逐一核对、且系统能稳定并发的范围内，超出的子任务分批跑，先完成一批、整合一批，再放下一批，而不是一次性全铺开。分批看似少了点并行的痛快，却换来可控和可核对，整体往往更稳。把数量与你的实际协调能力匹配，而不是追求理论上的最大并发，是并行成熟度的体现。
七点十、并行结果的三种典型不一致
整合之所以必须认真做，是因为并行的多个 Worker 天然会产生不一致。提前认识最常见的三种，你在汇总时就知道该重点找什么。
第一种是格式不一致：同样的信息，有的 Worker 用表格、有的用段落，字段命名和粒度各不相同，导致结果无法直接对齐。这要靠派活时统一输出模板来预防。第二种是口径不一致：对同一个概念（比如「活跃用户」「风险等级」），不同 Worker 采用了不同的理解和标准，各自的结论单看成立，放在一起却互相冲突。这需要主 Agent 在整合时用统一定义去校正。
第三种是覆盖不一致：有的子任务做得深、有的浅，有的覆盖了边界、有的只查了主路径，导致横向比较时厚薄悬殊，结论可能被这种差异误导。整合时要识别这种深浅差别，对过浅的部分补派，而不是把不同深度的结果当成同等可信来对比。认清这三种不一致，并在整合中逐一消除，并行产出才能真正拼成一个可信整体。
七点十一、并行失败后，该不该全部重来
并行任务出问题时，新手常见的反应是把所有 Worker 全部重跑一遍，图个干净；但这往往是最浪费的选择。这里专门讲讲失败后如何决定重跑范围，这是并行里很实用的成本意识。
先建立一个判断：并行的各个子任务是独立失败的，因此也应当被独立处理。 如果整合后发现是某一个 Worker 做错了、漏了，而其余几个都正确，那么问题只存在于那一格，重跑正确的几个没有任何意义，只会重复消耗 token、重复占用时间。正确做法是只重派出错的那一个，再把它的新结果放回整体中重新校验拼合即可。这也是为什么前面强调要在整合时定位清楚「具体哪里不一致」——定位得越准，重跑范围越小。
当然也有例外。如果发现失败的根源是一个共同前提错了，比如派活时给所有 Worker 的口径或背景本身有误，导致它们集体建立在错误基础上，那就不是个别重跑能解决的，需要纠正共同前提后整体重派。区别的关键在于：问题是局部的执行失误，还是共享的输入错误？ 前者局部重跑，后者整体重来。养成先判断失败性质、再决定重跑范围的习惯，你就能在并行返工中把成本压到最小，而不是用「全部重来」这种省事却昂贵的方式掩盖定位的懒惰。
总结
并行子 Agent 适合把互不依赖的子任务同时扇出以缩短时间，但必须统一输出格式、把写边界切干净以防竞态、并用模型分级和并发上限控制成本——收回后由主 Agent 做整合校验，并行带来的提速才不会被混乱和超支抵消。