Agent Plugins:一个插件通吃 Codex、Cursor、Copilot?

⭐ 设为星标 · 第一时间收到推送

一个插件通吃多个 Agent，“通吃”的其实是外壳

Agent 插件早就有了。麻烦在于，每家客户端都有自己的目录和清单。同一个 Skill、同一台 MCP Server，到了 Cursor、Codex 或 Copilot，常常要换一套摆放方式。插件作者维护的不是几种能力，而是几份相似的包。

Agent Plugins 1.0 就想削掉这层重复工作。它由 Vercel 发起，AWS、Anysphere、GitHub、Microsoft、OpenAI 和 Vercel 共同打磨。首批兼容 ChatGPT 与 Codex、Cursor、GitHub Copilot、Kiro 和 VS Code。

OpenAI 的发布视频把参与方摆在同一张画面里。阵容确实强，但它只证明这些客户端愿意识别同一种包装，没说插件进去之后会得到同样的待遇。

Agent Plugins 1.0 的主要参与方

一份包能被多个客户端识别，不等于一次安装就会出现在所有客户端里，也不等于行为完全一致。

三个文件，撑起 1.0 的可移植部分

这个标准很小。一个插件首先是一个目录，根目录必须有 plugin.json；Skill 固定放进 skills/；MCP Server 固定写在 mcp.json。

my-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
└── mcp.json

plugin.json 只要求两个字段：指向 1.0.0 Schema 的 $schema，以及插件的 name。版本、作者、仓库、许可证和关键词都可以加，但组件位置不能改，MCP 配置也不能直接塞进 manifest。

发布视频里的 hello-plugin 就是最小样板：一份根清单，加上固定位置里的 Skills 和 MCP 配置。

skills/ 下面的每个直接子目录，只要有 SKILL.md，就会被当作一个 Agent Skill。SKILL.md 怎么写、scripts/ 和 references/ 怎么组织，继续由 Agent Skills 规范负责。Agent Plugins 只管客户端去哪里找。

mcp.json 也不重写 MCP 协议，只统一连接配置。1.0 支持本地 stdio、远程 streamable-http，以及兼容旧实现的 sse。本地进程会拿到 ${PLUGIN_ROOT} 和持久化的 ${PLUGIN_DATA}；命令、工作目录和插件内路径不能借相对路径逃出插件目录。

组件会分开校验。某个 Skill 写坏了，客户端跳过它；某台 MCP Server 启动失败，其他 Skill 和 Server 仍可加载。这一点很务实：标准统一发现方式和失败边界，不把整个插件绑成一个非成即败的黑盒。

那些没写进标准的部分，才决定用户体验

Agent Plugins 官网把边界写得很直白。安装来源、商店、更新、缓存、启用流程、权限提示、信任策略、沙箱，以及 Skill 如何展示给用户或模型，全都留给客户端。

原因不复杂。Skills 和 MCP 已经有各自的规范，可以先做公共层；Hooks、Commands、Agents 和 Rules 仍与具体产品绑得太紧，1.0 没硬凑一个统一格式。

客户端专属能力可以放在反向域名命名空间里，例如 com.openai 或 com.cursor。支持它的客户端自己解释，其他客户端忽略。

这条边界上，已经有开源工具在从另一头补洞。代码采用 Apache License 2.0 的开源项目 AgentBro（agentbro.net），没有再造一份插件标准，而是把 Claude Code、Codex、Gemini、Cursor、Copilot 等客户端散落的 Hooks、Skills、MCP、插件和路径收进一个本地桌面控制台。它能把未纳管的 Skills 接进中心库，再用软链接或副本分发，也能扫描 MCP 和各家的插件配置。

两者处理的是同一个碎片化问题，位置不一样。Agent Plugins 让作者少打几份包；AgentBro 让用户少跑几个设置页。前者统一可移植格式，后者接住安装、管理和运行时的差异。目录标准只是第一步，用户仍需要一层工具，把分散的操作入口接起来。

我觉得这个设计很聪明，也有点暧昧。公共能力放进 skills/ 和 mcp.json，差异化功能仍留在各家的命名空间、商店和权限系统里。插件越依赖私有扩展，可移植性就越低；只用公共层，又可能放弃更强的原生体验。

安全问题也不能被“开放标准”四个字盖过去。规范会阻止插件内路径逃逸，要求远程 MCP 使用 HTTPS，也不允许把密钥写进可见的 headers 或 env 配置。但它明确说：这些路径规则不是进程沙箱。 插件能不能读仓库、调用外部服务、修改文件，最后仍看客户端的权限和执行策略。

这些公司为什么愿意坐到一张桌子上

它们分别掌握 Agent 客户端、开发者入口、云工具或插件分发能力，却碰到了同一个供给问题：插件作者不愿为每个客户端维护一份近似副本。

公共包装格式能让所有人的插件池变大，又没有要求谁交出商店、安装入口、企业策略、权限体验和用户关系。合作降低了插件作者的适配成本，产品差异还留在自己手里。这个交换很划算。

治理结构也做了多方制衡。当前技术指导委员会的 Core Maintainer 分别来自 Amazon、Cursor、Microsoft、OpenAI 和 Vercel；章程要求不能由单一厂商占据多数席位，提案和技术决策公开。Lead Core Maintainer 由 Vercel 的 Jonathan Hefner 担任。

Agent Plugins 初始技术指导委员会成员

不过，开放治理不等于平台力量消失。谁握着最大的客户端入口、默认安装渠道和企业采购关系，谁就更能影响开发者优先适配哪一层。规范把控制权摊开了一些，没有把它抹掉。

它会成为标准吗？先过三道门槛

第一道是覆盖面。首发阵容已经包含几个重要的编程 Agent，但 Anthropic 和 Claude Code 没在名单里。发布当天被检索到的几条开发者讨论反复问同一件事：如果一个主流客户端继续使用另一套格式，双线维护就还在。

第二道是分发。1.0 没有统一 Registry，也没有“一次发布，所有商店自动上架”。现在更可能出现的流程是：维护一份包，再分别去 Codex、Cursor、Copilot 或企业内部渠道安装、授权和更新。插件作者会轻松不少，普通用户未必马上有感。

第三道是语义一致性。同一份 SKILL.md 会被不同模型、上下文策略和工具系统执行；同一份 mcp.json 也会遇到不同的传输支持、鉴权和沙箱规则。“兼容”首先是能发现、能校验、能尝试加载，不是结果一模一样。

GitHub 上的 1.0.0 规范已经把目录、版本、组件发现、客户端扩展、环境变量和一致性要求写成完整契约。能不能再往上走，要看更多客户端是否加入，以及公共层能否一直克制，不被各家的私有扩展掏空。

Agent Plugins 1.0.0 规范与一致性目录