多智能体系统
概述
多智能体系统（MAS）由多个自主智能体组成，这些智能体相互交互、协作，共同解决单个智能体无法独立完成的复杂问题。
（来源：LangChain）
核心特征
分布式智能
- 去中心化决策：每个智能体自主做出决策
- 专业化能力：智能体承担特定角色并具备相应专业知识
- 协作解决问题：智能体协力朝共同目标推进
- 涌现行为：系统级智能从智能体的交互中涌现
通信与协调
- 消息传递：智能体之间交换信息和请求
- 协商协议：智能体就资源分配与任务指派进行协商
- 共识机制：智能体就共同决策达成一致
- 协调策略：智能体同步各自的行动
架构模式
层级组织
Manager Agent
├── Specialist Agent A
├── Specialist Agent B
└── Coordinator Agent
├── Worker Agent 1
└── Worker Agent 2
优势： - 命令结构清晰 - 任务委派高效 - 组织可扩展性强
点对点网络
Agent A ←→ Agent B
↕ ↕
Agent C ←→ Agent D
优势： - 故障容错性高 - 分布式处理 - 无单点故障
黑板架构（Blackboard Architecture）
Shared Knowledge Space (Blackboard)
↑ ↑ ↑
Agent A Agent B Agent C
优势： - 共享信息访问 - 异步协作 - 智能体参与方式灵活
实现框架
AutoGen（Microsoft）
- 对话式智能体：多智能体聊天系统
- 基于角色的设计：智能体角色专业化
- 人在回路（HITL）：人机协作互动
import autogen
# Define agents with specific roles
user_proxy = autogen.UserProxyAgent("user_proxy")
assistant = autogen.AssistantAgent("assistant")
critic = autogen.AssistantAgent("critic")
# Create group chat
groupchat = autogen.GroupChat(
agents=[user_proxy, assistant, critic],
messages=[],
max_round=10
)
CrewAI
- 基于角色的智能体：明确定义角色与职责
- 任务管理：结构化任务分配与执行
- 流程编排：工作流管理
from crewai import Agent, Task, Crew
# Define specialized agents
researcher = Agent(
role='Researcher',
goal='Gather comprehensive information',
backstory='Expert in information gathering'
)
writer = Agent(
role='Writer',
goal='Create engaging content',
backstory='Skilled content creator'
)
# Create crew with agents and tasks
crew = Crew(
agents=[researcher, writer],
tasks=[research_task, writing_task]
)
LangGraph
- 基于图的工作流：可视化工作流表示
- 状态管理：智能体间共享状态
- 条件逻辑：动态工作流路径
通信协议
消息类型
- 通知（Inform）：分享信息，无需对方回应
- 请求（Request）：请求执行操作或提供信息
- 提议（Propose）：建议某一行动方案
- 接受/拒绝（Accept/Reject）：对提议作出回应
- 查询（Query）：询问智能体状态或能力
协调机制
- 合同网协议（Contract Net Protocol）：竞标任务分配
- 共识算法（Consensus Algorithms）：分布式达成一致
- 市场机制（Market Mechanisms）：基于经济的协调
- 投票系统（Voting Systems）：民主决策
应用场景
软件开发
- 代码审查团队：多个智能体分别审查不同层面
- 测试自动化：专业化测试智能体
- 文档生成：协作式内容创作
业务流程自动化
- 客户服务：路由与专项处理
- 供应链管理：分布式优化
- 财务分析：多视角评估
研究与分析
- 文献综述：并行信息收集
- 数据分析：专业化分析智能体
- 报告生成：协作式综合输出
设计考量
智能体专业化
- 领域专业知识：智能体聚焦于特定领域
- 能力互补性：智能体具备不同的优势
- 角色清晰度：职责与边界定义明确
可扩展性
- 动态创建智能体：按需增加智能体
- 负载分发：在智能体间均衡工作量
- 资源管理：高效利用资源
故障容错
- 冗余：为关键功能配置多个智能体
- 优雅降级：系统在能力受限时仍可持续运行
- 恢复机制：自动错误恢复
最佳实践
系统设计
- 清晰的角色定义：每个智能体应有明确的职责范围
- 最小耦合：降低智能体之间的依赖
- 标准接口：采用一致的通信协议
- 监控与日志：追踪智能体交互与性能
实现
- 从简开始：先构建基础的多智能体交互
- 迭代开发：逐步增加复杂度与智能体数量
- 测试策略：分别测试单个智能体与系统整体交互
- 性能优化：监控并优化系统性能
挑战与应对
常见挑战
- 协调开销：管理智能体交互的成本
- 冲突解决：处理智能体之间的分歧
- 可扩展性上限：智能体数量增多时的性能下降
- 调试复杂度：在分布式系统中追踪问题
应对方案
- 高效协议：采用轻量级通信机制
- 冲突解决策略：实现协商与仲裁机制
- 层级组织：通过结构化智能体降低复杂度
- 全面日志：详细追踪智能体活动
多智能体系统的四个平面（AWS）
AWS 将多智能体系统划分为四个独立平面，每个平面承担明确的职责：
| 平面 | 职责 | AWS 服务 |
|---|---|---|
| 控制平面 | 编排者分解任务、委派给子智能体、监控进度、综合结果。只负责指挥，不直接执行。 | Amazon Bedrock Multi-Agent Collaboration（主管模式）、AWS Step Functions |
| 执行平面 | 独立的专业智能体，各自拥有范围受限的系统提示词、精选工具集和专属检索语料库。可独立部署、评测和扩展。 | Amazon Bedrock AgentCore、AWS Lambda |
| 状态平面 | 共享信息层：任务状态（持久化）、会话上下文（低延迟）、领域知识（检索式）。智能体通过状态协调，而非直接耦合。 | Amazon DynamoDB、Amazon ElastiCache、Amazon Bedrock Knowledge Bases |
| 能力平面 | 通过 MCP 服务器暴露工具——标准化、可发现、可治理。在智能体间共享，并在服务器层面实施各智能体的访问控制。 | Amazon MCP Servers、Amazon Bedrock AgentCore、AWS Lambda |
何时迁移至多智能体
以下四个信号表明单智能体工作流已难以为继：
| 触发条件 | 说明 |
|---|---|
| 上下文饱和 | 复杂的长流程任务超出单个上下文窗口的容量，智能体会遗忘早期内容却浑然不知。 |
| 任务专业化 | 单个智能体同时应对多个领域，导致全面平庸而非在某一领域卓越。 |
| 延迟与并行化 | 顺序执行不必要地拖慢速度，独立子任务本可并行处理。 |
| 故障隔离 | 单个智能体失败会拖垮整个工作流；多智能体系统可将故障局部化——一个智能体宕机不影响其余智能体。 |
经验法则：当单智能体工作流同时出现上述四个触发条件中的任意两个，即应迁移至多智能体架构。
编排模式
以下四种模式各自适用于不同的任务结构：
| 模式 | 适用场景 | AWS 实现方案 | 注意事项 |
|---|---|---|---|
| 集中式编排 | 需要动态规划与实时适应的复杂开放性任务 | Amazon Bedrock Multi-Agent（主管模式） | 编排者是单点故障——需重点投入 |
| 基于技能的分发 | 由推理智能体调用的固定、参数化操作集合 | AWS Lambda 函数，通过 MCP 服务器接口暴露 | 对开放性任务灵活性不足；最适合已知的稳定操作 |
| 交接链 | 每一步依赖上一步输出的线性顺序流水线 | Step Functions 状态机配合 Choice 状态 | 刚性较强——若不精心设计 Choice 状态，分支逻辑会变得难以管理 |
| 并行扇出与综合 | 多领域任务中，独立专家分析可并行执行 | Amazon EventBridge + Amazon SQS + Lambda 专家智能体 | 综合步骤常被低估——需显式处理冲突结果 |
规模化下的不确定性
不确定性会跨智能体边界叠加。假设每个智能体准确率为 90%：
| 流水线深度 | 复合准确率 |
|---|---|
| 1 个智能体 | 90% |
| 2 智能体流水线 | 81% |
| 4 智能体流水线 | 66% |
若每个智能体准确率达 99%，4 智能体流水线可达 96%。单个智能体的质量必须远高于可接受的整体错误率。
应对误差传播的三道防线：
- 每个边界使用结构化 Schema——在每次交接时要求经过 JSON Schema 校验的输出。智能体间自由格式的散文传递是一种缺陷。
- 弃权作为特性——对某项任务不确定的智能体应返回结构化弃权响应，而非低置信度的猜测。需在黄金数据集中显式构建并评测弃权行为。
- 端到端评测（不可省略）——单智能体评测必要但不充分，必须运行完整工作流评测。Builtin.GoalSuccessRate 衡量的是系统级成功，而非单智能体输出质量。
共享状态与交接设计
各类数据的存储建议：
| 存储 | 延迟 | 适用场景 | AWS 服务 |
|---|---|---|---|
| 任务状态 | 个位数毫秒读取，能在智能体失败后留存，有审计记录 | 持久化工作流执行状态 | Amazon DynamoDB |
| 会话上下文 | 亚毫秒访问，TTL 管理 | 对话轮次 + 近期访问的载荷 | Amazon ElastiCache |
| 领域知识 | 向量检索，治理管控 | 跨智能体共享，无重复存储 | Amazon Bedrock Knowledge Bases |
| 中间结果 | 成本低廉，持久化 | 由 DynamoDB 中的任务状态记录引用，不在载荷中转发 | Amazon S3 |
交接载荷原则：只包含下一个智能体所需的内容，不多传一字。冗长的载荷会撑大上下文窗口、降低推理质量。
多智能体系统中的 MCP 与 A2A
| 协议 | 接口 | 模式 | 规则 |
|---|---|---|---|
| MCP | 智能体 → 工具 | 客户端-服务器；智能体始终是客户端，工具服务器始终是响应方 | 访问控制必须在服务器层面实施——不能依赖系统提示词 |
| A2A | 智能体 → 智能体 | 对等协议；任何智能体均可发起或接收 | 不要将 MCP 用于智能体间委托——这是错误的抽象 |
A2A 任务对象包含：描述、上下文、授权资源、预期输出 Schema 和约束条件。智能体卡片（Agent Card）支持动态发现，无需预先集成。
多智能体系统特有的故障模式
| 故障模式 | 说明 | 缓解措施 |
|---|---|---|
| 级联失败 | 一个失败的智能体拖垮整条链路 | Step Functions 中的熔断器可捕获重复失败并路由至降级路径 |
| 编排循环 | 编排者反复循环委派任务，导致无上限的费用累积 | 设置显式步骤计数器、循环检测和强制终止条件；Step Functions 原生支持最大执行时间和步骤数限制 |
| 并行输出冲突 | 并行智能体评估同一配置后得出相反结论 | 综合步骤必须显式解决冲突——不能用通用的"总结"提示词；在安全关键领域，保守结果优先 |
| 交接时上下文损坏 | 格式错误、被截断或语义不一致的载荷导致静默失败 | 在执行前对每个传入的交接载荷进行 Schema 校验；校验失败时向编排者返回结构化错误 |
智能体边界的安全性
零信任原则：将每个智能体边界视为信任边界。在 MCP 服务器、智能体边界和编排层冗余实施安全控制。
| 风险 | 缓解措施 |
|---|---|
| 子智能体权限过大 | 按任务分配最小权限范围的凭证；AWS STS 生成时效性凭证 |
| 提示词注入传播 | 通过 Amazon Bedrock Guardrails 在每个智能体边界过滤内容；将所有来自外部的内容视为不可信，无论经过多少个智能体处理 |
| 载荷中暴露凭证 | 任务对象中禁止传递原始凭证；使用基于 IAM 角色的委托；非 AWS 负载使用 AWS IAM Roles Anywhere |
| 未授权的智能体发现 | 对智能体卡片注册表设置认证要求 |
分布式可观测性
一个一致的 Trace ID——贯穿每个智能体和工具调用的传播——是将日志关联为单一执行图谱的唯一方式。没有分布式链路追踪，根因分析只能靠猜测。
分层评测策略：单智能体（隔离数据集） + 完整工作流（Builtin.GoalSuccessRate） + 差异分析（将单智能体分数与系统级结果相关联）。
多智能体系统的七大优势
来自《掌握多智能体系统》（Galileo，2026），相较于单智能体方案的七项核心优势：
| 优势 | 单智能体局限 | 多智能体解决方案 |
|---|---|---|
| 专业化 | 单一模型处理所有任务，切换领域时丢失上下文 | 专业化智能体各自维护聚焦的上下文，减少幻觉 |
| 验证（正交检查） | 无自我纠错机制；错误时仍充满自信 | 同行评审层：生成 → 逻辑 → 事实 → 安全智能体，捕获初始模型遗漏的错误 |
| 并行处理 | 顺序处理触及时间和上下文限制 | 分发者 + 并行分析智能体 + 聚合者；100 条评论的任务从 20 分钟压缩至 3 分钟 |
| 故障容错 | 单点故障导致一切停摆 | 优雅降级：失败的智能体生成备份或标记供人工审核；已完成的工作得以保留 |
| 动态路由 | 同一模型处理简单 FAQ 和复杂推理 | 按置信度路由：>0.9 全自动；0.7–0.9 提供人工审核选项；<0.7 转至专家或人工 |
| 上下文保留 | 上下文窗口填满后遗忘早期消息 | 独立的记忆智能体 + 一致性检查器，在 50+ 条消息的会话中保持连贯性 |
| 可观测性 | 黑盒——难以判断出错原因 | 单智能体指标、单智能体 A/B 测试、按组件划分的 Token 成本归因 |
Gartner 预测：40% 的智能体 AI 项目将在 2027 年前因可靠性问题而被取消。成功的 60% 将根据实际需求匹配架构。
多智能体系统真正奏效的场景
来自 Galileo 研究，成功落地的实现普遍具备以下三类特征：
- 可并行化的问题——子任务在处理过程中无需通信。每个智能体独立工作，最终聚合结果。
- 读多写少的工作负载——智能体主要消费信息而非修改共享状态，协调复杂度大幅下降。
- 显式协调规则——具有明确交接点、定义好数据格式、交互协议和降级行为的确定性编排。
构建前的检查清单： - 能否将工作拆解为完全独立的任务？ - 智能体是否主要执行读取和分析，而非写入和修改？ - 结果是否可以机械化合并（拼接、投票、平均）？ - 并行处理速度是否值得承担 2–5 倍的成本增加？ - 某个智能体失败是否能与其他智能体隔离？
多智能体系统失效的场景
协调成本的经济学
两个智能体需要一条通信信道，三个需要三条，四个需要六条。协调开销呈二次方增长。三类高影响失效场景：
- 记忆碎片化——智能体 B 需要智能体 A 的输出，但获取的要么太多（昂贵）要么太少（功能断裂）。没有干净的方式只共享相关细节。
- 运营成本倍增——单智能体处理成本 $0.10 的任务，在多智能体系统中可能因上下文共享、交接和重试逻辑而达到 $1.00。
- 写冲突级联——智能体 A 创建一种用户档案结构，智能体 B 创建另一种，智能体 C 调和两者后创建第三种。同一数据出现三种不兼容的表示。
具体成本对比（客户支持）
| 方案 | 耗时 | 成本 | 故障点 |
|---|---|---|---|
| 单智能体（读取工单、搜索文档、查询账户、撰写回复） | 2 秒 | $0.05 | 1 |
| 多智能体（分流 + 研究 + 账户 + 回复 + 编排者） | 3.8 秒 | $0.40 | 5 个智能体，10 个潜在交互缺陷 |
多智能体系统成本高出 8 倍、耗时近两倍，且产生指数级更多的失效路径。
模型演进的挑战
Rich Sutton 的苦涩教训：使用更多算力的通用方法最终胜过专业化结构。多智能体复杂性往往是在弥补当前模型的局限，而这些局限终将消失：
- 上下文窗口太小 → 分散负载（但窗口正在增大）
- 工具调用不可靠 → 创建专用工具调用智能体（但模型正在改进）
- 复杂推理单次无法完成 → 拆分为专家智能体（但新模型已能原生支持）
为 GPT-4 构建的复杂编排层，在 GPT-5 面前往往变得多余。面向删除设计：将编排代码写入独立模块，以便更好的模型出现时可以删除。使智能体边界可合并，让智能体 A（研究）和智能体 B（摘要）日后能合并为一个"研究并摘要"智能体。
决策框架（5 个问题）
构建多智能体系统前，请按顺序回答：
- 更好的提示词工程能解决这个问题吗？ 80% 的情况下，具有良好上下文管理的精心设计单智能体优于多智能体。
- 你的子任务真的相互独立吗？ 真正的独立 = 处理过程中零共享状态。有依赖关系的顺序任务并非并行工作。
- 你能承担成本增加吗？ 预计比单智能体高出 2–5 倍，因为协调开销、重复上下文和重试逻辑都会带来额外消耗。
- 你的延迟容忍度以秒为单位吗？ 每次智能体交接增加 100–500 毫秒，五个智能体可增加 2 秒以上。
- 你有调试基础设施吗？ 多智能体故障需要追踪多条执行路径、共享状态变更和智能体间通信日志。
四种主要架构
1. 集中式：编排者模式
由一个强大的智能体担任中央协调者，负责分配任务、监控进度和综合结果。所有数据流经单一枢纽。
性能特征： - Token 效率：高（无重复工作） - 延迟：较高（顺序协调） - 吞吐量：受编排者容量上限制约 - 上下文：集中于中央智能体
最适合：需要强一致性的简单工作流；需要动态规划的复杂查询（例如 Anthropic 的 Research 智能体派生专业子智能体）。
注意事项：编排者是单点故障，在 10–20 个智能体规模时会成为瓶颈。
Map-reduce 模式：编排者将工作映射到并行智能体，再将其结果归约为单一答案。
2. 去中心化：点对点协调
智能体直接与邻近智能体通信，在无中央协调的情况下做出本地决策。智能从本地交互中涌现。
性能特征： - Token 效率：较低（可能产生重复工作） - 延迟：本地决策延迟较低 - 吞吐量：随智能体数量线性扩展 - 上下文：均匀分布于整个系统
最适合：需要弹性和本地优化的系统；例如企业 HR 系统中福利、薪酬、退休和休假智能体直接协调。
注意事项：协调全局行为有难度；在无中央权威的情况下维护一致性较为困难。
3. 层级式：多层管理
多层监督形成树状结构。上级智能体负责任务规划、分解工作、分配子任务，并协调专家之间的沟通。
性能特征： - Token 效率：中等（层级间存在一定冗余） - 延迟：中等（多跳协调） - 吞吐量：高（并行团队） - 上下文：按层级和团队分段
最适合：能自然分解为子问题的复杂多领域任务；例如设有内容、事实核查和发布团队的新闻聚合平台。Google ADK 是该模式的典型实现。
注意事项：层级间的协调开销增加复杂度，每一层应提供有意义的抽象而非官僚层级。
4. 混合式：战略中枢，战术边缘
将集中式控制与去中心化灵活性相结合。全局决策由中央协调者做出，本地优化通过对等交互实现。
性能特征： - Token 效率：取决于任务分配方式 - 延迟：对全局和本地操作均有优化 - 吞吐量：兼具两种方式的优势 - 上下文：中心侧偏战略，边缘侧偏战术
最适合：需求混合的企业级系统（例如外卖平台：中央编排者处理支付和订单完整性，区域智能体集群处理路由和时效）。
注意事项：复杂度最高；需仔细定义集中化与去中心化区域之间的边界。
架构选型矩阵
| 主要需求 | 最优架构 |
|---|---|
| 简单工作流，强一致性 | 集中式 |
| 弹性，本地优化 | 去中心化 |
| 复杂领域，团队结构 | 层级式 |
| 需求混合的企业系统 | 混合式 |
架构决策因素
- 一致性要求：需要所有智能体完美同步 → 集中式；智能体可接受略微过时的数据 → 去中心化。
- 规模发展轨迹：3–5 个智能体 → 集中式；数月内扩展至几十到几百个 → 层级式或混合式。
- 团队结构：层级汇报关系清晰 → 层级式；扁平化组织 → 点对点。
- 问题分解方式：完全独立的块 → 去中心化；任务之间相互依赖 → 集中式或层级式。
多智能体架构的框架对比
| 框架 | 核心优势 | 最适合 |
|---|---|---|
| LangGraph | 有向图建模、跨轮次持久记忆、完整状态追踪、支持条件流 | 需要状态管理的复杂工作流；层级式和混合式模式 |
| Agno | 约 2μs 智能体创建、约 3.75 KiB 内存占用、多模态支持、极低资源消耗 | 高性能、高吞吐量操作（如 500 个并发股票分析智能体） |
| Mastra | 原生 TypeScript、兼容现有 REST API、基于图的工作流、无需独立 AI 基础设施 | Web 应用和 TypeScript 项目 |
| CrewAI | 预定义智能体人设、配置简洁、集中式编排、角色行为一致 | 基于角色的协作与快速原型开发 |
| Google ADK | 灵活编排（顺序/并行/循环）、层级式组合、内置评测框架、Vertex AI 集成 | GCP 上的多智能体系统；新闻聚合、内容流水线 |
| AWS Strands | 模型驱动方式、原生 MCP 支持、A2A 协议用于智能体发现 | AWS 上的生产级智能体；代码现代化系统 |
框架选择意味着架构决策：LangGraph 适合层级式和混合式；CrewAI 适合集中式；Agno 适合去中心化高吞吐量；Mastra 适合混合式的 Web 集成系统。
主管模式与蜂群模式：直接对比
Arsanjani & Bustos（2026）将两种主要任务委派框架形式化为一个设计选择轴：
| 特征 | 主管架构（集中式） | 蜂群架构（去中心化） |
|---|---|---|
| 控制流 | 层级式；单一编排者向工作者委派任务 | 点对点；智能体从共享看板中自选任务 |
| 协调 | 显式且自上而下；主管管理工作流 | 涌现且自下而上；源于智能体的本地交互 |
| 模块化 | 高；专家智能体可在主管下添加或替换 | 高；智能体可加入或移出蜂群 |
| 核心优势 | 可预测性强，监督清晰，易于治理和调试 | 弹性强，无单点故障，水平可扩展 |
| 核心缺陷 | 主管是单点故障和潜在瓶颈 | 难以调试；治理与合规执行困难 |
| 最适合 | 逻辑清晰、顺序明确的受监管工作流（金融、医疗） | 创意任务、内容流水线、动态环境 |
实施建议：企业场景中优先采用主管架构。对弹性要求高于可预测性的子团队，引入蜂群模式。许多生产系统采用混合方式：主管管理业务流程，但将部分块委托给自组织的 Crew。
智能体路由器模式
智能体路由器（Agent Router）是主管架构的基础构建块。它并非硬编码的条件路由，而是采用：
- 语义意图提取——一个具有严格 Schema 的 LLM 将用户查询转换为包含动作（动词）和资源（名词）的结构化
RoutingIntent对象 - 能力图谱查找——一个图将
(action, resource)元组映射到智能体名称；若无匹配则拒绝请求
这种方式将提取层与智能体名称解耦，允许新智能体注册而无需修改路由逻辑，并将图谱用作安全白名单，防止路由到无能力的智能体。
多智能体模式的事件驱动实现（Confluent）
Confluent 的《智能体与多智能体系统的事件驱动设计指南》（2025）将智能体重新定位为与微服务类似的角色，并主张：从紧耦合的请求/响应式微服务向事件驱动架构（EDA）的转变，同样应适用于多智能体协调。将上述模式对应来看：
- 集中式 / 编排者-工作者：编排者不再直接连接每个工作者，而是向 Kafka 主题发布带键的命令消息。工作者智能体组成消费者组，从分配的分区中拉取消息；有状态序列跨消息复用同一键，确保落到同一工作者。Kafka 消费者重平衡协议会在工作者增减时自动重新平衡负载，失败的工作者通过从上次保存的偏移量回放日志进行恢复——无需编排者自行实现复杂的故障处理逻辑。
- 层级式：编排者-工作者的分解方式递归应用，每个非叶节点对自己的子树充当编排者。智能体通过跨层级的事件流发布/订阅，而非依赖直接的监督引用，因此可以在不修改核心逻辑的情况下增减层级。
- 黑板（Blackboard）：共享知识库实现为 Kafka 主题；智能体将更新作为事件发布，其他智能体只订阅与自己相关的更新，避免了直接查询共享数据库的同步瓶颈。
- 基于市场的模式 （上述四种架构之外的第五种协调模式）：智能体以事件形式发布买入/卖出报价；做市服务对其进行匹配并异步执行交易。这将 O(n²) 的直接点对点协商替换为通过单一中央事件日志的交互——这是高吞吐量场景（如实时金融交易智能体）的底层模式。
完整的逐模式对比（传统方式 vs. 事件驱动方式，以及 SDR 和 Agentic RAG 实战示例）见 多智能体系统的事件驱动设计模式（Confluent）。
多租户多智能体系统（Google Cloud）
Google Cloud 针对多租户智能体 AI 系统的参考架构，解决的是与上述模式正交的一类协调问题：单套已部署的多智能体系统如何同时服务多个相互隔离的租户（客户、业务单元或环境），并避免跨租户数据泄露或"嘈杂邻居"导致的资源争抢。
参考组件： - 计算层：Cloud Run 用于无状态、按请求调用智能体，内置每租户并发限制；GKE 适合需要更细粒度隔离的工作负载（专用节点池、命名空间，或——按照 Kubernetes Agent Sandbox 的说法——每次工具调用的沙箱隔离执行）。 - 智能体平台：Gemini Enterprise Agent Platform 提供租户范围的智能体注册表与路由，使同一编排者部署能够为不同租户提供各自独立的智能体阵容。 - 安全边界：Model Armor 部署在模型调用的前端，作为感知租户的策略执行点——在提示词和响应跨越租户边界之前，对提示词注入、数据泄露和策略违规进行筛查。 - 智能体构建与互操作：使用 Google ADK 构建每租户或共享智能体，并以 A2A 协议实现跨智能体（以及在明确授权时跨租户）通信。
该架构中描述的租户隔离策略与 四个平面 的框架相互呼应——身份/认证、数据、计算和控制平面隔离各自都需要租户范围的决策——但 Google 的方案专注于"一套部署，多个租户"，而非"一个租户，多个智能体"。两者可以组合使用：多租户部署中，每个租户的智能体阵容仍需要一套内部多智能体架构（集中式、去中心化、层级式或混合式）。
参见
- 多智能体系统的事件驱动设计模式（Confluent）
- 智能体开发框架
- FreePHDLabor — 以 ManagerAgent + 专用工作者组成的层级式多智能体科学研究自动化框架
- 架构组件选型
- 12-Factor Agents
- 上下文工程
- AWS AgentCore
- A2A 协议
- MCP 协议
- Kubernetes Agent Sandbox
- 生产最佳实践 / 部署
- 生产最佳实践 / 安全
- 生产最佳实践 / 可观测性
参考资料
- AWS Marketplace — 构建智能体系统：多智能体架构（模块 4） — 研讨会幻灯片，涵盖四个平面、编排模式、不确定性数学、共享状态设计、MCP/A2A 区别、智能体边界安全以及分布式可观测性
- 掌握多智能体系统电子书 — Galileo，2026。作者：Pratik Bhavsar。涵盖七大优势、故障模式、决策框架、四种架构、上下文工程以及使用 Galileo 可观测性平台的 LangGraph 生产示例。
- Multi-tenant agentic AI system architecture — Google Cloud Architecture Center。使用 Cloud Run、GKE、Gemini Enterprise Agent Platform、Model Armor、ADK 和 A2A 从单套多智能体部署服务多个租户的参考架构。
- Arsanjani, A., & Bustos, J.P. (2026). Agentic Architectural Patterns for Building Multi-Agent Systems. Packt Publishing. ISBN 978-1-80602-957-0. — 主管模式与蜂群模式对比及智能体路由器模式的来源。