多彩编程 多彩编程MZPH · CODE BLOG
ARTICLE DETAIL

文章详情

深耕前端与后端开发技术的一线实战笔记与踩坑复盘。

AI 圈六巨头发布 Agent Plugins 1.0.0 规范统一插件打包,开创者 Anthropic 缺席

AI 圈六巨头发布 Agent Plugins 1.0.0 规范统一插件打包,开创者 Anthropic 缺席 AI 圈六巨头发布 Agent Plugins 1.0.0 开放规范统一插件打包格式开创者 Anthropic 缺席AI 圈六家巨头罕见地坐到了一起。8 月 6 日一份名为 Agent Plugins 1.0.0 的开放规范正式公开。它做了一件无数 AI 开发者期待已久的事为 AI 智能体的插件制定一个统一的 包装盒。从此一份包就能通行天下无需再为每家客户端重复打包。OpenAI 开发者在官推上发文称一次打包就能在所有兼容的智能体客户端里通用还了一串共建方。这份规范看似普通却精准地戳中了痛点。同一个技能Skill、MCP 服务器MCP Server内核明明相同却要为 Cursor、GitHub Copilot、Codex 等客户端分别重新封装。而且只要有一家更新就得挨个跟着修改。而 Agent Plugins 要终结的正是这种重复劳动。它统一了目录结构、清单文件和 MCP 配置写法。打好一个包支持这套格式的客户端都能识别。Agent Plugins 的工作原理是将左边散装的技能与 MCP 收进中间的 plugin.json 包装盒再一次性分发给 IDE、CLI、企业端等各类客户端。举个例子你开发了一个 查数据库、写周报 的插件其中一个技能是让 AI 把查询结果整理成团队喜欢的周报一个 MCP 服务器负责帮 AI 连接数据库。以前要让这个插件在三个客户端都能使用就得打三份包修改一处就得改三遍。现在只需要打一份包、改一遍就行了。共建者名单里有 AWS、AnysphereCursor 母公司、GitHub、微软、OpenAI、Vercel 六家就连谷歌也在发布当天加入了核心维护者行列。唯独缺少了这套玩法的开创者——Anthropic。统一的是 包装盒不是智能体一个插件通常由两部分组成。一部分是 Agent Skills为模型提供可复用的指令和资源另一部分是 MCP Server负责连接外部工具和服务。这两部分原本就可以跨客户端复用。真正的问题在于最外层每家客户端的目录结构、清单文件、MCP 配置写法都不一样同一个组件换个客户端就得按照新客户端的规则重新打包。而 Agent Plugins 统一了外面的打包方式。一个插件就是一个文件夹。根目录放一份 plugin.json 清单技能放在 skills/ 文件夹中MCP 配置写进 mcp.json 文件。清单里只有 $schema 和 name 两个字段是必填项其他内容都可以通过固定位置找到客户端无需猜测甚至版本号都可以不写。对于各家想添加的 私货比如特有的钩子、命令、界面等都可以放在一个用反向域名命名的目录里。其他客户端不认识这个目录扫描到也会直接忽略。这样公共部分更加简洁、小巧实现起来也不困难。而且它的管理范围很有限。1.0 版本只认可两类可移植组件skills/ 里的技能和 mcp.json 里的 MCP 配置。hooks、斜杠命令、custom agents 等仍属于各家的私有领域并未统一。规范正文目前还标注着 工作草案Working Draft就像官方在旁边轻声提醒 还在修改距离行业认可的成熟标准还有一段距离。简单来说Agent Skills 负责指令MCP 负责连接工具Agent Plugins 负责将这两者装进同一个 包装盒。统一的只是 包装盒里面的智能体并没有改变。一次打包不等于到处运行即便 包装盒 统一了运行环境却远未统一。它只规范了 skills 和 mcp.json 这两类组件的外壳。到了实际运行阶段它就不再干涉安装、分发、权限、沙箱、认证、信任验证、用户体验等方面都由各家客户端自行处理。各家对 stdio、Streamable HTTP、旧版 HTTP SSE 等传输方式的支持也不完全一致。同一个插件在不同客户端能否顺利运行还得看运气。微软还特别提醒了安全问题插件里的 MCP Server 和 hooks 会在本机执行代码安装前一定要看清来源和作者尤其是社区市场里的东西更要小心。OpenAI 自家的打包文档目前使用的还是.codex - plugin/plugin.json 结构与开放规范根目录的 plugin.json 不同。规范只保证兼容的客户端能发现它支持的可移植组件但真正运行起来认证方式和运行环境可能各不相同。因此打包统一并不意味着运行也能统一中间还存在一整条工程链。说到底这次统一的恰好是巨头们最不介意放手的部分。真正有价值的部分如应用市场、权限体系、用户入口以及 hooks、custom agents 等专有能力一个都没有共享。这套结构怎么这样眼熟熟悉 Claude Code 插件的人可能会感到惊讶。plugin.json、skills、mcp.json这不就是 Claude Code 一直在使用的结构吗早在这份标准出现之前Anthropic 就为 Claude Code 打造了一套完整的插件系统根目录有一份.claude - plugin/plugin.json还有 skills、mcp.json、commands、agents并且开设了两个官方市场供用户分享插件。插件等于技能加 MCP 加一份清单 的打包思路Anthropic 是最早实现的之一而且它的体系更加完整技能、钩子、MCP、子智能体、斜杠命令都包含在内。这次的新标准只收录了能通用的两部分即技能和 MCP其他更丰富的部分并未纳入。有意思的是虽然 Anthropic 尚未加入但新标准的格式几乎与它的一致。Claude Code 有一个专门指向插件目录的根变量新标准原样照搬只是换了个名字功能相同骨架也几乎一样。兼容性更是明显。微软的 VS Code 官方文档中默认插件市场就有 anthropics/claude - code 这一项。它既支持新的开放格式又继续认可 Claude 格式的.claude - plugin/plugin.json。OpenAI 的 Codex 更是直接保留了 Claude 原来的变量名以兼容已有的 Claude 插件。可以说大家一起统一了一套 很像 Claude Code 的格式但 Anthropic 却没有参与。开创者成了缺席者一家开创了玩法的公司在别人将这套玩法定为标准时却全程缺席。但这并不意味着 Anthropic 被排除在外。谷歌新推出的两套工具都将 Claude Code 列为适配对象它自己还有两个官方插件市场。更准确地说Anthropic 更愿意打造自己的体系。这次它没有参与统一标准而是继续经营自己从格式到市场、再到分发的闭环。这也不是它第一次在 大家一起参与 的场合中成为显眼的缺席者。熟悉这家公司的人都知道它总是先把自己的体系打磨到极致再考虑是否与他人对齐。这样做的好处是产品自成体系、体验统一但代价是每次行业级的合作它都容易错过。那么为什么是现在呢因为底层标准一旦确定竞争就会上移。打个比方商场的地基可以几家共同建设但地基建好后竞争的就是楼上的店铺和货架了。那是各家公司的核心领域比拼的不再是模型跑分而是插件生态的规模以及谁能让开发者首先想到自己。六家公司这次确定了 盒子 的规格但真正决定胜负的不是 盒子而是里面的智能体——谁能凭借它留住开发者谁就是赢家。
返回列表