首页 / 博客 / Agent Plugins
ENGINEERING_BLOG · 2026.08.07

Agent Plugins是什么?
OpenAI联合五巨头发布的AI插件「统一包装」标准

5W 速览:2026 年 8 月 6 日,OpenAI 联合 Vercel、微软、亚马逊、Cursor 母公司 Anysphere 五方组成技术指导委员会,正式公开发布 Agent Plugins 1.0 版规范——一种让 AI Agent 的「技能」(Skills)和「工具」(MCP 服务器)可以打包成同一种目录格式、在 ChatGPT、Cursor、GitHub Copilot、VS Code、Kiro 等不同产品间通用的开放标准。谷歌当天宣布以核心维护者身份加入。这一发布恰好卡在 GPT-5 发布一周年(8 月 7 日)前一天,被外界解读为 OpenAI「从拼模型转向拼生态」的信号。本文依据官方规范与多家报道,拆解它解决了什么、又刻意留下了什么坑。

SECTION 01 读 Agent Plugins 新闻容易踩的坑

  • 把它当成「新协议」:Agent Plugins 不取代 MCP 或 Agent Skills,只是在两者之上加一层统一打包与发现格式;
  • 以为标准管安全:v1 明确不定义安装、分发、权限、沙箱、信任与来源校验——安全责任仍在各客户端;
  • 把「首日支持」当成「已在所有产品上线」:ChatGPT/Codex、Cursor、Copilot、Kiro、VS Code 为首日支持名单;谷歌称将接入 Antigravity、Gemini CLI、Data Agent Kit,发布当日未必全部就绪;
  • 忽略恶意 Skill 先例:发布前约一个月,安全公司 AIR 演示假技能绕过多家扫描器;Snyk 对近 4000 个技能的审计显示 36.8% 存在缺陷、13.4% 含致命级问题——标准本身未覆盖这类校验;
  • 默认「全球厂商都在桌上」:TSC 创始成员与谷歌均为美国公司,阿里、百度、字节、腾讯等国内已普遍支持 MCP 的厂商未出现在制定名单;
  • 与 Agent 运行时环境脱节:打包统一不等于生产环境统一;长稳 Agent、CI 与本机 macOS 算力仍是另一条线,可对照 AI Agent 安全防线 一并评估。

一句话:Agent Plugins 解决的是「包装长什么样」,不解决「这个包能不能信、装的时候有没有风险、去哪儿下载」。

SECTION 02 从 MCP 到 Agent Plugins:发生了什么时间线

AI Agent 的「可扩展性」不是新话题。Agent Plugins 是这条演进链上最新一环,而不是从零发明:

从 ChatGPT Plugins 到 Agent Plugins 的关键节点
时间 事件
2023 年 3 月 OpenAI 推出 ChatGPT Plugins,允许第三方为 ChatGPT 开发插件
2024 年 1 月 OpenAI 推出 GPTs 商店后逐步关闭 Plugins,转向更封闭的平台模式
2024 年 11 月 Anthropic 发布 MCP(Model Context Protocol),后捐赠给 Linux 基金会
2025 年 3 月 OpenAI、Google 相继宣布支持 MCP,行业逐渐统一到这套协议
2025 年 10 月 16 日 Anthropic 在 Claude Code 中推出 Agent Skills,用 SKILL.md 封装可复用指令
2025 年 12 月 18 日 Agent Skills 独立为开放标准(agentskills.io),微软、OpenAI 48 小时内跟进
2026 年 3 月 Agent Skills 采用范围扩大到 32 款以上工具(含 Gemini CLI、JetBrains Junie、AWS Kiro 等)
2026 年 7 月 24 日 Agent Plugins 规范 1.0.0 首次以「工作草案」形式发布
2026 年 8 月 6 日 Vercel 领头,联合 OpenAI、微软、亚马逊、Cursor 正式公开发布;谷歌同日加入核心维护者

Agent Skills 解决「怎么给 Agent 教一套可复用技能」,MCP 解决「怎么让 Agent 连上外部工具和数据」,但两者的打包、发现方式在不同客户端里各有一套目录与配置习惯。开发者想让同一个扩展包同时在这些产品里跑,此前往往要为每家平台各写一份。Agent Plugins 要把 Skills 和 MCP 服务器这两种组件,统一装进同一个「包装盒」。

SECTION 03 核心数据一览:标准化了什么、又为什么不多做

Agent Plugins 1.0 事实卡(截至 2026-08-06 官方口径)
项目 内容
规范版本 Agent Plugins 1.0.0(状态:工作草案)
发起方 Vercel(发起提案方)
技术指导委员会(TSC) 亚马逊(AWS)、Cursor 开发商 Anysphere、微软、OpenAI、Vercel;谷歌 8 月 6 日以核心维护者身份加入
标准覆盖的组件类型 仅 2 种:Agent Skills、MCP 服务器
核心文件 根目录 plugin.jsonskills/ 存放技能;mcp.json 描述 MCP 服务器配置
发布首日支持客户端 ChatGPT 与 Codex、Cursor、GitHub Copilot、Kiro、VS Code
治理方式 开放许可、公开仓库(GitHub agentplugins/agent-plugins-spec),无单一公司主导路线图
标准明确不覆盖 安装机制、分发/市场、权限模型、沙箱隔离、信任与来源校验、用户体验

1. 一个清单文件,两种组件。一个插件就是一个目录:根目录放 plugin.json,声明遵循哪个版本的规范;技能放在固定的 skills/ 下且须符合 Agent Skills 的 SKILL.md 格式;MCP 服务器配置写进 mcp.json,支持 stdio、Streamable HTTP 等多种连接方式。客户端认得这套目录结构即可自动发现和加载;不认识的组件类型或格式错误,只需跳过该组件而不是拒绝整个插件。另留「反向域名扩展命名空间」(如 com.cursor.xxx/),允许各家附加私有能力而不污染通用部分。

2. 故意留白的部分,才是真正的博弈焦点。规范文本明确:v1「不定义安装机制、不定义分发协议、不定义权限模型、不要求沙箱隔离、不做信任与来源校验、不涉及用户体验」。范围越窄,各方越容易达成一致——代价是「谁来判断一个插件是否安全」被明确甩给每一个客户端。

3. 为什么这件事现在做。MCP 与 Agent Skills 各自走过「厂商自造 → 开放捐赠 → 行业跟进」;Agent Plugins 从第一天就是多家共同制定。Skills 采用工具已超过 32 款,不统一打包方式意味着持续重复劳动。

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

SECTION 04 横向对比 + 开发者 6 步落地清单

Agent Plugins 和它的「前辈们」
标准/产品 发布方 解决的问题 现状
ChatGPT Plugins(2023) OpenAI 独家 让第三方为 ChatGPT 加功能 已于 2024 年停用,转向封闭的 GPTs 商店
MCP(2024) Anthropic 发起,后捐赠 Linux 基金会 Agent 连接外部工具/数据的通信协议 已成为行业事实标准,OpenAI、Google 均已支持
Agent Skills(2025) Anthropic 发起,后开放为独立标准 给 Agent 封装可复用的操作指令/工作流 采用工具超 32 款,仍在快速扩张
Agent Plugins(2026) Vercel 发起,五巨头联合制定 把 Skills 和 MCP 服务器统一打包、统一发现 刚发布 1.0 工作草案,谷歌已跟进加入

争议点速览:① 安全被明确甩锅给客户端——AIR 演示的 brand-landingpage 假技能借用约 3.6 万星仓库信誉,绕过 Cisco、Nvidia、skills.sh 等扫描,据称触达约 2.6 万个 Agent;② SST 作者 Dax Raad 称其「很薄」,有用部分会被做成私有扩展,也有开发者(如 Angie Jones)欢迎跨工具搬迁技能;③ 统一包装利好中小开发者「一次开发多端触达」,也可能进一步固化已有用户基数的头部客户端;④ 中国大厂集体缺席制定名单,可能只是时间差,也可能预示协议层平行发展。

  1. 先对齐分层关系:确认你要解决的是「打包/发现」,而不是重写 MCP 通信或 Skills 语义——三者是分层,不是替代;
  2. 盘点现有资产:列出已在用的 SKILL.md 与 MCP 服务器配置,以及目标客户端(ChatGPT、Cursor、Copilot、VS Code、Kiro 等);
  3. 落目录骨架:新建插件根目录,写入符合 1.0 的 plugin.json(至少含规范 schema 与插件名);
  4. 迁入 Skills:将技能放入 skills/,确保每个技能符合 Agent Skills 规范的 frontmatter 与目录布局;
  5. 迁入 MCP:在根目录 mcp.json 声明服务器(stdio / Streamable HTTP 等),勿把 MCP 配置塞进 plugin.json
  6. 做安全与兼容验收:在官方市场或可信来源安装;核对来源与变更历史,不盲信 star 数;用目标客户端分别加载,确认未知组件被跳过而非整包失败。发版后请再打开官方规范核对字段。

SECTION 05 从「拼模型」到「拼基础设施」:可引用数据与来源

  • 时间点信号:8 月 7 日为 GPT-5 发布一周年;OpenAI 同周还更新面向免费用户的 GPT-5.6 Luna(解除文字对话次数限制)与付费用户的 GPT-5.6 Sol(新增「思考强度」滑块),与 Agent Plugins 官宣叠在同一叙事周;
  • 三层闭环:MCP 解决「连接」,Agent Skills 解决「教学」,Agent Plugins 解决「分发」——叠在一起才更接近「Agent 能力可规模化复用」;
  • 硬数字备忘:规范版本 1.0.0(工作草案);组件类型恰好 2 种;Skills 采用工具超 32 款;Snyk 审计近 4000 技能中 36.8% 有缺陷、13.4% 致命级;AIR 案例约 2.6 万 Agent 触达;
  • 谷歌表述:官方博客称「打包是不体面但必要的基础设施,这种东西应该被共享,而不是被重新发明五次」。

以下为可核验官方与第三方来源(信息截至 2026 年 8 月 7 日整理;Agent Plugins 与相关模型更新仍在快速演进,发布前请核实最新数据):

Vercel 官方博客:Introducing Agent Plugins

Vercel Changelog:Introducing Agent Plugins 1.0.0

agent-plugins.org 官方规范站点

Google Developers Blog:Agent Plugins package your skills, tools, and more

The Next Web:OpenAI and four rivals just agreed on one standard for AI agents

统一打包降低了扩展分发摩擦,但并不自动给你一台可长期跑 Agent、跑 Xcode/Metal 的稳定 macOS 主机。云端虚拟化 Mac 在编译、图形加速与 7×24 任务上常有损耗与兼容性风险;对需要零损耗原生算力、稳定 iOS CI/CD 与 AI Agent 自动化的生产环境,MACNOX 的云端物理节点通常是更优解:100% 苹果原装物理机、完整 Root、无 Hypervisor 损耗、按天/周/月弹性下单。也可对照 Agent 安全部署防线GPT-5.6 定价变动 理解生态与成本两侧的变化。

SECTION 06 常见问题 FAQ

Agent Plugins 和 MCP、Agent Skills 是什么关系?会互相替代吗?

不会替代。MCP 负责「Agent 怎么连接外部工具和数据」,Agent Skills 负责「怎么给 Agent 封装一套可复用的操作指令」,Agent Plugins 则是在这两者之上加了一层统一的打包和发现格式,让开发者能把 Skills 和 MCP 服务器一起塞进同一个目录、被不同客户端认出来。三者是分层关系,不是竞争关系。

普通开发者现在需要关心 Agent Plugins 吗?

如果你正在给 Claude Code、Cursor、ChatGPT 等多个 Agent 工具分别开发扩展,且已经在用 Agent Skills 或 MCP 服务器,那么值得关注——用这套格式打包一次,理论上能同时被多家客户端识别,减少重复劳动。如果只是普通用户,短期内感知不会很明显。

这个标准安全吗,会不会被恶意插件利用?

标准本身不提供安全保障——它只定义「包装长什么样」,不涉及扫描、沙箱、来源校验。安全责任完全在各家客户端手里。鉴于此前已经出现过绕过多个主流扫描器的恶意 Agent Skill 案例,建议安装任何 Agent 插件前,仍要通过官方市场、核实来源,不要盲目信任 star 数或「看起来正规」的仓库。

国内厂商(阿里、百度、字节等)会跟进这个标准吗?

目前这些厂商都还没有出现在 Agent Plugins 的制定名单里,但它们此前已普遍支持 MCP 协议。考虑到该标准完全开放、任何客户端都可以自行实现,不排除后续国内工具跟进适配,但目前没有官方公开计划,建议关注后续动态。

Agent Plugins 会不会像 2023 年的 ChatGPT Plugins 一样,过一段时间就被放弃?

两者背景不同。ChatGPT Plugins 是 OpenAI 独家产品、决策权在一家公司手里,说停就能停。Agent Plugins 从第一天就是多家公司共同治理的开放标准,任何一家单独退出也不影响规范本身的存续。但开放标准也有自己的风险——如果实际使用者寥寥,或者各家客户端更愿意投入资源做私有扩展,标准同样可能被「晾在一边」。目前处于刚发布阶段,能否真正被广泛采用还需要观察后续几个月的落地情况。