登上 Skills Hot 第一，Google 把 Agent 的生产流程打包成了一套 Skill

Skills 开始进入一种更具体的竞争：不再只是给模型塞一份领域知识，而是在约束它怎样把一件复杂工作做完。Google 的 agents-cli 这两天排到 skills.sh Hot 当前第一。同一时点，仓库有 5,762 颗 GitHub stars；这两个数字来自不同系统，前者是 Skills 榜单信号，后者才是 GitHub star，不能互相替换。

我想借 agents-cli 说清一个正在变得常见的做法：把一个团队反复踩出来的 Agent 开发流程，写成 Agent 自己会在不同阶段重新读取的 Skill。它不是 Google 的又一款聊天式编程工具，而是一套 CLI 加七份 Skill，给 Claude Code、Codex 或其他编程 Agent 补上构建、评测、部署和观测 Google Cloud Agent 的具体步骤。期望对大家有所帮助。

它把“开发 Agent”拆成了七段

agents-cli 的 README列出七个 Skill：工作流、ADK 代码、脚手架、评测、部署、发布和可观测性。安装方式也相当直接：既可以运行 uvx google-agents-cli setup 安装 CLI 与 Skill，也可以只用 npx skills add google/agents-cli 把说明装进现有的编程 Agent。

关键不在文件数量，而是每份说明都带着进入条件。总入口的 google-agents-cli-workflow要求先澄清需求，再读取相应参考配方，之后才允许创建项目。它把开发路径写成：理解问题、研究配方、脚手架、实现、评测、部署、发布、观测。

flowchart LR
  A[需求与约束] --> B[workflow Skill]
  B --> C[scaffold]
  C --> D[ADK code]
  D --> E[eval]
  E --> F[deploy]
  F --> G[observability]

这看起来像普通工程流程，但它针对的是 Agent 很容易走的捷径。工作流 Skill 明确说，不能因为“需求已经很清楚”就跳过确认，也不能以一次 agents-cli run 的顺利输出代替行为评测。它还要求在每个阶段前重新加载对应 Skill，原因很现实：长对话的上下文压缩后，先前读过的约束可能已经不在窗口里。

不止会生成代码，还要留下验证路径

很多 Agent 项目的薄弱处不在最初的模板，而在后面那一串难以演示的环节：模型回答是否稳定、版本变更是否引入回归、上线后能否找到一次异常调用。agents-cli 把这些工作也放进了同一套方法里。

例如 google-agents-cli-eval区分了单次运行和评测：前者适合快速查看 Agent 是否能调用起来，后者才用数据集、指标与评审来检验行为。README 中对应的 agents-cli eval generate、grade、compare 和 analyze 命令，覆盖了生成轨迹、打分、对比与归因。

可观测性 Skill 的写法更值得细看。它不是笼统地说“接入 tracing”，而是把数据分为 Cloud Trace、提示词 - 回复日志、BigQuery Agent Analytics 和第三方平台四层，并区分哪些默认开启，哪些会把完整提示词与回复写入 GCS 或 BigQuery。完整说明特别提醒：即使 Trace 设置为不记录内容，启用了上传变量的 GCS 与 BigQuery 日志仍可能保存完整对话。这是部署前应该核实的保留策略，不是上线后再补的一行配置。

也就是说，这套 Skill 的价值不是让 Agent “知道更多 Google Cloud 命令”。它把脚手架、行为验证、权限、日志与回滚顺序放在一起，尽量让执行过程留下可以检查的中间物。

为什么现在又被看见

这次的直接传播信号是 skills.sh 的 Hot 榜，而不是 GitHub Trending 的日增 star。榜上第一项是 google-agents-cli-observability；详情页在本次观察时显示该 Skill 累计 110.8K installs，并标记 Google 为已验证组织。这个累计安装数也不是 GitHub star，更不能反推单日增长。skills.sh 条目与 GitHub 仓库 API 可以分别核对。

它并非沉寂很久的目录。仓库创建于 2026 年 4 月 8 日，8 月 28 日发布 v1.4.2。此前的 v1.4.1 调整了默认脚手架模型、评测 trace 的生成问题、闲置 Agent Runtime 与 Cloud Run 的最小实例默认值，也修复了脚手架创建过程中的任意文件写入漏洞；v1.4.0 还加入 Agent Gateway 部署支持和 A2A、MCP Agent Registry 指引。发行记录保留了这些变更。

因此，不能把当前 Hot 第一解释成某一条功能刚刚爆发。但它有足够具体的背景：Google 正把自己的 Agent 平台能力改写成可安装、可按阶段调用的操作说明，而不是只留在网页文档里。对于每天都在让编码工具生成 Agent 项目的人，这种“流程也作为依赖分发”的做法比又一个模板更有公共讨论价值。

谁该试，先确认什么

如果团队已经在用 Google ADK 或计划把 Agent 部署到 Agent Runtime、Cloud Run、GKE，agents-cli 值得在一个非生产项目里试一次。它的脚手架、eval 命令和环境准备能减少从空目录开始拼装的工作。只在本地跑 ADK 时，README 说明可以使用 AI Studio API key；云端部署才需要自己的 Google Cloud 项目。

但不要把安装 Skill 当作安全审查的终点。我会先做四件事：

• 阅读即将加载的 SKILL.md 与引用配方，确认它准备执行哪些命令和基础设施操作
• 把评测数据与生产日志分开，特别核实提示词、回复和用户数据是否会写入 GCS、BigQuery 或第三方观测平台
• 将 agents-cli deploy 留在人工确认之后，工作流本身也明确要求没有人的批准不得部署
• 检查当前 release、开放 issue 与云资源默认值，避免把持续迭代中的模板直接带进生产环境

Agent Skill 的意义不在于让工具更像一个万能专家，而是把一个团队愿意承担责任的步骤、边界与复查点交给它。agents-cli 这轮热度提醒了我：真正开始被产品化的，可能不是单个模型能力，而是怎样让 Agent 在完整流程里少跳过几步。