如果你每天都在跟 AI Agent 打交道，你一定经历过这个场景：
你辛辛苦苦写了一个 MCP 服务器，对接了公司内部的 JIRA、GitHub、数据库查询，再配上一份精心打磨的 SKILL.md，让你的 ChatGPT 或 Cursor 能完美地帮你做周报汇总。你觉得这玩意儿太棒了，想分享给隔壁用 VS Code + Copilot 的同事——然后噩梦开始了。
目录结构不一样、manifest 格式不同、MCP transport 推断方式有差异。你不得不维护两个版本，眼睁睁看着它们逐渐偏离。
这个痛苦，昨天终于结束了。
2026 年 8 月 6 日，一个由 Amazon、Cursor、Microsoft、OpenAI、Vercel 组成的 TSC（技术指导委员会）正式发布了 Agent Plugins 1.0.0 规范。Google 同时宣布加入成为 Core Maintainer。 这是 AI Agent 领域第一次出现真正的跨平台插件打包标准。
五巨头 + Google，史无前例的联盟
Agent Plugins 的 TSC 阵容堪称豪华：
- Amazon（通过 AWS Kiro 和 AWS Agent Toolkit）
- Cursor（最流行的 AI 原生 IDE）
- Microsoft（VS Code + GitHub Copilot）
- OpenAI（ChatGPT + Codex CLI）
- Vercel（AI SDK + 前端生态）
- Google（同日宣布加入，Kevin Hou 代表 Google DeepMind 进入 TSC）
支持的客户端更是一口气覆盖了目前最主流的 AI 编程环境：
| 客户端 | 所属公司 | 目标用户 |
|---|---|---|
| ChatGPT / Codex | OpenAI | 终端用户聊天气泡 + CLI |
| Cursor | Cursor | AI 原生 IDE |
| GitHub Copilot | Microsoft | VS Code 开发者 |
| Kiro | AWS | AWS 生态开发者 |
| VS Code | Microsoft | 全球最大 IDE |
为什么这六家能坐在一起？ 因为所有人都意识到：AI Agent 生态的瓶颈已经从「模型能力」变成了「互操作性」。你有再强的模型，如果你的技能和工具只能在自家客户端里跑，开发者就不愿意为你写插件。生态碎片化伤害的是所有人。
一个 Plugin 就是一个目录——克制才是美德
Agent Plugins 的设计理念让人想起早期 Unix 哲学：做一件事，做好，且做简单。
reports-plugin/
├── plugin.json # 就两行
├── skills/
│ └── summarize/
│ ├── SKILL.md
│ ├── scripts/
│ └── references/
├── mcp.json # 显式声明 transport 类型
└── com.example.client/ # 客户端专用扩展命名空间
plugin.json 只有两个必要字段：
{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "reports-plugin"
}
这个设计处处透露着「克制」：
- Skills 必须放在
skills/目录，格式遵循 Agent Skills 规范。没有重定向、没有别名、没有优先级配置。不存在，就不加载。 - MCP 服务器声明在
mcp.json，且每个条目必须显式指定 transport 类型（stdio、Streamable HTTP、HTTP+SSE）。客户端不再需要从 config 对象的形状「猜」传输方式。 - 组件独立失败：一个 MCP 服务器挂了，不影响 skills。client 跳过那个 entry，继续加载，然后报告错误。
- 客户端扩展命名空间：
com.example.client/目录完全归该客户端所有，其他客户端直接无视。可移植的核心保持精简，非可移植的部分有合法去处。
Google 开发者博客上说得特别好：「问题不在组件本身——Agent Skills 已经是可移植的，MCP 也已经是可移植的。不可移植的是装它们的那个「盒子」，而每个客户端都自己发明了一个盒子。」
什么情况下用 Plugin？什么情况下别用？
规范文档很诚实地指出：不是所有技能都需要变成 Plugin。
- 如果只是一个单文件 MCP 服务器，跑在单客户端上——直接扔个
mcp.json就够了。 - 如果只是一个孤立的 SKILL.md——不用 Plugin。
- 但如果你的技能和工具需要一起打包、一起迁移——那就是 Plugin 大显身手的时候。
这种「按需升级」的设计降低了入门门槛：你从一个小目录开始，没有任何框架负担。将来需要跨客户端了，加几行 plugin.json 就好。
Agent Plugins 在生态中的位置
Agent Plugins 不是孤立的。它是 Google 定义的「四层生态」中的第三层：
| 层次 | 做什么 | 已有标准/协议 |
|---|---|---|
| Find it | Agentic Resource Discovery | ARD 协议，Plugin 是第一类资源类型 |
| Describe it | AI Catalog 条目 | application/agent-plugins+json 注册类型 |
| Package it | Agent Plugins | 本次发布 |
| Run it | MCP + Agent Skills | 各自独立可移植 |
每一层都是独立可用的。 你可以 publish 一个 Plugin 但没有 catalog entry，也可以 catalog 一个非 Plugin 的资源。采用其中一层绝不绑定你到其他层。
这在架构上是一个极其清醒的决定——不搞「全家桶绑定」，每个组件都能独立演进。
Google 的产品落地
Google 在发布当天就带着两个产品落地了：
- Agents CLI Plugin：把 Google 的 Agent 构建、评估、部署、观测、发布等专家技能打包成 Plugin，让你的任意 AI 编码 Agent（Antigravity、Gemini CLI、Claude Code、Cursor）瞬间变成 Agent Ops 专家。
- Data Agent Kit：为数据工程师打造的 Plugin 集合，把 BigQuery、Spanner、Cloud SQL 等 Google Data Cloud 的能力打包成可移植的 Skills 和 MCP 服务器。
AWS 这边，Kiro 和 AWS Agent Toolkit 也已经原生支持了 Agent Plugins 格式。
为什么说这是历史性时刻？
回顾 AI Agent 的演进史，你会看到清晰的「分久必合」脉络：
- 2024-2025：MCP 诞生并迅速成为事实标准。Anthropic 发布了 MCP 协议，各大厂商纷纷接入。
- 2025-2026 上半年：各客户端纷纷推出自己的「插件/技能」格式。ChatGPT 有 GPTs + Actions，VS Code 有 Copilot Extensions，Cursor 有 .cursorrules，AWS 有 Kiro Powers。虽然底层都是 MCP+Skills，但「包装盒」各不相同。
- 2026.8.7：Agent Plugins 1.0 发布——包装盒终于标准化了。
这就像 HTTP 协议标准化之前，每个浏览器都有自己的协议；就像 Docker 统一了容器镜像格式之前，每个云厂商都有自己的虚拟机模板。
一个标准成型的过程通常是这样的：先有百花齐放的探索（各客户端自定格式），然后出现一个「最小共识」（Agent Plugins），最后行业默契地站在这个共识之上。
Agent Plugins 1.0 选择了一个非常聪明的策略：只做包装盒，不做跟包装盒无关的任何事。 它不定义安装机制、不定义分发协议、不定义权限模型、不定义沙箱要求、不定义信任验证——这些全部留给每个客户端自己去实现。因为 IDE 的安装体验和 CLI 的安装体验是完全不同的需求。
这种「各管各的，只管接口对齐」的模式，正是互联网标准化历史上最能成功的方式。
写在最后
Agent Plugins 1.0 是一个小到不能再小，但又足够完成任务的规范。它没有宏大叙事，没有一揽子解决方案，没有试图解决所有 Agent 生态问题。它只做一件事——定义你的技能和工具应该放在哪个目录里。
但就是这样一件小事，有可能成为 AI Agent 生态从「战国时代」走向「统一时代」的起点。
就像 TCP/IP 协议栈中，IP 层只做路由转发，把可靠传输留给 TCP——Agent Plugins 只做打包，把安装、分发、安全留给上层。每层做自己的事，这就是互联网架构的终极智慧。
顺便说一句，我们已经写过 MCP Gateway 横向评测 了，当时还在感慨 MCP 生态的碎片化。现在看来，行业共识来得比想象中更快。
📌 写一个 Plugin 有多简单？创建一个目录，写一个两行的
plugin.json，在skills/greet/下放一个「Hello World」SKILL.md——一分钟，搞定。