Agent互操作标准：MCP与A2A成AI基础设施

AI Agent 经济的瓶颈从来不是模型不够聪明，而是系统之间接不上线。当 Anthropic 将 MCP 捐给 Agentic AI Foundation、Google 随后把 A2A 也交到同一基金会手中时，真正重要的协议不再是某家公司的营销卖点，而变成了公共基础设施。

这背后是两个规范家族的分工：MCP 负责工具访问，A2A 负责 Agent 之间的委派。它们从实验室走进基金会的过程，以及为什么真正的安全边界是授权而非提示词设计，构成了理解 Agent 基础设施层的关键。

两个协议，两类问题

MCP（Model Context Protocol）由 Anthropic 主导，解决的是「模型如何调用外部工具」的问题——调用计算器、查询数据库、发起网络请求，而不需要为每个工具写一次定制集成。A2A（Agent-to-Agent Protocol）由 Google 发起，解决的是「一个 Agent 如何让另一个 Agent 替它做事」的问题：如何发现对方能力、如何委派任务、如何确认对面确实是它声称的那个 Agent。

两者的作用域并不重叠，这也是为什么它们能在同一基金会下共存，而非互相取代。

标准之争终结于基金会，而非市场

2025 年 12 月 9 日，Anthropic 把 MCP 的代码库与治理框架捐给 Linux Foundation。同一场活动上，基金会宣布成立 Agentic AI Foundation（AAIF）——一个定向基金（directed fund），并非独立法人实体，由 Anthropic、Block 和 OpenAI 联合发起，并获 AWS、Google、Microsoft、Cloudflare、Bloomberg 支持。

创始成员名单几乎就是基础设施层的点名册。铂金级包括 AWS、Anthropic、Block、Bloomberg、Cloudflare、Google、Microsoft、OpenAI；黄金级涵盖 Adyen、Cisco、Datadog、Docker、IBM、JetBrains、Okta、Oracle、Salesforce、SAP、Shopify、Snowflake、Temporal 等；白银级另有 22 家公司，从 Elastic 到 Zapier。

广度的意义在于：只有 Anthropic 支持的协议只是一个 API 封装；而被 Oracle、IBM、Docker 同时采纳的协议才是接线层。治理设计同样刻意——AAIF 作为 Linux Foundation 下的定向基金运作，继承的是 LF 的中立规则，而非任何联合发起公司的规则。MCP 官方博客确认「此前引入的治理模型继续沿用」，即捐赠转移的是资产，不是权威。

Linux Foundation 定向基金（Directed Fund） 是该组织常用的一种治理结构，并非独立法人，而是在基金会框架下设立、由多家成员共同出资并组成管理委员会的项目账户。它的特点在于：资产与商标的所有权归基金会而非单一捐赠方，治理规则遵循基金会的中立章程，成员按出资级别获得相应席位。这与把项目托管在单一公司 GitHub 组织下有本质区别——后者在法律和治理上仍受该公司控制，随时可能更改许可或路线。对 MCP 和 A2A 而言，进入 AAIF 意味着它们的演进方向不再由 Anthropic 或 Google 单方面决定，而是由铂金、黄金、白银各级成员共同参与。这也解释了文中那句「捐赠转移的是资产，不是权威」：Anthropic 仍是最大贡献者之一，但已无法像对待自家产品那样单方面改变协议规则。

MCP 靠分发赢了位置，而非靠优雅

MCP 捐赠公告中的数字比任何设计评估都更能解释它的采用轨迹：协议已累积 超过 9700 万次月度 SDK 下载、1 万个活跃服务器，并在 ChatGPT、Claude、Cursor、Gemini、Microsoft Copilot 和 Visual Studio Code 中获得一等公民级别的客户端支持。

拥有这种装机量的协议，赢下标准化之争靠的不是设计最优，而是它已经被接进了开发者每天早上打开的工具里。这也正是 Anthropic 的捐赠可信而非作秀的原因：捐出一个被生态系统依赖、月下载近亿的协议，战略代价是真实的——就像微软开源 Git 并没有消除 Git 的战略价值，但让替换它变得不可能。AAIF 的挑战不是建立采用，而是在一个不偏向捐赠方的治理模型下维持采用。

A2A 回答了 MCP 不愿问的问题

A2A 的时间线已是公开记录：2025 年 4 月由 Google 宣布，2025 年 6 月 23 日作为独立项目捐给 Linux Foundation，2026 年 8 月 18 日移入 AAIF 之下——一条三段式轨迹，而非单次捐赠事件。到 A2A 1.0 发布时，它加入了多租户、协议协商和签名 Agent 卡片。

签名 Agent 卡片是其中最具安全意义的新增项：它用于强化企业部署和身份验证，正是两个由不同厂商管理的 Agent 在缺乏共享身份提供商时建立互信所需的那套机制。Techstrong.ai 对 AAIF 整合的报道给出了直白定义：A2A「让 AI Agent 能跨框架和厂商发现能力、委派任务并通信，无需定制集成」。关键词是无需定制集成——任何互操作协议的经济价值，都随它消除的定制集成数量而放大。

签名 Agent 卡片（Signed Agent Card） 是 A2A 用于解决跨组织身份问题的机制。Agent 卡片本质是一份声明文档，列出该 Agent 的能力、端点、支持的协议版本与认证要求，供对方在委派任务前发现和评估。加上数字签名后，卡片不再只是自我声明，而是可由公钥验证来源的凭证——接收方可以确认「对面确实是我以为的那个 Agent」，而非某个冒名顶替者。这一点在企业部署中尤为关键：当两个由不同厂商、不同身份提供商管理的 Agent 需要协作时，双方并没有共享的 SSO 体系可以依赖，签名卡片就承担了跨信任域的身份锚点。它与 MCP 侧的受众绑定令牌形成互补——A2A 保证「对方是它自称的那个 Agent」，MCP 保证「这个令牌只能用在这一个服务上」。

碎片化没有消失，只是上移了一层

把两个协议放进同一基金会并不消除碎片化，只是把它搬了个位置。AAIF 之前，风险是两个厂商推出互不兼容的协议，逼每家企业维护两套集成面；AAIF 之后，风险变成两个协议在同一平台内共存，集成面从厂商边界移到了授权边界。

这不是更小的问题，某种意义上反而更大，因为失效模式从「缺一个连接器」变成了「混淆代理漏洞」（confused deputy）。MCP 授权规范在其 2025-06-18 修订版中明确点名了这一点：机制必须实现 OAuth 2.1（draft-ietf-oauth-v2-1-13），配合 RFC 9728 的受保护资源元数据和 RFC 8414 的授权服务器元数据。关键安全要求是经由 RFC 8707 的受众绑定：resource 参数必须同时出现在授权请求和令牌请求中，服务器必须验证访问令牌是专门为它作为预期受众签发的。规范明文列出的反模式是令牌透传。防御手段不是更多提示词指令，而是更严格的授权。

混淆代理漏洞（Confused Deputy） 是访问控制领域的经典问题：一个拥有较高权限的组件被低权限方诱骗，替它执行了本不该被允许的操作。经典例子是编译器服务——它有权写系统日志文件，攻击者让它把日志文件当成输出目标，于是借它的权限覆盖了本不该由自己触及的文件。在 Agent 场景中，MCP 服务器往往同时持有多个下游服务的凭据，如果它只验证「请求里有没有令牌」而不验证「这个令牌是不是专门签给我、面向这次调用的」，那么一个被攻陷或恶意的中间 Agent 就能拿别处获得的令牌驱使服务器代它访问本无权访问的资源。这正是 MCP 授权规范为什么把攻击面定位在协议层而非模型层的原因：模型无法通过更谨慎的推理来防御这类攻击，只有服务端的令牌受众校验才能阻断它。理解这个概念，是理解全文「安全边界是授权而非提示词设计」这一论断的前提。

文中提到的四项规范构成一套配合使用的元数据与授权机制。OAuth 2.1 是 OAuth 2.0 的精炼版本，删去了已被弃用的隐式授权和资源所有者密码模式，强制 PKCE，是当前授权流程的基线。RFC 9728（Protected Resource Metadata） 让资源服务器通过一个标准化端点公布「我是谁、我用哪个授权服务器」，使客户端无需硬编码即可发现信任链。RFC 8414（Authorization Server Metadata） 同理，用于暴露授权服务器的端点、支持的授权类型与签名算法。RFC 8707（Resource Indicators） 则规定客户端在授权请求与令牌请求中显式声明目标资源，使授权服务器能签发受众绑定令牌——即令牌本身写明了它只对某个特定服务有效。四者叠加的效果是：令牌在链路上流通时带有明确的归属，任何一方都无法用它越界行事。

工具访问是授权问题，不是提示词问题

MCP 规范的授权章节本身就是一份值得独立阅读的安全文档。其中的 MUST 条款不含糊：授权服务器必须实现 OAuth 2.1 并针对机密客户端和公共客户端采取相应安全措施；服务器必须实现 OAuth 2.0 受保护资源元数据（RFC 9728）；客户端必须实现 OAuth 2.0 Resource Indicators（RFC 8707）；resource 参数必须存在于授权和令牌两类请求中。没有可选合规一说——跳过受众绑定的服务器不是「不合规」，而是「有漏洞」，因为规范描述的混淆代理场景正是这样发生的。

对任何 Agent 部署而言，推论都很具体：把 Agent 接到真实外部 API 时，授权设计应当和对接外部厂商时完全一致——受众绑定令牌、按工具粒度的授权作用域、禁止令牌透传、明确出站允许清单、每次调用都审计日志、协议客户端与服务器之间进行版本协商，以及定义清晰的失败语义，让授权失败产生可恢复错误而非静默降级。这些不是最佳实践，而是让 Agent 保持互操作而不沦为混淆代理的前提条件。

像对接外部厂商一样把 Agent 接进真实系统

规范推导出的实操清单短而严：转发前验证受众绑定令牌；把每次授权限定到被调用的具体工具；绝不向下游服务透传未经修改的令牌；强制执行定义好的出站允许清单；每次调用都完整记录 resource 参数；显式协商协议版本；定义失败语义，让授权错误可恢复而非被掩盖。

这些恰恰是企业在集成第三方厂商之前会要求的控制项——而这就是正确的心智模型，因为一个被协议标准化的 Agent，在授权意义上，就是一个第三方厂商。

底线

Agent 互操作不再是投机性的标准设想。它是一个有可核实成员层级的基金会，一个拥有 9700 万月度 SDK 下载的协议，以及一份把自身失效模式写进正文的授权规范。剩下的问题不是 Agent 会不会被接进真实系统，而是接入它们的组织会不会像规范要求的那样严肃对待授权——或者说，第一起大规模混淆代理事故，会不会成为教会大家这一课的事件。基础设施层能在失败教会它之前撑住吗？