把 Agent Skill 当成产品:Google 如何构建、评测并规模化治理智能体技能

2026-08-03 34 预计阅读时间: 1 分钟
来源: cloud.google.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间:13 分钟

AI 编码智能体的能力上限,不只由模型决定,还取决于它拿到了什么指令、上下文和工具。Google Agent Skills 的核心思路,是把 Google Cloud 等领域知识编码成结构化、开源、可被智能体读取的操作说明,让智能体减少幻觉、遵循最佳实践,并更稳定地完成真实任务。

真正困难的部分并不是写出第一批 Skill,而是在越来越多团队参与后,仍然保证每个 Skill 都准确、可维护、可评测。Google 的实践显示,Agent Skill 更接近一个持续交付的软件产品,而不是放进仓库就不再更新的提示词文件。

从集中突击到规模化协作

Google Agent Skills 最初来自 Google Cloud Next 2026 前的一次跨职能集中协作。Developer Advocates、Technical Writers 等角色共同把产品知识整理成适合智能体执行的结构化指令。项目发布后获得超过 15,000 个 GitHub Star,也吸引了云服务之外的产品团队参与贡献。

贡献者增加后,仓库会迅速遇到几个典型问题:

  • 不同作者使用不同的目录、命名和元数据格式。
  • 指令看似完整,实际遗漏错误处理、权限边界或前置条件。
  • 文档链接失效,甚至混入模型生成但并不存在的 URL。
  • API、模型或 Agent Harness 更新后,原本有效的 Skill 出现退化。
  • 内部评测数据、所有权信息等资产不能直接进入公共仓库。

因此,Skill 的发布流程必须同时约束结构、内容、效果和所有权。仅靠人工代码审查,很难在大量产品团队并行贡献时守住这些边界。

Skill 的架构选择:优先连接远程 MCP 工具

在工具调用层面,Google Agent Skills 倾向于优先引用远程 Model Context Protocol(MCP)工具,只有在没有合适工具时才退回 CLI 或直接 API 调用。

这种选择适合 Agent 工作负载,原因不只是接口统一。远程 MCP Server 可以把认证、IAM 授权和工具定义放在服务端治理。Skill 负责告诉智能体何时调用工具、如何组织参数、怎样处理结果,而不必在指令中散落长期凭据或重复实现权限逻辑。

一个实用的选择顺序可以写成:

  1. 存在受治理的远程 MCP 工具时,优先使用 MCP。
  2. 没有 MCP,但目标环境具备标准 CLI 时,提供明确的 CLI 命令和错误处理。
  3. 只能调用 API 时,说明认证方式、请求参数、重试策略和权限范围。
  4. 不要让 Skill 要求智能体输出、记录或提交访问令牌。

这个原则并不意味着 MCP 自动解决所有问题。远程服务的可用性、版本兼容性、网络延迟和授权配置仍然需要监控;CLI 和 API 也应保留为经过评估的降级路径,而不是临时拼接的替代方案。

质量门禁不止是 Lint

Google 在 Skill 提交阶段运行自动化 CI/CD 检查,包括 frontmatter 元数据、行数、目录布局、命名约定和链接有效性。AI 辅助检查还会验证指令是否包含规定的结构与护栏。

这些静态检查解决的是“文件是否合规”,不能证明“智能体是否真的做对了”。因此,每个 Skill 还需要提交评测提示和评分规则,并接受两类持续评测:

  • 提交时评测:在新 Skill 发布前验证准确性和执行效率。
  • 每周评测:定期覆盖完整 Skill 库,发现 API、模型或 Agent 框架变化造成的回归。

评测会比较加载 Skill 与不加载 Skill 的智能体,重点观察两个维度:准确性,包括回答质量与任务完成率;效率,包括 Token 消耗与完成时间。测试还会在不同 Agent 框架上重复运行,避免把一次偶然成功当成稳定收益。

最终可以把结果放进一个 2×2 矩阵:准确性是否提升,效率是否提升。理想 Skill 同时改善两者;如果准确性提高但 Token 和耗时大幅增长,就需要判断这项成本是否值得;如果只缩短响应却降低任务完成率,则不能通过质量门禁。

可以这样实践:搭建最小 Skill 与评测流水线

下面是一个可改造的最小项目示例,用来演示目录约束、评测用例和 CI 检查。它不是 Google 仓库内部格式的复刻,字段和脚本需要按你的 Agent Harness 调整。

skills/
└── cloud-log-investigation/
    ├── SKILL.md
    └── evals.yaml
scripts/
└── validate_skill.py
.github/
└── workflows/
    └── validate-skills.yml

SKILL.md 可以把适用范围、工具优先级和安全边界写成可检查的结构:

---
name: cloud-log-investigation
version: 1.0.0
owner: platform-observability
---

# Cloud Log Investigation

## Use when

The user asks to investigate an application error using cloud logs.

## Tool policy

1. Prefer the approved remote MCP log-query tool.
2. Use the CLI only when the MCP tool is unavailable.
3. Never request, print, or persist access tokens.
4. Ask for the project and time range before running a broad query.

## Workflow

1. Confirm the project, service, region, and time range.
2. Start with a narrow error-level query.
3. Summarize recurring error signatures before fetching more data.
4. Distinguish observed evidence from possible causes.
5. Recommend a remediation only when supported by query results.

评测文件应描述输入和可验证的期望,而不是只保存一组“标准答案”:

cases:
  - id: asks-for-required-scope
    prompt: >-
      Investigate why checkout requests failed yesterday.
    expectations:
      - asks for the project or account scope
      - asks for a concrete time range or timezone
      - does not invent log entries
      - does not request an access token

  - id: prefers-governed-tool
    prompt: >-
      Find recurring ERROR messages for service checkout-api in
      project demo-prod between 10:00 and 10:15 UTC.
    expectations:
      - selects the approved remote MCP log-query tool when available
      - scopes the query to demo-prod and checkout-api
      - separates evidence from hypotheses

可以使用下面的 Python 脚本完成基础结构检查。运行前安装 PyYAML,然后把脚本保存到示例中的 scripts/validate_skill.py

from pathlib import Path
import re
import sys
import yaml

REQUIRED_SECTIONS = {"Use when", "Tool policy", "Workflow"}


def validate(skill_dir: Path) -> list[str]:
    errors = []
    skill_file = skill_dir / "SKILL.md"
    eval_file = skill_dir / "evals.yaml"

    if not skill_file.exists() or not eval_file.exists():
        return [f"{skill_dir}: SKILL.md and evals.yaml are required"]

    text = skill_file.read_text(encoding="utf-8")
    sections = set(re.findall(r"^## (.+)$", text, flags=re.MULTILINE))
    missing = REQUIRED_SECTIONS - sections
    if missing:
        errors.append(f"{skill_file}: missing sections {sorted(missing)}")

    data = yaml.safe_load(eval_file.read_text(encoding="utf-8")) or {}
    cases = data.get("cases", [])
    if len(cases) < 2:
        errors.append(f"{eval_file}: at least two evaluation cases are required")

    for case in cases:
        if not case.get("prompt") or not case.get("expectations"):
            errors.append(f"{eval_file}: each case needs prompt and expectations")

    return errors


all_errors = []
for path in sorted(Path("skills").iterdir()):
    if path.is_dir():
        all_errors.extend(validate(path))

if all_errors:
    print("\n".join(all_errors))
    sys.exit(1)

print("All skills passed structural validation.")

本地执行命令如下:

python -m pip install PyYAML
python scripts/validate_skill.py

再把同一项检查接入 GitHub Actions:

name: Validate agent skills

on:
  pull_request:
    paths:
      - "skills/**"
      - "scripts/validate_skill.py"

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: python -m pip install PyYAML
      - run: python scripts/validate_skill.py

这只是第一层门禁。生产流水线还应加入链接检查、敏感信息扫描,以及真正调用目标 Agent Harness 的对照评测。对照运行至少要记录 skill_enabled、任务是否完成、评分、Token 数、耗时、模型版本和框架版本,才能解释一周后的分数变化来自哪里。

发布治理:内部验证与公共导出分开

Google 的 Skill 会先在内部构建和评测,达到标准后再通过自动导出规则进入公共 GitHub 仓库。导出过程会移除内部资产、所有权信息和评测套件,使公共仓库保持干净。

这种模式比维护两套人工同步的目录更可靠。可以把内部仓库视为完整源数据,把公共仓库视为经过策略生成的发布产物。导出规则应采用默认拒绝策略:只有明确允许公开的文件和字段才能发布,并在 CI 中扫描内部域名、账号、项目 ID、凭据模式和受限说明。

治理责任也需要明确分层:仓库维护者负责 CI、目录健康和架构标准;Skill Owner 负责产品知识、API 变化和评测退化。当接口发生变化或每周评测报警时,必须能找到具体维护团队,而不是把问题留给仓库管理员猜测。

Google 还把相同方法用于内部 DevRel Skills,将内容转换、SEO 优化、内部报告等流程编码为团队专用 Skill。这说明公共 Skill 和内部 Skill 可以共用工程方法,但不能共用相同的发布边界和数据策略。

落地前检查清单

把 Agent Skill 引入团队时,可以先检查以下事项:

  • 是否有稳定的目录、元数据和命名规范。
  • 是否优先采用带认证与 IAM 治理的远程 MCP 工具。
  • 是否明确工具不可用、权限不足和输入不完整时的行为。
  • 每个 Skill 是否包含多个评测提示和可检查的评分规则。
  • 是否对比启用与未启用 Skill 的准确性、Token 和耗时。
  • 是否在提交时和定时任务中重复运行评测。
  • 是否记录模型、Agent 框架、工具和 Skill 的版本。
  • 是否为每个 Skill 指定长期 Owner 和退役流程。
  • 内部内容导出到公共仓库时,是否采用自动化白名单规则。

Skill 的价值不在于它写了多少条指令,而在于它能否持续让智能体更准确、更高效,并在依赖变化后仍然守住安全边界。只有把结构检查、对照评测、发布治理和长期所有权组合起来,Agent Skill 才能从一段有用的提示词成长为可规模化维护的工程资产。


相关推荐