Vercel发布Agent Plugins 1.0：AI Agent互操作标准成型

本月早些时候，Vercel 发布了 Agent Plugins 1.0.0，核心维护者来自 AWS、Cursor、Microsoft 和 OpenAI。当天 Google 也宣布加入。这一定义解决了一个真正令开发者头疼的问题：一个 skill 和一个 MCP server 各自运行良好，但只要你想把它们发布到第二个客户端，就不得不 fork 一份并维护两份。

尽管六家公司就组件存放位置达成了共识，但并未统一它们的行为规范。规范的第 7.1 节将 skill 格式交由 Agent Skills 规范来定义；第 7.2 节则将传输行为和生命周期交由 MCP 负责。这两套规范均出自 Anthropic之手，它以开放方式发布，但并未参与指导委员会。

项目自身对这一点毫不讳言。其文档坦然承认，成果只是一个"小型的互操作性底线"，Google 的公告也将 v1 描述为"包格式"而非更多。显而易见的分歧并不在于宣传话术与技术事实之间的矛盾，而在于"兼容""可移植""插件"这些词汇在日常使用中暗示的东西，远超这一狭义协议实际能提供的。

Anthropic 发布了什么，发布给了谁

Anthropic 于 2025 年 12 月 9 日将 MCP 捐赠给了 Agentic AI Foundation（一个由 Linux Foundation 主导的基金）。Agent Skills 则在九天后跟进，作为开放规范发布，现已在 agentskills.io 上公开开发。两者的治理故事各有不同：MCP 归属于一个独立基金会，而 Agent Skills 是一份开放开发的规范，没有与之相当的法律托管方。

Agent Plugins 项目对这两套标准都没有管辖权。这细节决定了整个生态后续发展的基调。

Agent Plugins 技术指导委员会成员包括：Amazon 的 Clare Liguori、Cursor 的 Roshan Sadanani、Microsoft 的 Harald Kirschner、OpenAI 的 Gav Verma，以及担任核心维护者主导的 Vercel 的 Jonathan Hefner。技术宪章措辞谨慎，声明治理角色由个人而非组织担任，没有为公司预留席位，且没有单一供应商可以控制多数核心维护者席位。

Google 的公告称其"正以核心维护者身份加入该团队，由 Kevin Hou 代表。"截至本文撰写时，宪章中指定为正式名册的 MAINTAINERS 文件仍只列有五人，没有 Google。"加入"仍在进行中而非已完成，如果你在追踪谁持有投票权，那个文件才是需要关注的。

没有主要来源解释 Anthropic 为何缺席，所以我不会凭空编造一个理由。

规范管辖的是位置，而非行为

插件是一个目录，其根目录包含一个 plugin.json 文件。Skills 放在 skills/ 目录下，每个 skill 一个子目录。MCP server 放在 mcp.json 中。这些位置是固定的，清单文件无法移动它们，也无法内联声明组件——这扼杀了每个客户端本来会单独发明的发现间接层和优先级规则。

reports-plugin/
├── plugin.json          # Agent Plugins 管辖此文件
├── skills/
│   └── summarize/
│       └── SKILL.md     # Agent Skills 管辖此文件
├── mcp.json             # Agent Plugins 管辖配置形状
└── com.vendor.client/   # 无人管辖此目录

清单文件只需两个字段：$schema 和 name。其他均为可选元数据。

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "reports-plugin"
}

在组件本身，规范指定由其他规范来定义。第 7.1 节明确指出，Agent Skills 规范"是 SKILL.md 格式、frontmatter 字段和目录布局的真值来源"，而 Agent Plugins 仅管辖如何在插件内部发现 skill。第 7.2 节对 MCP 做了同样的处理。

没有任何力量强迫做出这样的选择。规范可以通过定义 profile、强制某个子集或禁止可选特性来约束另一规范的实现。Agent Plugins 选择了不这样做。由于它将 Agent Skills 和 MCP 视为分开治理的契约，所以尽量避免在它们之上叠加行为要求，转而只标准化了地址。

因此，"兼容"是一个范围，而非一种状态

第 11.1 节列出了符合规范的客户端的最低要求，最后一项值得强调：客户端必须至少支持一种组件类型：skill 或 MCP server。第 11.2 节阐明了后果——仅支持 skill 的客户端可以在完全不支持 MCP 的情况下符合规范。

传输支持采取了类似的方法。支持 MCP 的客户端必须实现 stdio 或 Streamable HTTP 之一，且应该同时支持两者，而传统的 HTTP+SSE 保持为可选。第 7.2.2 节要求客户端跳过不支持其传输方式的 server 条目，并继续加载其余内容。

把这些堆叠在一起，一致性声明所能涵盖的范围变得更宽了。

客户端	Skill	MCP	stdio	Streamable HTTP	符合规范
A	Yes	No	N/A	N/A	Yes
B	No	Yes	Yes	No	Yes
C	Yes	Yes	No	Yes	Yes

客户端 A 和客户端 B 毫无交集，却都通过了合规认证。包含一个 skill 和一个捆绑 stdio server 的插件，无法在两者中任何一个上完整运行——因为 A 只加载 skill，B 只加载 server，且在每种情况下客户端的行为都完全符合规范要求。

公平地说，目前尚无这样的客户端存在。可兼容性客户端页面列出了 VS Code、Cursor、GitHub Copilot、ChatGPT、Codex、Kiro、Hermes Agent、OpenClaw 和 Grok Bot，它们每一个都同时支持 Agent Skills 和 MCP，并逐项列出了各自的传输方式。这个列表也已远超出发布周的六家，这是一个真实的采用信号。

虽然这种脆弱性比矩阵所暗示的更为具体，但它仍然是一个值得注意的细节。仅仅声称 Agent Plugins 合规，并不能预测互操作性。能预测互操作性的是每个客户端的能力矩阵，而这个矩阵是文档，不是合规声明本身的一部分。没有什么能阻止未来的客户端发布规范所允许的"仅 skill" profile，然后用与当前八家相同的方式描述自己。

与自身 schema 相矛盾的清单规则

大多数解释性报道对 plugin.json 说了同样的事情：schema 是封闭的，任何多余的最高层字段都会使清单失效。从 package.json 复制一个字段过来，插件就死了。

规范的说法则与此不同。第 5.2 节列出了允许的十个最高层字段，然后继续说明：如果清单包含任何其他最高层字段，"客户端必须报告并忽略每个未知字段，且如果清单在其他方面满足本节要求，则必须继续加载插件。"未知的最高层字段按设计是非致命的。任何其他 schema 违规则是致命的。

然后再看一下发布的 schema，它在最高层设置了 "additionalProperties": false。用标准的 JSON Schema 验证器运行一个含有多余字段的清单，会失败。但将同样的清单交给一个符合规范的客户端，它必须加载。

第 5.2 节预见了这一点，说在规范文本与 schema 冲突时，以规范文本为准。作为决胜规则固然不错，但这意味着机器可读的产物与规范性文本在一个会频繁出现的用例上存在分歧，而你的 CI 使用的恰恰是那个产物。如果你在写一个插件 linter，不要仅从 schema 生成它。

两个同名文件 plugin.json

Claude Code 使用 .claude-plugin/plugin.json 作为自己的插件系统。Agent Plugins 使用的是包根目录下的 plugin.json。文件名相同，位置不同，schema 不同，两者之间没有任何关系。

这确实造成了混淆。在编辑器中搜索会显示两个相同的文件名。文档中提到"插件清单"时不指明是哪一个。告诉你编辑 plugin.json 的迁移指南是模糊的，除非它每次都给出完整路径。

澄清 Anthropic 的缺席意味着什么和不意味着什么很重要。Claude Code 不是该格式的发布客户端，但 npx plugins add CLI 将其列为支持的安装目标，并将可移植包转换为 Claude 的原生插件系统。准确的表述是：插件通过 CLI 安装到 Claude Code 中，而非 Claude Code 实现了 Agent Plugins。那个转换步骤才是行为可能漂移的地方，规范本身并不管辖它。

客户端命名空间如何收回可移植性

第 8 节定义了客户端扩展，即反向域命名空间，用于可移植核心之外的任何内容。客户端可以在 extensions["com.vendor.client"] 中声明清单数据，或在顶层 com.vendor.client/ 目录中，或两者兼用。

阅读规范分配给该命名空间的内容："Agent Plugins 不对客户端扩展数据或文件分配任何可移植的发现、验证、加载或失败语义。每个客户端自行定义其自身命名空间的内容和行为。"

命令、hook、agent、规则和 LSP server 均位于 v1 之外，理由是它们的格式尚未收敛。每一项都是开发者实际为之构建插件的东西。当 EmpirioLabs 的 Adam Dalloul 警告说，有用的行为最终落入 vendor 命名空间会导致标准在纸面上开放、而碎片化转移到别处时，他描述的正是第 8 节所文档化的那个逃生舱。

这是否重要，取决于你插件的价值有多少在 hook 中。如果大部分价值都在 hook 里，那可移植的部分只是包装，而你原本试图避免的 fork 仍然在，只是换了不同的目录名。

你的插件在需要密码或二进制文件之前是可移植的

两个较小但会耗费开发者时间的发现。

第 7.2.1 节说 header 值是"可见的包数据，而非可移植的密钥机制"，插件不得在 header 或环境变量中嵌入凭证，v1 没有定义 OAuth 配置，也没有可移植的凭证引用字段。授权发现、用户交互和凭证存储由客户端管理。因此，任何连接到需要认证服务的插件，在打包层面是可移植的，但在配置层面是客户端特定的——而用户卡住的地方恰恰就是配置这一步。

第二点更为微妙。对于 stdio server，命令必须是裸可执行文件名或插件相对路径。配置的 PATH 值是否参与解析裸名称，用规范的话说，"由客户端定义"，声称符合规范的插件不得依赖该行为。客户端也可以按其认为合适的方式继承、忽略或清理环境变量。两个符合规范的客户端可以以不同的环境和不同的解析结果启动同一个 server。如果你的插件附带了可执行文件，请使用插件相对路径的命令，不要再依赖环境变量。

v1.1 需要修复什么

项目对自身差距毫不讳言。其未来考量的文档列出了权限声明、加密签名验证、认证链、密钥机制、组织允许列表、审计事件 schema、依赖解析和合规性测试套件。

其中两项职责不同，值得特别指出。合规套件将使实现声明可测试，建立起客户端正确做其所声称之事的证明。机器可读的能力 profile 将使剩余的可选表面可预测，将当前的兼容性客户端页面转变为构建时可以检查的东西。两者你都需要，而第二个是更便宜的胜利。

签名和权限比两者都更重要。权限模型迫使每个客户端同意插件可以触碰什么，而 IDE、CLI 和托管企业平台今天对这个问题各有各的答案。宪章没有给任何 vendor 足够的票数来打破僵局。我应该指出这是我的推测，因为项目本身并未明确提及。

Agent Plugins 做了其作者设定要做的窄事，这种克制是刻意的而非疏忽。只是把兼容性页面当作能力列表来读，而不是当作承诺来读，因为定义其两个可移植组件类型语义的那些规范，治理权在别处。