8 月 6 日，Vercel 发布 Agent Plugins 1.0.0。乍看只是又一个技术规范，但参与方名单让它分量不轻：发起方 Vercel，共同完善者包括 AWS、Anysphere（Cursor 母公司）、GitHub、Microsoft、OpenAI，技术指导委员会由 AWS、Cursor、Microsoft、OpenAI、Vercel 的核心维护者组成，Google 更是在发布当天就加入委员会。一句话概括它的目标——给 Agent 的扩展能力做一个「通用包装盒」，让同一份 Skill 或 MCP 服务，不用为每个客户端重新打包。
一、碎片化：开发者最隐形的税
要理解这个标准的价值，得先看清它要解决的问题。过去一年，Agent 客户端各自为战：ChatGPT、Codex、Cursor、GitHub Copilot、VS Code、Kiro 都支持 Agent Skills 和 MCP servers，但每个产品期望的顶级元数据、发现路径、MCP 配置各不相同。结果就是「重打包税」——同一套底层能力，作者要为每个目标客户端改写一遍元数据、调整目录结构、重新配置。组件本身是可移植的，包装却不是。Agent Plugins 精准地切在这道缝上：它不重新定义 Skill 或 MCP，而是定义「这些组件该住在哪里、客户端怎么发现并加载它们」。
二、一只目录就是全部
Agent Plugin 的本质极简：一个以 plugin.json 为清单的根目录，外加固定位置的组件。最小清单只需两个字段——$schema 和 name。组件被放在约定好的位置：skills/ 目录放 Agent Skills（每个子目录一个，含 SKILL.md），mcp.json 描述 MCP server 配置（支持 stdio、Streamable HTTP 或 legacy HTTP+SSE 传输）。更具巧思的是失败隔离：清单校验通过后，各组件独立校验，一个组件出错不会拖垮其他组件。客户端特有的行为则塞进 com.example.client/ 这类反向域名命名空间，其他客户端直接忽略——厂商特性不会泄漏进通用契约。
三、刻意做小的边界
这个标准最值得称道的，是「知道自己不做什么」。v1 只覆盖打包与可发现性，不碰市场、不分发、不管权限、不管策略、不管运行时环境。它只定义两种可移植组件（Agent Skills 与 MCP servers），命令、钩子、Agent 等仍留在各客户端。技术指导委员会还放话：未来是否加入新组件类型，要看是否出现真实的跨客户端可移植需求与实现者共识。这种克制是有意的——把边界做小，标准才容易落地，生态才有空间在「便携部分」收敛之前自由演进。Google 工程师的总结很到位：「Agent Plugins v1 就是个包格式，仅此而已，克制本身就是重点。」
四、谁在首日就上车
标准发布即被六大客户端支持：ChatGPT、Codex、Cursor、GitHub Copilot、Kiro、VS Code。作者打包一次，插件就能在这些客户端间自动携带。GitHub 还把支持铺进了 VS Code、Copilot CLI、Copilot SDK 与 Copilot 应用，并通过 managed-settings.json 让企业管控允许哪些插件与市场；Google 的 Agents CLI 与 Data Agent Kit 也同步支持。从「各写各的」到「一份格式多家加载」，这是 Agent 生态第一次围绕一小撮共享契约收敛——与此前 MCP 规范在生产服务器落地、A2A 协议移交中立基金会，构成同一股「互操作基建」的暗流。
五、一个绕不开的缺席者
值得客观指出的是，Agent Plugins 建立在 Anthropic 创造的 MCP 与 Agent Skills 之上，但 Anthropic 并未参与这一努力，其自家的 Cowork 桌面工具也有独立插件体系。开发者反应也两极：有人欢迎「我们太需要这个了」，也有人质疑它是「过薄的标准」，真正有用的部分最终还是会落到各客户端的私有扩展里。这些争议恰恰说明，标准只是第一步——没有分发、发现与信任机制的 v1，距离「真正统一的插件市场」还有距离。把盒子定义好，只是让组件能搬家；至于谁能住进哪栋楼、钥匙怎么发，仍是各家自家的生意。