夜雨聆风过去一年，很多人刚刚记住MCP：它让AI不只在对话框里回答问题，还能连接文件、数据库和业务工具。
现在，另一个缩写开始走到台前：A2A，Agent2Agent。
Axios在2026年8月17日报道，最初由Google创建的A2A协议正在进入Agentic AI Foundation。这个变化值得注意，不是因为AI行业又发明了一个新名词，而是因为竞争焦点正在移动：当一个Agent已经会调用工具，下一步就是多个来自不同系统、不同厂商的Agent，能不能听懂彼此、交接任务，并共同完成一条真实业务流程。
简单说，AI不只要“会做事”，还开始面对“怎么和别的AI一起做事”的问题。
一、这次变化，重要的不是又多了一个缩写
Google在2025年4月宣布A2A时，把它定位为开放协议：让不同厂商、不同框架构建的Agent，能够跨企业系统协作。Linux Foundation随后在2025年6月启动A2A项目，并称获得100多家技术公司的支持。
到了今天，任务提供的A2A项目当前信息显示，最新发布规范已到1.0.0。它关注的不只是消息能否传过去，还包括Agent如何被发现、如何协作、怎样处理长时间运行的任务，以及如何在不暴露内部记忆和工具的情况下对外提供能力。
如今A2A进一步进入基金会治理，释放的是一个更现实的信号：Agent互联不适合长期只由一家公司的产品路线决定。企业真正担心的，是今天接入一个Agent，明天换供应商、换框架或多接一个部门时，是否又要从头开发一套接口。中立治理无法保证标准胜出，却有机会降低参与者对单一厂商控制协议的顾虑。
这仍不等于A2A已经成为唯一标准，也不等于支持它的公司都已大规模部署。基金会、版本号和生态支持，说明的是标准化正在推进；真实采用效果，仍要看后续产品实现与企业运行结果。
二、MCP与A2A：一个管接工具，一个管Agent协作
理解A2A，最容易的方法，是先把它和MCP放在一张图里。
MCP解决的是：一个AI应用怎样连接外部工具和数据。
例如，一个客服Agent需要读取知识库、查询订单、更新工单。知识库、订单系统和工单系统都是它要使用的资源。MCP提供一种标准化连接思路，让AI应用不必为每个工具都重新发明一套接法。
A2A解决的是：一个Agent怎样与另一个独立Agent沟通和协作。
两种协议解决不同层次的连接问题，并非替代关系。
例如，客服Agent发现客户的问题涉及退款，它未必应该直接操作财务系统。更合理的方式可能是把任务交给退款Agent：说明目标、提供被允许共享的上下文、等待处理状态，再接收结果。退款Agent如何完成内部判断、用了哪些工具、保存了什么内部记忆，可以保持不透明；双方需要对齐的是任务与结果。
所以，MCP与A2A不是替代关系。Google Cloud在2025年12月也把两者描述为互补：MCP连接Agent与工具、数据，A2A连接Agent与Agent。
可以把它们想成一家公司的两类基础设施：MCP更像标准插座，让员工能使用设备；A2A更像跨部门的工单与交接规则，让不同团队知道任务是什么、做到哪一步、该把结果交给谁。
三、Agent互联，真正改变的是工作的交接方式
今天许多所谓“AI工作流”，本质上仍是一个大Agent包办全部环节：既要理解需求，又要查资料、调系统、做判断、写结果。演示时很顺，进入复杂企业环境后却容易碰到权限过大、上下文混乱、责任不清。
Agent互联提供了另一种拆法：让每个Agent只负责边界相对清楚的一段，再通过协议交接。
以采购流程为例，这不是某家公司的成功案例，而是一条常见业务流程的拆解。需求Agent可以整理部门提交的信息；供应商Agent负责获取被授权的供应商资料；合规Agent检查必填项和规则；采购Agent汇总状态，交由有权限的人审批。每个Agent可以属于不同系统，也可以采用不同技术实现。
它带来的变化，不是“多放几个机器人”，而是三件更具体的事。
第一，能力可以被发现。发起任务的一方需要知道，哪个Agent能做什么、接受什么输入、返回什么状态。
第二，任务可以被委派。复杂工作不必把所有数据塞给一个万能Agent，而是把必要信息交给合适的执行者。
第三，长任务可以有状态。订货、合规复核、退款等流程不一定几秒结束。协议需要支持等待、更新、失败和完成，而不是只返回一段即时文本。
这也解释了A2A规范为什么强调“opaque execution”：协作不要求一个Agent公开自己的内部记忆、提示词或全部工具。就像外包团队可以承诺交付结果，却不必把内部每一步操作都暴露给客户。对企业来说，这既关系知识产权，也关系最小化数据暴露。
四、有了标准，不等于有了可靠的自动协作
这里必须给热度踩一脚刹车。
协议能统一交流方式，却不能自动保证交流内容正确。两个Agent会“说同一种语言”，不代表它们理解一致，更不代表它们会稳定完成任务。
首先是身份。对面究竟是谁？它代表哪个系统或组织？身份不能确认，后面的权限就没有基础。
其次是权限。一个Agent可以知道某项能力存在，不等于它有权调用。跨Agent传递的上下文也应遵循最小必要原则，不能因为协作方便，就把完整客户资料或内部数据一路转发。
再次是可靠性。任务失败后是否重试，重复请求会不会造成重复扣款或重复下单，长任务卡住由谁终止，结果冲突时听谁的，都不是协议名称本身能替企业决定的。
最后是可观察与责任。企业需要知道任务经过哪些Agent、每一步用了什么权限、何时失败、谁批准了关键动作。否则，Agent越多，问题越容易在交接缝隙里消失。
因此，A2A更像修了一条标准道路，而不是交付了一支不会出错的自动驾驶车队。道路降低了互通成本；车辆是否可靠、交通规则是否清楚、事故由谁负责，仍需逐项建设。
五、你的团队真的需要A2A吗？先问五个问题
不是所有AI项目都需要多Agent。很多团队的问题，用一个Agent加几个工具就能更简单地解决。判断是否值得引入Agent互操作，可以先问五个问题。
一，任务是否真的跨越多个独立系统或责任主体？ 如果所有动作都在同一个应用、同一套权限里完成，一个Agent连接工具往往足够。
二，不同能力是否需要独立演进或替换？ 如果客服、合规、财务能力由不同团队或供应商维护，标准化交接的价值会更明显。
三，流程是否包含长时间等待和多次状态更新？ 如果任务不是一次问答，而要经历提交、补充、审批和完成，就需要认真设计状态与超时。
四，身份、权限和数据边界能否被明确表达？ 如果连“谁可以看什么、做什么”都说不清，多Agent只会放大风险。
五，企业是否具备追踪、暂停和人工接管能力？ 没有日志、告警、幂等控制和明确负责人时，先补运行底座，比先追协议更重要。
先判断协作复杂度，再决定是否引入Agent互操作。
如果前两问大多是否，先用单Agent和工具连接解决问题。如果前四问多为是，但第五问是否，也不该急着自动化。真正适合A2A的，不是“想显得更Agentic”的项目，而是已经存在清晰跨系统协作需求，同时愿意为治理和可靠性付出工程成本的流程。
最后
MCP让AI的手伸向工具和数据，A2A则尝试让不同Agent学会交接与协作。后者重要，不是因为每家公司都应该立刻搭建“Agent军团”，而是因为企业AI正在从单点助手走向跨系统流程，连接问题迟早会从工具层上升到协作层。
但标准最有价值的地方，从来不是制造想象，而是减少重复连接，让替换与组合变得可能。
对普通团队，最实用的行动不是马上部署A2A，而是选一条真实流程，画出参与者、系统、权限、等待状态、验收标准和人工接管点。画完以后，如果你发现多个独立Agent确实必须协同，A2A才从一个热门缩写，变成值得认真评估的基础设施。
资料来源
Axios，2026年8月17日，关于A2A进入Agentic AI Foundation的报道（依据任务提供的已核验事实）。 Google Developers Blog，2025年4月9日，A2A开放协议发布说明。 Linux Foundation，2025年6月23日，A2A项目启动公告。 a2aproject/A2A specification，任务提供的当前版本信息（1.0.0）。 Google Cloud，2025年12月15日，MCP与A2A互补关系说明。
编辑说明
本文由编辑基于以上来源完成事实梳理与观点写作；AI参与资料结构化、文字校对和视觉方案规划。文中的业务流程用于解释概念，不代表特定企业案例。