Google 如何规模化构建和测试 Agent Skills

一个 Agent Skill 看起来很小：一份 SKILL.md、几份 Reference，偶尔加个 Script。维护问题却一点不小。API 会变、链接会烂、模型行为会漂移、Agent Harness 会调整 Tool Semantics，同一套指令也可能帮到一个模型、拖慢另一个模型。

Google 在 2026 年 8 月公开了从发布 “Swarm” 走向受治理 Skill Library 的幕后方法。最值得学的不是某个 Prompt 技巧，而是：Skill 必须相对于 No-skill Baseline 证明增量价值，并在外部环境变化后持续证明。

先说结论

• 先用确定性 CI 检查结构、Metadata、命名、行数、链接与 Guardrail，再花钱跑 Agent Eval。
• 每个候选 Skill 必须提交多组 Prompt、Expectation 与 Scoring Rubric。
• 评测比较 With Skill 和 Without Skill 的 Accuracy 与 Efficiency，不只看有 Skill 的结果是否漂亮。
• 测试会重复运行并覆盖不同 Agent Framework，全库还做每周回归。
• Repo Maintainer 负责仓库健康，Product Skill Owner 对 API 变化与质量下降长期负责。
• 从内部到公开仓库的自动 Export 会剥离内部资产、Ownership 与 Eval Suite，这本身就是治理边界。

从一次 Swarm 变成供应链

Google 说项目起点是 Cloud Next 2026 前的跨职能 “Swarm”。Developer Advocate 与 Technical Writer 把 Cloud 领域知识整理成 Agent 可读指令。公开仓库得到强烈反响后，更多 Product Team 想贡献自己的 Skill，范围也超出 Google Cloud。

文章公开了 Authoring、Governance、CI 与 Evaluation 流程。来源：Google Cloud Blog。

小团队可以靠聊天协调；分散的 Product Contributor 则需要 Contribution Contract、自动 Gate、Owner、Release Hygiene 与 Regression Detection。

Skill Library 本质上变成了软件供应链。它交付的是指令而非 Binary，但仍能引导 Coding Agent 执行命令、访问数据、创建资源或制造昂贵错误。

先标准化 Package，再评价“智能”

Google 统一 Folder Layout 与 Frontmatter Contract。Check-in Pipeline 会验证 Metadata、Line Count、Directory Layout、Naming Convention 与所有 URL，并用 AI-assisted Checklist 检查必需结构和 Guardrail。

Gate	主要防止什么
Frontmatter Schema	无法 Discovery 或 Trigger 的 Skill
Name 与 Directory Rule	冲突和不一致安装路径
Line / Size Limit	巨型指令污染 Context
Link Checker	失效或编造的文档链接
Required Section	缺少 Validation、Safety 或 Completion 指南
Script Check	Helper 破损和隐藏 Runtime Assumption

Behavioral Eval 很贵，不应该浪费在格式错误的 Package 上。先 Lint，再让 Agent 运行。

公开 google/skills 能看到 Product-oriented Catalog：Agent Platform API、Cloud Basics、Onboarding Recipe 与 Well-Architected Framework，而且仓库明确仍在 Active Development。

公开仓库是从内部构建与评测体系 Export 出来的 Apache-2.0 Surface。来源：google/skills。

Baseline 是评测的心脏

很多 Skill Test 让 Agent 带着 Skill 做任务，再给结果打分。它能告诉你这次是否成功，却不能证明 Skill 帮了忙。

Google 比较两个条件：

同一任务 + 可比环境 + Without Skill
同一任务 + 可比环境 + With Skill

两者差异才是 Skill 的 Incremental Value。现代 Coding Agent 已经知道不少通用 Cloud 概念。一份 2,000 Token 的 Skill 如果只是重复模型知识，可能得到同样答案，却更慢、更贵。看起来不错的 Skilled Response 仍可能是负收益。

对照要控制 Task、Model、Tool Availability、Workspace State 和 Sampling Setting，并记录 Model、Harness、Skill、CLI 与文档版本。否则以后出现 Regression，也无法还原当时环境。

Accuracy 与 Efficiency 形成 2×2 决策

Google 看两个主维度：Accuracy 包括 Response Quality 与 Task Completion；Efficiency 包括 Token 与 Completion Time。

Accuracy	Efficiency	判断
更好	更好	明确收益，再验证安全与可维护性
更好	更差	看质量增益是否值得成本和延迟
更差	更好	通常拒绝，速度不能补偿错误
更差	更差	拒绝并重做

并不是只有 Accuracy 和 Efficiency 都提升才能上线。Deployment Skill 多用一些 Token，却阻止危险配置，可能非常值得。关键是让 Trade-off 与任务风险明确对应，而不是藏进 Aggregate Score。

Accuracy 也要拆开：Trigger Selection、Plan Correctness、Tool Choice、Argument、Artifact Validity、Safety Compliance 与 Final Explanation 应分别评分。一个 Judge 总分可能掩盖“文字很好看，但改错 Project”。

Agent 有随机性，所以必须重复

Google 会把 Eval 多次运行，并覆盖不同 Agent Framework，以获得更可靠的结果。这避免两种常见自欺：庆祝一次幸运 Pass，或把 Skill 过拟合到某个 Host 的加载机制。

每个 Case 都应保存逐 Run 数据：Pass/Fail 与 Rubric Dimension；Tool-call Trajectory 与 Denied Action；Input、Output 与 Cached Token；Wall Clock 与 Retry；Model/Harness Version；Activation 与加载的 Reference；Failure Category。

至少报告多次运行的 Pass Count，最好给出 Confidence Interval。6/10 Pass 不能被包装成普适意义上的“60% 正确”，但它比展示最佳 Transcript 诚实得多。

跨 Harness 测试还要包含 Activation。Gemini CLI 能正确选中、另一个 Agent 因 Description 模糊从不加载，这个 Skill 就不便携。Description 过宽也会在无关任务触发，增加成本和风险。

Unit Test 与 Agent Eval 不是一回事

Google agents-cli Workflow 划得很清楚：pytest 验证 Code Correctness，agents-cli eval 验证 Agent Behavior，并明确不建议在 Unit Test 中断言随机自然语言内容。

Implementation 后必须进入 Evaluation；Response Quality、Tool Use 与 Safety 不应伪装成普通 Unit Test。来源：google/agents-cli Workflow Skill。

对 Skill 可以这样分层：Deterministic Test 检查 Metadata、Script Type、Sample Validation、URL 与 Forbidden Path；Behavioral Eval 检查 Activation、Workflow、Tool、Approval、Task Completion 与 Evidence；Adversarial Eval 则让 Retrieved Content 尝试覆盖 Skill、索取 Secret、扩大 Scope 或跳过 Validation。

能确定性断言时，不要用 LLM Judge。任务如果要求 Cloud Run 禁止 Ingress，就直接检查最终 Config。Judge 对 Final Paragraph 的印象不是更强证据。

On-submit 与 Weekly Eval 发现不同问题

On-submit 回答：“这次提交能否改善当前系统？”Weekly Scheduled Eval 回答：“已发布 Skill 在今天的系统里是否仍有改善？”

第二个问题存在，是因为依赖会独立变化：Model Update 可能换一种方式理解指令；CLI 可能 Rename Flag；API 可能 Deprecate Field；Agent Host 可能调整 Discovery 或 Consent。Skill Repo 没有 Commit，它照样会 Regression。

因此每周检查最好同时有 Stable Comparison Lane 与 Current-production Lane。前者隔离 Skill Change，后者发现 Ecosystem Drift。两条 Lane 不一致时，Maintainer 才知道应修 Skill 还是调查 Upstream。

Library 很大时，用小 Canary 高频运行，完整 Matrix 定时运行。昂贵的 Cross-model、Cross-harness、Repeated Eval 留给 Release Candidate、高风险 Skill 与周期性 Audit。

为什么优先 Remote MCP

Google 的公开架构建议优先引用 Remote MCP Tool，CLI 或 Raw API 作为 Fallback。理由是 MCP Server 能提供 Agent-ready Tool，同时接入 Auth 与 IAM Governance。

这在 Remote Server 真正执行身份验证并暴露窄 Schema 时合理，但 MCP 不会自动带来安全。仍要测试 Authorization、Tenant Scope、Tool Description、Output Handling 与 Prompt Injection。一个包装成 MCP 的 execute_command 依然是宽泛命令执行。

Skill Eval 还应使用接近生产的 Identity。用 Owner Credential 测试，会把缺权限隐藏掉，也会让不安全调用显得“很可靠”。

Public Export 是安全与产品边界

Google 先在内部构建与评测，再用自动 Export Rule 生成干净公开仓库，移除内部 Asset、Ownership Information 与 Evaluation Suite。

清除私有材料能防泄露，但 Exported Skill 必须作为独立 Package 重新验证。内部 Reference 被删了，Instruction 仍可能暗中依赖它。Lint、Link、Install Test 与 Public-environment Smoke Eval 应针对导出产物，而不只是内部 Source Tree。

Eval Suite 全部私有会削弱社区复现。团队可以公开一组 Sanitized Core Benchmark，同时把暴露内部系统、Abuse Case 或敏感数据的用例留在私有 Suite。公开集说明预期行为，私有集保护敏感 Failure Mode。

Skill 是有 Owner 的产品

Google 让 Repo Maintainer 负责 CI 和 Architecture，让 Skill Owner 长期负责 API Change 与 Quality Regression。这可能是最容易被团队漏掉的一条。

每个 Skill 至少要有 Owner 与 Backup、支持 Model/Harness、Dependency Inventory、Risk Tier、Approval Behavior、Baseline Eval 与 Threshold、Review/Expiry Date、Known-good Rollback Version。

没有 Owner 的坏 Skill 不会自动变成“大家负责”，只会变成没人优先处理。

上一篇 UiPath for Coding Agents 也呈现同样趋势：具体 Skill 的成熟度比总产品兼容性更重要。Instruction Package 正在需要真正的 Release Engineering。

给团队的一套落地模板

先选一个高频、Output 可验证的任务，准备 10～20 个代表 Prompt，包括模糊与不安全请求。先跑 Without Skill，分类 Failure，再写最小 Instruction 与 Reference 去修这些 Failure。

加入确定性 Lint 和 Script Test，重复运行 With/Without Eval，对比 Accuracy、Token Delta、Latency、Activation Precision 与 Safety。通过后先给小范围用户，记录版本化 Telemetry，安排 Regression Job 和 Owner。

Skill 不再有帮助时，就修复或退休。Library 不能只靠累加增长，删除过时 Context 也是质量管理。

常见问题

为什么一定要与 Without Skill 比较？

因为一次成功的 Skilled Run 不能证明增量价值。Baseline 才能显示 Skill 是否优于 Agent 原有能力。

每个 Eval 要跑多少次？

没有通用数字。根据风险与成本跑到足以暴露 Variance，并报告分布。高风险或不稳定 Case 需要更多重复。

所有指标都该交给 LLM Judge 吗？

不该。File、Config、Tool Call 与 Policy Outcome 优先确定性检查；只有真正主观的维度才用明确 Rubric 的 Judge。

为什么要测多个 Agent Framework？

不同 Host 的 Discovery、Activation、Tool Semantics、Context Loading 与 Approval Behavior 不同。便携 Skill 必须跨越编写环境。

Evaluation Suite 应该公开吗？

公开足够多的用例来说明预期行为并支持社区验证；涉及内部系统、攻击技巧或敏感数据的 Case 保持私有。

最后的判断

Google 的方法把 Agent Skill 当作持续评测的产品，而不是聪明的 Markdown Snippet。结构和链接走确定性检查；行为价值与 Baseline 对照；随机运行跨 Harness 重复；Owner 在发布后继续负责。

这套流程没有写第一版 Prompt 那么兴奋，却正是 Skill Library 扩张后不把每次 Coding Agent Session 变成失控实验的原因。