Agent 插件迎来跨平台统一规范

Agent Plugins 1.0.0 是一项开放、厂商中立的规范，用于将 Agent Skills 和 MCP servers 打包成可移植的插件。该规范由来自 Amazon、Cursor、Microsoft、OpenAI 和 Vercel 的核心维护者组成的技术指导委员会（TSC）发布。Google 也将加入这个核心维护者团队，由 Kevin Hou 代表，同时我们正着手在自己的产品中提供支持。

你编写了一个 skill。你还为这个 skill 编写了配套脚本或 MCP server。它们组合在一起，能够出色地完成一项实用任务——它们知道如何查询你的报表数据库，也知道如何把查询结果整理成团队真正愿意阅读的每周摘要。

然后，你尝试将它交付给第二个客户端。

skill 本身没有问题，MCP server 也没有问题。问题出在包裹它们的外层结构上：目录布局不同，manifest 要求不同的顶层元数据，MCP 配置采用不同的结构，并以不同方式推断 transport。于是，你不得不 fork 这个软件包，维护两份原本根本没有差异的组件，然后眼看着它们逐渐产生分歧。

核心问题并不在组件，而在 manifest。

Agent Skills 已经为 Agent 提供了可复用的指令和资源。MCP 也已经能够将 Agent 连接到工具与服务。二者本身都具备可移植性。一直以来无法移植的，是你用来装载它们的那个盒子——而偏偏每个客户端都不得不自行发明这样一个盒子。

插件作者不应该被迫在“覆盖所有客户端”和“发挥各个客户端的独特优势”之间二选一。他们应该两者兼得：对于真正相同的部分，使用一套可预测的结构；对于不同的部分，则给每个客户端留下继续创新的空间。

这正是我们以核心维护者身份加入 Agent Plugins，并开始将其集成到自家产品中的原因。

Agent Plugin 到底是什么

插件就是一个目录。核心理念仅此而已，而这种克制恰恰是关键所在。

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

manifest 中真正有实质意义的内容只有两行：

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

其他所有内容都能在固定位置找到。Skills 位于 skills/ 中，每个 skill 独占一个子目录，并遵循 Agent Skills 规范已经定义好的格式。MCP servers 则在 mcp.json 中声明，每一项都必须明确指定类型。客户端不再需要根据配置对象的结构猜测 transport；无论使用 stdio、Streamable HTTP，还是传统的 HTTP+SSE，它都能正常工作。

请注意 plugin.json 不能做什么。它不能重新指定组件的位置，也不能以内联方式声明组件。这里没有需要配置的发现路径，也没有需要学习的优先级顺序。如果不存在 skills/，客户端就加载现有内容，然后继续处理。假如 mcp.json 中的某个 server 启动失败，也不会连带导致插件的 skills 无法使用——客户端会跳过该项、继续加载，并报告这次失败。相互独立的组件也会彼此独立地失败。

最后那个采用反向域名形式的目录是一条逃生通道。com.example.client/ 是完全归某个客户端所有的扩展命名空间，可用于放置 hooks、agents、commands，或者该客户端希望添加的任何其他内容。不认识它的客户端会直接忽略它。正因为不可移植的部分有了一个名正言顺的去处，可移植的核心才能保持精简。

并非每个 skill 都应该成为 Plugin

在决定使用插件之前，先问问自己是否真的需要它。如果你只是向单个客户端交付一个 MCP server，那么单独使用 mcp.json 仍然是更简单的方案。如果你只有一个 skill，也不需要插件。只有当多个组件彼此关联、需要一起迁移时，Agent Plugins 才能真正体现价值。

它刻意没有包含什么

Agent Plugins v1 只是一种包格式，仅此而已。它没有定义安装机制、分发协议、权限模型、沙箱要求、信任或来源验证，也没有规定用户体验。这些内容都在项目的未来考虑事项中被明确列出，而不是悄无声息地省略掉。

这是正确的决定。对于 IDE、CLI 和托管式企业平台这类不同客户端而言，安装、策略、企业控制以及审批 UX 都存在很大差异。每一种 Agent 应用对其用户承担的责任也确实不同。

Plugins 是生态系统的一部分

打包是一项工作。发现插件并将它交付给用户则是另一项工作，我们有必要准确区分每一层分别负责什么。

发现它——Agentic Resource Discovery。这是一种开放的发现协议，允许客户端询问“有哪些资源适合这项任务？”，并获得匹配的资源。ARD 已经将 Plugin 与 agents、MCP servers 和 Skills 一样，视为一种一等 Agent 资源类型。它完全发生在调用之前。

描述它——AI Catalog。这是 ARD 建立索引时采用的条目格式。一项拟议中的变更会将 application/agent-plugins+json 注册为已知类型，这样 catalog 条目就能像现有条目指向 agent card 或 mcp.json 那样，指向一个 plugin.json。

打包它——Agent Plugins。一个目录、固定位置，并且能够跨客户端移植。

运行它——MCP 和 Agent Skills。它们是早已具备可移植性的执行契约。

每一层都可以独立发挥作用，也可以独立采用。你可以发布一个没有 catalog 条目的插件，可以将并非插件的资源加入 catalog，也可以在完全没有插件的情况下运行 skills。采用其中一层，从来不意味着你必须继续采用下一层。

截至目前，已有两款 Google 产品支持这种格式。

Agents CLI 将 Google 在 Agent 构建、评估、部署、可观测性和发布方面的专家 skills 打包起来，让任何 AI 编程 Agent——无论是 Antigravity、Gemini CLI、Claude Code 还是 Cursor——都能成为 Agent 构建和 Agent 运维方面的专家。这些 skills 原本就可以分发。现在，它们能够以一种不再只属于 Google 的格式进行分发。

Data Agent Kit 提供了一组插件，把 Google Data Cloud 的能力直接带入你偏爱的 AI 编程 Agent 或 IDE。它专为数据工程师和开发者设计，使 Agent 能够无缝管理数据资产、运行查询并部署数据管道。通过采用 Agent Plugins 标准，Data Agent Kit 可以确保其丰富的 Agent skills 和 MCP servers——连接 BigQuery、Spanner、Cloud SQL 等服务——能够以可移植的方式提供给任何兼容客户端。

我们预计会在更多已经支持 Skills 和 MCP servers 的产品中加入对 Agent Plugins 的支持。

开始使用 Agent Plugins

自己构建一个。创建一个目录，添加包含名称的 plugin.json，然后在 skills/greet/SKILL.md 中编写一段简单的“hello world”指令。这就是一个有效的插件，整个过程大约只需一分钟。

阅读文档。查看完整规范以及兼容的客户端（很快还会有更多）。

查看 Data Agent Kit Plugins 和 Agents CLI Plugin。

打包是一种并不起眼的基础设施，而这种不起眼的基础设施恰恰最应该共享，而不是被重复发明五次。Agent Plugins 刻意保持较小的范围，只专注做好一件事，同时保持开放和互操作性；这正是我们支持它的原因。