A2A协议实战：两个Agent怎么聊

上篇用 MCP 写了一个天气查询工具。Claude 想知道北京天气。调 get_wear拿到结果，回答使用者。整条链路是 Agent → 工具单向调用。

但真实场景往往不是这样。你有一个 Agent 负责查天气，另一个 Agent 负责做决策——比如“今天适不适合打球”。查天气的 Agent 不管业务逻辑，做决策的 Agent 不管天气数据。它们需要互相通信。按理说，

痛点一：传统实现往往把对方的 URL、参数写死在代码里一旦对方改版。需要手动同步所有调用方，维护成本爆炸。

痛点二：不同团队使用不同语言或框架时没有统一的发现机制，导致“我怎么知道它到底提供了哪些能力？”的问题，

Google 在 2025 年 4 月发布了 A2A协议。目标很明确——建立一张“智能体互联网”，让不同厂商、不同框架开发的 Agent 能互相通信。

用后端的话说MCP 解决的是 Agent ↔ 工具 的通信，A2A 解决的是 Agent ↔ Agent 的通信。老实说，两个协议的定位互补：

 MCP A2A
Agent ──────► 工具 Agent ──────► Agent

A2A 的主要机制比较简单：每个 Agent 对外暴露一张“名片”。

This name is Agent Card,path fixed at / .well-known/agent.json. Any Agent that wants to know anor’s capabilities first fetches this card. The card contains name,description,endpoint URL,input schema,auth method—everything needed to call remote agent without hard‑coding.

This is analogous to a micro‑service registry . Instead of a central registry。each service publishes its own card at a well‑known location.

A2A 架构示意图

┌────────────────────────────┐
│ Agent Card │
│ /.well-known/agent.json │
├───────────────────────────┤
│ name: "wear-agent" │
│ description: "查天气" │
│ url: /api/tasks/wear │
│ input_schema: { │
│ city: string │
│ } │
│ auth: bearer_token │
└────────────┬───────────────┘
│① 先看名片：你是谁？怎么调，┌──────────────────────────┼───────────────────────────┐
▼ ▼
┌───────┴───────┐ ┌───────────────┐ ┌───────┴───────┐
│ BasketBall │ │ A2A Protocol │ │ Wear │
│ Agent │ │ │ │ Agent │
└───────▲───────┘ └──────▲─────────┘ └──────▲─────────┘
| | |
② 提交 task ③ 处理 task ④ 返回结果
POST /tasks JSON‑RPC JSON response

痛点三：如果忘记更新名片或 Schema 写错。会导致 LLM 构造错误参数，却没有直观报错； 在实际落地时需要 CI 检查卡片与实现的一致性。

两个 Agent 怎么聊：天气 + 打球案例

Wear Agent：暴露能力

The Wear Agent only does one thing: receive a city name and return wear. It publishes two artefacts:

• Name Card:

{
"name"这方面。"wear-agent","description": "查询指定城市的实时天气，返回温度、天气状况、风速","url": "http://localhost:","capabilities": {
"streaming": false
},"skills":
}
}
]
}

关键点：

• input_schema 必须遵循 JSON Schema 标准；否则 LLM 会误解参数类型。
• "required" 列表一定要完整。否则可选字段会被省略，引起后端校验错误。
• CARD 与实际服务端点保持同步是自动化部署的关键一步。

Name Card + Task Endpoint = 完整 A2A 能力。

BasketBall Agent：读名片、做决策

1. 读取名片：The agent sends ,parses:
   • The skill ID it needs .
   • The call URL .
   • The required payload schema.
   This eliminates any hard‑coded path;if Wear Agent changes its endpoint later,only card updates.
2. 提交任务：Create a payload that conforms to schema:

   {
   "task"这方面。"check_wear",“params”: {
   “city”这方面，“北京”
   }
   }
   

   POST it to . The protocol returns a task ID and eventually a status object;when completed you receive:

   {
   至于“city”，“北京”,“temperature”: 22,“condition”: “晴”。“wind_speed”: 5
   }
   

3. 业务决策：The Basketball Agent evaluates wear:
   • If temperature ∈  °C & condition = “晴” & wind_speed ≤ 10 km/h → “可以打球”。
   • If condition ∈ {“雨”。“雪”,“雾」} or wind_speed> 15 → “改室内”。

This flow shows that Basketball Agent never hard‑codes any URL or request shape – everything is discovered at runtime from card.

为什么不用 MCP？

MCP is great for exposing **functions** as tools. However:

• MCP calls are *stateless* and single‑hop – ideal for simple utilities.
• A2A treats remote party as an **independent agent** with its own lifecycle,state management and possibly its own sub‑graph of tools.
• If you need multi‑step collaboration,MCP would force you to embed that logic inside your own prompt chain。bloating caller.
• A2A’s **skill abstraction** lets you delegate whole capabilities while keeping your own business logic clean.

MCP vs A2A 对比表

维度	MCP	A2A
调用方向	Client → Tool Agent → Tool
	Agent ↔︎ Agent
主要机制	@tool 装饰器注册函数 函数列表硬编码在模型提示中 痛点：每次新增工具都要重新训练或提示更新。	Agent Card 名片动态发现 统一方法 / .well-known/agent.json 痛点：若卡片未同步会导致运行时错误。说起来，
后端类比	REST API 无状态函数调用	微服务间 RPC 支持状态管理、异步任务流
触发方式	L​LM 推理链中决定是否调用工具 痛点：推理过程不易审计；不过，工具调用散落在 Prompt 中。	L​LM 主动或业务代码主动发起任务请求 更易审计与监控
协议提出方	An​thropic OpenAI function calling 等实现	Google DeepMind 正在形成领域标准
适用场景	- 数据库查询、搜索 API、短暂计算等单一工具场景	- 多 Agent 编排、委派、链式调用 - 跨组织协作

快速上手小结

• Pain Point: 硬编码 endpoint  → Solve: 使用统一的 .well-known/agent.json Card .

Pain Point: 跨语言团队难以共享接口定义 → Solve:  作为语言无关的输入描述。不过，

Pain Point: 增加功能后需要逐个更新调用方 → Solve: 只更新 Card。即可自动生效，无需 redeploy。不过，

Pain Point: LLM 调用工具时缺少状态跟踪 → Solve: 任务式异步模型。可通过监控面板追踪每一步进度。

Pain Point: 多 Agent 协作缺乏统一治理 → Solve:& nbs p;统一安全模型写在 Card 中，由网关统一校验。l i>

© 2026 Tech·AI Insights – All rights reserved.

---