构建可靠的多智能体编排系统
从核心概念到架构模式，从通信协议到工程落地，系统梳理 Multi-Agent Orchestration 的技术栈、设计取舍与主流框架，帮助你在合适的场景做出合适的选择。
#1. 概览与定义
什么是「多智能体编排」，以及它解决了单智能体难以处理的哪些问题。
智能体 (Agent) 是以 LLM 为推理核心、能够自主调用工具、维护状态、 在循环中朝着目标迭代的程序实体。多智能体编排 (Multi-Agent Orchestration) 则是把一个复杂任务拆分给多个角色或职能各异的 Agent，通过显式或隐式的协议进行通信、分工与协作， 最终汇总产出结果的系统设计方法。
🧠 自主性 Autonomy
每个 Agent 拥有独立的目标、提示词、工具集与决策循环，不依赖中心化的硬编码流程。
🤝 协作性 Collaboration
通过消息、事件、共享状态或交接 (hand-off) 在多个 Agent 之间传递任务和上下文。
🎯 专业化 Specialization
不同 Agent 承担不同角色（规划、检索、写作、审查），降低单个上下文窗口的认知负担。
单智能体 vs 多智能体
| 维度 | 单智能体 (Single-Agent) | 多智能体 (Multi-Agent) |
|---|---|---|
| 认知边界 | 单一上下文窗口承载全部信息 | 每个 Agent 维护独立、精简的上下文 |
| 工具数量 | 工具过多时易选择错误 | 按角色分配工具，决策空间收敛 |
| 并行性 | 串行思考，难以并发 | 子任务可并行处理，整体延迟更低 |
| 可靠性 | 错误累积，难以局部恢复 | 角色隔离 + 审查者，可发现并修正错误 |
| 调试成本 | 提示词复杂，日志难追踪 | 角色边界清晰，但通信链路更复杂 |
| Token 成本 | 低 (单次调用) | 显著更高 (Anthropic 报告 ~15x) |
| 适用场景 | 明确流程、低分支、低风险 | 研究型、探索型、需多视角验证 |
#2. 何时该用多智能体
在引入复杂度之前，先验证它真的能换回收益。
✅ 适合的场景
- 任务可天然拆解为并行子任务（如同时检索多个来源）
- 需要多视角评审（生成 → 审查 → 修订）
- 子任务工具集差异大，单 Agent 工具过载
- 需要角色化输出（PM/Dev/QA 模拟工作流）
- 任务路径不确定，需要动态路由
- 结果价值远高于 Token 成本（深度研究、专家咨询）
⚠️ 不适合的场景
- 流程线性确定，用 Workflow / DAG 更稳定
- 子任务强耦合，需共享大量中间状态
- 对延迟敏感（IM 客服首响 < 1s）
- 预算紧张，Token 成本是关键约束
- 结果需严格一致性（金融交易、合规审批）
- 团队尚未建立完善的可观测性能力
决策光谱：Workflow ↔ Agent
建议沿光谱从左到右渐进式演进，避免一上来就引入最复杂的方案。
#3. 架构模式
六种最常见的多智能体拓扑结构，及各自的取舍。
3.1 Orchestrator-Worker（编排者-工作者）
一个中心 Orchestrator 负责拆解任务、分发给若干 Worker，再汇总结果。最常见、最易实现， Anthropic Research、OpenAI Deep Research 多采用此模式。
(Search)
(Analyze)
(Code)
优点 易控制、易并行、责任清晰。 缺点 Orchestrator 上下文可能膨胀，单点瓶颈。
3.2 Hierarchical（层级式 / Supervisor-of-Supervisors）
多层 Supervisor 嵌套，每层 Supervisor 管理一组下属 Agent。适合大型团队模拟 (MetaGPT) 或 跨业务域的企业级编排。LangGraph 官方推荐用于复杂场景。
优点 关注点分离，可扩展到大规模。 缺点 链路长，延迟高，需要严格的接口契约。
3.3 Sequential / Pipeline（顺序管道）
多个 Agent 串行执行，前一个的输出作为下一个的输入。本质接近 Workflow， 但每个节点保留 LLM 推理能力。CrewAI 默认即为顺序模式。
优点 简单、可预测、便于调试。 缺点 无并行、无回溯，无法应对分支决策。
3.4 Network / Mesh（网状自由协作）
所有 Agent 互相可见、可发起对话，没有中心节点。AutoGen GroupChat 是典型实现。
灵活但难以预测，适合开放式头脑风暴。
优点 灵活、涌现性强。 风险 易陷入死循环、跑题、Token 失控，必须设置终止条件。
3.5 Hand-off / Swarm（交接式）
OpenAI Swarm / Agents SDK 推广的范式：每个 Agent 通过transfer_to_xxx工具
把会话「移交」给另一个 Agent，控制权显式传递。介于 Sequential 与 Network 之间。
优点 路由清晰、上下文随会话流转。 缺点 不天然支持并行。
3.6 Plan-Execute-Reflect（规划-执行-反思）
Planner 制定计划 → Executors 执行 → Critic 反思与修订，循环直至满足。 LangGraph、Devin、Claude Code 的核心循环都是这一模式的变体。
优点 适合开放式、长周期任务，可自我纠错。 风险 反思循环可能不收敛，需限制最大迭代次数。
#4. 关键技术点
把多智能体系统真正跑起来，必须解决的 8 个核心问题。
4.1 通信协议与接口标准
🔌 MCP Model Context Protocol
Anthropic 主导，2024 开源。标准化 Agent ↔ 工具/数据源的连接。 类比「USB-C for AI」。已被 OpenAI、Google、Microsoft 采纳，成为事实标准。
🤝 A2A Agent-to-Agent
Google 2025 提出，标准化Agent ↔ Agent 的发现、协商、任务委派。 基于 JSON-RPC，定义 AgentCard、Task、Artifact 概念。与 MCP 互补。
📨 消息格式
主流：OpenAI Chat Message (role/content/tool_calls)。多 Agent 场景需扩展
name / sender / recipient 字段以区分发言者。
🎫 ACP / ANP 等
IBM ACP、ANP (Agent Network Protocol) 等多个候选协议正在演进， 目前生态尚未完全收敛，建议优先 MCP + A2A。
4.2 上下文工程 (Context Engineering)
多 Agent 系统中，上下文如何在 Agent 间传递是决定成败的核心问题。 Anthropic 与 LangChain 都强调："Context engineering is the new prompt engineering"。
- 压缩 (Compression)：长对话用 summary 替换原始消息；子 Agent 返回结果时只回传"结论 + 关键证据"。
- 隔离 (Isolation)：子 Agent 拥有独立窗口，只接收必要的任务描述，避免无关历史污染。
- 共享黑板 (Blackboard)：所有 Agent 读写一个结构化共享状态（LangGraph 的
State、CrewAI 的shared_memory）。 - 检索式上下文 (RAG over history)：长期任务把历史存入向量库，按需检索而非全量注入。
4.3 记忆系统 (Memory)
| 类型 | 作用 | 实现 | 代表方案 |
|---|---|---|---|
| 短期记忆 (Working) | 当前会话/任务的上下文 | 消息列表 + 滑动窗口 | 所有框架内置 |
| 长期记忆 (Long-term) | 跨会话的事实、偏好 | 向量库 + 语义检索 | Mem0、Zep、Letta (MemGPT) |
| 情景记忆 (Episodic) | 过往任务的成功/失败案例 | 结构化日志 + 检索 | 自建 + RAG |
| 语义记忆 (Semantic) | 领域知识库 | RAG / 知识图谱 | LlamaIndex、GraphRAG |
| 程序性记忆 (Procedural) | 常用流程/技能 | Skill Library、缓存的计划 | Voyager、Claude Skills |
4.4 任务规划与分解
- 静态规划：Planner 一次性产出全部步骤（ReWOO、Plan-and-Solve）。低延迟、易并行，但缺乏适应性。
- 动态规划：每步根据观察结果决定下一步（ReAct）。灵活但慢，token 开销大。
- 树搜索式：LATS、Tree-of-Thought，把规划视为搜索问题，可回溯。
- 分层规划：高层 Planner 出大纲，子 Agent 内部再规划。Devin、Manus 的典型做法。
4.5 工具调用 (Tool Use)
- 原生 Function Calling：依赖模型的 tool_use 能力，需注意 JSON-Schema 设计、参数描述质量。
- MCP Server：把工具封装为独立进程，跨 Agent / 跨项目复用。
- 代码即工具 (Code as Action)：让 Agent 输出 Python 代码并在沙箱中执行 (CodeAct、SmolAgents)， 表达力远高于 JSON 工具调用。
- 子 Agent 即工具：把另一个 Agent 包装成一个 tool，是构建层级编排最简洁的模式（OpenAI Agents SDK
agent.as_tool()）。
4.6 路由与决策
- LLM 路由：由 LLM 根据 query 选择下游 Agent，最灵活但有不确定性。
- 规则路由：基于关键词/正则/分类器，快且稳定，适合明确意图。
- 语义路由：embedding 相似度匹配 Agent 描述，介于二者之间。
- 混合路由：先规则兜底，未命中再 LLM 兜底（推荐生产实践）。
4.7 人在环路 (Human-in-the-Loop)
关键决策点暂停，等待人工 approve / edit / reject。LangGraph 的 interrupt()、
OpenAI Agents SDK 的 HumanApprovalTool、Temporal 的 signal 都是常见实现。
用于：高风险操作、低置信度兜底、训练数据回流。
4.8 可观测性 (Observability)
这是多 Agent 系统能否进入生产的分水岭。必备能力：
- 完整 trace：跨 Agent / 跨 LLM 调用的因果链（OpenTelemetry GenAI 语义约定）
- 结构化日志：每次 LLM 调用的 prompt、response、token、latency、cost
- 重放 (replay)：定位 bug 时能从任意一步重放
- 评估 (eval)：离线数据集 + 在线 LLM-as-Judge
主流工具：LangSmith、Langfuse、Arize Phoenix、 Helicone、Braintrust、W&B Weave。
#5. 工程考虑点
从原型到生产，无法绕开的非功能性问题。
💰 成本控制
- 多 Agent token 消耗常达单 Agent 的 10-20×，必须做 budget 监控
- 分层模型：Planner 用强模型 (Opus/GPT-5)，Worker 用便宜模型 (Haiku/4o-mini)
- Prompt caching、上下文复用、结果缓存
- Early-stop：信息已足够时尽快结束循环
⏱️ 延迟优化
- 并行调用：
asyncio.gather/ fan-out - 流式输出：Orchestrator 边收边转发
- 预热常用上下文（prompt caching）
- 预测式执行 / speculative routing
🔁 错误处理与重试
- 区分瞬时错误 (rate limit、超时) 与语义错误 (Agent 输出不符合要求)
- 瞬时错误：指数退避重试，多 provider fallback
- 语义错误：交给 Critic / Validator Agent，或回退给 Orchestrator 重新规划
- 最大步数 / 最大成本熔断必须存在
🛡️ 安全与权限
- Prompt Injection：来自工具返回值的对抗性指令（特别危险）
- 最小权限原则：每个 Agent 只授予完成职责所需的工具
- 沙箱执行：代码执行、shell 命令必须在隔离容器
- 敏感操作：HITL 强制审批 + 审计日志
- OWASP LLM Top 10、Lethal Trifecta 模型
🔄 状态管理与持久化
- 对话 / 任务状态需可序列化、可恢复（崩溃续跑）
- LangGraph
Checkpointer、Temporal Workflow 是参考实现 - 并发写共享状态时需考虑锁 / CRDT / 事件溯源
📏 评估 (Evaluation)
- 组件级：单 Agent 输出质量、工具调用准确率
- 端到端：整体任务成功率、用户满意度
- 过程级：步数、绕路率、回溯次数
- 方法：黄金数据集 + LLM-as-Judge + 人工抽检
🚦 非确定性治理
- 同一 query 两次结果不一致是常态，需容差区间而非精确匹配
- 关键路径用 temperature=0 + structured output 收敛
- 关键工具调用用 schema 校验 + 重试
🌐 部署与扩展
- Stateless API + 外部状态存储是首选
- 长任务用异步队列 (Celery / Temporal / SQS)，避免 HTTP 超时
- WebSocket / SSE 推送中间过程，提升体感
- 多租户：隔离上下文、配额、计费
- Token 黑洞：Agent 之间互相 ping 不收敛，账单一夜暴涨。→ 强制设置 max_iterations / max_cost。
- 上下文崩塌：Orchestrator 把所有子 Agent 的原始输出全部塞回自己窗口。→ 用 Summarizer 中间件。
- 静默漂移：没有评估集，模型一升级就退化无人发觉。→ 上线 eval pipeline 是非选项。
#6. 主流框架对比
截至 2026 年，多智能体编排领域已形成「代码框架 + 低代码平台 + 协议层」三大梯队。
6.1 代码框架（开发者主战场）
| 框架 | 厂商 | 核心抽象 | 编排范式 | 定位 | 适用 |
|---|---|---|---|---|---|
| LangGraph | LangChain | StateGraph (节点+边+共享 State) | 图 / 任意拓扑 | 底层最灵活，生产级首选 | 复杂工作流、需 HITL/持久化的项目 |
| AutoGen v0.4 | Microsoft | Actor / Event-driven Agent | 异步消息、GroupChat | 分布式 actor 模型，研究友好 | 研究、原型、需异步并发 |
| CrewAI | CrewAI Inc. | Crew / Agent / Task | Sequential / Hierarchical | 角色化协作，最易上手 | 业务流程模拟、内容生产 |
| OpenAI Agents SDK | OpenAI | Agent + Handoff + Guardrail | Handoff (Swarm 继任者) | 轻量、官方支持、自带 trace | OpenAI 生态、客服/路由类 |
| Google ADK | Agent / Workflow / Tool | 顺序/并行/循环 + LLM 路由 | 原生 A2A 支持，Gemini 优化 | GCP/Vertex 用户、企业级 | |
| Semantic Kernel | Microsoft | Kernel / Plugin / Planner | Planner + Plugin | .NET / Java 生态、企业集成 | 企业 Java/.NET 项目 |
| LlamaIndex Agents | LlamaIndex | AgentWorkflow / Event | 事件驱动 workflow | RAG 深度整合 | 知识密集型 + Agent |
| MetaGPT | 开源 | 角色 (SOP) | 软件公司模拟 | 预置软件研发 SOP | 代码生成研究、Demo |
| SmolAgents | HuggingFace | CodeAgent | 代码即行动 | 极简 (~1k LOC)，行动用代码 | 研究、教学、小型 Agent |
6.2 低代码 / 可视化平台
Dify 开源
可视化 Workflow + Agent，自带 RAG、知识库、监控。国内最流行，企业私有化部署友好。
Coze / 扣子 字节
面向 C 端 Bot 生态，插件市场丰富，海外/国内双版本。低代码工作流 + 多 Agent。
n8n 开源
通用自动化平台，2025 加入 AI 节点后成为热门 Agent 编排选项，集成 500+ 应用。
Flowise 开源
LangChain 的可视化前端，拖拽即可构建 Chain 与 Agent。
Microsoft Copilot Studio
面向企业 IT，深度集成 M365、Power Platform、Azure。无代码 Agent 构建。
百炼 / 千帆 / 文心智能体
阿里、百度的云上 Agent 平台，绑定自家模型，适合国内合规与生态用户。
6.3 协议与基础设施
MCP 协议
Agent ↔ 工具/数据的标准。生态：mcp-servers 已覆盖 GitHub、Slack、DB、Browser 等数百个。
A2A 协议
Agent ↔ Agent 标准。AgentCard 描述能力，便于跨厂商发现与调用。
Temporal / Restate 运行时
Durable Execution。长任务、崩溃恢复、人工审批的可靠底座。
LangSmith / Langfuse 观测
Agent 调用链 trace、prompt 管理、eval pipeline。生产必备。
Inngest / Trigger.dev 事件
事件驱动后台任务，对 Agent 长流程友好。
Mem0 / Letta 记忆
独立的 memory layer，可挂在任何 Agent 框架前。
#7. 选型决策
没有银弹，只有匹配。按团队特征 + 场景特征做组合选择。
7.1 决策矩阵
| 你的情境 | 推荐方案 | 理由 |
|---|---|---|
| Python 团队，复杂工作流，需 HITL + 持久化 | LangGraph + LangSmith | 图抽象灵活，checkpointer 成熟，生态最全 |
| 已在用 OpenAI，需要轻量编排 + 客服路由 | OpenAI Agents SDK | handoff 范式简洁，trace 开箱即用 |
| 业务模拟：销售/PM/Dev 协作 | CrewAI | 角色 + 任务抽象贴近真实组织 |
| 研究 / 实验异步多 Agent 拓扑 | AutoGen v0.4 | actor 模型 + 灵活 GroupChat |
| .NET / Java 企业系统 | Semantic Kernel | 原生支持，企业集成完善 |
| 非技术团队主导 / 快速 POC | Dify / Coze / n8n | 低代码、内置 RAG 与监控 |
| GCP + Gemini，需 A2A 跨厂商互通 | Google ADK | 原生 A2A，Vertex AI 深度整合 |
| RAG 是核心，Agent 是增强 | LlamaIndex | 索引与查询引擎一流 |
| 金融 / 医疗等高可靠场景 | LangGraph + Temporal | Durable execution 保证恢复与审计 |
7.2 选型核对清单
- 编排范式是否匹配你的任务结构（DAG / 自由消息 / 层级）
- 状态持久化是否原生支持（崩溃恢复、长任务）
- HITL 是否一等公民（中断、审批、编辑）
- 可观测性是否自带或易接入（OpenTelemetry、LangSmith）
- 模型抽象是否支持多 provider 与 fallback
- 工具生态 是否兼容 MCP，是否有现成集成
- 部署模型是否符合你的合规要求（开源/私有化/SaaS）
- 团队学习曲线与社区活跃度（GitHub star、issue 响应、文档质量）
- License（Apache 2.0 vs BSL vs 商业）
- 对接成本（与现有 LLM Gateway、向量库、Auth 系统）
#8. 实现路径与参考架构
从 0 到 1 到生产的渐进式路线图，以及一个通用的部署参考架构。
8.1 五阶段演进路径
8.2 参考部署架构
(Temporal / Celery)
(LangGraph / ADK)
(审批 UI)
(MCP Servers)
(Mem0 / Vector DB)
(LiteLLM / Portkey)
(Langfuse / OTel)
8.3 工程实践清单
🧱 代码组织
- 每个 Agent 一个独立模块：prompt / tools / schema 分离
- Prompt 用模板引擎 (Jinja2) 管理，禁止硬编码
- Tool 描述与实现解耦，便于跨 Agent 复用
- State Schema 用 Pydantic / TypedDict 强类型
🧪 测试策略
- 单元测试：Mock LLM，验证工具调用 schema、状态转移
- 回归测试：黄金数据集 + 输出快照 + 语义相似度
- 对抗测试：Prompt injection、越权工具调用
- 压测：并发任务下的 token 与延迟
🚀 发布策略
- Prompt 与代码同等对待，走 PR + Review + 版本号
- 金丝雀发布：5% 流量验证新 prompt / 新模型
- 影子模式 (shadow)：新 Agent 静默并行，仅记录不返回
- 自动回滚：质量指标低于阈值自动切回旧版
💡 上下文管理技巧
- 子 Agent 返回值用 schema 约束，避免长文本污染
- 每轮结束后由 Summarizer 压缩历史
- 关键事实写入 Memory，非关键信息丢弃
- 使用 Prompt Caching 复用稳定前缀
#9. 典型案例剖析
四个有代表性的真实多智能体系统，看模式如何落地。
9.1 Deep Research（Anthropic / OpenAI / Perplexity）
模式：Orchestrator-Worker。
流程：用户提交研究问题 → LeadResearcher 拆解为子问题 → 并行 fan-out 给多个 Subagent 检索 + 阅读 → 各 Subagent 返回结构化摘要 → Synthesizer 汇总 + CitationAgent 加引用。
关键设计：
- 子 Agent 独立窗口，原始网页内容不回传，只回压缩摘要
- Lead 使用强模型 (Opus)，Sub 使用快模型 (Sonnet/Haiku)
- 显式 token 预算，超额自动停止
- 报告：相比单 Agent 任务质量提升 ~90%，token 消耗 ~15×
9.2 编程智能体（Claude Code / Cursor / Devin）
模式：Plan-Execute-Reflect + 子 Agent 即工具。
流程：主 Agent 接收需求 → 制定计划 → 调用 search/edit/run 工具循环执行 → 复杂子任务（如大型重构）派生子 Agent，子 Agent 拥有独立上下文，完成后只回传 diff + 摘要 → 失败时 Critic 重新规划。
关键设计：
- 主 Agent 上下文只保留高层计划与文件级摘要，避免被代码淹没
- 每步都有 sandbox 执行 + 测试反馈作为闭环
- HITL 在敏感操作（删除、push）必须 approve
9.3 智能客服 (Triage + Specialist Handoff)
模式：Hand-off / Swarm。
流程：Triage Agent 识别意图 → 移交给 Billing / Tech / Sales Agent → Agent 调用 CRM / KB 工具 → 不确定或高风险时再 hand-off 给 Human Agent。
关键设计：
- 每个 Specialist 只暴露自己领域的工具，减小决策空间
- Guardrail Agent 拦截违规请求、PII 泄露
- 所有 hand-off 事件结构化记录，便于质检与训练
9.4 通用 Agent 助手 (Manus / GenSpark)
模式：分层 Planner + 异步 Workers + 虚拟桌面环境。
流程：主 Planner 维护待办清单 → 拉起子 Agent 在云端虚拟机内执行浏览/代码/文件操作 → 过程异步推送给用户 → 用户可中途打断 / 修改目标。
关键设计：
- 任务级而非对话级交付，用户离线后继续执行
- 所有副作用在隔离环境内，便于回滚与审计
- 事件流式 UI，让长任务可解释
#10. 常见陷阱与反模式
真实项目中最常见的踩坑清单。
❌ 过度多智能体化
把本可用 if-else / Workflow 解决的简单逻辑硬塞给一群 Agent 协作。
结果：成本 10×、延迟 5×、可靠性反而下降。
对策：保持「确定性优先，LLM 兜底」的设计原则。
❌ Orchestrator 上下文爆炸
子 Agent 把原始网页/代码/日志全部回传给 Orchestrator，几轮后窗口被挤爆。
对策：约定子 Agent 必须返回 schema 化的「结论 + 引用 ID」。
❌ 没有终止条件
GroupChat 模式下 Agent 互相 "thanks, anything else?"，token 失控。
对策：max_iterations、max_cost、显式 done 信号缺一不可。
❌ 提示词散落
各 Agent prompt 拷贝在不同文件里，改一处忘十处。
对策：集中 prompt registry + 版本号 + 引用。
❌ 用聊天日志当评估
没有 golden set，靠"感觉好像更好了"上线。
对策：上线前必须有可重复的 eval 脚本与分数。
❌ 忽视工具描述质量
Tool 的 description / 参数说明写得含糊，模型频繁选错或传错参。
对策：把工具描述当成 prompt 的核心部分迭代。
❌ Prompt Injection 防线缺失
来自检索结果 / 工具返回值 / 用户上传文件中的指令被 Agent 当真执行。
对策：区分可信/不可信上下文，敏感工具加 HITL。
❌ 试图让 Agent 学会一切
把整本手册塞进 system prompt，结果模型抓不到重点。
对策：让 Agent 学会"按需检索"而非"全量记忆"。