第一次做 Agent 测评，最容易走向两个极端。
一种是继续靠手工试玩，觉得多问几个问题就算测过。另一种是先研究平台、指标和统计方法，准备做一套完整系统，结果迟迟没有跑出第一批数据。
更实际的做法，是先选一个清晰任务，用大约 20 个有区分度的真实案例，跑通目标—用例—评分—分析—决策的最小闭环。
这里的 20 不是行业标准，只是一个便于启动的规模。正式样本量要根据风险、任务差异、结果波动和决策成本调整。
第一步：只选一个任务
第一次不要试图回答“整个 Agent 好不好”。
Agent 可能同时具备搜索、分析、写作、工具调用和文件处理能力。把所有能力混在一起评，结果一旦失败，很难知道问题发生在哪里。
一个适合首次测评的任务，通常具有三个特征：
- 用户需求真实且高频；
- 任务边界相对清晰；
- 完成结果可以被观察和判断。
例如，“根据一份会议记录生成开发可读的需求文档”，就比“评估这个 Agent 的产品能力”更适合。
然后冻结当前被测版本：
- 模型和参数；
- System Prompt；
- Skill 与脚本；
- 可用工具和权限；
- 上下文与运行环境。
最后写清这次测评用于什么决定。是保留新版 Prompt、判断 Skill 能否内部试用，还是比较两个候选模型？
没有决策目标，后面的分数很容易变成没有行动的报表。
第二步：把“好用”改成三类标准
“结果专业”“回答智能”“文档质量高”都无法直接验收。
可以把成功标准分成三层。
必须做到
这是任务成功的最低条件。
以需求文档为例：
- 识别业务目标和目标用户；
- 保留关键流程、字段和规则；
- 输出测试可以使用的验收点；
- 对材料中缺失的信息标记 TODO；
- 成功生成指定格式的文件。
绝不能发生
这是硬门槛，不能被其他高分抵消。
- 编造材料中不存在的结论；
- 暴露敏感信息；
- 未经授权修改或删除源文件；
- 声称已经生成文件，但实际文件不存在；
- 把待确认内容写成既定事实。
可以继续优化
这类指标适合比较版本，不一定决定是否可以使用。
- 文档结构是否更易读；
- 表达是否简洁；
- 响应速度；
- Token 和工具调用成本；
- 是否减少人工整理。
这三层标准对应三种决策：守底线、看能力、做优化。
第三步：收集首批真实任务
首批用例不需要很大，但不能只由开发者临时编写几个标准问题。
可以从五类来源构建：
| 类型 | 作用 | 示例 |
|---|---|---|
| 高频正常任务 | 代表主要使用场景 | 信息较完整的会议记录 |
| 表达变化 | 检查理解能力 | 简写、口语、顺序混乱 |
| 边界任务 | 暴露能力边界 | 材料缺字段、存在冲突 |
| 负例 | 检查不该执行时是否克制 | 输入与目标 Skill 无关 |
| 坏案例与风险 | 防止已知问题复发 | 曾出现编造、漏项或越权 |
如果以 20 个案例启动，可以参考这样的分配：
- 8 个高频正常任务；
- 4 个不同表达；
- 3 个边界或信息缺失任务；
- 2 个不应执行的负例；
- 3 个历史坏例或高风险任务。
这只是示例。高风险 Skill 需要增加异常和禁止行为，内容生成类 Agent 可以增加质量差异更明显的案例。
每个案例至少记录：
- Case ID；
- 用户任务和输入；
- 必要上下文与初始状态；
- 期望结果；
- 必须满足项；
- 禁止行为；
- 场景、风险和来源标签。
好的数据集不是题目越多越好，而是能代表真实任务，并且能区分两个版本的好坏。
第四步：选择合适的评分方式
不要把所有结果都交给同一种评分者。
能写规则的，优先用规则
格式、字段、文件和状态都可以确定性检查：
- JSON 是否可解析；
- 必填字段是否存在；
- 文件是否生成；
- 表格行数是否正确；
- 工具参数是否符合约束；
- 执行后状态是否按预期变化。
规则评分便宜、稳定，也容易定位原因。
开放质量，用 Rubric 判断
Rubric 可以理解为一份清晰的评分说明。
不要只写“完整性 1—5 分”，要说明每一档代表什么。例如：
- 5 分：全部关键目标、流程、字段、规则和验收点均被覆盖；
- 3 分：主体完整，但遗漏一项重要信息；
- 1 分：只能看出大致主题，无法供后续角色使用。
相关性、正确性、完整性和可用性最好分开判断，避免一个模糊总分。
AI 裁判负责提效，人工负责校准
大模型可以按照 Rubric 批量评分，并给出判定理由。
但 AI 裁判会受到答案顺序、篇幅、措辞和模型自身偏好的影响。首次使用时，应抽取一部分结果由业务专家或产品人员独立判断，再比较两者是否一致。
严重失败、临界结果和评分分歧需要人工复核。
第五步：跑出第一条基线
执行时，要让全部案例使用同一版本和同一配置。
保存的不只是最终回答，还包括：
- 是否成功完成；
- 各项评分；
- 触发和工具调用记录；
- 生成的文件或数据；
- 耗时、Token 和调用次数；
- 失败原因与人工备注。
结果表不要只保留一个平均分。至少分成四部分。
硬失败
是否出现越权、泄露、严重事实错误、文件丢失或虚假完成声明？
这类结果单独计数，不能被平均值稀释。
核心任务
任务成功率是多少？正常场景和边界场景分别如何？关键产物是否可用？
稳定与效率
如果任务风险较高，可以对关键案例重复运行。同步记录时延和成本，避免质量提升完全依赖更多调用。
典型坏例
每一类失败挑选代表案例，保留输入、输出、过程证据和可能原因。
总分告诉你大概位置，坏例才告诉你下一步改什么。
第六步：用结果做决定
一次 Eval 应以明确动作结束。
保留
硬门通过，核心任务达到最低标准，关键案例没有不可接受问题，可以保留当前版本作为基线。
修改
失败集中在明确模式，例如总是遗漏验收点、遇到缺失信息时不追问。将失败转成一个修改假设，再进入下一轮。
补测
结果波动大、评分存在分歧或部分场景样本不足。此时应增加运行次数、案例或人工复核，而不是强行下结论。
换方案
如果问题来自模型能力、检索数据、工具权限或工作流设计，继续堆叠 Prompt 可能没有意义。需要换模型、增加工具或调整流程。
回滚或停止
新版出现严重退化，或者提升不足以覆盖成本和风险，就回到旧版。
完成这一步，你已经拥有第一条可复现基线。以后每次修改，都可以在同一批任务上证明是改善还是退化。
下一篇将把范围收紧到 Skill：除了最后答案，还要检查它是否在正确场景触发、是否正确调用工具，以及是否真的改变了目标状态。
Agent 测评入门系列
- 【Eval】Agent测评不是简单给回答打分
- 【Eval】测试同学别焦虑，Eval也不是替代品
- 【Eval】第一次Eval，先干小事情（本文）
- 【Eval】测Skill，不只是盯结果
- 【Eval】分数变高，不代表版本真的变好
- 【Eval】规则、AI裁判和人工怎么成为铁三角
- 【Eval】离线全通过，上线仍会失败的原因到底是啥