行业观察

Agent 互操作协议之争：MCP、A2A 与工具调用标准的三条路线

作者

AgentMCP协议行业观察

Agent 生态在 2026 年出现了一个有点尴尬的局面：每家厂商都说自己”支持开放协议”，但把 A 家的 Agent 接到 B 家的运行时上，仍然要写一层适配代码。所谓”协议之争”，争的不是某个 JSON 字段，而是谁来定义 Agent 边界的切法。

本文不预测谁赢，而是把当前几条主要路线拆开：它们各自解决什么问题、在什么层次上重叠、以及一个正在做 Agent 产品的团队应该在哪一层投入、在哪一层保持可替换。以下涉及的时间与采纳情况均为公开信息整理与个人判断，具体数字仅作参考。

一、先分清三个不同的”互操作”

讨论协议时最大的混乱，是把三件事混成一件。它们的耦合点完全不同：

层次解决的问题代表方案谁是”客户端”
工具接入层Agent 如何发现并调用外部能力MCP、各家 plugin/tool 规范模型运行时
Agent 间协作层Agent 如何把任务委托给另一个 AgentA2A 类协议、任务/消息信封另一个 Agent
模型 API 层请求/响应报文长什么样OpenAI 兼容格式、Anthropic Messages应用代码

三层可以任意组合。你完全可以用 Anthropic 的 Messages API 跑一个挂了十个 MCP server 的 Agent，再用某种 Agent 间协议把子任务派给同事团队的服务。反过来，“我们支持 MCP” 这句话对模型 API 层的可移植性毫无贡献——这是最常见的误读。

可复用的判断：当有人说”我们兼容开放协议”，先问是哪一层。三层里只兼容一层的产品，迁移成本仍然接近从零重写。

二、工具接入层：MCP 事实上赢了半场

MCP 的设计优势不在技术新颖，而在它把”工具”从应用代码里拆了出来，变成一个可独立部署、独立鉴权、独立版本管理的进程。这一刀切得很准，因为它对应了真实的组织边界：写数据库查询工具的人，和写 Agent 编排逻辑的人，往往不是同一批。

它赢的是”半场”，因为剩下半场的问题没解决：

  • 权限粒度。协议层面定义了工具的调用契约，但”这个 Agent 能不能调这个工具、能调几次、在什么上下文下能调”，仍然是各家运行时自己实现。参见我们对 Agent 权限体系设计 的展开。
  • 工具描述质量不可移植。同一个 MCP server 挂到不同模型上，效果差异可能比换模型还大，因为工具描述的写法高度依赖目标模型的偏好。
  • 多 server 的上下文膨胀。挂十个 server 意味着几十个工具定义常驻上下文，token 成本和选择准确率同时恶化。

所以实际情况是：MCP 解决了分发问题（工具能被装上），没解决治理问题（工具被正确地用）。这也是为什么各家运行时仍在 MCP 之上加自己的一层。

三、Agent 间协作层：问题定义还没收敛

工具接入层之所以能收敛，是因为”调用一个函数拿到结果”这个语义足够窄。Agent 间协作没有这种运气——它至少要回答四个彼此独立的问题：

  1. 任务信封：一个任务的描述、输入、约束、截止条件怎么表达？
  2. 状态与长任务：Agent B 执行两小时，A 怎么轮询、怎么收中间进度、怎么取消？
  3. 身份与信任：A 凭什么相信 B 的输出？B 凭什么接受 A 的指令？跨组织时这是个真问题。
  4. 结果结构：返回自然语言、结构化对象，还是一份可审计的轨迹？

现有各种方案在 1 和 2 上有不少相似之处（本质是异步任务队列的 RPC 化），但在 3 和 4 上分歧很大。而 3、4 恰恰是决定协议能否跨组织用的关键——同一家公司内部，用 HTTP + 约定好的 JSON 就够了，根本不需要协议。

可操作的结论：如果你的 Agent 协作全部发生在自己的基础设施内，现在采用任何 Agent 间协议都是过度投资。把任务信封定义成自己的内部 schema，用 Agent 状态机设计 里那套显式状态管理，比追协议更有价值。等到确实要跟外部 Agent 打交道时再加适配层，成本不会更高。

四、模型 API 层：兼容格式是妥协不是标准

OpenAI 兼容格式变成了事实网关语言，原因很实际——工具链存量太大。但它作为”标准”有明显问题：它是某一家产品在某个时间点的实现细节被固化下来的结果，而不是设计出来的协议。

具体表现：

  • 推理类参数（thinking budget、reasoning effort）在兼容格式里没有位置，各家网关只能塞进 extra_body 之类的口袋字段
  • 缓存控制、引用（citations）、多模态的表达各家差异很大
  • 流式事件的粒度不同，SSE 解析逻辑无法直接复用

这意味着”改 base_url 就能换模型”只在最简单的对话场景成立。一旦你用到工具调用、缓存、结构化输出，跨家迁移仍然要改代码。这层的现实做法不是等标准，而是自己做抽象：

# 在应用和各家 SDK 之间放一层薄适配，只抽象你真正用到的能力
class ChatRequest:
    messages: list
    tools: list | None = None
    max_output_tokens: int = 4096
    reasoning: str | None = None   # "low" | "medium" | "high"，各家自行映射
    cache_hint: bool = False       # 由适配层决定翻译成 cache_control 还是 ttl 参数

class Provider(Protocol):
    def chat(self, req: ChatRequest) -> ChatResponse: ...
    def stream(self, req: ChatRequest) -> Iterator[ChatDelta]: ...

# 关键纪律：适配层只暴露"所有目标厂商都能表达"的能力交集，
# 厂商独有能力走显式的 escape hatch，调用处能一眼看出自己被锁定了。

这层薄适配通常两三百行就够，比等一个统一标准落地现实得多。相关取舍我们在 OpenAI 兼容格式与 Anthropic 协议的差异 里做过更细的对比。

五、协议竞争的真正变量：谁控制分发

技术上三条路线并不互斥，但商业上它们抢的是同一件东西——开发者默认写代码时想到的那个接口。历史上这类竞争的结果，通常不取决于协议本身的优劣，而取决于三件事：

  • 谁的实现最容易跑起来。一个 15 分钟能接通的 SDK，胜过一份写得更严谨的规范。
  • 谁能带来现成的对端。协议的价值等于对端数量的平方级函数，早期生态补贴比技术设计更有决定性。
  • 谁在模型侧有议价权。能让自家模型对某种工具描述格式”训练得更好”的一方，天然占优——这不是开放协议能抹平的。

第三点值得特别注意：即使协议是开放的，模型对协议的执行质量不是开放的。同样的工具 schema，不同模型的调用准确率差异可以到两位数百分点。这让”协议中立”在实践中打了折扣。

六、给正在做决策的团队的三条线

综合下来，我的建议按投入优先级排：

  • 工具接入层：跟进，但别裸奔。用 MCP 把工具拆出来是对的，收益是清晰的边界和复用。但在 MCP 之上必须自己加权限与预算控制——协议不会替你做这件事，参见 Agent 沙箱设计。
  • Agent 协作层：观望，先做内部 schema。没有跨组织需求就别引入。把任务定义、状态流转、重试语义写成自己能演进的结构，将来适配任何协议都只是加一层翻译。
  • 模型 API 层：自己抽象，不押注任何一家的”兼容”。两三百行的 Provider 接口，是这三层里性价比最高的一笔投入，也是多模型路由和故障切换的前提。

还有一条元判断：协议标准化程度越低的层次，越应该保留自己的抽象；标准化程度越高的层次，越应该直接用现成的。当下的分布恰好是工具接入层最收敛、Agent 协作层最发散，投入比例也应该按这个来。

七、未来一年可能的观察点

以下都是基于公开信息的个人判断，不构成预测：

  • 工具接入层的竞争大概率从”协议”转到”注册表与信任”——工具从哪来、谁签名、怎么审计，会比调用格式更重要
  • Agent 协作层可能不会出现单一赢家，而是在特定垂直场景（比如企业内部审批流、跨公司采购）先形成局部约定
  • 模型 API 层的碎片化短期不会缓解，因为新能力的发布速度快于标准化速度，这是结构性的

对开发者来说，好消息是：这三层的变化都发生在你自己抽象层的外侧。只要那层抽象存在，协议之争的结果对你的代码影响有限。

八、相关阅读

相关阅读