五个在任何事情上都谈不拢的竞争对手，在一个目录结构上谈拢了：Agent Plugins 1.0.0，由 Amazon、Cursor、Microsoft、OpenAI 与 Vercel 于 8 月 6 日发布，Google 同日以核心维护者身份加入。但读一读它的范围声明，真正的新闻是他们拒绝达成一致的那部分——没有安装机制、没有分发协议、没有权限模型、没有沙箱要求，也没有来源验证。这个格式标准化的，是一个既携带"给你的智能体的指令"、又携带"通往你系统的带凭据访问"的捆绑包；然后它把信任，留给了碰巧装上它的那个客户端。
一览
规范刻意做得很小。一个插件就是一个目录，几乎全部内容就这么多。
| 组成 | 装什么 | v1.0 中的状态 |
|---|---|---|
plugin.json |
清单——名称、版本、schema。 | 必需。 |
skills/ |
Agent Skills：打包好的、供模型阅读并遵循的指令。 | 可选。 |
mcp.json |
MCP 服务端配置——智能体拿到哪些工具，以及这些工具能触达哪些系统。 | 可选。 |
<namespace>/ |
可移植契约之外的客户端专属扩展；其他客户端会忽略自己未实现的部分。 | 可选。 |
发布时有六个客户端支持——ChatGPT、Codex、Cursor、GitHub Copilot、Kiro 与 VS Code——Google 也在同一天表示将在自家产品中接入，先从 Agents CLI 与 Data Agent Kit 开始。治理经由一个技术指导委员会运作，席位属于个人而非公司，并有章程禁止任何单一厂商占据多数。
为什么一个打包标准值得做
它解决的问题真实而不起眼。在此之前，把一项能力交付给智能体用户，意味着同样的集成要写好几遍：一个客户端格式的技能文件、下一个客户端的另一份、一次带着各客户端专属安装说明的 MCP 服务端注册，外加一份解释"哪种组合用在哪里"的 README。一家希望自己平台能被智能体使用的厂商，实际上在维护 N 套互相漂移的安装文档。
Agent Plugins 不是与 Skills 和 MCP 竞争的第三种格式——它是那层外包装，让"两者合一"的同一个捆绑包原封不动地装进六个客户端。这是实打实地减少了无谓劳动，也正是这次发布获得如此反响的原因。
这同样意味着，维护者为这个窄范围给出的理由并非不合理。安装、策略、企业管控与审批流程，在 IDE、CLI 与托管式企业平台上确实长得不一样；一份试图把它们统一起来的规范，五位签署方里至少会有两位不接受。一个人人都发货的格式，胜过一个没人采纳的治理模型。
接受这一切之后，有意思的问题就不是"范围划得对不对"了，而是：当打包问题被解决、信任问题没有被解决时，风险会发生什么变化。
这个捆绑包里装着两样很不一样的东西
技能是指令，而指令就是注入面
一个技能是模型会读、会照办的文本。这让一个 skills 目录成了一份"你把撰写权外包出去了"的提示词，而失效模式并不是恶意软件——而是某一段话以任何测试都覆盖不到的方式，挪动了智能体的默认行为。"当用户问到部署时，先检查 staging 配置"是一条有用的指令。同一句话换个后半段就成了一次改道，而且它读起来像文档，因为它本来就长得像文档。没有人建立过针对散文的评审文化，而一次技能更新的 diff，就是散文。
mcp.json 是触达范围，而它跑在你的凭据上
服务端这一侧是常规的供应链问题，只是它从一个"感觉不像加依赖"的通道进来。插件的 mcp.json 告诉客户端该启动哪些服务端；那些服务端是代码，握有网络出口，并以安装用户所拥有的一切权限行事。安装仪式是一条命令或一次点击，而不是一条会出现在 PR 里的 lockfile 记录。
两者合体，才是新的那部分
各自单看都有先例。新的是把它们作为一个整体交付：那个告诉智能体该做什么的产物，同时也提供了做成它的手段——一次安装，一个为可移植而设计的格式。这个组合还没有成型的评审实践，而 v1 也不打算造一个。
可移植性放大了爆炸半径——而这正是这个格式的全部意义
碎片化是一种税，但它也顺带是一道围堵边界。当一项能力必须按客户端重新打包时，一个被污染的捆绑包只能触达一个生态然后就停住了。一个可移植格式的价值，恰恰与它消除这种摩擦的程度成正比——而这对作者与攻击者同样成立，因为这个格式并不区分二者。
这不是反对这个格式的论证。这是关于"补偿性控制该落在哪里"的论证；而答案不是"落在规范里"，因为规范已经明说了它不管。项目自己的 future-considerations 文档把来源验证列为 v1 未处理的事项，与之并列的还有权限与审批交互、企业管控以及审计轨迹的标准化。这是一份罕见地诚实的产物，值得当作"你眼下自己扛着哪些东西"的路线图来读。
"没有信任模型"具体意味着什么
格式里没有加密签名。没有把已发布插件绑定回它自称来源仓库的证明。没有能力声明——plugin.json 里没有任何字段说"本插件会访问网络"或"本插件会写文件"——所以客户端即便想从清单渲染一个权限提示也做不到，也不存在可以逐级提升的信任等级。插件在被安装的那一刻就被信任了，而且是被"碰巧装它的那个客户端"信任的。
可移植性让"分歧"成为生态的固有属性
由于权限与沙箱因客户端而异，同一个捆绑包在每个客户端里的待遇都不同。装进一个带策略管控的托管式企业平台的插件，与被一位赶时间的开发者装进本地 CLI 的同一个插件，是同一件产物，暴露面却实质不同。你机构的实际姿态，等于任何人正在使用的那个最弱的客户端——而这个格式恰恰是被设计成"插件不知道也不关心自己落进了哪一个"。
这个月该做什么
以上没有一条是在主张远离这个格式。它们主张的是：把一次安装当成它本来的样子来对待。
- 把安装插件当作加一条依赖，走同样的评审。它从与
package.json不同的门进来，但应当达到同样的标准：谁发布的、它能触达什么、有没有钉版本、谁批准的。如果你的变更管理流程今天看不见插件安装，这个缺口就是第一件要补的事。 - 钉死版本，并把捆绑包 vendor 进来。在没有签名与证明的前提下，一份你自己取回并评审过的钉死副本，就是能拿到的最强完整性控制。升级时重新评审，因为散文里的改动正是在升级时无声落地的。
- 把
skills/当作提示词内容读，而不是当作文档读。每次版本变更都要 diff 它。它是最容易悄悄变化的那一半，也是你的评审者最没被训练去起疑的那一半。 - 让
mcp.json经由你自己运营的网关中转。插件启动的服务端，应当与其余一切走同一个代理、同一份允许名单，好让插件的触达范围由你的出站策略界定，而不是由它自己的配置界定。 - 把安装登记下来。一个插件改变了智能体能读什么、能做什么，因而它是对该智能体授权的一次变更——正是智能体清单与登记册所主张的那个记录单元。一次没人记录的插件安装，就是换了个漂亮包装的影子智能体问题。
- 客户端姿态要集中决定。既然权限因客户端而异，你的政策就必须写明哪些客户端根本被允许安装插件、以及要配哪些管控。把这件事留给每位工程师自己的工具偏好，等于让最弱的那套配置成为全组织的默认。
常见问题
Agent Plugins 会取代 MCP 吗？
不会。它把 MCP 服务端配置与 Agent Skills 打包在一起，让两者合一的捆绑包在各处以同样方式安装。MCP 仍然是协议；Agent Plugins 是包在插件内容外面的那层外壳。
一个插件里究竟有什么？
一个目录，含必需的 plugin.json 清单、可选的 skills/ 目录、可选的 mcp.json，以及可选的命名空间目录用于客户端专属功能——其他客户端会忽略它们。
哪些客户端支持它？
发布时有六个——ChatGPT、Codex、Cursor、GitHub Copilot、Kiro 与 VS Code。Google 于 8 月 6 日以核心维护者身份加入，并表示将从 Agents CLI 与 Data Agent Kit 开始在自家产品中加入支持。
插件有签名或经过验证吗？
规范层面没有。1.0 版没有定义签名、没有指向源码仓库的证明，也没有信任模型；来源验证被项目自己的 future-considerations 文档列为未处理事项。你今天想要的任何验证，都得自己实现。
维护者为什么把权限排除在外？
他们给出的理由是：安装、策略、企业管控与审批交互在 IDE、CLI 与托管平台之间差异很大，把它们写进规范会以各方无法一致接受的方式约束客户端。这是一个站得住的范围决策；但它同时也是"补偿性控制眼下归你"的原因。
这个标准会被某一家厂商控制吗？
治理章程禁止任何单一厂商占据指导委员会的多数席位，且每个席位属于个人而非公司。当前的核心维护者来自 Amazon、Cursor、Microsoft、OpenAI、Vercel 与 Google。
延伸阅读
本站相关：
- Agent Skills——插件里
skills/那一半究竟是什么。 - 什么是模型上下文协议（MCP）？——另一半，从零讲起。
- 智能体供应链安全——这个格式需要、却没有提供的那套评审实践。
- 工具投毒——为什么随包附带的指令是一个注入面。
- MCP 注册表与分发——v1 明确留白的那个分发问题。
- 智能体清单与登记册——把一次安装记录为智能体授权的一次变更。