Deepmind工程师分享评估与测试智能体技能的实用指南

Created time

Apr 13, 2026 04:59 PM

什么是智能体技能？

智能体技能（Agent Skills） 是一套由指令、脚本和资源组成的集合，无需重新训练或微调模型，即可扩展智能体的能力边界。技能遵循"渐进式披露"的设计模式，至少需要包含一个 SKILL.md 文件，其中涵盖以下内容：

元数据（触发器）：YAML 格式的 name（名称）和 description（描述），智能体凭此判断是否应该调用该技能。这是最关键的部分——描述模糊，技能就无法可靠地被触发。

正文（指令）：用 Markdown 编写的执行指导，说明应调用哪些 API、遵循哪些模式、以及需要避免哪些操作。

资源（可选）：智能体在执行过程中可供参考的 scripts/、examples/ 或 references/ 等文件。

从测试的角度来看，技能可以分为两类：

能力型技能：帮助智能体完成基础模型无法稳定执行的任务。随着模型能力的持续提升，这类技能可能逐渐变得多余——而评估结果会告诉你这个时机何时到来。

偏好型技能：记录特定的工作流程与操作规范。这类技能具有持久价值，但其有效性取决于对真实工作流的还原程度，评估的作用正是验证这种还原是否到位。

在动手写技能之前，先定义成功标准

在写任何评估代码之前，请先用可衡量的语言写清楚"什么叫成功"。评估的是结果，而不是过程。 智能体可以找到创造性的解法，你不应该因为它走了一条意料之外的路径就判定它失败。

结果：技能是否产出了可用的成果？代码能否编译、图像是否能正常渲染、文档是否成功创建、API 是否返回了有效响应？这是最基本的底线。如果输出本身不可用，其他一切都无从谈起。

风格与规范：输出是否遵循了你的约定和技能指令？比如：使用了正确的 SDK、当前有效的模型 ID、团队的命名规范，以及你指定的输出格式。

效率：它消耗了多少时间、Token 和算力？有没有多余的重试？Token 消耗是否合理？有没有出现指令冲突？这是最容易被忽视的维度。 两次运行可能产出完全相同的正确结果，但其中一次可能多花了 3 倍的 Token——这种差距在规模化之后会带来真实的成本压力。

以我们的 Interactions API 技能为例，具体的检验项包括：正确的 SDK 导入（from google import genai）、当前有效的模型 ID（而非已弃用的 gemini-2.0-flash）、使用 interactions.create() 而非 generateContent，以及在多轮对话中正确传递 previous_interaction_id。大多数检查项用正则表达式就能搞定。

评估工具搭建指南

本指南假设你已经有一个现成的技能，不涉及技能的创建过程。

在写评估代码之前，先手动跑几次技能。 使用明确的调用方式，例如"用 {技能名称} 执行 X"，或者使用智能体内置的触发方式（如 /skill {name}）。观察它在哪里出了问题。这几次手动运行不是为了打分，而是为了发现那些隐藏的前提假设：它是否假设了某个并不存在的依赖项？是否跳过了用户期望看到的步骤？

在手动运行过程中发现的每一个问题（补上缺失的安装命令、修正路径、精简描述），都会成为后续可以自动化验证的具体检查项。手动迭代不是浪费时间，而是必要投入。

1. 构建提示词集（Prompt Set）

对于单个技能，10–20 个提示词就足够入门了。每个提示词测试一个具体场景，并声明对应的成功标准。

每个测试通过 expected_checks 声明需要通过的检查项。对于智能体而言，每个测试用例可能有其独特的成功标准。

我在五个类别中共设计了 17 个测试：核心能力（7 个）、弃用模型防护（4 个）、技能内联示例之外的扩展功能（3 个），以及负向对照（2 个）；语言覆盖 Python（12 个）和 TypeScript（5 个）。

⚠️ 重要提示：不要跳过负向测试。描述过于宽泛的技能，可能会在所有编码提示词上都被触发。

2. 运行智能体并捕获输出

以实际使用的方式测试技能，例如通过 CLI。我们的案例使用 Python 脚本调用 Gemini CLI：

3. 编写确定性检查

每个检查项封装为一个小函数，用正则表达式匹配提取的代码，返回布尔值：

注册所有检查项，通过提示词集中的 check_id 进行调度，然后遍历每个测试用例：

我们针对 Interactions API 技能进行了约 20 轮测试迭代，通过率从 66.7% 提升至 100%。最关键的两个修复是：重写技能描述，使其更贴近用户的表达意图（而非 API 的技术术语）；以及将被动的弃用警告替换为明确的行动指令。仅仅改写描述，就修复了 7 个失败用例中的 5 个。

4. 引入 LLM 作为评判者，处理定性检查

注：我们在 Interactions API 技能的评估中未使用 LLM 作为评判者。

某些技能可能需要定性评估，例如代码结构的合理性、命名规范的一致性、设计质量，或输出是否符合预期模式——这些很难用正则表达式或文件是否存在来衡量。例如，一个前端设计技能要求产出"独特的、生产级的界面"。

对于这类技能，可以引入第二次模型辅助评估。使用结构化输出将 LLM 的返回内容约束为特定 Schema，确保结果可解析、可追踪：

请有选择地使用 LLM 评分：确定性检查速度快、成本低；LLM 评分会带来额外的时间和费用开销。

评估智能体技能的最佳实践

从技能描述入手：名称和描述是触发技能的开关。描述模糊意味着技能可能在不该触发时触发，或该触发时却没有触发。

用指令，而非信息：模型执行明确指令的能力，远强于从隐含信息中自行推断的能力。"始终使用 interactions.create()"有效，而"Interactions API 是推荐方式"则往往不起作用。

加入负向测试：写一些技能不应该被触发的提示词。关键词过于宽泛的技能，会把自己套在每一个请求上。

从小处着手，从失败中扩展：从真实使用场景中提取 10–20 个提示词开始。每一个用户反馈的错误输出，都应该成为一个新的测试用例。

评估结果，而非路径：智能体有能力找到创造性的解法。不要因为路径出乎意料就惩罚正确的答案。

隔离每次运行：为每个测试用例使用干净的运行环境。上下文的积累可能会在测试用例之间"渗漏"，遮蔽真实的失败信号。

多次试验取分布：智能体的行为本身具有随机性。单次通过/失败不足以作为判断依据，每个用例应运行 3–5 次，观察结果的分布，而不是只看单次结果。

跨框架测试：同一个技能在不同智能体框架下的表现可能大相径庭。如果你的技能跨工具使用，请在每个工具环境中分别进行评估。

让评估自我升级：能力评估通常从较低的通过率起步，给你一个可以努力攀升的目标。一旦通过率稳定在接近 100%，它就自然升级为回归评估，守住已有的性能，防止它在后续迭代中悄悄劣化。

主动识别技能退休时机：在卸载技能的情况下跑一次评估。如果依然能通过，说明模型已经将该技能的价值内化了——此时可以放心地将这个技能退休。