2025年初,AI Agent通信领域还处在一触即发的标准战争状态:Anthropic的MCP负责连接工具,Google的A2A负责Agent间通信,IBM的ACP同样瞄准Agent间互操作。三大科技巨头、三套协议,行业似乎注定要经历数年的分裂。但事实出乎所有人意料——到2025年底,IBM将ACP并入A2A,Anthropic将MCP捐给Linux基金会,三大协议在12个月内演变为一个清晰的双层协议栈:MCP负责Agent到工具的垂直连接,A2A负责Agent到Agent的水平协调。2026年3月A2A发布v1.0正式版,标志着多Agent协作进入协议原生时代。本文基于最新协议规范、生产案例和学术论文,深度拆解协议归一后六大实战协作模式。
| 协议 | 发起方 | 发布时间 | 定位 | 2026年现状 |
|---|---|---|---|---|
| MCP | Anthropic | 2024.11 | Agent→工具连接 | 月下载97M+,10K+ Server,捐给AAIF |
| A2A | 2025.04 | Agent→Agent协调 | v1.0稳定版,150+组织支持,捐给AAIF | |
| ACP | IBM | 2025.03 | Agent间互操作 | 2025.08并入A2A,历史协议 |
关键转折点:2025年8月IBM宣布ACP并入A2A,IBM Research总监Kate Blair加入A2A技术指导委员会(TSC),与Google、Microsoft、AWS、Cisco、Salesforce、SAP、ServiceNow的代表共同治理。ACP的REST-first设计理念(可用cURL直接调用)被吸收进A2A的gRPC传输层,BeeAI平台迁移至A2A适配器。ACP的DeepLearning.AI课程在2026年2月下架,替换为A2A课程。
┌─────────────────────────────────────────────────────┐
│ 应用层(业务逻辑) │
├─────────────────────────────────────────────────────┤
│ A2A层(水平): Agent发现 · 任务委派 · 结果交换 │
│ Agent Card · Task生命周期 · 签名验证 · 多租户 │
├─────────────────────────────────────────────────────┤
│ MCP层(垂直): 工具调用 · 资源读取 · Prompt模板 │
│ JSON-RPC · Streamable HTTP · 10K+ Server生态 │
├─────────────────────────────────────────────────────┤
│ 传输层:HTTP/gRPC/JSON-RPC/stdio │
└─────────────────────────────────────────────────────┘
这个分层的核心洞察是:MCP扩展单个Agent能"看到"和"做到"的事情,A2A解决多个自主Agent之间如何协商、委派和协调的问题。类比:MCP是USB-C(通用外设连接器),A2A是HTTP(服务间通信协议)。两者不竞争,而是互补叠加。
| 特性 | v0.3 | v1.0 |
|---|---|---|
| 传输协议 | HTTP+JSON | HTTP+JSON / gRPC / JSON-RPC三绑定 |
| Agent Card | 明文JSON | JWS签名 + RFC 8785规范化 |
| 多租户 | 无 | 原生tenant字段 |
| 认证 | 基础Bearer | API Key / OAuth 2.0 / OIDC / mTLS全栈 |
| Part类型 | TextPart/FilePart/DataPart分离 | 统一Part结构 |
| 枚举值 | 小写snake_case | SCREAMING_SNAKE_CASE前缀 |
| 错误处理 | RFC 9457 Problem Details | google.rpc.Status + ErrorInfo |
架构原理:最经典的协作模式。一个编排者Agent接收高层请求,通过A2A发现并委派任务给专职工作者Agent,每个工作者通过MCP访问自己专属的工具集。编排者维护全局上下文,工作者保持无状态。
工作流:
sequenceDiagram
participant User
participant Orchestrator
participant Researcher
participant Coder
participant Reviewer
User->>Orchestrator: 提交需求
Orchestrator->>Orchestrator: 解析Agent Card
Orchestrator->>Researcher: A2A Task: 调研
Researcher->>Researcher: MCP: 搜索/Web/数据库
Researcher-->>Orchestrator: 返回调研结果
Orchestrator->>Coder: A2A Task: 编码
Coder->>Coder: MCP: GitHub/代码执行
Coder-->>Orchestrator: 返回代码
Orchestrator->>Reviewer: A2A Task: 审查
Reviewer->>Reviewer: MCP: 测试/安全扫描
Reviewer-->>Orchestrator: 返回审查报告
Orchestrator-->>User: 汇总输出
关键代码片段(Google ADK):
from google.adk import Agent
from google.adk.a2a import RemoteA2aAgent
# 编排者发现远程Agent
researcher = RemoteA2aAgent("https://agents.corp.com/researcher")
coder = RemoteA2aAgent("https://agents.corp.com/coder")
orchestrator = Agent(
name="orchestrator",
model="gemini-2.5-pro",
sub_agents=[researcher, coder],
instruction="分解用户需求,委派给合适的子Agent执行"
)
优缺点:
| 维度 | 评估 |
|---|---|
| 优势 | 职责清晰、调试简单、易于添加/替换工作者 |
| 劣势 | 编排者是单点瓶颈、水平扩展受限于编排者吞吐 |
| 最佳场景 | 客户服务路由、企业审批流、数据处理管道 |
| 变现潜力 | ★★★★★ — 最通用模式,适合构建SaaS产品 |
生产案例:S&P Global Market Intelligence采用此模式处理金融数据工作流。Tyson Foods和Gordon Food Service构建供应链协作系统,路由Agent将采购请求分发至库存、物流、质检Agent。
架构原理:Agent按顺序排列,前一个Agent的输出(A2A Artifact)是后一个Agent的输入。类似工厂流水线,每站专注一个转换步骤。A2A v1.0的Task状态机(SUBMITTED→WORKING→COMPLETED)天然支持流水线的阶段性推进。
工作流:
# LangGraph流水线实现
from langgraph.graph import StateGraph
graph = StateGraph(PipelineState)
graph.add_node("extract", extract_agent)
graph.add_node("analyze", analyze_agent)
graph.add_node("format", format_agent)
graph.add_node("publish", publish_agent)
graph.add_edge("extract", "analyze")
graph.add_edge("analyze", "format")
graph.add_edge("format", "publish")
# 每个节点通过MCP访问专属工具
# extract → MCP: PDF解析/OCR
# analyze → MCP: 数据库/BI工具
# format → MCP: 模板引擎/图表生成
# publish → MCP: Notion/Slack/Email
优缺点:
| 维度 | 评估 |
|---|---|
| 优势 | 确定性高、审计追踪完整、每站可独立替换模型 |
| 劣势 | 串行瓶颈、前站错误会级联放大、灵活性低 |
| 最佳场景 | 文档处理、报告生成、合规审核 |
| 变现潜力 | ★★★★☆ — 适合自动化工具产品 |
关键设计要点:A2A的Artifact机制让流水线间的数据传递有了标准格式。v1.0统一了Part类型(TextPart/FilePart/DataPart合并),流水线中Agent间可以传递文本、文件、结构化数据,不再需要自定义序列化。
架构原理:没有中央编排者,Agent作为平等节点直接通信协商。适合创意性任务、共识决策、或需要多视角融合的场景。A2A的Agent Card发现机制让Agent能动态找到对等节点。
工作流:
Agent A ←── A2A Task ──→ Agent B
│ │
MCP MCP
(工具集A) (工具集B)
│ │
└──── 共享状态 ────────────┘
典型场景:法律合同审核——律师Agent、合规Agent、风险Agent各自独立分析合同,通过A2A交换发现和质疑,最终汇聚审核意见。每个Agent拥有不同的领域工具(法条数据库、风险评分API、合规检查列表)。
优缺点:
| 维度 | 评估 |
|---|---|
| 优势 | 无单点故障、弹性高、适合共识和创意任务 |
| 劣势 | 调试极难、可能出现死锁或无限循环、一致性难保 |
| 最佳场景 | 创意协作、多视角评估、去中心化决策 |
| 变现潜力 | ★★★☆☆ — 技术门槛高,更适合内部工具 |
反模式警告:对等协作中最大的陷阱是Agent间出现"礼貌无限循环"——两个Agent互相推让任务、反复确认、永远无法收敛。解决方案是设置最大轮次限制和超时熔断。CrewAI的max_iter参数和LangGraph的递归限制都是为此设计。
架构原理:模仿企业组织架构,高层Agent负责战略规划和资源分配,中层Agent管理具体子团队,底层Agent执行原子任务。当Agent数量超过7个时,层级结构是唯一可行的管理方式。
三层架构示例:
┌─────────────┐
│ CEO Agent │ 战略层
└──────┬──────┘
┌────────────┼────────────┐
┌─────┴─────┐ ┌────┴────┐ ┌────┴─────┐
│产品经理 │ │工程经理 │ │QA经理 │ 战术层
│Agent │ │Agent │ │Agent │
└─────┬─────┘ └────┬────┘ └────┬─────┘
┌──┴──┐ ┌───┼───┐ ┌─┴─┐
设计 文案 前端 后端 DevOps 测试 安全 执行层
关键代码片段(CrewAI层级模式):
from crewai import Agent, Crew, Task
manager = Agent(
role="项目总监",
goal="协调各子团队高效完成项目",
backstory="10年项目管理经验",
allow_delegation=True # 允许向下委派
)
frontend_lead = Agent(
role="前端负责人",
goal="管理前端开发团队",
allow_delegation=True
)
crew = Crew(
agents=[manager, frontend_lead, ...],
tasks=[...],
process="hierarchical", # 层级模式
manager_agent=manager
)
优缺点:
| 维度 | 评估 |
|---|---|
| 优势 | 可扩展(支持20+Agent)、职责分明、与组织架构匹配 |
| 劣势 | 延迟叠加(每层一跳)、上下文衰减、中间层可能成为瓶颈 |
| 最佳场景 | 大型企业项目、跨部门工作流、复杂供应链 |
| 变现潜力 | ★★★★★ — 企业客户最认可的模式 |
生产数据:Genentech的药物发现系统采用三层层级架构,协调10+专职Agent(分子分析、法规合规、临床试验设计),科学家聚焦突破性发现,Agent处理数据处理、文献综述和实验设计。
架构原理:多个Agent同时处理独立子任务,结果由汇总Agent合并。A2A v1.0的gRPC传输和流式支持让并行调用的延迟大幅降低。适合可分解、无依赖的任务。
性能对比:
| 配置 | 串行耗时 | 并行耗时 | 加速比 |
|---|---|---|---|
| 3个数据源调研 | 45s | 12s | 3.75x |
| 5份文档翻译 | 120s | 28s | 4.3x |
| 8个代码仓库分析 | 200s | 35s | 5.7x |
关键代码片段(LangGraph并行节点):
from langgraph.graph import StateGraph
graph = StateGraph(ParallelState)
# 添加并行节点(LangGraph自动并行执行无依赖节点)
graph.add_node("source_a", agent_query_a)
graph.add_node("source_b", agent_query_b)
graph.add_node("source_c", agent_query_c)
graph.add_node("merge", merge_agent)
graph.add_edge("source_a", "merge")
graph.add_edge("source_b", "merge")
graph.add_edge("source_c", "merge")
# source_a/b/c并行执行 → 全部完成后触发merge
优缺点:
| 维度 | 评估 |
|---|---|
| 优势 | 吞吐量最高、延迟最低、可水平扩展 |
| 劣势 | 仅适用于无依赖任务、结果合并可能有冲突、成本倍增 |
| 最佳场景 | 多源数据采集、批量处理、多模型投票 |
| 变现潜力 | ★★★★☆ — 适合高吞吐SaaS |
成本警示:多Agent系统Token消耗可达单Agent的15倍。并行模式下,5个Agent同时运行意味着5倍API调用。策略是:简单任务用小模型(如Haiku),复杂推理才用大模型(如Opus),并行中每个Agent按需选模型。
架构原理:运行时根据任务特征动态选择协作模式。简单查询走单Agent,多步骤任务走流水线,复杂决策启层级控制,批量操作切并行。这是2026年最前沿的模式,需要编排层具备"模式路由"能力。
决策引擎:
class AdaptiveOrchestrator:
def select_pattern(self, task: Task) -> str:
complexity = task.estimate_complexity()
dependencies = task.analyze_dependencies()
agent_count = task.required_agents()
if agent_count == 1:
return "single_agent" # 单Agent直接处理
elif dependencies == "sequential":
return "pipeline" # 流水线
elif dependencies == "independent":
return "parallel" # 并行
elif agent_count > 7:
return "hierarchical" # 层级控制
else:
return "orchestrator_worker" # 编排者-工作者
优缺点:
| 维度 | 评估 |
|---|---|
| 优势 | 最优性价比、适应性强、资源利用率最高 |
| 劣势 | 实现复杂度极高、模式切换可能有状态丢失、调试困难 |
| 最佳场景 | 通用Agent平台、SaaS产品、需要服务多样化需求 |
| 变现潜力 | ★★★★★ — Agent平台的核心差异化 |
行业实践:Amazon Q Developer使用混合自适应模式协调代码现代化Agent——依赖分析Agent并行扫描数千个Java应用,分析完成后切换为流水线模式逐个升级(语法更新→依赖更新→测试→文档),最后层级汇总报告。
| 维度 | 编排者-工作者 | 流水线 | 对等协作 | 层级控制 | 并行执行 | 混合自适应 |
|---|---|---|---|---|---|---|
| Agent数 | 3-7 | 3-5 | 2-4 | 7-20+ | 3-10 | 动态 |
| 延迟 | 中 | 中-高 | 低-中 | 高 | 最低 | 动态 |
| 可靠性 | 中 | 高 | 低 | 高 | 中 | 最高 |
| 调试难度 | ★★ | ★ | ★★★★ | ★★★ | ★★ | ★★★★★ |
| 成本 | 中 | 中 | 低 | 高 | 高 | 最优 |
| 适合框架 | CrewAI, ADK | LangGraph | AutoGen/AG2 | CrewAI | LangGraph | LangGraph+ADK |
| A2A依赖 | 强 | 中 | 强 | 强 | 中 | 强 |
| MCP依赖 | 强 | 强 | 中 | 强 | 强 | 强 |
graph TB
subgraph "A2A层 - Agent间通信"
RG[路由Agent] -->|A2A Task| BA[计费Agent]
RG -->|A2A Task| TA[技术支持Agent]
RG -->|A2A Task| SA[销售Agent]
end
subgraph "MCP层 - 工具访问"
BA -->|MCP| SF[(Salesforce)]
BA -->|MCP| ST[(Stripe)]
TA -->|MCP| KB[(知识库)]
TA -->|MCP| JIRA[(Jira)]
SA -->|MCP| CRM[(CRM)]
SA -->|MCP| EM[(Email)]
end
subgraph "基础设施"
AR[Agent Card<br/>注册中心]
GW[MCP网关<br/>权限/审计/限流]
OB[可观测性<br/>OpenTelemetry]
end
RG --> AR
BA --> AR
TA --> AR
SA --> AR
BA --> GW
TA --> GW
SA --> GW
RG --> OB
层1:Agent注册中心(A2A必需)
每个Agent发布Agent Card至/.well-known/agent-card.json,声明能力、I/O Schema和认证方式。v1.0支持JWS签名,确保Agent身份可加密验证。
{
"name": "BillingAgent",
"version": "1.0.0",
"capabilities": ["invoice_query", "payment_processing"],
"supportedInterfaces": [{
"protocolVersion": "1.0",
"transport": "grpc"
}],
"authentication": {
"type": "oauth2",
"scopes": ["read:billing", "write:payments"]
}
}
层2:MCP网关治理
MCP Server数量超过10个时,必须建立中央网关:统一路由所有MCP调用、每个Agent仅授予最小权限工具集、全量审计日志。2026年初MCP已披露95个CVE,主要涉及Prompt注入和工具伪装攻击,网关是第一道防线。
层3:可观测性
分布式追踪将A2A委派链串联为单一Trace(OpenTelemetry)、按Agent追踪LLM Token和MCP调用量、失败模式分析识别哪些Agent在什么条件下失败。
层4:熔断与隔离
Circuit Breaker在Agent连续失败N次后自动隔离、A2A Task委派设置显式超时、Fallback Agent在主Agent不可用时自动切换。Dapr Agents v1已内置熔断器。
你的任务需要几个Agent?
├─ 1个 → 单Agent + MCP(不需要A2A)
├─ 2-7个
│ ├─ 任务有依赖关系?
│ │ ├─ 是,且顺序固定 → 流水线模式
│ │ └─ 是,但需动态路由 → 编排者-工作者模式
│ └─ 任务完全独立?
│ ├─ 是 → 并行执行模式
│ └─ 否,需要协商 → 对等协作模式
└─ 7个以上
└─ 层级控制模式(上层管理下层)
需求多样化、流量波动大?
└─ 混合自适应模式
| 变现方向 | 适合模式 | 预估投入 | 市场空间 |
|---|---|---|---|
| Agent SaaS平台 | 混合自适应 | 6-12月 | 百亿级 |
| 企业工作流自动化 | 编排者-工作者/层级 | 3-6月 | 十亿级 |
| A2A/MCP培训 | 全部 | 1-2月 | 千万级 |
| MCP Server市场 | 配合所有模式 | 2-4月 | 亿级 |
| Agent安全审计 | 全部 | 3-6月 | 十亿级 |
| 垂直行业方案 | 层级控制 | 4-8月 | 行业而定 |
训练营可行方案:「MCP+A2A双栈工程师认证」——第1-2周MCP Server开发与治理,第3-4周A2A Agent Card设计与Task生命周期,第5-6周六大协作模式实战(每种模式一个项目),第7-8周生产部署(可观测性/安全/熔断)。定价区间8K-15K/人,目标学员:有Python基础的AI应用开发者。
当前MCP+A2A双栈覆盖了工具访问和Agent协调,但仍缺失关键层——商业层。当Agent A委派任务给Agent B并消耗资源时,没有标准化的计费、SLA和跨组织支付机制。
Google已推出Agent Payments Protocol(AP2)作为A2A的配套协议,60+组织(Mastercard、PayPal、Adyen、Coinbase等)参与制定。AP2使用Mandates(密码学签名的数字合约)作为购买意图的可验证证明,支持传统支付、银行转账和加密货币。这可能成为协议栈的第三层——Agent间商业层。
同时,Agent Network Protocol(ANP)正在解决开放互联网上的Agent发现问题——当前的Agent Card仅在已知端点可用,缺少全局注册和发现机制。ANP试图成为Agent的DNS。
完整的未来协议栈可能是:
应用层 业务逻辑
协调层 A2A (Agent间通信)
工具层 MCP (Agent到工具)
商业层 AP2/UCP (支付与SLA) ← 即将到来
发现层 ANP (全局Agent发现) ← 探索阶段
[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。
