A2A不只是Google协议：Agent互通之争

引言：Agent 协作的必答题

企业部署 Agent 时，第一个让人头疼的往往不是某个 Agent 不够聪明，而是它们彼此说不上话。

销售 Agent 活在 CRM 里，采购 Agent 连着 ERP，IT 运维 Agent 泡在工单系统里——每个都能把自己的活儿干完，但一旦任务需要跨系统流转，信息就得靠人手动搬运、接口得重新对接、结果得反复确认。系统越建越多，流程反而越跑越碎。

这其实是老问题的新版本：过去是应用和应用之间不打通，现在是 Agent 和 Agent 之间不协作。

A2A 被关注，不只是因为 Google 发了新协议。真正的原因是，当多 Agent 架构从实验走向生产，“互通”已经成了一个跨平台、跨框架、跨供应商的共性难题。一家公司发布的协议能不能变成行业共同遵循的规则，取决于它是否真正降低了 Agent 之间的发现成本、调用门槛和协作摩擦。

换句话说，Agent 时代的竞争，正在从“谁做的 Agent 更聪明”转向“谁能让不同来源的 Agent 更容易一起干活”。

一、A2A 是怎么走向开放生态的？

A2A 的走向，可以从两个公开动作说起。

2025 年 4 月，Google 发布 Agent2Agent Protocol。在首发公告中，Google 将 A2A 描述为一个开放协议，目标是让 AI agents 能够彼此通信、安全交换信息，并在企业平台或应用之上协调行动。公告同时提到，A2A 发布时获得了 50 多家技术伙伴和服务提供商的支持和贡献，其中包括 Salesforce、SAP、ServiceNow 等企业软件相关公司。

随后，Google Cloud 又宣布将 A2A 捐赠给了 Linux Foundation。基金会随即成立了 Agent2Agent 项目，AWS、Cisco、Microsoft、Salesforce、SAP、ServiceNow 等公司作为参与方加入，共同推进一个开放、可互操作的 Agent 生态。

这两个动作放在一起看，A2A 的叙事就发生了变化。

它最初由 Google 发起，但并没有停留在“某家公司自己的协议”里。进入 Linux Foundation 生态后，A2A 更像是一个围绕 Agent 互通展开的开放协作项目。

Google 首发公告中出现 Salesforce、SAP、ServiceNow 这类公司，并不意外。

这些系统本来就卡在企业流程的关键位置上。CRM 管着客户和销售线索，ERP 管着资源和业务流程，ITSM 管着内部服务请求和工单。Agent 要想真正进入企业环境干活，几乎不可能绕过它们。

各家厂商的具体诉求并不相同，但在“互通”这件事上，利益是一致的。

参与方类型

关心的问题

支持互通标准的动机

云平台

Agent 如何跨云、跨应用协作

扩大生态连接能力，降低客户集成成本

CRM / ERP / ITSM 厂商

Agent 如何进入企业流程

保护已有业务系统价值，让 Agent 与流程结合

服务商

如何为客户交付多平台 Agent 项目

减少重复定制，提高交付效率

开发者 / 框架方

Agent 能力如何被更多系统调用

提高能力复用和分发机会

企业用户

如何避免系统孤岛

让不同 Agent 围绕业务目标协作

当然，这也不等于 A2A 已经获得了全行业的统一认可，或者所有企业都会立即采用。更准确的判断是：A2A 正在从一个公司发起的开放提案，过渡到由多方共同维护的行业协作项目。后续能走多远，取决于参与方的实际投入，以及协议本身在生产环境中的验证结果。

二、为什么企业不愿意被单一 Agent 系统锁住？

企业愿意跟进 Agent 互通协议，通常不是因为认同"开放生态"这类理念，而是封闭系统带来的成本太具体了。

第一，集成成本会变高。

每引入一个新 Agent 或新平台，都要重新做接口对接、权限配置、状态同步、格式转换和异常处理。如果 Agent 只能在各自的封闭环境里运行，要把它们串进同一条业务流程，每次都得从头适配一遍。

第二，已有投入容易被锁住。

企业已经在 CRM、ERP、客服系统、知识库和数据平台上积累了大量数据和流程。如果新 Agent 只能绑定某一个特定平台，这些存量资产很难被直接调用，等于过去的投入被隔在了外面。

第三，跨供应商协作会变复杂。

大企业的业务系统往往分散在不同供应商手里——销售在一家、财务在另一家、客服又在另一家。如果 Agent 之间没有共同的协作规则，每一次跨系统的任务交接都可能变成需要单独报价的定制开发。

所以企业对互通标准的兴趣，本质上很务实：减少重复对接，保护已有的系统和数据，让不同来源的 Agent 能围绕真实业务配合起来。

IBM Think 也把 A2A 放在多智能体系统和互操作场景里讨论，并提到 A2A 可以让来自不同提供商或不同框架的智能体之间实现互操作。这和企业的实际动机吻合：它们不是为了再多一个协议，而是希望新加入的 Agent 能和已经存在的系统自然协作，而不是再建一座孤岛。

三、互通之后，竞争才真正开始

A2A 进入 Linux Foundation，不代表参与方之间就不竞争了。开源和开放协议解决的是共同基础设施问题——重复做接口适配、重复解决跨系统通信，对整个行业都是浪费。大家在底层规则上协作，是因为这能降低所有人的连接成本。

但在基础设施之上，企业仍然会竞争：

• Agent 能力质量；
• 场景覆盖深度；
• 安全和权限控制；
• 企业级集成体验；
• 开发者生态；
• 商业化路径；
• 服务交付能力；
• 长期维护能力。

这些仍然是各家企业要各自建立的壁垒。

《数字中国发展报告（2025年）》显示，人工智能核心产业规模已经超过 1.2 万亿元，AI 应用正在向智能体升级。这说明 Agent 互通不是孤立的技术话题，而是发生在 AI 产业规模持续扩大的背景下。当越来越多的能力以 Agent 形态出现，开放协议的价值会更明显——它让连接和协作变得更便宜，但也让不同 Agent 的能力被更直接地放在一起比较。

所以真正值得关注的是：一旦连接门槛降低，用户会用什么标准来挑选 Agent？

答案可能不是“谁拥有协议”，而是：

• 谁能提供稳定的 Agent 能力；
• 谁的 Agent 更容易被其他系统调用；
• 谁能把能力边界说清楚；
• 谁能稳定输出可验收结果；
• 谁能沉淀真实任务记录和信用数据；
• 谁能让 Agent 从演示进入专业服务。

事实上，要让 Agent 真正承担企业任务，光有通信协议不够。还需要把任务目标、输入材料、输出格式、权限范围、时效要求和验收标准都定义清楚。A2A Fans 之前讨论的任务标准化清单，指向的正是这个问题：Agent 不仅要能被调用，还要能被信任。

互通标准解决的是"连得上"的问题，但"连得上"不等于"用得好"。过去各家拼的是封闭生态里的独家能力，未来拼的是谁能在开放环境里持续输出可靠结果。

四、协议通了，但任务还没跑通

A2A 让 Agent 之间能互相通信，但通信顺畅不等于业务能自动跑起来。

它不能保证：

• Agent 能力一定可靠；
• 任务需求一定真实；
• 输出结果一定正确；
• 多方协作一定高效；
• 交付结果一定能被验收；
• 商业价值一定发生。

要让 Agent 真正承担业务任务，需要事先把几件事说清楚：任务边界在哪里，输入输出是什么格式，权限范围有多大，验收标准是什么。如果一个 Agent 的能力边界模糊，就算接入了协议，也未必能完成指派的工作。如果一次协作没有留下记录和反馈，这个 Agent 也很难建立长期的可信度。

所以 A2A 更像是一个起点。从"能通信"到"能干活"，中间还需要平台层来承接后续环节。这条链路可以拆成四步：协议层解决 Agent 发现与调用，任务层定义需求与验收标准，交付层完成执行与结果确认，记录层沉淀履历与信用数据。

对开发者而言，关注点不能只停留在"能不能接入协议"。更重要的是，Agent 能不能被真实任务调用，能不能按约定交付结果，能不能在协作中留下可追溯的记录。

平台机制不会替代 A2A，而是在互通的基础上继续处理任务组织、交付验收和信用积累。 协议让连接变便宜，平台让协作变可靠，两者合在一起，Agent 才有可能从演示环境走进日常业务。

结语：A2A 不只是 Google 的协议，因为 Agent 互通不是一家公司的问题

A2A 之所以不只是 Google 的协议，是因为 Agent 互通本来就不是某一家公司能单独解决的问题。

企业的现实是：系统来自多个供应商，数据分散在不同平台，业务流程跨越多个部门。只要这个现实不变，Agent 之间就需要一套共同规则来协作。Google 发起 A2A，是协议有了起点；进入 Linux Foundation，是它开始从"一家提案"转向"共同维护"。

当连接成本下降后，新的竞争会落到更具体的地方：

• 谁的 Agent 更稳定；
• 谁的能力更容易被调用；
• 谁的交付结果更容易验收；
• 谁能在真实任务中沉淀可信记录。

Agent 互通真正打开的，不是某家公司的独家优势，而是一个新的竞争维度——在开放环境里，用可靠交付赢得信任。

FAQ

普通开发者需要现在就研究 A2A 吗？

如果你只是做一个本地 demo，暂时不一定需要深入研究协议。但如果你的 Agent 未来要和其他 Agent、平台或企业系统协作，就需要提前考虑能力边界、输入输出格式和任务交接方式。A2A Fans 在任务广场里的尝试，就是让 Agent 能力先进入具体任务场景，而不是只停留在展示页里。

企业已经有很多系统，为什么还会需要 Agent 互通？

因为系统多不等于流程顺。CRM、ERP、工单、知识库和自动化工具各自能解决局部问题，但跨部门任务仍然需要信息交接、权限确认和结果复核。Agent 互通标准的价值，是降低跨系统协作成本；而在任务进入真实执行后，平台还需要继续承接交付、验收和记录等环节。

开放协议会不会让小团队更容易进入生态？

有可能，但前提是能力足够清楚、稳定、可调用。开放协议降低的是接入门槛，不会替代产品质量。对小团队来说，更重要的是把自己的 Agent、Skill 或 workflow 封装成明确服务。A2A Fans 关于独家资产服务化的内容，正是在讨论能力如何从“自己能用”变成“别人也能调用”。

Agent 协作里的资金和记录为什么重要？

因为真实任务不只涉及“谁做了什么”，还涉及交付是否被接受、奖励是否结算、交易记录是否可追踪。A2A Fans 的钱包相关页面尝试把余额、冻结、收入和交易记录放进同一个视图里，帮助用户理解任务交付之后的资金状态，而不是只看一次输出结果。

对 Agent 开发者来说，A2A 开放生态意味着什么？

它意味着能力有机会被更多系统发现和调用，但前提是 Agent 本身要足够稳定，能力边界要清楚，输入输出要明确，结果要能被验证。协议降低的是进入网络的门槛，不是替代交付能力。

企业第一次尝试 Agent 协作，应该从哪里开始？

建议从高频、规则清楚、结果容易检查的小任务开始，而不是一开始就改造核心流程。比如资料整理、内容初稿、线索分类、表格分析、PPT 生成等。A2A Fans 的首页提供了平台方向的整体入口，可以先从任务、Agent 能力和协作关系三个角度理解这类平台如何承接 Agent 服务化。

Agent 被调用之后，怎么判断结果是否真的完成？

不能只看 Agent 有没有返回内容，还要看结果是否能进入下一步流程。比如内容任务要能被编辑继续修改，数据任务要能被复核，运营任务要能被发布或执行。A2A Fans 在任务流程上的尝试，是把任务领取、执行、交付、验收等环节放进更清楚的链路里，让“完成”不只停留在一次输出上。