MCP 与 A2A 正在组成代理协议栈：企业真正要标准化的是能力边界

当 AI 从回答问题走向调用系统、修改数据和委托任务，企业面对的核心问题不再只是选哪一个模型，而是如何让不同模型、工具和代理在可控边界内协作。过去每个团队都为数据库、工单、代码仓库和内部服务单独编写连接层，模型一换、框架一换，接口和权限设计往往也要重做。MCP 与 A2A 的价值，正是把这部分重复工程抽象为共享协议。

但“支持协议”并不等于“可以直接上线”。协议统一的是交换方式，真正影响安全性和可靠性的，仍是能力如何描述、权限如何下放、任务如何恢复以及结果如何验证。把 MCP 或 A2A 当成一个新插件市场，很容易重新制造一套更隐蔽的系统耦合；把它们当成企业能力边界的契约，才可能获得长期收益。

两个协议解决的是不同层次的问题

MCP 2025-11-25 版规范采用客户端—服务器结构，服务器可向 AI 应用暴露三类核心能力：工具、资源和提示模板。工具让模型执行查询或动作，资源提供可读取的上下文，提示模板则承载可复用的交互入口。对应用而言，MCP 更像一条纵向连接：代理通过统一方式接入数据库、文件、SaaS 或开发工具。

A2A v1.0关注的是另一条横向连接：不同框架、语言或供应商实现的代理如何发现彼此、声明技能、交换消息并管理任务生命周期。调用方不需要看到远端代理的内部提示词、记忆或工具，只需要知道它提供什么能力、接受什么输入、返回什么产物，以及任务处于提交、执行、等待输入、完成或失败等哪种状态。

因此，两者不是替代关系。一个报销代理可以通过 MCP 查询财务制度并创建付款单，同时通过 A2A 把异常票据委托给合规代理。前者连接“代理与能力”，后者连接“代理与代理”。在简单业务里，一个代理加少量工具通常已经足够；只有当责任边界、技术栈或组织边界确实需要拆分时，多代理通信才会带来净收益。OpenAI 的代理构建指南也建议先最大化单代理能力，再在复杂逻辑或工具重叠造成稳定问题时拆分。

MCP · 纵向能力连接

企业代理↓MCP 客户端↓工具 · 资源 · 提示模板

A2A · 横向代理协作

调用代理↔任务生命周期↔远端代理

共同治理层身份与最小权限状态与幂等日志与审计结果评测

依据 MCP 与 A2A 公开规范整理。图中表示责任边界，不代表两套协议必须同时用于所有场景。

标准接口不等于标准语义

协议可以规定字段和传输，却无法自动回答“退款”具体意味着什么。一个名为 create_refund 的工具，可能只是生成草稿，也可能立即划款；金额单位可能是元，也可能是分；重复调用可能返回同一结果，也可能造成二次退款。结构化参数只能消除语法歧义，不能替代业务契约。

每项能力至少应补齐六类信息：适用场景与反例、输入输出约束、读取或写入范围、是否幂等、失败与重试语义、负责人和版本策略。高风险动作还应明确审批点、金额或数据范围上限以及可逆方式。工具描述不是写给演示看的说明文字，而是模型选择动作时依赖的运行时接口，也是安全审计的第一份证据。

这会带来一个重要变化：企业的“代理平台”不应只维护可连接服务的数量，还要维护一份受治理的能力目录。目录中的每个工具或代理技能都应有稳定标识、模式版本、风险等级、服务级别和测试样例。模型可以更换，编排框架也可以更换，但能力契约应当像成熟 API 一样持续演进。

身份与授权必须穿过整条调用链

多代理系统最危险的误解，是把上游已经登录等同于下游可以获得全部权限。用户允许一个助手读取日历，不代表它委托的任意代理都应得到同一访问令牌；一个代理可以提交采购建议，也不代表它有权批准付款。随着调用链变长，身份、授权目的和数据边界如果丢失，协议越通用，潜在影响面反而越大。

更稳妥的做法是让每次调用都携带可审计的主体、目的和最小权限范围，使用短期凭据，并在跨组织委托时重新进行授权判断。读操作与写操作应分离，查询、草拟、提交和批准也应是不同能力。高风险步骤需要明确的人类确认，不能仅依赖模型在自然语言中“记住要询问”。

MCP 的授权规范不断补充 OAuth 发现和增量授权等机制，A2A 也在 v1.0 中强化版本协商与企业部署要求；这些机制提供了实现基础，却不会自动替企业定义角色和职责。技术团队仍需要把现有 IAM、数据分级和审批制度映射到代理调用链。

长任务的难点是状态，而不是消息

现实任务经常跨越分钟、小时甚至数天：等待用户补充材料、等待外部系统回调、等待人工批准。此时一次请求和一次响应远远不够。系统需要持久化任务 ID、当前状态、已完成步骤、产物、错误和下一次可执行动作，还需要支持取消、超时、恢复与人工接管。

A2A 把任务生命周期放进协议，MCP 也已经探索可轮询、可延迟取回结果的任务机制。但工程上仍必须回答：网络超时后是否可以安全重试？代理重复提交会不会产生两笔订单？任务版本升级后旧状态能否恢复？取消指令到达时，已经发出的外部动作如何补偿？这些问题属于分布式系统，而不是提示词工程。

因此，所有有副作用的能力都应优先设计幂等键、去重窗口和补偿路径。任务编排器应把模型判断与确定性状态机分开：模型决定“下一步尝试什么”，状态机决定“这一步是否允许、是否已执行、如何记录”。

可观测性要覆盖结果与路径

仅记录最终回答，无法解释代理为什么调用了某个工具，也无法判断一次成功是否只是偶然。生产系统应关联用户请求、代理版本、模型版本、工具清单、授权决策、每次调用参数摘要、状态变化、最终产物和人工修改。敏感字段需要脱敏，但关键决策链不能消失。

评测也应围绕完整任务，而不是只检查一句输出。除正确率外，还要观察未经授权的调用、错误重试、任务完成时间、人工接管率、单位成功成本和重复运行的一致性。协议兼容测试只能证明双方“能说话”，业务评测才证明它们“能把事做对”。

一条更稳妥的落地路径

第一步，先整理能力目录。选择一条低风险、高频流程，把已有 API 按读取、草拟和执行分层，补齐模式、权限和失败语义。

第二步，用 MCP 统一工具接入。先服务一个代理和一个清晰场景，验证发现、调用、授权、日志和版本升级，不急于把所有内部系统一次性开放。

第三步，只在边界明确时引入 A2A。当任务需要跨团队、跨供应商或跨运行环境委托时，再把稳定能力封装成代理技能，并为任务状态和失败恢复建立契约。

第四步，把协议检查纳入发布门禁。每次变更同时运行模式兼容、权限负例、幂等重试和端到端结果测试；新模型上线也必须重跑同一套业务任务。

协议的护城河不在连接数量

MCP 与 A2A 降低了连接成本，也让工具和代理更容易替换。但企业真正积累的资产，不是接入了多少服务器或代理，而是是否拥有一套清晰、可测、可授权、可审计的能力契约。连接层越标准，业务语义和治理质量越会成为差异来源。

代理协议栈正在成形，但它不会替代系统工程。把模型放在受约束的能力边界里，让每次委托都有身份、状态、证据和退出路径，才是从“可以互联”走向“值得信任”的关键一步。