INDEX / NO.039 — 2026.08.13 — 前沿追踪

Agent Plugins 1.0 标准发布，Anthropic 反而缺席

Agent Plugins 1.0 统一 Skills 和 MCP 的打包、发现与加载方式。它能否推动 Agent 生态共享？

微信公众号原文 ↗ ← 返回索引

Agent Plugins 1.0 是什么？

它是一套给 Agent 扩展使用的开放标准：把 Skills 和 MCP servers 按统一方式打包，让不同 Agent 客户端从固定位置发现和加载。

它有什么用？

你写好的研究 Skill、代码审查 Skill，接好的数据库 MCP、浏览器 MCP，不必每换一个客户端，就重新找目录、改配置、写安装说明。只要客户端支持这套标准，同一份公共能力就有机会继续使用。

这和用户有什么关系？

  • 用户少折腾几套安装方法；
  • 开发者少维护几份客户端适配；
  • 企业可以用一个统一对象分发和管理 Agent 能力。

2026 年 8 月 6 日，Agent Plugins 1.0.0 发布。Vercel、Amazon、Microsoft、OpenAI、Cursor 等参与其中，发布时列出的支持客户端包括 ChatGPT、Codex、Cursor、GitHub Copilot、Kiro 和 VS Code。

规范已经把一套具体的目录、清单和发现规则公开出来了。

这件事还不等于 Agent 生态已经共享。总之是机会变大了，但能不能共享，取决于更多客户端接入、同一插件能否实际跑通，以及分发和治理能不能跟上。

但打包方式先有了共同标准，生态共享才有了继续往前走的起点。

这次标准由谁推动

Vercel 发起最初提案，Amazon Web Services（AWS）、Anysphere、GitHub、Microsoft、OpenAI 和 Vercel 的代表共同完善了 1.0.0。初始技术指导委员会包括来自 Amazon、Cursor、Microsoft、OpenAI 和 Vercel 的核心维护者。

现在谁已经接入

Agent Plugins 官网现在单独维护兼容客户端页面，并按组件和 MCP transport 区分支持范围，截至 2026 年 8 月 12 日，官网兼容客户端页面列出的客户端，名单还在持续更新中。

  • Cursor；
  • GitHub Copilot；
  • ChatGPT & Codex；
  • Kiro；
  • Hermes Agent；
  • Grok Bot；
  • OpenClaw；
  • VS Code。

缺席者：Anthropic

Agent Skills 由 Anthropic 维护并开放社区贡献，MCP 最初由 Anthropic 创建并开源。但上述截至日期时，Anthropic 不在 Agent Plugins 初始技术指导委员会名单中，Claude Code 也不在兼容页面的客户端列表里。

为什么需要统一打包

先把 Skill 和 MCP 分开看。

Skill 是工作方法。

它可以让 Agent 学会做研究、翻译、代码审查、PDF 处理，或者按照你的业务规则工作。

MCP 是连接工具和数据的方式。

它可以把数据库、浏览器、内部 API 接到 Agent 手里。

两类能力都可以复用。

真正麻烦的是交付。

你写好一个 Skill，先要回答：放在哪个目录？项目级还是全局级？OpenCode、Codex 和 Claude Code 能不能共用？

你写好一个 MCP server，还要为不同客户端准备不同的配置文件、字段、路径和环境变量说明。

以 OpenCode 为例，为了兼容不同生态，它会从 .opencode/skills/、.claude/skills/、.agents/skills/ 等位置寻找 Skill。它解决的是“尽量发现更多 Skill”，没有解决“所有客户端共享同一套交付方式”。

于是就有了这个局面：

Skill 的内容维护一份，安装方法维护五份。

开发者写一份能力，接着改目录、写说明、适配下一个客户端，再复制一遍。

这不是模型不够强。

是扩展的打包方式还没有统一。

Agent Plugins 1.0 来解决的，就是这层重复劳动。

Agent Plugins 1.0 统一了什么

Agent Plugins 采用的是一个更小的公共核心，而各家客户端仍然可以保留自己的插件能力和产品路线。

一个 Plugin 就是一个目录：

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

最小的 plugin.json 用来标识规范版本和插件名称：

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

根目录用 plugin.json 标识插件。

skills/ 放 Skills。

mcp.json 放 MCP server 配置。

com.example.client/ 这类目录，留给客户端自己的扩展。

客户端按照固定位置寻找组件，不必每个插件重新学习一套目录规则。

Agent Plugins 没有重新定义 Skills，也没有重新定义 MCP：

东西解决什么问题
Agent SkillsAgent 按什么方法做事
MCPAgent 如何接工具和数据
Agent PluginsSkills 和 MCP 如何一起打包、发现、分发

如果你还没看过 Agent Skills，可以先读之前的文章：Agent Skills 教程：安装、调用与编写。

两者的关系很简单：

Agent Skills 是能力本身的内容标准，Agent Plugins 是能力的交付格式。

Agent Plugins 1.0 复用 Agent Skills 的 SKILL.md 结构，再把它和 MCP 配置放进同一个 Plugin。

MCP 配置也有了共同入口

每个 MCP server 都要写明 type：

  • stdio：启动本地进程；
  • streamable-http：使用 Streamable HTTP；
  • sse：旧版 HTTP+SSE，可选支持。

客户端不必再根据 JSON 的长相猜 transport。遇到自己不支持的 transport，可以跳过对应 server，继续加载其他组件。

一个 MCP server 起不来，也不应该拖垮同一个 Plugin 里的 Skill。

统一的范围很明确：

插件怎么放，客户端去哪找，组件怎么加载。

Agent Plugins v1 统一范围

图：Agent Plugins v1 只统一 Skills 与 MCP 的公共交付格式；运行、权限、产品体验和分发治理仍由客户端决定。来源：Agent Plugins Specification v1.0.0。

这一步不大，却是共享能够成立的前提。

规范化会带来什么

普通用户：少重装几次

普通用户不需要研究 plugin.json。

如果客户端完成 Agent Plugins 1.0 的接入，一个同时包含 Skill 和 MCP 的插件，才有机会变成一次安装。

换客户端时，原来的能力也更容易跟着走，前提是新客户端支持相应组件和 transport。

眼下能说清楚的收益很朴素：

  • 少记一套安装路径；
  • 少复制几段配置；
  • 少维护一份客户端专属说明。

再往后，如果更多客户端采用同一格式，研究、翻译、代码审查、PDF 处理等工作流，就有机会不再绑定在某一个应用里。

这是机会，不是已经完成的迁移体验。

开发者：公共能力一次打包

过去，发布一个 Agent 扩展，常常要准备多套客户端安装方式和 MCP 配置。

现在可以先把公共部分放进：

  • plugin.json；
  • skills/；
  • mcp.json。

客户端专属的 Hook、Custom Agent、Slash Command，再单独维护。

这不会让所有适配工作消失，但会把公共能力和客户端特色拆开。

比如：

  • 代码审查 Skill、内部文档 MCP、数据分析工具，放进标准核心；
  • 某个 IDE 的命令面板、Hook 和特殊权限，留在客户端扩展里。

能统一的先统一。

这比每家客户端各维护一套 Plugin 格式，至少前进了一步。

企业：有了统一的交付对象

企业通常不是缺一个 Skill，而是有一堆散落在项目、团队和客户端里的能力：查销售数据、生成经营分析、检查代码、处理工单、调用审批系统。

如果这些能力绑在某个 AI 工具里，团队换工具要重做，企业也很难管理：

  • 谁装了什么？
  • 哪个 Skill 连了内部系统？
  • 哪个 MCP 有写权限？
  • 版本是否一致？

Agent Plugins 1.0 不能替企业回答这些问题，但它提供了一个清楚的交付对象：Plugin。

企业可以围绕 Plugin 建设内部仓库、版本管理、团队分发、允许列表和安装审核。

这些是企业平台基于标准补出来的治理能力，不是规范自动提供的能力。

它给企业的是统一交付的起点，不是现成的安全方案。

权限、密钥、审计、沙箱和审批，还得企业自己补。

做到共享还需要什么

打包方式统一，只是起点。

要让生态真正共享，还要补三件事。

兼容矩阵继续扩展

规范写出来不难，客户端愿意按规范加载，才算开始产生价值。

而且不是只识别 plugin.json 就够了。Skills、MCP、transport、路径变量和失败隔离，都要能在真实环境里跑通。

公共组件和客户端能力分开

Agent Plugins v1 只定义 Skills 和 MCP servers 两类可移植组件。

Hooks、Agents、Slash Commands 仍然主要属于客户端能力。一个 Plugin 可以跨端携带公共部分，但不一定带得走完整的客户端体验。

这不是坏事。

标准先统一能统一的部分，客户端继续保留自己的产品差异，生态反而更容易往前走。

分发、权限和信任跟上

Agent Plugins 1.0 没有统一 Marketplace、来源签名、权限声明、沙箱、密钥管理和企业审计。

不要把真实密钥明文写进 headers。1.0 没有定义通用的密钥注入和凭据管理机制。

插件路径不能逃逸根目录，也不等于插件里的本地进程没有权限。

开放格式解决了“怎么交付”，还没有解决“谁来分发、谁来批准、出了问题谁负责”。

总结

总之有章法，总比没章法强。

Agent Plugins 1.0 不会立刻带来一个统一的 Agent 世界。

它先做了一件扎实的事：把 Skills 和 MCP 的打包、发现、加载方式公开出来，给不同客户端留出了一块共同地面。

过去，开发者要为不同客户端重复写安装方法；现在，至少有了一套可以共同遵守的格式。

这不等于生态已经共享。但只要更多客户端接入，公共组件持续增加，分发和治理能力跟上，Agent 的一部分能力就有机会跨应用复用。

Agent Plugins 1.0 的价值，不是它今天已经做到了多少，而是它把“共享”从一句愿景，变成了一个可以继续接入、测试和维护的工程问题。

参考资料

扫码关注公众号
扫码关注公众号
扫码加群交流
扫码加群交流