跳到主要内容

A2A 入门与使用场景

当 Tool Use、MCP 这些能力逐渐清楚之后，下一步很容易出现一个新问题：

如果一个 Agent 已经不只是自己调工具，而是需要把任务交给另一个独立 Agent 去完成，系统之间应该怎么协作？

A2A 讨论的就是这一层。

这篇文档主要回答 5 件事：

  • A2A 是什么
  • 它和 MCP 的区别是什么
  • 它的核心对象为什么是 Task
  • 什么场景值得上 A2A
  • 在这个模块里它应该放在什么位置来学

本文参考的主要资料：

1. A2A 是什么​

A2A 全称通常写作 Agent2Agent Protocol。

按官方说明，它是一套开放协议，用来支持不同 Agent 系统之间的通信与互操作。

这句话里有两个关键词：

  • 不同 Agent 系统
  • 互操作

A2A 不是讨论单个 Agent 内部怎么调工具，而是在讨论：

  • 一个 Agent 怎样发现另一个 Agent 的能力
  • 怎样把任务发给对方
  • 怎样接收进度、状态和最终产物
  • 怎样在彼此不共享内部实现的前提下完成协作

可以先这样理解：

A2A 关注的是 Agent 与 Agent 之间怎样以统一方式协作。

2. 为什么会需要 A2A​

当系统还是单 Agent 时，很多事都还能在一个进程、一个框架、一个状态树里解决。

但一旦开始出现这些情况：

  • 不同团队维护不同 Agent
  • 不同 Agent 用不同框架实现
  • 某些能力已经是独立服务
  • 一个 Agent 需要把子任务交给另一个 Agent

问题就会从“怎么调工具”变成：

怎么和另一个独立 Agent 系统合作。

这时直接把对方当工具调用，有时也能工作，但会逐渐遇到边界：

  • 对方不只是一个同步函数
  • 对方任务可能会长时间运行
  • 对方会产出阶段性结果和工件
  • 对方可能需要自己的权限、认证和任务状态管理

这就是 A2A 的典型出现位置。

3. A2A 的核心对象为什么是 Task​

A2A 和普通工具调用很不一样的一点，是它把 Task 放在协议中心。

在 A2A 里，任务通常不是“一次函数调用立即返回”，而是：

  • 有唯一 ID
  • 有状态生命周期
  • 有历史消息
  • 有产物 Artifacts
  • 可以流式更新
  • 可以异步通知

A2A 更接近：

把另一个 Agent 当成一个会持续处理任务的远程协作者。

而不是把它当作“一个立刻返回结果的函数”。

4. A2A 的几个核心概念​

4.1 Agent Card​

Agent Card 可以理解成一个 Agent 的公开说明书。

它通常用来描述：

  • 这个 Agent 是谁
  • 它能做什么
  • 支持哪些输入输出模式
  • 有哪些技能 skills
  • 能否流式返回
  • 支持哪些安全方案

它的作用很像能力发现层。

4.2 Skills​

Skills 用来声明这个 Agent 擅长的能力。

例如：

  • 法务审查
  • 调研摘要
  • 日程协调
  • 数据清洗

这有助于上游 Agent 判断：

  • 这个任务该不该交给它
  • 这个 Agent 是不是合适的协作者

4.3 Task​

Task 是 A2A 里的工作单元。

它代表一个完整请求从开始到结束的生命周期。

4.4 Artifact​

Artifact 是任务产物。

它可以是：

  • 文本
  • 文件
  • 结构化数据
  • 增量结果

A2A 不只是“问一句答一句”，也支持更完整的结果交付。

4.5 Streaming / Push Notifications​

A2A 规范还考虑了：

  • 流式更新
  • 长任务重连
  • 异步推送

所以它更适合长任务和跨系统协作，而不只是一次短请求。

5. A2A 和 MCP 的区别​

这两个概念很容易被放在一起，但它们讨论的问题并不一样。

5.1 MCP 主要是能力接入协议​

MCP 的重点是：

  • 工具怎么暴露
  • 资源怎么暴露
  • 提示模板怎么暴露
  • 客户端怎么连接 server

它通常是：

把外部能力以统一协议接进 AI 应用。

5.2 A2A 主要是 Agent 互联协议​

A2A 的重点是：

  • Agent 怎样发现另一个 Agent
  • 怎样发起任务
  • 怎样追踪进度
  • 怎样接收产物

它通常是：

让一个 Agent 系统和另一个 Agent 系统合作。

5.3 一个简单区分​

可以这样记：

  • MCP：连接工具、资源、提示
  • A2A：连接 Agent、任务、产物

6. A2A 和 Tool Calling 的区别​

Tool Calling 通常是：

  • 当前 Agent 选择一个能力
  • 立刻调用
  • 得到结果
  • 回到本地继续推理

A2A 通常是：

  • 当前 Agent 发现另一个远程协作者
  • 把任务发给对方
  • 接收任务状态变化
  • 最后整合对方产物

所以 A2A 常见于：

  • 子任务委派
  • 多团队协作
  • 远程 Agent 编排
  • 长流程代理合作

7. 什么场景适合 A2A​

7.1 多 Agent 系统是独立部署的​

如果多个 Agent 并不在同一运行时里，而是各自独立服务化部署，A2A 就很自然。

7.2 一个 Agent 需要把任务委派出去​

例如：

  • 主控 Agent 负责拆任务
  • 调研 Agent 负责搜集资料
  • 合规 Agent 负责审查
  • 汇总 Agent 负责整理输出

这时 A2A 的任务模型会比普通函数调用更贴切。

7.3 任务有中间状态和产物​

如果远程任务会：

  • 持续运行
  • 分阶段产出结果
  • 需要断线重连
  • 需要流式回传

A2A 的协议设计会更合适。

7.4 需要跨框架互联​

如果一侧是 LangGraph，另一侧是 OpenAI Agents SDK，还有第三侧是内部自研系统，互联协议的价值会更明显。

8. 什么场景不一定需要 A2A​

8.1 单运行时内的多 Agent​

如果所有 Agent 都在同一个框架和同一个运行时里，先用框架自己的：

  • graph
  • workflow
  • handoff
  • team / crew

通常更简单。

8.2 只是同步工具调用​

如果下游能力只是：

  • 查一个接口
  • 读一个资源
  • 返回一段数据

那它往往按工具处理就够了，不一定需要变成远程 Agent。

9. 在这个模块里，A2A 应该放在哪里​

推荐放在：

  1. Tool Use / Function Calling
  2. MCP 入门与实践
  3. MCP vs Tool Calling
  4. 本文
  5. Workflow vs Agent
  6. Agent Planning Patterns

这条顺序背后的逻辑是：

  • 先理解单 Agent 的工具调用
  • 再理解能力接入协议
  • 最后进入 Agent 与 Agent 的协作协议

10. 和哪些框架章节一起看最合适​

A2A 最适合和这些内容一起看：

因为到这一步，核心问题已经不是“怎么调一个工具”，而是：

  • 怎样做任务委派
  • 怎样做远程协作
  • 怎样处理跨系统状态与产物

11. 小结​

A2A 最适合放在 Agent 协作层来理解。

它不是 MCP 的替代品，也不是普通 tool calling 的升级版。

它真正处理的是：

  • Agent 怎样发现另一个 Agent
  • 怎样发起和管理任务
  • 怎样接收中间状态与最终产物
  • 怎样在不同系统之间完成协作