六大巨头统一插件标准!一文看懂 Agent Plugins 1.0.0 的真相与局限

昨天一条消息在 AI 开发者圈子里传开了： AWS、Anysphere（Cursor 母公司）、GitHub、微软、OpenAI、Vercel 六家公司联合发布了 Agent Plugins 1.0.0 规范，谷歌也在发布当天加入了核心维护者名单。

这几家平时在 AI 编程和 Agent 领域打得不可开交，这次却在 插件格式 上签了同一份协议。要理解这件事为什么值得关注，得先说清楚之前的问题出在哪。

如果你给 Cursor 写过一个 Agent 插件，想让它也能在 GitHub Copilot 或 OpenAI Codex 里跑，大概率需要 重新打包一遍 。不是因为插件的核心功能有什么不同，而是每家的目录结构、配置文件格式、MCP 服务器声明方式都不一样。

本质上就是 包装盒不统一 。同一个插件，换个客户端就得换个壳。对插件开发者来说，这些重复适配工作既不产生新功能，也没有用户体验上的收益。

Agent Plugins 1.0.0 解决的就是这个 打包层面的碎片化 。规范给插件定了一个统一的目录结构：

根目录的 plugin.json 只有两个必填字段： $schema 和 name 。 skills/ 目录放 Agent Skills， mcp.json 描述 MCP 服务器的传输方式——支持 stdio、Streamable HTTP 和传统 HTTP+SSE 三种。

厂商自己的专属功能，比如特定客户端的 hooks 或斜杠命令，放在 反向域名命名的目录 里（如 com.example.client/hooks/ ）。这样其他客户端遇到不认识的目录可以直接跳过，不会报错。

这是很多报道一笔带过的部分，但对开发者来说可能 更重要 。

规范只统一了打包格式。 分发、安装、权限管理、沙箱隔离和用户体验 这些环节，仍然由各客户端自行决定。也就是说，你的插件目录结构虽然一样了，但它装到 Cursor 里和装到 Copilot 里，运行时的行为、权限和安全模型可能完全不同。

另一个没统一的是 传输协议的实际支持范围 。 mcp.json 虽然定义了三种 MCP 服务器类型，但哪些类型某个客户端真的支持，得看各家的实现。规范管的是“怎么声明”，不是“对方必须支持”。

对已经在写 Agent 插件的开发者来说，这个规范带来的变化是明确的：

以前为 N 个客户端维护 N 套打包格式，现在可以 合并成一套 。插件的核心资产——Skills 和 MCP Server 配置——只需要写一次。厂商特有功能隔离在专属目录里，互不干扰。

但也不必过于乐观。规范目前是 工作草案（Working Draft） 阶段，还不是正式版，后续可能会有调整。而且“统一打包”和“统一体验”之间还隔着安装流程、权限模型和沙箱机制这些没有标准化的环节。

如果你的插件目前只在单个平台上运行，暂时没有迁移的紧迫性。但如果你一直在为多端适配头疼，现在是一个 值得关注的节点 。

看完参与公司名单，很多人第一个反应是：Anthropic 呢？

Claude Code 的插件体系 在 Agent Plugins 之前就存在了，而且结构相当成熟。事实上，Agent Plugins 的目录结构大量参照了 Claude Code 已有的插件格式——VS Code 和 OpenAI Codex 都保持了对 Claude 原始格式的向后兼容。

Anthropic 没有参与这次联合规范。从公开信息来看，这家公司倾向于 独立运营自己的生态 ，先把自己的体系打磨到位，再考虑是否与外部标准对齐。这不算意外，但也意味着 Claude Code 的插件生态会继续保持独立的格式和分发渠道。

对开发者来说，如果你想同时覆盖 Agent Plugins 阵营和 Claude Code 阵营，目前仍然需要做两套适配。不过鉴于两者在目录结构上的高度相似， 实际工作量不会太大 。

Agent Plugins 1.0.0 走出了第一步，把打包格式统一了。接下来值得关注的几个方向：

规范何时从工作草案转为正式版；安装和权限管理层面会不会出现事实标准（某家客户端的做法被其他家跟）；Anthropic 会不会在某个时间点接入，还是继续走独立路线。

对于做 Agent 插件开发的同行，建议先关注规范的 GitHub 仓库和变更日志，了解正式版会有哪些调整。等规范稳定后再考虑 批量迁移 也不迟。