Orchestrator-Worker 模式
系列入口：如何使用 Agent。前置：子 Agent 配置。
一、一个你熟悉的组织模型
Orchestrator-Worker（编排者-工人）模式，本质上就是现实里的「领班 + 工人」：
- Orchestrator（编排者/主 Agent）：理解大目标、把它拆成若干子任务、决定派给谁、收回结果后整合与决策，必要时继续派下一轮。
- Worker（工人/子 Agent）：不操心全局，只执行分到的那一块明确任务，把结果交回。
这个分工的价值在于：让全局思考和具体执行各自处在最合适的上下文里——编排者保持主窗口干净、拿着全貌做判断；每个工人在自己隔离的上下文里钻具体细节。
二、一次完整协作的流程
- 理解目标：Orchestrator 先弄清要达成什么（这一步你可以用 Plan 模式让它先出方案）。
- 拆解：把大目标分成边界清晰、最好能独立交付的子任务（用任务拆解的原则）。
- 派活：给每个 Worker 明确的目标、范围、输出格式；无依赖的可并行派出。
- 执行与交回：Worker 在隔离上下文里干活，只返回结论。
- 整合与校验：Orchestrator 汇总各方结果，检查是否拼合、有无矛盾，再决定是否需要补派任务。
三、什么场景适合
- 一个大任务能自然切成若干相对独立的块：比如同时调研多个模块、给多个服务各补测试、按页面分别实现；
- 中间过程信息量大、需要上下文隔离；
- 各子任务可以并行、能明显缩短总时长。
如果子任务之间高度耦合、需要频繁共享中间状态、或必须严格按同一套判断层层推进，单纯的主从扇出就不够，更适合 Planner-Coder-Reviewer 那种有交接顺序的模式。
四、两个常见失败及对策
1. 编排者失控（战线越派越大） 它不断派新子任务、扩大范围，最后拼出一个谁也审不动的庞然大物。对策：你在顶层把住目标和范围，让编排者按确认的拆解派活，方案外的新派活要先停下对齐。
2. 工人各自为政（结果拼不起来） 每个 Worker 按自己的理解交回，格式不一、互相矛盾、或对公共部分做了冲突改动。对策：派活时统一输出格式与公共约定；涉及同一份代码的子任务避免并行冲突；编排者必须做整合校验，不能简单把结果堆在一起。
| 角色 | 职责 | 不该做的 |
|---|---|---|
| Orchestrator | 拆、派、汇总、决策 | 不一头扎进具体执行 |
| Worker | 干好一块明确子任务 | 不自行扩大范围 |
五、一次完整实战：给多个服务补测试
来看一个落地例子，帮助你把流程串起来。任务是：「给三个后端服务的工具函数都补上单元测试。」这三个服务彼此独立，是很典型的主从扇出场景。
- 理解目标：你先和 Orchestrator 确认目标——只补工具函数测试、不改业务逻辑、每个服务测试要能跑通。
- 拆解：它把任务切成三个子任务，每个 Worker 负责一个服务。
- 派活：给每个 Worker 统一的输出格式（新增了哪些测试文件、覆盖了哪些函数、测试运行结果），并明确不要改动非测试文件。三个服务无依赖，可以并行派。
- 执行交回：每个 Worker 在隔离上下文里读代码、写测试、跑通后交回结论。
- 整合校验：Orchestrator 核对三份结果是否齐全、格式是否一致、是否都跑通，再汇总给你。如果其中某个服务测试没通过，只重派那一个，而不必全部重来。
整个过程中，三个 Worker 各自读了不少代码，但这些过程信息都没进入主窗口，你看到的只是一份清晰的总览和可以立刻处理的个别问题。这就是主从模式省、稳、快的原因。
六、用好该模式的几个关键
- 拆得好不好，决定了大半成败：子任务要边界清晰、尽量能独立交付；拆得含糊，后面整合一定痛苦。
- 派活时统一格式与公共约定：这是结果能拼合的前提，不要等收回时才发现各说各话。
- 编排者必须真正做整合，而不是堆叠：检查矛盾、遗漏、拼合问题是它不可省略的职责。
- 范围由你在顶层把住：方案外的新派活要先对齐，防止战线失控。
七、常见问题
Q：Orchestrator 自己能不能也动手干活？ 最好让它专注编排。它一旦扎进具体执行，就容易丢掉全局视角和主窗口的整洁；具体活应交给 Worker。
Q：Worker 返回的结果很简略，我担心它没真做对？ 可以要求它附上关键验证证据（如测试运行结果、涉及的位置），但不必带回全部过程。简略和可验证并不矛盾。
Q：什么时候不该用主从模式？ 当子任务高度耦合、要频繁共享中间状态或严格按同一判断层层推进时，应改用有交接顺序的 Planner-Coder-Reviewer 模式，而不是简单扇出。
七点五、主从模式与现实组织的深层相似
这个模式之所以好懂、好用，是因为它几乎照搬了人类组织里最古老也最有效的协作结构——一个负责人带着若干专职工人。理解这种深层相似，能帮你凭直觉判断很多具体问题该怎么处理，而不必死记规则。
在现实里，一个领班之所以能管好多个工人，靠的不是自己比所有人都更会干每一件具体活，而是他清楚整体目标、知道该把哪块活交给谁、并在收回时检查质量。如果领班自己也跑去搬砖，现场反而没人统筹；如果他把活交代得含含糊糊，工人就只能各自理解、结果必然参差；如果他收回成品时只堆放不检查，矛盾和缺漏就会流到下一环节。这些现实中的管理常识，在多 Agent 编排里几乎一一对应：编排者不应深陷执行、派活要清晰统一、整合校验不可省略。
反过来想，现实中一个好领班在派活前会做什么？他会先确认每个工人的能力边界，把任务交代到「对方清楚要交什么、有什么约束」，并约定好验收方式。你在编排 Agent 时做的也是同样的事。当你把主从协作当成「带一个小团队」而不是「操作一堆程序」时，很多分寸感会自然浮现——比如你不会给一个新人交代一句模糊的话就指望完美结果，同样也不该给子 Agent 一个边界不清的任务。
七点六、从一次成功编排到可复用资产
第一次把主从模式跑顺，价值还只是完成了这一件事；更值得做的，是把这次成功的编排方式沉淀下来，让同类任务以后都能复用。
怎么做？当你发现某一类大任务反复出现——比如每次都要给多个服务补测试、每次发版前都要并行检查多个模块——就可以把这次验证过的拆解方式、统一的输出格式、整合校验的要点固定下来，写成 Skill 或团队模板。下次再遇到，就不必重新思考怎么拆、怎么收口，直接套用即可。编排者甚至可以被配置成自动加载这份方法，让整个扇出与汇总过程更稳定。
这里要提醒避免一个反向问题：不要为了「沉淀」而把只出现一次的偶然流程也固化成复杂模板，那会制造维护负担。沉淀的对象应是那些被验证过、且确实会反复出现的编排模式。 把握这个尺度，你就能既享受复用带来的效率，又不会让资产库堆满一次性的东西。当一次次成功的编排逐步沉淀成团队可复用的方法，你就真正把多 Agent 从「临场操作」升级成了「工程化能力」。
七点七、拆解质量决定整合成败
在整个主从流程里，最值得花心思的环节其实是「拆解」，因为它处在链路最前端，一旦拆得不好，后面的派活、执行、整合每一步都会被拖累；而一个好的拆解，往往已经注定了这次编排会顺利。
什么叫拆得好？核心是让每个子任务都边界清晰、尽量能独立交付、彼此重叠最小。边界清晰，意味着每个 Worker 都清楚自己负责到哪里为止，不会出现「这块到底归谁」的空档或重叠；能独立交付，意味着它不必频繁等待或借用其他子任务的中间结果，因而可以放心并行；重叠最小，则减少了多个 Worker 对同一处做冲突假设、冲突改动的机会。这三条其实是相互关联的，本质上都在追求同一件事——让分出去的每块活自成一体。
怎么判断自己拆得好不好？可以用一个简单的测试：把每个子任务单独念出来，看是否包含了完成它所需的全部信息、且交回物能被明确定义。 如果某个子任务要靠「到时候再看别人做的结果」才能完成，或你说不清它最终交什么，那通常是拆得还不够，要么切分方式有问题，要么这部分根本不该并行。花在拆解上的时间，会在整合阶段成倍地赚回来，这是主从模式里最划算的一笔投入。
七点八、整合不是「收尾」，而是「再决策」
很多人把 Orchestrator 的整合理解成流程末尾的一个收尾动作，把各方结果收齐、拼在一起就算完成。这是对编排者职责的低估——整合的本质是一次再决策：它要基于各方交回的信息，判断目标是否真正达成，以及下一步该做什么。
一个合格的整合，至少要回答三个问题。第一，齐全吗？每个被派出的子任务是否都按要求交回，有没有遗漏或交了一半。第二，一致吗？各份结果之间有没有口径冲突、对公共部分有没有矛盾的假设或改动。第三，成立吗？拼合起来的整体，是否真的回答了最初的目标，还是只在局部正确、整体却走样。这三问里任何一个不满足，编排者都不能就此交付，而要做出新的决策——是补派某一个 Worker、是退回重做，还是发现问题根源在最初的拆解、需要重新规划。
正是在这个意义上，编排者不能把自己变成一个单纯的「传声筒」或「打包员」。它手里握着全局视角和所有子任务的结论，是唯一能判断整体是否成立的角色；如果它放弃判断、只是堆叠，那么矛盾和缺漏就会直接流到你面前。让整合成为一次主动的再决策，而不是被动的收尾，主从模式才能真正把分散的执行汇聚成可靠的成果，而不是把分散的问题也一起汇聚上来。
七点九、如何防止编排者「自作主张」
主从模式把拆活派活的权力交给了 Orchestrator，这份权力用好了高效，失控了则会让战线悄悄扩大。如何防止它自作主张、不断往方案外加活，是用好该模式必须把住的一关。
典型的失控往往不是一次明显的越界，而是一连串看似合理的小动作：它在执行中发现「顺手也可以把那个改了」，于是加派一个子任务；新子任务又牵出下一处，再派一个；等你回过神，原本一个边界清楚的任务已经膨胀成谁也审不动的庞然大物。每一步单看都有道理，合起来却彻底偏离了初衷。这类膨胀之所以危险，正因为它是渐进、温和地发生的。
对策的核心是把范围确认前置、把变更收口：让 Orchestrator 先给出拆解方案，经你确认后再派，确认范围之外的新派活，无论看起来多合理，都要先停下、向你说明并得到同意，而不是边做边加。你在顶层守住「这次只做这些」，编排者的能动性才会被引导在既定范围内发挥，而不是无限外溢。
七点十、什么时候一个 Worker 也不该派
讲完怎么管编排者，也要提醒一个反向边界：不是所有看似能拆的任务都值得派 Worker，在某些情形下，一个 Worker 都不该派，主 Agent 自己做才对。
如果某一小块活需要的判断高度依赖其他部分的即时状态——比如改一处逻辑，要同时看着登录、权限、缓存好几处如何联动——把它隔离给一个看不到这些联动的 Worker，它只能在信息不全下做假设，交回的东西往往需要主 Agent 大量返工。这类强耦合的「小块」看似独立，实则与整体血脉相连，并不适合隔离。
另一种情形是改动虽小却牵动公共契约：比如修改一个被很多模块依赖的公共函数签名，这种改动影响面广、需要全局核对，绝不能当成一块普通子任务随手派给 Worker 自行处理，否则它改了一处、却看不到连锁影响。派 Worker 的前提始终是「边界清晰、能独立交付」，一旦这两条不成立，哪怕任务被切成了小块，也应留在掌握全貌的主 Agent 手里。
七点十一、主从模式适合多大规模的任务
把模式理解清楚后，一个很实际的问题是：它到底适合多大规模的任务？太小不值得拆，太大又可能失控，把握这个规模区间，能帮你判断用不用、怎么用。
从下限看，任务至少要大到「拆成几块后，每块都还是一件有意义、能独立交付的事」。如果拆完每块只剩改一两行，那么拆活、派活、收结果的协调开销，已经超过了直接做的成本，主从模式不划算。从上限看，任务规模不应大到你无法理解和核对整体——如果拆出的子任务多到编排者和你都看不清全貌、整合只能走过场，那么不是该换更简单的做法，就是该把大目标再往上拆成几个更小的、各自独立的编排，而不是让一个主从结构无限膨胀。
主从模式最舒服的区间，是那种「一个人串行做明显吃力、但切成若干清晰子块后每块都可独立完成、整体也仍在可理解范围内」的中等偏大任务。让任务规模落在「拆得开、也看得懂」之间，主从模式的优势才发挥得最充分。 超出任一端，都应考虑调整——过小退回单 Agent，过大则分层拆成多次编排，这本身就是务实工程判断的一部分。
总结
Orchestrator-Worker 就是让一个主 Agent 专职拆活派活、若干子 Agent 隔离执行交回、再由主 Agent 整合校验的编排法；适合能切成独立子块的大任务，关键是把住编排者的范围并让工人产出能拼合。