AI 编程工具的下一场争夺，落到了一个小小的 plugin.json 上。
8 月 6 日，Agent Plugins 1.0.0 公开发布。Google Developers Blog 随后宣布加入 Core Maintainer，AWS 和 Vercel 也分别发文支持这套规范；VS Code 文档已经把 Agent Plugins 1.0 与 Copilot、Claude、Legacy OpenPlugin 等格式并列识别。
这条新闻看起来像开发者生态小更新，实则指向 Agent 工具链的一个现实矛盾：技能、脚本、MCP 服务器都能复用，但每个客户端都要自己的包装格式。插件作者为了进 ChatGPT、Copilot、Cursor、Kiro 或 VS Code，常常要维护几份外壳，里面的能力相同，目录和清单字段却不同。
小清单成了接口边界
Google 在公告里把痛点写得很直接：
“The core problem isn’t the components. It’s the manifest.”
这句话抓住了 Agent 插件生态的卡点。MCP 已经负责把模型接到工具和数据，Agent Skills 负责沉淀可复用指令和资源，缺的那一层是把两者一起打包、分发、加载的共同外壳。
Agent Plugins 1.0.0 给出的外壳很克制。规范页写明，一个插件是单一目录，根目录必须有 plugin.json；技能固定放在 skills/，MCP 服务器配置固定放在 mcp.json；客户端私有能力放进反向域名目录，例如 com.example.client/。plugin.json 不能把组件改到别的路径，也不能内联 MCP 配置。
这个约束带来一个实际好处：客户端发现插件时少了猜测。规范要求清单使用 https://agent-plugins.org/schemas/1.0.0/plugin.schema.json，MCP 配置使用对应的 mcp.schema.json。VS Code 文档也用同一 schema 识别 Agent Plugins 1.0 包，并列出 Copilot、Claude、Legacy OpenPlugin 等兼容格式。
大厂先同意包装，权限仍各管各的
参与者名单比格式本身更能说明风向。Google 公告称，Agent Plugins 由 Amazon、Cursor、Microsoft、OpenAI 和 Vercel 的 Core Maintainers 技术指导委员会发布，Google 由 Kevin Hou 代表加入维护组。Vercel 的发布稿称 1.0.0 已公开可用；AWS 则把它解释为面向 Kiro、VS Code、Cursor 等客户端的一次“写一次、发多处”的包装标准。
这并不代表插件市场已经统一。规范刻意留下了很多空白：安装机制、分发协议、权限模型、沙箱、安全来源、用户体验都不在 1.0.0 范围内。换成人话讲，大家先同意“包长什么样”，至于谁能装、怎么授权、出错怎么拦、插件商店如何排序，仍由各家产品决定。
这个边界很重要。Agent 插件天然会连接本地文件、数据库、浏览器、云 API 和企业系统。如果一个开放标准一口气定义权限和分发，落地阻力会立刻变大。现在的 1.0.0 选择从低摩擦处开刀：目录、schema、加载规则、失败隔离。
规范还把失败边界写细了。skills/ 缺失不能当成错误；某个 MCP server 启动失败，客户端应跳过该条目并继续加载其他组件；路径必须留在插件根目录内，../bin/server 这类逃逸路径会被判为无效。这些细节不炫，但直接关系到企业客户端敢不敢加载外部包。
对开发者，少维护一层壳
这套标准的短期价值不在模型能力，而在工程成本。
- 技能和 MCP 可以一起移动：一个团队写了报表查询 MCP，再配一份周报总结 Skill，不必给每个客户端重做目录；
- 客户端能保留差异：各家私有 hooks、agents、commands 可以放在反向域名命名空间，兼容客户端忽略未知目录；
- 审计路径更清楚：固定
plugin.json、skills/、mcp.json后，企业安全团队能更容易扫清单、看入口、禁用高风险组件。
这也是它对中文开发者的增量价值。国内 Agent 工具正在从“接模型 API”走向“接业务系统”。一旦插件格式碎片化，团队会把大量精力花在适配外壳上；标准外壳成熟后，精力才更可能转回具体能力：能不能查准库存，能不能写对 SQL，能不能把审批、工单、监控和文档串起来。
验证点在兼容客户端
Agent Plugins 1.0.0 还处在 Working Draft 状态，规范可用不等于生态成熟。后续要看三个具体节点。
第一，看兼容客户端数量。Google 已经提到 Data Agent Kit 和 Agents CLI，VS Code 文档已经给出识别逻辑，AWS 提到 Kiro、VS Code、Cursor 等客户端。若 ChatGPT、Codex、Copilot、Cursor、Kiro 的加载行为逐步收敛，插件作者才会把它当默认包格式。
第二，看企业权限层是否跟上。规范没有替各家处理授权和沙箱，这会让早期落地更快，也会把风险留给客户端实现。企业采购时会盯住批准流、凭据隔离、网络访问、日志审计和撤销机制。
第三，看组件标准能否继续互补。MCP 负责运行时连接，Agent Skills 负责可复用知识，Agent Plugins 负责打包。如果三层各守边界，生态会变轻；若客户端开始把私有能力大量塞进扩展目录，便可能回到碎片化。
稳妥的读法是：Agent 时代的标准化先从“包装盒”开始。模型名字还在变，插件目录先变得可预测。对开发团队来说，这类不起眼的约定，往往决定一个工具能否从个人效率玩具走进团队工程流程。
参考来源：Google Developers Blog、AWS 开源博客、Vercel、Agent Plugins 规范、VS Code 文档、CocoLoop；核验 Agent Plugins 1.0.0 版本、Core Maintainers 参与方、plugin.json/schema 口径、skills 与 mcp.json 固定位置、VS Code 兼容格式和失败隔离规则。