AREX Feed Article
Agent Plugins 1.0.0 发布一周：Working Draft、没有信任模型、六种格式还在各自跑
2026 年 8 月 6 日，OpenAI Developers 在 X 上发了一条推文，宣布推出 Agent Plugins：一个与 AWS、Cursor、GitHub、VS Code 及 Vercel 共同开发的开放标准，将 Agent Skills 与 MCP 服务器配置打包为共享格式，实现"插件一次构建即可跨兼容的 agent 客户端通用"。 的推文获得超过 197 万次浏览和 6600 多个赞，Cursor 同日跟进确认支持。
五天过去了，更多细节浮出水面。规范页面写着 Status: Working Draft，GitHub 仓库没有 git tag 也没有 Release；Google 在同一天宣布以 Core Maintainer 身份加入技术指导委员会；v1 刻意回避了信任模型：安装即隐式信任；而 Cursor 和 OpenAI 各自仍然在维护自己更丰富的插件格式（.cursor-plugin/plugin.json 和 .codex-plugin/plugin.json），VS Code 的文档中也并列记载了四种 manifest 格式。Agent Plugins 解决了一个真实问题，但把最难的问题留给了未来。
一个目录、两个必填字段——其余全是可选的
Agent Plugins v1.0.0 定义的东西，用两句话就能说完。一个 plugin 就是一个目录，根目录下必须放一个 plugin.json，里面只有 $schema 和 name 两个字段是必填的。其余所有内容，skills 放在 skills/ 下、MCP 服务器配置放在 mcp.json 里，都从固定位置自动发现。写道，manifest 的 schema 是封闭的，只允许 10 个顶层字段，客户端必须忽略未知字段。plugin.json 不能重定位组件路径，也不能内联组件声明。
Google 开发者博客上用一句话概括了这个设计的核心克制："A plugin is a directory. That's the whole idea, and the restraint is the point."（插件就是一个目录。这就是全部想法，克制本身就是重点。） 上 Kevin Hou、Haoyu Wang 和 Alan Blount 联名写道，问题从来不在组件本身。Agent Skills 和 MCP 各自已经是可移植的，问题在"装组件的盒子"，而这个盒子之前每个客户端都得自己发明一遍。
规范限定了三种 MCP 传输方式：stdio、Streamable HTTP 和旧版 HTTP+SSE。环境变量只预留了两个：${PLUGIN_ROOT} 和 ${PLUGIN_DATA}。路径逃逸（../）被明确禁止，符号链接也只能指向插件根目录内部。失败隔离是规范级别的要求：一个 MCP 服务器启动失败不会拉垮同插件的 Skills，一个无效 Skill 只会被跳过而不会让整个插件不可用。
启动时兼容的客户端有五个条目，覆盖六款产品：VS Code、Cursor、GitHub Copilot、ChatGPT & Codex（合并为一条）、Kiro（AWS 的 agent harness）。 确认 AWS Agent Toolkit 已兼容，Kiro Powers 正逐步支持。
Status: Working Draft——但 README 说是 "current published release"
规范页面最上方两行字放在一起看，有一种没对齐的坦诚：Spec Version: 1.0.0，下一行 Status: Working Draft。
这不是笔误。 在 8 月 8 日检查了 GitHub tags API，返回一个空数组。仓库 README 同时将 Agent Plugins Specification 1.0.0 描述为 "the current published release"，但背后没有任何 git tag 或 GitHub Release。规范正文其实在 7 月 24 日就已经提交，比 8 月 6 日的联合公告早了将近两周。GitHub 组织本身更是 3 月 16 日就创建了。换句话说，8 月 6 日是一个协调过的公告日，不是创建日。
Agentic AI Foundation（AAIF）在 8 月 4 日就已经发了一篇 guest post 介绍这个格式，而 AAIF 自己的声明中还特意划清了一条线：Agent Plugins 不是 AAIF 项目，也没有提交过成为 AAIF 项目的提案。相比之下，MCP 是 AAIF 项目。Agent Plugins 打包 MCP，但本身不在 AAIF 的治理框架内。
许可证同样不简单。规范文本、文档、示例和图是 CC-BY-4.0；schema、源代码和脚本是 Apache 2.0。GitHub API 报告的仓库许可证是 NOASSERTION，正是因为这种拆分。
Google 同日入局，但发的不是客户端，是"插件生产者"
Google 在 8 月 6 日同一天宣布加入 Agent Plugins 技术指导委员会，由 Google DeepMind 的 Kevin Hou 担任 Core Maintainer。 列出了两个当天就支持该格式的 Google 产品：Agents CLI 和 Data Agent Kit。但这两个产品充当的是插件生产者：它们把 Google 的技能和 MCP 服务器打包成 Agent Plugins 格式供其他客户端消费，而不是作为客户端去加载第三方插件。
Digital Applied 指出，兼容客户端页面上并没有 Google。Google 发的是"我们做了插件给别人用"，不是"我们的 agent 能加载你的插件"。Google 在博客中写的是 "We expect to bring Agent Plugins support to more of our products"，从措辞看，这仍然是一个宣布出来的意图，不是已交付的行为。
相比之下，Anthropic 完全不在联盟内。这家公司创建了 MCP 协议和 Agent Skills 标准。Agent Plugins 打包的恰好就是这两样东西，但既不在技术指导委员会中，也没有在公告日发声。 特别指出了这一点。Anthropic 自己的 Claude 插件格式（.claude-plugin/plugin.json）仍然作为一等格式存在于 VS Code 中，即使 Anthropic 没有坐上 Agent Plugins 的桌子。
v1 没有信任模型，安装就是隐式信任
Agent Plugins v1.0.0 的未来考虑事项文档中，provenance verification（来源验证）明确标注为"未解决"。与此对照，VS Code 的文档写明，插件中的 MCP 服务器在安装时即被隐式信任，没有单独的启动信任提示。 的评价是："便携性先于信任基础设施出现，这扩大了潜在攻击面。"
规范本身两次明确声明机密信息不在范围内。header 值和环境变量值都被警告不得嵌入凭据。没有 OAuth 配置字段，也没有可移植的凭据引用字段：授权发现、用户交互和凭据存储全部留给客户端自行管理。
Google 在其博客中也坦率地列出了 v1 刻意不碰的领域：没有安装机制、没有分发协议、没有权限模型、没有沙盒要求、没有信任或来源验证、没有用户体验规范。这些不是悄悄省略的，而是公开命名为"未来考虑事项"。Google 的措辞是："This is the right call. Installation, policy, enterprise controls, and approval UX are quite different across clients."
六种格式共存——便携格式是地板，不是替代品
VS Code 的文档中并列记载了四种 manifest 格式：Agent Plugins 1.0、Copilot、Claude 和旧版 OpenPlugin。在 VS Code 之外，Cursor 有自己的 .cursor-plugin/plugin.json，OpenAI 的 Codex 有 .codex-plugin/plugin.json。 的统计是：六种格式，Agent Plugins 只是其中之一。
Vercel 的博客 把这件事说得很清楚：Agent Plugins 是一层加在现有格式之下的"互操作地板"，不是替代品。每个客户端仍然可以在自己的扩展命名空间（com.example.client/ 目录和 plugin.json 中 extensions 字段）里放任何客户端专用数据。这些扩展不在可移植合同之内，其他客户端直接忽略。Vercel 写道："A client-specific capability can remain client-specific until there is reason and consensus to standardize it."
提供了一个平行的视角：AAIF 还有一个"互补"项目叫 Skills Over MCP，走的是相反的路：把 Skills 捆绑进 MCP 服务器本身。用 AAIF 副总裁 Angie Jones 的话说，这就像"把说明书跟产品一起发货"。DevClass 的结语带着调侃："Should MCPs be festooned with skills? Or should each set of skills come with an attached MCP? Let the best approach win!"（该把 MCP 挂满 skills，还是该给每套 skills 配一个 MCP？让最好的方案胜出吧。）
规范已经为后续版本指名了七个可能的方向：hooks、sub-agents、commands 等，但没有任何一个承诺了发布时间。v1 标准化的只有 Skills 和 MCP 服务器，恰好是两个已有独立规范、各自已有可观采用量的组件类型。AWS 开源博客的措辞是 "The specification will evolve as the ecosystem identifies additional component types that benefit from portability"，会演进，但没时间表。
一个插件就是一个目录。两个必填字段。七项公开搁置的难题。Agent Plugins 1.0.0 的定义精确到可以被一个下午就实现，而那些真正区分"可用"和"安全"的东西：谁签了名、谁有权装、装了能碰什么，全部推到客户端一侧。这就是 1.0 的诚实之处：它把互操作问题拆到了最小的可解决单元，然后在通往真正生产的路上立了一块"施工中"的牌子。