Agent Plugins 1.0.0 发布：谷歌、亚马逊、微软等支持的统一智能体插件规范

Agent Plugins 1.0.0 是一项开放、厂商中立的规范，用于将 Agent Skills 和 MCP 服务器打包为可移植的插件。它由来自 Amazon、Cursor、Microsoft、OpenAI 和 Vercel 的核心维护者组成的 TSC 发布。Google 正以核心维护者身份加入该小组，由 Kevin Hou 代表，我们已开始在自己的产品中构建支持。

你写了一个技能。你写了一个脚本或 MCP 服务器来配合你的技能。它们合在一起做好一件有用的事——它们知道如何查询你的报表数据库，以及如何将结果转化为团队真正会阅读的每周摘要。

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

技能没问题。MCP 服务器没问题。但它们外面的包装不行：目录结构不同，manifest 要求不同的顶层元数据，MCP 配置使用不同的结构，并且以不同方式推断传输方式。于是你 fork 了这个包，维护两份本来从一开始就没有任何不同的组件副本，然后看着它们逐渐产生分歧。

核心问题不在于组件。而在于 manifest。

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/ 是一个完全由某个客户端拥有的扩展命名空间，用于钩子、智能体、命令或该客户端想要添加的任何其他内容。不认识它的客户端会将其忽略。可移植核心之所以能保持精简，是因为不可移植的部分有合法的去处。

并非每个技能都应该成为插件

在你伸手去拿插件之前，先问问自己是否真的需要它。如果你只是要把单个 MCP 服务器交付给单个客户端，那么仅靠 mcp.json 仍然是更简单的答案。如果你只有一个技能，你不需要插件。当你有一些本就属于一体、需要一起迁移的组件时，Agent Plugins 才体现出它的价值。

它刻意省略了什么

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

这是正确的决定。安装、策略、企业管控和审批用户体验，在 IDE、CLI 和托管企业平台这类不同客户端之间差异很大。每个智能体应用对其用户都承担着确实不同的义务。

插件是生态系统的一部分

打包是一回事。让插件被发现并送达用户手中是另一回事，值得精确厘清哪一层负责什么。

• 发现它—— Agentic Resource Discovery。[ 一种开放发现协议，让客户端可以询问"这项任务有哪些可用资源？"并得到匹配的资源。ARD 已经将 Plugin 视为一等智能体资源类型，与 agents、MCP servers 和 Skills 并列。它完全位于调用之前。
• 描述它—— AI Catalog。[ ARD 所索引的条目格式。一项拟议变更将 application/agent-plugins+json 注册为已知类型，因此目录条目可以指向一个 plugin.json，就像现有条目指向 agent card 或 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 服务器的产品中。

开始使用 Agent Plugins

• 构建一个。创建一个目录，添加一个带名称的 plugin.json，向 skills/greet/SKILL.md. 写一条简短的“hello world”指令。这就是一个有效的插件，大约只需一分钟。
• 阅读文档。完整规范、兼容客户端（更多即将推出）
• 查看 Data Agent Kit Plugins与Agents CLI Plugin

打包是平淡无奇的基础设施，而平淡无奇的基础设施恰恰是那种应该被共享、而不是被重复造五遍的东西。Agent Plugins 刻意保持小范围，只做好一件事，并且开放且可互操作；这正是我们支持它的原因。