夜雨聆风前两篇我们看清了一件事：插件里的零件（尤其 SKILL.md 和 MCP）格式正在跨工具统一，但把它们打包成「插件」的那一层，还没统一。
这篇我们就直面这一层。先看四家工具各自的插件体系长什么样，再看那个号称要做跨厂商标准的 open-plugins 到底卡在哪，最后回答一个更硬的问题：这层为什么这么难统一？
答案可能和你想的不一样——不是技术做不到，是商业上没人愿意。
Claude Code：目前最成熟的一套。插件放在 .claude-plugin/ 目录，用 plugin.json（单个插件）或 marketplace.json（市场）描述。一个插件能打包 skills、hooks、subagents、slash commands、MCP servers。安装很方便，在 Claude Code 里用 /plugin 命令，从官方或第三方市场一键装。Anthropic 自己维护着一个官方市场 claude-plugins-official，仓库 3.2 万 star——这是目前 Agent 插件生态里最大的官方阵地 [来源：GitHub]。
Cursor：也有一套完整的体系。插件放在 .cursor-plugin/，有自己的官方 marketplace。Cursor 的特点是「rules」很强——用 .mdc 文件放在 .cursor/rules/，按文件类型（globs）自动触发。组件覆盖 skills、subagents、rules、hooks、commands、MCP，基本和 Claude Code 对齐。社区侧有 cursor.directory 这样的策展目录 [来源：cursor.com]。
OpenCode：路子和前两家不一样——它的原生插件是「代码式」的：一个 TypeScript 或 JavaScript 模块，启动时加载，靠订阅事件、注册自定义工具来扩展行为，比「目录式」更灵活。但 OpenCode 并不是只认代码插件：它同样支持 SKILL.md（官方有第一方的 agent skills 支持，按需加载），也认 AGENTS.md 作为项目指令 [来源：opencode.ai/docs/skills、opencode.ai/docs/rules]。
Codex：OpenAI 这边的体系，比想象中开放得多。Codex 同样认 SKILL.md——放在 .agents/skills/，用 $skill 显式调用，也有 $skill-creator、$skill-installer 这样的内置工具。更关键的是，Codex 有自己的一套完整 hooks 系统（hooks.json 或 config.toml 里的 [hooks]），事件覆盖 PreToolUse、PostToolUse、SessionStart、Stop、PermissionRequest 等，和 Claude Code 几乎一一对应。它还有自己的插件格式 .codex-plugin/plugin.json，能打包 skills、MCP 连接和 hooks。最值得一提的是：Codex 的插件会主动设置 CLAUDE_PLUGIN_ROOT、CLAUDE_PLUGIN_DATA 这两个环境变量——这是 Claude Code 插件的规范，Codex 刻意做了兼容。换句话说，OpenAI 在主动向 Claude Code 的插件规范靠拢 [来源：learn.chatgpt.com/docs/build-skills、learn.chatgpt.com/docs/hooks]。
给个总览表：
.claude-plugin/ | ||||
.cursor-plugin/ | ||||
.codex-plugin/ | ||||
它们其实长得有点像，但通不了
有意思的是，这四家的插件体系，正在越走越近。一个最直观的证据：SKILL.md 这个格式，四家都认——Claude Code 从 .claude/skills/、Cursor 从 .cursor/skills/、Codex 从 .agents/skills/、OpenCode 也第一方支持，格式一模一样，写一次四处都能被发现。Codex 甚至主动兼容了 Claude Code 的插件环境变量（CLAUDE_PLUGIN_ROOT），靠拢的意味很明显。
但「长得像」不等于「能互通」。真要做一个在四家都能装的插件，你会发现壳这一层还是各有各的：
• 目录结构各搞各的（ .claude-plugin/、.cursor-plugin/、.codex-plugin/，manifest 字段名也都不一样）• rules 这块各家格式不同（Cursor 用 .mdc，Claude Code 和 Codex 用各自的规范）• 安装命令和市场完全不同，互不相通
这些差异单独看都不大，合在一起就足以让「写一次、处处装」变成「每个工具改一遍」。
这正是「零件统一、安装包没统一」的具体表现：底层零件（SKILL.md、MCP）能跨工具流通，但外面包的那层「壳」各家都不一样。
插件里到底装了什么：不止 skills 和 MCP
要理解「壳」为什么这么难统一，得先看清一个插件里到底装了多少东西。
很多人对插件的印象还停留在「一个 skill + 一个 MCP server」。但真去拆一个成熟的插件包，里面的组件类型多得多，大致分两类。
一类是「能力组件」——直接决定 agent 能做什么：
• skills：可复用技能（SKILL.md）• commands：slash 命令• agents：专门化子 agent（subagents）• hooks：事件自动化（改完文件自动 lint、commit 前检查）• mcpServers：MCP 工具服务器• lspServers：语言服务器（代码智能）• rules：按文件类型触发的编码规范（.mdc）
另一类是「工程与资源组件」——让插件像一个可分发的软件包：
• assets：静态资源（logo、模板）• bin：打包的可执行文件• dependencies：依赖声明• userConfig/settings：用户配置与设置• themes/outputStyles：主题与输出样式• channels：分发通道• monitors：监控• apps：应用级集成
加起来十几种。这意味着什么？今天的 Agent 插件，已经不是「几个能力的松散集合」，而在向「一个完整的可分发软件包」演进——既要装能力，又要管依赖、配置、资源、主题、监控、分发通道。它的复杂度，正在逼近 npm 包或 VS Code 扩展。
这恰恰是「安装包层为什么统一不起来」最硬的原因之一。定一个 manifest 格式容易，但要同时标准化十几种组件的语义、加载方式、权限边界——每一家都觉得「这部分我有自己的做法」，谁也不肯让。S04 我会讲自己怎么用一张「支持矩阵」把这事管下来。
open-plugins：想做 Agent 圈的 npm，但没成
有人看到了这个「壳不统一」的痛点，想来做标准。这就是 open-plugins.com（对应的 GitHub 仓库在 Vercel labs 名下，叫 open-plugin-spec，canonical 域名是 agent-plugins.org）。
它的思路是：定义一个厂商中立的插件格式——一个目录、一个 manifest（plugin.json）、若干组件（skills、MCP servers，甚至 hooks/rules/agents），任何符合标准的工具都能装。听着很像 npm 要干的事。
它的规范做得挺认真，甚至有 RFC 2119 级别的严格 conformance 语言。官网还点名 Claude Code、Cursor、OpenCode 是「conformant host（合规宿主）」。
但现实是：它没成气候。 几个硬证据：
• 热度反差：同一个生态里，MCP 的 servers 仓库近 9 万 star，Claude 官方插件市场 3.2 万，Vercel 的 skills 工具 2.7 万，连 A2A 协议都有 2.5 万——而 open-plugin-spec 这个仓库，截至 2026 年 7 月连稳定 star 数据都查不到，还经历了一次仓库迁移 [来源：GitHub API，2026-07-25]。 • 「conformant」要打折扣：官网说三家工具是 conformant host，但这更可能是「这些工具的扩展模型恰好和标准格式兼容」，而不等于「这些工具官方宣布采纳这个标准」。两件事差别很大——前者是被动碰巧，后者是主动背书。 • 没有强分发渠道：MCP 能成，很大程度因为 Anthropic 全力推、且有官方 servers 做示范。open-plugins 背后是 Vercel labs（实验性项目），既没有 Anthropic 那样的号召力，也没有自己的分发渠道。
一句话：它方向对、规范也认真，但缺一个能真正推动生态的主导方。
为什么这层这么难统一
回到 S02 提过的那套逻辑——一个标准能成，要满足三条：有主导方、单一职责、是最小可统一单元。
第五层「安装包」一条都不满足。但更深层的原因，是这一层是厂商的商业边界。
想想安装包这层管的是什么：插件从哪装（市场）、装完能干什么（权限）、怎么治理（审核、签名、版本）、分发渠道在谁手里。这些每一项都直接关系到厂商的护城河和商业化。Claude Code 的官方市场是 Anthropic 的分发阵地，Cursor 的市场是 Cursor 的——谁愿意把这块标准化掉、让用户随便从别处装？
这点和零件层根本不同。MCP、SKILL.md 是纯技术协议和格式，厂商推它不损失任何商业利益，反而让自己的生态更开放、更有吸引力。但「市场 + 权限 + 分发」是生意，不是技术。
npm 为什么能成？因为 JavaScript 没有一个「想控制分发的厂商」——JS 是开放语言，npm 填的是真空。Agent 领域不一样，这里有 Anthropic、OpenAI、Cursor、Google 多个强势厂商，每家都想 own 自己的插件生态。在有多个强势玩家都想控盘的领域，自发的开放标准很难成[注：此为作者基于商业逻辑的分析判断]。
所以结论是：不是技术上做不到统一插件格式，是商业上没人愿意让出分发渠道。 这才是第五层卡住的真正原因。
那这层会一直碎下去吗
短期内，大概率会碎——厂商利益摆在那，没人主动让步。
但长期看，统一的压力在积累：用户想跨工具复用插件，作者不想每个工具改一遍，企业部署时要统一治理和安全审计。这些需求不会消失。
我的判断是：突破不会从「统一一个 manifest 格式」开始，而会从「registry + 权限治理」开始。 因为「从哪装」和「装完安不安全」是跨厂商都能受益的刚需——厂商有动机在这一层合作（比如共建一个可信 registry），而不会在这一层直接交出自己的市场。
至于完整的「统一插件模型」（标准 manifest + registry + 权限 + 签名 + 依赖），那是更远的事，需要这几件一起成熟。
在那之前，从业者怎么办？标准没来，又不能干等。下一篇，我会讲我在这个「半统一」的过渡期，是怎么在多个 agent 之间管插件的。
结尾
安装包这层之所以统一不起来，不是技术问题，是商业问题——它是厂商的分发阵地和护城河，没人愿意标准化掉。
认清这一点，你就不会把希望寄托在某个还没成的开放标准上，而是会去想：在这个过渡期，怎么用最小代价，在多个工具之间复用自己的能力。
下一篇，是我自己的一线做法。
关注「言午 AI 进化论」，下篇讲跨 agent 的插件管理实践。