官方更新 Google Developers Blog 正文 ok 1093 words

Agent Plugins:统一打包技能、工具等组件

英文标题:Agent Plugins package your skills, tools, and more

Agent Plugins 1.0.0 是一项开放、厂商中立的目录规范,可将 Agent Skills 与 MCP 服务器打包为可移植插件。该规范由 Amazon、Cursor、Microsoft、OpenAI、Vercel 等公司的核心维护者发布,Google 也以核心维护者身份加入并开始在自家产品中集成支持。它通过固定目录结构和简洁的 `plugin.json` 清单,解决不同客户端在组件封装、MCP 配置和传输方式上的兼容性问题。Google 的 Agents CLI 与 Data Agent Kit 已支持该格式,为开发者跨 AI 编程 Agent、IDE 和其他兼容客户端分发技能及工具提供了标准化路径。
打开原文相关 9 · 机会 5
media11.7 KB media303.7 KB media163.1 KB media207.6 KB media186.0 KB media351.5 KB media38.9 KB media56.6 KB

中文

Agent Plugins 横幅

Agent Plugins 1.0.0 是一项开放、厂商中立的规范,用于将 Agent Skills 和 MCP 服务器打包成可移植插件。它由来自 Amazon、Cursor、Microsoft、OpenAI 和 Vercel 的核心维护者组成的技术指导委员会(TSC)发布。Google 也将加入该组织,Kevin Hou 将代表 Google 担任核心维护者;我们已开始在自己的产品中构建对这一规范的支持。

你编写了一个技能,也编写了一个与之配套的脚本或 MCP 服务器。它们组合起来,能够很好地完成一项实用任务——知道如何查询你的报表数据库,并将结果生成团队真正会阅读的每周摘要。

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

技能本身没有问题,MCP 服务器本身也没有问题。但包裹它们的外层出了问题:目录布局不同,清单要求不同的顶层元数据,MCP 配置采用不同的结构,并以不同方式推断传输协议。因此,你不得不分叉这个软件包,维护两份原本根本不该不同的组件副本,并看着它们逐渐产生差异。

核心问题不在组件,而在清单。

Agent Skills 已经为 Agent 提供可复用的指令和资源。MCP 已经将 Agent 连接到工具和服务。这两者本身都具备可移植性。此前不具备可移植性的,是装载它们的盒子——而这个盒子正是每个客户端都不得不自行发明的东西。

插件作者不应该必须在覆盖所有客户端与利用每个客户端的独特优势之间做选择。他们应该两者兼得:对于真正相同的部分,采用一种可预测的统一结构;对于并不相同的部分,则保留让每个客户端继续创新的空间。

这正是我们以核心维护者身份加入 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"
}

JSON

其余所有内容都位于固定位置。技能放在 skills/ 中,每个技能各自占用一个子目录,并遵循 Agent Skills 规范已定义的格式。MCP 服务器在 mcp.json 中声明,且每个条目都必须明确指定类型。客户端无需根据配置对象的形态猜测传输协议;它可以运行在 stdio、Streamable HTTP 或旧版 HTTP+SSE 上。

请注意,plugin.json 不能做什么:它不能重新定位组件,也不能以内联方式声明组件。没有可配置的发现路径,也没有需要学习的优先级顺序。如果不存在 skills/,客户端就加载现有内容并继续执行。某个 mcp.json 服务器启动失败,也不会导致插件中的技能无法使用——客户端会跳过该条目,继续加载其他内容,并报告这项失败。独立组件应当独立失败。

最后这个反向域名目录是一个逃生出口。com.example.client/ 是完全归某个客户端所有的扩展命名空间,可用于添加钩子、Agent、命令,或该客户端希望添加的任何内容。不识别它的客户端会忽略它。由于不可移植的部分有了合理的归宿,可移植核心便能保持精简。

并非每个 Skill 都应成为 Plugin

在使用插件之前,先问问自己是否真的需要它。如果你只是向单一客户端交付一个 MCP 服务器,单独使用 mcp.json 仍然是更简单的方案。如果你只有一个技能,则不需要插件。只有当你拥有应当归为一组、并且需要一同迁移的组件时,Agent Plugins 才能体现其价值。

它刻意不包含什么

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

这是正确的选择。对于 IDE、CLI 和受管理企业平台等客户端而言,安装、策略、企业控制和审批 UX 存在显著差异。每种 Agent 应用对其用户都确实承担着不同的责任。

Plugins 是生态系统的一部分

打包是一项工作。发现插件并将其交付给用户是另一项工作,因此准确区分每一层的职责很重要。

  • 发现它—— Agentic Resource Discovery**。**一项开放的发现协议,让客户端可以询问“这项任务有哪些可用资源?”,并获得匹配资源。ARD 已将 Plugin 视为一类一等 Agent 资源,与 Agent、MCP 服务器和 Skills 并列。它完全位于调用之前。
  • 描述它—— AI Catalog**。**这是 ARD 建立索引时使用的条目格式。一项拟议变更将 application/agent-plugins+json 注册为已知类型,因此目录条目可以指向 plugin.json,就像现有条目可指向 Agent 卡片或 mcp.json 一样。
  • **打包它——Agent Plugins。**一个目录、固定位置、可跨客户端移植。
  • **运行它——MCP 和 Agent Skills。**这些是原本就具备可移植性的执行契约。

每一层都独立有用,也都可以独立采用。你可以发布没有目录条目的插件,可以将并非插件的资源加入目录,也可以完全不使用插件而运行技能。采用其中一层,绝不意味着必须采用下一层。

今日发布

截至今日,两款 Google 产品已支持该格式。

Agents CLI 将 Google 的 Agent 构建、评估、部署、可观测性和发布专家技能打包,使任何 AI 编程 Agent——Antigravity、Gemini CLI、Claude Code 或 Cursor——都能成为 Agent 构建和 Agent 运维专家。这些技能此前已经可以分发。如今,它们可以通过一种并非仅属于我们的格式进行分发。

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

我们预计会将 Agent Plugins 支持带到更多已经支持 Skills 和 MCP 服务器的产品中。

开始使用 Agent Plugins

打包是缺乏光彩的基础设施,而这种缺乏光彩的基础设施,恰恰应该被共享,而非被重复发明五次。Agent Plugins 的范围刻意保持精简,专注做好一件事,并且开放、可互操作;这正是我们支持它的原因。

English / 原文

agent-plugins-banner-4209x1253

Agent Plugins 1.0.0 is an open, vendor-neutral specification for packaging Agent Skills and MCP servers into portable plugins. It was published by a TSC of Core Maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel. Google is joining that group as a Core Maintainer, represented by Kevin Hou, and we're starting to build support into our own products.

You wrote a skill. You wrote a script or an MCP server to go with your skill. Together they do one useful thing well — they know how to query your reporting database and how to turn the results into the weekly summary your team actually reads.

Then you try to ship it to a second client.

The skill is fine. The MCP server is fine. But the wrapper around them is not: the directory layout is different, the manifest wants different top-level metadata, the MCP configuration uses a different shape and infers transports differently. So you fork the package, maintain two copies of components that were never different in the first place, and watch them drift.

The core problem isn't the components. It's the manifest.

Agent Skills already gives agents reusable instructions and resources. MCP already connects agents to tools and services. Both are portable on their own. What has not been portable is the box you put them in — and that box is the thing every client had to invent for itself.

Plugin authors shouldn't have to choose between reaching every client and using what makes each client good. They should get both: one predictable structure for the parts that are genuinely the same, and room for each client to keep innovating on the parts that aren't.

This is why we're joining the Agent Plugins as core maintainers, and starting to integrate into our products.

What an Agent Plugin Actually Is

A plugin is a directory. That's the whole idea, and the restraint is the point.

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

Plain text

The manifest is two lines of substance:

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

JSON

Everything else is found at a fixed location. Skills live in skills/, one subdirectory each, in the format the Agent Skills specification already defines. MCP servers are declared in mcp.json, with an explicit type on every entry. A client never has to guess a transport from the shape of a config object, it will work on stdio, Streamable HTTP, or legacy HTTP+SSE.

Notice what plugin.json cannot do. It cannot relocate components, and it cannot declare them inline. There is no discovery path to configure and no precedence order to learn. If skills/ isn't there, the client loads what is there and moves on. A mcp.json server that fails to start doesn't take the plugin's skills down with it — the client skips that entry, keeps loading, and reports the failure. Independent components fail independently.

That last reverse-domain directory is the escape hatch. com.example.client/ is an extension namespace owned entirely by one client, for hooks, agents, commands, or anything else that client wants to add. Clients that don't recognize it ignore it. The portable core stays small because the non-portable parts have somewhere legitimate to go.

Not Every skill should be a Plugin

Before you reach for a plugin, ask whether you need one. If you're shipping a single MCP server to a single client, mcp.json on its own is still the simpler answer. If you have a single skill, you don’t need a plugin. Agent Plugins earns its keep when you have components that belong together and need to travel together.

What It Deliberately Leaves Out

Agent Plugins v1 is a package format and nothing more. It defines no install mechanism, no distribution protocol, no permission model, no sandboxing requirements, no trust or provenance verification, and no user experience. Those are named openly in the project's future considerations, not quietly omitted.

This is the right call. Installation, policy, enterprise controls, and approval UX are quite different across clients like an IDE, a CLI, and a managed enterprise platform. Each agentic application has genuinely different obligations to their users.

Plugins are part of an ecosystem

Packaging is one job. Discovering and getting a plugin to a user is a different job, and it's worth being precise about which layer does what.

  • Find it — Agentic Resource Discovery. An open discovery protocol that lets a client ask "what is available for this task?" and get back matching resources. ARD already treats a Plugin as a first-class agentic resource type, alongside agents, MCP servers, and Skills. It sits entirely before invocation.
  • Describe it — AI Catalog. The entry format ARD indexes. A proposed change registers application/agent-plugins+json as a known type, so a catalog entry can point at a plugin.json the way an existing entry points at an agent card or mcp.json.
  • Package it — Agent Plugins. One directory, fixed locations, portable across clients.
  • Run it — MCP and Agent Skills. The execution contracts that were already portable.

Each layer is independently useful and independently adoptable. You can publish a plugin with no catalog entry, catalog a resource that isn't a plugin, and run skills with no plugin at all. Adopting one never obligates you to the next.

Shipping Today

Two Google products support the format as of today.

Agents CLI packages Google's expert skills for agent building, evaluation, deployment, observability, and publishing, turning any AI coding agent — Antigravity, Gemini CLI, Claude Code, or Cursor — into an expert at agent building and agent ops. Those skills were already distributable. Now they're distributable in a format that isn't ours alone.

Data Agent Kit provides a collection of plugins that bring the power of Google Data Cloud directly into your preferred AI coding agent or IDE. Designed for data engineers and developers, it allows agents to seamlessly manage data assets, run queries, and deploy data pipelines. By adopting the Agent Plugins standard, the Data Agent Kit ensures that its rich set of agentic skills and MCP servers—connecting to BigQuery, Spanner, Cloud SQL, and more—are portably available across any compatible client.

We expect to bring Agent Plugins support to more of our products that already work with Skills and MCP servers.

Get Started with Agent Plugins

Packaging is unglamorous infrastructure, and unglamorous infrastructure is exactly the kind of thing that should be shared rather than reinvented five times. Agent Plugins is deliberately small in scope, does one thing well, and is open and interoperable; that's why we're backing it.