Agent 间协议概览

一句话理解：MCP 让 Agent 使用工具（纵向连接），A2A 让 Agent 与另一个 Agent 协作（横向连接）；工具有确定的输入输出，Agent 会自主推理、维持状态、需要多轮沟通，所以需要另一套协议。

设想这样一个场景：你们公司的订单售后 Agent 判断出“退款被支付渠道退回”，需要通知支付服务商处理。对方公司也有自己的对账 Agent，它有自己的模型、工具、记忆和审批流程，你既看不到、也不该看到。

你能把对方的 Agent 当作一个 MCP 工具来调用吗？对于“查一下支付状态”这类简单请求也许可以。但“协商一个重新打款方案、对方需要先内部审批、两天后再给答复”这种协作，就不是一次函数调用能表达的了。Agent 间协议要解决的正是这类问题。

为什么工具协议不够用

A2A 官方文档把两类对象的区别讲得很清楚：工具和资源是输入输出结构明确、通常执行特定功能的原语；Agent 是自主系统，会推理、规划、使用多个工具，并在较长的交互中维持状态。

维度	调用工具（MCP）	与 Agent 协作（A2A）
对方是什么	一个函数、数据源或提示模板	一个能自主决策的系统
交互形态	一次请求、一次结果	可能多轮往返、中途需要补充信息或授权
耗时	通常秒级	可能几分钟到几天
对方内部	输入输出由 Schema 描述	不透明：内部的模型、记忆、工具都不对外暴露
结果	工具结果	任务状态变化，以及报告、文件等产物
典型关系	同一个团队或供应商提供的能力	不同团队、不同公司、不同框架构建的 Agent

“不透明”是 A2A 的核心设计原则：远程 Agent 只暴露它能做什么、怎么和它沟通，内部实现保持隐藏。这让不同公司的 Agent 可以在不泄露知识产权和内部数据的前提下合作。

A2A 的核心概念

A2A（Agent2Agent）协议最初由 Google 发起，后来捐赠给 Linux Foundation，目前已发布 1.0 版本。2026 年 8 月，A2A 官方博客宣布项目加入 Agentic AI Foundation（AAIF），与 MCP 同属一个中立基金会治理。

它的参与方有三个：用户（人或自动化服务）、A2A 客户端（代表用户发起协作的 Agent 或应用）、A2A 服务端（通过 HTTP 端点提供 A2A 协议的远程 Agent）。

五个基本元素：

元素	是什么	订单场景里的例子
Agent Card	描述 Agent 身份、能力、技能与认证方式的 JSON 元数据文档，用于发现与建立连接	支付服务商的对账 Agent 声明自己能“查询与处理退款失败工单”
Task	有唯一 ID 和生命周期的、有状态的工作单元	“处理订单 ORD2026090142 的退款失败”
Message	一轮沟通，带有角色（用户或 Agent）	“请确认支付流水 PAY-88321 的退款失败原因并给出重试方案”
Part	消息与产物中的内容容器，可以是文本、文件或结构化数据	一段说明文字 + 一个 JSON 格式的退款明细
Artifact	任务过程中产生的具体产出	退款处理回执 PDF、处理结果记录

Agent Card 通常发布在 Agent 所在域名下的 /.well-known/agent-card.json，客户端据此了解对方能做什么、支持哪些交互方式、需要什么认证。1.0 版规范支持对 Agent Card 进行签名，用于验证身份。

任务的生命周期

A2A 用任务状态描述一次协作的进展。1.0 版规范定义的状态包括：已提交、处理中、已完成、失败、已取消、已拒绝，以及两种“中断”状态：需要输入 与 需要授权。

状态之间的流转如下：

图 1 · A2A 任务状态：两种中断状态让协作可以中途补充信息或授权

长任务怎么获得进展？规范提供三种方式：客户端轮询任务状态；通过流式连接（SSE）实时接收更新；或者注册 推送通知，由服务端在状态变化时回调客户端提供的 Webhook。这和长时间运行的任务里讲的异步模式是同一类问题。

规范采用分层设计：统一的数据模型、与传输无关的抽象操作（如发送消息、获取任务、取消任务、订阅任务），以及三种标准的协议绑定：JSON-RPC、gRPC 与 HTTP+JSON/REST。认证方面，Agent Card 可以声明 API Key、HTTP 认证、OAuth 2.0、OpenID Connect、双向 TLS 等方案。

MCP 与 A2A 如何配合

两者不是竞争关系，而是不同方向的连接。A2A 官方文档用一个汽修店的例子说明：顾客通过 A2A 与“店长 Agent”沟通故障；店长把任务委派给“技师 Agent”；技师通过 MCP 使用诊断仪等工具和维修手册；需要零件时，技师再通过 A2A 与“供应商 Agent”协商。

套用到订单场景：

图 2 · 一个 Agent 往往两者兼用：MCP 向下连工具，A2A 向外找 Agent

一个实用的判断方法：

对方是 确定性的能力（查询、计算、执行某个动作），并且输入输出能用 Schema 描述清楚 → 用 MCP 工具。A2A 文档也提到，定义明确、可以像工具一样无状态调用的能力，可以作为 MCP 兼容的能力暴露。
对方是 会自主判断的系统，需要多轮沟通、可能中途要求补充信息、耗时较长，并且属于另一个团队或公司 → 考虑 A2A。
两个 Agent 都在 自己的系统内部 → 通常不需要跨组织协议，用框架内的子 Agent 或 Agent-as-Tool 即可，见 Agent as Tool 与 Handoff。

另外，MCP 自身也在向长任务方向扩展：2026-07-28 版把 Tasks 做成了正式扩展，支持轮询、中途补充输入等能力。两个协议的边界会持续演进，选型时以“对方是工具还是自主 Agent、是否跨组织”为主要判断依据，而不是某个具体功能。

协议之外，更难的问题

协议解决的是“怎么沟通”，下面这些问题仍然需要产品和组织层面来回答：

信任：对方 Agent 的 Agent Card 是真的吗？它的回答能直接作为我方决策的依据吗？
责任：对方 Agent 答应重新打款，结果没有执行，责任如何界定？协作记录要保存多久？
数据边界：发给对方的消息里能包含哪些客户信息？对方返回的内容同样可能夹带注入指令。
成本与失控：两个 Agent 来回沟通，可能陷入无休止的循环，需要轮数、时长和预算上限。

这些问题和多 Agent 系统内部遇到的挑战本质相同，只是跨越了组织边界，见多 Agent 的代价。

常见误区

“有了 A2A，就不需要 MCP 了。” 两者方向不同。一个 Agent 往往同时通过 MCP 使用工具、通过 A2A 与其他 Agent 协作。
“公司内部的多 Agent 系统都应该用 A2A。” 同一套系统内部的 Agent 协作，框架自带的机制通常更简单高效。跨团队独立部署、跨技术栈或跨公司时，标准协议的价值才明显。
“把对方 Agent 包装成一个工具最省事。” 对简单、快速、无状态的请求可以这么做；对需要多轮沟通、审批和长时间等待的协作，强行包装成工具会丢失状态与中间交互。

产品经理检查清单

要对接的对象是工具还是自主 Agent？是否跨团队、跨公司？
协作是一次请求就能完成，还是需要多轮沟通、补充信息或额外授权？
任务可能持续多久？我们用轮询、流式还是推送来获取进展？
对方 Agent 的身份如何验证？认证方式是什么？
发给对方的信息里有哪些敏感数据？对方返回的内容如何校验？
协作失败、超时或结果有争议时，谁来接手？记录保存在哪里？

练习

为“订单售后 Agent 与支付服务商对账 Agent 的协作”写一份简要设计（45 分钟）：

写出对方 Agent 的 Agent Card 要点：名称、能力描述、两项技能、认证方式。
画出一次退款失败处理任务的状态流转，至少包含一次“需要输入”。
列出我方发出的第一条消息包含哪些 Part（文本、结构化数据），并标出哪些字段属于敏感信息、是否需要脱敏。
判断：这次协作中，哪些环节其实用 MCP 工具就够了？

下一步

工具与连接生态讲完了。下一个模块从「Skill 是什么」开始，讲 Agent 如何把方法、SOP 与脚本封装成可复用的能力。

Agent 间协议概览