getedgehq/agent-evals

智能体评估

一次评估只回答一个问题：智能体是否正确地完成了工作？ 以下所有内容都是为了更可靠、更廉价、更频繁地提出这个问题。

根据 Alex Lieberman 与 Viv (LangChain) 在2026年共同举办的评估大师班内容构建： youtube.com/watch?v=zLeG-XJtbIE。其中的结构（简单模式、困难模式、上帝模式）归功于他们。本技能中的任何错误归我们。

首先向用户了解三件事

1. 智能体实际执行的是什么工作？说出它接触的系统名称（CRM、收件箱、代码仓库、数据库）。
2. 公司里目前谁最擅长那份工作？他们的判断是基准真相。
3. 智能体是否已经投入生产运行？如果是，追踪记录存放在哪里？

根据答案选择模式。不要在没有任务和验证器的情况下直接跳到上帝模式。

简单模式：任务与验证器

任务是真实工作中一个可检查的小块。 验证器用于判断该任务是否被正确完成。

1. 编写10到30个模仿真实同事所做工作的任务。例如销售智能体：
   • 在通话后向CRM记录添加备注
   • 查找不在明显表格中的潜在客户
   • 草拟一封回复邮件但不发送
2. 为每个任务编写验证器。优先选择（按顺序）：
   • 状态检查（一个脚本）：字段之前为空，之后持有正确的值；email_sent 标签存在。
   • 检查清单（由模型或人类完成）：对于无法直接验证的内容，将“良好”分解为是/否问题。“不超过三段？”“使用了品牌语气规则？”
3. 保持每个判断为二进制。要求模型给出1到10分的评分时，它们往往会集中在7分左右并含糊其辞。是/否无法含糊。
4. 从最擅长该工作的人那里以书面形式获取检查清单。运行智能体，手动抽查一个样本。如果输出通过了检查清单但仍然感觉不对，说明检查清单不完整。添加缺失的问题。

简单模式的输出：一个包含任务的文件夹，每个任务都有指令和验证器，以及通过率。

困难模式：环境

环境是智能体执行工作的地方：它的文件、工具、数据和权限。 绝不能针对生产数据进行评估。一个评估失败的智能体会修改真实的CRM。

1. 构建一个对智能体而言看起来真实的副本：相同的表格、相同的工具、虚假的记录。打包成每次运行都能重置到相同状态（通常选择容器）。
2. 一个任务 = 指令 + 环境 + 验证器。将它们存储在一起。
3. 如果可能，不要自己构建运行器。Harbor (github.com/harbor-framework/harbor) 提供了任务、环境和验证器的共享格式，以及许多可供改编的已发布任务。
4. 测试环境本身。 你的第一个环境一定是错的。让几个不同的智能体或模型在其上运行，并寻找异常模式：
   • 一个强模型失败了，而一个弱模型却通过了
   • 智能体在它不应该找到的地方找到了答案（占位符行、泄露的文件）。智能体会利用任何捷径来通过测试。移除泄露点。
5. 按家族标记每个任务（编码、销售、代码审查）。当新模型发布时，只运行它可能擅长的家族。
6. 用表格而不是感觉来选择模型。 让每个候选模型在相同的标记任务上运行。并列记录通过率、成本和速度。然后由人类决定：在这个家族中，5个百分点的准确率是否值得付出3倍的成本？面向用户的任务通常值得使用顶级模型；内部任务则通常不值得。

困难模式的输出：一个评估套件，可以一键在任何模型上重新运行，并附带每个任务家族的对比结果表。

上帝模式：改进循环

循环：智能体运行，生成追踪记录，失败转化为新任务，智能体得到修复，重复。

1. 开启追踪。 追踪记录是每个动作的日志：每次工具调用、每条消息、每个结果。没有人能预测智能体会做什么。每个人都能判断它做了什么。
2. 将追踪记录存储在一个地方。 对于单个开发者，智能体自身磁盘上的日志就足够了。对于团队，请使用具有权限管理的追踪产品。
3. 让第二个智能体来分析追踪记录。 它的唯一工作就是寻找模式。给它一份关于良好行为和不良行为的简短说明。要求它找出：
   • 失败或重复的工具调用
   • 被忽略或半执行的指令
   • 反复出现的错误路径（总是搜索错误的表，要求三个时只做一个公司）
4. 将每个确认的失败转化为评估套件中的一个任务，使其永远无法悄无声息地再次出现。
5. 修复智能体，从最便宜的杠杆开始：
   • 框架：提示词、工具描述、工具集、模型选择
   • 一旦评估套件证明小型开放模型在特定任务上与大型模型匹配，就在该窄任务上对小型开放模型进行微调
6. 让人类来定义“良好”。 智能体可以提出修复方案和起草任务。人类仍然需要决定哪些任务对业务重要，并审查新的任务。将此过程记录下来是整个循环中杠杆率最高的部分。

规则

• 没有命名真实工作的评估无效。通用基准不能告诉你你的智能体是否有效。
• 仅使用二进制验证器。将任何分数拆分为是/否问题。
• 绝不让评估接触生产数据。
• 一个所有任务都通过的套件是一个有缺陷的套件。检查是否存在泄漏。
• 报告通过率时必须附带任务数量（例如“21/30”），绝不能只报告百分比。