Agent Plugins 将你的技能、工具等打包在一起

2026 年 8 月 6 日　Kevin Hou　Google DeepMind 高级资深工程师　Haoyu Wang　Google Cloud Data 资深软件工程师　Alan Blount　Google Cloud AI 技术产品经理

Agent Plugins 1.0.0 是一个开放、与厂商无关的规范，用于将 Agent Skills（代理技能）和 MCP（Model Context Protocol，模型上下文协议）服务器打包成可移植的插件。它由来自 Amazon、Cursor、Microsoft、OpenAI 和 Vercel 的核心维护者组成的技术指导委员会（TSC）发布。Google 正作为核心维护者加入这一阵营，由 Kevin Hou 代表参与，并且我们已开始把相关支持集成进我们自家的产品中。

你写了一个技能，又写了一个配套的脚本或 MCP 服务器。组合起来它们能很好地完成一件有用的事——比如查询你的报表数据库，并把结果整理成你团队真正会看的周报摘要。

然后你试着把它交付给第二个客户端。

技能没问题，MCP 服务器也没问题。但包裹它们的"外壳"有问题：目录布局不一样，清单文件要求的顶层元数据不一样，MCP 配置的形态不同，推断传输协议的方式也不同。于是你只能 fork 这个包，维护两份原本毫无差异的组件副本，眼睁睁看着它们逐渐分道扬镳。

agent-plugins-figure-fork-and-drift

核心问题不在组件本身，而在于清单文件。

Agent Skills 已经能让代理拥有可复用的指令和资源。MCP 已经能让代理连接工具和服务。两者各自都是可移植的。一直无法可移植的，是装它们的那个盒子——而那个盒子，正是每个客户端不得不各自发明的部分。

插件作者不应该在"覆盖所有客户端"和"发挥每个客户端的特长"之间二选一。他们应该两全：对于真正相同的那部分，有一个可预期的统一结构；对于确实不同的那部分，则留出空间让每个客户端继续创新。

正因如此，我们决定以核心维护者的身份加入 Agent Plugins 项目，并开始把它集成进我们的产品。

一个 Agent Plugin 究竟是什么

插件就是一个目录。这就是全部想法，而克制本身就是要点。

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

清单文件实质上只有两行：

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

其余一切都在固定位置查找。技能放在 skills/ 下，每个子目录对应一项，遵循 Agent Skills 规范已有的格式。MCP 服务器在 mcp.json 中声明，每个条目都带有明确的 type 字段。客户端再也不必根据配置对象的形态去猜测传输协议——它可以直接运行在 stdio、Streamable HTTP 或旧版 HTTP+SSE 上。

请注意 plugin.json 不能做什么。它不能重新定位组件，也不能把组件内联声明。没有可配置的发现路径，也没有需要学习的优先级。如果 skills/ 不存在，客户端就只加载存在的内容并继续往下走。如果 mcp.json 中的某个服务器启动失败，插件的技能也不会跟着遭殃——客户端会跳过这条条目，继续加载，并报告这次失败。独立的组件独立失败。

那个反向域名的目录是整个机制的"逃生舱"。com.example.client/ 是一个完全归某个客户端所有的扩展命名空间，用于存放钩子、代理、命令或该客户端想新增的任何东西。不认识它的客户端会直接忽略它。可移植的核心之所以能保持精简，是因为不可移植的部分有了一个合理去处。

不是每个技能都该成为插件

在动手做插件之前，先问问自己是否真的需要它。如果你只是把单个 MCP 服务器交付给单个客户端，那么单独的 mcp.json 仍然是更简单的答案。如果你只有一个技能，你同样不需要插件。只有当你拥有必须一起存在、一起迁移的多个组件时，Agent Plugins 才真正物有所值。

agent-plugins-figure-not-every-skill

它刻意没有覆盖的内容

Agent Plugins v1 只是一个打包格式，仅此而已。它不定义安装机制、不定义分发协议、不定义权限模型、不定义沙箱要求、不定义信任或来源验证，也不定义用户体验。这些都在项目的 future considerations 中公开列出，而不是悄悄忽略。

这是正确的取舍。安装、策略、企业管控和审批 UX，在 IDE、CLI 和托管型企业平台等不同客户端之间差异极大。每款代理类应用对用户承担的责任也各不相同。

插件是生态的一部分

打包是一件事，发现并把插件送达用户则是另一件事——值得清楚地划清各层职责。

发现它——Agentic Resource Discovery（代理资源发现）。 一种开放的发现协议，让客户端可以询问"这个任务有哪些可用资源？"并拿到匹配的资源列表。ARD 已经把 Plugin 作为一等代理资源类型，与代理、MCP 服务器和技能并列。它完全运行在调用发生之前。
描述它——AI Catalog。 ARD 索引所用的条目格式。一项提议的变更正将 application/agent-plugins+json 注册为已知类型，这样目录条目就可以像现有的条目指向代理卡片或 mcp.json 一样，指向某个 plugin.json。
打包它——Agent Plugins。 一个目录、固定位置、跨客户端可移植。
运行它——MCP 与 Agent Skills。 这些本就可移植的执行契约。

每一层都各自独立有用、可独立采用。你可以发布一个没有任何目录条目的插件，也可以收录一条不是插件的资源，更可以直接运行完全不依赖插件的技能。采纳其中任何一层，从不意味着必须采纳下一层。

agent-plugins-figure-ecosystem-layers

现已上线

截至今天，两款 Google 产品已支持该格式。

Agents CLI 把 Google 在代理构建、评估、部署、可观测性和发布方面的专家技能打包成插件，让任意一款 AI 编程代理——Antigravity、Gemini CLI、Claude Code 或 Cursor——都能成为代理构建与代理运维方面的专家。这些技能此前已经可以分发，如今则以不再仅属于我们一家厂商的格式进行分发。

Data Agent Kit 提供了一组插件，把 Google Data Cloud 的能力直接带入你惯用的 AI 编程代理或 IDE。它面向数据工程师和开发者设计，让代理可以无缝管理数据资产、运行查询并部署数据管道。通过采纳 Agent Plugins 标准，Data Agent Kit 得以确保其丰富的代理技能与 MCP 服务器集合（连接 BigQuery、Spanner、Cloud SQL 等服务）在任何兼容的客户端上均可移植可用。

我们预计将在更多已支持 Skills 和 MCP 服务器的产品中引入 Agent Plugins 支持。

开始使用 Agent Plugins

动手做一个。 新建一个目录，写一份带 name 字段的 plugin.json，再在 skills/greet/SKILL.md 里写一段简短的 "hello world" 指令。这就是一合规的插件，整个过程大约一分钟。
阅读文档。 查看完整规范和兼容客户端列表（很快会更多）。
试用示例插件。 查看 Data Agent Kit 插件与 Agents CLI 插件。

打包算不上光鲜的基础设施，而这种不性感的基建恰恰最应该共享，而不是被重复发明五次。Agent Plugins 在范围上刻意克制，把一件事做好，并且保持开放与互操作——这正是我们支持它的原因。

相关阅读

Why client SDK generation belongs in the open（2026 年 9 月 17 日）
Colab is now part of your Google AI plan（2026 年 9 月 22 日）

Agent Plugins package your skills, tools, and more