地图:七组里的 19 个概念

一张地铁图:先看整条线路,再一站一站地坐。

这门课分七组。第一,为什么要拆——为什么要把工作分给多个智能体,以及你为此付出什么。然后是系统里的三种角色:负责拆分和汇总的 orchestrator、做窄任务的 worker,以及它们之间的 handoff。接着是把智能体接起来的三种形态、multi-agent 会成倍放大的三种故障模式,最后是实践:什么时候该拆,什么时候不该拆。

如何阅读每个概念

一本护照:每个人的栏目都相同,所以容易比较。

从这里开始,每个概念都有同样的几部分:它的英文名(记住它——文档和论文就这么叫)、一幅生活中的画面、一张图,以及一张带有问题、思路、例子、代价和关联等栏目的卡片。这门课的核心想法:更多的智能体既成倍放大能力,也成倍放大出错的方式——所以只有当一个智能体真的不够用时,才拆。

Specialization——什么都做的一个智能体,什么都做不好

一个人被要求同时当建筑师、水管工、电工和检查员,对比一支小队,每个专家把一件事做好。

这就是 Specialization(专门化)的概念。单个智能体的职责太宽——所有工具、各种任务、一个巨大的 prompt——每一步都有太多出错的方式。活越大,它的可靠性就越低。

把工作拆给专门的智能体,每个只负责一件窄任务,能让整个系统更强、更可靠——就像一队专家胜过一个疲于奔命的多面手。专门化是 multi-agent 存在的核心理由。

Context & Tool Overload——上下文和工具让单个智能体不堪重负

一张桌子堆满了十种不同工作的所有文件和所有工具——工作的人花在整理杂物上的力气,比干活还多。

有两个具体的限制把你推向单个智能体之外——这就是 Context & Tool Overload。第一:一个智能体的上下文窗口被任务各个部分的所有内容塞满,而塞得过满的上下文会拉低质量(上下文工程的问题)。第二:拿着所有工具的单个智能体,每一轮都得从一份巨大的菜单里选——菜单越长,选得越差。

拆开之后,每个智能体只带它那份窄任务所需的上下文和工具——干净、专注、可靠。

Coordination Cost——专门化是收益,协调是代价

接力队比一个人跑四棒更快——但前提是交接棒练习过;接力棒一掉,比赛就输了。

multi-agent 的收益是专门化:窄的智能体各自把一件事做好。代价是 Coordination Cost(协调成本):现在得有东西来拆分工作、路由、在智能体之间传递上下文,并汇总结果。而这种协调本身就是复杂性和故障的来源。

整套功夫就是:拿到专门化的收益,同时不让协调成本把它吃掉。当收益盖不过成本时,一个智能体才是正确答案。

Orchestrator——分派工作的协调者

工地上的总承包商:他们不砌砖,也不接配电箱——他们把项目拆成一项项工作,分派给合适的专业人员。

这就是 Orchestrator 模式(也叫协调者)。它是负责统筹的智能体:接过整体目标,拆成子任务(分解),再把每个子任务路由给合适的专门智能体。它自己不做专门的活;它的工作是分解和指挥。

这呼应了智能体课程里的 plan-and-execute 思路,只是规模更大——一个有能力的智能体负责规划和委派,专注的 worker 负责完成各个部分。

Assembly——orchestrator 合并各 worker 的结果

编辑向不同的作者约稿,再把各部分合成一篇连贯的文章——稿子交回来,得有人把它们变成一个整体。

orchestrator 的第二项工作是 Assembly(汇总,也叫综合):收集各个 worker agent 返回的内容,合并成一个连贯的最终结果。研究类 orchestrator 可能把子话题发给几个智能体,再把它们的发现综合成一个答案。

这个收集合并的步骤,是各条独立的工作流变成一个输出的地方——做好它(化解冲突、去掉重复)和拆分一样重要。

Coordination Layer——协调层才是真正的架构

管弦乐队不是一堆出色的独奏者——而是指挥和乐谱在决定谁在何时演奏。协调就是音乐。

在 multi-agent 系统里,价值和难点都转移到了 Coordination Layer(协调层):谁在何时运行、用什么输入、结果如何合并。大家的注意力在各个智能体上,但系统能不能工作,取决于围绕它们的编排——路由、上下文传递、错误处理。

和单个智能体一样,模型是容易的部分;可靠性是赢在还是输在它周围的结构上。

Worker Agent——每个 worker 只有一项明确的工作

一间厨房,每项工作一个工位——一个人管酱汁,一个管烤架,一个管摆盘——每人精通自己那个窄角色,而不是样样手忙脚乱。

Worker Agent 是一个专门的智能体,有一项窄而明确的工作:搜文档、写代码、核查事实、排版输出。因为它的职责小,所以它的 prompt 专注,工具很少,行为可预测。

orchestrator 交给它一个明确的子任务,它做这一件事,然后返回结果。窄的 worker 是积木——每块都简单到能做对、能信任。

Per-agent Evals——窄的智能体更容易测试、更值得信任

你可以彻底检查一位专家的工作,因为他的活小而明确——比审查一个什么都沾点边的多面手容易得多。

窄的智能体比庞杂的智能体容易评估、调试和信任得多。有了一项明确的工作,你就能给它写 evals——这就是 Per-agent Evals 的做法,给每个智能体单独做测试。你能准确看到它在哪里失败,并单独修好它——和智能体课程里同样的可靠性论证,只是用在每一块上。

multi-agent 系统只有在每个 worker 单独都可靠时才可靠,而当每个只做一件范围明确的事时,这容易得多。

Depth over Breadth——在一项工作上的深度胜过在多项工作上的广度

一个外科医生只做一种手术,做上几千次,胜过偶尔做一次的多面手——专注带来的可靠性,广度给不了。

贯穿这一切的原则是 Depth over Breadth(深度胜过广度):一个反复做一件事的专注智能体,比偶尔做很多事的宽泛智能体更可靠。这就是为什么要分解——不是为了多出一些智能体,而是为了让每个都窄到真正擅长自己那一块。

如果某个 worker 的工作仍然宽到不可靠,答案通常是再拆细,而不是给它堆更多工具。

Handoff——在智能体之间传递工作

接力跑者交接棒:交接本身就是一门技术,赢得比赛的是一次干净的交接,而不只是跑得快的选手。

Handoff(交接)是一个智能体把工作交给另一个的那一刻——orchestrator 交给 worker,或者一个智能体直接交给下一个。传递的是子任务和完成它所需的上下文。

handoff 是很多 multi-agent 故障发生的地方:如果接收方没拿到它需要的东西,或者拿到的是一个含糊的版本,不管这个智能体多好,它的输出都会是错的。交接是设计中的一等公民,不是细节。

Clean Handoff——传干净、有结构的上下文,而不是全部

一次好的交底,只给下一个人完成任务所需的东西——而不是把之前每场对话的完整记录丢给他去翻。

诱惑在于把到目前为止的全部历史都传给每个智能体,但这会在每个智能体内部重现上下文塞得过满的问题。更好的做法是 Clean Handoff(干净交接):给接收方一份专注、有结构的摘要,只含它需要的东西——相关事实和具体任务——而不是原始的信息洪流。

这让每个智能体的上下文保持紧凑、专注,而这正是当初拆分之所以值得的原因。

Context Isolation——每个智能体有自己干净的上下文

分开的工作间,每间只有那个房间的工作所需的材料——这样没人会被其他所有任务的杂物分心或搞糊涂。

multi-agent 的一个实在好处是 Context Isolation(上下文隔离):每个智能体在自己干净的上下文里工作,只看到它的工作所需的东西,而不是整个系统积累下来的一团乱。这也是拆分能提高可靠性的原因之一——它避免了单个长时间运行的智能体里逐渐积累的 context rot(上下文腐烂)。

但只有 handoff 做得规范,你才能得到这个好处;要是把一切都传给所有人,你就是在用额外的步骤重建那个单个过载智能体的问题。

Sequential——分阶段的流水线

一条装配线:每个工位做自己的那部分,按固定顺序把产品传给下一个,直到最后成品下线。

Sequential(顺序)模式把智能体按固定顺序串起来:智能体 A 的输出喂给智能体 B,B 的输出再喂给智能体 C。先是起草智能体,再是编辑智能体,再是事实核查智能体。

它是最简单的 multi-agent 形态,也最可预测,适合工作有必须按顺序发生的自然阶段的情形。它本质上是一条专家流水线——当步骤固定时,它比每次都重新决定顺序的循环更可靠。

Parallel——扇出再汇集

把同一个调研问题同时发给几位助手,再把他们的发现收到一起——许多人同时工作,最后合并结果。

Parallel(并行)模式让多个智能体同时处理相互独立的部分,然后汇集它们的结果——先 fan-out(扇出),再 gather(汇集)。调研五个子话题、处理很多条目、获取几个独立的视角:这些并行做都比一个接一个更快。

orchestrator 拆分工作,worker 同时运行,结果再合并。当各部分互不依赖且速度重要时,parallel 最能发挥作用。

Hierarchical——orchestrator 的 orchestrator

公司的组织架构图:经理指挥组长,组长各自指挥自己的员工——协调分层嵌套,用于一层装不下的大工作。

Hierarchical(层级)模式把协调嵌套起来:顶层 orchestrator 把活委派给子 orchestrator,各自管理自己的 worker。这样靠一层层分解,来处理真正庞大复杂的任务,就像一个组织那样。

它是最强大的形态,也是最复杂的——更多协调,更多出错的地方——所以只有当任务大到确实需要嵌套分解时才用它。大多数系统用 sequential 或 parallel 就够了;层级是留给少数不够用的情形。

Compounding Error——步骤越多,误差累积越多

更长的接力有更多次交接,就有更多机会掉棒——每多一次交换,就多一个让整场跑失败的地方。

这就是 Compounding Error(误差累积)的概念。单个智能体在一条长链上本来就只有一部分时候能成功(智能体课程里的可靠性问题),而 multi-agent 让链更长:更多智能体、更多 handoff、更多步骤,每一步都可能失败,并把错误传给下游。

可靠性沿链条相乘,所以增加智能体可能降低整体成功率,除非每一块和每次 handoff 都扎实。更多的智能体意味着更多误差累积的面,而不是自动意味着更多能力。

Coordination Overhead——协调有它自己的开销和成本

为协调五个团队开的一场会,可能比活本身还贵——过了某个点,协调比干活更费劲。

这就是 Coordination Overhead(协调开销)。每个智能体都有自己的模型调用、自己的延迟、自己的成本——而编排又在上面再加一层:路由、handoff、汇总、重试。同一个任务,multi-agent 系统可能比单个智能体慢得多、贵得多,有时还没有更好。

如果专门化的收益没有明显盖过这些额外的成本和延迟,那么更简单的单个智能体才是更好的工程选择。

Multi-agent Tracing——更难追踪和调试

追踪一个包裹很容易;在一张由仓库、卡车和交接构成的网里追查故障,是另一回事,难得多。

multi-agent 系统出了问题,要找到在哪里,比单个智能体难得多:故障可能在任何一个 worker、任何一次 handoff,或编排本身。所以可观测性变得必不可少——这就是 Multi-agent Tracing 的做法:跨智能体追踪一个请求,并记录每一次 handoff。

这种调试成本是代价的真实组成部分。一个你无法追踪的系统,就是一个你无法可靠修复的系统,而 multi-agent 确实让追踪更难。

Single Agent by Default——只有当一个智能体真的应付不了时才拆

回答一个简单的问题,你不会组一个委员会——只有当活确实大到一个能干的人干不了时,你才请来一个团队。

这就是 Single Agent by Default(默认单个智能体)的原则。默认应该是单个智能体,只有当一个确实应付不了这项工作时——不同的技能太多、工具太多、上下文多到无法连贯地装下——你才去用 multi-agent。如果一个构建良好的单个智能体能做到,multi-agent 版本只是白白增加成本、延迟和故障模式。

问题从来不是"我能拆吗?"——几乎任何东西都能拆——而是"一个智能体在这里真的不够吗?"

让每个智能体保持窄,每次 handoff 保持干净

一支管理良好的队伍有明确界定的角色和练习过的交接——让它可靠的是结构,而不是英雄式的拼搏。

当你确实要上 multi-agent 时,让它奏效的两条纪律是:让每个 worker 保持窄(一项明确的工作、很少的工具、能单独测试),让每次 handoff 保持干净(只含所需内容的专注摘要,而不是全部历史)。大多数 multi-agent 故障都能追到某个太宽的 worker 或某次太含糊的 handoff。把这两点做对,再配上明确的 orchestrator 和最简单的适用模式,系统在扩大规模时仍能保持可靠。

这一切如何串起来

完整的地铁图:现在你能看到各条线在哪里交汇。

你从一个智能体开始。如果它应付不了,orchestrator 就出现了:它挑一种模式(sequential、parallel 或 hierarchical),通过干净的 handoff 把活交给窄的 worker,然后汇总结果。每个智能体和每次 handoff 都会增加开销和累积误差——如果收益小于成本,就退回一个智能体。而追踪能准确显示哪里出了问题。