谷歌 Agent2Agent 协议来了！但它不是另一个 MCP

最新推荐文章于 2025-04-25 15:24:01 发布

人工智能学家

最新推荐文章于 2025-04-25 15:24:01 发布

阅读量67

点赞数

文章标签：人工智能

原文链接：https://mp.weixin.qq.com/s?__biz=MzIwOTA1MDAyNA==&mid=2650032591&idx=2&sn=bdca655518c9727f3f83260ccafc8230&chksm=8edeec086d8460b6818a7ad3fd34f4b713c1d6dddfdb940f74276147179de8ad7c02d01b1dbc&scene=126&sessionid=0

版权

来源：探索AGI

嘿，大家好！这里是一个专注于前沿AI和智能体的频道~

4月9日，谷歌在 Cloud Next 大会上正式发布了名为 Agent2Agent (A2A) 的全新开放协议，实现不同 AI Agent 之间的通信与协作。

blog: https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
github: https://github.com/google/A2A

2025年，不同平台、不同供应商构建的 AI Agent 如雨后春笋般涌现，但它们之间缺乏统一的通信标准，形成了信息和能力的“孤岛”。谷歌此次联合 Salesforce、SAP、ServiceNow、Atlassian 等超过50家技术伙伴共同推出 A2A，正是为了应对这一挑战，尝试为 Agent 之间的互联互通建立标准。

所以这自然会引出一个问题：这个协议跟上个月炒作的 MCP 有何关联？它们是竞争关系还是互补关系？

AI Agent 的“巴别塔”困境

在深入 A2A 之前，有必要先理解它试图解决的问题背景。

现在 AI Agent 很火，能自动处理邮件、订票、分析数据，甚至写代码。企业也纷纷部署 Agent 来提升效率，比如客服 Agent、销售 Agent、供应链 Agent 等等。

但问题来了，不同公司、不同团队用不同的框架（像 LangGraph、Crew.ai）和平台（Salesforce、SAP）构建 Agent，它们之间没法直接交流和协作。就像一群说着不同语言的人想一起建个塔（巴别塔），结果可想而知——效率低下，很多潜力无法发挥。

要完成一个稍微复杂点的任务，比如说自动化招聘流程，可能需要 HR Agent 发布职位、筛选简历 Agent 初筛、面试安排 Agent 协调时间、背景调查 Agent 核实信息……如果这些 Agent 不能顺畅沟通、传递信息、协调任务，整个流程就会卡壳，或者需要大量人工介入。

这就是 A2A 协议想要解决的核心痛点：为不同来源、不同技术的 AI Agent 提供一个通用的“语言”和“协作规范”。

谷歌 A2A 协议详解

A2A 协议被设计成一个开放、中立的标准（基于 Apache 2.0 许可），目标就是实现 AI Agent 之间安全、高效的直接通信和协作。谷歌强调，它基于几个关键原则：

那么，更简单来说，A2A 是如何让 Agent 协作起来的呢？它有几个核心概念：

能力发现 (Capability Discovery) - Agent Card:你可以把 Agent Card 想象成每个 Agent 的“数字名片”或“能力说明书”。它是一个公开的 JSON 文件（通常放在 /.well-known/agent.json），里面写清楚了这个 Agent 能做什么（技能）、怎么联系它（端点 URL）、需要什么身份验证等等。当一个 Agent (称之为 Client Agent) 需要找其他 Agent 帮忙时，它就可以通过查看这些 Agent Card 来找到合适的“队友”(Remote Agent)，了解对方的能力和沟通方式。这就像一个自动化的“婚介系统”，让 Agent 能够动态地发现和利用生态中其他 Agent 的能力。
任务管理 (Task Management):Agent 之间的协作是围绕“任务”进行的。A2A 定义了一个结构化的任务模型和清晰的生命周期状态，比如 submitted (已提交), working (处理中), input-required (需要输入), completed (已完成), failed (失败), canceled (已取消)。这就像一个项目管理系统，让发起任务的 Client Agent 和执行任务的 Remote Agent 能够清晰地追踪任务进展，知道当前进行到哪一步了。对于需要多个步骤、跨越较长时间的复杂业务流程（比如前面提到的招聘），这种状态管理就变得非常的中央了。任务的输出结果被称为“工件 (artifact)”。
安全协作 (Secure Collaboration):它支持标准的认证授权机制，并且 Agent Card 会明确指定访问服务所需的认证方法。而且，协议设计上只共享完成任务所必需的输入和输出（工件），而不会暴露 Agent 内部的思考过程或记忆状态，保护了各自的“秘密”和敏感数据。
用户体验协商 (User Experience Negotiation):Agent 输出的内容 (比如图片、表单、视频) 会包含具体的内容类型。Client Agent 和 Remote Agent 可以协商内容的呈现格式，甚至可以协商客户端的 UI 能力（比如是否支持 iframe 或交互式表单），确保最终用户能获得一致且有效的体验。

Client Agent 和 Remote Agent 通过 A2A 协议进行交互的基本流程：简单来说，就是 Client Agent 通过 Agent Card 发现 Remote Agent，然后创建一个 Task 发给 Remote Agent，两者通过定义好的消息格式进行通信、交换工件、同步状态，直到任务完成或出现其他状态。

A2A vs MCP：互补而非竞争

好了，现在回到大家关心的问题：谷歌的 A2A 和 Anthropic 的 MCP 是什么关系？

谷歌官方的说法非常明确：A2A 是对 MCP 的补充 (complementary)。

这两者解决的问题层面不同：

MCP (模型上下文协议): 主要关注的是 单个 AI 模型 (或 Agent) 如何安全、标准地连接和交互外部的工具、数据源和服务。它像是一个“通用遥控器”或“USB-C 接口”，让 AI 模型能够方便地调用 API、访问数据库、读取文件、执行代码片段等，从而获取完成任务所需的上下文信息和能力。
A2A (Agent2Agent 协议): 主要关注的是 不同 AI Agent 之间如何进行通信、协调和协作。它解决的是多个 Agent 如何作为一个团队一起工作的问题。

❝
如果说 MCP 是给 Agent 提供了使用工具的“扳手” (wrench)，那么 A2A 就是“工程师之间的对话” (conversation between mechanics)，让多个 Agent 能像一个诊断问题的技师团队一样沟通协作。

一个例子简单总结一下。

A2A 和 MCP 并不冲突，反而可以很好地结合使用。想象一个复杂的场景：

用户的个人助理 Agent (Client Agent) 接到指令要完成一份市场研究报告。

但是呢，这个助理 Agent 能力有限，于是它通过 A2A 协议，找到了一个专门负责信息搜集的 Research Agent (Remote Agent)，并将任务委派给它。

这个 Research Agent 需要访问最新的行业数据库、调用网页爬虫工具、分析财报数据。这时，它就可以利用 MCP 协议，安全、高效地连接到这些外部数据库和工具来获取所需信息。

然后，Research Agent 完成研究后，再次通过 A2A 协议，将整理好的报告（工件）返回给用户的个人助理 Agent。

在这个例子里，MCP 增强了单个 Agent (Research Agent) 的能力，而 A2A 则实现了不同 Agent (个人助理 Agent 和 Research Agent) 之间的协作。两者结合，才能高效完成复杂的任务。

最后

A2A 协议刚刚发布，还处于规范草案阶段，计划在今年晚些时候推出生产就绪版本。它的成功与否，最终取决于能否获得广泛的行业采纳和社区支持。但谷歌这次联合了这么多重量级合作伙伴，无疑为它的推广打下了坚实的基础。

A2A的推出，对AI Agent领域意味着，促进开放，打破孤岛，实现真正的跨平台协作。

阅读最新前沿科技趋势报告，请访问欧米伽研究所的“未来知识库”

https://wx.zsxq.com/group/454854145828

未来知识库是“欧米伽未来研究所”建立的在线知识库平台，收藏的资料范围包括人工智能、脑科学、互联网、超级智能，数智大脑、能源、军事、经济、人类风险等等领域的前沿进展与未来趋势。目前拥有超过8000篇重要资料。每周更新不少于100篇世界范围最新研究资料。欢迎扫描二维码或访问https://wx.zsxq.com/group/454854145828 进入。