AI智能体插件包装盒统一了，但真正的难题才刚刚开始
2026年8月6日，一份名为Agent Plugins 1.0.0的开放规范正式公开。AWS、Anysphere（Cursor母公司）、GitHub、微软、OpenAI、Vercel六家公司罕见地坐到同一张桌子上，共同起草并签署这份规范，谷歌也在发布当天追加为核心维护者。
这份规范要解决的是一个被开发者吐槽已久的问题：同一个技能或MCP服务器，内核明明一样，却要为Cursor、GitHub Copilot、Codex等不同客户端重复打包；哪家客户端一更新，就得跟着改一遍。Agent Plugins的目的，就是给AI智能体的插件定一个统一的「包装盒」，让一份包可以走天下。
这份规范到底管什么
一个典型的智能体插件，通常由两部分组成：Agent Skills（给模型用的可复用指令和资源）和MCP Server（连接外部工具和服务的接口）。这两部分本身已经可以跨客户端复用，真正卡住的是最外层——每家客户端的目录结构、清单文件、MCP配置写法都不一样，同一个组件换个客户端就得重新打一次包。
Agent Plugins统一的就是这一层。它的结构非常简洁：
- 根目录放一份`plugin.json`清单，作为插件的身份证
- 技能全部放进`skills/`目录
- MCP配置写进`mcp.json`
清单里只有$schema和name两个字段是必填的，其余一切靠固定目录位置去找，客户端不用猜，连版本号都可以不写。各家想夹带的私货——比如自己特有的钩子、命令、界面——统统丢进一个用反向域名命名的目录里，别的客户端扫到了会直接略过，这样公共层就保持了干净和小巧。
用一句话概括三者的关系：Agent Skills管指令，MCP管连工具，Agent Plugins管把这两样装进同一个包装盒。
它管得很少，也很克制
1.0版本只认两类可移植组件：skills/里的技能，和mcp.json里的MCP配置。hooks、斜杠命令、custom agents这些各家独有的能力，统统没被纳入，仍由各家客户端自己做。规范正文目前还标着「工作草案（Working Draft）」，离成熟的行业标准还有距离。
这种克制的设计带来一个直接的好处：实现门槛低。规范只要求识别固定目录和两份清单文件，客户端不需要理解复杂的逻辑，因此理论上任何现有的插件客户端都可以较低成本地兼容这套格式。
一次打包，不等于到处运行
这是开发者最容易高估的地方。包装盒统一了，但运行远没有跟着统一。
规范明确只管skills和mcp.json这两类组件的外壳，一旦到了真正运行的层面，它就撒手了：安装、分发、权限、沙箱、认证、信任验证、用户体验，一样都不管，全留给各家客户端自己做。
更具体地说：
- 各家客户端对MCP传输方式（stdio、Streamable HTTP、旧版HTTP+SSE）的支持并不完全一致，同一个插件换个客户端能不能顺利跑起来，还要看具体情况。
- OpenAI自家的打包文档目前仍在使用
.codex-plugin/plugin.json结构，和开放规范的根目录plugin.json不是同一套，迁移需要时间。 - 微软在文档中专门提示安全风险：插件里的MCP Server和hooks会在用户本机执行代码，安装前务必看清来源和作者，社区市场里的内容尤其要当心。
因此，打包统一不代表运行统一，中间还隔着一整条工程链。这是从规范到落地之间最容易被忽视的鸿沟。
熟悉的配方：和Claude Code几乎一模一样
熟悉Claude Code插件的人会立刻发现：plugin.json、skills、mcp.json——这不正是Claude Code一直在用的那套吗？
事实上，在这份标准出现之前，Anthropic就已经为Claude Code做好了整套插件系统：根目录放.claude-plugin/plugin.json，配上skills、mcp.json、commands、agents，还开了两个官方插件市场供用户分享。「插件等于技能加MCP加一份清单」的打包思路，Anthropic是最早跑通的之一，而且它那套还更全——技能、钩子、MCP、子智能体、斜杠命令，一整包全打进去了。
这次的新标准只收了能通用的两块，其他更花哨的部分没进来。有几个细节很说明问题：
- Claude Code有一个专门指向插件目录的根变量，新标准原样搬了过来，只换了个名字，作用完全一样。
- 微软的VS Code官方文档里，默认插件市场就有
anthropics/claude-code这一项，一边支持新的开放格式，一边继续认Claude格式的.claude-plugin/plugin.json。 - OpenAI的Codex更直接，连Claude原来那个变量名都专门留着，目的就是兼容已有的Claude插件。
换句话说，六家公司坐在一起，统一了一套「非常像Claude Code」的格式，但开创这个玩法的Anthropic全程不在场。
为什么缺席本身就是一个信号
Anthropic的缺席并不等于被排除在外。谷歌新推的两套工具都把Claude Code列进了适配对象，Anthropic自己仍运营着两个官方插件市场。
更准确的解释是，Anthropic一贯倾向于先把自己那套打磨到极致，再考虑是否与外部对齐。这样做的好处是产品自成体系、用户体验统一，代价是每一次行业级的握手场合，它都容易成为最显眼的缺席者。
这次它没坐上统一标准的桌，而是继续经营自己那一整套从格式到市场、再到分发的闭环。可以理解为：当底层标准一旦谈拢，竞争就会上移一层——商场的地基可以几家合起来打，可地基一落定，要竞争的就变成了楼上的铺面和货架，那是各家公司自己的地盘。
落地实践：开发者现在该做什么
对于正在或打算做智能体插件的团队，几点具体建议值得参考：
- 可以开始按新规范打包，但不要押注单一形态。新规范目前仍是工作草案，未来目录结构和清单字段可能调整；同时OpenAI自家的打包格式还没并轨，跨平台兼容需要适配层。
- 核心代码与清单解耦。把技能逻辑、MCP配置、外壳清单分离，这样无论将来规范如何演进，核心资产都能复用。
- 传输方式提前兼容。建议MCP服务器同时支持stdio和Streamable HTTP两种传输方式，覆盖更多客户端。
- 来源和签名机制务必自建。规范不解决信任验证问题，社区市场也不会替你背书，特别是涉及本机代码执行的hooks和MCP Server，建议在团队内部建立来源审查和签名校验流程。
- 关注Claude格式兼容路径。如果目标用户已经在使用Claude Code插件生态，保留对
.claude-plugin/plugin.json格式的兼容能力，会比纯押注新规范更稳妥。
这只是开始
六家公司这回把盒子的规格定了。但决定胜负的不是盒子，是里面装的智能体——谁能靠它把开发者留在自己身边，谁才是赢家。在hooks、custom agents、应用市场、权限体系这些更值钱的层面，各家仍未交出自己的地盘。规范解决的只是最不敏感的那一层，真正的博弈才刚刚进入下一轮。