MCP、A2A、Agent Plugins 三层协议分化，AI Agent 生态基础设施格局初定

这不是说竞争消失了——而是战场发生了转移。半年前，开发者还在热烈争论"MCP vs 其它协议哪个更好"，而现在答案已经清晰得让人有点意外：没有哪个更好，只有哪个更适合哪一层。

先说背景。AI Agent 的协议演进，在过去两年里经历了一个典型的"分久必合、合久必分"的过程：

• 2024年：各自为战，每家平台都有自己的工具调用格式
• 2025年：MCP 异军突起，成为工具调用的事实标准
• 2026年上半年：协作需求爆发，A2A 协议顺势而出
• 2026年8月：打包分发问题浮出水面，Agent Plugins 1.0 登场

三层架构不是设计出来的，是需求倒逼出来的。

第一层：MCP——管"工具"，做执行

MCP（Model Context Protocol） 的定位从一开始就很明确：Agent 与外部世界的接口层。它定义了 Agent 如何调用工具、读取资源、接收提示——本质上是一套标准化的"工具发现 + 调用"协议。

2026年7月28日，MCP 发布了史上最大一次重构：彻底移除 Session 状态，转向无状态 HTTP 架构。这一决策看似技术性，实则是战略性的：

无状态意味着协议本身可以真正中立于具体实现

同周，MCP 月下载量突破 1.1亿次。这个数字意味着什么？意味着它已经不只是 Anthropic 的产品，而是整个 AI 工具生态的基础设施。

MCP 解决的是"Agent 能做什么"的问题，但它不解决：

• 如何组合多个 Agent 的能力完成复杂目标
• 如何分发和安装一个 Agent 的全部技能包

第二层：A2A——管"协作"，做编排

A2A（Agent-to-Agent Protocol） 是协作层的协议。2026年8月，它迎来发布一周年，同时交出了一份漂亮的成绩单：150+ 组织进入生产部署，Google Cloud、AWS、Azure 三大云平台全部原生内置。

这是非常重要的信号。三大云同时选择内置，意味着 A2A 已经成为企业级 Agent 编排的事实底座。

A2A 解决的核心问题是：当一个 Agent 需要另一个 Agent 的能力时，它们如何互相发现、如何交换上下文、如何协调执行。

你有一个"行程规划 Agent"，它发现用户需要订酒店。它不需要自己实现酒店 API，而是通过 A2A 找到"酒店预订 Agent"，把用户偏好传递过去，等待结果，继续执行后续流程。

这种模式下，每个 Agent 只需要做好自己的专长，不需要变成全能的"上帝 Agent"。

A2A 处理的是"Agent 如何对话"，但它不涉及：

• 如何分发、版本控制、安装一个 Agent 的能力

第三层：Agent Plugins——管"分发"，做资产化

2026年8月6日，Agent Plugins 1.0 正式发布，由 OpenAI、AWS、微软、Vercel、Cursor、GitHub 六家联合发布。

这个协议的核心创新是：将 Skills（技能定义）+ MCP 配置打包成一个可移植的插件单元。

Agent Plugin = Skill Manifest + MCP Config + 权限声明 + 版本信息

这意味着什么？意味着你可以把一个复杂的 Agent 技能包，像安装 npm 包一样，分发给其他开发者、其他平台、其他环境。

一个细节：Anthropic 不在 Agent Plugins 的联合发布名单里。

这不代表 Anthropic 的失败，恰恰相反——这更像是一种有意识的生态选择。Claude Code 已经有了自己的 Agent 架构和工具链，MCP 的主导权也在 Anthropic 手中。他们不需要再加入一个打包分发协议来削弱自己的话语权。

这也让 Agent Plugins 的竞争格局更加清晰：它是一个平台中立的标准，而非某一家公司的产品延伸。能否真正做到这一点，将决定它能走多远。

竞争格局：三层各守边界

协议层的竞争已经基本结束——不是说没有替代方案，而是三层的边界已经足够清晰，任何试图跨越多层大一统的方案，都会因为不够专注而失去竞争力。

当协议标准化之后，下一个竞争维度是谁能让插件的发布、分发、安装体验做到最顺滑。GitHub 和 Vercel 的加入不是偶然——他们在开发者分发基础设施上有深厚的积累。Cursor 的参与则说明 IDE 集成会是重要的分发入口。

安全与信任：被放大的风险

当 Agent 可以调用外部工具、可以与其他 Agent 协作、可以安装来自第三方的插件时，安全问题会被指数级放大。

• 一个 Agent Plugin 申请了哪些权限？边界是否清晰？
• 两个 Agent 协作时，数据如何在它们之间流转？

这些问题目前只有初步的答案，还没有成熟的解决方案。谁能率先建立可靠的信任体系，谁就能赢得企业市场。

长期记忆：悬而未决的标准空白

三层协议解决的都是"即时"问题——工具调用、任务协作、技能分发。但 Agent 的长期记忆、经验积累、跨会话学习，目前还没有标准协议。

开发范式转变

这个问题已经没有意义了。三层各司其职，你的 Agent 需要什么就用什么：

• 需要调用外部工具？→ 用 MCP
• 需要和其他 Agent 协作？→ 用 A2A
• 需要把你的 Agent 打包给别人用？→ 用 Agent Plugins

过去的 Agent 开发模式是：做一个能干的单体 Agent，所有能力都塞进去。

未来的 Agent 开发模式应该是：做一系列可组合的专业技能包，每个包都可以独立工作，也可以与其他包组合。

这就要求你在设计每一个 Agent 时，问自己一个问题：这个 Agent 的能力，能否被完整地打包并安装到另一个 Agent 环境中去？

如果答案是"不能"，那就说明设计上有耦合问题，需要重构。

下一步值得关注

Agent Plugins 1.0 的发布只是开始。真正的价值在于围绕它的插件市场——谁会成为 Agent 技能的"npm"？这才是 2026 年下半年最值得关注的竞争点。

如果你是 Agent 开发者，现在就开始用 Agent Plugins 的格式来结构化你的技能包。即使工具链还不成熟，提前对齐格式会在生态成熟时获得先发优势。

它意味着基础设施趋于稳定，开发者可以把更多精力放在真正重要的事情上：做什么样的 Agent，解决什么问题，创造什么价值。

三层分化的架构给了我们一个清晰的框架：工具层做执行，协作层做编排，分发层做资产化。每个层面都有自己的创新空间，每个层面都值得深耕。

但最本质的信号只有一个：Agent 不再是一个独立的软件产品，而是一个可以组合、可以分发、可以协作的数字劳动力单元。

如果你对这个话题有更多想法，欢迎在评论区交流。我也在关注 MCP 无状态重构的具体实现细节，以及 Agent Plugins 的生态发展，后续会继续写文章跟进。