A2A握手税：多智能体互通实测

概述

2026年多智能体系统的战场，已经从"谁的框架更强"转移到"谁的协议能互通"。继Anthropic的MCP（Model Context Protocol）统一了智能体与工具之间的接口之后，Google于2025年4月发布的A2A（Agent2Agent）协议，正在把"智能体与智能体"之间的通信也标准化。更关键的是，IBM主导的ACP协议已在Linux基金会下并入A2A，ANP则押注去中心化发现——一份arXiv综述（2505.02279）首次把MCP、A2A、ACP、ANP明确划归到不同的协调层。本期聚焦一个被忽视的工程真相：把进程内的编排（LangGraph/CrewAI）改成跨厂商协议编排（A2A/MCP），要交一笔结构性的"握手税"——发现、序列化、任务状态轮询、网络往返层层叠加。我们把这层税单拆开，给出什么场景该用进程内、什么场景必须上协议的判定线。

协议栈全景：四层各管一段

很多人把MCP和A2A当成"二选一"，这是2026年最常见的认知误区。它们根本不在同一层：

MCP管的是"智能体怎么调用一个计算器、一个数据库"；A2A管的是"一个写代码的智能体怎么把测试任务委托给另一个跑测试的智能体"。arXiv 2505.02279给出的定位很清楚：MCP是资源访问层，A2A/ACP是任务委托层，ANP是网络发现层。它们是叠加关系，不是替代关系。一个生产级多智能体系统，往往是MCP打底（接工具）、A2A架在中间（跨agent委托）、上层用LangGraph做有状态编排。

进程内编排 vs 协议编排：握手税的根源

这是本期最核心的判断。多智能体协作有两条完全不同的技术路径，税费差异巨大：

路径一：进程内编排（LangGraph / CrewAI / AutoGen） 所有agent跑在同一个进程里，共享一个内存中的状态对象（State Graph）。agent之间传递的是Python对象引用，没有序列化、没有网络往返、没有握手。LangGraph的supervisor模式里，supervisor agent把消息塞进state["messages"]，worker agent直接读这个字段——一次函数调用级别的事。

路径二：协议编排（A2A / MCP） 每个agent是独立的HTTP服务，可能由不同厂商、不同框架、不同语言实现。agent A要委托agent B，必须：拉取B的Agent Card（发现）→ 按JSON-RPC封装请求 → 走HTTP往返 → B轮询任务状态（submitted/working/completed）→ B返回Artifact → A反序列化。

握手税就堆叠在路径二的每一步里。我们把一次"delegate任务"的代价拆开看：

实测层面，baeseokjae的2026生产指南给出了一个值得记住的数字：并行fan-out只有在墙钟延迟比token花费更重要时才值得那笔开销——典型是3倍延迟成本换吞吐。这3倍，本质上就是握手税。LangGraph的官方建议也印证了这点：langgraph-supervisor预构件能几分钟搭起原型，但代价是"牺牲状态归属权"——状态被推到协议层后，调试和回放都变难。

A2A的三大原语：Agent Card、Task、Artifact

要理解A2A为什么能跨厂商，必须看它的三个核心原语，它们直接决定了握手税的结构。

Agent Card（智能体名片）：每个A2A server在/.well-known/agent.json暴露一个JSON文档，声明自己的能力。这是A2A的"服务发现"——调用方先GET这张卡，才知道对方会什么、要不要流式、认证方式是什么。一张典型Agent Card约1-2KB，包含name、description、skills、capabilities.streaming等字段。这张卡本身就要进上下文——如果系统里有20个agent，光发现阶段就可能吃掉几十KB的token。这是握手税里最容易被忽视的一笔：能力声明的token成本。

Task（任务）：A2A不传"消息"，传"任务"。任务有明确的生命周期：submitted → working → input-required → completed / failed / canceled。这个状态机是A2A相对MCP最大的设计差异——MCP是无状态的工具调用（call一次拿结果），A2A是有状态的长期任务。好处是支持人机协作中断（input-required时暂停等人补输入）和长任务流式反馈；代价是调用方必须轮询或订阅任务状态，握手税从"一次往返"变成"多次往返+状态机维护"。

Artifact（产物）：任务完成后，结果以Artifact形式返回，支持流式（SSE）。这意味着A2A天然适合"写文档→审文档→改文档"这种增量产出场景。

# A2A 调用方：发现 → 委托 → 订阅状态（a2a-sdk 风格）
import asyncio
from a2a.client import A2AClient, A2ACardResolver

async def delegate_test(remote_agent_url: str):
    # 1. 握手：拉取 Agent Card（约 1-2KB，会进上下文）
    resolver = A2ACardResolver(httpx_client=None, base_url=remote_agent_url)
    card = await resolver.get_agent_card()
    client = A2AClient(agent_card=card)

    # 2. 委托：创建任务，附上 payload
    payload = {"message": {"role": "user", "parts": [{"text": "跑一下 pytest 并报告失败用例"}]}}
    task = await client.send_task(payload)

    # 3. 订阅状态：握手税在这里——状态机轮询/SSE，非单次返回
    async for event in client.send_task_streaming(payload):
        if event.status.state == "input-required":
            return await handle_human_input(event)   # 长任务可中断
        if event.status.state in ("completed", "failed"):
            return event.artifacts                    # 拿产物

这段代码相对LangGraph进程内调用的增量，就是握手税的全部来源：一次Card拉取、JSON-RPC封装、SSE流式订阅、状态机分支处理。功能更强，但每一行都对应真实成本。

ACP并入A2A：协议归一的拐点

2025年下半年到2026年初，智能体协议领域发生了一个决定性事件：IBM的ACP正式并入Google的A2A，统一在Linux基金会下托管。这不是技术细节，而是整个赛道的拐点信号。

ACP（Agent Communication Protocol）原本是IBM为BeeAI框架设计的agent间通信标准，特别强调异步长任务和离线发现。A2A和ACP在功能上高度重叠（都做agent↔agent），区别主要在传输细节和任务模型。两个标准并行存在意味着跨厂商互通会分裂成两个生态——这正是当年OAuth碎片化、API网关碎片化重演。

Linux基金会主导的归并做了三件事：①A2A吸收了ACP的长任务和异步发现能力；②BeeAI的agent现在原生说A2A；③ANP的去中心化发现层作为A2A的补充而非竞争。结果是agent↔agent层基本收敛到A2A一个事实标准，和MCP在tool层的地位对称。这条信息对选型极其重要：2026年再为agent间通信自研私有协议，等于2015年还在自研RPC框架——基本是在交重复发明的税。

归并后的协议栈呈"三明治"结构：底层MCP（接工具）+ 中层A2A（跨agent）+ 编排层（LangGraph/CrewAI做有状态流程）。ANP则负责那些需要DID身份和去中心化发现的场景（比如跨组织的agent网络）。

何时该上协议：握手税的判定线

握手税不是越低越好——它买来的是跨厂商、跨语言、可独立部署、可独立扩缩容。关键是在正确的层付这笔税。我们给出一条判定线：

留在进程内（LangGraph/CrewAI）的场景：agent都是你自己写的、同语言、同部署单元、需要共享复杂状态、对延迟敏感（如实时对话编排）。此时握手税纯亏——你要的是编译期类型安全、共享内存、微秒级切换。比如一个"检索+生成+审核"三agent流水线，全部Python、跑在一个容器里，用LangGraph的supervisor模式，状态共享一把梭。

必须上A2A的场景：agent来自不同厂商（你的agent要调用Salesforce的官方agent、调用同事用CrewAI写的agent）、需要独立扩缩容（重计算agent单独上GPU池）、长任务需要断点续传（input-required暂停等人）、要做能力市场（agent动态发现）。此时握手税买的是真正的解耦。

必须上MCP的场景：凡是"调用一个外部能力"——数据库、文件系统、第三方API、内部遗留系统。这是最低层的税，几乎不可省，除非你完全自己封装SDK（那就是在重复MCP的发明）。

一个反直觉但重要的结论：很多团队在不需要跨厂商时强行上A2A，结果把原本一个Python进程能搞定的事拆成5个HTTP服务，握手税、部署复杂度、调试难度全部翻倍。 Towards AI那篇"We Spent $47K on AI Agents in Production"记录的真实案例——agent陷入11天死循环烧掉$47,000——很大一部分根因就是协议层的重试和状态机在没有良好熔断时互相放大。协议不是越多越好，是越在正确层越好。

flowchart TB
    subgraph PROC["进程内编排（低握手税）"]
        ORCH["编排器 LangGraph/CrewAI"]
        A1["Agent A 同进程"]
        A2["Agent B 同进程"]
        STATE["共享 State Graph 内存对象"]
        ORCH <--> STATE
        A1 <--> STATE
        A2 <--> STATE
    end

    subgraph PROTO["协议编排（高握手税，买解耦）"]
        A2ACLIENT["A2A Client Agent A"]
        CARD[/"Agent Card 发现 1-2KB"/]
        TASK["Task 状态机 submitted/working/completed"]
        A2ASERVER["A2A Server Agent B 异构"]
        A2ACLIENT -->|1 拉Card| CARD
        CARD --> A2ASERVER
        A2ACLIENT -->|2 JSON-RPC over HTTP| TASK
        TASK -->|3 SSE 流式| A2ACLIENT
    end

    subgraph TOOLS["工具层 MCP"]
        M1["DB / 文件 / API"]
    end

    A2 -.->|"跨厂商委托才走协议"| A2ACLIENT
    PROC -.->|"调用外部能力"| TOOLS
    PROTO -.->|"每个agent各自接工具"| TOOLS

    classDef low fill:#d4edda,stroke:#28a745
    classDef high fill:#f8d7da,stroke:#dc3545
    classDef tool fill:#cce5ff,stroke:#007bff
    class PROC,ORCH,A1,A2,STATE low
    class PROTO,A2ACLIENT,CARD,TASK,A2ASERVER high
    class TOOLS,M1 tool

安全与失败模式：协议层的隐性税

握手税之外，协议编排还引入两类隐性成本，选型时必须算进去。

认证与信任传递。进程内编排里，所有agent共享一个信任边界。一旦上A2A，每次委托都要做身份验证（OAuth2、mTLS、API Key），还要处理"agent A是否有权委托agent B执行这个高权限操作"的问题。A2A的Agent Card里带securitySchemes字段，但要你自己把这条信任链实现出来。blueheadline的2026生产安全指南指出，A2A和MCP共享一类安全风险——提示注入通过工具/agent返回值回流——而协议层因为消息要跨网络、跨格式，注入面更大。

状态机放大故障。MCP是无状态的，失败就是一次调用失败，重试即可。A2A是有状态任务，一次委托可能进入working态后卡住，调用方不知道对方是还在跑还是死了。如果没有合理的超时和熔断，就会出现$47K那种长循环。生产级A2A部署必须配齐：任务级超时、canceled态的幂等清理、SSE断线重连、Agent Card缓存（避免每次发现都拉一遍）。

这两类成本叠加，意味着协议编排的运维心智成本远高于进程内。一个经验法则：进程内编排的故障通常是"agent想错了"，可观测性强、好调；协议编排的故障常常是"消息在途中状态错了"，涉及网络+序列化+状态机，调试要拉全链路trace。这就是为什么本期开篇的可观测性话题在协议层尤其关键——没有分布式追踪，A2A系统基本无法运维。

推荐方案

按场景给判定：

1. 纯自有、同栈、强状态共享的多agent（如内部RAG流水线、代码生成+测试闭环）→ LangGraph supervisor/swarm进程内编排，MCP接工具，不要碰A2A。延迟低、好调、省握手税。

2. 需要集成厂商官方agent或跨团队agent（如调用Salesforce/ServiceNow的agent、对接合作伙伴系统）→ A2A做委托层，MCP做各自的工具层，LangGraph/自研编排器做上层流程。这是协议归一后的标准三明治。

3. 长任务+人机协作中断（合同审核需要法务介入、运维变更需要审批）→ A2A的Task状态机（input-required）是当前唯一原生支持的设计，进程内编排要自己造轮子。

4. 跨组织、去中心化、动态发现（agent市场、开放生态）→ ANP做DID身份与发现，A2A做通信。这是最前沿也最不成熟的组合，留作预研。

5. 任何"调用外部能力"的环节（数据库、文件、第三方API）→ 一律MCP，不要自己封SDK。

一句话总括：进程内编排是省税的快车道，协议编排是买解耦的过路费。2026年的正确姿势不是二选一，而是在正确的层各付各的税——MCP接工具、A2A跨agent、LangGraph做编排——把每笔握手税都花在它真正能买来解耦的地方。

参考来源

1. A2A Protocol 官方文档：A2A and MCP 详细对比 — A2A与MCP分层定位的官方说明，Agent Card/Task/Artifact原语定义
2. Agentic AI Protocols Comparison: MCP vs A2A vs ACP vs ANP — K21 Academy — 四大协议架构、传输层、用例并排对比
3. Agent-to-Agent Communication Protocol Standards: A2A, MCP, ACP, and ANP — Zylos Research — 基于arXiv综述2505.02279的协议协调层划分分析
4. Agent Communication Protocol (ACP) — IBM Research — ACP并入A2A、Linux基金会归一的官方说明与迁移指引
5. Multi-Agent System Design: Architecture Patterns for Production AI in 2026 — baeseokjae — 并行fan-out 3倍延迟成本的实测数据与生产权衡
6. We Spent $47K on AI Agents in Production. Here's What Broke — Towards AI — A2A/MCP协议层死循环、状态机放大故障的真实生产案例
7. A2A Protocol v1 2026: How AI Agents Actually Talk to Each Other — Towards AI — A2A 1.0的HTTP/SSE/Agent Card/Task生命周期技术细节

[!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 等场景全覆盖。