多 Agent：什么时候值得，什么时候是自找麻烦

所属：第三部分 · 结构与可靠性（第 9–11 章） 前置：第 8 章（能力调用与任务委托）、第 5 章（本轮工作集与上下文隔离）、第 3 章（任务级控制流与编排） 本章新概念：多 Agent（本课的操作性定义）、主 Agent、子 Agent、主 Agent—子 Agent 编排、子任务交接合同、handoff（责任移交）、审稿模式、群聊式协作

一、上一章留下的问题¶

上一章已经区分了两种跨程序动作：调用一个边界清楚的能力，或把一项目标及其内部执行责任委托给远端 Agent。A2A 可以帮助两个 Agent 按共同协议协作，但「能够委托」只解决连接问题，没有证明这项任务值得拆开。

仍以每周调研为例。现在要汇总过去一周值得关注的 AI Agent 动态，从十几条候选事件里选出五项，写成一页简报。每项必须说明发生了什么、为什么值得关注，并附上原始来源、发布日期和证据缺口。

一个 Agent 顺序搜索、阅读、核对、比较和写作，可能耗时很长，工作集也会不断混入不同事件的原文和探索轨迹。最直觉的改法是开五个 Agent，同时查五个方向。

但这五个 Agent 也可能同时查到同一项发布，使用不同标准判断「重要」，最后交回五种格式。负责最终汇总的主 Agent 不但要重新去重、核对和排序，还要补查各自漏掉的内容。看起来并行了，实际新增了一轮拆任务、交接、合并和返工。

所以，多 Agent 的问题不是「能不能多开几个」，而是：

拆分产生的并行、专注或独立核验收益，能不能盖过新增的交接、重复处理、等待和合并成本？

二、什么才算多 Agent¶

本课采用一个便于判断系统结构的定义：

同一项任务的执行职责，被分给两个以上可以分别配置、各自运行的 Agent；运行系统负责调用、移交或汇总它们的工作。

按本课的判据，每个被算作 Agent 的角色都要能在自己的职责范围内，根据反馈继续选择动作与停止时点。它们可以分别配置指令、工具和本轮工作集，可以使用同一个底层模型，也可以使用不同模型；可以同时运行，也可以顺序交接。并行是一种调度方式，不是多 Agent 的定义。

在本章的主从例子里，负责总目标、分派和最终汇总的角色叫主 Agent；接收有界子任务、在自己的动作循环里工作的角色叫子 Agent。有些多 Agent 结构会顺序移交责任或采用多方协作，并不一定都有一个主 Agent。

Anthropic 在 2025 年介绍其研究系统时，把多 Agent 描述为多个能够在循环中自主使用工具的 Agent 共同工作。本课的定义与它相近，但重点放在能否判断职责与交接边界，而不把某个产品实现当成统一标准。Anthropic 的多 Agent 研究系统

下面几种情况不自动构成多 Agent：

• 一个 Agent 调用了十种工具，仍然只有一个 Agent 在选择任务路径；
• 程序并行发出五次普通摘要请求，每次都只完成固定动作，这是并行模型调用；
• 提示词要求同一个模型「先扮演研究员，再扮演编辑」，仍是一个调用里的角色提示；
• 一条固定流水线把搜索结果依次交给摘要、翻译和排版模型，若每个节点只完成预写职责，整体仍是工作流；
• 接入 MCP Server 只表示 Agent 能调用外部能力，Server 不因此自动成为另一个 Agent。

回到 Agent 这个词指四种东西的判据：先看一个节点有没有根据反馈持续选择动作与停止时点，再数系统里有几个 Agent。 给普通模型调用起五个角色名，不会让工作流自动变成多 Agent。

三、拆开以后，多了三段工作¶

单 Agent 运行时，一条循环负责整项任务：模型选择动作，运行系统执行并回填，直到它给出结果或被强制停止。

拆成主 Agent 和子 Agent 后，原来的任务路径之间多了三段工作：

1. 委派。 主 Agent 或程序要决定拆出什么子任务，并准备子 Agent 真正需要的输入、工具和边界。
2. 交接。 子 Agent 要把结果、证据、缺口和失败状态交回来，不能只说「已经完成」。
3. 合并。 主 Agent 或程序要处理重复、冲突、缺失和不同格式，再决定是否继续分派或形成最终结果。

这三段工作不会因为框架提供了「创建子 Agent」按钮就消失。它们正是多 Agent 新增的协调成本。

拆分也可能带来三类收益：

• 并行。 互不依赖的子任务可以同时推进，缩短等待时间；
• 隔离与专注。 每个子 Agent 只看本职责需要的材料、指令和工具，避免所有支线过程挤进主线工作集；
• 独立核验。 一份中间交付物可以由另一套标准或另一条取证路径检查，不必让生产者自己给自己打分。

这些收益不是同时自动出现。顺序移交职责可能带来职责和提示词隔离，却没有并行收益；五个子 Agent 同时搜索可能并行，却因范围重叠而无法独立验收；再开一个使用相同材料、相同判断方式的「审稿 Agent」，也可能只是把同一种错误重复一次。

多 Agent 不是免费增加五份能力，而是用新的任务边界交换并行、隔离或核验机会。每增加一道边界，都要同时计算它带来的收益和协调成本。

四、拆分前先过三道门¶

第一道：这项职责为什么要拥有自己的 Agent

先指出单 Agent 的具体缺口。合理理由可以是：子任务能独立并行；它需要明显不同的指令、工具或权限；它的探索过程不值得进入主线；或者它需要由另一套标准独立检查。

「让系统看起来更专业」「每个角色只做一件事」不是充分理由。一次固定分类、格式转换或确定性计算，通常更适合留在程序或普通模型调用里。

第二道：责任结束时，结果能否验收或接续

每个独立职责都要有可判断的完成或失败状态，也要说明结果交给谁。子 Agent 返回有界结果时，交付物应能被接受、拒绝或标成未完成，并能进入后续合并；责任移交给另一个 Agent 时，接任者也要知道完成标准，以及谁对最终交付物负责。

对调研任务，至少要能检查：来源是否存在，日期是否在范围内，原文是否支持主张，缺口是否如实保留，输出是否能与其他结果去重和比较。

如果主 Agent 必须读完子 Agent 的全部搜索轨迹，才能知道它做了什么；或者五份结果必须放在一起，才勉强能判断其中每一份是否正确，那么拆分边界并不清楚。上下文虽然分开了，核验和合并工作却没有真正分开。若责任已经移交，却没人知道接任者何时算完成、结果由谁发布，交接同样没有闭环。

第三道：端到端结果是否优于单 Agent 基线

拆分的目标必须落到可观察结果上，例如覆盖更多可靠来源、减少遗漏、缩短总等待时间，或者降低主线被无关材料干扰的程度。同时还要累计模型调用、工具调用、重复读取、最慢分支等待、返工和合并成本。

只有多 Agent 在相同任务和质量要求下带来净收益，才值得保留。否则，它只是把一个难调试的循环变成一组更难追踪的循环。

把三道门放进「同时调查多个事件」这个场景：第一道门检查子任务能否独立推进、主线是否需要看各支线的中间过程，由此判断并行与隔离收益；第二道门检查交付物能否独立核验并合并；第三道门仍要与单 Agent 基线比较。这里的「独立推进、独立核验、不共享中间过程」是并行研究的强适配信号，不是所有多 Agent 结构的必要条件。顺序交接和审稿循环不满足「独立并行」，却可能因职责隔离或检查方式不同而有价值。

五、同一份调研，坏拆分与好拆分差在哪里¶

一种坏拆分是按宽泛话题分工：五个子 Agent 分别查「模型」「产品」「框架」「协议」和「行业动态」。这些范围互相重叠：一家公司发布新的 Agent 产品，可能同时落进模型、产品和行业动态。各子 Agent 又只看自己的候选，无法在全部事件中判断哪五项最重要。

一种更清楚的拆法，是先由主 Agent 或固定程序完成候选扫描，把讲同一件事的链接归入一个事件包。每个子 Agent 只核查一个事件包，回答同一组问题；最终的跨事件去重、冲突处理和重要性排序仍由主 Agent 完成。

两种做法改变的是任务边界：

好拆分可以按以下顺序运行：

1. 主 Agent 扫描候选链接，把同一事件的材料归到同一个事件编号下。
2. 每个子 Agent 收到一个事件包，在自己的工作集中搜索、阅读和核对。
3. 子 Agent 只交回事件证据卡，不把全部搜索轨迹塞回主线。
4. 运行系统检查必填项；需要二次复查时，审稿 Agent 按来源重新检查支持关系。
5. 主 Agent 同时看所有通过核验的事件，统一去重、排序并写成简报。

这里没有把所有步骤都拆出去。形成互不重叠的事件包决定子任务边界，最终排序又依赖看见全部候选；这两项都留在全局。 真正分出去的，是中间那些能够独立调查和验收的事件。

交接不能只给一句角色名

给子 Agent 写「你是资深研究员，请调查这个事件」，没有说明边界、交付物和失败状态。主 Agent 至少要把六件事说清：

1. 目标与范围。 要确认什么，哪些情况算在内，哪些不算；
2. 起始材料。 事件编号、时间范围、已有来源和待确认问题；
3. 允许动作。 可以使用哪些工具、来源和权限；
4. 交付物。 必须返回哪些字段，以多细的程度返回；
5. 证据与不确定性。 每条主张由什么材料支持，有哪些冲突或缺口；
6. 结束与失败。 什么状态算完成，何时停止，超时、无结果或被阻塞时怎样报告。

这六项合起来，可以称为子任务交接合同。它不是提示词写得长，而是让主 Agent 和运行系统能够判断子任务是否完成、结果能否合并。

交回主线的事件证据卡可以只带：事件编号、一句话事实主张、核验状态、原始来源与日期、原文支持什么、不支持什么、未解决问题，以及可能重复的事件编号。支线读过的原始材料仍应保存在模型外，并留下可回查指针。模型生成的卡仍是待检查记录；字段齐全只证明格式合格，不证明内容为真。

六、五种常见组织形状¶

下面五种形状经常出现在「多 Agent」讨论里。它们不是一套官方穷尽分类，也不是五个互斥方案。单 Agent 是比较基线；流水线和审稿链若只有固定模型调用，仍可能只是工作流；真实系统还可以把主从、并行和审稿组合起来。

1. 单 Agent：先保留不拆的基线

一个 Agent 负责搜索、阅读、比较和写作。它不用描述子任务，也没有跨 Agent 的信息损失和合并冲突。任务不大、材料能被良好管理、工具选择也不复杂时，这通常是成本最低、最容易排查的起点。

单 Agent 不等于把所有内容都塞进一个窗口。上下文工程里的外置、检索、压缩和隔离仍然适用；其中一些支线还可以用独立的固定模型调用完成，不必立刻升级为子 Agent。

2. 主 Agent—子 Agent 编排：主线保留最终责任

主 Agent 判断需要哪些子任务，调用一个或多个子 Agent，再接收结果并形成最终答案。子 Agent 像有独立工作集和动作循环的工具，只负责有界任务，不接管用户对话。

这种形状适合本章的事件核查：主 Agent 保留全局候选和最终排序，子 Agent 分别调查事件。独立事件可以并行；存在依赖的事件则应等待必要输入。

OpenAI Agents SDK 把相近模式称为 agents as tools：manager 保留对话与综合责任，specialist 返回有界结果。OpenAI 的 Agent 编排说明

3. 流水线：交付物按预设阶段流动

前一阶段的交付物成为后一阶段的输入。例如研究 Agent 交给写作 Agent，写作结果再交给发布检查。它适合阶段边界稳定、每一步的输入输出都能写清的任务，但不能靠并行缩短一条有依赖的链。

流水线描述的是预设阶段顺序。如果顺序和转移规则由程序预先写好，整条结构仍是工作流，即使每个节点都叫「Agent」。

**Handoff（责任移交）**与流水线不在同一个分类维度。流水线描述工作经过哪些阶段；handoff 描述当前责任主体发生变化，可以出现在路由、流水线或其他结构里。如果当前 Agent 根据现场输入选择某个专家，并让专家成为当前活跃 Agent，就发生了一次 handoff。在 OpenAI Agents SDK 的 handoff 模式中，专家接管本轮后续交互；原 Agent 不会自动等专家做完再回来综合。需要回传时，必须另设交接路径。OpenAI 的 handoff 说明

因此，handoff 不是「调用子 Agent 后等结果返回」的另一个名字。前者转移当前责任，后者由主 Agent 保留责任。

4. 审稿模式：生产者与检查者分开

一个 Agent 先产出，另一个按明确标准给出通过、拒绝或修改意见；不通过时，结果回到生产者再改。它适合可以写出检查标准、反馈也确实能改善结果的任务。

审稿模式不一定是多 Agent。如果生产与检查都只是程序触发的一次固定模型调用，它是生成—检查工作流；如果双方各自能用工具取证、根据结果循环并决定何时结束，才符合本课的多 Agent 定义。Anthropic 在 2024 年的工程文章中把相近的固定模式称为 evaluator-optimizer，并强调它依赖清楚的评价标准。Anthropic 的 Agent 构建模式

5. 群聊式协作：多方共享消息再继续

多个 Agent 把消息发到一个共享线程里，由程序、指定主持者或模型决定下一位发言者。它适合问题需要多种视角互相修正，而且新的发言确实依赖别人刚说过的内容。

群聊不等于把几个 Agent 同时启动。参与者要频繁阅读彼此消息，工作集会重新汇合；如果没有明确的发言选择、决策归属和停止条件，系统容易重复讨论、互相附和，最后没有人对正式交付物负责。能够提前拆成独立事件包的调研任务，通常不需要让所有子 Agent 共享完整群聊。

七、把五种形状放到同一组问题里¶

前面的五种形状可以用同一组问题比较：下一项职责怎样启动，任务阶段能否并行，谁拥有最终交付物，以及主要失败点是什么。

这张表不是成熟度阶梯。一个常见组合是：主 Agent 先并行分派事件核查，汇总证据卡后交给审稿 Agent 检查，最后自己写简报。另一个系统也可能先 handoff 给合适的领域专家，专家再把窄任务分给子 Agent。

Agents as tools 与 handoff 回答的是「当前责任是否仍由主 Agent 保留」，不是第六种组织形状。前者把有界结果交回主 Agent；后者让接任者成为当前活跃 Agent。两种责任关系都可以嵌入更大的编排结构。

选择形状时，不要先问「哪种最先进」，而要沿着任务依赖来问：哪些工作能同时开始，哪些必须等上一步，谁需要看全局，谁只需要一个有界工作集，哪一个角色对最终结果负责。

八、另一个 Agent 同意，不等于结果已经核验¶

多 Agent 常给人一种直觉：一方写，另一方看过，就比单 Agent 更可靠。但第二个 Agent 的「同意」仍然只是模型输出。两个 Agent 如果读取同一份错误摘要、使用相同的判断提示，或者都没有打开原始来源，完全可能重复同一种错误。

真正的核验必须给检查者一项可观察依据：

• 数字能否由程序重新计算；
• 链接能否打开，发布日期是否在要求范围内；
• 原文具体片段是否支持主张，而不是只与话题相关；
• 两份记录是否指向同一事件；
• 已知正确答案或人工标准是否与结果一致。

对调研任务，审稿 Agent 应读取主张、来源指针和原文片段，重新判断支持关系；不必继承研究 Agent 的整段推理过程。运行系统还要检查结构和状态。如果某个事件无可靠来源、仍有冲突或子 Agent 超时，就把它标成未核实、冲突或未完成，而不是让主 Agent 凭语气补成确定结论。

上下文隔离只让检查者少受生产过程影响，不会把检查者自动变成独立证据。没有外部标准时，最多可以说多了一次不同角色的复查，不能声称事实已经被证明。

九、并行可能省实际等待时间，不省总工作量¶

假设五个事件都能独立调查。顺序执行时，等待时间接近五段工作逐项相加；同时启动后，调查阶段可能接近最慢那一段，再加上分派与合并时间。

但每个子 Agent 读取的材料、使用的 token 和发出的工具调用仍要累计。多个分支还可能重复搜索共同背景；如果汇总必须等齐所有分支，最慢的分支会拖住整批；限流、重试和共享写入冲突也会吃掉并行收益。并行可能缩短从开始到完成的实际等待时间，却不会自动减少总计算量或总成本。

2025 年 6 月，Anthropic 介绍了一套主 Agent 配合并行搜索子 Agent 的研究系统，并称这种结构尤其适合同时追踪多个独立方向的问题。在其内部研究评测中，Claude Opus 4 主 Agent 配合 Claude Sonnet 4 子 Agent，比单个 Claude Opus 4 的评测表现高 90.2%。同一篇文章另行报告，在 Anthropic 自有数据中，多 Agent 系统使用的 token 约为普通聊天的 15 倍。前一个数字只说明特定模型组合在该内部评测中的相对成绩，后一个数字只说明其自有数据里的总体 token 量级；两者不能用来计算单 Agent 到多 Agent 的性价比。Anthropic 的多 Agent 研究系统

是否值得，要用自己的任务比较单 Agent 与多 Agent。至少同时看：

1. 最终结果是否更完整，来源是否真正支持结论；
2. 从开始到交付等了多久；
3. 总模型用量、工具调用和外部服务成本是多少；
4. 有多少重复搜索、重复事件和合并冲突；
5. 某个子任务失败后，系统能否单独重试、降级或如实交付部分结果。

只比较最终文风，会漏掉多 Agent 最主要的代价；只比较调用次数，也会漏掉并行缩短等待和上下文隔离带来的收益。

十、最稳的做法：一次只增加一道边界¶

面对一个新任务，可以按六步决定是否拆：

1. 先跑单 Agent 或固定工作流基线。 记录它在什么任务上失败，别从组织结构猜问题。
2. 指出具体缺口。 是等待太久、工具太多、上下文互相干扰、职责需要不同权限，还是结果缺少独立检查？
3. 只增加一道针对缺口的边界。 例如先把独立事件核查交给一个子 Agent，而不是一次建出十个角色。
4. 写清交接合同。 让子任务有明确范围、输入、工具、交付物、证据、完成与失败状态。
5. 与原基线比较。 同时检查质量、等待时间、总成本、重复工作、合并冲突和失败恢复。
6. 没有净收益就撤掉。 多 Agent 是可删除的设计选择，不是项目成熟度的证明。

这条方法也能阻止另一种常见错误：问题明明来自工具说明含混或工作集装配不当，却用新增 Agent 掩盖。子 Agent 仍会使用同样的工具、读取同样的材料；底层边界没修好，多开几个循环只会把问题复制出去。

使用完成任务所需的最少 Agent。先找到单 Agent 的真实缺口，再用一道可验收的职责边界修它；只有端到端结果变好，才保留这次拆分。

十一、三条结论¶

一，多 Agent 的定义不在数量标签，而在执行职责是否分给了多个可分别运行的 Agent。 多工具、多次模型调用、提示词里的多角色和固定模型流水线都不自动构成多 Agent；多个 Agent 也不一定并行。

二，拆分新增了委派、交接和合并，必须用真实收益支付这些协调成本。 并行、上下文隔离和独立核验都是可能的收益来源；每项独立职责能否在结束时被验收、失败时被识别，并让后续责任人继续处理，是拆分边界能否成立的基础。

三，选择多 Agent 要比较端到端净收益。 先用单 Agent 或工作流建立基线，再逐道增加边界；质量、覆盖、等待时间、总成本和失败恢复没有整体变好，就不应为架构名称保留复杂度。

十二、这一章引出的问题¶

把任务拆开以后，系统并没有自动变得可靠。它反而新增了委派是否正确、交接是否漏信息、子任务是否失败、合并是否冲突等失败机会。

下一章继续处理这些失败机会：哪些判断可以改成程序能够校验的确定性操作，哪些结果需要护栏、恢复或人工确认，怎样提高每个关键检查点的通过率，并减少未被发现和纠正的错误继续向后传播。

十三、自检题¶

1. 一个 Agent 同时调用搜索、读取和计算工具，为什么不算多 Agent？
2. 程序并行调用五次模型，让它们各自摘要一篇文章，是否一定算多 Agent？
3. 为什么「可并行、可独立核验、彼此不看中间过程」不能写成所有多 Agent 的必要条件？
4. 你要核对 30 个互不依赖的候选事件，每个都按原文检查五个固定字段。怎样用三道门判断是否拆成多个子 Agent？为什么答案仍可能是「不拆」？
5. 一个可以独立验收的子任务交接，至少要写清哪些内容？
6. 主 Agent 调用子 Agent 后继续负责综合，与 handoff 给专家有什么区别？
7. 固定流水线里有三个名叫「研究 Agent」「写作 Agent」「排版 Agent」的模型节点，为什么整体仍可能是工作流？
8. 审稿 Agent 表示同意，为什么不能证明原结论为真？
9. 五个独立子任务并行执行，为什么总等待时间可能下降，而总成本反而上升？
10. 多 Agent 必须使用 A2A 吗？MCP Server 又是否自动算一个子 Agent？

十四、参考答案¶

先自己答完再往下看。

1. 因为任务路径仍由同一个 Agent 循环选择。 工具是它可调用的外部能力，不是拥有独立职责、工作集和动作循环的另一个 Agent。
2. 不一定。 如果五次调用都只完成程序预写的固定摘要动作，它们是并行模型调用；只有调用对象各自拥有 Agent 职责与运行循环时，才符合本课定义。
3. 因为多 Agent 不一定用于并行分工。 顺序 handoff 可以为不同职责切换指令和工具，审稿模式也依赖先生产再检查。三项同时成立只适合作为并行研究拆分的强判据。
4. 先看收益来源，再看验收边界，最后比较基线。 三十个事件互不依赖，说明并行可能缩短等待；五个固定字段和原文依据可以形成统一交付物，说明结果可能单独验收与合并。但仍要与单 Agent 基线比较质量、实际等待时间、总成本、重复工作和失败恢复。若单 Agent 已能在要求时间内稳定完成，或拆分成本更高，答案仍可以是不拆。
5. 至少写清目标与范围、起始材料、允许动作、交付物、证据与不确定性，以及完成和失败状态。 这些信息让结果能够被验收、拒绝、重试或合并。
6. 主从调用不转移最终责任，handoff 会切换当前责任主体。 主 Agent 把子 Agent 当有界能力使用，等结果回来后自己综合；handoff 后专家成为当前活跃 Agent，除非另设回传路径，否则原 Agent 不会自动回来汇总。
7. 因为角色名不会改变控制流。 如果三个节点的顺序、输入输出和转移规则都由程序预先写好，每个节点只完成固定职责，整体仍是工作流。
8. 因为同意仍是模型输出，不是外部证据。 两个 Agent 可能共享同一份错误材料和同一种判断盲点；核验还要重新计算、打开原始来源或对照已知标准。
9. 并行改变的是等待方式。 从开始到完成的实际等待时间可能接近最慢分支加协调时间，但每个分支的模型用量、工具调用、重复工作和合并处理仍会累计。
10. 不必。 多 Agent 可以在同一个应用内由运行系统直接编排，也可以通过专有接口或 A2A 跨边界协作。MCP Server 主要提供被调用的能力；除非它在系统里另有独立 Agent 职责和循环，否则不自动算子 Agent。

上一章：第 8 章　MCP 与 A2A：调用外部能力，还是委托远端任务 下一章：第 10 章　可靠性：九十分的评测为什么跑不出九十分