软件分发原本只有两种主流颗粒度：一个是代码包（npm/pip/Docker），一个是 SaaS 帐号。最近半个月，我观察到第三种颗粒度正在固化下来——Plugin。OpenAI 给 Codex 加了 Plugin marketplace，Anthropic 在 Claude Code 上把 Plugin 升级成一级系统。两家的实现路径不同，但形状惊人地像。
下面这篇是我自己学习、动手拼、并且观察这套东西怎么发布的过程。
先把术语理清楚
这一层概念很容易混。我的理解是这样的：
- Skill：一个 Markdown 文件包，里面写着指令、流程、几条 few-shot 示例。Agent 加载它，就获得一种能力。
- MCP（Model Context Protocol）：Agent 接外部系统的标准协议。装上 MCP，就相当于给 Agent 接了一根数据线。
- Agent：可以被调度的执行体，可以定时、可以被事件触发。
- Plugin：把上面三样打包到一起、再加一个项目级的 CLAUDE.md / AGENTS.md 知识层，对外作为一个单元被分发。
最容易被误解的点是：Plugin 不是 Skill 的升级版。它和 Skill 不是同一层的东西。Skill 是能力，Plugin 是装能力的盒子。装上一个 Plugin，等于一键拿到了知识、能力、数据接入、自主调度这四样的完整套件。
两家的 Plugin 长什么样
我把 Anthropic 的 claude-for-legal 仓库和 OpenAI Codex 的 Plugin 文档放在一起看了一遍，骨架几乎是镜像的。
Anthropic 这边一个 Plugin 长这样：
commercial-legal/
├── .claude-plugin/plugin.json 身份信息
├── .mcp.json 数据层声明
├── CLAUDE.md 知识层（团队 playbook 模板）
├── skills/ 能力层
│ ├── review/SKILL.md 路由 Skill，自动派发
│ ├── nda-review/SKILL.md
│ └── ...
├── agents/ 调度层（定时/事件驱动）
│ ├── renewal-watcher.md
│ └── deal-debrief.md
└── hooks/hooks.json 生命周期钩子
Codex 那边是这样：
my-plugin/
├── .codex-plugin/plugin.json
├── skills/ Prompt 文件
├── .app.json App 连接器
├── .mcp.json MCP 服务器
└── assets/
不同点很少：Codex 把 App 连接器和 MCP 拆成了两个文件，Anthropic 都塞在 .mcp.json 里；Codex 在云端沙箱里跑（Seatbelt/Landlock/seccomp），Anthropic 跑在本地终端、用 hooks 做安全层。剩下的，身份、知识、能力、数据、调度，这五层两家完全对齐。
我个人觉得这种"结构同构、机制分歧"的状态很值得关注。它意味着 Plugin 形态已经稳定，剩下的是分发机制的竞争。
Anthropic 的几个细节我比较欣赏
第一个是配置路径与代码路径分离。Plugin 自己的 CLAUDE.md 是模板，用户配置写在 ~/.claude/plugins/config/<plugin>/CLAUDE.md。升级 Plugin 不会冲掉团队定制。这一条直接决定了 Plugin 能不能进企业环境。
第二个是 Router Skill 模式。用户只调用 /commercial-legal:review，路由 Skill 在 Plugin 内部识别文档类型（NDA、MSA、SaaS 协议），再派发给对应的专项 Skill。一个入口，多个实现。专项 Skill 标注 user-invocable: false，外部看不到，只能被路由调起来。
第三个是 Cold-start Interview。Plugin 首次安装时，由一个采访 Skill 引导用户填写 playbook、升级链、风格偏好，写入用户配置。后续所有 Skill 读取这份配置。这是 Plugin 区别于"复制粘贴几个 Markdown"的关键——它有自己的初始化协议。
第四个是 Scheduled Agent 必须显式声明工具白名单。比如 tools: ["Read", "Write", "mcp__ironclad__*", "mcp__*__slack_send_message"]，再没有别的权限。每个 Skill / Agent 还必须写"What this does NOT do"。法律行业对安全的要求把这一层逼了出来。
怎么自己拼一个 Plugin
我自己照着这个骨架试着拼了一个内部用的 gs-deployment Plugin。流程是这样的：
第一步，Fork 一个参考骨架。Anthropic 的 claude-for-legal 是目前最完整的官方样例，直接 fork 比从头写省两天。
第二步，写 plugin.json 把身份钉死。版本号、作者、依赖列表。这一步看似形式，但后面 marketplace 装载、依赖解析、token 预算都依赖它。
第三步，Cold-start interview 优先于任何 Skill。我的习惯是先写采集脚本（客户环境、技术栈、网络拓扑、SLA），把团队上下文沉淀进 ~/.claude/plugins/config/。这一步省了，后续 Skill 就是空对空。
第四步，Skill 分层。一个 Plugin 里至少要分"路由 Skill / 工作 Skill / 诊断 Skill"。工作 Skill 不暴露，只能被路由调用。诊断 Skill 单独成组，发生故障时由 Agent 自动调起来。
第五步，MCP 不要散落在全局。Plugin 自己的 .mcp.json 写清楚要哪些外部系统。这样别人装 Plugin 时一目了然，不需要去翻全局配置。
第六步，Agent 写工具白名单 + 显式负面范围。这一条我刚开始嫌啰嗦，后来体会到必要性：Plugin 一旦被多个项目复用，没有白名单就是定时炸弹。
发布和分发：5 天里变了什么
我大约 5 天前写过一份 Plugin 模式的内部分析，当时下了一个保守判断："Anthropic 还只有 GitHub 仓库，marketplace 估计要 3-6 个月"。结果不到一周，剧情完全变了。
Anthropic 这边：
- v2.1.108 起，Claude Code 一级支持
--plugin-url和--plugin-dir，自动安装package.json依赖。 - 加了
blockedMarketplaces配置键，企业可以禁掉未授权 marketplace。 /plugin浏览面板开始显示每 turn / 每次调用的 token 估算——Plugin 携带成本元数据了。plugin disable会拒绝拆掉被依赖的插件，enable会自动启用传递依赖。包管理器语义已经长出来。- 截至 5 月 16 日，公开 marketplace 一共 69 个，Plugin 总数 1163 个。
OpenAI Codex 那边：
- 3 月 27 日已经开放 marketplace，首批 20+ 个集成。
- 4 月 16 日一口气上线 90+ 个 Plugin：Atlassian Rovo、CircleCI、CodeRabbit、GitLab Issues、Microsoft Suite、Render、Box、Figma、Linear、Notion、Sentry、Slack、Gmail、Hugging Face。
- 分发分三档：官方 Plugin Directory、repo-scoped marketplace（项目内私有）、个人 marketplace。
- 企业治理用 JSON policy：pre-installed / available / blocked 三态。
- Codex 周活到 1.6M，GPT-5.3 发布后三倍。
repo-scoped marketplace 这一档我之前完全没预料到。它本质上是"项目内私有分发"，离"内部 SaaS"只剩一步。如果你选 Anthropic 栈想做等价的事，目前只能自己搭一个静态站 + manifest JSON 当 marketplace。
我自己的几个判断
Plugin 是 Agent 时代的"包"。npm 之于 JavaScript，pip 之于 Python，Plugin 之于 Agent。这一层一旦稳定，整个生态从手工坊进入工业化。
Domain Layer 还空着。Connector Layer（Slack/Figma/Linear/Notion 这类）已经被两家平台官方招安。Platform Layer（runtime、marketplace、沙箱）在 Anthropic 和 OpenAI 手里。真正没人占的是 Domain Layer——懂行业 know-how 的人把方法论封装成 Plugin 卖出去。Anthropic 用法律行业打了第一枪，金融合规、医疗临床、房地产、企业 IT 运维都还没有像样的玩家。
计量层会成为 Plugin 的第 5 层。原本我画的 Plugin 是四层（知识、能力、数据、调度）。Anthropic 把 token 估算挂进 marketplace 后，模型要补一层 metering——Plugin 装上后吃多少 context、多少钱，这是企业选型的下一个维度。早期没人在乎，晚期会变成技术债。
窗口期比想象中短。我 5 天前的判断是"3-6 个月垂直行业 Plugin 爆发"。现在我把这个数字改成"1-3 个月"。原因是 Connector Layer 已经被吃掉，Domain Layer 的窗口在 Platform 向上吞并的引力下持续收窄。
给团队的几个动作
如果你也在做内部工具集 / 内部 Skill 集，我建议尽早把它们重组成 Plugin 的形态。理由不是"赶时髦"，而是 Plugin 把"团队知识 + 能力 + 数据接入 + 调度"绑成一个单元，安装即完整这件事，本身就降低了团队内的沟通成本。
具体可以做的几件事：
- 先在团队内 fork 一份
claude-for-legal骨架，跑通安装、依赖、token 预算这三件事 - 把零散的 Skill 按 Plugin 结构重组，路由 Skill 当门面，工作 Skill 不外露
- 写一个 cold-start interview，把"新项目的上下文"沉淀进配置——这是 Plugin 最不容易被复制的部分
- 自建一个静态 marketplace（GitHub Pages + manifest JSON），等价 Codex 的 repo-scoped 能力
- 每个 Plugin 自带 token 预算估算，否则未来 marketplace 加 metering 时全是债
还在观察的几个信号
- Anthropic 是否跟进 repo-scoped marketplace
- 谁先开闸付费分发——两家都还没收费，谁先动，谁就重新定价整层
- 第一个 Domain Layer 跑出 ARR 的案例是哪个行业
- MCP 协议在 Plugin 里是平级还是从属，是被反向收编还是继续平等
- 30 天后 1163 / 90 这两个数字变多少——增速比绝对值更说明问题
剩下的，等下次写。
— toy