过去一年多，MCP（Model Context Protocol）基本统一了「Agent 接工具」的姿势：数据库、浏览器、内部 API，都可以封装成 MCP Server 挂给模型，本站此前的《从零写一个 MCP Server》《一篇读懂 Function Calling》讲的都是这条线。但 MCP 解决的是 Agent ↔ 工具；当两个 Agent 要对话时——比如一家厂商用 LangGraph 写的客服 Agent，要把任务转交给另一家厂商基于 CrewAI 的物流 Agent——双方互不知道对方存在，更不知道对方会什么，MCP 帮不上忙。补上这一环的，是 Agent2Agent 协议（A2A）。
为什么跨厂商 Agent 互操作需要一个开放协议
想象一下没有 A2A 的世界，Agent 之间协作只有三条路，都不好走：
- 点对点集成：每对接一个外部 Agent 就写一套定制适配。N 家厂商互相对接，复杂度是 O(N²)，而且每换一版内部实现就得重写适配层。
- 把对方 Agent 包成工具：表面上看 Function Calling 就够了，但工具调用是「一次进、一次出」的同步函数语义，撑不起多轮协商、长时任务和人类介入——官方文档的原话是，把智能体包成工具会限制其能力，A2A 让智能体「以智能体的方式」协作，无需包装。
- 交换内部实现：把提示词、记忆、工具清单开放给对方？商业上不可行。
所以 A2A 的设计目标有三条底线：跨异构框架（不管对方是 LangGraph、CrewAI 还是 Google ADK 写的）；不透明执行（Opaque Execution，智能体不暴露内部逻辑、记忆与专有工具，只声明「我能做什么、干到哪一步」）；运行时能力发现（不靠人事先牵线，Agent 自己能查到「网上存在一个能帮我订机票的 Agent」）。
沿革与现状：从 Google 项目到 Linux Foundation
时间线如下（关键日期均已对照一手来源）：
- 2025-04-09：Google 在 Cloud Next '25 发布 A2A，官方公告列出 50+ 合作伙伴，包括 Atlassian、Box、Cohere、Intuit、LangChain、MongoDB、PayPal、Salesforce、SAP、ServiceNow、UKG、Workday，以及 Accenture、BCG、麦肯锡等一众咨询集成商。
- 2025-06：Google 把协议捐给 Linux Foundation，走中立开源治理；AWS、Cisco、Microsoft、Salesforce、SAP 等均表态参与。
- 2025-07-30：规范 v0.3.0，能力发现地址从
agent.json改为agent-card.json，并加入 Agent Card 签名。 - 2025-12-09：Linux Foundation 宣布成立 Agentic AI Foundation（AAIF），创始项目为 Anthropic 的 MCP、Block 的 goose 与 OpenAI 的 AGENTS.md（注意：A2A 此时并未入库）。
- 2026-03-12：规范 v1.0.0 发布，这是一次大版本重构：应用层与传输映射分离、新增支持分页过滤的
tasks/list、统一推送配置结构、现代化 OAuth 2.0 流程（移除 implicit/password，加入 device code 与 PKCE）、gRPC 多租户。 - 2026-05：补丁版 v1.0.1。
- 2026-08：官方宣布 A2A 正式加入 AAIF，与 MCP 同门治理。
截至 2026-10-07，A2A 最新规范版本为 1.0（仓库最新发布 v1.0.1），由 Linux Foundation 旗下 AAIF 治理；GitHub 主仓库约 26k star，官方 SDK 覆盖 Python、Go、JavaScript、Java、.NET、Rust 六种语言。
核心概念：把规范读薄
Agent Card：智能体的「名片」
每个 A2A 服务端在约定地址 /.well-known/agent-card.json 暴露一份自描述 JSON，内容包括：名称、描述、版本、能力声明（capabilities：是否支持流式、推送通知、扩展）、安全方案（securitySchemes）与安全要求、默认输入/输出模态、skills 技能列表（每条含 id、name、description、tags、examples），以及 supportedInterfaces——声明支持哪种协议绑定和服务地址，第一条为首选。调用方拿到名片，就知道该往哪个地址、用什么方式、以什么身份发任务。v0.3.0 起还支持用 JWS 给卡片签名防篡改；另有「认证扩展卡」机制：公开名片之外，完成认证后可下发信息更全的第二张卡。
Task：带状态机的「工单」
A2A 的交互以 Task 为中心。客户端发消息后，服务端创建 Task 并在生命周期中流转状态：
submitted（已受理）
└─> working（处理中）──> completed（完成，终态）
│───────> failed（失败，终态）
│───────> canceled（取消，终态）
├───────> input-required（中断：等调用方补充输入）
├───────> auth-required（中断：等认证）
└───────> rejected（拒绝接单，终态）
两个细节值得注意：多轮对话靠 contextId 串联上下文；input-required 让 Agent 可以「干一半、问一句、再接着干」——这正是把工具调用的无状态函数语义撑不起来的长流程，做成了协议原生能力。
Message、Part 与 Artifact
- Message：一次发言，
role为user或agent，核心是parts数组，用messageId标识、可引用历史任务（referenceTaskIds）。 - Part：内容的最小单元，四选一——
text（文本）、raw（base64 字节）、url（链接）、data（任意 JSON 结构），携带mediaType，所以协议天然不限于文本，图像、音频、结构化数据都能走。 - Artifact：任务的产物，同样由 parts 组成，可以边干边流式产出（
TaskArtifactUpdateEvent），一个任务可以产出多个。
流式与长任务：三种绑定 + SSE + 推送
传输上 A2A 分三层：最底层的消息原型用 Protocol Buffer 定义（规范的唯一来源），其上是与传输无关的抽象操作层，最下面是三种官方等价绑定——JSON-RPC 2.0、gRPC、HTTP+JSON/REST，内容类型为 application/a2a+json，客户端任选其一。
短任务用 message/send 一问一答；长任务用 message/stream 走 SSE（Server-Sent Events）持续接收状态与产物更新。如果双方根本无法保持长连接（移动端、离线批处理），A2A 提供 push notification：调用方给任务挂一个 webhook（PushNotificationConfig，含认证信息），服务端在状态变化时向 webhook POST 结果——语义是 at-least-once，客户端必须幂等处理并回 2xx；推送配置持续生效到任务完结。
一次典型的协作时序如下：
sequenceDiagram
participant C as 客户端 Agent
participant S as 远程 Agent
C->>S: GET /.well-known/agent-card.json
S-->>C: Agent Card（能力/接口/安全方案）
C->>S: message/stream（新建 Task）
S-->>C: Task 状态：working
S-->>C: input-required（等补充出发日期）
C->>S: message（同 contextId，补齐参数）
S-->>C: TaskArtifactUpdateEvent（流式产物）
S-->>C: Task 状态：completed
Note over C,S: 长连接不可用时改走 webhook 推送
与 MCP 的关系：互补，不是竞争
官方的定位很直接：「MCP 连接智能体与工具、数据；A2A 跨越的是智能体之间的边界」。逐项对比：
| 维度 | MCP | A2A |
|---|---|---|
| 解决的问题 | Agent ↔ 工具 / 数据 / 资源 | Agent ↔ Agent |
| 对端形态 | 接口明确的工具函数、资源 | 不透明的对等智能体（黑盒） |
| 交互粒度 | 单次工具调用，通常无状态 | 完整任务，可多轮、长时、可中断 |
| 状态模型 | 调用本身无状态 | Task 有完整生命周期状态机 |
| 暴露程度 | 工具 schema 是显式契约 | 内部提示词、记忆、工具全部隐藏 |
| 典型信任边界 | 同一主体内，Agent 与自己的工具 | 跨组织、跨厂商的主体间协作 |
实践中两者常叠着用：A2A 负责把任务委派给另一个 Agent，接活的 Agent 内部照旧用 MCP 调自己的工具。选型上不必二选一——一个 Agent 完全可以同时是 MCP 客户端和 A2A 服务端。
最小示例：一张 Agent Card 长什么样
下面是按官方规范字段整理的最小 Agent Card（结构对应官方 Python 教程中的 AgentCard 定义）：
{
"name": "travel-planner",
"description": "根据目的地、日期与预算规划行程，输出逐日安排",
"version": "1.0.0",
"supportedInterfaces": [
{
"protocolBinding": "JSONRPC",
"url": "https://travel.example.com/a2a",
"protocolVersion": "1.0"
}
],
"capabilities": {
"streaming": true,
"pushNotifications": true
},
"defaultInputModes": ["text/plain"],
"defaultOutputModes": ["text/plain", "application/json"],
"skills": [
{
"id": "plan_trip",
"name": "行程规划",
"description": "输入目的地、天数与预算，输出逐日行程 JSON",
"tags": ["travel", "planning"],
"examples": ["帮我规划东京五日游，预算一万五"]
}
]
}
调用方的动作序列：拉取 /.well-known/agent-card.json → 校验能力与安全方案是否匹配 → 向首选接口发送 message/stream 新建任务 → 收到 input-required 时补充输入 → 持续接收 artifact 流 → 等到 completed 终态收取最终产物。整个过程里，调用方只知道「它会规划行程」，不知道也不需要知道它内部用了什么模型、什么工具——这就是不透明执行带来的解耦。
边界与冷思考
采用度：声势与落地之间有落差。 50+ 厂商站台、Linux Foundation 背书、六语言 SDK 都是真的；但 2026 年 3 月也有从业者（Credal）直言「好像没人在谈 A2A 了」，理由是它宣传的多数优势（状态管理、长任务、发现）可以绕 MCP 变通实现，而引入第二套协议带来的兼容矩阵与运维成本是实打实的。所谓「已在大量企业生产落地」的说法目前缺乏可交叉验证的统计，本文不予采信。截至 2026-10-07 更稳妥的判断是：标准与基础设施已就绪（v1.0 + 六语言 SDK），规模化跨厂商互操作案例仍处早期。
与 Function Calling 直连方案的取舍。 如果两端 Agent 都在自己系统内，直接 Function Calling 或内部 RPC 更省事——协议是给「跨组织、跨框架、互为黑盒」的场景准备的。反过来，一旦对方是外部主体，自研点对点集成的维护成本和安全暴露面就会反噬。所以选型的真正问题是「要不要标准化这条边界」，而不是「哪个方案更先进」。
生态还缺什么。 公网层面的大规模发现机制（谁来做可信的 Agent 目录）、跨主体身份与授权的成熟范式（卡片签名、认证扩展卡都刚起步）、以及协作背后的商务层（计费、SLA、责任界定）都还没有公认答案。v1.0 落地的版本协商（A2A-Version 头，版本号只到 Major.Minor）与卡片签名，正是朝「信任」方向补的第一批课。协议解决了「怎么对话」；「敢跟谁对话、怎么收费」还留给生态。
读者留言
COMMENTS 暂无还没有留言，来说第一句？