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

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

嘿，大家好！这里是一个专注于前沿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 有何关联？它们是竞争关系还是互补关系？

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

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

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

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

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

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 或交互式表单），确保最终用户能获得一致且有效的体验。