中文译本。原文见同目录 README.md

第 7 课：多智能体系统（Multi-Agent Systems）——当一个智能体不够用时

引言

到目前为止，本课程聚焦于构建单个智能体——一个带工具、记忆与规划循环的 LLM。对许多任务，这种做法非常有效。但随着你想自动化的范围扩大，单个智能体开始吃力：变慢、变糊涂，试图成为所有领域的专家，结果样样稀松。

多智能体系统通过把工作拆给多个专业智能体、并由它们协调达成共同目标来解决这一问题。可以把它想成个人自由职业者与组织良好的团队之间的差别。自由职业者能做很多事，但一群各管一域的专家，能解决单个人无法独自应对的问题。

本课你将学习何时以及为何使用多个智能体、组织它们的主要架构模式、智能体如何通信，以及如何处理分布式系统带来的协调挑战。

为什么使用多个智能体？

单个智能体的局限

一个能访问二十种工具、有超长系统提示、指令覆盖五个不同领域的单个智能体，就像第一天就被塞了五份岗位说明的新人。技术上也许每件事都能做，但同时兼顾会导致错误、变慢与混乱。

考虑拆成多个智能体的具体理由：

单个智能体的问题 多智能体如何帮助
提示变得巨大且难维护 每个智能体拿到聚焦、可管理的提示
工具太多导致选择错误 每个智能体只看到与其角色相关的工具
一次失败拖垮整个工作流 失败隔离在一个智能体；其他继续工作
瓶颈步骤难扩展 可独立扩展单个智能体
难测试与调试 每个智能体可隔离测试
安全上的单点故障 不同智能体可有不同权限级别

ELI5：医院类比

多智能体系统像医院。你带着健康问题走进来，不会遇到一个包办一切的医生——量生命体征、抽血、读 X 光、做手术、再处理账单。相反，你穿过专家体系：分诊护士评估、医生诊断、放射科读片、必要时外科手术、行政处理保险。每个人是自己角色上的专家，并通过共享病历与交接协议协作。

AI 多智能体系统同理。每个智能体是有聚焦角色、自有工具集、以及清晰边界的专家——知道自己处理什么、何时交接。

何时保持单智能体 vs. 走向多智能体

并非每个问题都需要多个智能体。这里有一个简单决策框架：

在以下情况保持单个智能体：

  • 任务定义清晰且范围窄（例如「总结这份文档」）
  • 需要的工具少于 5–7 个
  • 工作流线性且可预期
  • 延迟要求紧（多智能体会增加开销）

在以下情况考虑多智能体：

  • 任务跨越多个领域（例如客服 + 支付 + 合规）
  • 不同步骤需要不同权限级别
  • 希望独立开发、测试与部署各部分
  • 系统需要以不同速率扩展不同能力
  • 需要故障隔离——一部分失败不应拖垮一切

单智能体 vs. 多智能体：街角小店 vs. 百货公司

想象一家由一个人经营的街角小店。店主招呼你、找货、结账、处理退货、补货。对只有零星顾客的小店，这很好用。店主什么都知道、什么都能做。

现在想象同一个人要独自经营一家百货公司。成千上万顾客、几十个部门、复杂库存、专业商品。那会是灾难。百货公司能运转，是因为有专业员工：电子区、服装区、收银员、楼层经理、退货台。每个人角色清晰，通过既定流程协作。

方面 单智能体（街角小店） 多智能体（百货公司）
复杂度处理 适合简单任务 为复杂工作流而生
专业化 样样通 领域专家
失败影响 一切停摆 仅受影响的智能体受冲击
开发速度 原型快 对单个部分迭代更快
协调开销 无 需要显式协调逻辑
简单任务的成本 更低 更高（更多 LLM 调用）

多智能体架构

组织多个智能体主要有四种模式。各有优势，真实系统中常会组合使用。

1. 顺序式（Sequential / 流水线）

在顺序架构中，智能体排成管道。智能体 A 完成工作后交给 B，B 再交给 C，以此类推。每个智能体在传递前转换或丰富输出。

如何工作：

[Agent A] --> [Agent B] --> [Agent C] --> Final Output
 (Research)   (Draft)       (Review)

类比： 想想汽车装配线。一个工位焊车架，下一个装发动机，再下一个喷漆。每个工位做好一件事，车沿流水线前进。

何时使用：

  • 任务有清晰、有序的阶段
  • 每阶段依赖前一阶段的输出
  • 想要简单、可预期的流程

示例： 内容流水线：Research Agent 收集来源，Writing Agent 写出草稿，Editing Agent 审质量与准确性。

优点：

  • 易理解与调试
  • 数据流清晰
  • 易增删阶段

缺点：

  • 速度取决于最慢的智能体
  • 无并行
  • 早期智能体出错会向前传播

2. 分层式（Hierarchical / 经理与工人）

在分层架构中，监督者智能体（「经理」）接收总体任务，拆成子任务，并把每个子任务委派给专业工人智能体。经理收集结果、检查质量，若不满意可重新委派。

如何工作：

              [Manager Agent]
             /       |       \
    [Worker A]  [Worker B]  [Worker C]
    (Search)    (Calculate)  (Draft)

类比： 像公司组织架构图。CEO 不写代码、不报税——他们定方向并委派给部门负责人，后者再委派给团队。CEO 审结果并做最终决策。

何时使用：

  • 任务需要动态分解（无法提前预测子任务）
  • 不同子任务需要不同能力
  • 需要单一协调与质量控制点

示例： 项目管理智能体收到「规划 Q3 产品发布」，把调研委派给一个智能体，时间线给另一个，风险评估给第三个。

优点：

  • 灵活——可处理多样任务
  • 集中质量控制
  • 可并行化子任务

缺点：

  • 经理智能体是瓶颈与单点故障
  • 经理必须足够聪明，能把任务拆好
  • 实现比顺序式更复杂

在 Google Agent Development Kit（ADK） 中，分层模式支持良好。你可以定义把工作委派给子智能体的父智能体，每个子智能体有自己的工具与指令。

3. 协作式（Collaborative / 对等网络）

在协作架构中，智能体以对等身份一起工作。没有老板。智能体共享信息、在彼此工作上推进，并通过沟通收敛到解。

如何工作：

[Agent A] <--> [Agent B]
    ^              ^
    |              |
    v              v
[Agent C] <--> [Agent D]

类比： 像一群同事的头脑风暴。每人贡献想法、回应他人所说，小组收敛到一个计划。没人当头——最好的想法通过讨论浮现。

何时使用：

  • 问题受益于多元视角
  • 没有单个智能体掌握所需全部信息
  • 想要创造性或探索性输出

示例： 代码评审系统：Security Agent、Performance Agent 与 Readability Agent 各自评审同一段代码并分享发现，再协作产出统一评审意见。

优点：

  • 适合没有清晰分解方式的复杂问题
  • 多元视角提升质量
  • 无单点故障

缺点：

  • 行为更难预测
  • 有无限循环或循环讨论风险
  • 更难调试

4. 竞争式（Competitive / 最佳答案胜出）

在竞争架构中，多个智能体独立解决同一问题，由评判者（另一个智能体或评分函数）选出最佳输出。

如何工作：

[Agent A] --\
[Agent B] ----> [Judge] --> Best Output
[Agent C] --/

类比： 像设计竞赛。三家建筑事务所各提交一座新建筑方案。评审团审阅三者并选出最佳。竞赛往往比任何单一事务所独自产出更好的结果。

何时使用：

  • 质量比成本更重要
  • 问题有多种有效方法
  • 想降低坏输出的概率

示例： 三个不同的编码智能体各写一道编程题的解。Judge Agent 跑测试、检查代码质量，并选出最佳实现。

优点：

  • 通过竞争获得更高质量输出
  • 天然有韧性——一个失败，其他可能成功
  • 适合错误代价高的关键任务

缺点：

  • 昂贵（N 个智能体约 N 倍算力）
  • 需要良好的评估机制
  • 若智能体产出相似，则浪费

架构对比小结

架构 流程 最适合 协调复杂度
Sequential（顺序） 线性流水线 有序多阶段任务 低
Hierarchical（分层） 树（经理 + 工人） 动态任务分解 中
Collaborative（协作） 网状（对等） 需要多元输入的复杂问题 高
Competitive（竞争） 并行 + 评判 高风险决策 中

Multi-Agent Architecture Visualizer

Click an architecture to see animated message passing between agents.

通信模式

智能体需要彼此交谈。通信方式塑造系统行为、可调试性与性能。主要有三种模式：

直接消息（Direct messaging）

智能体直接互发消息。智能体 A 知道智能体 B，并向其发送请求。

Agent A --"summarize this document"--> Agent B
Agent B --"here is the summary"--> Agent A

优点： 简单、低延迟、易追踪。 缺点： 紧耦合——A 必须知道 B。添加新智能体需要更新现有智能体。

共享黑板（Shared blackboard）

所有智能体从共享工作区（「黑板」）读写。智能体检查黑板上的新信息，完成工作，再把结果贴回去。

[Blackboard / Shared State]
    ^       ^       ^
    |       |       |
Agent A  Agent B  Agent C

优点： 松耦合——智能体不必彼此知晓。易添加新智能体。适合协作架构。 缺点： 多个智能体写同一区域时可能冲突。更难追踪因果（谁改了什么、为何）。

基于事件（Event-Based）

智能体向消息总线发布事件。其他智能体订阅关心的事件并做出反应。

Agent A --publishes "order_refund_requested"--> [Event Bus]
[Event Bus] --notifies--> Agent B (Payment)
[Event Bus] --notifies--> Agent C (Compliance)

优点： 高度解耦。扩展性好。对做过微服务的工程师很熟悉。 缺点： 要管理更多基础设施。更难调试。最终一致性挑战。

选哪种模式

场景 推荐模式
两个智能体有清晰请求-响应流 Direct Messaging
多个智能体在共享上下文上共建 Shared Blackboard
微服务风格、智能体很多 Event-Based
简单原型 Direct Messaging
大规模生产系统 Event-Based

智能体角色

在设计良好的多智能体系统中，每个智能体都有清晰角色。以下是许多架构中常见的四种角色：

Planner（规划者）

Planner 把高层目标拆成步骤或子任务序列。它决定需要发生什么、以何顺序。

职责：

  • 解释用户目标
  • 分解为子任务
  • 确定子任务间依赖
  • 创建执行计划

示例： 给定「为下个月预订团队团建」，Planner 可能产出：(1) 查团队日历，(2) 找可用场地，(3) 比价，(4) 预订最佳选项，(5) 发日历邀请。

Retriever（检索者）

Retriever 从外部来源——数据库、API、文档、网络——查找信息。它知道数据在哪、如何获取。

职责：

  • 搜索知识库与文档库
  • 查询 API 与数据库
  • 按相关性过滤与排序结果
  • 向其他智能体返回结构化信息

Executor（执行者）

Executor 在真实世界中采取行动。它调用 API、写文件、发邮件或改数据库。它是「做事」的智能体。

职责：

  • 执行 Planner 确定的步骤
  • 调用外部 API 与工具
  • 处理错误与重试
  • 回报结果

Evaluator（评估者）

Evaluator 检查其他智能体工作的质量。它验证正确性、安全性与完备性。

职责：

  • 对照需求验证输出
  • 检查错误、幻觉或策略违规
  • 打分并决定是否需要重做
  • 提供改进反馈

真实示例演练：客户退款系统

我们来走一遍电商公司处理客户退款的具体多智能体系统。该示例使用分层架构与四个专业智能体。

智能体

智能体 角色 工具 权限
Customer Agent Planner + 界面 客户查询、订单历史 读客户数据
Payment Agent Executor 退款 API、支付网关 处理最高 $500 的退款
Compliance Agent Evaluator 策略库、欺诈检测 只读访问
Resolution Agent Manager / Orchestrator 无（协调其他智能体） 可委派给所有智能体

流程

场景： 客户写信说「我从未收到订单 #12345，我想退款。」

步骤 1：Resolution Agent 接收请求

Resolution Agent 是入口。它阅读客户消息，决定需要哪些智能体参与。

Resolution Agent thinks:
"This is a refund request for a missing order. I need to:
1. Verify the customer and order details
2. Check compliance with refund policy
3. Process the refund if approved"

步骤 2：Resolution Agent 委派给 Customer Agent

Resolution Agent 请 Customer Agent 查询客户与订单。

Resolution Agent -> Customer Agent:
"Look up order #12345 and provide the order details,
delivery status, and customer history."

Customer Agent 查询订单库，发现订单 #12345 标记为「已发货」，但物流显示从未妥投。它把信息返回给 Resolution Agent。

步骤 3：Resolution Agent 委派给 Compliance Agent

拿到订单详情后，Resolution Agent 请 Compliance Agent 检查退款是否合适。

Resolution Agent -> Compliance Agent:
"Order #12345, $89.99, shipped but never delivered.
Customer has 2 prior refund requests in the last year.
Is a refund appropriate per our policy?"

Compliance Agent 检查退款策略，确认这不是欺诈模式，并回复退款获批——客户在策略限额内，承运商也确认了配送失败。

步骤 4：Resolution Agent 委派给 Payment Agent

有合规批准后，Resolution Agent 指示 Payment Agent 处理退款。

Resolution Agent -> Payment Agent:
"Process a refund of $89.99 to the original payment
method for order #12345. Compliance approved."

Payment Agent 调用支付网关 API，处理退款，并返回含退款交易 ID 的确认。

步骤 5：Resolution Agent 回复客户

Resolution Agent 汇总结果，生成面向客户的退款确认回复。

为何这种设计有效

  • 关注点分离： 每个智能体管一个领域。Payment Agent 从不碰客户数据。Compliance Agent 从不处理支付。
  • 安全： Payment Agent 有退款权限，但上限 $500。更大退款需人工批准。Customer Agent 可读数据但不能改。
  • 故障隔离： 若支付 API 宕机，Compliance 与 Customer 仍可工作。系统可排队退款稍后重试。
  • 可测试性： 可独立测试每个智能体。Compliance Agent 是否在客户近期索赔过多时正确拒绝退款？可完全不涉及支付来测。
  • 可审计性： 每次委派与响应都有日志。有清晰轨迹说明谁决定了什么、为何。

用 Google ADK 构建

Google Agent Development Kit（ADK） 为多智能体模式提供内置支持。你可以把智能体定义成带自有指令、工具与子智能体的类。ADK 处理智能体间消息传递，并提供追踪以便调试。

对于遵循可预期模式的工作流智能体（如我们的顺序合规检查），ADK 提供带内置顺序、并行与循环构造的 workflow agents。

协调挑战

多智能体系统是分布式系统，而分布式系统有单智能体系统没有的失败模式。以下是最常见的协调挑战及应对方式：

死锁（Deadlocks）

是什么： 两个或多个智能体彼此等待对方完成，于是毫无进展。

示例： 智能体 A 等 B 的输出才能继续。B 等 A 的输出才能继续。谁都动不了。

如何预防：

  • 尽量设计单向数据流
  • 为所有智能体间通信加超时
  • 用中央编排器检测并打破环
  • 实现超时后优雅失败的熔断器

循环委派（Circular delegation）

是什么： A 委派给 B，B 又委派回 A，形成无限循环。

示例： Planner Agent 请 Research Agent 要信息。Research Agent 觉得需要更多上下文，请 Planner 澄清。Planner 没有新信息，又再问 Research。永远循环。

如何预防：

  • 设定最大委派深度（例如单个任务交接不超过 3 次）
  • 追踪委派历史，拒绝会形成环的请求
  • 给智能体清晰边界：自己处理什么 vs. 升级给人类

冲突动作（Conflicting actions）

是什么： 两个智能体独立对同一资源采取矛盾动作。

示例： Pricing Agent 根据竞品分析把产品定价为 $49.99。同时 Promotions Agent 为闪购把同一产品定为 $29.99。最终价格取决于谁后写入。

如何预防：

  • 对共享资源使用锁机制
  • 指定单一智能体为每个资源的所有者
  • 实现冲突解决智能体或策略
  • 使用事件溯源，使所有变更可追踪、可回滚

资源争用（Resource contention）

是什么： 多个智能体竞争有限资源（API 速率限制、token 预算、数据库连接）。

示例： 十个智能体同时调用同一外部 API，触发速率限制，导致全部失败。

如何预防：

  • 在系统层实现限流与排队
  • 使用带公平调度的共享资源池
  • 给关键智能体更高的共享资源优先级
  • 监控资源使用并为每个智能体设预算

状态不一致（Inconsistent state）

是什么： 智能体对世界有不同视图，因为共享状态更新尚未传播到所有人。

示例： Customer Agent 查库存并告诉客户有货。同时 Fulfillment Agent 刚卖掉最后一件。客户收到确认，但商品已不可用。

如何预防：

  • 对共享状态使用单一事实来源
  • 用版本号实现乐观锁
  • 设计智能体优雅处理过期数据（行动前再检查）
  • 把不一致窗口尽量压小

多智能体系统设计原则

基于上述模式与挑战，应遵循以下关键原则：

1. 从简单开始

从单个智能体开始。只有碰到明确限制时再增加智能体。过早拆成多个智能体只会增加复杂度而无收益。

2. 定义清晰边界

每个智能体应有明确定义的范围、自有工具，以及清晰规则：自己处理什么、传给谁。模糊边界导致重复与冲突。

3. 为失败而设计

假设任何智能体随时可能失败。使用超时、重试、熔断与回退。设计良好的多智能体系统会优雅降级，而不是整体崩溃。

4. 让通信可观测

记录智能体间的每条消息。调试问题时你会需要这些日志。若无法追踪请求在系统中的完整路径，坏了就修不好。

5. 限制智能体自主权

每个智能体应只有所需的最小权限。Payment Agent 不应能读客户邮件。Customer Agent 不应能处理退款。这限制了智能体行为异常时的爆炸半径。

6. 把人类当作熔断器

对高风险决策，纳入 human-in-the-loop 步骤。智能体擅长处理常规情况。人类应处理例外、边界情况与后果重大的决策。

动手练习

为下列场景之一设计多智能体系统。对你选择的场景，定义：

  1. 智能体及其角色
  2. 架构模式（sequential、hierarchical、collaborative 或 competitive）
  3. 通信模式（direct、blackboard 或 event-based）
  4. 至少两个潜在协调挑战及你的缓解策略

场景 A：自动化代码评审 一个评审 PR 的代码质量、安全漏洞、性能问题与风格合规的系统。

场景 B：旅行预订助理 帮助用户规划并预订旅行——航班、酒店、租车与活动——同时控制在预算内的系统。

场景 C：内容审核流水线 在发布前审核用户生成内容是否违规、垃圾信息、虚假信息与有害内容的系统。

关键要点

  • 多智能体系统把工作拆给专业智能体，各自有聚焦职责、工具与权限。
  • 主要有四种架构模式：顺序（流水线）、分层（经理-工人）、协作（对等网络）、竞争（最佳答案胜出）。按任务结构选择。
  • 通信模式——直接消息、共享黑板、基于事件——决定智能体耦合有多紧。
  • 常见角色（Planner、Retriever、Executor、Evaluator）为设计系统提供起始词汇。
  • 死锁、循环委派、冲突动作等协调挑战，才是多智能体系统真正的工程问题。从一开始就要为它们设计。
  • 从单个智能体开始，只在需要时增加复杂度。最好的多智能体系统是能解决问题的最简单那个。

延伸阅读

下一课： Agentic RAG