本文作者：泊舟（@bozhou_ai）。版权归作者所有，未经授权禁止转载。

如果你已经在用 Agent 或 Skills，可能遇到过这样的情况：提示词写得越来越长，Agent 偶尔能给出很好的结果，但换个模型、换个项目，或者过几周再跑一次，结果就开始漂移。真正让人返工的，通常不是 Skill 不够“聪明”，而是它没有目录规范、测试标准、维护责任和持续检查。

Google Agent Skills 的幕后文章，讲的正是这件事：一个 Skill 如何从快速启动的项目，变成可以由很多团队共同贡献、又不至于失控的产品。

一、项目起点：为 Next 2026 集结的 swarm

这个项目并不是先搭好一套完美平台，再慢慢填内容。它起步于 Google Cloud Next 2026 前的一次高强度协作。

一支由 Developer Advocates（开发者布道师）和 Technical Writers（技术写作者）牵头的跨职能小组，先把 Google Cloud 领域知识整理成 Agent 能读懂、能执行的结构化指令。这个阶段更像一个 swarm：不同角色围绕同一个目标并行推进，而不是等一个大团队按传统项目节奏逐层交付。

项目随后通过官方发布文章对外公布，社区反应很快。原文提到，仓库获得了超过 15,000 个 GitHub stars。更重要的是，Google 内外的开发者和工程团队看到了 Skills 的实际作用：它们可以减少 Agent 的幻觉，并把最佳实践写进执行路径。

Article image

于是，贡献请求不再只来自 Cloud 团队。包括 Ads 在内的其他产品团队，也希望为自己的服务加入 Skill。项目从一次发布冲刺，变成了一个需要长期治理的公共技能库。

二、扩张之后，最难的不是写得更多，而是保持质量

当只有少量作者时，很多质量问题可以靠熟悉项目的人肉眼发现。贡献者一多，情况马上变了：

  • 指令写得含糊，Agent 不知道该在什么时候执行；
  • 链接已经失效，Agent 会沿着错误资料继续工作；
  • 目录和元数据不统一，工具难以自动发现或加载；
  • 没有覆盖异常路径，正常示例能跑，真实任务却容易失败。

这些问题看似只影响一个 Skill，实际会损害整套 Agent 的使用体验。一个仓库如果只鼓励“把内容放进来”，没有标准和自动治理，很快就会变成难以维护的开放文档堆。

因此，Google 选择把发布门槛定得很高：让更多团队可以贡献，同时用流程和自动化守住开发者体验。后面的目录、CI、评测和所有权规则，都是围绕这个矛盾展开的。

三、一个 Skill 的标准骨架

为了让不同 Google 服务的 Skill 看起来像同一种可交付物，仓库规定了统一的目录结构：

{skill-name}/
├── SKILL.md                 # 必需：主指令与 frontmatter 元数据
├── OWNERS                   # 必需：维护者信息，内部保留
├── EVAL.yaml                # 必需：评测提示词套件与评分标准，内部保留
├── reference/               # 可选：深入技术文档、schema
├── scripts/                 # 可选：可执行的辅助脚本
├── assets/                  # 可选：静态资源、图示
└── _internal/               # 可选：测试 mock 与内部数据，内部保留

这里有一个很值得借鉴的设计：把“使用说明”“维护责任”和“怎么证明它有效”都视为 Skill 的组成部分。SKILL.md 是给 Agent 的主入口；OWNERS 说明谁要长期负责；EVAL.yaml 则把评测用例和评分规则固定下来。参考文档、脚本和资源可以按需增加，但不能替代这几个核心约束。

MCP 优先，CLI/API 作为后备

在架构选择上，Google 的原则是：能引用远程 Model Context Protocol（MCP）工具，就优先引用 MCP；只有必要时才退回 CLI 或直接调用 API。

原因不只是接口形式更现代。远程 MCP 服务本身就是为 Agent 工作设计的工具入口，同时可以配合现成的认证和 IAM 治理。这样，Skill 负责说明“该用什么能力、在什么条件下用”，权限和身份管理则由服务端的工具体系承接。

这不是说 CLI 或 API 没有用，而是先问一句：这个能力是否已经有一个可治理的远程工具入口？如果有，Skill 不必再复制一套连接、认证和权限逻辑。

对外发布，不等于把内部仓库原样公开

Google 的 Skill 会先在内部构建和评测，确认工作正常并通过验证后，才走自动化导出规则发布到 GitHub。导出过程中会清理内部资产、所有权信息和评测套件，让公开仓库保持干净，同时避免把内部测试数据和治理细节一起暴露出去。

这是一种“内部先验证，公开时再投影”的方式。公开仓库是交付面，不必承担所有内部开发过程。

四、提交时的自动检查：先挡住低级错误

每个 Skill 进入仓库前，都要经过 CI/CD 流程。原文列出的自动检查大致分三层。

第一层是静态规范：检查 frontmatter 元数据、文件行数、目录布局，以及严格的命名约定。这样，后续工具至少能可靠地找到入口、解析字段，并按统一方式处理目录。

第二层是链接检查：逐个验证 URL，尽早发现 404 或凭空写出的链接。原文特别提到可以使用 lychee 这类链接检查工具。

第三层是 AI 辅助清单：检查指令是否符合要求的结构模式，必要的护栏是否存在。它不是让模型替代测试，而是把容易漏看的结构性要求也纳入自动验证。

GitHub Actions 示例可以怎么拆

如果你维护自己的公开 Skill 仓库，可以把原文示例理解成一条很小但完整的流水线：

  1. 在 main 的 push、针对 main 的 pull request，以及手动触发时运行。
  2. 只授予读取仓库内容的权限。
  3. Checkout 代码，配置 Python 3.12。
  4. 安装 skills-ref，把它加入 GitHub Actions 的可执行路径。
  5. 遍历 skills/*/ 下的每个 Skill，逐个运行 agentskills validate。

示例还把 GitHub 官方 Action 固定到具体提交哈希，而不是完全依赖浮动标签。对一个需要长期稳定运行的公共仓库来说，这个细节有助于让构建输入更可追溯。重点不在于照抄某一份 YAML，而在于把“每个 Skill 都必须过同一套校验”变成合并前的机器动作。

五、提交一次还不够：持续评测要跑在全生命周期里

Skill 面对的环境会持续变化：文档和 API 会更新，底层模型会换，Agent harness 也可能改变。今天表现良好的 Skill，不代表下个月仍然有效。因此 Google 把评测分成提交时和每周两种节奏。

提交时评测：给新 Skill 设定初始质量线

作者需要为每个 Skill 提供多组评测用例。每组至少包含一个任务提示词，以及这次任务应满足的期望和评分标准。新 Skill 先在内部运行，确认准确性和效率达到要求后再发布。

每周评测：寻找已经发生的回归

定期任务会对完整的 Skill 库重新运行评测，目的是发现那些不是代码改坏、而是外部环境变化后逐渐变差的 Skill。它让质量检查从“一次性验收”变成持续监控。

每次评测都要比较同一个 Agent 在“有 Skill”和“没有 Skill”时的表现。Google 关注两个主维度：

  • 准确率：回答质量和任务完成率是否提高；
  • 效率：完成任务消耗的 token 数和时间是否下降。

评测还会在不同 Agent 框架上重复运行，以获得更有统计意义的结果。这样可以避免某个 Skill 只是碰巧适配了某一个模型或某一套 harness。

用 2×2 看增益，而不是只看一个分数

最后，结果会放进“准确率 × 效率”的 2×2 矩阵。这个矩阵的价值在于同时回答两件事：Skill 是否让 Agent 做得更对，以及是否让它用更少的时间和 token 做完。

只看准确率，可能把一个极其耗时的方案误判成好方案；只看速度，又可能把一个快速但经常出错的方案误判成高效。把两条轴放在一起，才能判断一个 Skill 是否带来可测量的综合提升，以及提升究竟来自质量、效率，还是两者兼得。

Article image

六、Skill 是产品，不是写完就走的片段

Google 在实践中得到的另一个结论是：Skill 是一个持续变化的产品，而不是一次性文档。

为此，项目把责任拆成两层：

  • 仓库维护者负责整体健康度、CI 流水线和架构标准；
  • Skill owner负责某个具体 Skill 的长期维护。

例如，产品 API 发生变化时，具体 Skill 的 owner 需要更新它；评测发现质量下降时，也由 owner 跟进修复。仓库维护者保证规则能运行，Skill owner 保证知识本身没有过期。没有这层 ownership，任何自动检查最终都会变成“有人发现问题，但没人负责修”。

七、作者也需要工具：把写 Skill 变成可学习的工作流

写出有效指令和可靠的评测套件，本身需要经验。Google 没有把这件事完全交给作者自行摸索，而是提供了两类支持。

一类是专门服务于作者的内部 Skills，用来辅助设计新 Skill、完善指令，以及编写更稳健的评测。另一类是基于 ADK 构建的 Agent 工具，让多个 Agent 参与作者工作流：可以协助起草、互相批评和自我检查，完成后再导出到主仓库。

这段信息的重点不是“再做一个生成器”，而是把 Skill 的生产过程本身也做成 Agent 可以辅助的工程流程。原文表示，作者工具和 agentic workflow 会在后续文章继续展开。

八、公开 Google Agent Skills 之外，还有内部 DevRel Skills

Google 同时启动了一个平行的内部项目：DevRel Skills。

公开的 Google Agent Skills 面向外部开发者，内部 DevRel Skills 则服务于团队自己的工作。它们把内容转换、SEO 优化、内部报告等重复流程编码成专用 Skill，帮助团队每天更一致、更高效地完成工作。

这两套项目的边界很清楚：一套把 Google 的领域知识交付给外部开发者，另一套把内部协作流程变成团队可复用的能力。内部流程不必全部公开，但同样需要结构、评测和维护。

九、给落地实践者的最小实践清单

如果你现在只有几个零散 Skill，不必马上搭一套很重的平台。可以先把原文的做法压缩成下面这份最小清单：

  • 统一骨架：每个 Skill 都有明确的主入口、元数据和固定目录，参考资料、脚本、资源各归其位。
  • 优先使用可治理的工具入口：能用远程 MCP，就不要在每个 Skill 里重复实现连接和权限；CLI/API 只作为必要时的后备。
  • 把内部信息与公开交付分层：内部保留 owner、评测套件和测试数据；对外通过导出规则生成干净版本。
  • 让 CI 先做基础体检：frontmatter、命名、目录、行数、链接和结构护栏，在合并前自动检查。
  • 每个 Skill 都带评测用例：写清任务提示词、期望结果和评分规则，不要只凭作者自己的感觉验收。
  • 同时看提交时和每周结果：新 Skill 要过初始质量线，整个库还要定期回归，防止模型、API 或框架变化后悄悄退化。
  • 至少观察准确率和效率两条轴：记录任务完成质量、token 消耗和耗时，比较有 Skill 与无 Skill 的差异。
  • 明确两层 ownership：有人维护仓库规则，也有人对每个 Skill 的知识更新和评测退化负责。
  • 给作者一条可复用的生产线：必要时用内部 Skill 或多 Agent 的起草、自评、互评流程，降低编写和维护门槛。

写在最后

Google Agent Skills 这篇幕后文章最值得带走的，不是某个目录名或某个 GitHub Action，而是一种质量观：Skill 不是“给模型再塞一段提示词”，而是一件需要被定义、验证、导出、维护和复盘的工程产品。

当贡献者从一个小团队扩展到多个产品线，质量不能靠少数专家记住所有规则来维持。标准目录让结构可读，MCP 优先让能力更容易治理，CI 把低级错误挡在合并前，持续评测把模型和 API 变化带来的回归暴露出来，ownership 则回答了“出了问题谁来修”。

如果你正在搭自己的 Skills 库，最先做的事情可能不是再写十个 Skill，而是为现有的一个 Skill 补上这四样东西：清楚的目录和入口、一个可以重复运行的评测套件、一条提交时自动检查的流水线，以及一个明确的长期 owner。规模化之前先把这条最小闭环跑通，后面才有资格谈更多能力。

相关仓库：https://github.com/google/skills

编译说明：本文根据 Remigiusz Samborski 于 2026 年 8 月 3 日发布的文章编译，不是逐句翻译。正文忠实保留了原文的核心事实与方法，并按中文阅读习惯进行了重组。原文：Behind the scenes: How we build, test, and scale Google Agent Skills