title: 多Agent协作与A2A协议------CrewAI + LangGraph搭建AI协作团队
tags: 多Agent协作,A2A协议,CrewAI,LangGraph,AutoGen,Agent协作,Agent Card,Agent开发,Python,AI Agent
category: 人工智能
多Agent协作与A2A协议------CrewAI + LangGraph搭建AI协作团队
本文是《AI编程与Agent实战》系列第10篇。第09篇用FastMCP从零写了一个完整的MCP Server，覆盖Tools/Resources/Prompts三大原语、调试方法和Docker部署。结尾指出：MCP解决的是Agent到工具的连接，那Agent到Agent的连接谁来解决。
系列前置阅读：第01篇：工具横评 | 第02篇：Cursor入门 | 第03篇：Claude Code实战 | 第04篇：本地模型编程 | 第05篇：Agentic Engineering | 第06篇：AI代码安全 | 第07篇：全栈项目实战 | 第08篇：Agent开发入门 | 第09篇：MCP Server开发
2026年4月9日，Linux基金会Agentic AI Foundation发布A2A协议一周年数据：22,000+ GitHub stars、150+生产级组织部署、5种语言官方SDK（Python/JavaScript/Java/Go/.NET）。Microsoft Copilot Studio、Azure AI Foundry、Amazon Bedrock AgentCore Runtime全部原生集成。同一天，签名Agent Card（加密身份验证）和Agent Payments Protocol（AP2，60+支付行业伙伴）正式发布。
数字背后的工程现实：企业Agent架构正在从「单个Agent+多个MCP工具」走向「多个Agent通过A2A协议互委托任务」。一个LangGraph编排的财务Agent可以把合规检查委托给CrewAI构建的法务Agent，两者运行在不同框架、不同服务器、甚至不同组织，不需要任何定制集成。
但这套图景有一个容易被忽略的前提：多Agent协作的失败率远高于单Agent。UC Berkeley的MAST研究分析了1,600条生产执行trace，发现多Agent系统41%到86.7%的失败率，其中79%来自架构设计问题，不是模型能力问题。Augment Code的分析更直接：朴素的「Bag of Agents」管线累积错误的速度是单Agent系统的17倍。
这篇从协议层到框架层拆解多Agent协作的完整图景：A2A协议怎么让不同框架的Agent互相通信，CrewAI怎么用几十行代码搭建一个AI团队，LangGraph怎么构建有状态的工作流，以及为什么多Agent不是越多越好。
来源：Linux Foundation AAIF Press Release 2026.04, agentmarketcap.ai A2A一周年分析 2026.04, UC Berkeley MAST Taxonomy arXiv 2503.13657 2025.03, Augment Code Bag of Agents分析 2026
目录
- 从单Agent到多Agent：为什么需要协作
- [2026年Agent协议全景：MCP + A2A + AP2三层模型](#2026年Agent协议全景：MCP + A2A + AP2三层模型)
- [A2A协议详解：Agent Card、Task与Transport](#A2A协议详解：Agent Card、Task与Transport)
- CrewAI实战：搭建AI研究团队
- LangGraph实战：构建有状态的复杂工作流
- [三大框架对比：CrewAI vs LangGraph vs AutoGen](#三大框架对比：CrewAI vs LangGraph vs AutoGen)
- 多Agent协作的失败模式：MAST分类法
- 辩证看待：多Agent不是越多越好
- 选型建议：什么场景用什么框架
- 总结与下一篇预告
1. 从单Agent到多Agent：为什么需要协作
1.1 单Agent的天花板
一个配了MCP工具的Agent已经很强了：能查数据库、调API、读写文件、执行代码。但生产环境中的复杂任务会撞上三面墙。
注意力分散。 让一个Agent同时扮演研究员、分析师和撰稿人，它在每一步推理时都需要在不同角色间切换上下文。LLM的注意力是有限的资源，角色越多，每个角色分到的注意力越少，输出质量逐级下降。CrewAI官方实测数据：比LangGraph快5.76倍的原因之一是专业分工让每个Agent的推理路径更短。
上下文窗口膨胀。 复杂任务需要大量中间结果。一个Agent处理完整流程，所有中间数据都堆在一个上下文窗口里。Token消耗线性增长，到了窗口上限只能截断或摘要，信息丢失不可避免。Augment Code的基准测试显示，多Agent管线的Token消耗约是单Agent的15倍，但每个Agent各自处理的上下文更小、更聚焦。
错误传播。 单Agent管线里，第3步的错误直接进入第4步的输入，第4步基于错误数据继续推理，错误被「合法化」。MAST研究发现，这是多Agent系统最常见的失败模式之一（Error Cascade，错误级联），在单Agent中同样存在，只是多Agent场景下传播路径更隐蔽。
1.2 多Agent的核心价值
多Agent协作解决这三个问题的思路是专业分工。
单Agent模式：
用户 → [全能Agent: 研究+分析+写作+审核] → 输出
问题：注意力分散、上下文膨胀、错误不可控
多Agent模式：
用户 → [研究员Agent] → [分析师Agent] → [撰稿Agent] → [审核Agent] → 输出
优势：专业分工、独立上下文、可插入验证节点每个Agent有自己的角色定义（role）、目标（goal）、背景故事（backstory）和工具集。研究员Agent只管搜索和整理资料，分析师Agent只管从数据中提炼洞察，撰稿Agent只管把分析结果写成文章。每个Agent的上下文窗口只装自己需要的信息，推理路径更短、更聚焦。
但这个图景有一个容易被忽视的前提：多Agent的价值取决于架构和任务的对齐程度。架构不对齐，多Agent比单Agent更差。后面第7节会详细展开。
1.3 多Agent的三种协作拓扑
生产环境中多Agent协作有三种主流拓扑结构：
星型（Orchestrator + Workers）。 一个中央编排器Agent接收任务，决定分给哪个专业Agent执行，收集结果后决定下一步。LangGraph的Supervisor模式和大部分CrewAI实现属于这一类。优势是可预测性强、编排器有全局视野。劣势是扩展性有限，编排器在5-6个Agent以上容易成为瓶颈。
网状（Peer-to-Peer）。 所有Agent平级，通过消息互相通信，没有中央编排器。AutoGen和部分CrewAI配置采用这种模式。优势是灵活、无单点瓶颈。劣势是极易出现语义漂移和无限协商，调试困难。
层级（Hierarchical）。 组织结构式的编排。顶层Supervisor委托给中层Team Lead，Team Lead再分配给底层执行Agent。LangGraph通过子图（Subgraph）支持这种模式。适合大规模系统，但设计复杂度高。
2026年Q1的生产验证结果很明确：星型（Orchestrator + Workers）是唯一在生产环境中稳定运行的拓扑。网状协作在demo中看起来优雅，在production中几乎全部被替换。
来源：swoft.ai多Agent协调14种失败模式 2026, buildtest.run多Agent生产报告Q1 2026, codexical.com多Agent编排失败分析 2026.05
2. 2026年Agent协议全景：MCP + A2A + AP2三层模型
2.1 三层协议栈
2026年的Agent协议生态已经形成了清晰的三层结构：
┌─────────────────────────────────────────────────┐
│ 多 Agent 系统架构 │
│ │
│ Agent A ◄──── A2A ────► Agent B │
│ (LangGraph) 协议 (CrewAI) │
│ │ │ │
│ MCP MCP │
│ 协议 协议 │
│ │ │ │
│ 数据库 API 文件 数据库 API 文件 │
│ │
│ ──────────────────────────────────── │
│ AP2 协议：Agent 之间的支付与结算 │
└─────────────────────────────────────────────────┘| 层级 | 协议 | 解决什么 | 主导方 | 治理 |
|---|---|---|---|---|
| Agent → 工具 | MCP | Agent怎么调用外部工具和API | Anthropic | Linux基金会AAIF |
| Agent → Agent | A2A | Agent怎么委托任务给另一个Agent | Linux基金会AAIF | |
| Agent → 支付 | AP2 | Agent怎么进行交易授权和结算 | A2A生态 | Linux基金会AAIF |
三层协议的关系不是竞争，是互补。MCP让Agent有工具可用，A2A让Agent有同事可用，AP2让Agent有交易能力。生产级Agent系统三个都需要。
2025年12月，Linux基金会成立Agentic AI Foundation（AAIF），把MCP和A2A放在同一个治理伞下。IBM的Agent Communication Protocol（ACP）在2025年8月合并进A2A，消除了唯一的分叉风险。截至2026年4月，三大云厂商（Microsoft Azure、AWS Bedrock、Google Cloud）全部原生集成A2A。
来源：Linux Foundation AAIF公告 2025.12, agentmarketcap.ai A2A分析 2026.04, PRNewswire A2A一周年新闻稿 2026.04
2.2 A2A vs MCP：不是替代，是互补
这是最常被问到的问题。一张表说清楚：
| 维度 | MCP | A2A |
|---|---|---|
| 解决什么 | Agent怎么调工具 | Agent怎么委托另一个Agent |
| 类比 | USB-C接口（连接外设） | HTTP协议（服务间通信） |
| 交互模式 | 无状态请求/响应 | 有状态长任务（submitted→working→completed） |
| 对方是什么 | MCP Server对Agent透明 | Agent有自己的推理，是黑盒 |
| 传输 | stdio / Streamable HTTP | JSON-RPC 2.0 over HTTPS + SSE |
| 规范维护 | Anthropic → AAIF | Google → AAIF |
一句话：MCP让Agent有手（工具），A2A让Agent有同事（其他Agent）。
来源：juejin.cn A2A协议解析, rapidclaw.dev A2A完整指南 2026
3. A2A协议详解：Agent Card、Task与Transport
3.1 Agent Card：Agent的数字名片
A2A协议的三个核心原语：Agent Card（发现）、Task（工作单元）、Transport（传输）。
每个支持A2A的Agent在/.well-known/agent.json发布一份JSON文档，告诉世界「我是谁、我能做什么、怎么跟我通信」。这就是Agent Card。
json
{
"name": "legal-compliance-agent",
"description": "法务合规审查Agent，识别合同中的法律风险条款",
"version": "1.2.0",
"url": "https://legal.internal.company.com/a2a",
"capabilities": {
"streaming": true,
"pushNotifications": true
},
"skills": [
{
"name": "contract_review",
"description": "审查商业合同，识别违约责任、管辖权和知识产权归属等风险条款",
"inputModes": ["text", "file"],
"outputModes": ["text", "json"]
},
{
"name": "compliance_check",
"description": "检查文档是否符合GDPR、SOC2等合规要求",
"inputModes": ["text", "file"],
"outputModes": ["text", "json"]
}
],
"authentication": {
"schemes": ["bearer"]
}
}任何Agent只要知道这个URL，就能读取Agent Card，决定是否委托任务。不需要预先注册、不需要中心化目录。这是一种去中心化的服务发现机制，和Web世界的.well-known/标准一脉相承。
3.2 签名Agent Card：企业级信任
2026年4月v1.0引入的关键特性：Agent Card支持加密签名。签名绑定到发布者的域名，调用方在信任Agent的能力声明之前，先验证Card是否由声明的域名签发。
这是企业采购的解锁功能。跨组织Agent协作时，你怎么知道对面的Agent Card没有被篡改？签名验证解决了这个问题。没有这个特性，跨组织A2A部署在合规层面几乎不可行。
3.3 Task：有状态的工作单元
A2A的Task不是简单的函数调用。它是一个有状态的工作单元，包含目标、消息线程和产出的类型化工件（artifacts）。
Task的状态机：
submitted → working → input-required → working → completed
↑ ↓
└───────────┘
(需要补充信息时回到working)三种通信模式对应不同任务类型：
同步请求/响应。 快速操作，毫秒级返回。查一个状态、执行一次计算。
流式（SSE）。 长任务实时进度更新。Agent在执行过程中持续推送中间结果，调用方看到进度条。一个研究报告生成任务可能需要30秒，流式模式让调用方不需要干等。
异步推送通知。 超长任务（小时级甚至天级）。Agent接收任务后返回一个webhook URL，任务完成时主动推送结果。金融合规审计一个季度报告不会在几秒内返回，异步模式处理这种工作流。
3.4 Transport：无聊但可靠的技术选择
A2A的传输层用了「最无聊的技术组合」：HTTPS传输、JSON-RPC 2.0消息封装、SSE流式更新。
这是有意为之的设计决策。企业安全团队和负载均衡器已经知道怎么处理HTTP流量。引入新的传输层会产生采用摩擦，A2A避开了。你能用Nginx做反向代理、用CDN做加速、用WAF做防护，运维体系不需要改造。
3.5 A2A的SDK生态
截至2026年4月，A2A有5种语言的官方SDK：
| 语言 | SDK | 状态 |
|---|---|---|
| Python | a2a-sdk | 生产就绪 |
| JavaScript/TypeScript | @a2a-protocol/js | 生产就绪 |
| Java | Quarkus A2A | 1.0.0.Beta1 |
| Go | a2a-go | 生产就绪 |
| .NET | Microsoft Agent Framework | A2A v1原生 |
原生支持A2A的框架：Google ADK、LangGraph、CrewAI、LlamaIndex、Semantic Kernel、AutoGen、Microsoft Agent Framework。这意味着你用这些框架构建的Agent，天然可以互相委托任务。
来源：rapidclaw.dev A2A完整指南 2026, agentmarketcap.ai A2A协议分析 2026.04, PRNewswire A2A新闻稿 2026.04, a2a-protocol.org官方规范
4. CrewAI实战：搭建AI研究团队
4.1 CrewAI是什么
CrewAI是把人类团队协作模式映射到AI上的框架。核心抽象是「角色+任务+团队」：每个Agent有专业角色（role）、个人目标（goal）和背景故事（backstory），任务（Task）在团队成员间传递，Crew负责编排执行顺序。
截至2026年4月，CrewAI v1.14.3，GitHub stars约35K+，认证开发者超过100,000人。关键特性：完全独立，不依赖LangChain生态；官方实测比LangGraph快5.76倍；支持MCP协议和A2A通信。
4.2 安装与项目创建
bash
# 安装（推荐用uv，比pip快10-100倍）
uv pip install crewai
uv pip install 'crewai[tools]' # 安装官方工具集
# 或者用pip
pip install crewai crewai-tools用脚手架创建标准项目：
bash
crewai create crew research_team
cd research_team
crewai install
crewai run项目结构自动生成：
research_team/
├── .env # API Key
├── pyproject.toml
├── src/research_team/
│ ├── main.py # 入口
│ ├── crew.py # Crew定义
│ ├── config/
│ │ ├── agents.yaml # Agent配置
│ │ └── tasks.yaml # Task配置
│ └── tools/
│ └── custom_tool.py4.3 实战：搭建「研究员+分析师+撰稿人」团队
场景：给一个研究课题，三个Agent协作产出一份研究报告。
python
# main.py
from crewai import Agent, Task, Crew, Process, LLM
from crewai_tools import SerperDevTool # 搜索工具
# 配置LLM
llm = LLM(model="gpt-4o-mini")
# 搜索工具
search_tool = SerperDevTool()
# ============================================================
# ① 定义三个Agent
# ============================================================
researcher = Agent(
role="科技研究员",
goal="深入研究{topic}，找出最新进展和关键信息",
backstory="""你是一位经验丰富的科技记者，擅长快速定位
关键信息并提炼要点。你的研究风格严谨，总是区分
事实与推测，注明信息来源。""",
llm=llm,
tools=[search_tool],
max_iter=15, # ReAct循环最多15步
verbose=True,
)
analyst = Agent(
role="数据分析师",
goal="从研究数据中提炼可操作的商业洞察",
backstory="""你在金融行业有10年数据分析经验，
擅长用统计学方法发现隐藏规律。你的分析报告
总是包含数据支撑和风险提示。""",
llm=llm,
verbose=True,
)
writer = Agent(
role="技术撰稿人",
goal="将分析结果整理成清晰易读的中文报告",
backstory="""你是一位专业的科技博主，文风简洁，
善于用通俗的语言解释复杂概念。你的文章结构清晰，
每段不超过3句话。""",
llm=llm,
verbose=True,
)
# ============================================================
# ② 定义三个Task
# ============================================================
research_task = Task(
description="""对{topic}进行深入调研：
1. 搜索最新的技术进展和行业动态
2. 识别3-5个关键技术要点
3. 收集支持数据和市场数据
4. 记录所有信息来源""",
expected_output="包含3-5个关键技术要点的结构化摘要，"
"每条2-3句话说明，附数据来源",
agent=researcher,
)
analysis_task = Task(
description="""基于研究员的调研结果：
1. 分析技术要点的商业影响
2. 识别机会和风险
3. 给出可操作的建议
4. 标注每条结论的置信度（高/中/低）""",
expected_output="包含商业洞察、风险提示和建议的分析报告，"
"每条结论标注置信度",
agent=analyst,
context=[research_task], # 依赖研究任务的输出
)
writing_task = Task(
description="""基于分析师的报告：
1. 撰写一份800字以内的中文报告
2. 包含引言、正文和结语
3. 语言通俗，避免技术术语
4. 在关键结论处加粗""",
expected_output="一篇结构清晰、语言通俗的中文研究报告",
agent=writer,
context=[analysis_task], # 依赖分析任务的输出
output_file="report.md", # 自动保存到文件
)
# ============================================================
# ③ 组建Crew并执行
# ============================================================
crew = Crew(
agents=[researcher, analyst, writer],
tasks=[research_task, analysis_task, writing_task],
process=Process.sequential, # 顺序执行
verbose=True,
)
result = crew.kickoff(inputs={"topic": "A2A协议与企业Agent架构"})
print(result)执行流程：
crew.kickoff(inputs)
│
├─ Task 1: research_task → researcher执行
│ └─ 输出: 技术要点摘要 + 数据来源
│
├─ Task 2: analysis_task → analyst执行（拿到Task 1的上下文）
│ └─ 输出: 商业洞察 + 风险提示 + 建议
│
└─ Task 3: writing_task → writer执行（拿到Task 2的上下文）
└─ 输出: 中文报告 → 保存到report.md4.4 逐层解析
Agent的身份三要素。 role、goal、backstory共同构成给LLM的System Prompt。模糊的配置（"助手""帮忙做事"）产出质量差；具体的配置（"法律合同审查专家，15年律所经验，专注违约责任和知识产权"）产出质量高。这三个参数是CrewAI中影响输出质量最大的杠杆。
Task的context参数。 context=[research_task]让analyst拿到researcher的输出。CrewAI自动把前序Task的结果注入下一个Task的上下文。这是信息在Agent间传递的主要方式。
max_iter限制。 ReAct循环最多执行多少步。默认20，生产环境建议5-8。不设上限的Agent可能因为模型判断「还没完成」而无限循环，烧掉Token预算。
Process.sequential vs Process.hierarchical。 顺序模式按Task列表顺序执行。层级模式引入一个Manager Agent，由Manager决定把Task分给谁、什么时候执行。层级模式适合任务依赖关系不明确的场景，但Token消耗更高（Manager需要额外推理）。
4.5 进阶：CrewAI Flow
CrewAI v1.x引入了Flow（事件驱动工作流），弥补sequential/hierarchical两种模式在精确控制上的不足：
python
from crewai.flow.flow import Flow, listen, start, router
class ResearchFlow(Flow):
@start()
def begin_research(self):
"""启动研究流程"""
return {"topic": self.state.topic}
@listen(begin_research)
def run_research_crew(self):
"""执行研究Crew"""
result = research_crew.kickoff(inputs=self.state)
return result.raw
@router(run_research_crew)
def route_by_quality(self):
"""根据质量评分路由"""
if self.state.quality_score > 0.8:
return "publish"
else:
return "revise"
@listen("publish")
def publish_report(self):
"""质量合格，发布报告"""
return "报告已发布"
@listen("revise")
def revise_report(self):
"""质量不合格，打回修改"""
return "报告需修改"
flow = ResearchFlow()
flow.kickoff(inputs={"topic": "A2A协议"})Flow的核心价值：条件分支、状态持久化、事件驱动。当Crew的顺序执行不够用时，Flow提供了精确的控制流。CrewAI官方建议：需要智能协作用Crews，需要精确掌控用Flows。两者可以嵌套使用，在Flow的某个步骤中执行一个Crew。
来源：juejin.cn CrewAI完全指南 v1.14.3 2026.04, alicelabs.ai CrewAI企业指南 2026, aiskillnav.com CrewAI教程 2026
5. LangGraph实战：构建有状态的复杂工作流
5.1 LangGraph是什么
LangGraph是LangChain团队出品的图式Agent编排框架。核心思想：把Agent工作流建模为有向图（StateGraph），节点（Node）是函数，边（Edge）定义状态流转，条件边实现分支和循环。
LangGraph 2.0于2026年2月发布，标志着从快速迭代期进入生产稳定期。所有非实验性API均被视为稳定和生产就绪。截至2026年4月，LangGraph是Python生态中采用最广的Agent编排库，LangChain组织全仓库GitHub stars超过126,000。生产用户包括Klarna（支持响应时间降低80%）、Uber、LinkedIn、Coinbase、Cloudflare。
5.2 核心概念
五个基础概念是理解LangGraph的前提：
State。 TypedDict或Pydantic模型，所有节点读写共享状态的唯一渠道。用Annotated标注的reducer函数控制并发更新如何合并。
python
from typing import Annotated
from typing_extensions import TypedDict
import operator
class AgentState(TypedDict):
messages: Annotated[list, operator.add] # 追加而非覆盖
next_step: str
result: strNode。 纯函数，接收当前状态，返回状态更新。可以调LLM、执行工具、查数据库。节点间通过状态通信，不直接互相调用。
python
def my_node(state: AgentState):
# 用state做点什么
return {"result": "computed value"}Edge。 定义节点间流转。普通边固定从A到B。条件边根据状态函数的返回值决定下一个节点，这是循环和分支的关键。
python
# 固定边：从agent到tools
graph.add_edge("agent", "tools")
# 条件边：根据状态决定下一步
graph.add_conditional_edges(
"agent",
lambda state: "tools" if state.get("needs_tool") else "end",
{"tools": "tools_node", "end": END}
)Checkpoint。 每次节点转换时可选保存完整图状态。开发用MemorySaver，生产用PostgreSQL或Redis。崩溃后从最后一个checkpoint恢复，不丢失已完成的工作。这是LangGraph在生产环境最大的差异化能力。
Thread。 用thread_id标识一个隔离的执行上下文（一次对话会话）。每个thread维护自己的状态历史。一个图可以服务数千个并发用户，各有各的记忆。
5.3 实战：Supervisor + Researcher + Writer工作流
构建一个Supervisor编排的多Agent工作流。Supervisor接收任务，决定分给Researcher还是Writer，收集结果后决定是否完成。
python
# langgraph_supervisor.py
from typing import Annotated, Literal
from typing_extensions import TypedDict
import operator
from langchain_core.messages import HumanMessage, AIMessage
from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph, START, END
# ============================================================
# ① 定义状态
# ============================================================
class AgentState(TypedDict):
messages: Annotated[list, operator.add]
next_step: str
research_result: str
final_report: str
# ============================================================
# ② LLM
# ============================================================
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
# ============================================================
# ③ 定义节点
# ============================================================
def supervisor_node(state: AgentState) -> dict:
"""Supervisor：决定下一步分给谁"""
messages = state["messages"]
# 让LLM决定下一步
decision_prompt = f"""你是一个任务编排器。根据当前对话历史，决定下一步：
- "researcher"：需要研究/搜索信息
- "writer"：需要撰写/整理内容
- "FINISH"：任务已完成
当前对话：
{messages[-1].content if messages else "无"}
只返回一个词：researcher、writer或FINISH。"""
response = llm.invoke(decision_prompt)
next_step = response.content.strip().lower()
if next_step not in ["researcher", "writer", "finish"]:
next_step = "researcher" # 默认给研究员
return {"next_step": next_step}
def researcher_node(state: AgentState) -> dict:
"""研究员Agent：搜索和整理信息"""
research_prompt = """你是一位科技研究员。请对以下主题进行调研，
总结3个关键技术要点，每个要点2-3句话。"""
messages = state["messages"]
full_prompt = research_prompt + "\n\n主题：" + messages[-1].content
response = llm.invoke(full_prompt)
return {
"messages": [AIMessage(content=response.content, name="researcher")],
"research_result": response.content,
}
def writer_node(state: AgentState) -> dict:
"""撰稿Agent：把研究结果写成报告"""
research = state.get("research_result", "")
writing_prompt = f"""你是一位技术撰稿人。请基于以下研究结果，
撰写一份400字以内的中文报告，包含引言、正文和结语。
研究结果：
{research}"""
response = llm.invoke(writing_prompt)
return {
"messages": [AIMessage(content=response.content, name="writer")],
"final_report": response.content,
}
# ============================================================
# ④ 路由函数
# ============================================================
def route_from_supervisor(state: AgentState) -> str:
"""根据Supervisor的决定路由"""
next_step = state["next_step"]
if next_step == "researcher":
return "researcher"
elif next_step == "writer":
return "writer"
else:
return "end"
# ============================================================
# ⑤ 构建图
# ============================================================
graph = StateGraph(AgentState)
# 添加节点
graph.add_node("supervisor", supervisor_node)
graph.add_node("researcher", researcher_node)
graph.add_node("writer", writer_node)
# 添加边
graph.add_edge(START, "supervisor")
# 条件边：Supervisor决定下一步
graph.add_conditional_edges(
"supervisor",
route_from_supervisor,
{
"researcher": "researcher",
"writer": "writer",
"end": END,
}
)
# Researcher和Writer完成后回到Supervisor
graph.add_edge("researcher", "supervisor")
graph.add_edge("writer", "supervisor")
# 编译
app = graph.compile()
# ============================================================
# ⑥ 执行
# ============================================================
result = app.invoke({
"messages": [HumanMessage(content="研究A2A协议的发展现状和未来趋势")]
})
print("=== 最终报告 ===")
print(result["final_report"])执行流程可视化：
START → supervisor → ┬─ researcher → supervisor → ...
├─ writer → supervisor → ...
└─ END (任务完成)Supervisor是循环的中心。每次Researcher或Writer完成任务后，控制权回到Supervisor，由它决定是否需要继续。
5.4 进阶：人在回路（Human-in-the-Loop）
LangGraph 2.0用interrupt()原语替代了旧的breakpoint API，提供一等公民的人在回路支持：
python
from langgraph.types import interrupt, Command
def human_review_node(state: AgentState) -> dict:
"""在关键节点暂停，等待人工确认"""
review_prompt = f"""请审核以下研究报告：
{state.get('final_report', '')}
输入 'approve' 发布，输入 'revise' 打回修改。"""
# 执行暂停，返回token给调用方
decision = interrupt({"review_needed": True, "report": state["final_report"]})
if decision == "approve":
return {"next_step": "publish"}
else:
return {"next_step": "revise"}调用方在interrupt()处暂停，可以是一个Web API返回等待状态给前端，用户在界面上审核后通过另一个请求恢复执行。这是长流程审批、高风险操作确认等场景的关键能力。
5.5 Checkpointing：崩溃恢复与时间旅行
python
from langgraph.checkpoint.memory import MemorySaver
from langgraph.checkpoint.postgres import PostgresSaver
# 开发环境：内存checkpoint
checkpointer = MemorySaver()
app = graph.compile(checkpointer=checkpointer)
# 生产环境：PostgreSQL持久化
# checkpointer = PostgresSaver.from_conn_string("postgresql://...")
# app = graph.compile(checkpointer=checkpointer)
# 每次调用指定thread_id
config = {"configurable": {"thread_id": "user-123-session-1"}}
result = app.invoke(
{"messages": [HumanMessage(content="研究A2A协议")]},
config=config
)
# 从checkpoint恢复（同一个thread_id）
result = app.invoke(
{"messages": [HumanMessage(content="继续上次的研究")]},
config=config # 自动加载该thread的历史状态
)Checkpoint的三个生产价值：
- 崩溃恢复。 进程重启后从最后一个checkpoint恢复，不丢工作。
- 时间旅行调试。 回退到任意历史状态，修改输入，分叉新执行路径。LangGraph Studio v2提供可视化界面直接做这件事。
- 评估管线。 在历史trace上重放新prompt或新模型版本，对比结果差异。
来源：josenobile.co LangGraph 2.0指南 2026, autolearningagents.com LangGraph完全指南, cowork.ink LangGraph教程 2026, appscale.blog Serverless多Agent 2026
6. 三大框架对比：CrewAI vs LangGraph vs AutoGen
6.1 框架现状速览
| 维度 | CrewAI | LangGraph | AutoGen |
|---|---|---|---|
| 版本 | v1.14.3 (2026.04) | 2.0 (2026.02) | 维护模式 |
| GitHub Stars | ~35K | ~10K (LangChain全系126K) | ~40K |
| 架构模型 | 角色团队 | 有向图 | 对话式 |
| 核心抽象 | Agent + Task + Crew | StateGraph + Node + Edge | AssistantAgent + UserProxy |
| 状态管理 | Memory系统 | Checkpointing（一等公民） | 对话历史 |
| Human-in-the-Loop | 支持（community级） | 一等公民（interrupt原语） | 支持 |
| 可观测性 | AgentOps集成 | LangSmith深度集成 | Azure Monitor |
| A2A支持 | 原生 | 原生 | 通过MAF |
| MCP支持 | 原生 | 原生 | 通过MAF |
| 学习曲线 | 低 | 高 | 中 |
| 生产成熟度 | 企业版AMP | 生产默认选择 | 转向MAF |
| 典型用户 | 快速原型/内容管线 | Klarna/Uber/LinkedIn | 微软生态 |
6.2 AutoGen的变局
AutoGen在2026年需要特别说明。Microsoft已确认AutoGen进入维护模式：只接受bug修复和安全补丁，不再开发新功能。Microsoft的战略重心转向了Agent Framework（MAF 1.0，2026年4月发布），它合并了AutoGen的编排模式和Semantic Kernel的企业级基础。
AutoGen的原始创建者发起了AG2社区分支，延续旧路线。这意味着选择AutoGen的开发者面临一个分叉：跟随Microsoft走MAF路线，还是跟随社区走AG2路线。
务实建议：新项目不要选AutoGen。如果你在微软生态中（Azure、GitHub Copilot、M365），直接用Microsoft Agent Framework。如果你需要对话式多Agent（辩论、共识），AG2是社区维护的替代品，但长期支持存疑。
6.3 一个常被忽略的混合模式
三个框架不是互斥的。一个被验证过的生产模式是：用LangGraph做顶层编排，用AutoGen（或CrewAI）Agent作为图中的节点。LangGraph提供持久化控制和人在回路，AutoGen/CrewAI提供对话式或角色式的Agent能力。
LangGraph (顶层编排，持久化，HITL)
├─ Node 1: CrewAI Crew (研究团队)
├─ Node 2: AutoGen Group (辩论/共识)
└─ Node 3: LangGraph Node (数据处理)这种模式在TrueFoundry的实践中被验证有效。LangGraph的durable control在外层，AutoGen的conversational code execution在内层。
来源：similarlabs.com CrewAI vs AutoGen vs LangGraph 2026, innovatrixinfotech.com框架对比 2026, nomadx.ae AI Agent框架对比 2026.07, internative.net框架对比 2026
7. 多Agent协作的失败模式：MAST分类法
7.1 MAST Taxonomy
UC Berkeley的Cemri等人2025年3月在arXiv发表MAST（Multi-Agent System Failure Taxonomy），分析了1,600条生产执行trace，覆盖7个主流多Agent框架。这是目前最系统化的多Agent失败模式研究。
MAST把失败分为三大类14种模式：
FC1: 系统设计失败（41.77%）。 任务执行前就埋下了祸根。
| 失败模式 | 描述 | 频率 |
|---|---|---|
| 角色模糊 | Agent的角色定义不清晰，职责重叠或缺失 | 最高频 |
| 任务定义模糊 | Task描述缺乏约束，Agent不知道什么算完成 | 高频 |
| 缺失约束 | 没有限制Agent的行为边界 | 中频 |
FC2: Agent间对齐失败（36.94%）。 任务执行中Agent之间的协作出问题。
| 失败模式 | 描述 |
|---|---|
| 错误级联 | 上游Agent的错误传播到下游，被当作权威输入接受 |
| 上下文丢失 | Agent不知道其他Agent已经做了什么，重复劳动 |
| 无限协商 | 两个Agent反复迭代无法收敛，烧Token无产出 |
| 集体幻觉 | 一个Agent编造的「事实」被其他Agent当真 |
| 角色矛盾 | 两个Agent对同一对象做出冲突决策 |
| 目标漂移 | 系统忘记原始目标，聚焦局部子目标 |
| 循环依赖死锁 | A等B，B等C，C等A，系统冻结 |
| 语义漂移 | 概念含义在Agent间逐渐偏移，最终不一致 |
| 阿谀奉承 | Agent互相附和缺乏批判性思维，集体偏见 |
FC3: 任务验证失败（21.30%）。 完成的步骤没有被检查就进入了下一步。
| 失败模式 | 描述 |
|---|---|
| 模糊归因 | 无法确定哪个Agent做了什么决策，审计不可能 |
| 编排过载 | 中央编排器成为瓶颈，拖慢整个系统 |
| 共享资源争用 | 多个Agent同时写同一个资源，没有协调 |
| 过度委托 | Agent把什么都委派给别人，自己什么不做 |
| 容量崩溃 | 体积超过阈值后系统丧失协调能力 |
7.2 关键发现
模型不是瓶颈，架构才是。 79%的失败来自规范和协调问题。Gartner 2025年AI部署调查中88%的项目失败率，大部分不是因为LLM差，而是Agent之间的架构是事后补的。
错误复合传播。 Augment Code的「Bag of Agents」分析发现，朴素多Agent管线累积错误的速度是单Agent的17倍。不是每个Agent更差，而是错误在交接点乘法增长而非有界传播。
Demo vs Production的鸿沟。 Composio 2025 AI Agent报告记录了从业者知道但很少直说的现象：大部分多Agent系统是为demo条件优化的。干净的输入、合作的输入、可预测的场景。生产环境什么都没有。用户问系统没设计过的问题，上游API返回意外schema，任务跨越Agent边界的方式没人预想过。
pass@1指标高估可靠性20-40%。 ReliabilityBench研究发现，标准的pass@1指标测量的是「最优条件下成功一次」，不是「生产变异性下可靠成功」。CLEAR框架分析发现同一个任务一天60%成功率，另一天25%。团队在优化一个测量错了东西的指标。
7.3 三个最常见的生产事故模式
模式1：错误级联
Researcher → [错误数据] → Analyst → [基于错误数据的分析] → Writer → [错误报告]
问题：没有任何节点验证上游输入的正确性
模式2：无限协商循环
Agent A → "我觉得应该这样" → Agent B → "不对，应该那样" → Agent A → "不对..."
问题：没有终止条件，没有仲裁者，Token烧到预算上限
模式3：上下文不一致
Agent A 基于数据X做了决策 → Agent C 开始工作时数据X已被Agent B更新
问题：消息传递式的记忆，Agent C拿着5分钟前的过时状态在工作来源：UC Berkeley MAST arXiv 2503.13657 2025.03, agentscodex.com MAST企业分析 2026.03, codexical.com多Agent编排失败 2026.05, zartis.com复合错误问题 2026, Augment Code Bag of Agents分析 2026
8. 辩证看待：多Agent不是越多越好
8.1 「Bag of Agents」反模式
多Agent领域最大的认知陷阱：认为Agent越多越好。Augment Code 2026年的分析把这个直觉打碎了。
朴素的推理是这样的：一个Agent不够强，那多加几个专业Agent，让它们协作，整体性能就上去了。实际发生的是：每多一个Agent，就多一个交接点，每个交接点都是一个潜在失败点。Agent A把输出交给Agent B，B在A的输出基础上推理，A的错误被B当作事实接受，B在错误基础上产出新的错误，传给C。
MAST研究的数据：在最坏情况下，多Agent变体比单Agent顺序推理的性能差39%到70%。这个结论在四个基准测试和三个模型系列上一致。
这并不意味着多Agent没用。它意味着多Agent的价值有严格的条件：架构必须与任务对齐，交接点必须有验证机制，终止条件必须在设计时就确定。
8.2 什么时候不该用多Agent
三个判断标准：
LLM调用总共只有1-3次。 如果你的「Agent」就是调一次LLM、用一两个工具、返回结果，直接用OpenAI SDK或Anthropic API写50行Python比引入任何框架都简单。框架的开销（CrewAI约100ms/次，LangGraph约50ms/次）在这种场景下是净损失。
任务边界清晰且线性。 A→B→C→完成的流程，如果每一步都是确定性的（不需要循环、不需要条件分支、不需要人工确认），用普通的Python函数调用就够了。LangGraph的图模型在不需要循环和分支时是过度设计。
纯RAG场景。 检索+回答的pipeline不需要Agent框架。LangChain（不是LangGraph）或LlamaIndex是更合适的工具。
8.3 2026年Q1生产验证的存活模式
buildtest.run的Q1 2026生产报告总结了几条经过验证的模式：
Orchestrator + Workers，不是Peer-to-Peer。 生产环境中存活的模式都有一个中央编排器（或确定性控制器），它决定哪一步分给哪个Agent。专业Agent之间不直接通信，只跟编排器通信。编排器拥有路由、状态和终止权。这不如swarm优雅，但可靠得多。
共享状态存储，不是消息传递。 消息传递式的记忆在两个Agent需要在不同时间操作同一信息时会崩溃。Agent C开始工作时，Agent D可能刚刚更新了底层记录。如果C只知道5分钟前传过来的信息，它在过时状态上工作。存活的系统都把状态外化到一个共享层（向量库、结构化数据库，或两者兼有），Agent之间的消息传的是指针，不是数据负载。
先定义契约再写Agent。 在写任何Agent之前，先写好输入schema、输出schema和失败模式。有效输入长什么样？有效输出长什么样？Agent返回半成品时下一步怎么办？大部分实现对这个问题的回答是沉默，下一个Agent把沉默当作有效输入处理。
8.4 成本结构：多Agent的15倍Token税
多Agent系统消耗约15倍于单Agent的Token（buildtest.run Q1 2026数据）。每次交接携带上下文，每次协调消息都花钱。demo中看起来优雅的模式在生产体量下经济灾难性。大部分团队在第二个月的账单上发现这个问题。
三个成本控制手段：
模型分层。 研究/提取类Agent用便宜模型（GPT-4o-mini、Claude Haiku），综合/写作类Agent用强模型（GPT-4o、Claude Sonnet）。
max_iter硬限制。 每个Agent设5-8步上限。生产环境在代码审查中把这个作为团队标准强制执行。
Token预算告警。 用AgentOps或LangSmith设置每轮预算上限。$X/run的kill switch防止prompt injection攻击迫使昂贵循环。
来源：Augment Code Bag of Agents分析 2026, buildtest.run多Agent生产Q1 2026, zartis.com复合错误 2026, codexical.com编排失败 2026.05, alicelabs.ai CrewAI企业部署 2026
9. 选型建议：什么场景用什么框架
9.1 决策树
你的需求是什么？
│
├─ 需要快速原型（2周内MVP）
│ └─ CrewAI
│ 理由：角色抽象最直观，30分钟出demo
│
├─ 需要生产级可靠性
│ └─ LangGraph
│ 理由：durable execution, checkpointing, LangSmith可观测
│
├─ 需要条件分支、循环、人在回路
│ └─ LangGraph
│ 理由：interrupt原语是生产级HITL的唯一选择
│
├─ 任务自然分解为专业角色（研究→分析→写作）
│ └─ CrewAI（原型）→ LangGraph（生产）
│ 理由：先用CrewAI验证逻辑，再用LangGraph重写为可控工作流
│
├─ 需要Agent间对话/辩论/共识
│ └─ AutoGen (AG2) 或 Microsoft Agent Framework
│ 注意：AutoGen维护模式，新项目走MAF
│
├─ 在微软生态中（Azure/M365/GitHub Copilot）
│ └─ Microsoft Agent Framework
│ 理由：原生集成Azure生态
│
├─ LLM调用总共1-3次
│ └─ 不用框架，直接用provider SDK
│ 理由：框架开销是净损失
│
└─ 纯RAG（检索+回答）
└─ LangChain 或 LlamaIndex
理由：不需要Agent编排层9.2 常见选型错误
按GitHub Stars选。 三个框架都20K+ stars，信号是噪音。生产适配性比流行度重要。
自己造框架。 「我们在OpenAI SDK上写个薄层。」6个月后你重建了一个更差的LangGraph。不要这么做。用框架，在编排层定制。
把框架选择当作永久决策。 迁移痛苦但可行。框架迭代快。今天的选择18个月后可能不是最优解。为可替换性设计架构。
9.3 一个务实的迁移路径
很多团队的实践路径：CrewAI原型 → LangGraph生产。
Week 1-2: CrewAI快速验证
└─ 确认Agent分工是否合理、任务依赖是否正确
Week 3-6: LangGraph重写
└─ 加入checkpointing、HITL、可观测性、错误处理
Week 7-8: 生产部署
└─ LangSmith追踪 + Token预算 + 成本告警CrewAI的Agent/Task/Crew抽象非常适合验证「这个任务该不该拆成多个Agent」「拆成几个」「各自的角色是什么」。验证完成后，用LangGraph的StateGraph重写，获得生产级的状态管理、错误恢复和可观测性。
来源：internative.net框架对比 2026, similarlabs.com框架对比 2026, innovatrixinfotech.com框架对比 2026, bigaiagent.tech框架对比 2026
10. 总结与下一篇预告
10.1 核心要点
2026年的Agent协议生态形成了清晰的三层结构。MCP（Anthropic主导）解决Agent到工具的连接，A2A（Google主导）解决Agent到Agent的连接，AP2解决Agent间的支付和结算。三者都在Linux基金会AAIF治理下，150+组织支持，三大云厂商全部原生集成。MCP和A2A不是竞争关系，是互补层。
A2A协议的三个核心原语：Agent Card是Agent的数字名片（发布在/.well-known/agent.json），Task是有状态的工作单元（submitted→working→completed），Transport用JSON-RPC 2.0 over HTTPS + SSE。v1.0引入的签名Agent Card解决了跨组织信任问题，这是企业采购的解锁功能。
CrewAI用角色团队抽象让多Agent开发门槛降到最低。Agent的身份三要素（role/goal/backstory）是输出质量的最大杠杆。Task的context参数实现信息在Agent间传递。Flow模式补充了精确控制流能力。30分钟出demo，适合原型验证。
LangGraph用StateGraph把Agent工作流变成有向图。Checkpointing是一等公民，提供崩溃恢复、时间旅行调试和评估管线能力。interrupt原语让人在回路从补丁变成原生特性。LangSmith深度集成提供生产级可观测性。Klarna、Uber、LinkedIn的生产选择。
多Agent协作的失败率远高于直觉。MAST Taxonomy揭示了14种失败模式，79%来自架构设计而非模型能力。错误在交接点乘法增长，朴素多Agent管线累积错误17倍于单Agent。pass@1指标高估可靠性20-40%。Orchestrator+Workers是Q1 2026唯一稳定存活的拓扑。先定义契约再写Agent，先外化状态再考虑消息传递。
选型决策：CrewAI原型快，LangGraph生产稳，AutoGen已维护模式。务实路径是CrewAI验证逻辑后用LangGraph重写为生产系统。LLM调用1-3次不用框架，纯RAG用LangChain/LlamaIndex。
10.2 下一篇预告
第11篇：Agent记忆系统------让AI拥有长期记忆，从MemGPT到Letta实战
这篇讲的是多个Agent怎么协作。下一篇回到单个Agent的内部能力：记忆。LLM本质无状态，Agent的连续性完全依赖外部记忆管理。从全量上下文到RAG到Agentic RAG再到长期记忆产品化，记忆系统的演进路径是什么。Letta（前身MemGPT）怎么像操作系统一样管理上下文窗口，用热数据/温数据/冷数据三级架构实现虚拟内存管理。Mem0和Zep等记忆服务怎么选型。怎么为Agent添加跨会话的长期记忆。
系列推荐阅读：
本文数据来源：Linux Foundation AAIF Press Release（2026.04.09，150+组织，22K+ GitHub stars，5种语言SDK）、agentmarketcap.ai A2A一周年分析（2026.04.23）、PRNewswire A2A新闻稿（2026.04）、rapidclaw.dev A2A完整指南2026、a2a-protocol.org官方规范v1.2、UC Berkeley MAST Taxonomy（arXiv 2503.13657，2025.03发表，2025.10 v3更新）、agentscodex.com MAST企业失败分析（2026.03）、codexical.com多Agent编排失败分析（2026.05）、zartis.com复合错误问题分析（2026）、Augment Code「Bag of Agents」分析（2026）、buildtest.run多Agent生产报告Q1 2026、Composio 2025 AI Agent Report、ReliabilityBench研究、juejin.cn CrewAI完全指南v1.14.3（2026.04）、alicelabs.ai CrewAI企业指南2026、aiskillnav.com CrewAI教程2026、josenobile.co LangGraph 2.0指南（2026）、autolearningagents.com LangGraph完全指南、cowork.ink LangGraph教程2026、appscale.blog Serverless多Agent LangGraph+AgentCore 2026、similarlabs.com CrewAI vs AutoGen vs LangGraph 2026、innovatrixinfotech.com框架对比2026、nomadx.ae AI Agent框架对比2026.07、internative.net框架对比2026、bigaiagent.tech框架对比2026。