大厂推出一个新协议，很少只是为了技术利他。更多时候，它是大厂划领地、立规矩、顺便把自己的开发习惯强加给行业的一种方式。选择一个协议，从来不只是引入几行接口代码，而是把你整个系统的架构交给了对方的设计哲学。2025 年 Google 推出 Agent-to-Agent（A2A）协议并把它捐给 Linux 基金会时，背后也是同样的逻辑。
在 AI 便宜到几分钱推理一次的今天，如果两个系统想通个信，开发者完全可以自己随手写个简单的 JSON 接口。那为什么像 Salesforce、SAP、ServiceNow 这些企业大厂还要围坐在一起，搞一个专门的 A2A 协议？这背后到底解决的是真问题，还是又一场炒作？
在真实的企业环境里，传统接口吃不下、但又极其折腾人的场景其实非常集中。这个场景不是你平时在单机上写代码或调 API，而是跨公司、跨平台的远端协作。在企业的真实业务里，这类应用有着非常明确的边界。
拿企业客服来说，客户在 Salesforce 的前端页面提交了一个复杂的争议退款请求。Salesforce 自身的 AI 识别出意图后，光查自家的 CRM 数据还不够，它必须找到 SAP 的 AI 查 ERP 里的财务扣款，同时还得叫 ServiceNow 的 AI 去翻翻过去的客服工单。这三个 AI 运行在完全不同的云端，由三家不同的巨头开发，互相谁也不信任谁的数据。如果只是取点数据，普通的 REST API 就能做到；但这里关键的要求是，SAP 和 ServiceNow 的 AI 必须在自己内部做独立的推理和逻辑评估。
在执行过程中，SAP 可能会因为风险规则超标，不得不暂停手头的工作，等待人工管理员审核；或者因为凭证过期，需要跨租户重新要求用户授权。这种需要长耗时运行、中途可能会暂停等待、还要跨系统把控权限的远端委派，才是这类需求真正生长的土壤。
泰森食品与大型分销商 Gordon Food Service 在供应链上的试点，呈现了另一个代表性的跨公司场景。泰森的 AI 销售 Agent 与 Gordon 的 AI 采购 Agent 之间，直接建立起了长期的对话机制。两家公司的 Agent 就像两个黑盒，泰森不需要向对方暴露自家的数据库结构或内部 Prompt，Gordon 也不需要开放自家的采购系统接口。双方的 Agent 在框架约束下，自动分享实时库存、协商补货计划、传递销售线索。远端协作场景的本质，不在于替代代码里的函数调用，而是为了在两个互不信任、架构完全不同的企业系统之间，搭建一条能够带状态、带权限管控的跨界通道。
既然这种跨界协作的需求真实存在，为什么不能直接用已有的 API 拼凑，而是非要搞出一套专门的标准化协议？要理清这个需求，不妨把 Anthropic 推出的 Model Context Protocol（MCP）放在一起看。两者的脾气秉性完全不同，恰好折射出两类完全不同的工程难题。
MCP 的切入点很直接，主要解决怎么让 AI 顺畅地去读本地文件、查 Postgres 数据库或者调 Slack。它诞生于 Anthropic 想改进 Claude Desktop 和 IDE 体验的需求。它非常轻，基于标准输入输出或者简单的 HTTP，目标就是让开发者在十分钟内，把工具接进 AI 的上下文里。
但当场景从给 AI 调本地工具变成让一个 AI 向另一个公司的 AI 委派任务时，传统的 API 和 MCP 就都力不从心了。在跨公司协作里，你无法假设远端 Agent 的技术栈，无法预知它需要处理多久，更无法用简单的同步请求拿回结果。远端 Agent 可能在推理三分钟后发现权限不足，需要暂时挂起任务，等待人工干预；也可能在生成结果的过程中，需要不断向发起方实时推送进度。
更残酷的现实来自于商业与市场规模的悬殊。钓鱼要去鱼多的地方，MCP 面对的是绝大多数普通的 AI 开发者——任何一个做 AI 应用的人，都需要让模型连数据库、读文件。这种刚需和低门槛，让 MCP 在 Cursor、VS Code 和开源社区里迅速形成了爆发式的生态红利。而跨 Agent 委派所面对的，是一个极度小众的企业远端 RPC 市场，只有当公司大到需要把 Salesforce、SAP、UiPath 这些巨头的 AI 串在一起跨公司干活时，这种专门的标准化协议才用得上。市场大小的悬殊，直接决定了这种协议在开发者里的热度天然远低于 MCP。
为了解决上述跨界协作里的长耗时、不信任与鉴权难题，Google
给出了极其鲜明的 Google 风格工程解法。Google 写 A2A
的思路很像写微服务，用 HTTP 传 JSON，把接口全做成标准 RPC
调用的形式。它要求把能力名片挂在指定的网址上（/.well-known/agent-card.json），用规范的签名校验。这套设计，全是为了满足大企业对
API 网关路由、防火墙穿越、OAuth2 授权和实时推流的工程死要求。
在任务调度上，Google 引入了一套明确的任务状态机，涵盖了从已提交、处理中，到挂起等待输入、挂起等待授权，最后到完成或失败的全生命周期。这种架构和 MCP 即调即返回的模式完全不同。MCP 像调一个本地函数，调完马上拿结果；而 A2A 必须考虑到网络另一端的 Agent 可能会干很久，随时需要暂停下来等你给新权限。在角色分工上，Google 的解法极其干脆，必须分清谁是下指令的主控，谁是只管干活的远端工具。
去年很多团队试多 Agent 时，最直观的想法是搞个 Agent 自由聊天室——让 PM Agent、Dev Agent、QA Agent 在一个群里用自然语言自由开会讨论。但跑了一阵子后，账单和延迟把大家打醒了。一个简单的任务，几个 Agent 客套澄清几轮，Token 翻了五倍，耗时拉到一分半，还经常因为某个 Agent 的小错导致全盘乱套。靠 Agent 自由聊天干活，在工程上根本跑不通。Google 彻底放弃了这种聊天室幻想，明确了控制流，必须由一个主控掌控全局，远端 Agent 仅仅是提供特定能力的工具。
然而，这种设计虽然解决了远端 RPC 问题，却在单系统内部遭遇了应用内 Sub-agent 机制的剧烈挤压。很多人在谈多 Agent 的价值时，常喜欢举出用子 Agent 读五万字日志只返回两百字摘要来清理上下文、用大模型规划配合小模型清洗来省钱、以及同时派几个子 Agent 并行搜索等典型用法。但这其实是一个很大的误区，大家以为自己在谈专门的网络协议，但这些场景在实际落地时，根本不需要任何网络协议。
在 Claude Code、Codex 或 OpenCode 这类工具里，应用内部的 Sub-agent 机制已经在本地以零网络开销完美解决了这些问题。开发者可以在本地内存里直接派发子任务，根本不需要部署 HTTP 接口，也不需要配置能力名片。本地 Sub-agent 在单体工具里的出色表现，直接吃掉了这类协议在单系统内部的绝大部分生存空间。真正不可替代的价值，被死死压缩在剩下 10% 的跨公司远端 RPC 场景里。
上述工程取舍与市场挤压交织在一起，最终构成了此类协议极其尴尬的后继后果。极其狭窄的市场空间，加上技术和安全上的巨大麻烦，让 A2A 陷入了吃力不讨好的困局。跨网络让 Agent 互相通信，安全上的隐患层出不穷。
最致命的安全风险是提示词注入级联。一个负责抓取网页的子 Agent 被恶意数据污染后，返回的结果可能会诱骗主控 Agent 去执行删除本地文件或导出密钥的操作。另一个棘手的问题是混淆代理越权，低权限的外部 Agent 可能会利用远端高权限 Agent 的身份，去越权调取敏感数据。
更深层的危险在于授权模型的断层。本地命令行工具默认继承你本机的确认授权，但一旦暴露成 HTTP 接口，它就变成了远程多租户服务。Google 自身的 Gemini CLI 之前紧急修复 A2A 隔离漏洞，就是因为发现如果多个 A2A 任务共享工作区，注入攻击会直接变成远程代码执行。僵尸任务的缠绕同样难以收拾。在跨网络调用中，如果用户点了取消，远端子 Agent 如果没有可靠的通知机制，就会变成在后台默默烧 Token 且随时可能写脏数据的僵尸进程。
极其狭窄的目标市场，加上提示词注入、身份传递、多租户沙盒和僵尸任务等一堆极难解决的工程死穴，最终决定了 A2A 协议的命运。它可能会作为大企业 B2B 基础设施的一部分安静存在，但在更广泛的 AI 开发者圈子里，它注定会长期保持不温不火的状态。