如果你平时用 Claude Code、Codex 或 Cursor 干活，Skill、MCP、插件这几个词，大概已经绕着你转了一年多。最近两周，又多了一个新名词：Agent Plugins。8 月 6 日，Agent Plugins 1.0 正式发布，由 Vercel 发起，AWS、Anysphere、GitHub、Microsoft、OpenAI 共同推出，Google 当天以核心维护者身份加入。GitHub官方博客它定义的事情很具体：一个开放的、不属于任何厂商的标准，把 Agent Skills 和 MCP 服务器打包成可分发的插件，让兼容的 AI Agent 客户端都能发现和加载。Vercel官方博客
它只管一件事：打包
最常见的误会，是以为 Agent Plugins 要取代 MCP 和 Skill。其实三者分工很明确：MCP 负责接工具，Skill 负责告诉 Agent 怎么做事，Agent Plugins 负责把它们收进同一个包。知乎翻译到目录结构上，一个标准插件包长这样：根目录放 plugin.json，声明规范版本和插件名；skills/ 目录放 Skill；mcp.json 写 MCP 的连接方式；再留一个 com.example.client/ 这类命名空间目录，给客户端专属扩展用，别的客户端看到会直接跳过。Skill 和 MCP 不用全都有，客户端也可以只支持其中一个。
1.0 管到的边界，就停在"打包"这一层：插件从哪里下载、怎么安装、谁来审核、用户在哪授权，它都不碰。官方说法很直白：这个格式刻意做得小、做得容易实现，安装、分发、策略和用户体验，都留给每个客户端自己决定。Vercel官方博客所以"AI Agent 的应用商店"目前还只是愿景，现在只有一个通用打包盒，还没有跨厂商的商店。
它解决的问题：一份 Skill，三个客户端，三份配置
同时维护多个客户端 Agent 配置的人，对这种痛最有体会。Agent Plugins 1.0 想解决的，正是 Agent 工具配置的重复维护、版本漂移和团队交接问题。知乎这种混乱离普通用户也不远。小红书有篇笔记说得直白：同一个 Skill，在 Claude Code 上写好了，想在 Codex 上也用，还得再放一份。小红书还有人干脆把帖子标题写成"我以为 Skill 是插件，装错才懂"。新名词的热闹背后，用户实际在为"每换一个客户端就重新打包一遍"付成本，Agent Plugins 1.0 想终结的就是这件事。
同一时间线：MCP 刚完成史上最大重构
要理解 Agent Plugins 的分量，得看它前后十天发生的事。7 月 28 日，MCP 发布了诞生以来最大规模的重构：彻底移除 Session，协议层不再持有状态。知乎旧版要先 initialize 握手拿到会话 ID，再带着会话 ID 调工具，服务器端得做会话亲和、粘性路由，部署到 Serverless 环境很痛苦；新版每个请求自我描述，OAuth 2.1 成了强制要求，状态管理被踢回应用层。
开发者社区的反应很有意思。InfoQ 把一个热问搬上知乎，标题直接用了开发者的追问："MCP 走向无状态，开发者追问「这不就又变回 API 了吗？」"这个问题背后其实是认可：去掉会话包袱之后，MCP 更像成熟的基础设施，而不是新奇的玩具。
几乎同一时间，负责 Agent 与 Agent 之间通信的 A2A 协议满一周年，150 多家组织把它跑进了生产环境。把 Agent Plugins 也算进来，协议层的分工其实已经定局：Agent 连工具走 MCP，Agent 对话走 A2A，打包分发层来了个新人。接下来要争的，不再是协议本身，而是打包、分发、信任这几块空白。
最反常识的一点：发明这一切的没上桌
再看一遍参与名单：GitHub、AWS、Anysphere、Microsoft、OpenAI、Vercel，加上当天加入的 Google——缺席的那个名字是 Anthropic。但 MCP 是 Anthropic 发明的，Agent Skills 是 Anthropic 发明的，连 Agent Plugins 借鉴的 .claude-plugin 打包形式，都是 Claude Code 先用的。有基于 30 多个信源交叉验证的深度研究记录了当时的名单：8 月 6 日剧情反转，OpenAI、AWS、微软、Vercel、Cursor、GitHub 六家发布 Agent Plugins 1.0.0，把「Agent Skills + MCP 配置」打包成可移植插件，Google 当天加入，Anthropic 不在名单里。发明这一切的公司，成了唯一没上桌的一家。知乎这不是技术上的失败，更像开放标准的结构性宿命：Anthropic 把 MCP 捐给了 Linux 基金会，技术开放给全行业，但开放标准在行业手里，长成了别人的生态位。该研究还判断，"Anthropic 没上桌"不是偶发，而是开放标准治理的结构性宿命。
社区也不全是叫好声。微博上有人直接泼冷水：搞完 MCP 搞 Skill 搞 Cli，现在又可以继续搞一遍"插件"了，"大佬"们这是又被续命了。微博这种疲劳感不是没道理：如果生态只是换个包装重做一遍，体验没有增量，用户迟早会用脚投票。
还有一个误读值得澄清："Anthropic 没上桌"不等于 Claude Code 用不上插件。AWS 官方插件仓库里写得清楚，他们的 Agent Plugins 目前已支持 Claude Code、Codex 和 Cursor。GitHubAnthropic 缺的是标准的制定席位，不是客户端的插件能力。
要不要迁配置，分三种人
先看官方口径：已有的 skills 和 MCP server 配置继续受支持，不要求立即迁移。知乎支持范围上，Agent Plugins 1.0 已在 VS Code、Copilot CLI、GitHub Copilot SDK 和 GitHub Copilot 应用上全计划可用。GitHub官方博客这些客户端里还能直接从内置的 Awesome Copilot 市场安装规范插件。其他 Agent 客户端的支持情况，需要单独确认。
所以我的建议是，按三种人决定动不动。只用一个客户端的个人用户：先别动。你现在的配置照常用，迁移暂时不带来任何增量，反而引入运行时不确定性。
同时维护多个客户端的团队：值得趁这次把配置理一遍。实战文章里的三条迁移原则可以直接抄：公共能力集中，客户端差异隔离，密钥和权限留在部署环境，别写进插件包。知乎验收标准是行为等价，旧入口先留着，别一次性删光。
等企业级推广的团队：可以再等等。管理工具其实已经有了，GitHub 的企业托管设置里可以用 enabledPlugins 自动安装或屏蔽指定插件，把安装来源限制在受管市场，不需要为新标准单独建一套策略。GitHub官方博客但跨厂商的分发、审核和信任链条还是空白，这个状态下把插件放进关键生产环境，还是早了点。
三个值得盯的信号
一、Anthropic 会不会入局
它是 MCP 和 Skill 的发明者，Claude Code 又是当下最活跃的 Agent 客户端之一，它如果跟进标准，"通用插件包"才算真正闭环。官方规范仓库里，1.1.0 版已经挂上了工作草案的牌子。GitHub
二、会不会出现真正的跨厂商商店
像 npm 一样收敛成一个生态，还是像早年 Java applet 一样各家各开一个店，决定了这个标准是入口还是摆设。
三、供应链安全
插件打包意味着一包能力装进即运行，权限边界怎么画、恶意插件怎么防，还没有统一答案。一次大规模投毒事件，就可能让企业采用集体踩刹车。
协议层的故事已经收敛，真正决定胜负的，是谁能把打包、分发、信任做成一条龙。对大多数用户来说，现在不用急着迁配置，先盯住这三个信号，再动手也不迟。
