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「从拼模型转向拼生态」的信号。本文给出完整时间线、核心数据表、设计取舍拆解、横向对比、安全争议与FAQ，并附六步评估/打包清单。
01 发生了什么：一条从MCP到Agent Plugins的时间线
AI Agent的「可扩展性」问题不是新话题。开发者真正的痛点是：Agent Skills解决了「怎么给Agent教一套可复用技能」，MCP解决了「怎么让Agent连上外部工具和数据」，但两者的打包、发现方式在不同客户端（ChatGPT、Cursor、Copilot……）里各有一套目录结构和配置习惯——想让同一个扩展包同时在这些产品里跑，此前需要为每家平台各写一份。
- 打包碎片化：同一套 Skills / MCP 配置要为 Claude Code、Cursor、VS Code Copilot 各打一版包装。
- 发现机制不互通：客户端认目录习惯不同，跨产品「一次开发、多端加载」几乎不可能。
- 安全责任悬空：恶意 Skill 已出现绕过主流扫描的案例，而新标准刻意不覆盖信任与沙箱——风险原样传给下一步。
- 生态话语权博弈：统一包装利好谁、中国大厂是否缺席，直接影响长期采用路径。
Agent Plugins要做的，就是把Skills和MCP服务器这两种组件，统一装进同一个「包装盒」。完整时间线如下：
| 时间 | 事件 |
|---|---|
| 2023年3月 | OpenAI推出ChatGPT Plugins，允许第三方为ChatGPT开发插件，是早期较开放的扩展生态 |
| 2024年1月 | OpenAI推出GPTs商店后，逐步关闭Plugins，转向更封闭的平台模式 |
| 2024年11月 | Anthropic发布MCP（Model Context Protocol），标准化Agent连接外部工具/数据的方式，后捐赠给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 Plugins 1.0，谷歌同日加入核心维护者行列 |
Agent Plugins并不是从零发明能力，而是在 MCP（连接）与 Agent Skills（教学）之上，补上「打包与发现」这一层工程契约。
02 核心数据一览与横向对比：它和前辈们差在哪
先把规范本身的关键事实摊开，再和 ChatGPT Plugins / MCP / Agent Skills 并排对照：
| 项目 | 内容 |
|---|---|
| 规范版本 | Agent Plugins 1.0.0（状态：工作草案） |
| 发起方 | Vercel（发起提案方） |
| 技术指导委员会（TSC） | 亚马逊（AWS）、Cursor开发商Anysphere、微软、OpenAI、Vercel；谷歌8月6日以核心维护者身份加入 |
| 标准覆盖的组件类型 | 仅2种：Agent Skills、MCP服务器 |
| 核心文件 | 根目录plugin.json清单文件；skills/目录存放技能；mcp.json描述MCP服务器配置 |
| 发布首日支持客户端 | ChatGPT与Codex、Cursor、GitHub Copilot、Kiro、VS Code |
| 治理方式 | 开放许可、公开仓库（GitHub agentplugins/agent-plugins-spec），无单一公司主导路线图 |
| 标准明确不覆盖 | 安装机制、分发/市场、权限模型、沙箱隔离、信任与来源校验、用户体验 |
*数据来源：Vercel官方博客、agent-plugins.org规范文档、Google Developers Blog（均为2026年8月6日发布）。*
| 标准/产品 | 发布方 | 解决的问题 | 现状 |
|---|---|---|---|
| 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工作草案，谷歌已跟进加入 |
可以看到，Agent Plugins并不是要取代MCP或Agent Skills，而是在这两层协议之上加了一层「打包契约」——它解决的是「最后一公里」的工程摩擦，而不是重新定义Agent怎么调用工具。
03 深度拆解：它到底标准化了什么，又为什么不多做
1. 一个清单文件，两种组件
Agent Plugins的技术设计其实很「小」：一个插件就是一个目录，根目录放一个plugin.json清单，声明这个包遵循哪个版本的规范。如果插件里带了技能，就放在固定的skills/目录下，且必须符合Agent Skills规范定义的SKILL.md格式；如果带了MCP服务器配置，就写进mcp.json，支持stdio、Streamable HTTP等多种连接方式。客户端只要认得这套固定的目录结构，就能自动发现和加载对应组件——不认识的组件类型或格式错误，只需跳过该组件而不是拒绝整个插件。此外还留了「反向域名扩展命名空间」机制（比如com.cursor.xxx/），允许各家客户端在标准之外附加自己的私有能力，不会污染通用部分。
my-agent-plugin/
├── plugin.json # 清单：声明规范版本
├── skills/ # Agent Skills（须符合 SKILL.md）
│ └── .../SKILL.md
├── mcp.json # MCP 服务器配置（stdio / Streamable HTTP 等）
└── com.cursor.xxx/ # 可选：客户端私有扩展命名空间2. 故意留白的部分，才是真正的博弈焦点
规范文本里明确写着：v1版本「不定义安装机制、不定义分发协议、不定义权限模型、不要求沙箱隔离、不做信任与来源校验、不涉及用户体验」——这些统统留给各家客户端自己决定。换句话说，Agent Plugins解决的是「包装长什么样」，不解决「这个包能不能信、装的时候有没有风险、去哪儿下载」。这不是疏漏，而是刻意为之的设计取舍：范围越窄，各方越容易达成一致、越容易落地。但代价是，恰恰最难、最要命的问题——谁来判断一个插件是否安全——被明确甩给了每一个客户端自己去解决。
3. 为什么这件事现在做，而不是更早
MCP和Agent Skills各自走过了「厂商自造标准→开放捐赠→行业跟进」的路径（MCP捐给了Linux基金会，Agent Skills由Anthropic主动开放）。这一次Agent Plugins从第一天就是多家公司共同制定，某种程度上是行业吸取了此前「先各自为战再艰难统一」的教训，也说明Skills和MCP的采用规模已经大到「不统一打包方式，大家都要重复劳动」的临界点——据统计，Agent Skills规范发布后半年内采用工具已超过32款。
影响与背景：从「拼模型」到「拼基础设施」
这次发布还有一个耐人寻味的时间点——8月7日正是GPT-5发布一周年，OpenAI选在这个节点前一天官宣Agent Plugins，同时还在同一周更新了面向免费用户的GPT-5.6 Luna模型（解除文字对话次数限制）和面向付费用户的GPT-5.6 Sol（新增「思考强度」滑块）。这种安排释放的信号很明确：过去两年AI行业比拼的是模型参数和榜单排名，但现在无论是OpenAI还是谷歌、微软，都在同步往「基础设施/生态」这条线上发力——用Google在官方博客里的说法，「打包是不体面但必要的基础设施，这种东西应该被共享，而不是被重新发明五次」。这也和更广泛的行业叙事吻合：MCP解决了「连接」，Agent Skills解决了「教学」，Agent Plugins解决了「分发」——三层协议叠在一起，才勉强拼出一个「Agent真正能被规模化复用」的技术闭环。
04 六步落地：如何评估与打包一套Agent Plugins
规范刚发布，生产环境不必盲目全量迁移；但若你已在多客户端维护 Skills / MCP，可用下面六步降低重复劳动与安全风险：
- 盘点现有组件：列出你已有的 Agent Skills（
SKILL.md）与 MCP 服务器配置，确认它们各自符合现有规范，而不是平台私有格式。 - 建统一目录骨架：新建插件根目录，写入声明规范版本的
plugin.json，并把技能放进skills/、把 MCP 配置写入mcp.json。 - 先在首日支持客户端验证：优先在 ChatGPT/Codex、Cursor、GitHub Copilot、Kiro、VS Code 中加载同一包，确认「跳过未知组件」行为符合预期。
- 私有能力走反向域名命名空间：仅某客户端需要的扩展放进如
com.cursor.xxx/，避免污染可移植核心。 - 安全审查独立于标准：标准不覆盖信任校验——安装前走官方市场、核对来源仓库、关注 TOCTOU 类链接替换风险，不要只看 star 数。
- 对齐运行时算力环境：插件再标准，Agent 仍要跑在真实机器上。若工作流依赖 Apple Silicon、iOS 工具链或长时间无人值守 Agent，同步评估裸金属 Mac 节点与虚拟化云实例的损耗与稳定性差异（可参考 裸金属架构宣言）。
05 争议点、可引用数据、FAQ 与决策结论
争议点：开放标准≠没有风险，也≠没有算盘
- 安全问题被明确甩锅给客户端：就在Agent Plugins发布前一个月，安全公司AIR公开演示了一次「假技能」攻击——一个名为
brand-landingpage的恶意Agent Skill，借用一个拥有3.6万星标的知名仓库的信誉，成功绕过了Cisco、Nvidia、skills.sh等多家安全扫描工具，据称触达约2.6万个Agent（部分为企业账号）。核心漏洞是经典的「检查时-使用时」（TOCTOU）时间差：扫描时链接指向的是正常文档，通过审核后再悄悄替换成恶意地址。Snyk同期对近4000个已上线技能的审计也发现，36.8%存在安全缺陷，13.4%含有致命级问题（恶意代码、凭据泄露等）。Agent Plugins标准本身完全没有涉及这类信任与来源校验机制。 - 「这是不是一个太单薄的标准」：开发者工具框架SST的作者Dax Raad公开表示「非常反对」这份标准，认为它是「一个很薄的标准」，真正有用的部分最终还是会被各家客户端做成自己的私有扩展。但也有开发者（如开发者布道师Angie Jones）对此表示欢迎，认为终于有了一种方式，能把自己积累的技能包在不同工具间搬来搬去，不用来回重写。
- 统一「包装规格」到底利好谁：支持者的逻辑是，统一包装能让中小开发者一次开发、同时触达ChatGPT、Cursor、Copilot等所有主流客户端。但反过来看，标准往往利好已经拥有用户基数的头部客户端——用户还是要先打开一个具体的Agent产品才能用上它，头部效应可能反而被这层「统一插件层」进一步固化。
- 中国大厂集体缺席：Agent Plugins的五个创始技术指导委员会成员以及后来加入的谷歌，清一色是美国公司；阿里、百度、字节、腾讯等在国内已经普遍支持MCP协议、甚至各自搭建了MCP广场的厂商，均未出现在这份标准的制定名单里。这既可能是时间差，也可能预示着中美AI Agent生态在底层协议层面的又一次「平行发展」。
可引用硬核数据（发稿口径）
- 规范版本与状态：Agent Plugins 1.0.0，工作草案；2026年7月24日草案首发，8月6日五方公开联合发布，谷歌同日加入核心维护者。
- 覆盖范围：仅打包 Agent Skills 与 MCP 服务器两类组件；首日支持客户端包括 ChatGPT/Codex、Cursor、GitHub Copilot、Kiro、VS Code。
- 安全侧旁证：AIR 演示假技能绕过 Cisco / Nvidia / skills.sh 扫描，据称触达约 2.6 万 Agent；Snyk 审计近 4000 个技能，36.8% 有缺陷、13.4% 含致命级问题。
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从第一天就是多家公司共同治理的开放标准，任何一家单独退出也不影响规范本身的存续。但开放标准也有自己的风险——如果实际使用者寥寥，或者各家客户端更愿意投入资源做私有扩展，标准同样可能被「晾在一边」。目前处于刚发布阶段，能否真正被广泛采用还需要观察后续几个月的落地情况。
数据与报道来源（信息截至2026年8月7日整理，发版后请以最新官方文档为准）：
Vercel 官方博客：Introducing Agent Plugins（2026-08-06）
agent-plugins.org：Agent Plugins Specification 1.0.0（工作草案）
Google Developers Blog：Agent Plugins package your skills, tools, and more（2026-08-06）
The Next Web：OpenAI and four rivals just agreed on one standard for AI agents
Virtualization Review：Cloud Giants Back Agent Plugins for Cross-Client AI
开放标准统一了「包装盒」，但没有统一信任、沙箱与安装路径；各客户端私有扩展仍会继续分化，恶意 Skill 风险也不会因为多了一层 plugin.json 而自动消失。对企业侧来说，把 Agent 工作流全部押在单一虚拟化云实例上，常见问题是 Hypervisor 损耗、Apple Silicon / iOS 工具链兼容差、以及长周期无人值守稳定性不足。若你的团队需要零损耗原生算力、稳定 iOS CI/CD 与 AI Agent 7×24 自动化，ZUKCLOUD 的裸金属 Mac mini 云端节点通常是更优解：独占 Apple Silicon 物理机、无 Hypervisor 损耗、7×24 在线、按天/周/月弹性下单。可先看 定价页 或直接前往 下单页。