# 当一个智能体不够用时 关于 multi-agent 系统的速成课——什么时候该把工作拆给由 orchestrator 协调的多个专门智能体,什么时候这样做还不如一个智能体。19 个概念——Specialization、Orchestrator、Worker Agent、Handoff、Context Isolation、Sequential、Parallel、Hierarchical、Compounding Error、Coordination Overhead 等——每个都有英文名、一张图、一张卡片和一个例子。最后附一页速查表,汇总所有概念。 - **Author:** Fedor Chishchin - **Level:** intermediate - **Reading time:** ~35 分钟阅读 - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/zh/learn/multi-agent-express --- ## 1. 为什么要拆成多个 在把智能体接到一起之前,先理解它要解决的问题。Multi-agent 系统的存在有一个具体的理由——没有那个理由就伸手去用,正是它出错的方式。 ### 地图:七组里的 19 个概念 > 一张地铁图:先看整条线路,再一站一站地坐。 这门课分七组。第一,**为什么要拆**——为什么要把工作分给多个智能体,以及你为此付出什么。然后是系统里的三种角色:负责拆分和汇总的 **orchestrator**、做窄任务的 **worker**,以及它们之间的 **handoff**。接着是把智能体接起来的三种**形态**、multi-agent 会成倍放大的三种**故障模式**,最后是**实践**:什么时候该拆,什么时候不该拆。 _Diagram: 七组概念——第 1–7 章依次讲它们。_ ### 如何阅读每个概念 > 一本护照:每个人的栏目都相同,所以容易比较。 从这里开始,每个概念都有同样的几部分:它的**英文名**(记住它——文档和论文就这么叫)、一幅生活中的画面、一张**图**,以及一张带有*问题*、_思路_、_例子_、*代价*和*关联*等栏目的**卡片**。这门课的核心想法:**更多的智能体既成倍放大能力,也成倍放大出错的方式**——所以只有当一个智能体真的不够用时,才拆。 ### Specialization——什么都做的一个智能体,什么都做不好 > 一个人被要求同时当建筑师、水管工、电工和检查员,对比一支小队,每个专家把一件事做好。 这就是 **Specialization**(专门化)的概念。单个智能体的职责太宽——所有工具、各种任务、一个巨大的 prompt——每一步都有太多出错的方式。活越大,它的可靠性就越低。 把工作拆给**专门的智能体**,每个只负责一件窄任务,能让整个系统更强、更可靠——就像一队专家胜过一个疲于奔命的多面手。专门化是 multi-agent 存在的核心理由。 _Diagram: 左:一个智能体包办所有活——到处都可能出错。右:一支小队,每个只做一件事。_ #### Specialization (专门的智能体) - **问题:** 职责宽泛的一个智能体——所有工具、一个巨大的 prompt——经常出错。 - **思路:** 把工作拆成窄的智能体,每个把一件事做好。 - **例子:** 不用一个"什么都做的智能体",而是一个研究员、一个程序员、一个事实核查员和一个排版员。 - **代价:** 现在需要**协调**——得有东西来拆分工作并汇总。 - **关联:** 使用 **Orchestrator** 和 **Worker Agent** 的理由;代价是 **Coordination Cost**。 ### Context & Tool Overload——上下文和工具让单个智能体不堪重负 > 一张桌子堆满了十种不同工作的所有文件和所有工具——工作的人花在整理杂物上的力气,比干活还多。 有两个具体的限制把你推向单个智能体之外——这就是 **Context & Tool Overload**。第一:一个智能体的**上下文窗口**被任务各个部分的所有内容塞满,而塞得过满的上下文会拉低质量(上下文工程的问题)。第二:拿着*所有*工具的单个智能体,每一轮都得从一份巨大的菜单里选——菜单越长,选得越差。 拆开之后,每个智能体只带它那份窄任务所需的上下文和工具——干净、专注、可靠。 _Diagram: 一个智能体:窗口里塞满一切,还有十二个工具的菜单。拆开后,每个都是小窗口加三个工具。_ #### Context & Tool Overload (上下文太多、工具太多) - **是什么:** 单个智能体的两个限制:上下文窗口塞得过满,工具菜单过长。 - **为什么重要:** 塞满的上下文会拉低质量,过长的菜单让每一轮的工具选择都更差。 - **例子:** 一个客服智能体的窗口里放着账单、技术文档和全部历史记录,外加二十个工具。 - **坑:** 先试着收窄这一个智能体的工具、清理它的上下文——有时这就够了。 - **关联:** 用 **Context Isolation** 和窄的 **Worker Agents** 来解决。 ### Coordination Cost——专门化是收益,协调是代价 > 接力队比一个人跑四棒更快——但前提是交接棒练习过;接力棒一掉,比赛就输了。 multi-agent 的收益是专门化:窄的智能体各自把一件事做好。代价是 **Coordination Cost**(协调成本):现在得有东西来拆分工作、路由、在智能体之间传递上下文,并汇总结果。而这种协调本身就是复杂性和故障的来源。 整套功夫就是:拿到专门化的收益,同时不让协调成本把它吃掉。当收益盖不过成本时,一个智能体才是正确答案。 _Diagram: 一杆秤:只有当专门化的收益大于协调成本时,multi-agent 才划算。_ #### Coordination Cost (协调的代价) - **是什么:** 让智能体一起工作所需的一切:拆分、路由、传递、汇总。 - **为什么重要:** 协调本身就是复杂性和故障的来源。 - **例子:** 只有交接棒练习过,接力才能胜过一个人跑。 - **坑:** 如果它盖过了收益,multi-agent 让系统变差,而不是变好。 - **关联:** 具体体现为 **Coordination Overhead** 和 **Compounding Error**。 > **框定问题:** "这件事对一个智能体来说是不是真的太多了——工具、技能或上下文太多——以至于专门化带来的好处,比它付出的协调代价更大?" > 什么都做的一个智能体什么都做不好——上下文太多,工具太多。多个专门的智能体可以更强,但代价是协调,而协调必须值得这份收益。 ## 2. orchestrator 模式 multi-agent 系统最常见的形态,中心有一个协调者。理解了 orchestrator,就理解了这类系统大半的接法。 ### Orchestrator——分派工作的协调者 > 工地上的总承包商:他们不砌砖,也不接配电箱——他们把项目拆成一项项工作,分派给合适的专业人员。 这就是 **Orchestrator** 模式(也叫协调者)。它是负责统筹的智能体:接过整体目标,**拆成子任务**(分解),再把每个子任务**路由**给合适的专门智能体。它自己不做专门的活;它的工作是分解和指挥。 这呼应了智能体课程里的 **plan-and-execute** 思路,只是规模更大——一个有能力的智能体负责规划和委派,专注的 worker 负责完成各个部分。 _Diagram: orchestrator 把目标拆成子任务,把每个交给对应的 worker。它自己不做专家们的活。_ #### Orchestrator (协调者、orchestrator–worker) - **问题:** 需要不同技能的大目标,不能直接丢给一个窄的智能体。 - **思路:** 一个主智能体把目标拆成子任务,并把每个路由给合适的 worker。 - **例子:** 研究类 orchestrator 把子话题分给几个研究智能体。 - **代价:** 多一个智能体,多一层可能出问题的地方。 - **何时使用:** 工作确实能拆成需要不同技能或工具的几块。 - **关联:** 放大版的 **Plan-and-execute**;通过 **Handoffs** 指挥 **Worker Agents**;通过 **Assembly** 合并结果。 ### Assembly——orchestrator 合并各 worker 的结果 > 编辑向不同的作者约稿,再把各部分合成一篇连贯的文章——稿子交回来,得有人把它们变成一个整体。 orchestrator 的第二项工作是 **Assembly**(汇总,也叫综合):收集各个 worker agent 返回的内容,合并成一个连贯的最终结果。研究类 orchestrator 可能把子话题发给几个智能体,再把它们的发现综合成一个答案。 这个收集合并的步骤,是各条独立的工作流变成一个输出的地方——做好它(**化解冲突、去掉重复**)和拆分一样重要。 _Diagram: 三个 worker 的发现汇到 orchestrator:它化解冲突、去掉重复,给出一个答案。_ #### Assembly (综合、合并结果) - **是什么:** orchestrator 把各 worker 的输出变成一个结果的步骤。 - **为什么重要:** 没有好的汇总,你得到的不是答案,而是一堆互相矛盾的碎片。 - **例子:** 三个智能体研究了三个子话题;orchestrator 写出一份没有重复的报告。 - **坑:** 汇总常被当成细节——但冲突和重复恰恰在这里冒出来。 - **关联:** **Orchestrator** 的后半部分;**Parallel** 的最后一步。 ### Coordination Layer——协调层才是真正的架构 > 管弦乐队不是一堆出色的独奏者——而是指挥和乐谱在决定谁在何时演奏。协调就是音乐。 在 multi-agent 系统里,价值和难点都转移到了 **Coordination Layer**(协调层):谁在何时运行、用什么输入、结果如何合并。大家的注意力在各个智能体上,但系统能不能工作,取决于围绕它们的编排——**路由、上下文传递、错误处理**。 和单个智能体一样,模型是容易的部分;可靠性是赢在还是输在它周围的结构上。 _Diagram: 智能体之上是协调层:路由、上下文传递、汇总、错误处理。系统能否工作由它决定。_ #### Coordination Layer (编排) - **是什么:** 围绕智能体的代码和规则:谁在何时运行、用什么输入、结果如何合并。 - **为什么重要:** 系统能否工作在这里决定,而不是在单个智能体里。 - **例子:** 智能体都很出色,但某个 worker 拿到了错误的输入——整个系统输出的都是垃圾。 - **坑:** 把心思花在打磨智能体的 prompt 上,却把协调交给运气。 - **关联:** 包含 **Orchestrator**、**Handoff** 和 **Assembly**;用 **Multi-agent Tracing** 来调试。 > **orchestrator 之问:** "有没有一个明确的协调者,负责分解目标、把每一块路由给合适的智能体并汇总结果——还是协调只是碰巧发生的?" > orchestrator 分解目标,把每个子任务路由给专门的 worker,再汇总它们的结果。协调层——而不是单个智能体——才是真正的架构。 ## 3. 专门的 worker orchestrator 指挥的智能体,在每个都很窄的时候最有用。让 worker 保持专注的纪律,正是整个系统可靠、可测试的原因。 ### Worker Agent——每个 worker 只有一项明确的工作 > 一间厨房,每项工作一个工位——一个人管酱汁,一个管烤架,一个管摆盘——每人精通自己那个窄角色,而不是样样手忙脚乱。 **Worker Agent** 是一个专门的智能体,有一项窄而明确的工作:搜文档、写代码、核查事实、排版输出。因为它的职责小,所以它的 **prompt 专注**,**工具很少**,行为可预测。 orchestrator 交给它一个明确的子任务,它做这一件事,然后返回结果。窄的 worker 是积木——每块都简单到能做对、能信任。 _Diagram: 一个 worker:来自 orchestrator 的子任务进来,里面是专注的 prompt 和几个工具,结果出去。_ #### Worker Agent (专家智能体) - **是什么:** 只有一项窄工作、一个短 prompt 和很少工具的智能体。 - **如何工作:** 从 orchestrator 拿到明确的子任务,完成它,并返回结果。 - **例子:** 一个搜文档的智能体、一个写代码的智能体、一个核查事实的智能体、一个排版的智能体。 - **坑:** worker 慢慢地"再多加几个工具",又变回了多面手。 - **关联:** 由 **Orchestrator** 指挥;用 **Per-agent Evals** 检查;遵循 **Depth over Breadth**。 ### Per-agent Evals——窄的智能体更容易测试、更值得信任 > 你可以彻底检查一位专家的工作,因为他的活小而明确——比审查一个什么都沾点边的多面手容易得多。 窄的智能体比庞杂的智能体容易评估、调试和信任得多。有了一项明确的工作,你就能给它写 **evals**——这就是 **Per-agent Evals** 的做法,给每个智能体单独做测试。你能准确看到它在哪里失败,并单独修好它——和智能体课程里同样的可靠性论证,只是用在每一块上。 multi-agent 系统只有在每个 worker 单独都可靠时才可靠,而当每个只做一件范围明确的事时,这容易得多。 _Diagram: 每个 worker 都有自己的 evals。某个失败时,你能准确看到是哪一个,并在不碰其他的情况下修好它。_ #### Per-agent Evals (给每个 worker 的测试) - **是什么:** 给每个 worker 单独准备的一套测试,而不只是给整个系统。 - **怎么做:** 为每项窄工作准备自己的"输入 → 期望输出"样例,并检查结果。 - **例子:** 事实核查员的 evals 失败了——你修它的 prompt,不去动其他智能体。 - **坑:** 只测系统的最终输出:失败时,你分不清该怪哪个智能体。 - **关联:** 只有每个 **Worker Agent** 都够窄才有效;与 **Multi-agent Tracing** 互补。 ### Depth over Breadth——在一项工作上的深度胜过在多项工作上的广度 > 一个外科医生只做一种手术,做上几千次,胜过偶尔做一次的多面手——专注带来的可靠性,广度给不了。 贯穿这一切的原则是 **Depth over Breadth**(深度胜过广度):一个反复做一件事的专注智能体,比偶尔做很多事的宽泛智能体更可靠。这就是为什么要分解——不是为了多出一些智能体,而是为了让每个都窄到真正擅长自己那一块。 如果某个 worker 的工作仍然宽到不可靠,答案通常是**再拆细**,而不是给它堆更多工具。 #### Depth over Breadth (窄胜过宽) - **是什么:** 只做一件事的窄智能体,比做很多事的宽智能体更可靠。 - **为什么重要:** 这正是分解的意义——不在于智能体的数量,而在于它们的窄度。 - **例子:** 一个"调研并写报告"的智能体总是出岔子——把它拆成"调研"和"写作"。 - **坑:** 用更多工具去修一个不可靠的 worker——那只会让它更宽,而不是更好。 - **关联:** **Specialization** 和 **Worker Agent** 的基础。 > **worker 之问:** "每个智能体的工作是否窄到我能单独测试它、信任它——还是某个 worker 仍然做得太多,不可靠?" > worker agent 是窄的专家——一项明确的工作、专注的 prompt、很少的工具——这让每个都可测试、可信任。在一项工作上的深度,胜过在多项工作上的广度。 ## 4. handoff 与上下文 智能体的好坏,取决于它们彼此传递的东西。工作和上下文在它们之间怎么流动——干净还是凌乱——决定了系统是保持连贯,还是退化成噪声。 ### Handoff——在智能体之间传递工作 > 接力跑者交接棒:交接本身就是一门技术,赢得比赛的是一次干净的交接,而不只是跑得快的选手。 **Handoff**(交接)是一个智能体把工作交给另一个的那一刻——orchestrator 交给 worker,或者一个智能体直接交给下一个。传递的是**子任务和完成它所需的上下文**。 handoff 是很多 multi-agent 故障发生的地方:如果接收方没拿到它需要的东西,或者拿到的是一个含糊的版本,不管这个智能体多好,它的输出都会是错的。交接是设计中的一等公民,不是细节。 _Diagram: 一次 handoff 把子任务和上下文从智能体 A 带给智能体 B。含糊的 handoff 意味着错误的结果,哪怕 B 很强。_ #### Handoff (在智能体之间传递工作) - **是什么:** 工作和上下文从一个智能体转到另一个的那一刻。 - **如何工作:** orchestrator → worker,或智能体 → 下一个智能体:子任务加上它所需的上下文。 - **例子:** 研究智能体把找到的事实和任务"写这一节"交给写作智能体。 - **坑:** 很强的智能体拿到糟糕的输入,就会给出糟糕的结果——被怪罪的是智能体,出错的却是 handoff。 - **关联:** 要做成 **Clean Handoff**;它让 **Context Isolation** 成为可能;每次 handoff 都是 **Compounding Error** 的一步。 ### Clean Handoff——传干净、有结构的上下文,而不是全部 > 一次好的交底,只给下一个人完成任务所需的东西——而不是把之前每场对话的完整记录丢给他去翻。 诱惑在于把到目前为止的全部历史都传给每个智能体,但这会在每个智能体内部重现上下文塞得过满的问题。更好的做法是 **Clean Handoff**(干净交接):给接收方一份**专注、有结构的摘要**,只含它需要的东西——相关事实和具体任务——而不是原始的信息洪流。 这让每个智能体的上下文保持紧凑、专注,而这正是当初拆分之所以值得的原因。 _Diagram: 上:整段历史被倒给智能体 B——又一次过载。下:一份简短的事实和任务摘要——B 的上下文保持干净。_ #### Clean Handoff (专注的简报) - **问题:** 传递全部历史会让下一个智能体的上下文过载。 - **思路:** 传一份简短有结构的摘要:所需的事实 + 具体任务。 - **例子:** 不传 40 轮对话,而是"事实:…;任务:写定价这一节,不超过 300 字"。 - **代价:** 得有人决定什么重要——还可能不小心漏掉需要的东西。 - **何时使用:** 每次 handoff 都默认这样做。 - **关联:** 做 **Handoff** 的正确方式;正是它带来了 **Context Isolation**。 ### Context Isolation——每个智能体有自己干净的上下文 > 分开的工作间,每间只有那个房间的工作所需的材料——这样没人会被其他所有任务的杂物分心或搞糊涂。 multi-agent 的一个实在好处是 **Context Isolation**(上下文隔离):每个智能体在自己干净的上下文里工作,只看到它的工作所需的东西,而不是整个系统积累下来的一团乱。这也是拆分能提高可靠性的原因之一——它避免了单个长时间运行的智能体里逐渐积累的 **context rot**(上下文腐烂)。 但只有 handoff 做得规范,你才能得到这个好处;要是把一切都传给所有人,你就是在用额外的步骤重建那个单个过载智能体的问题。 _Diagram: 三个房间:每间里,智能体只看到自己的任务和材料。把一切都给所有人,就又回到一个过载的智能体。_ #### Context Isolation (分开、干净的上下文) - **是什么:** 每个智能体在自己干净的窗口里工作,里面只有它的任务。 - **为什么重要:** 不会像单个长时间运行的智能体那样积累 context rot。 - **例子:** 审阅智能体只看到草稿和评审标准——看不到搜索日志或失败的代码尝试。 - **坑:** 只有配合干净的 handoff 才有效;"所有东西给所有人"会毁掉它。 - **关联:** **Context & Tool Overload** 的答案;建立在 **Clean Handoff** 之上。 > **handoff 之问:** "每次 handoff,我传的是只含下一个智能体所需内容的干净、专注的摘要——还是把全部历史倒过去,重现上下文过载的问题?" > handoff 在智能体之间传递工作,而它们正是 multi-agent 常出问题的地方。传一份只含所需内容的干净、有结构的摘要,让每个智能体保持拆分本该带来的那种专注的上下文。 ## 5. sequential、parallel、hierarchical multi-agent 系统是按几种反复出现的形态接起来的。了解其中三种主要的——以及各自何时合适——就知道了大半该怎么组织协调。 ### Sequential——分阶段的流水线 > 一条装配线:每个工位做自己的那部分,按固定顺序把产品传给下一个,直到最后成品下线。 **Sequential**(顺序)模式把智能体按固定顺序串起来:智能体 A 的输出喂给智能体 B,B 的输出再喂给智能体 C。先是起草智能体,再是编辑智能体,再是事实核查智能体。 它是最简单的 multi-agent 形态,也最可预测,适合工作有必须按顺序发生的自然阶段的情形。它本质上是一条**专家流水线**——当步骤固定时,它比每次都重新决定顺序的循环更可靠。 _Diagram: 一条顺序流水线:起草 → 编辑 → 事实核查。顺序永远一样。_ #### Sequential (流水线、智能体链) - **问题:** 工作有必须严格按顺序进行的阶段。 - **思路:** 一条智能体链:前一个的输出是后一个的输入。 - **例子:** 起草智能体 → 编辑智能体 → 事实核查智能体。 - **代价:** 比 parallel 慢;早期阶段的错误会沿链往下传。 - **何时使用:** 步骤固定且彼此依赖。最简单的形态。 - **关联:** 像架构模式里的 **Pipe-and-Filter**;每个衔接处都是一次 **Handoff**。 ### Parallel——扇出再汇集 > 把同一个调研问题同时发给几位助手,再把他们的发现收到一起——许多人同时工作,最后合并结果。 **Parallel**(并行)模式让多个智能体同时处理相互独立的部分,然后汇集它们的结果——先 **fan-out**(扇出),再 **gather**(汇集)。调研五个子话题、处理很多条目、获取几个独立的视角:这些并行做都比一个接一个更快。 orchestrator 拆分工作,worker 同时运行,结果再合并。当各部分互不依赖且速度重要时,parallel 最能发挥作用。 _Diagram: 扇出:orchestrator 分发五个子话题,worker 同时运行。汇集:结果合并成一个。_ #### Parallel (fan-out / gather) - **问题:** 有很多相互独立的部分,一个一个做太慢。 - **思路:** 把各部分同时交给几个智能体,再汇集结果。 - **例子:** 并行调研五个子话题,再把发现合并成一份报告。 - **代价:** 同时发出更多模型调用;汇总时必须化解各结果之间的冲突。 - **何时使用:** 各部分互不依赖,且速度重要。 - **关联:** 最后一步是 **Assembly**;**Orchestrator** 负责扇出和汇集。 ### Hierarchical——orchestrator 的 orchestrator > 公司的组织架构图:经理指挥组长,组长各自指挥自己的员工——协调分层嵌套,用于一层装不下的大工作。 **Hierarchical**(层级)模式把协调嵌套起来:顶层 orchestrator 把活委派给**子 orchestrator**,各自管理自己的 worker。这样靠一层层分解,来处理真正庞大复杂的任务,就像一个组织那样。 它是最强大的形态,也是最复杂的——更多协调,更多出错的地方——所以只有当任务大到确实需要嵌套分解时才用它。大多数系统用 sequential 或 parallel 就够了;层级是留给少数不够用的情形。 _Diagram: 顶层 orchestrator 指挥子 orchestrator,它们再指挥各自的 worker。三层协调。_ #### Hierarchical (嵌套的 orchestrator) - **问题:** 任务大到一个 orchestrator 拆不开,也撑不住。 - **思路:** 顶层 orchestrator 委派给子 orchestrator,每个都有自己的 worker。 - **例子:** 一个大型研究项目:顶层智能体把它分成几个领域,每个领域有自己的协调者和研究员。 - **代价:** 最复杂的形态:更多协调,更多出错的地方。 - **何时使用:** 只有当任务确实需要嵌套分解时。很少用。 - **关联:** **Orchestrator** 嵌套在自己里面;每一层内部是 **Sequential** 或 **Parallel**。 > **形态之问:** "这项工作适合固定的流水线(sequential)、同时运行的独立部分(parallel),还是嵌套的多层协调(hierarchical)——我用的是适合的形态里最简单的那个吗?" > sequential 把智能体串成固定的流水线;parallel 把独立的工作扇出再汇集;hierarchical 为大任务嵌套 orchestrator。用工作真正需要的最简单的形态。 ## 6. 被成倍放大的故障模式 multi-agent 很诱人,也常被滥用。更多的智能体不只是增加能力——它们成倍增加系统出错的方式,而忽视这一点,正是这类系统悄悄失败的原因。 ### Compounding Error——步骤越多,误差累积越多 > 更长的接力有更多次交接,就有更多机会掉棒——每多一次交换,就多一个让整场跑失败的地方。 这就是 **Compounding Error**(误差累积)的概念。单个智能体在一条长链上本来就只有一部分时候能成功(智能体课程里的可靠性问题),而 multi-agent 让链更长:更多智能体、更多 handoff、更多步骤,每一步都可能失败,并把错误传给下游。 **可靠性沿链条相乘**,所以增加智能体可能*降低*整体成功率,除非每一块和每次 handoff 都扎实。更多的智能体意味着更多误差累积的面,而不是自动意味着更多能力。 _Diagram: 一个示意性的例子:如果每一步成功率为 95%,一条 10 步的链只有约 60% 的成功率。_ #### Compounding Error (沿链条相乘的误差) - **是什么:** 成功的概率一步步相乘,所以长链更容易失败。 - **为什么重要:** 每多一个智能体、每多一次 handoff,就多一个小于 1 的乘数。 - **例子:** 每步 95%,三步后约 86%,十步后约 60%。 - **坑:** 以为更多的智能体总是意味着更多的能力。 - **关联:** 随每次 **Handoff** 增长;所以 **Sequential** 要保持短,**Hierarchical** 很少用。 ### Coordination Overhead——协调有它自己的开销和成本 > 为协调五个团队开的一场会,可能比活本身还贵——过了某个点,协调比干活更费劲。 这就是 **Coordination Overhead**(协调开销)。每个智能体都有自己的模型调用、自己的延迟、自己的成本——而编排又在上面再加一层:**路由、handoff、汇总、重试**。同一个任务,multi-agent 系统可能比单个智能体慢得多、贵得多,有时还没有更好。 如果专门化的收益没有明显盖过这些额外的成本和延迟,那么更简单的单个智能体才是更好的工程选择。 _Diagram: 同样的活,但 multi-agent 版本在上面又加了路由、handoff、汇总和重试——更多延迟和花费。_ #### Coordination Overhead (编排的额外成本) - **是什么:** 花在路由、handoff、汇总和重试上的额外模型调用、延迟和金钱。 - **为什么重要:** 系统可能变得比一个智能体更慢、更贵——却没有变得更好。 - **例子:** 一个简单的问题要经过一个 orchestrator 和三个 worker,而不是一次调用。 - **坑:** 拆分前后不衡量成本和延迟。 - **关联:** **Coordination Cost** 的具体形态;支持 **Single Agent by Default** 的论据。 ### Multi-agent Tracing——更难追踪和调试 > 追踪一个包裹很容易;在一张由仓库、卡车和交接构成的网里追查故障,是另一回事,难得多。 multi-agent 系统出了问题,要找到*在哪里*,比单个智能体难得多:故障可能在任何一个 worker、任何一次 handoff,或编排本身。所以**可观测性**变得必不可少——这就是 **Multi-agent Tracing** 的做法:跨智能体追踪一个请求,并**记录每一次 handoff**。 这种调试成本是代价的真实组成部分。一个你无法追踪的系统,就是一个你无法可靠修复的系统,而 multi-agent 确实让追踪更难。 _Diagram: 一个请求的追踪记录:orchestrator、handoff、智能体、汇总。你能看出是代码智能体失败了。_ #### Multi-agent Tracing (跨智能体的可观测性) - **是什么:** 记录一个请求经过每个智能体和每次 handoff 的路径。 - **怎么做:** 共用的请求 ID、每次 handoff 的日志(传了什么、回来了什么)、每一步的耗时和成本。 - **例子:** 答案是错的——追踪显示代码智能体在 handoff 时拿到的上下文不完整。 - **坑:** 没有追踪,故障就是"系统里的某个地方"——盲目修复几乎不可能。 - **关联:** 你调试 **Coordination Layer** 的方式;配合 **Per-agent Evals** 能看出该怪谁。 > **成本之问:** "这里专门化的收益,是否明显盖过了被成倍放大的成本——更多步骤累积误差、更多延迟和花费、更难追踪——还是我只是条件反射地加智能体?" > 更多智能体成倍放大故障模式:更多步骤累积误差、实实在在的协调开销和成本,以及难得多的追踪。条件反射式的 multi-agent 降低的是可靠性,而不是提高它。 ## 7. 用好它 multi-agent 对合适的问题是强大的工具,对不合适的问题则是昂贵的错误。用好它主要是克制:只有当单个智能体真的应付不了时才拆。 ### Single Agent by Default——只有当一个智能体真的应付不了时才拆 > 回答一个简单的问题,你不会组一个委员会——只有当活确实大到一个能干的人干不了时,你才请来一个团队。 这就是 **Single Agent by Default**(默认单个智能体)的原则。默认应该是**单个智能体**,只有当一个确实应付不了这项工作时——不同的技能太多、工具太多、上下文多到无法连贯地装下——你才去用 multi-agent。如果一个构建良好的单个智能体能做到,multi-agent 版本只是白白增加成本、延迟和故障模式。 问题从来不是"我能拆吗?"——几乎任何东西都能拆——而是"一个智能体在这里真的不够吗?" _Diagram: 从一个智能体开始。如果它吃力,先收窄它的工具、收紧它的上下文。只有这样还不行——再上 multi-agent。_ #### Single Agent by Default (从一个智能体开始) - **是什么:** 从一个智能体开始,只有当它真的应付不了时才拆。 - **为什么重要:** 多出来的智能体增加成本、延迟和故障模式,却没有收益。 - **例子:** 一个智能体在 20 个工具里迷路了——先只留给它需要的 5 个,之后再考虑拆。 - **坑:** 问"这能拆吗?"——几乎任何东西都能拆。 - **关联:** **Coordination Overhead** 和 **Compounding Error** 的制衡;通往 **Orchestrator** 的出口——只在真正需要时。 ### 让每个智能体保持窄,每次 handoff 保持干净 > 一支管理良好的队伍有明确界定的角色和练习过的交接——让它可靠的是结构,而不是英雄式的拼搏。 当你确实要上 multi-agent 时,让它奏效的两条纪律是:让每个 worker 保持**窄**(一项明确的工作、很少的工具、能单独测试),让每次 handoff 保持**干净**(只含所需内容的专注摘要,而不是全部历史)。大多数 multi-agent 故障都能追到某个太宽的 worker 或某次太含糊的 handoff。把这两点做对,再配上明确的 orchestrator 和最简单的适用模式,系统在扩大规模时仍能保持可靠。 #### 上 multi-agent 之前 - **一个智能体真的做不了这件事吗**——还是它在这个负载下确实会崩? - **有没有明确的 orchestrator**,负责分解、路由和汇总? - **每个 worker 都够窄吗**——一项工作、很少的工具、能单独测试? - **handoff 干净吗**——专注的摘要,而不是倒过去整段历史? - **哪种模式适合**——sequential、parallel 还是 hierarchical——它是可行的里面最简单的吗? - **收益盖过成本了吗**——更多步骤、延迟、花费,以及更难的追踪? #### 你编排得好的迹象 - 你**只在一个智能体真的应付不了时**才用 multi-agent。 - 一个明确的 **orchestrator** 负责分解、路由和汇总工作。 - 每个 **worker 都很窄**——能单独测试、值得信任。 - **handoff 是干净的**,传递专注的上下文,让每个智能体的窗口保持紧凑。 - 你用的是适合的**最简单的模式**,并且能**跨智能体追踪**一次故障。 ### 这一切如何串起来 > 完整的地铁图:现在你能看到各条线在哪里交汇。 你从**一个智能体**开始。如果它应付不了,**orchestrator** 就出现了:它挑一种**模式**(sequential、parallel 或 hierarchical),通过**干净的 handoff** 把活交给**窄的 worker**,然后汇总结果。每个智能体和每次 handoff 都会增加**开销**和**累积误差**——如果收益小于成本,就退回一个智能体。而**追踪**能准确显示哪里出了问题。 _Diagram: 课程概念的链条:从一个智能体到 orchestrator、模式、handoff 和 worker——以及把你拉回单个智能体的成本。_ ## 速查表:全部 19 个概念 ### 为什么要拆 - **Specialization** (专门的智能体): 窄的智能体各自把一件事做好——multi-agent 的核心理由。 - **Context & Tool Overload** (上下文太多、工具太多): 一个智能体的窗口塞得太满,工具菜单太长。 - **Coordination Cost** (协调的代价): 拆分、路由、传递、汇总——这要花成本,而且必须值得。 ### Orchestrator - **Orchestrator** (协调者): 主智能体把目标拆成子任务,交给 worker。 - **Assembly** (综合): 把各 worker 的输出合并成一个结果:化解冲突、去掉重复。 - **Coordination Layer** (编排): 谁在何时运行、用什么输入、结果如何合并——真正的架构。 ### Workers - **Worker Agent** (专家智能体): 一项窄工作,一个短 prompt,很少的工具。 - **Per-agent Evals** (给每个 worker 的测试): 单独测试每个 worker——看出谁失败了,并单独修好它。 - **Depth over Breadth** (窄胜过宽): worker 太宽、不可靠——再拆细,别加工具。 ### Handoffs - **Handoff** (传递工作): 子任务及其上下文从一个智能体转到另一个的那一刻。 - **Clean Handoff** (专注的简报): 一份简短的摘要:所需的事实 + 任务,而不是全部历史。 - **Context Isolation** (分开、干净的上下文): 每个智能体有自己干净的窗口——没有 context rot。 ### 模式 - **Sequential** (流水线): A → B → C,顺序固定。最简单、最可预测。 - **Parallel** (fan-out / gather): 独立的部分同时进行,然后汇集。追求速度。 - **Hierarchical** (嵌套的 orchestrator): orchestrator 的 orchestrator。最强大也最复杂——很少用。 ### 故障模式 - **Compounding Error** (误差相乘): 成功率逐步相乘:智能体越多——链越长——故障越多。 - **Coordination Overhead** (额外成本): 路由、handoff、汇总、重试——更多延迟和金钱。 - **Multi-agent Tracing** (跨智能体的可观测性): 记录每次 handoff,这样就能准确找到哪里出了问题。 ### 实践 - **Single Agent by Default** (从一个智能体开始): 只有当一个构建良好的智能体真的应付不了时才拆。 > multi-agent 是深思熟虑的选择:只有当一个智能体真的应付不了时才拆,给它一个明确的 orchestrator,让每个 worker 保持窄、每次 handoff 保持干净,并用最简单的模式——因为你每多加一个智能体,成本和故障模式都会成倍增加。 速成课结束 · 7 章 · 19 个概念 接下来是实践:拿一个你很想拆给多个智能体的任务,先试着让一个构建良好的智能体去做——收窄它的工具、收紧它的上下文。如果它真的应付不了,就分解:一个明确的 orchestrator、两三个窄的 worker、干净的 handoff、最简单的适用模式。然后把一次运行从头追踪到尾,看看成本和错误究竟落在哪里。当你亲身感到协调有多贵,并把它留给专门化真正划算的场合时,这门功夫就通了。但要把一个想法放在所有想法之上:更多的智能体既成倍放大能力,也成倍放大故障模式。只有当一个智能体不够用时才拆——而一旦拆了,围绕它们的结构就是全部的关键。