Agent 间通信 A2A：让不同 AI Agent 能互相认识、互相调用、互相负责

Agent 间通信，简单说就是：让不同系统、不同框架、不同团队做出来的 AI Agent，可以像同事一样互相发现、互相协作，并且出问题时能追溯责任。

如果说 MCP 是让 Agent 会用工具，RAG 是让 Agent 会查资料，那么 A2A 解决的是另一个问题：当一个 Agent 自己做不完一件事时，怎样安全、标准地把任务交给另一个 Agent？

它不是简单的“两个程序互相发 HTTP 请求”。真正有价值的地方在于三件事：

这才是 A2A 的核心。

一、A2A 是 Agent 之间的“协作协议”

你可以把 A2A 想象成一个大型商场里的服务协作系统。

商场里有咨询台、售后台、会员中心、财务柜台、安保中心。顾客来到咨询台，说：

我想买一台电脑，还想知道能不能开发票、有没有会员积分、坏了能不能维修。

咨询台自己不可能处理所有事情。它要把商品问题交给电脑柜台，把发票问题交给财务柜台，把积分问题交给会员中心，把售后问题交给维修中心。

但这里有几个前提：

• 咨询台要知道每个柜台在哪里；
• 要知道每个柜台负责什么；
• 要确认对方是真的官方柜台，不是临时冒充的；
• 要记录这次转交过程，方便后续追踪。

A2A 做的就是这套事情。

放到 AI Agent 里，一个旅行规划 Agent 可能会调用天气 Agent 查询目的地天气，调用航班 Agent 查询机票，调用酒店 Agent 查询住宿，再调用预算 Agent 计算费用。

如果没有统一协议，每两个 Agent 之间都要单独写一套对接逻辑。Agent 越多，集成成本越高，系统也越乱。A2A 的目标，就是把这种“点对点乱接线”，变成一套标准化的协作方式。

二、为什么需要 A2A：Agent 多了以后，最大的问题不是能力，而是协作

单个 Agent 再强，也有边界。

它可能擅长写报告，但不擅长查实时库存；它可能擅长客服回复，但不能直接处理退款；它可能能分析合同，但没有权限访问企业内部知识库。

比如一个企业采购场景：

用户：帮我采购 100 台适合设计师使用的笔记本电脑，预算控制在 80 万以内，并生成采购建议。

这个任务看起来是一句话，实际包含需求理解、商品查询、库存确认、价格比较、合规检查和报告生成。一个 Agent 全部自己做，容易出现三个问题：

所以 A2A 的价值不只是“让 Agent 能说话”，而是让 Agent 之间的协作变得可发现、可验证、可追踪、可治理。

三、A2A 到底在做什么：四个关键动作

从工程视角看，一次标准的 A2A 协作可以拆成四个动作：

1. 找到对方；
2. 识别对方；
3. 理解对方会什么；
4. 发起任务并追踪过程。

1. 发现：我能找谁帮忙？

A2A 里，每个 Agent 可以通过标准方式暴露自己的信息。典型做法是放一个 AgentCard，也就是一份描述自己的 JSON 文件，常见路径类似：

/.well-known/agent.json

这就像公司官网上的“营业执照 + 服务目录”。调用方不用先猜这个 Agent 能做什么，而是先读取这张卡。

2. 识别：你真的是你吗？

只靠一个 JSON 文件是不够的。任何人都可以写一份：

{
  "name": "PaymentBot",
  "description": "I can process payments."
}

问题是：它真的是官方支付 Agent 吗？

生产环境需要更强的身份验证，例如 mTLS、OAuth、独立凭证、Signed Agent Cards、DID 或其他可验证身份机制。核心思想是：Agent 的身份不能只靠 name 字段声明，而要能被验证。

3. 声明能力：我会做什么，怎么调用我？

AgentCard 里最重要的字段之一是 skills。简化示例：

{
  "name": "WeatherBot",
  "description": "提供天气查询能力",
  "url": "https://weather.example.com/a2a",
  "version": "1.0.0",
  "authentication": {
    "schemes": ["oauth2"]
  },
  "skills": [
    {
      "id": "get_current_weather",
      "name": "查询实时天气",
      "description": "根据城市名称查询当前天气",
      "inputModes": ["text", "json"],
      "outputModes": ["json"]
    }
  ]
}

这张卡至少告诉调用方四件事：这个 Agent 是谁、服务地址在哪里、支持什么认证方式、有哪些可调用能力。

能力声明不是随便写一句“我会查天气”就结束了。生产级 AgentCard 最好明确输入格式、输出格式、错误码、超时时间、权限范围、数据是否会被保存，以及是否支持流式输出或异步任务。

4. 调用和追踪：任务怎么交出去，结果怎么拿回来？

当调用方确认对方身份和能力后，就可以通过统一协议发送任务。A2A 常见底层通信方式是基于 HTTP(S) 的 JSON-RPC。

{
  "jsonrpc": "2.0",
  "id": "task-001",
  "method": "sendTask",
  "params": {
    "message": {
      "role": "user",
      "parts": [
        {
          "type": "text",
          "text": "查询下周一上海的天气"
        }
      ]
    },
    "trace_id": "trace-20260623-001"
  }
}

注意这里的 trace_id 很关键。

它的作用不是完成业务，而是为了之后能追踪谁发起了调用、调用了哪个 Agent、调用耗时多久、中间有没有继续转交、最终结果来自哪里。

没有 trace 的多 Agent 系统，后期排查问题会非常痛苦。

四、A2A 适合用在哪些场景

A2A 不适合所有项目。它真正适合的是“多个 Agent 之间需要协作”的场景。

反过来，如果你的系统只有一个 Agent，而且它只是调用几个工具，那么优先考虑 MCP 或普通工具调用就够了。不要为了“架构高级”而强行引入 A2A。

五、不是所有任务都适合同步等待

很多人一想到接口调用，就想到“请求一次，马上返回”。

但 Agent 任务的时间差异很大。查天气可能 1 秒完成，生成一份 30 页分析报告可能要几分钟，训练一个模型可能要几小时。A2A 因此需要支持多种交互方式。

选型可以简单记：

30 秒内完成：同步
几分钟完成：异步轮询
用户正在等待：流式更新
几小时或更久：推送通知

推送通知尤其要谨慎。调用方不仅要提供 callback 地址，还要处理 webhook 签名校验、失败重试和幂等，否则“通知到了”也可能变成新的事故现场。

六、完整案例：旅行规划 Agent 如何调用天气 Agent

下面用一个完整业务案例把 A2A 串起来。

用户：我下周去成都玩 3 天，帮我规划行程，顺便考虑天气情况。

旅行规划 Agent 自己擅长做行程安排，但它不一定有实时天气数据。于是它需要调用天气 Agent。

它大概会这样做：

1. 识别目的地是成都，时间是下周 3 天；
2. 在注册表或固定配置里找到天气能力候选项；
3. 读取候选 Agent 的 AgentCard；
4. 验证 AgentCard 签名、服务地址、调用权限和 skills；
5. 确认天气 Agent 支持按城市和日期范围查询天气；
6. 带上 trace_id 发起任务；
7. 拿到天气结果后，再把它融合进最终行程。

天气 Agent 的能力声明最好像这样具体：

{
  "id": "get_forecast",
  "name": "查询未来天气预报",
  "description": "根据城市和日期范围返回天气预报",
  "input_schema": {
    "city": "string",
    "start_date": "string",
    "end_date": "string"
  },
  "output_schema": {
    "daily": [
      {
        "date": "string",
        "temperature": "string",
        "condition": "string",
        "suggestion": "string"
      }
    ]
  }
}

旅行规划 Agent 调用后，可能得到这样的结果：

{
  "daily": [
    {
      "date": "2026-06-29",
      "temperature": "24-31°C",
      "condition": "多云",
      "suggestion": "适合安排户外景点"
    },
    {
      "date": "2026-06-30",
      "temperature": "23-29°C",
      "condition": "小雨",
      "suggestion": "建议安排博物馆、茶馆等室内活动"
    },
    {
      "date": "2026-07-01",
      "temperature": "25-32°C",
      "condition": "晴",
      "suggestion": "适合短途户外活动，注意防晒"
    }
  ]
}

最终它就能生成更合理的行程：

第 1 天：天气多云，适合安排宽窄巷子、人民公园、锦里等户外路线。
第 2 天：有小雨，建议安排成都博物馆、茶馆体验、室内餐厅探店。
第 3 天：天气晴朗，可安排熊猫基地或青城山短途游，注意防晒。

这个案例里，A2A 的价值不是“查到天气”本身，而是让旅行规划 Agent 能够标准、安全、可追踪地调用另一个专业 Agent。

七、A2A 和 MCP、RAG、HITL 的关系

很多人会把 A2A、MCP、RAG、HITL 混在一起。其实它们解决的是不同方向的问题。

真实系统里，它们往往会组合使用，而不是互相替代。

如果是上一篇讲 RAG，那么这篇 A2A 可以看成进一步扩展：

• RAG 解决“知识从哪里来”；
• MCP 解决“工具怎么调用”；
• A2A 解决“能力从哪里来”；
• HITL 解决“哪些事必须让人负责”。

八、常见坑：A2A 不是把接口接起来就完了

A2A 最容易踩坑的地方，不在协议字段，而在“以为能调通就结束了”。

可以用这个流程判断要不要引入 A2A：

关键原则很简单：不是有 Agent 就要上 A2A，而是多个 Agent 需要标准协作时才上 A2A。

九、落地时可以直接复用的设计清单

做 A2A 系统时，可以用下面这份清单自查。

AgentCard 必须回答的问题

1. 我是谁？
2. 我的服务地址是什么？
3. 我支持哪些认证方式？
4. 我有哪些能力？
5. 每个能力的输入是什么？
6. 每个能力的输出是什么？
7. 哪些能力需要审批？
8. 哪些能力有权限限制？
9. 是否支持流式、异步或推送？
10. 出错时返回什么？

调用链路必须记录的信息

1. trace_id
2. parent_trace_id
3. caller_agent
4. target_agent
5. skill_id
6. input_summary
7. output_summary
8. status
9. error_code
10. timestamp

权限设计必须遵守的原则

1. 每个 Agent 独立身份；
2. 每个 Agent 最小权限；
3. 高风险动作需要审批；
4. 凭证可轮换；
5. 凭证可撤销；
6. 不共享 API Key；
7. 不默认信任上下文；
8. 每跳调用都要重新校验。

这里尤其要注意“上下文传递”的风险。

一个 Agent 把用户上下文传给另一个 Agent 时，不代表后面的 Agent 可以自动继承所有权限。更安全的做法是：

每一跳调用都重新鉴权；
每一个动作都重新授权；
不要把原始 session 无限制向下传递。

可以把它理解为：

已知 Agent 不等于可信操作；
可信身份不等于拥有所有权限；
拥有上下文不等于可以继续转授权。

十、一句话记住 A2A

A2A 的本质不是“让 Agent 互相发消息”，而是让不同 Agent 在可验证身份、明确能力边界和可追踪责任链的前提下，安全地协同完成任务。