Agent Plugins 1.0：一种适配所有 AI 智能体的打包格式

什么是 Agent Plugins？ Agent Plugins 1.0 是一项于 2026 年 8 月 6 日发布的开放、厂商中立的打包标准，它把 Agent Skills 与 MCP 服务器配置捆绑进一个可移植目录，任何兼容的智能体客户端都能加载。一个插件就是一个文件夹：必需的 plugin.json 清单、可选的存放 Agent Skills 的 skills/ 文件夹，以及可选的用于声明 MCP 服务器的 mcp.json。发布之初，ChatGPT、Codex、Cursor、GitHub Copilot、Kiro 和 VS Code 均已支持。¹²

六家每天都在彼此竞争的公司，为一个所有智能体用户都感受过的问题给出了同一个答案：你为某个智能体客户端做的扩展，换一个客户端就用不了。提案由 Vercel 发起，规范则由其与 Amazon、Anysphere（Cursor 的开发商）、GitHub、Microsoft 和 OpenAI 共同制定；² Google 在同一天宣布加入核心维护者行列，并已着手在自家产品中提供支持。⁶ 官方网站的一句话概括是：“一种可移植的打包格式，用于扩展 AI 智能体的可复用组件。”¹

被打包的这两层，恰恰出自一家名字并不在维护者名单上的公司。这份缺席是故事的一半，也是本文后半部分的主题。

摘要： Agent Plugins 1.0 标准化的是围绕两项既有规范——Agent Skills 与 Model Context Protocol——的打包层，它并不取代其中任何一个，只是确定了两者在一个可共享目录中的位置。¹ 插件就是一个文件夹：plugin.json 负责身份标识，skills/ 存放技能，mcp.json 声明服务器，再加上用于客户端专属内容的反向域名命名空间目录。第 1 版有意只做到互操作的地板线：规范没有为安装、注册表、权限、来源溯源、密钥或 OAuth 定义任何可移植语义，这些全部交由客户端自行管理。¹² Codex 在 v0.146.0 与 v0.147.0 两个版本中完成了支持。⁴ 创造了 Agent Skills 与 MCP 的 Anthropic 并不在维护者之列，Claude Code 仍保留自己的插件格式。³⁷⁸

关键要点

• 独立开发者： 把技能写成标准 Agent Skills（一个含有 SKILL.md 的文件夹），它本身就已经是可移植的底层材料，再包成插件也只差一份清单。别再为每个客户端各维护一份副本了。
• 技术负责人： 该标准覆盖的是打包，而非分发或策略。注册表、更新机制、白名单方案依然是各客户端各自的决定。在内部许下“一次编写、处处运行”的承诺之前，先把这部分工作量算进去。
• 安全工程师： 第 1 版既没有溯源层，也没有权限层，更没有签名层，信任判断被整体推给了安装时的人工审查。可移植性越强，被投毒技能攻击的波及面也就越广。

已经落地的部分

2026 年 8 月 6 日，Vercel 发布了 Agent Plugins 1.0.0——一份由其发起、并与 Amazon、Anysphere、GitHub、Microsoft 和 OpenAI 共同制定的开放规范。² 规范正文托管在一个公开仓库中，维护者名单横跨 Amazon、Cursor、Microsoft、OpenAI 和 Vercel；³ Google 则在发布当天宣布以核心维护者身份加入该团队，支持能力已在陆续进入其自有智能体工具链。⁶

首批客户端名单覆盖了生态中最大的几个入口：VS Code、Cursor、GitHub Copilot、ChatGPT 与 Codex，以及 Kiro。¹² Codex 的 CLI 支持实际上早于公开宣布：v0.146.0（7 月 29 日）加入了 Agent Plugins 清单与工作区插件发布，v0.147.0（8 月 7 日）补齐了可移植插件安装，以及横跨本地、个人、工作区和远程目录的搜索。⁴

适用范围写在规范开篇第一句里：该文档“定义了正式的 Agent Plugins Specification v1.0.0，用于把扩展 AI 智能体的可复用组件打包成可分发的插件”。¹ 是打包，而不是一门新的技能语言，也不是 MCP 的替代品。底层这两种格式各自保留自己的规范；这项标准确定的，只是它们在客户端能够发现的目录中所处的位置。

插件的结构

插件是一个目录，包含一个必需文件和三个可选部分：¹

my-plugin/
├── plugin.json              # required: identity + metadata
├── skills/                  # optional: Agent Skills
│   └── release-notes/
│       └── SKILL.md         # one immediate subdirectory = one skill
├── mcp.json                 # optional: MCP server configs
└── com.example.client/      # optional: client-namespace directory

plugin.json 是一份封闭模式的清单。顶层允许的字段恰好十个：$schema、name、version、description、author、homepage、repository、license、keywords 和 extensions；对其余一切，规范措辞相当严格：“客户端必须（MUST）报告并忽略每一个未知字段，且只要清单在本节其他方面合规，就必须（MUST）继续加载该插件。”¹ name 字段允许小写字母数字、连字符和句点，首尾必须是字母数字，且不得出现连续的连字符或句点。¹

skills/ 原封不动地承载已有形态的 Agent Skills：“每个直接子目录，只要其中名为 SKILL.md 的路径解析为一个常规文件，就被视为一个技能。”¹ mcp.json 用于声明 MCP 服务器；支持插件内 MCP 服务器的客户端“必须（MUST）至少支持 stdio 或 streamable-http 其中之一”，并且应当（SHOULD）两者都支持，sse 则为可选。规范还明确允许仅支持技能的客户端在完全不支持 MCP 服务器的情况下满足合规要求。¹

com.example.client/ 这类反向域名目录用于承载客户端专属行为，可移植性规则以规范性措辞写明：“对于自己未实现的命名空间，客户端必须（MUST）忽略其清单条目，且不得校验这些条目的取值内容。”¹

最后这个机制的分量比表面上重得多。各客户端之间差异最大的组件，被挡在了可移植内核之外：命令、钩子、子智能体、规则和 LSP 服务器，正是规范自己举出的那类“对稳定的可移植契约而言仍过于依赖具体客户端”的组件类型，在各自格式收敛之前都留在第 1 版之外。¹ 可移植内核就是技能加 MCP 配置，仅此而已。

第 1 版刻意留白之处

这份规范只标准化了能够跑通的最小集合。它没有为安装、注册表、权限、来源溯源、密钥或 OAuth 定义任何可移植语义，这些全部仍归客户端管理¹²，也没有定义签名层。维护者规划的扩张路径在设计上就是保守的：某类组件只有等到各家实现收敛到足以被精确定义时，才会被提升进可移植内核。¹

与其把这看作胆怯，不如理解为联盟的力学。六家公司——其中五家都在出货带有互不兼容插件格式的智能体客户端——能够达成一致的，只是文件放在哪里；至于钩子如何触发、命令如何注册、谁的权限模型说了算，他们还谈不拢。于是标准把行为已经收敛的那一层冻结下来（技能是 Markdown 文件夹，MCP 是线路协议），把所有有争议的部分圈进命名空间。这是一块互操作的地板，而地板之所以有用，恰恰因为所有人都能站上去。

这块地板的代价是：“一次构建、处处运行”适用于包，而不是体验。插件到哪里都能装，但它能做什么依然因客户端而异，如何安装、更新与被信任更是完全由客户端决定。

一个 Anthropic 形状的空缺

奇怪的地方在这里。被这项标准打包的 Agent Skills——那种以文件夹承载指令的格式——出自 Anthropic 之手，2025 年 10 月发布。⁸ Model Context Protocol 同样如此，Anthropic 于 2024 年 11 月将其开源。⁷ 这项打包标准之下的两层，都来自同一家主流智能体工具厂商，而它的名字在维护者名单上遍寻不见。³

Claude Code 保留着自己的插件格式——自己的清单、自己的市场源、自己那套钩子与命令的打包方式——8 月 6 日发布的任何内容都没有改变这一点。目前的桥接是单向的：Codex 内置了 Claude Code 市场源（v0.146.0），其 /import 命令可以把 Claude Code 的设置、MCP 服务器、插件、会话、命令和项目级记忆迁移进 Codex。⁴

从实操层面看，这道接缝比组织架构图暗示的要窄，原因就在底层材料上：无论在哪个生态，技能都是一个含有 SKILL.md 的文件夹。你为 Claude Code 写的技能，与 Agent Plugin 所承载的是同一件产物。真正无法迁移的是外包装——一边是 Claude Code 的插件清单，另一边是 plugin.json——以及各生态各自原生保留的客户端专属组件（首当其冲是钩子）。如果你今天在维护技能，那你其实已经在写可移植的那一层；分叉发生在打包，而不在内容。

Anthropic 最终会采纳这一格式、发布一个对等方案，还是任由这座桥保持单向，正是这次发布抛出的开放问题。联盟的构成——除一家之外的所有主流智能体客户端厂商悉数在列——意味着这项打包标准的走向，取决于其两层底座的缺席作者是否认为这块地板值得站上去，而不太取决于技术优劣。

无人标准化的供应链问题

一种没有溯源层的可移植打包格式，同时也是一种可移植的攻击格式。第 1 版把溯源与权限交由客户端管理，也没有定义任何签名或校验工具，¹ 这意味着信任判断完全落在安装那一刻，落在每个客户端、每个用户身上。

这件事在本月比上个月更要紧。近期关于技能层面攻击的研究——ElasticBack 是其中最锋利的例子——演示了植入单份技能文档的条件式后门，并把智能体技能界定为“一条正在成形的供应链，其中一份被投毒的技能就能持续危害每一个安装它的智能体”。⁵ 可移植性把这一风险成倍放大：同一个被投毒的插件如今装进的是六个客户端而不是一个，而标准的范围又把检测留给了各客户端（或各用户）自行审查。

在这项标准出现之前，我在Agent Skills 需要包管理器一文中做过更完整的论证：智能体上下文已经成为一条软件供应链，安全地安装它需要包生态早已学会构建的那套机制——清单、锁文件、限定作用域的安装、审查关卡、回滚。Agent Plugins 1.0 给出了清单，然后就停下了；清单之外的那些，恰恰是第 1 版留给客户端的部分。安装什么，就自己检查什么，格式不会替你代劳。（我的智能体看不见的技能一文里还有一个相邻的坑：智能体是在严格的上下文预算下加载技能描述的，插件附带的技能也会进入同一份目录清单——可移植性等于往一个本就会悄悄被截断的队列里继续塞技能。）

今天可以做什么

如果你用 Codex： 标准已经在你手上了。codex plugin 提供可移植的 Agent Plugins 安装，自 v0.147.0 起，插件搜索横跨本地、个人、工作区和远程目录。⁴ 团队可以把插件发布到自己的工作区，而不必去搭一个公开市场。

如果你用 Claude Code： 你的插件格式毫无变化。继续用标准技能文件夹的形式写技能——那才是可移植的一层——把外包装当成可弃之物。如果你同时也跑 Codex，它的 Claude Code 市场源和 /import 能把你现有的配置带过去。⁴

如果你用 VS Code、Cursor、Copilot、ChatGPT 或 Kiro： 你在首批客户端名单里；插件如何安装取决于你所用客户端的交互设计，因为标准有意不去规定这一点。¹

如果你在做开发者工具： 这份清单小到一个下午就能接入，规范仓库也是公开的。³ 真正值得琢磨的决定不是要不要读取 plugin.json，而是把自己的哪些组件圈进反向域名命名空间——那条边界事实上就是你对“什么算可移植”的公开表态。

常见问题

Agent Plugins 会取代 MCP 或 Agent Skills 吗？

不会。规范自陈的职责是“把扩展 AI 智能体的可复用组件打包成可分发的插件”¹——技能保留 SKILL.md 格式，MCP 服务器保留自己的协议，标准确定的只是两者在可共享目录中的位置。

插件能分发钩子、斜杠命令或自定义智能体吗？

在第 1 版里，无法以可移植的方式做到。规范点名命令、钩子、子智能体、规则和 LSP 服务器，作为“对稳定的可移植契约而言仍过于依赖具体客户端”的组件类型示例，在其形态收敛之前都被排除在可移植格式之外。客户端可以把它们放进自己的反向域名命名空间目录，而对未实现的命名空间，客户端必须（MUST）忽略。¹ 可移植内核是技能加 MCP 配置。

Anthropic 为什么没有参与这项标准？

规范方与联盟方都未作说明。已公开的事实是：维护者名单横跨 Amazon、Cursor、Microsoft、OpenAI 和 Vercel，Google 在发布时加入，³⁶ 而同时创造了 Agent Skills 与 MCP 的 Anthropic⁷⁸ 缺席，Claude Code 保留自己的插件格式。当下切实可用的桥梁在 Codex 一侧：它的 Claude Code 市场源与 /import 迁移。⁴

安装第三方 Agent Plugins 安全吗？

这个格式帮不上你判断：第 1 版把权限与溯源交由客户端管理，也没有定义签名或校验工具。¹ 请把插件当作任何一段你授予自身权限的代码来对待。技能层面的后门研究（ElasticBack）表明，一份被投毒的技能文档就能有条件地危害每一个安装它的智能体，而可移植性会把这个安装基数成倍放大。⁵

参考资料