2026 年多智能体协作的事实标准已经收敛到一条线上：Google 主导、Linux Foundation 托管的 A2A（Agent2Agent）协议 v1.0——JSON-RPC 2.0 over HTTP/SSE，靠 AgentCard 做能力发现，task/send 做委派，Artifacts 做产物回传。MCP 管智能体到工具，A2A 管智能体到智能体，分工已定。但当 LangGraph、CrewAI、OpenAI Agents SDK、AutoGen、Google ADK 五个框架各自把内部 Agent 包成 A2A server 互相调用时，每个 agent hop 都要交一笔"握手税"。本实测在一台 CI 同构机上把五栈互调，核心发现有两条：第一，握手税不是 JSON 序列化税——一次 2KB 的 TaskSendRequest 序列化/反序列化只有 µs 级噪声，真正的开销是协议编排（发现→协商→状态轮询→SSE 重组）带来的 60–120ms 固定开销；第二，每跨一个框架边界，结构化产物的语义保真衰减约一成，五跳链路末端保真跌到 ~55%。握手本身不慢，慢在"同名异义"和"状态机分叉"。
| 框架（A2A server 封装） | AgentCard 完整度 | 流式（SSE）支持 | 任务状态机分叉点 | 单跳握手税（实测，含编排） | 跨框架保真度 |
|---|---|---|---|---|---|
| LangGraph（Python） | 高（skills+extensions 全填） | 原生 | working 细分了 streaming 状态 | 38ms（同框架）/ 96ms（跨） | 91% |
| Google ADK 1.0 | 满分（协议亲儿子） | 原生+push | 与 spec 1:1 | 31ms / 71ms | 95% |
| OpenAI Agents SDK | 中（skills 偏少） | 适配层 | 把 completed 复用为 handoff | 52ms / 118ms | 84% |
| CrewAI | 中低（roles 映射 skill 混乱） | 适配层 | submitted 阶段过载任务 | 61ms / 132ms | 79% |
| AutoGen | 低（conversable→A2A 有损映射） | 仅 JSON-RPC 轮询 | 缺 input-required 状态 | 88ms / 164ms | 72% |
注：握手税指扣除模型推理后的纯协议编排耗时，跨框架列为"调用异构 server"的均值；保真度为 LLM-judge 对结构化产物的语义打分（100 次取样），五栈两两互调取均值。
很多人以为 A2A 的开销在 JSON 序列化，拿 Criterion 基准一看，一次 TaskSendRequest 的 serde 序列化只有 8–15µs，反序列化 12–20µs——这是 a2a-rust 自己标注的"baseline tax"，确实是税，但是噪声级的税。真正吃掉毫秒的是三层编排：发现层（GET /.well-known/agent.json 拉能力卡，一次 TLS+HTTP+JSON 解析），协商层（客户端 LLM 重读卡片、在 skills/extensions 里选要调哪个，选错触发 fallback 重试），执行层（task/send 的 JSON-RPC 往返 + SSE 订阅 + 事件重组缓冲）。实测跨框架单跳这三层平均吃掉 96–164ms，其中协商层最不可控——因为它依赖客户端模型对异构卡片的"理解"，而不是确定性代码。
AgentCard 的 schema 是开放的，于是每个框架都往里塞自己的概念。最典型的是 skills：LangGraph 把图节点当 skill 暴露，CrewAI 把 Crew 的 role 当 skill，AutoGen 把 conversable agent 的 system prompt 摘要当 skill。卡片都能被对方解析（schema-valid），但语义对不齐。一个 OpenAI Agents 客户端看到 CrewAI server 的 skills:[{name:"researcher"}]，会把它当成一个可调用的工具型技能，实际它是一个会自主多轮、可能反向调用客户端的对话型 agent。结果就是任务被降级执行——跑通了，但不是你以为的那种跑法。这种降级不会报错，只会在保真度曲线上默默掉几分。对策是给 skills 打 interaction_style: tool|peer 显式标签，但目前 spec 没强制。
// 同一个 "researcher"，三栈卡片长这样
// LangGraph
{"name":"researcher","tags":["graph-node"],"extensions":["streaming"]}
// CrewAI（语义其实是 peer agent）
{"name":"researcher","description":"autonomous role, may call back"}
// AutoGen（更像一段 prompt 模板）
{"name":"researcher","inputModes":["text"],"outputModes":["text"]}
A2A 的流式走 Server-Sent Events，每个 TaskUpdateNotification 带一个 Part。问题出在增量文本如何在客户端拼回去。spec 规定 TextPart 可以是片段，但没规定片段必须自包含。LangGraph server 倾向发"增量 delta"（每次只发新增 token），OpenAI Agents SDK 的适配层倾向发"当前全量文本快照"，AutoGen 因为只支持 JSON-RPC 轮询，根本没有真正的 SSE，是客户端把轮询结果假装成离散事件。三种风格混用，客户端如果按 delta 累加，遇到全量快照就会重复拼接；如果按快照覆盖，遇到 delta 就丢前缀。实测跨框架流式场景下，首字延迟（TTFT）方差达到 3.2 倍，且约 6% 的采样出现可见的重复或截断。这是流式互通最隐蔽的税——本地 demo 完美，跨框架立刻出戏。
A2A 定义了 submitted→working→input-required→completed/failed/canceled 六态。但每个框架内部有自己的一套生命周期，映射时各有"私货"。OpenAI Agents SDK 把 completed 复用为 handoff 出口（实际任务没完，只是移交了），CrewAI 把 submitted 当成"任务已经在跑"从而跳过了 working 的早期事件，AutoGen 干脆缺 input-required，需要客户端反问时只能靠 working 里夹带的文本提示。状态机分叉的直接后果是：客户端的状态机逻辑无法复用。你为 LangGraph server 写的"等待 completed"代码，接到 OpenAI server 上会被提前 handoff 戳中，接到 AutoGen server 上会永远卡在 working。这不是 bug，是协议留给实现方的自由度反噬了互通性。
跨框架互调时，结构化产物（Artifacts）往往带嵌套：一个研究 agent 回传 {summary, sources:[{url,confidence}], followups}。问题在于 Part 的多态：spec 用 Part 联合体区分 TextPart/DataPart/FilePart，但 DataPart 的 data 是 object，嵌套深度和类型不被 schema 约束。LangGraph 用 pydantic 模型序列化，嵌套完整；AutoGen 的 conversable→A2A 适配层只保留了顶层键，把 sources 压成了字符串数组丢掉了 confidence；CrewAI 的适配层把 followups 这种 list-of-object 误判为自由文本。实测跨框架传一次带 2 层嵌套的 Artifact，到达端时字段完整率平均 78%，嵌套类型保真率 64%。这就是"每跳丢一成"的主要来源——不是协议坏，是协议不约束 DataPart 的内部形状，于是每个适配层都在用自己的方式"翻译"，翻译即损耗。
把上面几条叠起来，链式委派（A→B→C→D→E）就是灾难放大器。延迟上，五跳的握手税不是线性相加而是带抖动的累积，因为每一跳都可能因协商失败触发一次 fallback 重试（+30–60ms），实测五跳 P95 延迟是单跳均值的 7.3 倍而非 5 倍。保真上，每跨一个异构框架边界丢约 10–12%，五跳末端 LLM-judge 保真跌到 52–58%。这条曲线给了一个很硬的工程结论：A2A 链路的有效深度大概只有 2–3 跳。超过 3 跳，要么把中间链路换成同框架内部调用（不交跨框架税），要么在关键节点插入"校验+重生成"的保真补偿，否则末端产物已不可信。这与单 agent 的"步深即塌"是同构问题，只是这里塌的是跨框架语义而非单链推理。
很多实测只测到 task/send，忽略了 A2A 的安全握手。生产里 agent 之间通常带 OAuth2/ bearer token 或 mTLS，一次完整的跨域调用要先做 token 交换或 JWKS 拉取，冷启动时这一步能吃掉 80–200ms。更隐蔽的是身份的语义传递：A2A 的任务上下文里有 contextId 和 taskId，但没有标准化的"调用者身份+权限范围"字段，于是每个框架自己往 metadata 里塞。LangGraph server 认 metadata.user，CrewAI server 认 metadata.role，跨框架时身份常常被对端忽略，导致权限边界失效——不是慢，是漏。这比握手税更值得警惕，因为它不出现在延迟曲线上，只出现在安全审计里。
把税降下来有三招，按性价比排序。第一式，A2A 网关聚合：不要让五个异构 agent 两两直连，而是在中间放一个同框架（推荐 LangGraph 或 ADK）的聚合层，把异构 server 收敛成内部子图调用，只有出/入网关那两跳交跨框架税，内部全走同框架。实测能把五跳链路的跨框架握手次数从 4 次降到 2 次，P95 延迟降 41%，保真回升到 ~80%。第二式，能力卡校准层：在客户端和异构 server 之间加一个 card normalizer，统一把 skills 标上 interaction_style、把状态机映射到 canonical 六态，把流式风格声明成 delta|snapshot。这层是无状态的、可缓存的，能把"同名异义"降级从 23% 压到 6%。第三式，SSE 边界对齐：约定全网只发 delta 且每个 Part 自包含偏移，客户端按 offset 重组——这是协议层最该进 spec 的改动。三式叠加，跨框架单跳保真可从 84% 提到 92%，链路有效深度从 3 跳撑到 5 跳。
flowchart LR
subgraph Client["A2A 客户端编排器（LangGraph）"]
D["发现: GET /.well-known/agent.json<br/>8-25ms"]
N["协商: 选 skill / 状态映射<br/>1-3ms, 失败重试 +40ms"]
E["执行: task/send JSON-RPC<br/>15-40ms"]
R["重组: SSE 事件拼接<br/>5-20ms"]
D --> N --> E --> R
end
subgraph Hetero["异构 A2A Server 群"]
S1["LangGraph<br/>同框架 38ms"]
S2["ADK 1.0<br/>71ms / 亲儿子"]
S3["OpenAI Agents<br/>118ms / handoff 复用 completed"]
S4["CrewAI<br/>132ms / role-as-skill"]
S5["AutoGen<br/>164ms / 无 SSE"]
end
E -.task/send.-> S3
S3 -.SSE delta.-> R
R -->|每跨一框架边界<br/>保真 -10~12%| F["末端产物<br/>五跳后保真 ~55%<br/>有效深度 2-3 跳"]
style D fill:#fde68a
style N fill:#fca5a5
style E fill:#bfdbfe
style R fill:#ddd6fe
style F fill:#fecaca
场景一：同公司多团队、技术栈统一。 别急着上 A2A 跨框架互通。直接选 LangGraph 或 ADK 做内部编排，子 agent 全走内部子图调用（不交握手税），只在"对外暴露给第三方 agent"的边界上包一层 A2A server。这是 2026 年最省税的拓扑——内网同框架，外网才 A2A。
场景二：必须跨厂商协作（如银行 agent 调外部合规 agent）。 用网关聚合 + 能力卡校准双保险。中间放一个同框架网关收敛异构调用，并在网关里跑 card normalizer，把状态机和流式风格对齐。链路深度控制在 2–3 跳以内，第 3 跳后必须插人工/LLM 校验。
场景三：做一个面向开发者的"多 agent 市场"平台。 这种场景跨框架互通是核心卖点，握手税是平台成本——建议自建 A2A TCK（技术兼容性套件）做准入门槛，强制要求上架 agent 的 AgentCard 通过 normalizer 校验、流式声明 delta|snapshot、状态机映射 canonical 六态。把"同名异义"挡在门外，比上线后靠降税三式补救便宜得多。
变现/训练营评估： "A2A 跨框架互通实战"是 2026 下半年极佳的 B 端训练营选题——协议刚 v1.0、企业刚开始铺、踩坑集中在握手和保真。一个 2 天的课可以拆成：Day1 把五栈各包成 A2A server（环境搭建+卡片设计），Day2 测握手税、复现状态机分叉、跑降税三式。门槛在于你得真的搭得起五栈环境并跑出曲线，这正是训练营的溢价点。
延伸阅读：A2A 解决了"能不能对话"，本实测回答的是"对话要交多少税"。当协议层的握手税降到可接受，下一道坎是任务状态机的语义统一——这大概率是 A2A v1.1 的主战场。 验曲线 2. Multi-Agent Debate 设计模式 — AutoGen 官方文档 — AutoGen 0.4 基于 actor 模型的辩论式实现与代码示例 3. Reflection 设计模式 — AutoGen 官方文档 — 批判-修正式（反思循环）的官方实现与停止条件设计 4. Ranked Voting based Self-Consistency of Large Language Models — ACL 2025 — 把多数投票升级为排序投票，缓解"多数暴政"与答案同质化 5. AI Red Teaming Agent — Microsoft Foundry — 红蓝对抗式的产品化实现，攻击者/防御者智能体与对抗召回率指标
本文由「51学通信」出品，站长爱卫生（微信：gprshome201101）。聚焦 AI 智能体实战，每周拆解一个真实系统架构。
[!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 等场景全覆盖。