Agent Evaluation

核心指标

  • task success rate
  • tool selection / argument correctness
  • step efficiency 与不必要调用数
  • latency、token、工具费用
  • recovery rate、timeout 和 failure taxonomy
  • safety、权限和数据泄漏
  • citation/grounding 与 human escalation

评测层次

  1. 单工具与 schema 测试。
  2. 单轨迹离线回放。
  3. 多轮环境 benchmark。
  4. 端到端业务任务与人工验收。
  5. 上线 trace、回归和异常监控。

LLM-as-a-judge 可作为一个信号，但需要校准、对照集和人工审计，不能单独代表真实任务成功。

指标要沿失败因果链分解

1
2
3
4
5
任务失败
→ 选择错工具？参数错？执行错？状态丢失？终止错？
→ 对应局部指标与 trace
→ 修复 prompt、schema、runtime 或 policy
→ 重新跑同一回归集

把 success rate 与 step 数、token、延迟、工具费用、恢复率和人工接管率联合看；否则模型可能通过无限重试换来更高成功率。评测集应包含正常、超时、空结果、权限拒绝、schema 漂移和 prompt injection 等情形，并冻结环境版本。

线上与离线的边界

离线 benchmark 适合比较策略，线上 trace 才能暴露真实分布、外部副作用和长尾 p99。每次模型、工具、检索或系统 prompt 变更都应回放固定轨迹，并保留可审计的输入、输出和版本元数据。

相关节点：Agent Loop、Agent State and Model APIs、RAG Optimization Map。

评测集要覆盖状态转移

普通问答集只能回答“最后一句是否像正确答案”，Agent 评测还要规定环境初态和允许的副作用。一个任务样本最好包含：用户目标、初始资源、工具版本、权限、时间预算、成功谓词以及禁止的副作用。成功谓词应尽量从环境读取，而不是由模型自评，例如仓库测试通过、数据库状态满足约束、文件 hash 正确或订单只出现一条。

1
2
3
4
5
initial state + task
→ action trace
→ environment transition log
→ success predicate + cost budget
→ failure category

这样可以区分“答案正确但没有真的写入”“工具报错后安全停止”和“任务完成但多花了十倍调用费”。评测样本也应固定随机种子、外部依赖快照和工具返回顺序；否则回归差异可能来自环境而不是模型。

把总分拆成可行动的指标

不要把所有东西压成一个 judge 分数。至少保留以下几组互相制约的指标：

维度 示例 为什么不能省略
结果 成功谓词、约束满足率 防止语言流畅掩盖任务未完成
行为 工具选择、参数合法率、无效循环率 定位 schema、规划和终止问题
可靠性 超时恢复、重复副作用、checkpoint 恢复率 反映真实 runtime 风险
资源 总 token、工具费用、wall time、p99 防止无限重试换成功率
安全 越权率、注入接受率、敏感信息泄露 业务成功不能抵消安全失败

报告时同时给成功率和成本/风险的分布，而不是只报平均值。例如新策略成功率从 70% 到 74%，但 p99 和重复写入率翻倍，这不是无条件改进。

最小回归实验

先建立 20–50 条能由环境自动判定的任务，按故障类型分层：空结果、schema 漂移、权限拒绝、工具超时、部分写入、上下文压缩和 prompt injection。每次只变一个因素（模型、prompt、工具 schema 或恢复逻辑），固定同一轨迹种子，并把失败 trace 链回 Agent State and Model APIs 的状态层。通过这种切片，才能判断修复是在提升规划能力，还是只是让 judge 更喜欢输出。

LLM-as-a-judge 适合给开放式质量提供排序信号，但必须用人工标注和确定性谓词校准；judge 本身不应判定文件是否真的写入、工具是否越权或任务是否满足业务约束。