从零理解 A2A当一个 Agent 需要另一个 Agent 帮忙MCP 解决了 Agent 和工具之间的问题。但 Agent 和 Agent 之间呢目录一个 Agent 搞不定的事为什么不能直接调用A2A 是什么Agent 怎么发现其他 Agent发现之后怎么通信出问题了怎么办A2A 和 MCP 是什么关系应用场景总结一个 Agent 搞不定的事假设你在做一个电商系统搭了两个 AI Agent库存 Agent监控库存水平发现哪些商品快卖完了采购 Agent负责联系供应商下单补货库存 Agent 发现某商品只剩 10 件需要补货。但它不能自己下单——那是采购 Agent 的职责。问题来了库存 Agent 怎么告诉采购 Agent「帮我订 500 件商品 X」你可能会说这不就是一个函数调用的事吗没那么简单。上一篇我们讲了 MCPModel Context Protocol解决了 Agent 和工具之间的问题——让 AI 能查数据库、调 API、读文件。但 MCP 的视角是「Agent ↔ 工具」是一个 Agent 使用外部资源。A2A 要解决的是另一个问题Agent ↔ Agent两个独立的 AI 智能体之间怎么沟通、协作、分配任务。一句话区分MCP 是给 Agent 配工具A2A 是让 Agent 之间能开会协作。为什么不能直接调用我最初的想法是两个 Agent 都是程序为什么不能直接函数调用// 库存 Agent 直接调用采购 Agent 的方法purchaseAgent.createOrder(商品X,500);如果两个 Agent 在同一个项目里、同一个进程里确实可以这么做。但现实世界往往是这样的库存 Agent 是 Python 写的采购 Agent 是 Java 写的库存 Agent 部署在北京的服务器采购 Agent 部署在上海库存 Agent 是你公司的采购 Agent 是合作伙伴提供的甚至你都不知道采购 Agent 内部是怎么实现的你只知道它能下单直接函数调用的前提是同语言、同进程、同部署环境。现实世界几乎不满足这些条件。那怎么办你需要一个跨语言、跨网络、跨组织的通用协议。就像人与人之间用中文或英文沟通一样Agent 之间也需要一种「通用语言」。这就是 A2AAgent-to-Agent协议要解决的核心问题互操作性。不管你是 Python 还是 Java不管你部署在哪里只要大家都说 A2A 这种「语言」就能互相沟通。A2A 是什么A2AAgent-to-Agent协议是一个由 Google 发起、现由 Linux 基金会托管的开放标准。它的目标很明确让不同 AI Agent 能相互发现、通信、协作共同完成复杂任务。你可以把它理解为 AI 智能体世界的「互联网协议」。就像 HTTP 让不同的网站能互相链接一样A2A 让不同的 Agent 能互相合作。五个设计原则A2A 的设计遵循五个核心理念用大白话说互操作性不管你是哪个厂商的 Agent用什么语言写的都能聊。就像不管你是中国移动还是中国联通打电话都能接通。协作性复杂任务可以拆分给别人。你做你擅长的我做我擅长的合在一起就行。可发现性Agent 能动态发现「谁能帮我」。不需要提前硬编码所有合作伙伴的地址。异步优先任务可能要跑几小时甚至几天不能干等着。A2A 原生支持长时间任务和实时状态更新。安全黑盒你不需要知道我内部怎么实现的我也不需要暴露我的专有数据和工具。大家只通过标准化接口沟通。一个类比把 A2A 想象成商务会议的礼仪交换名片Agent Card智能体名片——告诉你我是谁、我能干什么分配任务Task任务——我请你帮忙做一件事汇报进度Message消息——实时告诉你任务进展交付成果Artifact工件——任务完成后的最终结果不管你是哪个公司的人只要大家都遵守这套礼仪会议就能顺利进行。Agent 怎么发现其他 Agent好A2A 让 Agent 之间能沟通。但第一个问题是库存 Agent 怎么知道采购 Agent 的存在怎么知道它能干什么答案是Agent Card智能体名片。Agent Card 是什么每个 A2A 兼容的 Agent 都会发布一份 JSON 文档相当于它的「自我介绍」。里面包含我叫什么name我是干什么的description我有什么技能skills怎么联系我endpoint我支持什么样的交互方式文本、文件等{name:采购Agent,description:负责商品采购和供应商管理,skills:[{name:create_order,description:向供应商下单采购},{name:query_supplier,description:查询供应商信息和报价}],endpoint:https://purchase-agent.example.com/a2a}三种发现方式Agent 怎么拿到其他 Agent 的名片有三种方式1. 知名 URI推荐这是最标准的方式。每个 Agent 把自己的名片放在一个固定的路径上https://{agent域名}/.well-known/agent-card.json就像公司官网的/robots.txt一样约定俗成。库存 Agent 只要知道采购 Agent 的域名发一个 HTTP GET 请求就能拿到名片。2. 集中式注册中心类似企业内部的「黄页」。Agent 们把自己的名片注册到一个中央目录里。其他 Agent 可以去这个目录搜索按技能、标签等条件筛选。适合企业内部或特定生态系统的 Agent 管理。3. 直接配置开发阶段最简单的方式硬编码目标 Agent 的地址。跳过发现过程直接通信。发现流程库存 Agent | | 1. GET https://purchase-agent.example.com/.well-known/agent-card.json | v 采购 Agent 返回 Agent Card | | 2. 库存 Agent 解析名片确认采购 Agent 有 create_order 技能 | | 3. 开始通信 v这个设计的巧妙之处在于库存 Agent 不需要提前知道采购 Agent 的具体实现只需要知道它的域名剩下的靠名片来了解。发现之后怎么通信拿到名片了知道对方能干什么了。然后呢怎么发消息发什么格式基础协议A2A 的所有通信都基于HTTP(S)传输层JSON-RPC 2.0消息格式。所有请求和响应都是 JSON-RPC 格式选择 JSON-RPC 而不是 REST API是因为 JSON-RPC 天然支持「方法调用」的语义——你可以告诉对方「请执行这个方法」而不只是「操作这个资源」。三个核心概念Task任务任务是 A2A 通信的核心单元。库存 Agent 给采购 Agent 发的不是一个「消息」而是一个「任务」。任务有生命周期submitted → working → completed | → input-required → (等待客户端补充信息) → working | → failed | → canceledsubmitted任务刚提交working采购 Agent 正在处理input-required需要库存 Agent 补充信息比如「你要采购的具体数量是多少」completed任务完成failed任务失败canceled任务被取消Message消息客户端和服务端之间的通信单元。一条消息可以包含多个 PartTextPart文本内容FilePart文件可以是内联数据或 URL比如库存 Agent 发的消息可能包含一段文字说明 一份库存报告文件。Artifact工件任务完成后生成的最终结果。比如采购 Agent 完成下单后返回一个订单确认信息。工件是不可变的——一旦生成就不会改变。两种通信模式同步请求-响应适合简单、快速的任务。库存 Agent 发送请求等待采购 Agent 返回结果。库存 Agent ---{tasks/send}--- 采购 Agent 库存 Agent ---{任务结果}--- 采购 Agent异步流式传输SSE这是 A2A 的核心能力之一专为耗时较长的任务设计。基于 SSEServer-Sent Events实现。库存 Agent ---{tasks/send 订阅}--- 采购 Agent 库存 Agent ---{状态更新: 正在联系供应商}--- 采购 Agent 库存 Agent ---{状态更新: 已下单等待确认}--- 采购 Agent 库存 Agent ---{状态更新: 订单确认完成}--- 采购 Agent 库存 Agent ---{final: true, 工件: 订单详情}--- 采购 Agent (连接关闭)整个过程中采购 Agent 持续推送状态更新库存 Agent 能实时知道任务进展。当任务完成或失败时服务器发送一个带有final: true标志的事件然后关闭连接。如果连接意外中断怎么办客户端可以重新订阅恢复对正在运行任务的监听。出问题了怎么办跨 Agent 通信中间环节很多出问题是常态。A2A 协议设计了完善的错误处理机制。标准错误类型A2A 定义了一套标准错误都继承自A2AError错误类型什么时候出现AgentCardResolutionError获取或解析 Agent Card 失败TaskNotFoundError操作一个不存在的任务InvalidRequestError请求格式不对或参数无效InternalErrorAgent 服务器内部出错这些错误会映射到标准的 HTTP 状态码方便客户端统一处理。重试与熔断SDK 通常内置了重试和熔断逻辑智能重试遇到临时错误比如网络超时自动重试遇到认证错误触发重新认证熔断如果某个 Agent 连续失败多次暂时停止向它发请求避免雪崩任务状态监控通过异步模式下的状态更新事件客户端可以实时监控任务状态。如果任务进入failed状态客户端可以查看失败原因决定是否重试通知用户或启动备选方案一句话A2A 的错误处理不是「出了问题就报错」而是「出了问题知道怎么应对」。A2A 和 MCP 是什么关系上一篇讲了 MCP这篇讲 A2A。很多人会问这俩是竞争关系吗不是。它们解决的是不同层面的问题而且可以组合使用。对比维度A2AMCP核心目的Agent 之间通信Agent 调用工具和数据交互对象智能体 ↔ 智能体智能体 ↔ 工具/数据类比不同部门的同事开会给同事配电脑和数据库协议基础HTTP JSON-RPCHTTP JSON-RPC状态管理有状态Task 生命周期无状态单次调用发起方另一个 AgentAgent 自己一句话MCP 让 Agent 能用工具A2A 让 Agent 能找帮手。一个完整的例子回到开头的库存 采购场景看看 MCP 和 A2A 怎么配合库存 Agent | | 1. 通过 MCP 查询数据库工具调用 | - 发现商品 X 库存只剩 10 件 | | 2. 通过 A2A 发送任务给采购 AgentAgent 间通信 | - 请为商品 X 下单补货 500 件 | v 采购 Agent | | 3. 通过 MCP 查询供应商 API工具调用 | - 获取供应商报价和交货时间 | | 4. 通过 MCP 创建采购订单工具调用 | - 订单创建成功 | | 5. 通过 A2A 返回结果给库存 AgentAgent 间通信 | - 订单已创建预计 3 天到货 | v 库存 Agent 收到结果更新库存预期整个流程中MCP 负责「Agent 和工具之间的交互」A2A 负责「Agent 和 Agent 之间的协作」。两者各司其职缺一不可。应用场景理解了 A2A 的机制什么时候该用它适合用 A2A 的场景多 Agent 协作最典型的场景。比如库存 Agent 采购 Agent自动补货客服 Agent 工单 Agent 知识库 Agent客户问题自动流转面试 Agent 评分 Agent 追问 AgentAI 面试系统跨组织协作你的 Agent 需要和合作伙伴的 Agent 配合。比如你的库存 Agent 需要调用供应商的采购 Agent双方用 A2A 协议通信不需要暴露各自的内部实现。复杂任务分解一个大任务可以拆成多个小任务分发给不同的专业 Agent。比如「帮我做一份市场分析报告」可以拆成数据采集 Agent、数据分析 Agent、报告生成 Agent。不适合用 A2A 的场景单 Agent 任务一个 Agent 就能搞定的事不需要 A2AAgent 调工具用 MCP 就够了不需要 A2A 的复杂性同进程内的简单调用直接函数调用更简单没必要走网络协议一句话当你需要「一个 Agent 请另一个 Agent 帮忙」时就该用 A2A。总结回顾一下我们走过的路起点一个 Agent 搞不定的事——库存 Agent 能发现缺货但不能下单问题为什么不能直接函数调用——不同语言、不同部署、不同组织解法A2A 协议——一个跨 Agent 的通用通信标准发现Agent Card智能体名片——告诉你我是谁、我能干什么通信HTTP JSON-RPC SSE——同步和异步两种模式容错标准错误类型 重试熔断——出了问题知道怎么应对定位A2A 和 MCP 互补——MCP 管工具A2A 管 Agent 间通信A2A 的核心价值让 AI Agent 从「单兵作战」变成「团队协作」。它不是一个 Agent 框架而是一个通信协议。你不需要用特定的语言或框架来实现 Agent只需要遵守 A2A 协议你的 Agent 就能和其他任何 A2A 兼容的 Agent 合作。目前 A2A 已经发布了 1.0 正式版本有超过 50 家技术伙伴支持包括 Google、Atlassian、Salesforce、SAP、LangChain 等。官方资料在 a2a-protocol.org。下一篇可以聊聊在一个实际项目中怎么同时用 MCP 和 A2A 搭建一个多 Agent 协作系统。
【从零理解 A2A：当一个 Agent 需要另一个 Agent 帮忙
发布时间：2026/6/26 3:28:09
从零理解 A2A当一个 Agent 需要另一个 Agent 帮忙MCP 解决了 Agent 和工具之间的问题。但 Agent 和 Agent 之间呢目录一个 Agent 搞不定的事为什么不能直接调用A2A 是什么Agent 怎么发现其他 Agent发现之后怎么通信出问题了怎么办A2A 和 MCP 是什么关系应用场景总结一个 Agent 搞不定的事假设你在做一个电商系统搭了两个 AI Agent库存 Agent监控库存水平发现哪些商品快卖完了采购 Agent负责联系供应商下单补货库存 Agent 发现某商品只剩 10 件需要补货。但它不能自己下单——那是采购 Agent 的职责。问题来了库存 Agent 怎么告诉采购 Agent「帮我订 500 件商品 X」你可能会说这不就是一个函数调用的事吗没那么简单。上一篇我们讲了 MCPModel Context Protocol解决了 Agent 和工具之间的问题——让 AI 能查数据库、调 API、读文件。但 MCP 的视角是「Agent ↔ 工具」是一个 Agent 使用外部资源。A2A 要解决的是另一个问题Agent ↔ Agent两个独立的 AI 智能体之间怎么沟通、协作、分配任务。一句话区分MCP 是给 Agent 配工具A2A 是让 Agent 之间能开会协作。为什么不能直接调用我最初的想法是两个 Agent 都是程序为什么不能直接函数调用// 库存 Agent 直接调用采购 Agent 的方法purchaseAgent.createOrder(商品X,500);如果两个 Agent 在同一个项目里、同一个进程里确实可以这么做。但现实世界往往是这样的库存 Agent 是 Python 写的采购 Agent 是 Java 写的库存 Agent 部署在北京的服务器采购 Agent 部署在上海库存 Agent 是你公司的采购 Agent 是合作伙伴提供的甚至你都不知道采购 Agent 内部是怎么实现的你只知道它能下单直接函数调用的前提是同语言、同进程、同部署环境。现实世界几乎不满足这些条件。那怎么办你需要一个跨语言、跨网络、跨组织的通用协议。就像人与人之间用中文或英文沟通一样Agent 之间也需要一种「通用语言」。这就是 A2AAgent-to-Agent协议要解决的核心问题互操作性。不管你是 Python 还是 Java不管你部署在哪里只要大家都说 A2A 这种「语言」就能互相沟通。A2A 是什么A2AAgent-to-Agent协议是一个由 Google 发起、现由 Linux 基金会托管的开放标准。它的目标很明确让不同 AI Agent 能相互发现、通信、协作共同完成复杂任务。你可以把它理解为 AI 智能体世界的「互联网协议」。就像 HTTP 让不同的网站能互相链接一样A2A 让不同的 Agent 能互相合作。五个设计原则A2A 的设计遵循五个核心理念用大白话说互操作性不管你是哪个厂商的 Agent用什么语言写的都能聊。就像不管你是中国移动还是中国联通打电话都能接通。协作性复杂任务可以拆分给别人。你做你擅长的我做我擅长的合在一起就行。可发现性Agent 能动态发现「谁能帮我」。不需要提前硬编码所有合作伙伴的地址。异步优先任务可能要跑几小时甚至几天不能干等着。A2A 原生支持长时间任务和实时状态更新。安全黑盒你不需要知道我内部怎么实现的我也不需要暴露我的专有数据和工具。大家只通过标准化接口沟通。一个类比把 A2A 想象成商务会议的礼仪交换名片Agent Card智能体名片——告诉你我是谁、我能干什么分配任务Task任务——我请你帮忙做一件事汇报进度Message消息——实时告诉你任务进展交付成果Artifact工件——任务完成后的最终结果不管你是哪个公司的人只要大家都遵守这套礼仪会议就能顺利进行。Agent 怎么发现其他 Agent好A2A 让 Agent 之间能沟通。但第一个问题是库存 Agent 怎么知道采购 Agent 的存在怎么知道它能干什么答案是Agent Card智能体名片。Agent Card 是什么每个 A2A 兼容的 Agent 都会发布一份 JSON 文档相当于它的「自我介绍」。里面包含我叫什么name我是干什么的description我有什么技能skills怎么联系我endpoint我支持什么样的交互方式文本、文件等{name:采购Agent,description:负责商品采购和供应商管理,skills:[{name:create_order,description:向供应商下单采购},{name:query_supplier,description:查询供应商信息和报价}],endpoint:https://purchase-agent.example.com/a2a}三种发现方式Agent 怎么拿到其他 Agent 的名片有三种方式1. 知名 URI推荐这是最标准的方式。每个 Agent 把自己的名片放在一个固定的路径上https://{agent域名}/.well-known/agent-card.json就像公司官网的/robots.txt一样约定俗成。库存 Agent 只要知道采购 Agent 的域名发一个 HTTP GET 请求就能拿到名片。2. 集中式注册中心类似企业内部的「黄页」。Agent 们把自己的名片注册到一个中央目录里。其他 Agent 可以去这个目录搜索按技能、标签等条件筛选。适合企业内部或特定生态系统的 Agent 管理。3. 直接配置开发阶段最简单的方式硬编码目标 Agent 的地址。跳过发现过程直接通信。发现流程库存 Agent | | 1. GET https://purchase-agent.example.com/.well-known/agent-card.json | v 采购 Agent 返回 Agent Card | | 2. 库存 Agent 解析名片确认采购 Agent 有 create_order 技能 | | 3. 开始通信 v这个设计的巧妙之处在于库存 Agent 不需要提前知道采购 Agent 的具体实现只需要知道它的域名剩下的靠名片来了解。发现之后怎么通信拿到名片了知道对方能干什么了。然后呢怎么发消息发什么格式基础协议A2A 的所有通信都基于HTTP(S)传输层JSON-RPC 2.0消息格式。所有请求和响应都是 JSON-RPC 格式选择 JSON-RPC 而不是 REST API是因为 JSON-RPC 天然支持「方法调用」的语义——你可以告诉对方「请执行这个方法」而不只是「操作这个资源」。三个核心概念Task任务任务是 A2A 通信的核心单元。库存 Agent 给采购 Agent 发的不是一个「消息」而是一个「任务」。任务有生命周期submitted → working → completed | → input-required → (等待客户端补充信息) → working | → failed | → canceledsubmitted任务刚提交working采购 Agent 正在处理input-required需要库存 Agent 补充信息比如「你要采购的具体数量是多少」completed任务完成failed任务失败canceled任务被取消Message消息客户端和服务端之间的通信单元。一条消息可以包含多个 PartTextPart文本内容FilePart文件可以是内联数据或 URL比如库存 Agent 发的消息可能包含一段文字说明 一份库存报告文件。Artifact工件任务完成后生成的最终结果。比如采购 Agent 完成下单后返回一个订单确认信息。工件是不可变的——一旦生成就不会改变。两种通信模式同步请求-响应适合简单、快速的任务。库存 Agent 发送请求等待采购 Agent 返回结果。库存 Agent ---{tasks/send}--- 采购 Agent 库存 Agent ---{任务结果}--- 采购 Agent异步流式传输SSE这是 A2A 的核心能力之一专为耗时较长的任务设计。基于 SSEServer-Sent Events实现。库存 Agent ---{tasks/send 订阅}--- 采购 Agent 库存 Agent ---{状态更新: 正在联系供应商}--- 采购 Agent 库存 Agent ---{状态更新: 已下单等待确认}--- 采购 Agent 库存 Agent ---{状态更新: 订单确认完成}--- 采购 Agent 库存 Agent ---{final: true, 工件: 订单详情}--- 采购 Agent (连接关闭)整个过程中采购 Agent 持续推送状态更新库存 Agent 能实时知道任务进展。当任务完成或失败时服务器发送一个带有final: true标志的事件然后关闭连接。如果连接意外中断怎么办客户端可以重新订阅恢复对正在运行任务的监听。出问题了怎么办跨 Agent 通信中间环节很多出问题是常态。A2A 协议设计了完善的错误处理机制。标准错误类型A2A 定义了一套标准错误都继承自A2AError错误类型什么时候出现AgentCardResolutionError获取或解析 Agent Card 失败TaskNotFoundError操作一个不存在的任务InvalidRequestError请求格式不对或参数无效InternalErrorAgent 服务器内部出错这些错误会映射到标准的 HTTP 状态码方便客户端统一处理。重试与熔断SDK 通常内置了重试和熔断逻辑智能重试遇到临时错误比如网络超时自动重试遇到认证错误触发重新认证熔断如果某个 Agent 连续失败多次暂时停止向它发请求避免雪崩任务状态监控通过异步模式下的状态更新事件客户端可以实时监控任务状态。如果任务进入failed状态客户端可以查看失败原因决定是否重试通知用户或启动备选方案一句话A2A 的错误处理不是「出了问题就报错」而是「出了问题知道怎么应对」。A2A 和 MCP 是什么关系上一篇讲了 MCP这篇讲 A2A。很多人会问这俩是竞争关系吗不是。它们解决的是不同层面的问题而且可以组合使用。对比维度A2AMCP核心目的Agent 之间通信Agent 调用工具和数据交互对象智能体 ↔ 智能体智能体 ↔ 工具/数据类比不同部门的同事开会给同事配电脑和数据库协议基础HTTP JSON-RPCHTTP JSON-RPC状态管理有状态Task 生命周期无状态单次调用发起方另一个 AgentAgent 自己一句话MCP 让 Agent 能用工具A2A 让 Agent 能找帮手。一个完整的例子回到开头的库存 采购场景看看 MCP 和 A2A 怎么配合库存 Agent | | 1. 通过 MCP 查询数据库工具调用 | - 发现商品 X 库存只剩 10 件 | | 2. 通过 A2A 发送任务给采购 AgentAgent 间通信 | - 请为商品 X 下单补货 500 件 | v 采购 Agent | | 3. 通过 MCP 查询供应商 API工具调用 | - 获取供应商报价和交货时间 | | 4. 通过 MCP 创建采购订单工具调用 | - 订单创建成功 | | 5. 通过 A2A 返回结果给库存 AgentAgent 间通信 | - 订单已创建预计 3 天到货 | v 库存 Agent 收到结果更新库存预期整个流程中MCP 负责「Agent 和工具之间的交互」A2A 负责「Agent 和 Agent 之间的协作」。两者各司其职缺一不可。应用场景理解了 A2A 的机制什么时候该用它适合用 A2A 的场景多 Agent 协作最典型的场景。比如库存 Agent 采购 Agent自动补货客服 Agent 工单 Agent 知识库 Agent客户问题自动流转面试 Agent 评分 Agent 追问 AgentAI 面试系统跨组织协作你的 Agent 需要和合作伙伴的 Agent 配合。比如你的库存 Agent 需要调用供应商的采购 Agent双方用 A2A 协议通信不需要暴露各自的内部实现。复杂任务分解一个大任务可以拆成多个小任务分发给不同的专业 Agent。比如「帮我做一份市场分析报告」可以拆成数据采集 Agent、数据分析 Agent、报告生成 Agent。不适合用 A2A 的场景单 Agent 任务一个 Agent 就能搞定的事不需要 A2AAgent 调工具用 MCP 就够了不需要 A2A 的复杂性同进程内的简单调用直接函数调用更简单没必要走网络协议一句话当你需要「一个 Agent 请另一个 Agent 帮忙」时就该用 A2A。总结回顾一下我们走过的路起点一个 Agent 搞不定的事——库存 Agent 能发现缺货但不能下单问题为什么不能直接函数调用——不同语言、不同部署、不同组织解法A2A 协议——一个跨 Agent 的通用通信标准发现Agent Card智能体名片——告诉你我是谁、我能干什么通信HTTP JSON-RPC SSE——同步和异步两种模式容错标准错误类型 重试熔断——出了问题知道怎么应对定位A2A 和 MCP 互补——MCP 管工具A2A 管 Agent 间通信A2A 的核心价值让 AI Agent 从「单兵作战」变成「团队协作」。它不是一个 Agent 框架而是一个通信协议。你不需要用特定的语言或框架来实现 Agent只需要遵守 A2A 协议你的 Agent 就能和其他任何 A2A 兼容的 Agent 合作。目前 A2A 已经发布了 1.0 正式版本有超过 50 家技术伙伴支持包括 Google、Atlassian、Salesforce、SAP、LangChain 等。官方资料在 a2a-protocol.org。下一篇可以聊聊在一个实际项目中怎么同时用 MCP 和 A2A 搭建一个多 Agent 协作系统。
