若你正把检索、推理、生成、审核全塞进一个 LLM Agent，却在规模化时遭遇上下文爆满、串行超时与单点故障——本文给出可写进架构评审的完整路径：① 为什么单 Agent 不够、多 Agent 系统（MAS）的三种控制模式；② 覆盖 95% 生产场景的六大编排设计模式（含 LangGraph / AutoGen 代码）；③ LangGraph vs CrewAI vs AutoGen 选型矩阵与 MCP+A2A 双层通信协议；④ 状态持久化、可观测性、四大踩坑与选型决策树。与MCP 协议解读、MCP Server 教程互补——本篇专注多 Agent 编排 → 框架选型 → 生产落地。
根据 MLflow 2026 年报告，Google 内部 Agent Bake-Off 实验显示，采用分布式多 Agent 架构后处理时间从 1 小时降至 10 分钟，提升超过 6 倍。AdaptOrch（2026 学术论文）进一步证明：在多 Agent 系统中，编排拓扑的选择对系统性能的影响比底层模型的选择更大，在 SWE-bench 等基准上正确的拓扑可带来 12–23% 的性能提升。
多 Agent 协作系统（Multi-Agent System，MAS）是指由多个独立的 AI Agent 组成的系统，这些 Agent 通过明确的通信协议和编排机制协作完成单个 Agent 无法高效完成的复杂任务。
Agent A 的输出直接作为 Agent B 的输入，严格线性执行。适用：步骤间有严格依赖、流程固定、不需要动态路由（文章创作流水线、代码审查流程）。
from langgraph.graph import StateGraph, START, END
from typing import TypedDict
class PipelineState(TypedDict):
query: str
retrieved_docs: str
analysis: str
final_report: str
def retrieval_agent(state):
return {"retrieved_docs": search_knowledge_base(state["query"])}
def analysis_agent(state):
result = llm.invoke(f"分析：{state['retrieved_docs']}")
return {"analysis": result.content}
builder = StateGraph(PipelineState)
builder.add_node("retriever", retrieval_agent)
builder.add_node("analyzer", analysis_agent)
builder.add_edge(START, "retriever")
builder.add_edge("retriever", "analyzer")
builder.add_edge("analyzer", END)
pipeline = builder.compile()
优缺点：实现简单、行为可预测、适合合规审计；但总耗时 = 各步之和，单步失败整体阻塞，无法处理动态分支。
多个 Agent 同时处理独立子任务，汇聚节点合并结果。总耗时 = max(T1, T2, ..., Tn) 而非求和。适用：子任务彼此独立（多来源研究、多维度风险评估）。
from langgraph.types import Send
from typing import Annotated
import operator
class ResearchState(TypedDict):
query: str
research_results: Annotated[list, operator.add]
final_synthesis: str
def supervisor(state):
return [Send("research_worker", {"query": state["query"], "source": s})
for s in ("academic", "industry", "news")]
def research_worker(state):
return {"research_results": [search_by_source(state["query"], state["source"])]}
关键技术点：LangGraph 的 Send API 返回 Send 对象列表，子图会真正并发执行。配合 Annotated[list, operator.add] Reducer，并行分支结果自动聚合，无需手写锁或同步逻辑。
主管 Agent 负责意图识别、任务拆解和路由决策，将子任务分配给专业 Worker，最后汇总。适用：工作可拆解为不同专业领域（研究员、写手、编码员）、任务类型多样需动态路由（Replit 代码助手、客服系统）。
双层路由优化：第一层关键字快速通道（响应 <1ms，无需 LLM）；第二层 LLM 精确路由处理复杂/模糊意图。
Agent 之间点对点直接传递任务，无中央协调者，依靠终止规则（轮数、共识、超时）停止。适用：多轮协商和辩论（代码审查、方案评估）。注意：非确定性高，生产环境慎用，建议用层级模式替代。 AutoGen GroupChat 示例中须设置 max_round=6 硬性终止防止无限循环。
所有 Agent 共享一个结构化工作空间（黑板），Agent 在满足前提条件时主动读写黑板，无需显式调度。适用：长时间异步任务（小时级甚至天级）、异构服务协作、工作流条件复杂难以提前预定路由。
在同一系统中组合多种模式，通常是「主管模式 + 流水线」。真实案例：Intent Agent 路由 → 简单查询直接回答；复杂报告 → Supervisor 层级 → 并行研究扇出 + 质量保障流水线（审核 → 人工审核 → 发布）。
| 维度 | LangGraph | CrewAI | AutoGen（微软） |
|---|---|---|---|
| 架构范式 | 状态机图 | 角色制团队 | 对话式多 Agent |
| 编程语言 | Python / JS/TS | Python | Python / .NET |
| 学习曲线 | 较陡 | 平缓 | 中等 |
| 状态管理 | 原生支持 | 需自实现 | 有限支持 |
| Human-in-the-Loop | 原生支持 | 需自实现 | 支持 |
| 可观测性 | LangSmith（商业） | 有限 | Azure Monitor |
| 生产就绪度 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| 快速原型 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Azure 集成 | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ |
| 适合场景 | 复杂有状态工作流 | 角色制内容流水线 | 对话式协作 |
选 LangGraph：生产级可靠性（金融、医疗）、复杂状态管理与持久化、Human-in-the-Loop 精细控制、条件分支和循环精确表达。
选 CrewAI：1–2 天快速验证 Idea、团队用「角色」直觉理解 Agent、内容生成/研究报告等角色制场景。
选 AutoGen：微软/Azure 技术栈、需要 Agent 多轮辩论和迭代推理、研究或快速实验不同对话模式。
2026 年，多 Agent 系统通信协议已标准化为两层互补架构，均已纳入 Linux Foundation Agentic AI Foundation 管理：
每个 A2A Agent 发布 Agent Card（/.well-known/agent.json），Orchestrator 通过 JSON-RPC 2.0 发现并委托任务。详见MCP 协议解读与MCP Server 开发教程。
使用 PostgresSaver 作为 LangGraph 检查点存储，即使进程重启也可从上次状态恢复（thread_id 跨会话）。
LangGraph interrupt() 在高风险操作前暂停，等待人工确认（如修改生产数据库）。
对外部 Agent 调用实施 Circuit Breaker（CLOSED / OPEN / HALF_OPEN），失败阈值触发熔断，避免级联故障。
TokenBudgetManager 在每次 Agent 调用前检查剩余预算，超额抛出 BudgetExceededException，按 Agent 维度记录用量。
根据 MAST 研究团队对 1642 个执行追踪的分析，多 Agent 系统故障分布如下：
| 故障类型 | 占比 | 说明 |
|---|---|---|
| 系统设计问题 | 41.77% | 步骤重复、工具选择错误、上下文溢出、缺少终止条件 |
| Agent 间不对齐 | 36.94% | 交接时上下文丢失、一个 Agent 的幻觉成为下一个的「事实」 |
| 任务验证失败 | 21.30% | 过早终止、不完整验证 |
更令人担忧的是：57% 的组织已有 Agent 在生产环境运行，但仅 8% 完成了 LLM 可观测性实施。大量错误以 HTTP 200 返回，监控面板全绿，系统实际输出却是错误结果。
分布式追踪：每次 Agent 调用携带 correlation_id，OpenTelemetry span 记录 agent.name、tokens_used、status。
关键监控指标：端到端任务完成率（目标 >85%）、P95 延迟（<30s）、各 Agent 错误率（<5%）、重试次数、Token 成本、LLM-as-a-Judge 输出质量评分。
Agent A 产生幻觉，错误结果传给 B、C，整个系统基于错误前提输出，HTTP 状态码却全是 200。防坑：每个 Agent 交接点做 Schema 验证、置信度阈值（<0.7 拒绝）、必填字段检查。
Agent 进入重试循环，Token 费用几分钟内暴涨至预期百倍。防坑：硬性上限 MAX_ITERATIONS=10、MAX_TOOL_CALLS_PER_AGENT=20、MAX_TOTAL_TOKENS=50_000；LangGraph interrupt_before 高代价操作前暂停。
把简单两步 LLM 链拆成 8 个 Agent，调试难度指数级上升。原则：先从顺序流水线开始；有具体证据（并发需求、超上下文、专业能力需独立升级）才增加 Agent。生产系统最佳 Agent 数量通常是 3–8 个。
内部 Demo 效果好，上线后边缘输入频繁失败。防坑：输入长度限制、提示注入检测、PII 过滤、有害内容检测——ProductionGuardrails 从第一天就位。
Send API 派发并行分支后，Supervisor 在慢分支完成前重跑，导致重复执行。防坑：builder.add_node("supervisor", supervisor_node, defer=True) 创建显式同步屏障。
thread_id，支持断点续传与 Human-in-the-Loop。核心要点：① 编排拓扑 > 模型选择；② 从简单顺序流水线开始；③ MCP + A2A 是未来标准；④ 可观测性不是可选项；⑤ 生产 Agent 数量 3–8 个最佳，超过应考虑层级化。
2026 年值得关注：联邦编排（多团队子编排器共享路由策略）、多模态多 Agent（视觉/音频与文本混合）、自适应拓扑选择（AdaptOrch 方向）、EU AI Act 合规要求完整决策审计链。
但若把 LangGraph 编排、MCP Server 与 A2A Gateway 跑在会睡眠的笔记本或与他人共用的开发机上，你会面临三项隐性成本：检查点与会话因合盖中断、环境漂移导致 Agent 交接失败、以及无法维持 7×24 多步骤工作流。对需要稳定多 Agent 编排与 MCP/A2A 长连接的生产环境，把 Gateway 与状态存储落在 MACCOME Mac mini（M4 / M4 Pro）独占节点上，通常比在本地与睡眠策略搏斗更省总成本；公开档位见租赁价格说明。
常见问题
LangGraph、CrewAI、AutoGen 怎么选？
需要生产级状态管理、Human-in-the-Loop 与复杂分支选 LangGraph；快速角色制原型选 CrewAI；微软/Azure 栈且需多轮辩论选 AutoGen。详见上文对比矩阵。
MCP 和 A2A 在多 Agent 系统中分别做什么？
MCP 是垂直层（Agent ↔ 工具）；A2A 是水平层（Agent ↔ Agent）。详见MCP 协议解读。
生产环境应该有多少个 Agent？
实证甜区是 3–8 个。超过后协调开销往往超过收益，应考虑层级化拆分为子团队。