Agent2Agent ProtocolA2A，智能体间协议

不是。MCP 连工具/数据（纵向），A2A 连 Agent（横向），一个系统里常常两个都用—— A2A 编排的 Agent 内部往往正用 MCP 调工具。

这是本册最常被问的一题：粒度也不同——MCP 是一次工具调用，A2A 是一次可长时运行的任务委派。

下一步　用差旅审批一张图讲两层：A2A 决定谁接力这一单， MCP 决定每个 Agent 手里有什么工具。

依据　分工对照表

能就别上。只有当存在多个独立、专精、可能来自不同厂商的 Agent 要协作时 A2A 才有价值；单 Agent 场景直接 MCP 即可。

跨 Agent 有网络与模型开销——拆分本身有成本，专精/隔离/跨厂商的收益要大过它才划算。

下一步　拿选型器把手头场景过一遍，判断尺子就一条：是否存在多个异构 Agent 要接力一件事。

依据　选型尺子

不会。2025-06 已捐给中立的 Linux Foundation；150+ 组织参与、六语言官方 SDK、三大云托管且互通，治理和演进公开。

「中立治理 + 广泛采用」是回应「昙花一现」质疑最有力的组合——和 MCP 走的同一条去厂商化路线。

下一步　30 秒成熟度话术用四个数字组织：150+ 组织 / v1.0 稳定版 / 5 个 SDK / 3 大云。

依据　采用度

不用。A2A 是框架之上的互操作层：LangGraph、ADK 等都能对外暴露/调用 A2A，内部实现不动。server 端主要是「包壳」，client 端几行发消息。

「业务核心不动」是接入量评估的关键口径——新增的只有 Card 声明、 executor 包装、发布三块。

下一步　挑熟悉语言的官方 SDK 跑通 hello-world 级 server + client，再给客户列接入清单。

依据　接入心智模型

Task 状态需要持久化（内存/DB 皆可），但这正是长任务、断点续传、推送回调的基础；短任务也可即时 completed，不强制长存。

「有状态」是 A2A 与一次性 RPC 的本质差别——真实协作是长耗时、多轮、要人工介入的，工单模式才接得住。

下一步　记住终态纪律：终态不可回跳、重试建新 Task——审计与回放靠它；状态真相永远在服务端。

依据　Task 状态机

用推送通知：注册 webhook，Task 完成或变更时服务端回调你——客户端无需挂连接，天然适配离线与批量。

四种交付各有代价：阻塞占连接、轮询会陈旧、流式要处理断线背压、推送要防重复投递与回调伪造（幂等 + URL 校验 + 签名）。

下一步　口诀选型：短活阻塞、简单轮询、看进度流式、长任务推送——先判运行条件再选交付。

依据　四种交付

用 v1.0 的 Signed Agent Card：名片带密码学签名，接收方验签确认确由你的域名签发——伪造的 Card 过不了验证。

自动协作把发现从人工审批变成机器接单，「可验证信任」是跨组织委派的前提——这正是 v1.0 头号新特性的动机。

下一步　给安全负责人讲「默认设防」全景：验签 + 最小权限 + 关自动批准 + 全链路审计，别只说「支持 OAuth」。

依据　Signed Agent Cards

每个 Task 有 ID 和状态、可观测，链路上逐段查即可；生产部署给每个 Task 打 trace，配统一可观测。

验收的终极判断：任意一次协作能回放「谁委派、做了什么、为何结束、交付了什么、谁验收」——答不全就还没到生产。

下一步　按六条验收线（发现/任务语义/授权/异步交付/运营/ 安全）列上线 checklist。

依据　生产验收

先把话说在前头：那些采纳数字是自报口径、没有公开统计方法。它们能证明的是「这不是某一家的私有协议」——中立治理、官方 SDK 覆盖主流后端栈、三大云都托管；证不了「已经在生产里大规模跑起来」。所以成熟度要拆两层讲：协议层已经稳（v1.0 稳定线、以 protobuf 为唯一权威定义、有 TCK 可自测一致性），生态层还在长。判断早不早，不看别人几家在用，看你自己有没有那条「要跨出去」的边。

把「参与组织数」当「生产案例数」讲，是这册最容易犯也最贵的一次口误——验收时一定会被翻出来。主动说破这条边界反而最像行家，还顺手把话题从「别人怎么样」拉回「你有没有这个场景」。

下一步　报那几个数字时永远配一句限定语：「这是生态广度，不是生产规模。」生产成熟度另外证——TCK 跑协议一致性（注意它只证一致性，不替代安全与业务评测），再加你们自己的验收线。

依据　采用度与不可外推边界　·　Inspector 与 TCK

很可能不需要——这句要先说，别硬推。同一套代码库、同一个团队维护、一起发版的几个 Agent，内部流转归框架（LangGraph / ADK 之流）管就好，中间插一层 A2A 只是多一跳网络和一层序列化。A2A 的价值在跨出去的那一步，判据只有一条：这个 Agent 归不归你管——你能改它、你决定它什么时候发版，就框架编排；不归你管（子公司、供应商、SaaS 厂商、有独立发版节奏的兄弟部门），那条边才值得标准化。

这题答「当然要」会当场丢分：对方比你更清楚自己的系统。诚实划出边界，你后面说「这一步该上」时才有人信；而且这条判据客户拿得走、回去自己就能用。

下一步　请客户在自己的架构图上圈一下：哪几个 Agent 不由他们自己发版？圈出来的那几条边就是 A2A 的边；一条都圈不出来，就先别上。

依据　三层叠起来看　·　接入选型器

先划界，再摆证据链。界划在接口上：opaque 协作里你看不见对方内部，也不为对方内部负责——你担的是「委派得对不对」（照 Card 声明的能力调、输入给全、授权范围给准），对方担的是「交付得对不对」（Artifact 里的内容）。证据留在 Task 上：异常终态本身就在记责任，rejected 是对方没接、failed 是接了没跑成、canceled 是委派方自己撤；再加上终态不可回跳、事件序列可回放，一次协作能完整复盘「谁委派、做了什么、为何结束、交付了什么、谁验收」。所以责任条款要锚在这套记录上，而不是锚在会议纪要上。

多方系统里「谁的锅」平时没人问，一出事就是甲乙双方最难看的一段。协议本身不判责，但它把判责要用的事实固定了下来——这话得在签字之前讲，出事之后再讲就晚了。

下一步　把验收线里「任务语义」那条抽出来当合同附件：失败 / 取消用例跑通、事件序列可回放——这两样是划责的最低证据。

依据　opaque agents　·　Task 状态机　·　六条验收线

先把最坏情况的上限算出来，再决定。A2A 在你系统里的形状是「在已有能力外面包一层壳」——Card 声明 + executor 包装 + 发布，业务核心不动；真押错了，重写的是那层壳，不是脑子。往里还有两层缓冲：三种传输绑定的语义由 protobuf 统一约束、可互换；不用官方 SDK 也能手写报文对接，不绑语言不绑框架。反过来，推迟决定也不是零成本——不定标准就继续一对一定制对接，M×N 那笔账每多一家供应商就再付一次。

客户问「会不会打水漂」，真正想知道的是最坏能亏多少，而不是要你保证它一定赢。给沉没成本的上限比给信心承诺有用得多；顺手把「不做决定」的成本也摆上台面，这道选择题才是完整的。

下一步　接入时守一条纪律：A2A 相关的东西只待在壳里、别渗进业务代码。守住了，「将来换协议」永远是一笔能估量的改造，而不是一次重做。

依据　接入心智模型　·　三种绑定