A2A（Agent2Agent 协议）
让不同厂商的 Agent 互相委派任务：2026-03 发布 1.0，2026-08 与 MCP 同归 AAIF
它不是「更好的 MCP」，而是另一层：MCP 给 Agent 装手，A2A 给 Agent 配同事。判断标准只有一条——对面那个 Agent 归不归你管。同一个信任边界内的多 Agent 调用，加 A2A 只是给自己加一层协调机制；真正跨供应商、跨组织委派时，签名 Agent Card 和任务生命周期才开始值钱。
基于 A2A 官方规范站（a2a-protocol.org）与 Linux Foundation 公告相关报道评估：解决跨框架 / 跨组织 Agent 委派这一真实问题，但只在「两边都不归你管」时才值得引入
协议层需要 SDK 与 Agent Card 端点，非开箱即用，调试要靠 trace
公开标准 Apache-2.0、零许可成本
无地域限制、但中文一手资料少
1.0 稳定版 + Linux Foundation 治理 + 多语言 SDK，跨组织生产流量仍偏早期
- 评分人
- AI 之家编辑部
- 最近复核
- 2026-10-27
- 下次复核
- 2027-04-25 （周期 180 天）
- 利益声明
- 本站不接软文、不卖排名
TL;DR
一句话： A2A（Agent2Agent）解决的问题是**「两个不是你写的 Agent 怎么互相交活」**。它给每个 Agent 一张可发现的 Agent Card，用统一的任务模型跨组织委派，用签名卡片在委派前先确认对方是谁。
2026 年两条关键时间线：① 2026-03-12 发布 1.0 稳定版——签名 Agent Card、多租户单端点、三种协议绑定（JSON-RPC 2.0 / gRPC / HTTP+JSON）、请求级版本协商；② 2026-08-20 与 MCP 同归 Linux Foundation 下的 AAIF，「哪个协议赢」的争论正式结束，两层栈（MCP 竖向接工具、A2A 横向接 Agent）成了参考架构。
判断要不要上，只需一句话：对面那个 Agent 归不归你管。同一个信任边界内、全部 Agent 自己维护 → 不必要；跨供应商 / 跨组织委派 → 签名卡片与任务生命周期才开始值钱。
来源说明：本卡基于 A2A 官方规范站与官方代码仓整理，辅以协议层技术分析报道；版本细节以官方规范为准。
它到底是个什么
先摆清两层栈的位置，这是最容易搞混的地方：
| 层 | 协议 | 解决什么 | 类比 |
|---|---|---|---|
| 竖向 | MCP | 一个 Agent 连接自己的工具、数据源、API | 给 Agent 装手 |
| 横向 | A2A | 一个 Agent 把任务委派给另一个 Agent | 给 Agent 配同事 |
四个核心对象：
| 对象 | 作用 |
|---|---|
| Agent Card | 放在 /.well-known/agent-card.json 的身份与能力声明：技能、端点、可接受的安全方案；1.0 起可 JWS 签名 |
| Message | 交互的一轮内容 |
| Task | 有唯一 id 与状态的工作单元，支持 input-required 中途要输入、可 cancel |
| Artifact | 任务产出的结果物 |
核心能力
发现与身份：签名卡片
Agent Card 从「一个静态 JSON」演化成了信任层的一部分：1.0 起支持 AgentCardSignature——对 RFC 8785 规范化后的 JSON 做 JWS（RFC 7515）签名，调用方可以验证「这张卡是谁发的、字节是否完整」。
但要清楚它的边界：签名证明来源与完整性，不证明卡里宣称的能力是真的。你要判断「这个供应商真的通过了某认证」，靠的是卡外的机制，不是这张卡。
卡里同时声明可接受的安全方案（OAuth 2.0 各 flow、OIDC、API Key、mTLS）。注意规范只声明、不强制——实际鉴权由各家实现落地，这是接第三方 Agent 时最常见的坑。
任务生命周期：不是一次函数调用
这是 A2A 与「直接调 API」的根本差别。一次 A2A 交互是长时任务：发送 → 任务进入 working / input-required → 结果以 artifact 返回；期间可以用 contextId 把多轮交互归到同一会话、用 taskId 定位具体工作单元，推送更新走轮询、SSE 或 push notification 三种机制。
对企业流程（理赔、采购、跨机构审核）来说，「任务可以被查询、被取消、被续做」比「接口返回得快」重要得多。
三种规范绑定
JSON-RPC 2.0 over HTTP(S)、gRPC、HTTP+JSON——三者以同一份 a2a.proto 为真相源、保证等价。选哪个取决于你的既有栈：gRPC 适合已有服务网格的内部链路，JSON-RPC 适合对外暴露给不特定调用方。
SDK 与生态
官方 SDK 覆盖 Python / JavaScript-TypeScript / Go / Java / .NET-C# / Rust；Apache-2.0 许可，含专利授权。云侧原生支持已经铺开：Azure AI Foundry、Copilot Studio、Amazon Bedrock AgentCore 均支持 A2A，Google 的 ADK 原生实现并开源了 A2A 支持。
规模与生产现状
官方仓已过 24,000 stars、580+ commits、11 个 release；Linux Foundation 口径 150+ 支持组织（2026-04）。但要说清分层现实：据其 2026-04 公告，供应链、金融、保险、IT 运维已有生产部署；跨组织、双方互不控制对方部署的流量仍多处于演示阶段。今天大多数被称作「多 Agent」的系统，其实是一个编排器在顺序调工具，而不是两个独立 Agent 越过信任边界。
落地成本
| 项目 | 成本 | 说明 |
|---|---|---|
| 规范 / SDK | $0 | Apache-2.0，无许可费 |
| Agent 端点 | 一次开发 | 一个 Agent Card 静态文件 + 一个绑定端点，工作量不大 |
| 鉴权与网关 | 持续投入 | 卡片只声明安全方案，实际 OAuth/mTLS 落地靠自己 |
| 可观测 | 持续投入 | 跨组织任务出问题，没有 trace 基本无法归因 |
| 组织成本 | 最容易被低估 | 跨公司流程要谈 SLA、责任划分、数据边界 |
同层对比
| 维度 | A2A | MCP | Composio | Smithery |
|---|---|---|---|---|
| 层位 | Agent ↔ Agent | Agent ↔ 工具 | 工具集成层 | MCP server 市场 |
| 跨组织 | 设计目标 | 不为此设计 | 需自建 | 需自建 |
| 身份验证 | 签名 Agent Card | 连接级（OAuth 远程） | 平台侧 | 平台侧 |
| 长任务生命周期 | 原生 | 单次调用 | ||
| 何时用 | 对方 Agent 不归你管 | Agent 要调工具 | 要快速接一堆 SaaS | 想找现成 MCP server |
避坑清单
- 别在单一信任边界内上 A2A：协调机制的价值来自「对手不受你控制」。内部全自研的多 Agent，走自己的编排层更快更便宜。
- 签名 ≠ 可信：卡片签名只证明「谁发的」，不证明「它真的有能力、真的合规」。证书链、资质审核仍是卡外的事。
- 安全方案是声明，不是强制：规范列出 OAuth 2.0 / OIDC / mTLS，但落地由各家实现；接第三方前必须实测鉴权行为。
- 中文一手资料稀缺：规范、SDK 文档、社区讨论基本全英文，团队要预留学习成本。
- 跨组织流量还很早期：把它当「已成熟的跨公司基建」会踩空，先在自己控制的边界内跑通再向外扩。
- 和 MCP 别搞混：把「Agent 连工具」的诉求硬套 A2A，会写出一个又慢又难调的中间层。
适合 / 不适合
要把自研 Agent 委派给供应商 / 合作方；多框架并存需要互通的平台团队；跨公司流程（采购、理赔、供应链、跨机构审核）；需要「先验证对方是谁」再委派的强合规场景。
单个 Agent 调工具（那是 MCP）；同一信任边界内部全自研的系统；只想快速搭个工作流给业务用。
相关阅读
- 概念层：A2A 百科词条 · MCP 协议 · Agent 编排 · Function Calling
- 工程实现：Microsoft Agent Framework（MCP 与 A2A 一等公民）· AutoGen（已进维护模式）· CrewAI
- 工具侧：Composio · Smithery · MCP Toolbox
- 商业化延伸：智能体支付协议
Long-tail quick picks
长尾检索速查：对应「A2A 和 MCP 区别 / A2A 怎么实现 / 值不值得上」等搜索意图。
Open-source alternatives
Free tier
- 是否有免费档：完全免费（开放标准 + Apache-2.0 SDK）
- 真正的成本在鉴权网关、可观测与组织协同，不在许可
China availability
- 是否国内可用：可用（无地域限制）
- 中文友好度评分：3 / 5（SDK 与文档以英文为主）
- 国内大厂多在自有 Agent 平台内闭环，跨生态互通的落地案例仍少
来源
- A2A 协议官方规范 v1.0 — a2a-protocol.org
- A2A 官方代码仓 a2aproject/A2A（Apache-2.0）
- MCP and A2A — The Protocol Layer of the Agent Ecosystem
- A2A and MCP Are Now Under One Roof: What AAIF Means
- 智能体架构大一统：Linux 基金会 AAIF 下的 A2A 与 MCP 协同实战
本卡片由 AI 之家编辑部根据规范站与公开技术分析整理，非厂商付费内容；协议细节以官方规范为准，欢迎在 反馈邮箱 反馈更新。
| 计划 | 价格 | 限制 | 国内支付 | 备注 |
|---|---|---|---|---|
| 规范与 SDK | $0 / Apache-2.0 | 规范、参考实现、Python / JS / Go / Java / .NET / Rust SDK 全免费 | — | 无许可成本，无厂商绑定 |
| 自建 Agent 端点 | 按你的基础设施 | 一个 Agent Card 静态文件 + 一个 JSON-RPC / gRPC 端点 | — | 成本主要在网关、鉴权与可观测 |
| 接入托管 Agent 服务 | 按供应商 | Bedrock AgentCore / Azure AI Foundry / Copilot Studio 等已原生支持 | — | 按各云厂商计费 |
- · 要把自研 Agent 委派给供应商 / 合作方 Agent 的团队
- · 多框架并存（LangGraph + MAF + 自研）需要互通的平台团队
- · 跨公司流程：采购、理赔、供应链、跨机构审核
- · 需要「先验证对方是谁」再委派任务的强合规场景
- · 单个 Agent 调工具的场景（那是 MCP 的活）
- · 同一个信任边界内部、全部 Agent 自己维护的系统
- · 只想快速搭个工作流给业务用（去看 Dify / n8n）
A2A 和 MCP 到底谁替代谁？
都不替代。MCP 是竖向的：一个 Agent 连接自己的工具与数据源（数据库、API、文件）；A2A 是横向的：一个 Agent 把任务委派给另一个 Agent。2026-08-20 两者同归 Linux Foundation 下的 AAIF 治理，「协议之争」这件事正式结束，两层栈成了参考架构。单个只调工具的 Agent 只需要 MCP。
什么时候才真的需要 A2A？
一条判断标准：对方 Agent 归不归你管。归你管 → 直接调用或走内部网关；不归你管（供应商、合作方、跨组织）→ A2A 的 Agent Card 发现、签名验证、任务生命周期才有价值。在单一信任边界内引入 A2A，等于买了一套没有对手可协调的协调机制。
Agent Card 是什么？
一个放在 `/.well-known/agent-card.json` 的 JSON 文档，描述这个 Agent 的身份、技能、端点与可接受的安全方案（OAuth 2.0 / OIDC / API Key / mTLS）。1.0 起卡片可做 JWS 签名（RFC 7515）对 RFC 8785 规范化后的 JSON 签名——调用方能确认「这张卡确实是声称的那一方发的、内容没被改」。注意：签名证明的是来源与完整性，不证明卡片里宣称的能力是真的。
任务怎么跟踪？
任务模型：send / stream 一条 message，然后 get / list / cancel 这个 task，结果以 message 与 artifact 返回。多轮交互靠 contextId 逻辑分组、taskId 定位具体工作单元；进度通过轮询、SSE 流式或推送通知三种方式获取。
现在有生产案例吗？
据 Linux Foundation 2026-04 公告口径，供应链、金融服务、保险、IT 运维已有生产部署；但跨组织、双方互不控制部署的流量仍多停留在演示阶段。换句话：组织内多 Agent 路由已可用，跨公司委派还在早期。
国内能用吗？
能用——它是开放标准、无地域限制，SDK 覆盖 Python / JS / Go / Java / .NET / Rust。主要障碍是中文一手资料少、以及国内大厂更多在自己的 Agent 平台内闭环（钉钉 / 飞书 / 企微各自生态），跨生态互通的诉求目前还没有强到推动 A2A 落地。
可接入 / 兼容以下大模型 API（在设置中配置 key 即可切换底座）：