AI Agent开发实战（七）Agent 间协作协议 —— A2A

缘来如此09

340人浏览 · 2026-08-06 08:58:00

缘来如此09 · 2026-08-06 08:58:00 发布

引言：

上一篇 MCP 解决的是"Agent 怎么用工具"。但当 Agent 越来越多、还分属不同团队甚至不同公司,一个新问题浮现:Agent 与 Agent 之间怎么互相发现、怎么委托任务、怎么协作? 这不是工具接入能覆盖的。这一篇的主角 A2A(Agent2Agent) 协议,专治这个问题。读完你会理解 A2A 的核心概念、它和 MCP 的清晰分工,以及整个互操作生态的走向。

一、为什么 MCP 不够:工具接入 ≠ 智能体协作

先回到一个根本区别。MCP 让你的 Agent 能调用工具——但工具是被动、无状态、听话的:你调 get_weather,它返回天气,不会反问你、不会自己规划、不会说"这事我干不了但我认识能干的人"。

而另一个 Agent 是主动、有状态、会思考的。当你想让 Agent A 把一件复杂任务委托给 Agent B(可能是别的团队、别的公司、用完全不同框架写的),事情就复杂了:

Agent B 到底会干什么?你怎么知道它的能力边界?(发现问题)
任务可能要跑很久(比如"生成一份行业研究报告"),怎么跟踪进度、拿中间结果?(长任务问题)
双方用不同框架、不同模型,怎么说同一种话?(互操作问题)
跨组织协作,身份和鉴权怎么办?(信任问题)

把另一个 Agent 硬塞进"工具"的模型里是别扭的——工具调用假设"一问一答、马上返回",而 Agent 协作往往是"委托一个目标、异步推进、多轮交互"。A2A 就是为"Agent 把 Agent 当协作对象"而设计的协议,由 Google 在 2025 年牵头提出并开源,随后捐给 Linux 基金会,得到大量厂商支持。

一句话记住分工:MCP 让 Agent 接上工具(往下扎根),A2A 让 Agent 找到 Agent(向外握手)。这一节的对比后面还会展开。

二、A2A 的核心概念

A2A 建立在大家熟悉的 Web 技术栈上(HTTP、JSON-RPC、SSE),所以工程上门槛不高。它的几个核心概念如下。

Agent Card(能力名片)。 这是 A2A 的灵魂。每个对外提供服务的 Agent,都发布一份机器可读的"名片"(通常是一个约定路径下的 JSON,如 /.well-known/agent.json),声明:我是谁、我能干什么(技能列表)、我的服务地址、我需要什么鉴权、支持哪些交互方式。别的 Agent 靠读这张卡来发现和理解你——就像人类交换名片。

{
  "name": "行业研究 Agent",
  "description": "根据主题生成结构化行业研究报告",
  "url": "https://research.example.com/a2a",
  "skills": [
    {"id": "market_report",
     "description": "生成指定行业的市场分析报告,支持中英文"}
  ],
  "authentication": {"schemes": ["Bearer"]}
}

Task(任务)。 A2A 的交互以"任务"为中心,而非"一次函数调用"。客户端 Agent 向服务端 Agent 发起一个 Task(比如"给我一份新能源汽车行业报告"),这个 Task 有自己的生命周期状态:submitted(已提交)→ working(处理中)→ input-required(需要补充输入)→ completed / failed。这套状态机正是为长耗时任务准备的。

Message 与 Part(消息与部件)。 双方在一个 Task 内来回发消息。消息由多个 Part 组成,Part 可以是文本、文件、结构化数据——支持多模态协作,不局限于纯文本。

Artifact(产出物)。 Task 完成后的正式交付物(那份报告、那张图),作为结构化结果返回。

Streaming 与 Push(流式与推送)。 对长任务,客户端可以用 SSE 流式接收进度更新;甚至可以注册回调,让服务端在任务状态变化时主动推送通知——这样客户端不必傻等或轮询。

 客户端 Agent                          服务端 Agent
       │   ①读取 Agent Card,确认它会干这活   │
       │  ─────────────────────────────▶  │
       │   ②发起 Task:"生成新能源行业报告"     │
       │  ─────────────────────────────▶  │
       │                                   │ submitted → working
       │   ③流式回传进度(SSE)               │
       │  ◀─────────────────────────────  │
       │   ④(如需)补充输入                  │ input-required
       │  ─────────────────────────────▶  │
       │   ⑤返回 Artifact(报告)            │ completed
       │  ◀─────────────────────────────  │

这套设计的精髓是:它把"Agent 协作"当成一等公民来建模——有发现、有异步、有状态、有多模态、有跨组织鉴权,而不是勉强套用工具调用那套一问一答。

三、A2A 与 MCP:互补,不是竞争

这是本篇最该记牢的一点。很多人一看两个协议就问"该用哪个",这是个假问题——它们解决不同层次的事,通常一起用。

用一个类比:你(一个 Agent)要完成"筹办一场活动"。

你自己用的工具——查日历、订场地系统的 API、发邮件——这是你向下够到的能力,用 MCP 接入。
你要协调的别的专业方——摄影师、餐饮供应商——他们是独立的个体/Agent,有自己的判断和流程,你向外委托任务给他们,用 A2A 协作。

放到架构图里:

        ┌──────────────── 你的 Agent ────────────────┐
        │                    [ LLM ]                  │
        │                      │                      │
        │   ── A2A ──▶ 委托给别的 Agent(向外握手)     │
        │        ├──▶ [法务 Agent]                     │
        │        └──▶ [财务 Agent]  ← 它自己内部又用    │
        │                            MCP 接自己的工具   │
        │                                             │
        │   ── MCP ──▶ 调用自己的工具(向下扎根)        │
        │        ├──▶ [数据库]                         │
        │        └──▶ [邮件系统]                       │
        └─────────────────────────────────────────────┘

注意图里的细节:你通过 A2A 委托给"财务 Agent",而财务 Agent 自己内部又用 MCP 接了它的数据库工具。两个协议正交、可嵌套:A2A 管 Agent 之间的水平协作,MCP 管单个 Agent 垂直向下的工具接入。

维度	MCP	A2A
连接对象	Agent ↔ 工具/数据	Agent ↔ Agent
对方性质	被动、无状态、听话	主动、有状态、会思考
交互模型	一问一答、即时返回	委托任务、异步长时
关键概念	Tools/Resources/Prompts	Agent Card/Task/Artifact
提出方	Anthropic	Google(捐 Linux 基金会)
一句话	让 Agent 用上工具	让 Agent 找到 Agent

记住:问"MCP 还是 A2A"就像问"该用数据库还是用 HTTP"——层次不同,该用就一起用。

四、身份、鉴权与可信:跨组织协作绕不开的坎

工具调用大多在你自己的信任域内。但 A2A 的典型场景是跨团队、跨公司协作——你委托的 Agent 可能在另一家公司的服务器上。这就把安全推到了最前面。

鉴权在协议层是一等公民。 Agent Card 里就声明了需要什么鉴权方式(OAuth、API Key、mTLS 等)。客户端 Agent 发起 Task 前必须先满足对方的鉴权要求。A2A 复用成熟的 Web 鉴权标准,而不是自己发明一套。

要防的几类风险:

冒充与信任链:你读到的 Agent Card 是真的吗?对方声称的能力可信吗?跨组织时需要有机制验证名片来源(如签名、可信注册中心)。
越权委托:委托出去的任务,对方 Agent 会不会拿到超出必要的数据/权限?同样遵循最小授权——只给完成这个 Task 必需的信息。
提示注入的传染:如果对方 Agent 返回的内容里藏了恶意指令,会不会污染你的 Agent?跨 Agent 边界的输入,和工具返回一样,都要当不可信数据处理
责任与审计:多个 Agent 协作出了错,谁负责?务必全链路留痕——哪个 Agent、在哪个 Task、做了什么,是事后追责和调试的唯一依据。

务实的建议:现阶段 A2A 最成熟、最安全的落地场景是"同一组织内、多个团队的 Agent 互通"——信任基础好、鉴权可控。真正开放的跨公司 Agent 互联,协议在快速演进,但信任基础设施(可信注册、身份验证)还在建设中,生产上要谨慎,关键委托仍建议保留人工审批

五、更大的互操作图景:A2A 之外还有谁

A2A 是目前声量最大的 Agent 协作协议,但互操作这件事仍在群雄探索期,了解全景能帮你不被单一标准绑架。

ACP(Agent Communication Protocol)。 由 IBM/BeeAI 等推动,同样面向 Agent 间通信,更强调基于 REST 的简洁接入和本地/离线场景。目标和 A2A 有重叠,是另一条技术路线。

AGP / AGNTCY 等生态尝试。 一些厂商和联盟(如思科牵头的 AGNTCY)在推更完整的"Agent 互联网"设想——不只是通信协议,还包括 Agent 目录、身份、可观测的整套基础设施。

框架自带的协作机制。 别忘了,在跨组织协议成熟之前,大量多 Agent 协作其实发生在单一框架内部:LangGraph 的节点间状态传递、OpenAI Agents SDK 的 handoff、CrewAI 的角色协作。这些是"进程内/框架内"的协作,不需要 A2A 这种跨边界协议,反而更简单可靠。

该怎么看待这片混战? 三条判断:

先分清协作发生在哪一层。 同一框架内的多 Agent,用框架自带机制即可,别为了赶时髦硬上 A2A。只有跨框架、跨组织时,标准协议才真正有价值。
MCP 已基本尘埃落定,A2A 是当前 Agent 协作层的领跑者,但尚未一统。押注时给自己留一层抽象,别把业务逻辑和某个协议的细节焊死。
协议是手段不是目的。 用户要的是"任务被完成",不是"我用了 A2A"。能用简单方案解决的,不必上重协议。

六、踩坑记录:接入 Agent 协作时的常见误区

误区一:把什么都做成 A2A。 一个只会"一问一答、马上返回"的下游服务,做成 MCP 工具就行,包装成 A2A Agent 纯属过度设计。先判断对方是"工具"还是"Agent"——被动听话的是工具,主动有状态的才是 Agent。

误区二:用同步思维对待长任务。 A2A 的 Task 天生是异步的。如果你还用"发请求 → 阻塞等返回"的写法去调一个要跑十分钟的报告 Agent,不是超时就是把自己卡死。长任务一定要用流式/推送 + 状态轮询,别同步硬等。

误区三:忽略 input-required 状态。 委托出去的任务中途可能需要补充信息(对方 Agent 卡在 input-required)。如果你的客户端不处理这个状态,任务就永远悬在那。要把 Task 状态机完整处理掉,尤其是"需要补充输入"和"失败"两个分支。

误区四:跨 Agent 的返回内容照单全收。 别的 Agent 返回的内容可能不可信(错误、幻觉、甚至注入)。委托 ≠ 甩锅——拿回结果后该校验校验、该兜底兜底,尤其结果要用于后续关键动作时。

误区五:没有全链路追踪。 多 Agent 协作一旦出问题,没有贯穿各 Agent 的 trace 几乎无法定位。从第一天就把 Task ID / trace 透传下去,别等出事才想起加。

七、小结

这一篇我们越过了"工具",进入"Agent 协作":A2A 用 Agent Card 解决发现、用 Task 状态机 + 流式/推送解决长时异步、用 Message/Part 支持多模态、用协议层鉴权应对跨组织信任。它和 MCP 是正交互补的两层——MCP 让 Agent 向下用工具,A2A 让 Agent 向外找 Agent,该用就一起用。而互操作生态(ACP、AGNTCY……)仍在演进,务实的态度是"先分清协作发生在哪一层,能简单就别上重协议"。