六巨头共建AI插件标准：为何开创者Anthropic意外缺席？
告别“重复造轮子”：AI插件标准化的必然趋势
在人工智能从模型竞赛迈向应用落地的深水区，开发者长期面临着一项令人头疼的工程性难题：同一个功能模块，往往需要在不同的客户端环境中进行重复适配与打包。无论是Cursor、GitHub Copilot还是OpenAI的Codex，每一家平台都拥有独立的目录结构、清单文件格式以及配置规范。这种碎片化的现状，不仅极大地增加了开发者的维护成本，也阻碍了智能体插件的跨平台流通。
2026年8月6日，这一僵局终于被打破。AWS、Anysphere（Cursor母公司）、GitHub、微软、OpenAI、Vercel六家科技巨头，联合谷歌，共同发布了名为Agent Plugins 1.0.0的开放规范。这份文档看似平静，实则具有里程碑式的意义。它确立了一个统一的“包装盒”标准，旨在实现“一次打包，到处运行”的理想状态。
核心痛点在于解决技能（Skills）与模型上下文协议（MCP）服务器的复用问题。在过去，一个用于“查询数据库并生成周报”的插件，若要在三个不同客户端中使用，开发者需要编写三份几乎相同的配置代码，任何一处逻辑修改都需要在三处同步更新。Agent Plugins 1.0.0通过统一定义目录结构、清单文件（plugin.json）及MCP配置写法，将这一过程简化为单一源的维护。只要客户端兼容该规范，即可自动识别并加载插件内容，从而彻底终结了这种低效的重复劳动。
解构统一规范：是“包装盒”而非“智能体”本身
理解Agent Plugins 1.0.0的关键，在于厘清它统一的是什么，以及它未触碰的边界。这份规范的核心价值在于封装，而非定义智能体的行为逻辑。
一个标准的AI插件主要由两部分构成：一是Agent Skills，即给模型的可复用指令和资源；二是MCP Server，负责连接外部工具和服务。这两者本身具备跨客户端复用的潜力，真正阻碍复用的，是最外层的封装形式。各家客户端对文件结构、元数据描述方式的差异，导致同一个内核组件换个平台就得重新“搬家”。
Agent Plugins将这一层封装标准化了。其结构极其精简：插件即一个文件夹，根目录存放plugin.json清单，技能目录置于skills/下，MCP配置写入mcp.json。清单文件中仅强制要求$schema和name两个字段，其余配置依靠固定路径自动发现。这种设计使得客户端无需具备复杂的解析逻辑，降低了实现门槛。
值得注意的是，规范采取了“少即是多”的策略。它仅统一了可移植性最强的两类组件：skills和mcp.json。对于 hooks（钩子）、斜杠命令（slash commands）、custom agents（自定义智能体）等具有较强平台依赖性的功能，规范明确将其保留在各自客户端的私有领域。这些私有内容被放置在以反向域名命名的目录中，其他不认识的客户端会直接忽略，从而保证了公共规范的纯净与轻量。
此外，当前规范仍标记为“工作草案”（Working Draft），这意味着标准本身仍在演进中。它更像是一个基础协议框架，为未来的扩展留下了空间，但尚未成为最终的行业盖章标准。
运行环境的鸿沟：统一封装不等于统一执行
尽管“包装盒”统一了，但插件在客户端内部的运行逻辑依然存在巨大差异。规范正文明确声明，对于安装、分发、权限管理、沙箱隔离、身份认证、信任验证以及最终的用户体验，规范均不予干涉，完全交由各客户端自行决定。
这种“甩手”式的设计，反映了巨头们在标准制定上的务实态度。真正具有商业壁垒和用户粘性的部分——如应用市场分发体系、用户权限控制、以及独特的交互能力——是各家企业的核心资产，绝不可能在基础规范阶段交出。
以传输协议为例，微软、OpenAI等对stdio、Streamable HTTP、旧版HTTP+SSE等不同传输方式的支持程度不一。这意味着，即便插件格式统一，开发者仍需关注目标客户端的具体运行环境。微软官方文档甚至特别强调，由于插件中的MCP Server和hooks涉及本机代码执行，安装前必须严格审查来源与作者，尤其是在社区市场中下载的插件，安全风险不容忽视。
此外，生态兼容性的过渡也需要时间。目前，OpenAI的Codex仍使用其特有的.codex-plugin结构，与新的开放规范并不完全一致，尽管其文档已开始引导兼容。这种过渡期的混乱表明，从标准发布到广泛落地，中间还隔着一条复杂的工程链。统一格式只是第一步，真正的互操作性需要客户端厂商在运行时进行大量的适配工作。
熟悉的配方：Anthropic的缺席与“影子标准”
仔细观察Agent Plugins 1.0.0的结构，熟悉Anthropic及其Claude Code插件系统的开发者会产生强烈的既视感。plugin.json作为根清单，skills/目录存放技能，mcp.json配置MCP服务器，以及根目录下指向插件目录的变量——这些元素与Claude Code长期使用的.claude-plugin体系高度相似。
事实上，Anthropic是最早跑通“插件=技能+MCP+清单”这一打包思路的公司之一。早在标准发布之前，Claude Code就已经实现了这一整套系统，且覆盖范围更广，包括技能、钩子、MCP、子智能体和斜杠命令的统一打包。Anthropic甚至建立了两个官方插件市场，形成了从格式到分发的闭环生态。
这次六巨头制定的规范，几乎是Claude Code插件系统的“最小可行性版本”（MVP）。它剥离了更花哨的私有扩展，只保留了最通用、最能促进互操作性的核心部分。微软的VS Code官方文档中，默认支持anthropics/claude-code插件，并兼容旧的.claude-plugin格式；OpenAI的Codex也专门保留了Claude的变量名以兼容现有插件。这些细节无一不在暗示：新标准在很大程度上“借鉴”了Anthropic已有的实践。
然而，作为这一玩法开创者的Anthropic，却在标准的共建者名单中缺席。这并非被排除在外，而是Anthropic一贯产品哲学的体现。该公司倾向于先将自己的产品打磨到极致，形成强大的闭环体验，再考虑是否参与行业标准联盟。这种“先建楼，再谈地基”的策略，使得Anthropic在每次行业级的握手时刻都显得尤为低调。
生态竞争的新高地：从底层规范到应用留存
Anthropic的缺席，或许预示着AI行业竞争重心的转移。当底层的基础设施标准——如插件的打包格式——逐渐趋于统一时，竞争必然向上游移动。底层的标准化降低了开发者的进入门槛，却同时也削弱了平台通过封闭格式构建护城河的能力。
这就好比商场的地基可以共用，但地基打好后，胜负取决于谁能提供更好的铺面、更精准的客流以及更丰富的商品。在AI智能体领域，这意味着竞争焦点将从“模型跑分”和“格式标准”，转向“插件生态丰富度”、“开发者体验”以及“用户留存率”。
六家巨头共同定义盒子，是为了防止生态进一步碎片化导致的整体萎缩。但对于单个平台而言，真正的护城河在于：当开发者使用统一的插件格式时，谁的客户端能提供更流畅的运行环境、更安全的执行沙箱、更广阔的分发渠道，从而将开发者和用户牢牢锁定在自己的生态系统中。
Anthropic选择继续经营自己的闭环，而非加入这场地基共建。这可能是一种策略性保留，也可能是一种风险对冲。一旦行业标准完全固化，缺乏早期标准参与度的公司可能会面临被动适应的局面。但也正如Anthropic所证明的，极致的产品体验本身就是一种强大的标准。在插件生态的博弈中，谁能让开发者第一个想到自己，谁能让用户感受到不可替代的价值，谁才是最终的赢家。
未来，随着Agent Plugins 1.0.0从草案走向成熟，我们有理由期待一个更加开放、互操作性更强的AI开发环境。但这并不意味着巨头竞争的结束，而是新一轮围绕生态主导权的更激烈角逐的开始。