五大厂商联手发布 Agent Plugins 1.0，创建 MCP 的 Anthropic 却不在决策桌上

每个 Agent 客户端都在重新发明同一个插件

如果你在过去一年里给 ChatGPT、Cursor、GitHub Copilot 分别写过插件，你大概率把同一套逻辑重写了三遍。底层的 Agent Skill 指令是一样的，MCP 服务器的配置也没变，但每个客户端有自己的元数据格式、自己的目录结构、自己的发现路径。开发者被迫做一件没有信息增量的事：把同一个东西重新打包，只是为了让不同的客户端能识别它。

这个碎片化局面持续了至少一年。每个客户端都在各自的轨道上独立迭代——Codex 有自己的一套，Cursor 有自己的一套，Copilot 又有自己的一套。开发者社区里流传着一个自嘲式的共识："你写的第一个 Agent 插件永远不是插件本身，而是那个插件的第二个客户端适配器。"

直到今天，Vercel 攒了一个局。

Vercel 攒局：五家巨头共同推出 Agent Plugins 1.0

2026 年 8 月 6 日，Vercel 通过官方博客和 X 账号宣布 Agent Plugins 1.0.0 正式公开发布。这是一个开放、厂商中立（vendor-neutral）的插件标准，目标是用一个可移植的包格式取代当前各客户端的私有插件格式。

标准的技术指导委员会（TSC）包括 Amazon、Cursor、Microsoft、OpenAI 和 Vercel 五家 Core Maintainers。Vercel 发起了提案，来自 AWS、Anysphere（Cursor 母公司）、GitHub、Microsoft 和 OpenAI 的代表共同将提案打磨为 1.0.0 版本。项目采用开放许可，在 GitHub 上公开开发，治理规则和贡献流程全部透明。

首批兼容客户端覆盖了目前最主要的 AI 编程工具：ChatGPT 与 Codex、Cursor、GitHub Copilot、Kiro 和 VS Code。插件作者打包一次，即可在这些客户端之间无缝迁移。

Vercel 官方推文发布后迅速引爆社交网络：769 次点赞、149,000 次浏览、444 次收藏，引用推文超过 36 条。配合发布的是 Vercel 博客上一篇署名 Jonathan Hefner（Vercel 技术团队成员）的长文，以及 agent-plugins.org 官网上完整的规范文档、JSON Schema 和开发者指南。GitHub 仓库在几小时内收获 149 颗星。

极简到只剩一个文件夹——Agent Plugins 的技术内核

Agent Plugins 不重新定义 Agent Skills，也不重新定义 MCP。它做的只有一件事：给这两样东西一个统一的文件夹结构和一个最小的 JSON 清单。

一个最小的 Agent Plugin 长这样：

text

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

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

plugin.json 里最少只需要两个字段——$schema 指向规范版本，name 命名插件。除此之外的全部约定都体现在目录结构里。支持 Skills 的客户端去 skills/ 下发现 Skill，支持 MCP 的客户端读 mcp.json 获取服务器配置。客户端可以只支持其中一种组件，也可以两种都支持。一个组件验证失败不会影响另一个。

这种极简设计是故意的。Agent Plugins 1.0 刻意把范围限定在 "可移植的部分"：Skills 和 MCP 服务器。命令（commands）、钩子（hooks）、代理（agents）这些概念在不同客户端之间还没有一致的语义和安全模型，所以暂不纳入标准。规范用反向域名命名空间（如 com.example.client/）给单个客户端留出扩展空间，但这些扩展不在可移植合约之内，其他客户端会忽略它们。

用规范自己的话说："Agent Plugins 是插件作者和客户端之间的合约。这份合约现在已经定义好了，对双方开放以待塑造。"

换句话说，它解决的是打包问题，不是运行时问题。安装、权限、沙箱、用户体验、发行渠道、签名验证——全部留给客户端自己决定。这份克制是 Agent Plugins 和历史上那些试图包办一切最后什么都推不动的 "大而全" 标准之间最本质的区别。

AAIF（AI Application Infrastructure Foundation）在社区文章中用一个具体场景解释了这种分层设计的好处：假设一个 SRE 团队写了一个部署助手插件，Skill 部分描述了组织怎么准备发布、检查服务健康、安全回滚——这是死知识，不需要运行时状态。MCP 部分则把 Agent 连到真实的部署平台，获取部署状态、触发健康检查、执行回滚操作——这需要保持连接。Agent Plugins 把这两层打包在一起，客户端各取所需。一个团队成员可以在 Cursor 里加载这个插件做本地调试，另一个可以在 Codex 里用它做生产部署，同一个包里拿出来，不需要改任何文件。

OpenAI 的 Nick Cooper 在接受采访时总结了这个设计哲学："有用的能力应该能在 Agent 之间流转。通过构建一个共享的、开放的、易采用的标准，Agent Plugins 为整个 Agent 生态解锁了互操作性。这不仅给开发者留出了持续创新的空间，也让更多人能从他们构建的东西中受益。"

微软、OpenAI、AWS、Cursor 悉数入席，唯独缺了 Anthropic

这是整个发布中最值得细品的事实。Agent Plugins 打包的两样底层技术——Agent Skills 和 MCP——都是 Anthropic 创建的。

MCP（Model Context Protocol）于 2024 年 11 月由 Anthropic 作为开放协议推出，让模型通过统一的接口连接外部工具和数据。OpenAI 在 2025 年 3 月跟进支持，将其纳入 Agents SDK 和 ChatGPT。Agent Skills 则于 2025 年 10 月 15 日由 Anthropic 发布，用 SKILL.md 格式让模型读取结构化指令和工作流脚本。

现在，一纸 Agent Plugins 1.0 把这两项 Anthropic 创建的底层技术打包进一个分发格式——而决定这个格式怎么写的五人委员会里没有 Anthropic。

科技媒体 Temperature2 的 Adrian Iyer 在报道中直言不讳："委员会缺席比少了一个 logo 更严重。技术指导委员会决定版本规则、发现机制和合规客户端的定义，而这些规则将影响所有插件作者此后的构建方式。"

不过，Anthropic 的 MCP 负责人 Tobin South 在 X 上给出了一个出人意料的正面回应。他发推说："插件本质上就是一个文件夹——一个很好的文件夹。它们将变成所有东西的默认打包机制，包括 MCP、CLI、Skills、钩子等等。Claude 已经支持了，而且我们会支持得更好（很快）。这对所有人都是好事。"

South 的回应至少说明一件事：Anthropic 不打算在门外建一堵墙。Claude Code 尚未出现在兼容客户端列表中，但 "很快会支持得更好" 的表述暗示 Anthropic 可能会选择作为客户端适配该标准，而非另起炉灶。

这个局面和八个月前 OpenAI 采纳 MCP 的逻辑如出一辙。2025 年 3 月，OpenAI 同样没有在 MCP 的委员会里，但它在自己的 Agents SDK 和 ChatGPT 中支持了 MCP——因为开发者已经在用它连接数据库、浏览器和代码仓库，不支持就意味着丢掉生态。Anthropic 今天面临同样的选择题：Agent Plugins 能不能积累足够的开发者采用量，让 Anthropic 不得不跟？还是 Anthropic 会推一个以 SKILL.md 为中心的竞争性打包格式，把 MCP 留在自己的轨道上？

答案很可能取决于前三个月有多少现有 MCP 服务器主动加上 Agent Plugins 清单。社区里已经有人开始行动。Vue.js 核心团队成员 Justineo 在引用推文中写道："时间刚好。我本来把它发布为 Codex 和 Claude Code 的插件，现在它也很快会支持新的标准化 Agent Plugin 格式。" 如果像这样的人足够多，委员会有没有 Anthropic 就不再是一个有意义的问题。

开发者社区的反应，一半兴奋一半警惕

社交平台上的开发者反馈分裂成了两个阵营。

积极的一方看到的是效率提升。AI 基础设施公司 Leviathan 的创始人 Deva 评论道："标准化 MCP 是摆脱当前碎片化工具集成的唯一出路。把 Agent 能力与特定 IDE 解耦，对开发者效用的提升是巨大的。" 独立开发者 Francisco Moretti 说："如果你喜欢 Agents.md 和 Agents Skills，你也会喜欢这个。" ElevenLabs 开发者关系工程师 Tadas Petra 的评论更简短："很高兴看到 AI 工具周边正在形成标准。" 来自印度的全栈开发者 Daksh Tyagi 点出了最实际的收益："一次构建，跨多个 Agent 客户端部署，省掉的是无数小时的定制集成工作。"

Valentin De Matos（AI 工程师，前 EF 成员）则迅速给出了一个务实总结："一个文件夹、plugin.json + skills/ + mcp.json。Codex、Cursor、Copilot、Kiro、VS Code 都能读。安装和更新各自管。Claude Code 缺席。我的 symlinks 保留。"

怀疑的一方聚焦在两个问题上。一是供应商联盟能否代表真正的 "开放"。独立开发者 Gregor 评论道："一个供应商联盟写规范，这叫合作关系公告，不叫开放标准。真正的开放标准需要那些会对结果提出异议的参与方。" 二是安全问题。乌克兰安全工程师 Vyacheslav Ops 指出："一个通用的打包格式意味着一个恶意或被入侵的插件现在只需要一个目标格式就能攻击所有客户端，而不是五个。在 '一个插件跑所有客户端' 变成 '一次供应链攻击打所有客户端' 之前，值得看看规范里关于签名、来源和验证说了什么。"

还有人发了一张 xkcd 漫画——关于标准的经典笑话：已经有 N 个标准了，让我们再做一个统一它们。这条回复收获了 63 个赞，是最高赞的社区反应。

标准能不能成，不取决于委员会里有多少家公司

TechCrunch 级别的媒体没有发通稿，但开发者社区内部的讨论密度已经足够说明问题。Agent Plugins 踩在了一个真实痛点上：AI 编码工具的市场格局已经清晰，ChatGPT/Codex、Cursor、GitHub Copilot 三足鼎立，VS Code 是横跨所有这些生态的基础设施层。如果一个标准能让他们共享插件，开发者是买单的。

关键变量有三个。

第一，Anthropic 会入局吗？Tobin South 的推文释放了积极信号，但 "很快" 不等于 "已经"。如果 Claude Code 在三个月内出现在兼容客户端列表中，Agent Plugins 的生态位就基本确立。如果拖到半年以上，Anthropic 可能会推出自己的打包层，到时候就不是 "统一" 而是 "又多了一个"。

第二，供应链安全这关怎么过。规范 1.0 没有定义签名、来源验证或沙箱策略，这些目前全部丢给客户端。在 Agent 越来越深入文件系统和云基础设施的当下，安全不是一个 "以后再说" 的问题。Vyacheslav Ops 的担忧会被越来越多安全团队重提。

第三，Vercel 能不能放手。规范现在由 Vercel 发起并由 Jonathan Hefner（Vercel 员工）作为主要贡献者维护——GitHub 仓库中 76 次贡献全部来自他。chaliy 在 X 上的评论切中要害："这是必要的努力，但让 Vercel 做主要维护者感觉不太对。" 如果规范不能尽快吸引来自其他厂商的实质性代码贡献，它就会始终带着 "Vercel 的项目" 的标签，而不是 "行业的协议"。

Agent Plugins 1.0 最聪明的地方是它的克制。它不做大一统，只做 "可移植的最小公约数"。这份克制让它能在一天之内获得五家巨头的背书。但克制不是终点。

回到 Vercel 的那条推文——769 次点赞、444 次收藏——开发者用大拇指投了赞成票。从 Cursor 的 Matt Palmer 简洁回复 "nice"，到 Anthropic 的 Tobin South 说 "这对所有人都是好事"，行业内最懂 Agent 的这群人不约而同选择了正面回应。这说明痛点足够真，方案足够简单，时机也足够对。

剩下的事不在规范文档里。当第一个跨客户端的安全漏洞出现时，当 Anthropic 做出最终选择时，当第一个大客户要求插件供应商签名时，这份刻意回避了安全、发行和信任机制的 1.0 规范，需要长出它今天说不属于自己范围的那些能力。到那一天，委员会有没有 Anthropic 或许不再是问题——真正的裁判是那些已经在 skills/ 目录下写 SKILL.md 的开发者。

参考链接：