2026年8月6日，OpenAI、微软、亚马逊、Cursor和Vercel共同推出Agent Plugins 1.0.0，试图为AI Agent建立一种跨产品通用的插件封装格式。开发者可以把操作说明、脚本和参考资料组成的Agent Skills，与连接数据库、云服务及开发工具的MCP服务器放进同一个目录；理论上只需打包一次，就能在ChatGPT、Codex、VS Code、Cursor、GitHub Copilot和Kiro等兼容客户端中使用。它要解决的不是模型能力问题，而是Agent生态正在出现的格式碎片化：同一项能力目前往往要为不同产品分别编写清单文件、修改目录结构并维护多个分支。不过，1.0.0规范仍标注为“工作草案”，目前只统一封装方式，没有规定插件商店、安装协议、权限模型、沙箱隔离和来源验证。因此，它更像Agent生态的“包格式”，还不是一个可以放心安装任意插件的成熟应用商店。
文章作者、来源：Jonathan Hefner，Vercel技术团队成员
Agent有了技能，却没有通用的“包装盒”
AI Agent生态过去一年形成了两类重要扩展能力。
第一类是Agent Skills。它们通常由一份SKILL.md文件、相关脚本和参考资料组成，用来告诉Agent如何完成某类工作。比如，部署一个网站、分析财务文件或检查代码安全时，技能可以提供操作步骤、注意事项、验证规则和可直接执行的程序。
第二类是MCP服务器。MCP负责让Agent连接外部工具和数据，例如读取数据库、操作GitHub、查询云平台状态，或者调用企业内部系统。Skills偏向“教会Agent怎样做”，MCP则偏向“给Agent提供可以实际调用的工具”。
问题在于，这些组件此前缺少统一的封装方式。即使一项技能或MCP服务器的核心内容完全相同，开发者把它接入不同Agent产品时，仍可能需要分别修改清单文件、目录结构和配置字段。久而久之，同一个扩展会产生多个客户端专用版本；其中一个版本修复了错误，其他分支却未必同步，最终形成Google所说的“分叉与漂移”。
Agent Plugins要提供的，就是这些能力外面那只通用的包装盒。其角色更接近JavaScript生态的package.json或容器领域的OCI格式：它不取代里面的代码和协议，而是统一描述这些东西应当怎样被组织、发现和加载。
一个插件，本质上就是一个目录
按照1.0.0版规范，一个Agent Plugin是具有固定结构的目录，根目录必须包含plugin.json。最简清单只需要声明所采用的规范版本和插件名称。
如果插件包含技能，它们统一放入skills/目录，每项技能拥有自己的SKILL.md，还可以附带脚本、参考文件和其他资源。如果插件需要连接外部工具，则在根目录放置mcp.json，声明一个或多个MCP服务器。
MCP部分目前支持三种连接方式：在本机启动进程的stdio、当前推荐的Streamable HTTP，以及为了兼容旧系统保留的HTTP+SSE。不同客户端不必支持全部传输方式，但至少要支持stdio或Streamable HTTP中的一种。
这种固定结构带来的直接好处是，客户端不必猜测文件在哪里，插件作者也不需要针对每个产品重新设计目录。一个兼容客户端即使只支持Skills、不支持MCP，也可以继续读取技能部分；某个MCP配置出错时，规范要求客户端尽可能跳过出错的服务器，而不是让整个插件完全失效。
Agent Plugins还允许厂商保留专属功能。客户端可以用反向域名建立自己的扩展命名空间，例如com.example.client。其他客户端遇到不认识的专属配置时应当忽略它，而不是拒绝整个插件。这让标准能够提供共同底座，同时不强迫所有产品拥有完全相同的功能。
首批兼容产品已经覆盖主要编程Agent
官方兼容列表目前包括VS Code、Cursor、GitHub Copilot、ChatGPT与Codex，以及亚马逊的Kiro。Vercel发起了最初的规范提案，之后由AWS、Cursor母公司Anysphere、微软、OpenAI和Vercel共同建立初始技术指导委员会；GitHub也参与了规范完善。
Google在发布当天宣布加入核心维护工作，并开始让相关产品支持这一格式。Google计划在Agents CLI和Data Agent Kit中采用Agent Plugins，使开发者能够把BigQuery、Spanner和Cloud SQL等数据能力组合成可移植插件。
这组参与者值得关注，因为它们在模型和产品层面并非同一阵营。微软拥有VS Code和GitHub Copilot，与OpenAI关系密切；Cursor是独立AI编程工具；AWS拥有Kiro，同时在云市场与微软和Google竞争；Vercel则希望成为AI应用部署平台。它们愿意共同制定封装标准，说明插件碎片化已经开始增加所有厂商的维护成本。
规范采用公开许可，技术讨论和决策也计划在公共项目中进行。它至少在制度设计上试图避免由单一模型公司完全控制格式。不过，开放治理最终是否有效，仍取决于后续版本的决策过程，以及各家产品会不会大量依赖自己的专属扩展。
它刻意没有解决什么
Agent Plugins最容易引起误解的地方，是“插件”这个名称会让人联想到浏览器扩展或手机应用商店。实际上，目前的1.0.0版本只统一了包装格式，没有建立完整的插件分发与安全体系。
Google的官方解读明确指出，第一版没有规定插件应当通过什么协议安装、从哪里搜索和下载，也没有统一权限申请、用户确认、运行沙箱、发布者身份及来源验证。这些工作仍由各个Agent客户端自行完成。
规范虽然要求插件内的文件路径不能通过../或符号链接逃离插件根目录，但官方特别说明：这种路径约束不等于对插件进程进行沙箱隔离。一个通过stdio启动的MCP服务器仍然可能执行程序；它究竟可以访问哪些文件、环境变量、网络和用户数据，要由客户端的权限体系决定。
远程MCP端点原则上必须使用HTTPS，插件也不得直接把密码或其他秘密写进公开的请求头与环境配置中。不过，1.0.0没有提供通用OAuth配置或可移植的凭证引用机制，认证发现、用户登录和凭证保存仍由客户端处理。
因此，统一格式同时也可能提高恶意扩展的传播效率。开发者可以“一次打包、到处运行”，攻击者理论上也能这样做。未来真正决定该标准能否大规模使用的，可能不是目录结构，而是签名、权限提示、供应链审查、自动更新和撤销机制能否及时跟上。
为什么第一版只容纳Skills和MCP
许多Agent产品还有命令、事件钩子、子Agent模板、界面组件以及自定义工作流。制定者没有在第一版中强行统一这些内容，而是只选择Skills和MCP两种已经形成一定跨平台基础的组件。
这是一个偏保守但现实的选择。标准如果一开始就试图规定所有Agent能力，很容易变得庞大，而且会把某个产品当前的设计固化成整个行业的长期规则。Agent Plugins先解决最明确的问题：把Agent的操作知识和工具连接放进同一个可搬运的软件包。
Google还特别提醒，不是每一项独立技能或每一个MCP服务器都需要被包装成插件。插件更适合一组需要共同安装、共同版本管理和共同迁移的能力。例如，一套数据库开发插件可以同时包含SQL查询技能、数据库MCP连接、故障排查指南和部署脚本；如果只是单独一份简单说明文件，直接以技能形式分发可能更合适。
真正被削弱的可能是平台锁定
如果标准获得足够多客户端支持，开发者不必因为团队从Cursor换到VS Code、从Codex换到其他Agent，就重新建设全部技能和工具连接。个人或企业长期积累的Agent能力可以跟随用户迁移，底层模型和客户端因而更容易被替换。
这会改变Agent平台的竞争方式。厂商不能只靠封闭的插件格式留住用户，而需要在模型质量、执行可靠性、权限控制、界面体验和插件发现能力上持续竞争。对开发者而言，可移植插件也意味着一次投入能够覆盖更多潜在用户，不必为每一个Agent市场重复维护几乎相同的项目。
但真正的可移植性仍有边界。客户端可以只实现规范的一部分，不同产品的授权机制与执行环境也不相同；插件虽然能被识别，却未必在每个客户端上获得完全一致的行为。大量使用厂商专属命名空间的插件，还可能在形式兼容的外表下重新形成事实锁定。
此外，MCP最初由Anthropic推动，但Anthropic目前没有出现在Agent Plugins公布的初始核心维护者或首批正式兼容客户端名单中。这并不意味着Claude未来不会支持该格式，却说明新的封装标准尚未覆盖所有主要Agent阵营。
一个标准是否成功，要看插件能不能真的流动
Agent Plugins目前最大的价值不是技术复杂度，而是让多家竞争厂商承认了同一个问题：模型可以调用越来越多的工具，但如果每个平台都拥有自己的插件包装方式，Agent生态会重演早期移动应用和浏览器扩展彼此割裂的历史。
第一版规范非常小，甚至没有解决插件如何找到、安装和信任。但这种克制也可能是它的优势。它先统一最基础、最容易形成共识的一层，让Skills和MCP服务器拥有共同的运输方式，再把权限、分发和更多组件留给后续版本。
需要注意的是，官方规范页面虽然标注版本为1.0.0，状态仍是“Working Draft”，后续细节存在调整可能。目前支持也主要来自参与制定标准的厂商，尚不能证明更广泛的Agent生态已经接受它。