ai-agent教程-08-多智能体协作

本章目标:讲清「为什么需要多个 Agent」、协作的四种拓扑、通信与编排的工程细节、以及 A2A 协议;最后给出一个被反复验证的忠告:什么时候不该用多智能体。

1. 为什么需要多个 Agent

一个 Agent 就能做很多事,为什么还要多个?三个真实动机:

能力隔离与专业化。一个 Agent 拥有全部工具与全部提示词,容易「上下文打架」。拆成「研究员」「写手」「审查员」,每个 Agent 的系统提示与工具集高度定制, 质量和成本都可控。
并行提速 。调研 10 个话题,10 个 Agent 同时干,理想上限接近串行的 10 倍 (实际要扣除协调开销与 token 成本,见本章 §6)。
多视角提升质量。让两个 Agent 互相辩论、批评,能显著降低幻觉与偏见------ 「对手方意见」的价值在大模型时代同样成立。

但要冷静:多 Agent 的代价是真实且昂贵的------ 协调开销、额外的模型往返(token 成本翻倍)、更多失败点、更难的调试。所以本章最后一节给「反模式」留了重要篇幅。

2. 协作拓扑(四种基本形态)

2.1 编排者-工作者(Orchestrator-Worker)

scss 复制代码

                    ┌─► worker(research)
[leader] ──拆解──►  ├─► worker(write)
  │                 └─► worker(review)
  └───────汇总────────┘

谁:一个 leader(或「CEO」)负责拆解、分派、汇总;多个 worker 各司其职;
通信:leader 与 worker 点对点;必要时黑板共享;
优点:结构清晰、责任明确、天然支持并行;
缺点:leader 是单点(失败全挂,需重试);每次拆解/汇总多一次模型往返;
适用:任务可分解、子任务彼此相对独立。

mini-agent 的 Orchestrator(src/multiagent/team.ts)就是这个模式, 第 07 章已走读。它的一个工程细节值得记住:worker 失败不拖垮团队------ catch 后标记 failed 继续,让 leader 在汇总时看到失败信息。

2.2 辩论/批评(Debate & Critique)

css 复制代码

[A] 提出观点 ⇄ [B] 反驳
        ↘        ↙
      [裁判/共识]

谁:两个或多个 Agent 就同一问题提出并反驳观点;或一个 Agent 生成、另一个 Agent 批评;可加裁判汇总;
通信:多轮消息交换,观点与反驳相互引用;
优点:显著降低幻觉与单点偏见,提升推理质量;
缺点:token 成本成倍增加;辩论可能跑偏(需要收敛机制);
适用:重要决策、事实核查、内容审查。

工程要点 :辩论要限轮数 (如最多 3 轮)和设收敛规则(由裁判或规则终止)。无限辩论是常见的失控模式。

2.3 流水线(Pipeline)

css 复制代码

[A 调研] → [B 写作] → [C 审查] → [D 发布]

谁:每个 Agent 只做上游给它的产物,完成后交给下游;
通信:单向传递产物;
优点:最简单,像工厂流水线;每步可独立替换与测试;
缺点:串行(慢);上游错误会污染下游;
适用:内容生产、数据处理、发布流程。

2.4 市场/群体智能(Marketplace / Swarm)

大量 Agent 各自行动,通过某种「市场机制」或「涌现协调」达成整体目标, 没有显式的中央协调者。

优点:高扩展、去中心化、对动态环境鲁棒;
缺点:难预测、难调试、容易失序;
适用:研究探索、大规模并行搜索;生产环境较少见。

2.5 主流多 Agent 框架对比

四种拓扑是思想 ,框架是实现。2026 年的主流框架基本都能映射回 §2.1--§2.4 的某种拓扑------所以选框架前,先用拓扑想清楚「协作长什么样」, 再落到具体产品。第 06 章 §8 从「单 Agent harness」视角做过横向对比; 这里换一个维度,只看它们的多 Agent 协作能力:

框架	协作范式	状态管理	生产成熟度	与 A2A 结合
AutoGen / AG2	对话式 GroupChat:一组 Agent + 发言者选择,多轮自由对话	弱(对话历史即状态)	中高(历史贡献大;但品牌分裂------原版维护模式、AG2 社区分支、Microsoft Agent Framework 另起炉灶)	部分
CrewAI	角色化团队:role/goal/backstory + 任务依赖流转	轻量任务状态	中(上手最快,约 20 行跑通 demo)	原生
LangGraph	状态图:节点 / 边 / State,编排逻辑显式化	强:显式 State + 检查点 + 断点续跑	高(企业级控制力最强)	部分
OpenAI Agents SDK	Agent 循环 + handoff(交接即调用 transfer 工具)+ 三层护栏	中(会话交接;状态模型弱于 LangGraph)	中(OpenAI 绑定)	部分
Claude Agent SDK	深度自主 + 子 Agent 上下文隔离 + 生命周期钩子	中(子 Agent 隔离上下文 + token 归因)	中高(MCP 生态最深)	无
Google ADK	多 Agent 编排,面向跨模型 / 跨协议互操作	中	中	覆盖最全(MCP / A2A / ACP)

读表的三个视角:

协作范式决定「对话还是流程」:AutoGen 的 GroupChat 偏「自由对话」,适合辩论/批评拓扑(§2.2);LangGraph 偏「显式流程」,适合流水线与编排者-工作者 (§2.1 / §2.3)。自由对话灵活但难收敛,显式流程可控但僵化------没有免费的午餐;
状态管理决定「审计与断点」:需要人工审批、断点续跑、回放审计 → LangGraph 的检查点是杀手锏(第 06 章 §9);只要「跑通 demo」→ CrewAI 最快;
与 A2A 的结合决定「跨组织协作」:要跨公司/跨团队连别的 Agent,优先 CrewAI(原生)与 Google ADK(MCP/A2A/ACP 全覆盖);只在自己的边界内协作, 「与 A2A 结合」这一列可以先不看。

结论要点:

没有全能框架。每个框架都在「控制精度 / 上手速度 / 生态绑定」之间取舍, 第 06 章 §8 那句「没有框架在所有维度赢」在多 Agent 维度同样成立;
选型取决于三个需求 (呼应第 06 章 §9 的决策框架):确定性需求 (流程确定→状态图;不确定→对话式)、绑定模型 (绑 OpenAI→OpenAI SDK, 绑 Claude→Claude Agent SDK)、审计需求(要审计/断点→LangGraph);
多 Agent 框架的共同底层 = 第 07 章 mini-agent 的 MessageBus + Orchestrator。 GroupChat、Crew、StateGraph、handoff,本质都是「结构化消息(§3)+ 编排循环(§4)」的不同封装------你已经在第 07 章亲手实现过它,换框架只是换皮不换里。

工程启示 :框架对比表会过时(2026 年的品牌分裂、0.x 版本每天都在变), 但「拓扑 → 范式 → 状态管理 → 审计」这条选型链不会。把框架当实现细节, 把拓扑与工程问题(§3 通信、§4 编排)当决策主线。

3. 通信:多智能体的「语言」

多智能体的通信需要一套结构化的消息协议,而不是自然语言的自由发挥:

ts 复制代码

// mini-agent: src/multiagent/bus.ts
export interface BusMessage {
  id: string;         // 消息唯一 ID
  from: string;       // 发送者
  to?: string;        // 目标(undefined = 广播)
  kind: string;       // 消息类型(task / result / notice ...)
  payload: unknown;   // 结构化载荷
  timestamp: number;
}

设计要点:

kind 字段:把「任务分派」与「结果汇报」「进度通知」区分开, 接收方按 kind 处理,而不是猜「这段自然语言是什么意思」;
结构化载荷:任务描述、参数、结果用结构化对象而非散文, 减少解析错误;
邮箱 + 历史:点对点用邮箱(不丢消息),广播进历史(黑板共享)。
消息溯源:每条消息带 from/id,便于审计与调试。

通信模式:

点对点:直接派活(leader → worker);
发布-订阅:广播通知(plan、step_done),谁关心谁收;
黑板:共享记忆区,隐式通信(第 02 章 §5.8)。

3.1 通信的可靠性工程:消息会丢、会重、会乱序

生产多 Agent 系统的核心难点不在「消息长什么样」,而在投递语义。四个必须回答的问题:

问题	风险	对策
消息会丢吗?	worker 崩溃、网络闪断	可靠队列(持久化)+ 未确认重投(至少一次)
会重复投递吗?	重投导致任务被跑两次	消费幂等:任务携带 task_id,worker 执行前检查「这个任务是否已做过」(§2.4 状态表的幂等键)
会乱序吗?	后发任务的结果先到	每条消息带 `seq`;结果按 task_id 关联,不依赖到达顺序
会有背压吗?	worker 处理不过来,队列暴涨	队列深度监控 + 限流 + 拒绝新任务(第 12 章 §5.4)

两条工程经验:

「至少一次投递 + 消费幂等」是默认组合。「至多一次」在 Agent 场景几乎不可用(你不知道消息是不是真丢了),而「恰好一次」需要分布式事务,贵且慢;
副作用要可重放:worker 执行了「写库」这类副作用再失败,重投会把副作用跑两遍。要么让副作用幂等(按 task_id 去重),要么把「副作用」从 worker 的失败范围里拆出来(先记录意图,确认成功后再执行)。

4. 编排的工程问题

4.1 谁来拆解?

leader 模型驱动 :leader 用 planner 拆解(第 07 章 Orchestrator 的做法);
代码驱动:任务模板 + 规则拆解,确定性高;
混合:规则兜底,模型增强。

4.2 分派策略

策略	描述	适用
round-robin	轮流分配	无偏好、任务同质
by-role	按角色/关键词匹配	有明显角色分工
能力感知	根据历史成功率分配	长期运行、有反馈
动态竞标	各 Agent 自报能力	市场模式

4.3 结果聚合

简单聚合:把所有 worker 结果拼起来交给 leader 总结;
结构化汇总:要求 worker 返回固定格式(JSON),leader 据此做表格/对比;
共识机制:多 worker 独立解答,投票/对比取优(类似 self-consistency)。

4.4 失败处理

多智能体系统的失败处理比单 Agent 更关键(失败点更多):

worker 失败:重试一次 → 标记 failed → 交给其它 worker / leader 兜底;
leader 失败:整体重试(有状态可断点续跑);
协调死锁:两个 Agent 互相等待 → 超时 + 强制终止;
降级路径:多 Agent 失败时,回退到单 Agent 或人工。

4.5 成本与延迟建模

多智能体是 token 消耗大户。估算一次运行的成本:

scss 复制代码

总 token ≈ Σ(每个 Agent 的 prompt + completion) + 协调消息的上下文重复

一个 5-Agent、每 Agent 3 轮的团队任务,轻松消耗单 Agent 方案的 5--10 倍 token。 成本预算应在架构阶段就做,而不是上线后惊呆。

4.6 多智能体的评测与安全(被低估的两个维度)

多智能体的评测与安全,是比单 Agent 更难、也更容易被跳过的问题。

评测:多 Agent 怎么算「变好了」?

评测层面	问题	方法与工具
单成员评测	每个 Agent 单独表现如何?	按成员分别跑单 Agent 评测(第 10 章)
协作评测	团队整体完成任务了吗?	端到端任务成功率(最终产物质量)
过程评测	分工是否合理、消息是否浪费?	消息数、成员间往返轮数、是否有多余分派
成本评测	协作花了多少 token?	按成员聚合 token 消耗
对比评测	多 Agent 比单 Agent 好在哪?	先跑单 Agent 基线,再对比增量收益------这是第 08 章 §8「先单后多」的量化依据

安全:多 Agent 放大了攻击面

prompt injection 在成员间传播:一个成员被注入,可能通过消息污染其它成员。每个成员都要把「收到的消息」当不可信输入(第 11 章);
权限扩散 :每个成员都有自己的工具与凭证,「最弱成员」就是系统的安全下限------成员的权限要按职责最小化,而不是全员全量;
恶意成员 / 供应链:多 Agent 协作时,一个被攻破或恶意的成员可以拖垮整个团队。对跨组织协作(A2A),「信任对方 Agent」是开放问题 (第 13 章 §4.7);
审计难度:路径更长、决策更多,「谁在哪一步做了什么」更难回溯------ 每个成员都要有 trace,协作要有一条端到端的 trace 串起来。

工程结论 :多 Agent 的评测与安全成本必须计入「是否该用多 Agent」的决策。如果评测与安全都做不齐,单 Agent 往往是更负责任的选择。

5. A2A:Agent 间通信协议

5.1 为什么需要协议

当多 Agent 协作跨组织/跨团队 时,每家都用自己的消息格式是不可持续的。 A2A(Agent2Agent)协议由 Google 于 2025 年提出,同年 6 月捐赠给 Linux 基金会, 2026 年又与 MCP 一并并入 Linux 基金会新成立的 Agentic AI Foundation(AAIF), 旨在为「Agent 之间如何发现、协商、协作、结算」建立开放标准。

5.2 A2A 核心概念

Agent Card:Agent 的「名片」------描述它能做什么、接受什么输入、用什么传输方式;
任务( Task ):Agent 间的协作单元,有状态机(pending → working → completed / failed / input-required / canceled);
消息( Message ):任务上下文里的通信内容;
能力发现:通过 Agent Card 发现其它 Agent 的能力,无需预先集成;
与 MCP 的分工:MCP 是「Agent 连工具」,A2A 是「Agent 连 Agent」。

协议面的最小形态:A2A 是 JSON-RPC(over HTTP/SSE),核心方法让你对另一个 Agent 完成「提交→查询→取消→推送消息」四个动作:

方法	作用
`tasks/send`	提交一个新任务,返回任务 ID 与初始状态
`tasks/get`	查询任务当前状态与进度
`tasks/cancel`	取消一个任务(§5.3 状态机里的 `canceled`)
`message/send`	在任务上下文里推送一条消息(进度、部分结果、补输入)

Agent Card 长什么样(精简版,真实格式是 JSON-LD):

jsonc 复制代码

{
  "name": "物流查询 Agent",
  "description": "查询订单物流、预计送达时间。",
  "skills": [{ "id": "query_logistics", "name": "物流查询" }],
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "defaultInputModes": ["text"],
  "defaultOutputModes": ["text"],
  "security": { "auth": { "schemes": ["apiKey"] } }
}

为什么是 JSON-LD:Agent Card 要能被搜索引擎/目录抓取,让其它 Agent 「无需预先集成」就能发现你------它本质上是一种「可发现的元数据」, 类似网页的 robots.txt + OpenGraph 的合体。

5.3 A2A 任务状态机:协作单元的「生命周期契约」

A2A 最核心的抽象是任务(Task) ------它是跨 Agent 协作的原子单元。每个任务有一条显式的状态机,这比「自由对话」可靠得多,因为双方 (调用方与被调用方)对「现在进行到哪一步」有共同语言:

scss 复制代码

                    ┌──────────► completed
                    │
submitted ──► working ──► input-required ──► working(补齐输入后继续)
   │            │            │
   │            │            └──► canceled(调用方取消)
   │            └──► failed
   └──► canceled(提交后即取消)

状态	含义	谁触发	工程含义
`submitted`	任务已提交	调用方	被调用方收到任务描述,返回任务 ID
`working`	执行中	被调用方	可推送进度/部分消息
`input-required`	需要更多输入	被调用方	调用方补数据后重新提交(典型的「转人工」或「要参数」场景)
`completed`	成功	被调用方	返回最终结果(可多条消息)
`failed`	失败	被调用方	返回错误信息,调用方决定重试/换 Agent
`canceled`	取消	调用方	被调用方收到取消信号,停止执行

三个工程要点:

状态是「谁的消息」由协议保证,不是靠信任。被调用方上报状态、调用方轮询或订阅;双方都以任务 ID 为锚点,不靠自然语言对齐;
input-required 是 A2A 的「人机协作」入口 。当任务卡在需要用户提供信息(授权、参数、选择),被调用方不是失败,而是请求输入; 这与第 12 章 requires_approval 状态的设计思想一脉相承;
超时与取消是必须的 。跨组织调用,被调用方可能失联------ 调用方必须能 canceled,并有「任务超时」策略(第 12 章 §4)。

与 mini-agent 的对照 :mini-agent 的 MessageBus + Orchestrator 是「进程内协作」的教学实现,任务是隐式的(plan step)。A2A 把它「协议化」------任务有 ID、有状态机、可跨进程/跨组织。工程语义是同一套: 通信要结构化,状态要显式,失败要可处理。

5.4 2026 年的格局

MCP 与 A2A 都已在 Linux 基金会治理下,协议化成为行业共识;
框架侧:CrewAI 原生支持 A2A,Google ADK 同时支持 MCP/A2A/ACP;
企业侧:A2A 多用于跨部门/跨公司的 Agent 编排。

读协议规范时注意:协议解决「互操作」,不解决「协调逻辑」。你的编排策略(谁拆解、谁聚合、怎么失败处理)仍然是你的架构责任。

6. 设计一个多 Agent 系统的清单

7. 对照 mini-agent

概念	代码
消息契约	`src/multiagent/bus.ts` `BusMessage`(kind/payload/from/to)
邮箱 + 黑板	`MessageBus.attach/send/broadcast/history`
编排者-工作者	`src/multiagent/team.ts` `Orchestrator`
角色适配	`RoleAgent`(把 Agent 包装成成员)
失败隔离	`Orchestrator.run` catch worker 异常,标记 failed
演示	`node examples/team.ts`

8. 反模式:什么时候不该用多智能体

多智能体是 2024-2026 年最被滥用的概念之一。以下场景通常不该用:

单 Agent + 好工具就能解决------这是最常见的情况。一个 Agent 配 5 个工具, 往往比 3 个 Agent 更便宜、更可靠。
子任务不独立------如果 worker 必须频繁交换中间结果,协调成本会吃掉并行收益。
需要强一致性与审计------多 Agent 的路径更难复现。LangGraph 单图 + 检查点可能更好。
团队刚起步------没有评测基线与可观测性,多 Agent 的故障会淹没你。
延迟敏感------多 Agent 串行(流水线)可能比单 Agent 慢数倍。

经验法则:

先用单 Agent 做出基线,用评测量化瓶颈。当「单 Agent 的上下文过长」或「单一提示词难以兼顾多个职责」成为真实瓶颈时, 再引入多 Agent------而且一次只引入一个拆分。

9. 本节要点

多 Agent 的动机:专业化、并行、多视角------但代价是成本、复杂、难调试;
四种拓扑:编排者-工作者 / 辩论 / 流水线 / 市场,按任务特性选择;
通信需要结构化契约(kind + payload + 溯源),而不是自由自然语言;
编排要解决:拆解、分派、聚合、失败处理、成本建模;
多 Agent 的评测与安全成本必须计入选型:成员分评 + 协作端评 + 先单后多对比;每个成员最小权限、收到的消息当不可信输入;
A2A 协议解决跨组织的 Agent 互操作,与 MCP 分工不同;
worker 失败要隔离(不拖垮团队),leader 失败要可重试;
反模式:能单就单,多 Agent 是「被评测证明必要」之后的选择,不是默认选项;
A2A 任务状态机(submitted→working→completed/failed/input-required/canceled) 是跨 Agent 协作的「生命周期契约」------状态显式、以任务 ID 为锚、超时与取消必须支持。

下一章,讲 Agent 连接世界的最重要协议------MCP。