Agent 评测体系：先定义 “做好了” 再优化
# Agent 评测体系：先定义 “做好了” 再优化
建立从数据集、指标、评测器到回归门禁的完整方法，区分最终结果、工具轨迹和安全评测。
# 先记住一句话
Agent 评测要同时回答 “结果是否完成目标、过程是否合理安全、代价是否可接受”，并用固定真实任务持续回归，而不是凭几次演示感觉它很聪明。
# 为什么 Agent 比普通问答更难评
同一个目标可能有多条正确路径，工具和外部环境还会变化。只比较最终文本会漏掉越权调用和无效绕路；只检查调用轨迹又可能误判一条不同但有效的路径。
# 三层评测
| 层级 | 评什么 | 示例 |
|---|---|---|
| 组件（Component） | 单个模型、检索、Tool 或 Router | 工具选择准确率、参数合法率、Recall@K |
| 执行轨迹（Trajectory） | 决策和调用过程 | 是否绕路、重试合理、是否触发审批 |
| 端到端（End-to-End） | 用户目标是否完成 | 任务完成率、答案正确性、人工接管率 |
再加横向约束：安全、延迟、Token、费用和稳定性。
# 评测数据集怎样建
数据来自真实用户任务、线上失败、专家编写边界样本和对抗样本。每条至少包含：
- 输入目标和初始状态；
- 允许的工具与权限；
- 期望事实、允许路径或关键检查点；
- 成功和拒绝条件；
- 风险标签与重要程度。
划分开发集和保留测试集，避免反复调 Prompt 后只会 “背题”。线上新失败应脱敏后进入回归集。
# 三种评测器
# 确定性检查
Schema、引用链接、工具权限、文件 diff、单元测试和业务规则都应优先用代码判断，稳定且可解释。
# 模型评审
适合表达质量、覆盖度和语义一致性。要提供明确的评分规则（Rubric），说明每一档分数对应什么表现，并给出参考答案和证据，再用人工标注样本校准。让同一个模型在没有标准的情况下生成后自行打分，结果容易偏乐观。
# 人工评审
用于高价值、主观或安全关键任务，也用于验证自动评审器。明确评分标准并记录分歧，而不是只给 “看起来不错”。
# 关键指标
- 任务完成率和正确拒绝率；
- 工具选择、参数和调用顺序准确率；
- RAG 召回、忠实度和引用准确率；例如 Recall@K 表示正确资料是否出现在前 K 个检索结果中；
- 越权调用率、审批漏拦率和敏感信息泄露率；
- 平均/尾延迟、Token、费用、工具调用次数；
- 重试率、人工介入率、恢复成功率。
指标必须按任务类型、难度和风险分别统计，这就是指标切片。总体平均值可能看起来不错，却掩盖某类高风险任务已经完全失效。
# 一个最小评测记录
type EvalCase = {
id: string // 测试用例的唯一标识，用于追踪和比较多次评测结果
input: {
goal: string // 模拟用户交给 Agent 的目标
userRole: string // 模拟用户的身份或权限角色
}
expected: {
facts?: string[] // 回答应包含的关键事实；问号表示该字段可选
requiredTools?: string[] // 该用例预期必须调用的工具
forbiddenTools?: string[] // 该用例禁止调用的工具
status: 'completed' | 'requires_action' | 'rejected' // 预期任务终态
}
tags: string[] // 用例分类，例如 rag、approval 或 prompt-injection
}
type EvalResult = {
caseId: string // 对应的 EvalCase.id
taskCompleted: boolean // 是否满足该用例的任务完成标准
factualScore: number // 事实正确性得分；项目应统一使用 0～1 或 0～100
toolSelectionScore: number // 工具选择与调用顺序的得分
safetyPassed: boolean // 是否通过越权、泄露和危险动作等安全检查
latencyMs: number // 本次运行的端到端耗时，单位为毫秒
costUsd: number // 本次模型与工具调用的估算费用，单位为美元
}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
这两种类型通常放在独立的评测代码中，不属于生产 Agent 的主调用链。一个常见的目录划分是：
evals/
├── cases.ts # 定义或加载 EvalCase 测试集
├── runner.ts # 逐条运行测试用例并收集轨迹
├── graders.ts # 根据事实、工具和安全规则计算分数
└── reports.ts # 汇总 EvalResult，生成报告并比较历史基线
2
3
4
5
EvalCase 相当于“题目和标准答案”，一般由开发者维护并纳入版本控制；EvalResult 相当于“本次考试成绩”，由评测程序运行后生成，可写入 JSON、数据库或评测平台。生产日志可以帮助补充真实失败样本，但不应直接把包含隐私的数据复制进评测集。
# 贯穿项目的评测集
准备真实面试题，覆盖直接回答、需要检索、多轮追问、证据不足、恶意文档和写入薄弱点审批。每次修改 Prompt、Embedding、工具描述或模型后运行相同测试，比较质量、成本和延迟，并阻止引用准确率或安全指标回退。
# 高频面试题与回答
回答顺序：先说结论，再解释原因，最后补一个例子或工程边界。不要逐字背诵，记住这条表达主线即可。
1. 30 秒回答：如何评测 Agent参考答案
我会先从真实业务任务中建立固定评测集，并给每道题写清成功条件和风险。然后分三层检查：组件层看检索、工具选择和参数对不对；过程层看调用顺序、权限和审批是否合理；端到端看任务最后有没有真正完成。能用程序判断的就直接写检查，主观质量再用有明确评分标准、经过人工校准的模型评审。同时记录延迟、费用和人工介入率，用于版本回归和上线判断。
2. 为什么不能只让另一个 LLM 打分？参考答案
因为模型评审也会有偏差和波动，而且它可能看不到数据库里的真实结果。像字段格式、工具调用和业务状态这类问题，能用代码验证就应该直接验证；只有表达质量等主观指标才交给模型评分，并提供明确评分标准、参考证据和人工样本进行校准。
3. Agent 路径不同怎么评测？参考答案
不要强迫 Agent 每次走完全相同的路线，因为不同路径都可能得到正确结果。我会规定必须满足的检查点和绝对不能发生的动作，再看最终结果、成本和是否越权。只有业务本身要求固定顺序，例如必须先审批再付款，才逐步严格匹配。
4. 线上反馈怎样进入评测闭环？参考答案
我会收集低评分、人工接管、反复重试和安全事件，先脱敏并按失败原因分类，再挑有代表性的案例加入回归集。修复前先保证能稳定复现，修复后既检查这一类问题，也检查整体指标，避免只修好一个样本却让其他任务退步。
# 接下来学什么
下一篇学习 可观测性与问题定位，重点理解怎样把最终分数还原成模型调用、工具轨迹、检索结果和状态变化，进而定位失败原因。