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 服务器打包成可移植的插件。该规范由来自 Amazon、Cursor、Microsoft、OpenAI 和 Vercel 的核心维护者组成的 TSC（技术指导委员会）发布。Google 正以核心维护者身份加入该小组，由 Kevin Hou 代表，我们已开始将支持集成到自己的产品中。
你编写了一个技能，也编写了一个与之配套的脚本或 MCP 服务器。它们配合起来能出色地完成一件有用的事——例如，知道如何查询你的报告数据库，并能将结果转化为你的团队真正会阅读的每周摘要。
然后你尝试将其交付给第二个客户端。
技能没问题，MCP 服务器也没问题。但它们周围的包装层却有问题：目录布局不同，清单（manifest）要求不同的顶层元数据，MCP 配置使用不同的结构并以不同的方式推断传输协议。因此，你不得不 fork 软件包，维护着两份最初并无差别的组件副本，并眼睁睁地看着它们逐渐产生偏差。
核心问题不在于组件，而在于清单。
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 中声明，每个条目都有明确的类型。客户端永远不需要根据配置对象的形状去猜测传输协议，它可以在 stdio、Streamable HTTP 或传统的 HTTP+SSE 上工作。
请注意 plugin.json 不能做什么。它不能重新定位组件，也不能内联声明它们。没有需要配置的发现路径，也没有需要学习的优先级顺序。如果 skills/ 目录不存在，客户端就加载现有内容然后继续。mcp.json 中启动失败的服务器不会把插件的技能也拖垮——客户端会跳过该条目，继续加载，并报告故障。独立的组件独立地失败。
最后的那个反向域名目录是“逃生舱”。com.example.client/ 是一个完全由一个客户端拥有的扩展命名空间，用于存放钩子（hooks）、智能体（agents）、命令（commands）或该客户端想添加的任何其他内容。不识别它的客户端会直接忽略它。可移植的核心部分保持小巧，因为不可移植的部分有了一个合理的去处。
并非每个技能都应该成为插件
在你着手使用插件之前，先问问自己是否真的需要。如果你只是向单个客户端交付一个 MCP 服务器，单独使用 mcp.json 仍然是更简单的答案。如果你只有一个技能，你不需要插件。当你拥有一些属于一体且需要一同分发的组件时，Agent Plugins 才真正发挥作用。
它有意省略的部分
Agent Plugins v1 是一种打包格式，仅此而已。它没有定义安装机制、分发协议、权限模型、沙箱要求、信任或来源验证，也没有定义用户体验。这些都在项目的未来考量中公开列出，而并非悄然省略。
这是一个正确的决策。安装、策略、企业控制和审批用户体验在不同客户端（如 IDE、CLI 和托管企业平台）之间差异很大。每个智能体应用对其用户都负有真正不同的责任。
插件是生态系统的一部分
打包是一回事。发现插件并将其送到用户手中是另一回事，精确区分各层做什么是值得的。
- 发现它 —— Agentic Resource Discovery（智能体资源发现）。一个开放的发现协议，允许客户端询问“对于这个任务有什么可用资源？”并获取匹配的资源。ARD 已经将 Plugin 视为与智能体、MCP 服务器和 Skills 并列的一级智能体资源类型。它完全位于调用之前。
- 描述它 —— AI Catalog（AI 目录）。ARD 用来建立索引的条目格式。一项提议的更改注册了
application/agent-plugins+json作为已知类型，这样目录条目就可以指向一个plugin.json，就像现有条目指向智能体卡片或mcp.json一样。 - 打包它 —— Agent Plugins。一个目录，固定位置，可跨客户端移植。
- 运行它 —— MCP 和 Agent Skills。已经是可移植的执行契约。
每一层都是独立有用且可独立采纳的。你可以发布一个没有目录条目的插件，可以将一个非插件的资源收录到目录中，也可以完全不使用插件来运行技能。采纳其中一层从来不会强制你采纳下一层。
即日起交付
即日起，有两款 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 等——可以在任何兼容的客户端上可移植地使用。
我们期望将 Agent Plugins 支持带到更多我们已支持 Skills 和 MCP 服务器的产品中。
