第 4 课：编排者-工人：让分解本身动起来

学习目标：

• 说清编排者-工人的定义，以及它跟并行化的关键差异：拓扑上相似，但子任务不是预定义的，由编排者按具体输入决定
• 给每一份派工配齐四要素（目标、输出格式、工具与来源的使用指引、任务边界），并把「派几个、每个花多少」的配额规则写进提示词
• 读懂一个真实上线系统的完整账本：90.2% 的提升出现在什么条件下、15× 的账单为什么是同一个机制的另一半、同步执行卡在哪、异步要新扛哪三项代价

前置要求：读完第 1–3 课（本课接的是第 3 课末尾那个没答完的问题） | 上一课 第 3 课 << | 下一课 第 5 课 >>

第 3 课留下的那个洞

第 3 课你写了分段：把一个任务切成几块独立的子任务，同时跑，再用代码把结果聚起来。回头看那段代码，切法藏在哪儿？藏在你手写的那个数组里——SECTIONS = ['安全', '性能', '可读性']。三个分支是你在写代码的时候决定的，运行时只是照着执行。

这套做法能成立，前提很硬：你在写代码的时候就知道该切成哪几块。审代码这种任务确实知道，因为审查维度是稳定的，换一个仓库也还是这几条。

现在换一个任务：

「给这个代码库的性能问题做一次调查。」

要切成几块？切成哪几块？没法预先写死。也许瓶颈在数据库查询上，那该派人去翻 ORM 的调用点；也许在一个热路径的循环里，那该派人去读 profile；也许根本是构建产物太大，跟运行时无关。要改哪些文件、该查哪几个方向，得先看一眼这个具体的仓库、这个具体的问题描述，才知道。

也就是说：拆分本身得是运行时算出来的。你的代码不再持有「切成哪几块」这个决定，只持有「怎么派、怎么收、怎么合」这套机制。谁来做那个决定？一个 LLM。

这就是第四个模式。

定义，以及它和并行化差在哪

官方原典给的定义只有一句：在编排者-工人这个工作流里，一个中央 LLM 动态地分解任务、把子任务委派给 worker LLM、再合成它们的结果¹。

三个动作：分解、委派、合成。中间那个「委派」你在第 3 课已经写过了，扇出的代码几乎一样。真正新的是第一个动作——分解从代码里搬到了模型手里。

适用时机的原话说得更准：这个工作流适合那些你没法预测所需子任务的复杂任务；官方拿编码举了例——要改的文件数量、每个文件里改动的性质，很可能取决于任务本身¹。

然后是那句必须记住的对照。原文说：虽然它在拓扑上跟并行化相似，但关键差异在于灵活性——子任务不是预定义的，而是由编排者根据具体输入决定的¹。

原文用的词是 topographically similar——形状上相像。这个说法值得多停一秒。如果你把第 3 课的分段和这一课的编排者-工人画成图，你会画出几乎一样的形状：一个点扇出成三个点，三个点再收回一个点。形状骗人。区别不在图里，在那个决定是什么时候做出来的：

最后那一行是工程上最疼的地方。分段的时候，每个分支的提示词是你亲手写的，你可以反复打磨、可以针对每个维度塞例子。编排者-工人不行——派工提示词是编排者当场生成的，你能控制的只有它生成派工时遵循的规则。这一课后面两节讲的就是那套规则该写什么。

先把机制写出来一个骨架。下面这段是本课自己写的示意代码，一手材料里没有官方的编排脚本，别把它当成标准实现：

跟第 3 课的扇出代码逐行比一下，你会发现只多了第一步。多出来的这一步，把整个系统的可预测性换掉了——这也是后面那些账要一笔笔算清楚的原因。

一个真实上线的系统长这样

模式定义能背，不等于知道它上线之后是什么样子。这一课有个便宜可占：Anthropic 把他们 Research 功能的工程复盘公开写了出来，那就是一个跑在生产里的编排者-工人系统。这一节到后面几节，用的都是这份账本。

架构原话：他们的 Research 系统用的是多 Agent 架构下的编排者-工人模式，一个主代理（lead agent）协调整个流程，同时委派给并行操作的专门子代理²。

跑起来的样子：用户提交一个查询，主代理分析它、拟出一套策略、然后孵出子代理去同时探索不同的方面²。

注意「分析它、拟出策略」这半句——这正是上一节说的那个运行时决定。用户问什么，主代理就现算该派几路、每路查什么。

还有一句定义值得单独拎出来：一个多 Agent 系统由多个代理组成，这里的代理指的是「在循环里自主使用工具的 LLM」，它们协同工作²。

括号里那句话你应该觉得眼熟。worker 不是什么新东西，它就是你在本系列第 7 门课手写的那个 harness 循环。 编排者-工人没有引入新的执行单元，它引入的是「一个循环去启动另一批循环」这件事。你已经会写那个循环了，这一课教的是怎么把循环接起来。

同一份复盘里还提了扇出为什么有用：检索的本质是压缩——从庞大的语料里提炼洞见。子代理带着各自的上下文窗口并行工作，同时探索问题的不同侧面，再把最重要的 token 压缩后交给主研究代理；每个子代理还提供了关注点分离——不同的工具、不同的提示词、不同的探索轨迹——这减少了路径依赖，让每一路调查都能独立做透²。

「独立的上下文窗口」这一条你在第 3 课已经算过一遍账了。这里它换了个身份出场：不只是容量，还是隔离——三路调查互相看不见对方的中间过程，就不会被对方的错误方向带跑。

账本的正面：90.2% 与那 80%

这份复盘里最出名的数字，也是最容易被抄坏的数字。原话是：他们的内部评测显示，多 Agent 研究系统尤其擅长广度优先的查询——那种需要同时追多个独立方向的题；他们发现，以 Claude Opus 4 作主代理、Claude Sonnet 4 作子代理的多 Agent 系统，在他们的内部研究评测上比单代理的 Claude Opus 4 高出 90.2%²。

这个数字缺一个条件都不能引：

• 在他们的内部研究评测上——不是公开基准，你没法复现，也不知道它跟你的任务分布像不像。
• Opus 4 主代理 + Sonnet 4 子代理——是这一对组合的成绩。换个模型搭配，这个数字不承诺任何事。
• 尤其擅长广度优先的查询——那种要同时追多个独立方向的题。深度依赖型的任务（下一步必须等上一步的结论）不在这句话的射程里。

还有一条更要紧的纪律：这个数字是多 Agent 对单 Agent，不是「结构化编排对循环」。 它不能拿来论证「把控制流搬进代码比让模型自己跑一个循环强」——那是另一个命题，本课用到的所有一手材料里都没有比过。这一课后面还会反复用到「谁持有计划」这根轴，但那根轴上没有任何一手基准数据，只有工程权衡。

多 Agent 为什么普遍有效？复盘给了一个不那么浪漫的解释——注意它的支撑分析做在另一个评测上，不是出 90.2% 的那一个：多 Agent 系统之所以有效，主要是因为它们帮你花掉了足够多的 token 来解决问题；在他们对 BrowseComp 评测（考的是浏览型代理找到难找信息的能力）的分析里，三个因素解释了 95% 的性能方差，其中 token 用量本身就解释了 80%，另外两个解释因素是工具调用次数和模型选择²。他们说，这个发现验证了他们的架构选择——把工作分散到拥有各自独立上下文窗口的代理上，以增加并行推理的容量²。

95% 和 80% 这两个数只在 BrowseComp 那段分析里成立，别把它们搬到别处去当通用结论。

但这个机制解释有个很实际的用处：如果你的任务不需要花那么多 token 就能解决，编排者-工人的收益基础就不在了。 （这是从机制陈述推出来的工程判断，不是 95%/80% 那两个数字的直接推论。）一个查一次文档就能答的问题，派三个 worker 出去不会让它变得更对，只会让它变贵。

账本的背面：4× 和 15×

这两个数字第 1 课亮过，这里把原话摆全。同一段复盘紧接着说：有个坏处——这类架构在实践中烧 token 烧得很快；在他们的数据里，代理消耗的 token 大约是聊天交互的 4 倍，而多 Agent 系统大约是聊天的 15 倍；要在经济上成立，多 Agent 系统需要那种任务价值高到足以支付这份性能提升的场景²。

把这两节的数字并排放：一边是 90.2%（特定条件下），一边是 15×。上一节说清楚了，性能提升主要就是 token 花出来的，那么账单变高不是副作用，是同一个机制的另一半。

「任务价值要配得上」这句话该怎么落地？它其实是在让你先回答一个业务问题再回答技术问题：这次调查如果做对了，值多少钱？如果答案是「省了工程师半小时」，那 15× 的账单大概率不划算；如果答案是「避免一次线上事故」，那就另说。

复盘还划了一条更硬的边界：有些领域今天不适合多 Agent 系统——那些要求所有代理共享同一份上下文的、或者代理之间存在大量依赖的场景；举例来说，大多数编码任务里真正可并行的部分比研究少，而且 LLM 代理目前还不太擅长实时协调和向其他代理委派²。反过来，他们发现多 Agent 系统擅长的是那些有价值的、涉及大量并行化、信息量超出单个上下文窗口、需要跟大量复杂工具打交道的任务²。

这里有两句话要放在一起读，否则会读拧：官方原典拿编码举例说明「所需子任务无法预知」¹，而多 Agent 复盘说大多数编码任务里真正可并行的部分比研究少²。它们不矛盾，说的是两件事——前一句说的是拆分得动态算，后一句说的是算出来的子任务未必能同时跑。动态分解不等于必然并行。一个编排者完全可以动态算出五个子任务，然后串着跑其中三个、并着跑另外两个。

派工提示词的四要素

这是本课最该记住的一条工程纪律，原话很短：

教会编排者怎么委派。在他们的系统里，主代理把查询分解成子任务并把它们描述给子代理。每个子代理需要一个目标、一个输出格式、关于使用哪些工具和来源的指引、以及清晰的任务边界。 没有详细的任务描述，代理会重复劳动、留下空缺、或者找不到必要的信息²。

四要素，一个都不能省：

目标——这个 worker 要产出什么结论。不是「调查性能」，是「找出运行时 CPU 占用最高的 3 个热点」。目标要窄到能判断做没做到。

输出格式——交回来的东西长什么样。字段、条数上限、排序规则。这一项直接决定编排者的合成阶段好不好写：如果三个 worker 交回三段散文，合成就只能靠模型再读一遍；如果交回的是同一个 schema 的 JSON，合成有一半可以用代码做。

工具与来源的使用指引——允许它用哪些工具、去哪些地方找。这一项同时是成本控制和防跑偏：不给它联网工具，它就不会跑去搜一个不存在的东西。

任务边界——明确它不该做什么。这一项最容易漏，也最直接决定 worker 之间会不会撞车。「不看 src/server/，那是另一个 worker 的地盘」这样一句，比任何事后去重都管用。

复盘里给的翻车现场几乎是教科书式的：有一次，一个子代理去探索 2021 年的汽车芯片危机，同时另外两个子代理重复地调查 2025 年的当前供应链，整批任务没有形成有效的分工²。

三个 worker，两个重复、一个跑到不相干的年代——这正是「重复劳动、留下空缺」那句话的具体样子。

跟你已经学过的东西搭个桥：本系列第 6 门课讲多 Agent 协作时，已经把这四项拆开讲过一遍（它的叫法是目标、范围、信息来源、输出格式），第 2 课也点过名。 这一课做那两处没做的事：把四要素放回编排者当场生成派工的位置——你控制的不再是每份派工的内容，而是编排者生成它们时要遵守的规则。四要素照样可以当 checklist 用——你现在可以拿它当 checklist 用：写完一份派工，逐个数一遍这四项在不在。

按复杂度配额：把投入规则写进提示词

四要素解决「每个 worker 干什么」，还剩一个问题：派几个、每个花多少。

这组数字在本系列第 6 门课开篇亮过一次，这里换个用法——不是拿它判断要不要上多 Agent，是把它写进编排者的提示词、让它自己配额。复盘对这个问题的诊断很直白：代理不擅长判断不同任务应该投入多少，所以他们把伸缩规则嵌进了提示词里——简单的事实查证只需要 1 个代理、3 到 10 次工具调用；直接的对比可能需要 2 到 4 个子代理、每个 10 到 15 次调用；复杂的研究可能会用到 10 个以上的子代理并明确划分职责²。

关于这组数字，有一条引用纪律要守住：它们的身份是「他们嵌进自己提示词里的规则」，不是行业标准，也不是你该照抄的刻度。 你的任务分布、工具速度、模型都跟他们不一样。真正可迁移的是那个做法本身——把投入规则显式写进编排者的提示词，而不是指望编排者自己拿捏分寸。

不写会怎样？复盘也给了现场：多 Agent 系统跟单 Agent 系统有几个关键差异，其中一个是协调复杂度的快速增长；他们早期的代理犯过这些错——为简单查询孵出 50 个子代理、为不存在的来源无休止地扫网、用过量的更新互相干扰²。

「为简单查询孵出 50 个子代理」这一条，用上一节的账本换算一下就明白了：按他们的数据，多 Agent 大约是聊天的 15 倍 token²，那这类失控的扇出会把这个乘数再抬上去一大截。配额规则不是抠门，是让成本跟任务价值保持在同一个数量级上的手段。

这条规则该怎么写进你自己的编排者提示词？照着他们的形状，把你自己的刻度填进去：先给任务分几档，每档规定子代理数量上限和每个子代理的工具调用上限，再补一句「超过上限就交回当前已有的发现，不要继续」。这句话能降低失控的概率，但它仍然只是提示词——对非确定性的模型，写在提示词里的上限永远只是个建议。真正的闸门在代码侧：骨架里那个 pool 的 LIMIT。提示词层管「模型自觉」，代码层管「兜底」，两层都要有。

同步的瓶颈，和异步的价钱

这一节讲的是这套架构今天还没解决的问题。原话分两段。

第一段说现状：同步执行会造成瓶颈。目前他们的主代理是同步执行子代理的，等每一批子代理全部完成之后才继续。这简化了协调，但在代理之间的信息流上造成了瓶颈——举例来说，主代理没法中途给子代理改方向、子代理之间没法互相协调、而且整个系统可能被卡住，只因为在等某一个子代理搜完²。

三个「做不到」，逐条对应三种真实损失：

• 主代理没法中途改派——第 2 分钟它就能看出 worker C 的方向不对，但它得等到这一批结束才能做任何事。
• 子代理之间没法协调——worker A 已经查到的东西，worker B 不知道，可能正在重查一遍。
• 整批被最慢的一个阻塞——两个 3 分钟完成的 worker，会陪着一个 25 分钟才超时的 worker 一起等到 25 分钟。

第二段说另一条路的价钱：异步执行会带来额外的并行——代理并发地工作、在需要时创建新的子代理。但这种异步性在结果协调、状态一致性、以及跨子代理的错误传播上增加了难度²。

请注意这句话的语气：一手材料是把这三项列为难题，不是给出了解法。所以这一课也不会给你一套「官方推荐的异步编排方案」——没有那个东西。你要是自己上异步，这三项就是你自己要扛的：

• 结果协调：worker 陆续回来，「什么时候算齐了、可以开始合成」这个判断得你来定义。
• 状态一致性：主代理中途改了调查范围，正在跑的 worker 用的还是旧范围，两边的前提就分叉了。
• 错误传播：一个 worker 失败了，而它的中途产出已经被用来派出了新的 worker，那条链上谁该重跑、谁的结果作废，需要显式规则。

本课的练习 Level 2 会让你在一条具体的时间线上把这三项各举一个实例。

涌现行为，和最后一公里

还有几条来自同一份复盘的工程经验，都不长，但每条都值一次线上事故。

多 Agent 系统有涌现行为，它们不来自任何专门的编程；举例来说，对主代理的小改动会以不可预测的方式改变子代理的行为；要做成这件事，需要理解交互模式，而不只是单个代理的行为²。同一份复盘还补了一句更狠的：在传统软件里一个 bug 可能弄坏一个功能、拖慢性能或者引发宕机，而在代理系统里，微小的改动会级联成巨大的行为变化，这让「为必须在长时间运行中维持状态的复杂代理写代码」变得异常困难²。

对你的日常影响是：改了编排者的提示词，就得重跑整套评测，不能只看编排者自己的输出。本系列第 10 门课那条评测跑道在这里派上用场——它是你唯一能看见「小改动有没有把子代理带歪」的仪器。

最后一公里往往是大半程：在构建 AI 代理时，最后一公里常常成了整段旅程的大部分；在开发机上能跑的代码库，需要大量工程投入才能变成可靠的生产系统；代理系统里错误的复合性质，意味着传统软件里的小毛病足以让代理彻底跑偏²。

配套的两个做法：他们把基于 Claude 的 AI 代理的适应力，与重试逻辑、定期检查点这类确定性护栏结合起来²；发布时用彩虹部署避免打断正在运行的代理——把流量从旧版本逐步切到新版本，同时让两个版本一起跑着²。

彩虹部署这条，回扣的是本系列第 9 门课开篇拿部署更新当崩溃场景时提过的问题：普通 Web 服务重启，用户重试一次就行；一个跑了 20 分钟的代理被重启打断，丢的是 20 分钟的工作和已经花掉的 token。长任务的部署跟无状态服务的部署不是一回事。

分寸：这是五个模式里最贵的一个

到这里，五个模式你已经见过四个。按成本排，编排者-工人是目前为止最贵的：它在并行化的开销之上，又加了一次「让模型现算拆分」的调用，以及那份「拆分可能算错」的风险。

所以在动手之前，按顺序问三个问题：

第一，拆分能不能预先写死？ 如果能，回第 3 课用分段。分段的每个分支提示词是你亲手打磨的，编排者-工人的派工是模型当场生成的——前者的质量上限更高，也更好调试。能预定义就别动态。

第二，这个任务值那么多钱吗？ 按他们的数据，多 Agent 大约是聊天的 15 倍 token²，而且要在经济上成立，需要任务价值高到足以支付这份提升²。这是个业务判断，不是技术判断，但它得在写代码之前做。

第三，不确定的话，先量。 官方原典对整套模式的收尾态度是：这些构件不是规定动作，成功的关键在于测量性能并迭代实现，只有在复杂度能被证明改善了结果时才增加它¹。本系列第 10 门课给了你那条跑道——先用单个循环跑一遍你的真实任务集，拿到一条基线，再判断编排者-工人有没有把它抬起来。没有基线的时候，「感觉更好了」和「花了 15 倍的钱得到同样的结果」在你眼里长得一模一样。

本课到此为止只讲了「派出去、收回来」。派回来的东西质量不行怎么办、要不要让另一个代理去审它、以及怎么把这四个模式拼起来——那是第 5 课的内容。

💻 练习

小结

• 编排者-工人是一个中央 LLM 动态分解任务、委派给 worker LLM、再合成结果的工作流；它适合那些你没法预测所需子任务的复杂任务¹
• 它跟并行化在拓扑上相似，关键差异是灵活性：子任务不是预定义的，而是由编排者根据具体输入决定的¹——形状一样，决定的时机不一样
• worker 不是新东西：多 Agent 系统就是多个「在循环里自主使用工具的 LLM」协同工作，一个主代理协调流程、委派给并行操作的专门子代理²
• 那个 90.2% 只在它的完整语境里成立：他们的内部研究评测、Claude Opus 4 主代理搭 Claude Sonnet 4 子代理、尤其擅长广度优先的查询²；机制解释是多 Agent 主要帮你花掉了足够多的 token——BrowseComp 的分析里三因素解释 95% 方差，token 用量独占 80%²
• 账单是同一本账的背面：按他们的数据，代理约为聊天的 4 倍 token、多 Agent 约为 15 倍，要在经济上成立，任务价值得高到支付得起²
• 每个子代理需要一个目标、一个输出格式、关于工具与来源的使用指引、以及清晰的任务边界；缺了详细任务描述，代理会重复劳动、留下空缺、找不到必要信息²——本系列第 6 门课那条「派活提示词自包含」，展开就是这四项
• 代理不擅长判断该投入多少，所以把配额规则写进提示词：他们的刻度是简单事实查证 1 个代理 3-10 次调用、直接对比 2-4 个子代理各 10-15 次、复杂研究 10 个以上子代理明确分工²；不写规则的后果他们也见过——为简单查询孵出 50 个子代理、为不存在的来源无休止扫网、用过量更新互相干扰²
• 同步执行简化了协调，但卡住信息流：主代理不能中途改派、子代理之间不能协调、整个系统会被一个子代理阻塞²；异步能换来更多并行，代价是结果协调、状态一致性、跨子代理的错误传播——这三项在一手材料里是难题，不是已有解法²
• 多 Agent 系统有涌现行为，对主代理的小改动会不可预测地改变子代理行为，要理解的是交互模式而不只是单个代理²；最后一公里往往是大半程，开发机上能跑的代码要靠大量工程才能变成可靠的生产系统²，配套手段是确定性护栏（重试逻辑、定期检查点）²与彩虹部署——逐步切流量、两个版本并跑，避免打断正在运行的代理²
• 这是目前学过的四个模式里最贵的一个：动手前先确认拆分真的没法预定义（能预定义就回第 3 课的分段），再确认任务价值撑得住 15×，拿不准就先用本系列第 10 门课那条跑道量一条基线——只在复杂度能被证明改善了结果时才加它¹

>> 第 5 课：评审回路，以及把模式组合成图

Footnotes

1. Building Effective AI Agents — Anthropic Engineering — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

2. How we built our multi-agent research system — Anthropic Engineering — https://www.anthropic.com/engineering/multi-agent-research-system ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³ ↩²⁴ ↩²⁵ ↩²⁶ ↩²⁷ ↩²⁸ ↩²⁹ ↩³⁰ ↩³¹ ↩³² ↩³³ ↩³⁴ ↩³⁵ ↩³⁶ ↩³⁷ ↩³⁸