本文永久链接 – https://tonybai.com/2026/08/09/google-agent-skills-behind-the-scenes

大家好，我是Tony Bai。

【导读】

Google开源的Agent Skills项目自发布以来狂揽超过1.5万GitHub Star，吸引了越来越多产品团队想要为自家服务贡献Skill。但“人人都能写Skill”的另一面，是质量失控的风险——一份写得含糊、链接失效、漏掉边界情况的Skill，足以拖垮整个Agent体验。Google内部到底是怎么在开放和质量之间找平衡的?这篇文章带你看懂背后的完整流程：从立项冲刺、标准化目录结构，到CI/CD自动检查、持续评测、再到“Skill Owner”式的长期治理。

【文章要点】

  • Google Agent Skills项目诞生于Google Cloud Next ‘26发布前的一次跨团队“冲刺”(swarm)，由Developer Advocate和技术文档团队牵头。
  • 项目上线后Star数迅速突破1.5万，带动越来越多产品线(不限于Cloud，还包括Ads等)想要贡献自己的Skill。
  • 每个Skill都遵循统一的仓库目录结构，并优先“引用远程MCP工具”，CLI/API调用只作为兜底方案。
  • Skill先在内部构建和评测，达标后才通过自动化导出规则发布到GitHub，同时会剥离内部资产和评测套件。
  • 上线前必须通过Linter、链接检查、AI辅助结构校验三重自动化关卡。
  • 质量不是一次性达标，而是靠“提交时评测+每周例行评测”持续监控，从准确率和效率两个维度打分，形成2x2矩阵判断一个Skill到底有没有带来提升。
  • Google把Skill当作“产品”而非“一次性文档”来运营，设有Repo Maintainer和Skill Owner两层责任人。
  • 团队还打造了内部Skill和基于ADK的多智能体协作工具，帮助作者写Skill、写评测集;并内部平行运行一套服务于DevRel团队日常工作流的“DevRel Skills”体系。

1.5万星的“甜蜜负担”

给AI智能体喂知识，现在流行一种新格式：Skill（技能包）。

它不是一段提示词，而是一份结构化、可被智能体读取的说明文件，把某个领域的最佳实践、边界情况、操作步骤，打包成智能体可以直接“调用”的经验。

Google Cloud在今年的Next大会前后，正式开源了自己的Agent Skills仓库google/skills，把Google Cloud的领域知识变成结构化、可读取的智能体指令。项目上线后热度远超预期，Star数很快冲到1.5万以上。

热度带来了新的“麻烦”：越来越多的产品团队——不只是Cloud，还包括Ads等业务线——都想把自己的知识打包成Skill贡献进来。人多手杂，质量怎么控？Google Cloud首席开发者关系工程师Remigiusz Samborski近日撰文，第一次系统讲清楚了这套“造血机制”是怎么运转的。

起点：Next ‘26前的一次“冲刺战”

这个项目并不是关起门来憋出来的。它诞生于一次冲着Google Cloud Next 2026去的快节奏“swarm”冲刺——由开发者布道师（Developer Advocate）和技术文档团队牵头组成的跨职能小组，目标很直接：把Google Cloud的领域知识，打包成结构化、机器可读的智能体指令。

项目正式发布后，开发者的反馈比团队预期的要热烈得多。看到Skill确实能让Agent少犯错、少“幻觉”、更遵守最佳实践之后，越来越多内部团队坐不住了，纷纷提出想为自己的产品线贡献Skill。

火了之后的真问题：谁来把关质量

规模一旦上来，一致性就成了老大难。不同团队各写各的，标准很容易走样——指令写得模糊、链接失效、漏掉关键的边界情况，任何一处瑕疵都会拖累整个Agent的使用体验。

Google Cloud团队的应对思路很朴素：既要让各团队能顺畅地发布Skill，又要保住开发者体验，那就必须提前把标准立住、把关卡设死。没有清晰的规范和自动化治理，一个开源Skill仓库很快就会失控。

解剖一个Skill：标准目录+“优先用远程MCP”

为了在众多Google产品线之间保持一致，每一个Skill都遵循统一的仓库目录结构——同样的文件命名、同样的层级组织方式，让人和Agent都能按套路去读、去写。

在架构设计上，团队定下了一条核心原则：优先引用远程MCP（Model Context Protocol）工具，只有在必要时才退而求其次，用CLI或API调用。

原因也很实际——远程MCP服务器天生适合智能体这种工作负载，既能直接提供工具能力，又自带鉴权和IAM级别的治理能力，比裸调CLI/API更省心也更安全。

从内部到公开：先在家里练好，再上台

一个Skill不会一写完就直接推上GitHub。Google的做法是先在内部构建、内部评测，确认它真正管用、通过验证之后，才用一套自动化导出规则，把它发布到公开仓库。

这个导出过程同时承担着“脱敏”职责：剥离掉内部资产、内部归属信息，以及内部专用的评测套件，只把干净、可复用的部分留给公众仓库。

第一道关卡：上线前的自动化三重检查

任何一个Skill在正式进入仓库之前，都必须先跑通一整套CI/CD自动化流水线，主要包括三类检查：

  • Linter（代码/格式检查）：校验frontmatter元数据、行数限制、目录结构，以及严格的命名规范。
  • 链接检查器：用专门的链接检测工具逐条测试Skill里出现的每一个URL，在合并之前就把404和“幻觉链接”清理掉。
  • AI辅助结构校验：借助自动化校验，检查指令内容是否遵循了规定的结构模式与防护规则。

第二道关卡：持续评测——不是一锤子买卖

文档和API在不断变化，底层的大模型和Agent运行环境也在不断迭代。今天还能用的Skill，明天可能就因为某个API、某个模型或某个Agent框架的变化而失灵。为了守住质量底线、防止“悄悄退化”，团队建立了一套持续评测机制：

  • 提交时评测：Skill作者必须提供明确的评测提示词集合和打分标准。每一个新上线的Skill，都要先经过内部评测，验证准确率和效率是否达标。
  • 每周例行评测：针对整个Skill库，团队会定期、自动地跑一遍评测任务，尽早发现质量回退的信号。

具体怎么打分？作者需要提供多组评测用例，每组用例包含一个提示词和一套预期结果，然后对比“用了这个Skill的Agent”和“没用这个Skill的Agent”的表现差异，重点看两个维度：

  1. 准确率——回答质量、任务完成率；
  2. 效率——消耗的Token数量与完成任务所用的时间。

为了让结果站得住脚，团队还会把同一套评测跑在多个不同的Agent框架上，取得具有统计显著性的结果。最终，团队用一张2×2矩阵来判断——这个Skill到底是不是真的能带来“又准又快”的双重提升，还是只是看上去很美。

治理哲学：Skill是产品，不是一次性文档

Google团队总结的一条重要经验是：Skill是一个需要长期运营的“活”产品，而不是写完就扔的一次性文档。为此，他们设立了明确的责任分工：

  • 仓库维护者（Repo Maintainer）：负责整个仓库的健康度、CI流水线，以及架构层面的统一标准。
  • Skill所有者（Skill Owner）：负责自己那份Skill的长期维护。比如某个产品API变了，Skill Owner就得去更新对应内容；评测中发现质量下滑，同样由Skill Owner负责修复。

给作者“减负”：内部Skill+多智能体写作流程

写好一份指令、配好一套评测集，本身就需要经验积累，团队并不指望每个作者都从零手搓。为此，他们专门打造了一批工具和智能体化工作流来支持贡献者：

  • 内部专用Skill：专门用来辅助作者构建新Skill、编写健壮的评测集。
  • 基于ADK的智能体工具：跑多智能体循环，实现自动撰写与自我批评（self-critique），并配有一条顺畅的导出路径，方便把成果并入主仓库。

除了面向外部开发者的公开仓库，Google内部还并行运行着一套名为DevRel Skills的内部体系，专门为DevRel团队自己的日常工作流服务——比如内容转换、SEO优化、内部报告生成等等，都被封装成了专属Skill，帮团队更高效、更一致地完成日常工作。

小结：给国内团队的启示

通过Google这个分享，我们国内团队可以得到以下的一些启示：

  • 规模化的前提是标准化：统一的目录结构、命名规范，是让不同团队协作而不打架的地基。
  • 架构上优先选“可治理”的工具：远程MCP优先于裸CLI/API，本质上是把鉴权、权限管控这些“脏活”交给基础设施，而不是靠人肉约束。
  • 质量关卡要前置也要持续：上线前的Linter、链接检查、结构校验只是第一道门槛；真正的考验是上线之后能不能持续跟踪、及时发现回退。
  • 评测要量化、要可比：准确率和效率两个维度、多框架交叉验证、2×2矩阵判断——这套方法论本身就值得国内团队做Agent能力沉淀时借鉴。
  • 责任要落到人：Skill Owner制度说明，光有流程还不够，必须有人对每一份Skill的长期质量负责。

对正在探索“怎么给自己的Agent攒经验包”的团队来说，Google这套“标准化+自动化把关+持续评测+专人负责”的组合拳，是目前公开资料里少见的、比较完整的工程化范本。

参考资料

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

  • 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
  • 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
  • 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
  • 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
  • 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

  • 告别低效，重塑开发范式
  • 驾驭AI Agent(Claude Code)，实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。