@mylifcc: Agent Skills 已经解决了“按需注入专业知识”的问题，但分发与绑定一直是烂摊子。Agent Plugins 1.0.0 试图把这个烂摊子收成一个可移植的目录。Agent Plugins 的价值不在于发明了什么新能力，而在于承认并…

Agent Skills 已经解决了“按需注入专业知识”的问题，但分发与绑定一直是烂摊子。Agent Plugins 1.0.0 试图把这个烂摊子收成一个可移植的目录。Agent Plugins 的价值不在于发明了什么新能力，而在于承认并正式处理了“能力需要一起旅行”这个工程现实。它把 Skills 和 MCP 从“各自可移植、组合时却要手写胶水”的状态，推进到了“有一个被多方认可的盒子”。

Agent Skills 的核心价值已经很清晰： 把一段可复用的指令、参考资料和脚本放进一个文件夹，模型只在任务匹配时才加载，避免把部署手册塞进修 CSS 的上下文里。Google 自己在 google/skills 和 Agents CLI 里已经重度依赖这套东西。

但 Skills 从来没有解决工具依赖的问题。一个真正有用的 skill 往往需要 MCP server： 指令在 SKILL.md 工具在 MCP server 两者之间的绑定关系，写在 README 里，或者每个客户端各自发明一套打包方式。

结果是：作者写一次，就得为不同客户端重写安装片段；客户端则各自发明 bundle 格式。Agent Plugins 的目标很克制——标准化这个盒子，而不是重新发明盒子里的东西。Skills 和 MCP 本身已经是可移植的，缺的只是把它们绑在一起的便携容器。

什么是插件？ 插件就是一个目录。 根目录必须有 plugin.json，skills 固定放在 skills/ 下（只看一层，不递归），MCP 配置固定放在根目录的 mcp.json。没有花哨的发现路径，没有优先级规则，没有“你可以放在任何地方然后声明位置”的自由度。固定位置换来的是可检查性、版本控制友好，以及客户端实现成本极低。 失败是被刻意设计成可隔离的。这点比表面看起来更重要。如果某个 MCP server 起不来，或者某个 skill 的 SKILL.md 不合规，客户端必须继续加载其他组件，而不是整包拒绝。规格把失败边界拆得很清楚：插件级、组件类型级、单个条目级。这直接决定了“把指令和可能需要联网的 server 放在同一个文件夹里”这件事是否安全。一个 all-or-nothing 的 bundle 在真实场景里几乎不可用。 扩展命名空间是有意识的“逃生舱”。hooks、commands、subagents、rules 这些东西目前太客户端特定，强行标准化只会冻结某一方的路线图。规格因此给了每个客户端一个 reverse-domain 命名空间（可以出现在根目录，也可以出现在 plugin.json 的 extensions 字段）。不认识的命名空间直接忽略，核心保持可移植。这是在标准化与差异化之间做的现实妥协，也是未来最容易再次碎片化的地方。

几个容易被忽略、但工程上很关键的设计：

mcp.json 强制显式声明 transport。stdio、streamable-http、sse 三种，字段要求不同。客户端不用再猜配置对象的形状。command 只能是单个可执行 token（或 ./ 开头的插件相对路径），不支持 shell 命令，也不做占位符展开——这是为了安全和控制。 两个占位符语义清晰且有意不对称：{PLUGIN_ROOT} 是只读的包内容，{PLUGIN_DATA} 是客户端提供的可写位置。写进 PLUGIN_ROOT 的状态，下次更新插件就消失。展开只发生在 args、env 的值和 cwd，而且是单次文本替换。 凭证被明确排除。规格禁止在 headers 或任何地方放 secret，也没有定义可移植的 OAuth 或 credential reference。认证永远是客户端的责任。这既是务实，也是当前最大的缺口——任何需要认证的远程 server，插件只能把“需要认证”这件事带过去，真正的凭据配置还得各客户端自己做。 manifest 是封闭 schema。未知顶层字段会被报告但忽略，类型错误是致命的。这种严格性对长期兼容性有利，但对迁移中的大型 skills 库可能一开始会踩坑（尤其是“skills 只能发现一层”这条规则，很多人已经习惯按类别建子目录）。

Agent Plugins 最初由 Vercel 发起，TSC 核心维护者来自 Amazon、Cursor、Microsoft、OpenAI、Vercel。Google 以 Kevin Hou 为代表加入 Core Maintainer，并已经把两套东西做成了 Agent Plugins：

Agents CLI：把他们自己的 agent 构建、评估、部署、可观测性、发布相关的 expert skills 打包成标准插件。 Data Agent Kit：把 Spanner、Cloud SQL、AlloyDB，以及 BigQuery 相关的 starter pack 做成可移植插件，直接进任何兼容的 coding agent。

这不是“我们也支持一下”的姿态。Google 在用自己的真实产品验证规格，同时把数据云产品的 agent 能力从“只在 Google 自己的工具里好用”变成“能跟着用户的 agent 走”。对 Cloud 数据产品来说，这是降低采用门槛的很务实一步。

Google Cloud Tech (@GoogleCloudTech): Agent Plugins: Build it once, use it everywhere.