Google发起的Agent2Agent协议（A2A）正式加入Linux基金会旗下的Agentic AI Foundation，成为与MCP、AGENTS.md、goose和agentgateway并列的开放项目。A2A解决的不是模型如何调用数据库或搜索工具，而是来自不同公司、使用不同框架的AI Agent如何发现彼此、验证身份、委托任务并交换结果。该协议目前获得超过150家机构支持，已经进入华为HarmonyOS、腾讯微信以及Google Cloud、微软Azure和AWS的Agent平台。它与MCP进入同一治理体系，意味着AI产业开始尝试建立一套类似互联网协议栈的公共基础设施：MCP负责Agent与工具之间的连接，A2A负责Agent与Agent之间的协作，agentgateway则负责流量、策略和可观察性。不过，协议统一只能降低集成成本，并不会自动解决权限滥用、恶意Agent、身份冒充和跨系统责任归属问题。
文章作者、来源：Agentic AI Foundation
Agent已经能工作，却还不会跨平台交接工作
当前AI Agent生态面临的一个核心问题，不是缺少模型或工具，而是不同系统之间无法自然协作。
一家企业可能使用Google的Agent Development Kit开发客服Agent，同时在微软平台运行内部办公Agent，再接入Salesforce、SAP或ServiceNow提供的专业Agent。这些系统即使都具备推理、工具调用和长任务能力，也未必知道怎样发现彼此、怎样描述自身能力，以及怎样把一个尚未完成的任务安全地交给另一个系统。
过去的解决办法通常是为每一对系统编写专用接口。如果一个物流Agent需要分别连接采购、金融、仓储和客户服务Agent，工程团队就要为每一种组合设计数据格式、身份验证、状态同步和错误处理。增加一个供应商，往往意味着重新进行一轮集成。
AAIF的发布文章认为，多Agent系统真正昂贵的部分逐渐不再是Agent本身，而是Agent之间的连接。A2A就是为降低这部分成本而设计的。
每个Agent先公开一张“能力名片”
A2A的起点是Agent Card，可以理解为Agent面向其他系统发布的一张结构化数字名片。
这份JSON文件会说明Agent是谁、可以完成哪些任务、服务入口在哪里、支持什么通信方式，以及调用它需要满足哪些身份验证条件。其他Agent读取名片后，可以判断它是否适合当前任务，再决定是否建立连接。
例如，一名用户要求自己的个人助理安排商务旅行。主Agent可以先发现航班Agent、酒店Agent和行程管理Agent，比较它们公开的能力，再把不同子任务分别委托出去。整个过程不要求这些Agent使用同一家公司的模型，也不要求它们基于相同的开发框架。
A2A不会要求远程Agent暴露内部提示词、记忆、模型或工具。对调用方来说，对面的Agent可以保持为一个“黑箱”：调用方只需知道它能做什么、怎样与它通信，以及怎样取得任务结果。
这对商业系统十分重要。航空公司可以开放订票Agent，却不必公开内部定价模型；银行可以提供合规核查Agent，也不必暴露风险规则和客户数据库。
交接的不是一次API调用，而是一项持续任务
A2A与普通接口的重要区别，是它把工作组织成具有状态和生命周期的Task。
简单请求可以立即返回一条Message；复杂任务则可以创建唯一任务编号，随后持续更新状态，并最终交付一个或多个Artifact。Artifact可以是一份文档、一张图片、一个文件或结构化数据，而不仅是一段聊天文本。
按照A2A核心概念文档，协议同时支持普通请求与响应、服务器发送事件流，以及面向长时间任务的异步推送通知。调用方可以轮询任务状态，也可以保持流式连接，或提供Webhook等待远程Agent主动通知。
这使A2A更适合持续数分钟、数小时甚至更久的Agent工作。例如，供应链Agent可以把“寻找替代供应商并评估交付风险”委托给采购Agent；采购Agent在工作期间不断返回进度，最后提交包含候选名单、报价和风险数据的正式结果。
A2A 1.0于2026年3月发布，加入多协议绑定、版本协商、多租户支持以及带数字签名的Agent Card。签名机制可以帮助调用方验证能力名片是否来自声称的发布者，减少Agent身份被冒充或信息被篡改的风险。
A2A和MCP并不是竞争关系
A2A最容易引发的误解，是它是否要取代已经广泛采用的Model Context Protocol。实际上，两者处理的是不同层级的问题。
MCP主要负责Agent与工具、数据和服务之间的连接。模型可以通过MCP查询数据库、调用计算器、读取文件或操作外部API。这些工具一般具有明确的输入与输出，执行一次相对具体的功能。
A2A面对的则是更加自主的协作对象。另一个Agent可能需要先理解目标、制订计划、调用多个工具、与用户来回沟通，再经过较长时间才能完成任务。因此，A2A不只定义一次调用，还需要处理能力发现、任务状态、上下文延续、结果交付和异步通知。
两者可以同时出现在一套工作流中：主Agent通过A2A把汽车故障诊断任务交给维修Agent；维修Agent再通过MCP连接车辆扫描仪、维修手册数据库和升降平台；如果需要购买零件，维修Agent又可以通过A2A与供应商Agent协商库存和订单。
简化来说，MCP解决“Agent怎样使用工具”，A2A解决“Agent怎样与另一个Agent共同工作”。
开放Agent技术栈开始形成
A2A加入AAIF后，与多个Agent基础设施项目进入同一套中立治理体系。
AGENTS.md负责让代码项目向编程Agent说明规则、约定和操作要求；goose提供Agent规划、推理和执行任务的运行环境；MCP负责连接工具和数据；agentgateway位于Agent系统与基础设施之间，处理路由、策略控制和可观察性；A2A则补上不同Agent之间的发现、通信和任务交接。
这套分层方式很像互联网和云原生生态的发展路径。开发者不必让一家公司同时控制模型、Agent框架、工具接口、通信协议和流量网关，而可以在每一层选择不同实现。
A2A最初由Google在2025年4月推出，随后捐赠给Linux基金会。AWS、Cisco、微软、Salesforce、SAP和ServiceNow等公司参与了项目建设。2025年8月，IBM原有的Agent Communication Protocol并入A2A，减少了行业出现多个不兼容Agent通信标准的可能性。
此次变化并非A2A第一次脱离Google控制，而是把此前位于Linux基金会广泛项目组合中的A2A，进一步迁入专门管理Agent基础设施的AAIF。Axios称，AAIF从2025年12月成立时不足40名成员，已经扩大到超过250名成员。
华为、微信和三大云平台已经开始部署
A2A并非只存在于规范文件中。
AAIF称，华为已经把A2A作为HarmonyOS中Celia系统级助手与应用内Agent之间的通信协议。Celia可以把长时间任务交给应用Agent，通过Agent控制应用界面，也可以向应用请求上下文推荐。
微信则是首批通过A2A接入华为及其他Android手机厂商助手的主要应用之一。用户可以让系统助手发起微信消息、语音通话或视频通话，相关流程通过A2A实施双重授权。
在云端，Google Cloud的ADK、Agent Engine、Cloud Run和GKE已经支持开发或部署A2A Agent；微软Azure AI Foundry允许Agent公开A2A端点并发现外部Agent；AWS Bedrock AgentCore也能够托管和运行A2A服务器。
Google Cloud与PayPal还在把A2A用于Agent商业交易。商品发现、价格查询和履约可以由不同Agent协作完成，支付授权则交给Agent Payments Protocol处理。
这些案例和部署范围来自AAIF及参与公司的公开说明，尚不存在统一的第三方统计，无法判断各平台上的真实调用规模和活跃度。
统一协议不会自动带来可信协作
A2A解决的是互操作性，而不是所有安全与治理问题。
一个Agent拥有可验证的身份，不代表它的判断可靠；它公开某种能力，也不代表它一定能够正确完成任务。多个Agent跨组织协作后，权限、数据和责任链条还会变得更复杂：谁有权把用户数据交给外部Agent，远程Agent是否可以继续转委托，任务失败由谁承担责任，以及付款、删除文件等不可逆操作应该在哪一层再次取得用户确认，都需要额外机制。
Agent Card的数字签名主要证明“这张名片由谁发布”，无法证明名片中的能力描述真实，也无法阻止合法Agent在执行过程中出现错误。协议可以使用OAuth、API密钥和标准Web安全机制，但具体授权范围仍由部署者设计。
开放标准甚至可能扩大攻击面。过去只在单个平台内部运行的Agent一旦能够发现并调用外部Agent，恶意能力描述、提示注入、身份混淆和供应链攻击也可能跨越系统传播。因此，A2A进入生产环境后，Agent身份、最小权限、审计日志、任务撤销和结果验证的重要性都会上升。
真正的变化，是Agent开始从产品变成网络
过去的大模型竞争主要发生在单个聊天窗口里，用户直接选择ChatGPT、Claude或Gemini。Agent时代的系统则可能由许多不同来源的模型与服务组成：一个Agent理解用户目标，多个专业Agent分别执行子任务，再由工具层读取数据和完成操作。
如果A2A与MCP等协议得到广泛采用，企业更换模型或Agent供应商的成本可能下降。系统不必把全部能力绑定在同一家公司，可以根据准确率、价格、速度、隐私和地区合规要求选择不同组件。
这也是中立治理真正重要的原因。A2A的150多家支持机构中包含直接竞争者。如果协议仍由某一家云厂商单独控制，其他公司就必须承担其路线变化、产品绑定和版本周期带来的风险；进入Linux基金会旗下的AAIF后，协议的规格、SDK和路线图可以由更广泛的社区共同维护。
截至本次检索，X没有稳定展示AAIF原帖的完整浏览量、点赞、转发和回复数据，因此具体热度指标无法可靠核实。此次发布同时得到Axios、Techzine等媒体跟进，并在云计算、Agent开发和开放标准社区形成讨论。本次选择主要依据官方文章的信息密度、A2A超过150家机构的产业支持、已经披露的生产部署，以及它对MCP和开放Agent技术栈未来格局的影响。