A2A：Agent 间协作协议

一句话定位：MCP 接工具，A2A 接 Agent——当对方也是一个有主权的 Agent 而不是被动工具时，用 Agent Card 相识、用 Task 委托干活、互不暴露内部实现。前置：MCP：协议与工具接入——先分清「接工具」与「接 Agent」。

对方也是个 Agent，凭什么当工具用

你的报销 Agent 需要发票核验能力。巧了，另一家公司有一个专门做发票核验的 Agent，做得很好。

第一反应是「调它的接口」——但接口调用是把对方当工具：你的请求格式它得适配、它的内部流程你得理解、它升级了你的调用就得改。更现实的麻烦是：对方每个季度都在优化核验策略，接口字段跟着变，你的报销 Agent 就要跟着改一轮；反过来你想把发票影像换成结构化数据，还得求对方为你开接口。可对方不是一个函数，是一个会自己规划、有自己的工具和状态的 Agent——把它当提线木偶，既绑死了它，也累坏了自己。

Agent 与 Agent 之间，有没有一种像两家公司谈合作那样的平级标准——互相发现、谈好条件、委托干活，而不是把对方拆成接口？

有。这就是 A2A（Agent2Agent）协议：一种让 Agent 平级协作的标准——互相发现、谈好怎么合作、委托任务、收交付物，全程不必知道对方内部怎么运转。

图：A2A 协作三步——①名片发现 ②任务委托 ③交付物返回；双方内部实现互不暴露

渐进拆解：外包给另一家公司

类比：给员工配工具，还是外包给另一家公司

MCP 和 A2A 的差别，是「给员工配工具」和「外包给另一家公司」的差别。员工报销要用计算器，你买一个发给他（MCP 接工具）——工具没有自主权，怎么用你说了算。但发票核验这种专业活，你外包给专业公司（A2A 接 Agent）：发需求文档、约定交付标准，对方自己组织人手、自己安排流程，到期交付结果。你不需要也不应该知道对方公司内部怎么分工。外包还有个隐性好处：对方升级了核验技术，你一行代码不用改，升级无感接入——协议把对方的演进隔离在了它的墙内。

不透明原则：协作双方只看接口与交付物

这条原则的保护是双向的：对方不必暴露「核验用的什么模型、流程怎么走」（商业机密与安全边界），你也不必理解「它内部怎么分工」（认知负担归零）——委托的粒度是目标，不是步骤。传统接口集成里，调用方往往要理解服务方的内部模型才能正确传参；A2A 把这份理解成本降到了「看名片、发任务、收结果」。

Agent Card：机器可读的能力名片

每个 A2A Agent 在约定的公开地址放一张 Agent Card：我是谁（名称、描述）、我会什么（技能清单，每条技能带 tags 关键字——客户端按能力检索名片时匹配的就是它）、在哪个地址、需要什么鉴权。客户端 Agent 拿着这张名片做两件事：发现（这个领域有谁能干这活）与协商（它的鉴权要求我满足得了吗）。名片让「找到对的合作方」从人际打听变成标准查询——而且名片是机器可读的，发现这一步可以由 Agent 自动完成：接到陌生领域的任务，先按能力描述搜一圈名片，再决定委托给谁。

Task：委托的载体

协作的基本单位不是一次调用，而是一个任务（Task）：客户端 Agent 发起任务，远程 Agent 接单后进入自己的生命周期——已提交（submitted）、处理中（working）、完成或失败（completed/failed），发起方随时可取消（canceled）——完成时交付交付物（Artifact）。

任务可以跑很久——核验一万张发票不是一次请求能返回的，A2A 支持三种节奏：

同步等待：适合几秒能完的短任务。
流式更新：适合几分钟的长处理，处理中持续回报进度，用户界面不至于干等。
异步推送：适合小时级的批处理，发起后先去干别的，完成时对方主动通知。

这与「调个函数等返回」的工具调用是两种世界观：工具是即时问答，任务是有始有终的委托。

一次完整的委托时序：

客户端读名片，拿到地址与鉴权方式。
携带凭证发起任务（「核验这批发票」+ 影像附件）。
对方返回任务 id 与「处理中」状态。
客户端该干嘛干嘛（流式模式下会陆续收到进度）。
对方转「已完成」，附上 Artifact（逐张发票的核验结论）。
客户端取回结果，任务闭环。

整条链路里，客户端只见过任务 id 与交付物。

大白话：配装备与找队友

MCP 给 Agent 配装备，A2A 给 Agent 找队友。装备听你指挥，队友只对你的需求负责。

看一个两者协同的完整例子——报销 Agent 处理一笔报销：它通过 MCP 调用公司报销系统的工具（读报销单、写审批记录——这些是自家系统的工具，走的纵向接入）；发票核验环节发现是外部供应商的发票，转而通过 A2A 委托外部核验 Agent（横向协作）；核验结果回来，它继续用 MCP 的工具把结论写回系统。一次业务里两种协议各司其职——纵向管自家资源的读写，横向管外部能力的借用。

技术定义

A2A（Agent2Agent）是 Google 于 2025 年 4 月发布、同年 6 月捐入 Linux Foundation 的开放协议，定位为「让不透明的智能体应用之间实现通信与互操作」。核心机制：Agent Card（JSON 格式的能力自描述，支持发现与协商）、Task（带生命周期管理的委托载体）与 Message/Artifact（消息与交付物）。

通信默认走 HTTP(S) 上的 JSON-RPC 2.0——规范 v0.3 起新增 gRPC 与 HTTP+JSON 两种绑定，由名片里的接口声明逐一点名，对方支持哪种，客户端就用哪种。

到 2026 年 9 月的生态现状：

版本线：规范经历 v0.3.0（2025 年 7 月，引入多绑定与名片签名）与 v1.0.0（2026 年 3 月，清理废弃字段）两轮大版本，现行 v1.0.1（2026 年 5 月，版本日期见官方仓库发布记录）。
SDK：官方开源组织提供 Python、Java、JavaScript 等多语言 SDK。
成员：SAP、ServiceNow、思科等企业在捐入新闻稿中列为创始成员，微软、Salesforce 等公开发声支持，逾百家科技公司加入；官方文档将 A2A 定位为 MCP 的互补。

边界与取舍：Subagent 面前，边界还清晰吗

先说清晰的部分

MCP 与 A2A 的官方分工：MCP 是纵向的——Agent 连接工具与数据；A2A 是横向的——Agent 连接 Agent。工具没有自己的目标（计算器不会拒绝按），Agent 有（核验 Agent 会自己规划怎么核）——有没有自主目标，是工具与 Agent 的分界线。一张图记住分工：

图：互补分工——往下接工具走 MCP，往平级接 Agent 走 A2A；判据是对方有没有自主目标

模糊出现在 Subagent 面前

主 Agent 派一个 Subagent 去干活——那也是「Agent 用 Agent」，A2A 的地盘吗？不是，关键看信任域与运行时：Subagent 与主 Agent 跑在同一个 harness（承载 Agent 主循环的运行时外壳）里、共享鉴权与信任、生命周期被主 Agent 完全掌控（派活、收结果、随时可停）——这是 harness 内部的编排，走多 Agent 编排那套机制，不需要协议。A2A 处理的是另一种关系：跨组织、跨信任域、双方各自独立部署、各自有自己的用户与生命周期——对方不归你管，才需要协议来约定协作。

什么场景必须 A2A，而不能退化成「主 Agent 里塞 Subagent」？

三个信号：

跨信任域：对方公司不可能把凭证交给你、你也进不了它的网络。
对方有独立生命周期：它服务很多客户，不为你随叫随到，任务要异步、要推送。
能力专业且自主：对方对核验流程有专业判断，你委托的是目标不是步骤。

落到开头那个例子：报销 Agent 与发票核验 Agent 分属两家公司——凭证各自管理，是跨信任域；核验 Agent 同时服务几十家企业，是独立生命周期；核验怎么抽查、怎么比对税务库是它的专业流程，你只管发发票影像——三个信号全中，必须走协议。三个都不沾，老老实实用 Subagent——协议是给「不归你管的 Agent」准备的。

热点检验：Codex 的多模型协同是 A2A 吗

拿一个 2026 年 9 月的热点来实测这套判据。Codex 的 subagent 能力正火：主模型作为编排者，并行派生多个 subagent 分头探索、测试、读日志，还能给每个 subagent 指定不同的模型——官方文档直接给出分工建议：重推理用 gpt-5.6，快速扫描用 gpt-5.6-terra，高频小任务用 gpt-5.6-luna，推理档位也可逐个调整。「一个 Agent 派 Agent 干活、还各用不同的大模型」，听着很像 A2A 的地盘？三个信号量一遍：

跨信任域？没有——官方文档明说 subagent 继承你当前会话的沙箱策略与权限模式，凭证是同一份。
独立生命周期？没有——派生、等待结果、追加指令、随时叫停、关闭线程，全由主 Agent 一手编排。
委托目标而非步骤？没有——连提示词都是主 Agent 写好下发的，subagent 没有自己的专业流程可自主。

三个信号全不沾：这是 harness 内的编排，不涉及任何协议。再进一层，这里甚至算不上「Agent 接 Agent」——给 subagent 换一个轻量模型，换的只是干活的大脑，不是另一个主体：对方没有自己的目标、用户与生命周期。哪个任务派哪个模型，本质是模型调用层的路由（见模型调用），连协作都谈不上。一句话：多模型协同不等于多 Agent 协作——前者是编排与路由，后者才需要协议。

真正踩到 A2A 地盘边上的，是社区那些让 Claude Code 和 Codex 两个独立进程互相对话的胶水工具：它们确实跨了产品与信任边界，但靠自定义脚本转发拼接对话，没有名片、任务、交付物的标准契约。这恰好说明 A2A 想填的空白是真实的——一旦协作跨到「不归你管的 Agent」那一侧，一家一户的胶水代码不可持续，协议化才是规模化的出路。

别为了新潮上协议

单团队、单进程内的多 Agent 协作，用 harness 编排更简单可控；先确认协作双方「互不隶属」，再请出 A2A。

动手：一张最小的 Agent Card

Agent Card 就是一份 JSON，托管在约定的公开发现地址——https://<域名>/.well-known/agent-card.json，任何客户端都能匿名读到。读懂下面这张名片，就懂了 A2A 的协作契约长什么样：

{
  "name": "发票核验 Agent",
  "description": "校验增值税发票真伪与金额一致性",
  "version": "1.0.0",
  "supportedInterfaces": [{ "url": "https://invoice-agent.example.com/a2a", "protocolBinding": "JSONRPC", "protocolVersion": "1.0" }],
  "capabilities": { "streaming": true, "pushNotifications": true },
  "defaultInputModes": ["image/png", "application/json"],
  "defaultOutputModes": ["application/json"],
  "securitySchemes": {
    "invoiceOauth": {
      "oauth2SecurityScheme": { "flows": { "clientCredentials": {
        "tokenUrl": "https://invoice-agent.example.com/oauth/token",
        "scopes": { "invoice:verify": "委托发票核验" } } } }
    }
  },
  "securityRequirements": [{ "schemes": { "invoiceOauth": { "list": ["invoice:verify"] } } }],
  "skills": [
    { "id": "invoice-verify", "name": "发票核验", "description": "给定发票影像，返回真伪与关键科目校验结果", "tags": ["invoice", "verification"] }
  ]
}

字段	作用
`supportedInterfaces`	点名服务地址与协议绑定；JSONRPC / GRPC / HTTP+JSON 是官方核心三种，协议也允许自定义绑定扩展——「绑定由名片声明」落在这里
`capabilities`	长任务的两个节奏开关：流式更新、异步推送
`defaultInputModes` / `defaultOutputModes`	声明收发的内容类型——客户端据此知道能直接把发票影像（image/png）作为任务附件发过来
`securitySchemes` 与 `securityRequirements`	合起来交代「你怎么证明你有权委托」：用哪种鉴权体系、找哪个端点换 token、要什么权限范围
`skills`	技能清单，每条技能的 `tags` 就是发现检索的关键字——客户端按「invoice」搜一圈名片，命中的就是它

两个容易踩的坑：

名片是公开文档，谁都能读——密钥、内部地址别放进去；名片只声明「用哪种鉴权体系」，真正的凭证交换走该体系的标准握手（比如 OAuth2 的 token 端点）。
协商淘汰发生在发现阶段——对方要求的鉴权 scheme 你满足不了，这张名片就从候选里划掉，别等发起任务时才吃 401。

安全敏感的场景还可以验名片自带的数字签名，先验签再信任内容。把名片放到发现地址，你的 Agent 就进入了协作网络——剩下的委托与交付，协议管。

自测

合上文章先自己答，再展开对照：

MCP 管工具接入、A2A 管 Agent 协作——这条边界在 Subagent 面前还清晰吗？

在 Subagent 面前边界确实模糊了，但辨析的钥匙是「信任域与运行时」而不是「对方是不是 Agent」。Subagent 是 Agent——但它跑在同一个 harness 里、共享鉴权与信任、生命周期被主 Agent 完全掌控，属于 harness 内部编排，走多 Agent 编排机制（详见多 Agent 编排篇），不涉及协议。A2A 处理的是跨信任域的平级关系：对方独立部署、有自己的用户与生命周期、互不暴露内部实现。一句话：管得着的叫 Subagent（编排），管不着的才叫协作方（协议）。

什么场景必须 A2A 而不能退化为「主 Agent 里塞 Subagent」？

三个信号叠加时。其一，跨信任域：对方是外部组织的 Agent，凭证、网络、数据所有权都分属两边——Subagent 机制建立在共享信任上，跨域走不通。其二，对方有独立生命周期：它服务多个客户、不为你常驻，任务需要异步提交与推送通知——Subagent 是主 Agent 进程的一部分，做不到「你睡它的活还在跑」。其三，能力专业且自主：对方对交付有自己的专业流程，你委托的是目标而非步骤——A2A 的不透明原则恰好要求你只看结果。三个信号都不占，Subagent 更简单：同一进程内、可控可停、无协议开销。

「Codex 主模型派生 subagent，还给每个指定不同模型」——这是 A2A 吗？

不是，拿三信号量：subagent 继承主会话的沙箱策略与权限模式，凭证同一份——不跨信任域；派生、追加指令、叫停、收结果全由主 Agent 编排——没有独立生命周期；提示词都是主 Agent 写好下发的——委托的是步骤不是目标。三个信号全不沾，属于 harness 内编排。再进一步，给 subagent 换轻量模型换的只是「大脑」不是「另一个主体」，连「Agent 接 Agent」都算不上，本质是模型调用层的路由。多模型协同不等于多 Agent 协作。真正跨了信任边界的是 Claude Code 与 Codex 互调这类跨厂商胶水工具，但它们靠自定义脚本而非标准契约——这正说明 A2A 要标准化的空白真实存在。

参考与延伸

Google 开发者博客《Announcing the Agent2Agent Protocol (A2A)》（2025-04-09）：协议发布官宣，含定位与 MCP 互补的官方口径 — developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability
Linux Foundation 新闻稿《Linux Foundation Launches the Agent2Agent Protocol Project》（2025-06-23）：捐入 Linux Foundation、逾百家科技公司支持的官方公告 — linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project
A2A 协议官方仓库（Apache-2.0）：现行规范文档（Agent Card 字段、发现地址与三种协议绑定）、官方多语言 SDK 与版本发布记录 — github.com/a2aproject/A2A
ChatGPT Learn 官方文档《Subagents》（2026-09-15 查证）：Codex subagent 的官方口径——并行派生与结果回收、subagent 模型与推理档位可逐个配置（gpt-5.6 / gpt-5.6-terra / gpt-5.6-luna 分工建议）、subagent 继承当前沙箱策略与权限模式，是本文「热点检验」一节的信源 — learn.chatgpt.com/docs/agent-configuration/subagents

下一站：Agent 框架：LangGraph、DeepAgents 与取舍——别人都替你造好的循环与状态管理，什么时候该用、什么时候是负资产。

学习舱 · 知识库