你把一套可复用的 Skill 写好，又接上一个 MCP server。接下来却要为不同客户端重复安排目录、复制配置、解释安装步骤；一旦涉及密钥、审批或沙箱，差异更多。表面上看，这是“插件格式不统一”的问题；更深一层，它是在问：哪些东西真的可以随包携带，哪些必须留给运行它的客户端决定？
Agent Plugins 1.0 给出的答案很克制：它定义 Agent Skills 与 MCP servers 的可移植打包和发现约定，而不是定义一个统一的插件运行时。plugin.json、skills/ 与 mcp.json 可以跨支持该规范的客户端被发现；权限、信任、密钥、来源验证、沙箱、分发与客户端行为仍然各自负责。
这一区分决定了它真正适合解决的问题：少维护几份同一能力的包装，而不是承诺“一次打包，到处行为完全一样”。
过去为什么同一个能力要重复打包
在没有共同约定时，一个“给 Agent 增加发布检查能力”的扩展，往往被拆成几种彼此相近却不能直接互认的东西：某个客户端的 Skill 目录、一份 MCP 配置、另一份安装说明，以及平台专有的 hook 或 agent 定义。能力本身没有变，发现方式、配置入口和运行约束却各不相同。
AWS 对该问题的说明 很直接：作者需要为一个客户端适配、为另一个客户端重写，然后对每一种工具重复。Agent Plugins 的价值不是让所有 Agent 使用相同模型或权限系统，而是把“这个包里有哪些标准组件、应该从哪里找到”变成共同语言。
Agent Plugins 1.0 实际定义了什么
1.0.0 将一个插件定义为一个目录：根目录的 plugin.json 是唯一必需的 manifest；skills/ 中的子目录以 SKILL.md 表示 Skill；根目录的 mcp.json 描述 MCP servers。不存在某个组件目录不是错误，客户端可以只支持 Skills、只支持 MCP，或同时支持两者；对不支持的标准组件，客户端应忽略而不是把它解释成另一个运行时。
一个最小、符合规范的目录可以长这样：
release-helper/
├── plugin.json
├── skills/
│ └── release-check/
│ └── SKILL.md
└── mcp.jsonplugin.json 只承担身份和描述等 manifest 职责。最小示意如下：
{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "release-helper",
"version": "1.0.0",
"description": "Release checks for an agent client"
}这里没有把密钥写进 manifest，也没有把“允许执行什么命令”塞进统一字段。这不是示例遗漏，而是 1.0 的边界：它固定了可发现的组件位置与格式，不把客户端的安全和执行模型伪装成可移植事实。规范的仓库说明 将它定位为面向 Skills 与 MCP 的开放、厂商中立格式；MCP 的线协议仍由 MCP 自己定义，客户端如何把包内配置映射到本机行为仍可能不同。
图：上半部分是 Agent Plugins 1.0 可携带的包结构；下半部分是仍由客户端拥有的运行时决策。
可移植部分与客户端自有部分
| 层 | 可以共同约定的内容 | 仍需逐客户端确认的内容 |
|---|---|---|
| 包结构 | 根目录、plugin.json、skills/、mcp.json 的发现位置 |
从哪个目录、仓库或插件目录安装；是否允许远程包 |
| Skill | SKILL.md 的位置和包内组织 |
如何呈现给模型、是否自动调用、可见的上下文与工具 |
| MCP | 包内 mcp.json 的配置入口 |
传输支持、认证交互、连接生命周期和错误呈现 |
| 扩展能力 | extensions 的反向域名命名空间和顶层扩展目录约定 |
hooks、sub-agents，以及扩展内容、运行行为和具体失败语义由客户端定义 |
| 安全 | 可把配置作为包数据携带 | 权限、用户同意、信任等级、沙箱、网络、审计和密钥存储由客户端定义 |
最容易被忽略的是：1.0 已经统一了 extensions 的反向域名命名空间和顶层扩展目录约定；hooks、sub-agents，以及扩展内容、运行行为和具体失败语义仍由客户端定义。未来考虑文档还明确说明，1.0 并未定义信任模型、权限系统或沙箱要求，也没有可移植的秘密处理、存储或作用域机制；签名、来源证明、密钥注入、轮换、撤销、企业允许/阻止清单和审计都只是后续可能的方向，而非当前承诺。Future Considerations 本身也是非规范性文档：它说明问题空间，不等于已经交付的能力。
Codex 0.147 如何落在这条边界上
Codex rust-v0.147.0 发布说明 写明可以安装 portable Agent Plugins，并搜索本地、个人、工作区与远程插件目录。其对应实现 PR也落在对标准根目录 plugin.json 的识别与安装上。这是 Codex 对标准包的产品支持声明，不是 Omnihex 对多客户端兼容性的实测结论。
这里还要分清 Codex 的双格式路径。Agent Plugins 1.0 使用包根目录的 plugin.json，并以 mcp.json 作为标准 MCP 配置入口；OpenAI 当前的插件构建文档 则使用 .codex-plugin/plugin.json，MCP 使用 .mcp.json 或 .app.json。两套结构可以在同一个项目中共存，但属于不同约定，不能把目录或配置字段混写。官方插件支持页面目前还说明 Codex IDE extension 不支持插件；因此这里不能把终端/桌面端的产品支持外推到 IDE extension。
同一发布说明还有三项容易被过度解读的改动：
- Codex 可导入 Cursor-managed skills；这描述的是已有 Skill 的导入路径，不意味着导入所有 Cursor 配置。
- 对已导入的 Claude 与 Cursor conversations，同步的是这些已导入会话中的变更且避免重复；它不等于设置、账户状态或长期记忆的完整迁移。
--approve-for-me说的是自动审阅审批，不能写成无条件自动放行。
发布说明还提到陌生本地项目的显式信任、受管理认证限制，以及策略更新失败时的插件隔离与网络收紧。这些恰好说明：即使包的结构可以互认，实际启用、授权和隔离仍是客户端的安全策略，而不是 Agent Plugins 1.0 给所有客户端规定的统一行为。
Vercel 的首发支持名单列出 ChatGPT 和 Codex、Cursor、GitHub Copilot、Kiro 与 VS Code。Vercel 的发布文章 中没有列出 Claude Code；这只描述首发名单，不能推导为它永久不支持该规范。
四种角色，应该怎样用
独立开发者：先把重复的能力包起来
如果你的 Skill 指令和 MCP server 会在两个以上支持该规范的客户端之间反复安装，先做一个只含标准组件的插件根目录，能减少复制配置。真正接入前仍要逐个确认认证方式、网络权限与批准体验；“能被发现”不等于“可以安全执行”。
团队平台工程师：把共同层与适配层分开
团队可以把通用的 Skill、MCP 配置和版本信息放进 Agent Plugin；把身份提供方、密钥注入、私有 registry、日志与审批策略留在各客户端的适配层。这样迁移客户端时，复用的是能力包，而不是悄悄继承一套不相容的安全假设。
插件作者：不要把专有行为伪装成跨客户端能力
写作者可以把可移植的说明放在 skills/，把 MCP 的通用配置放在 mcp.json。若某个客户端需要 hooks、agent 定义或专有目录，应使用其客户端扩展机制并单独写兼容说明。把它们混进标准根目录，短期看方便，长期会让安装者误判兼容范围。
安全负责人：把“包可安装”和“包可信”分成两道门
来源校验、签名策略、依赖审查、允许的服务器、密钥作用域、网络出口与人工批准都应独立评审。标准格式降低了分发摩擦，却不会替组织做信任决策。一个能被 catalog 找到的包，不因此自动获得生产凭据或命令执行权。
什么时候值得采用，什么时候继续维护专用扩展
适合优先采用 Agent Plugins 1.0 的情形，是你的核心价值主要由 Skill 和 MCP 组成，并且团队愿意为每个目标客户端做最小接入验证。此时统一 manifest 和固定目录能直接减少维护面，版本也更容易对齐。
如果能力依赖 hooks、sub-agents、特定审批 UX、私有认证流程、强沙箱保证或企业分发控制，则仍应维护客户端专用扩展。不是标准失败，而是这些运行时契约尚未被 1.0 标准化。最稳妥的工程选择通常是：把公共部分做成 Agent Plugin，把不可移植部分显式留在适配层。
当前未实测的边界
本文没有安装或操作 Codex、Cursor、GitHub Copilot、Kiro、VS Code 或 Claude Code，也没有完成跨客户端实际安装、执行或权限行为测试。文中关于各产品的内容仅限官方发布与规范所述；它们不能替代你的客户端、版本、组织策略和网络环境中的验收。
结论是：Agent Plugins 1.0 让扩展包更可移植，但没有让插件运行时变成统一运行时。 对作者而言，最好的起点是先抽出共同的 Skills 与 MCP；对使用者而言，仍要把权限、信任、密钥和沙箱当作每个客户端自己的上线门槛。