一句话总结：Agent 评测的单位是轨迹（trace）而非单个回答——"答对了但过程烂"（错工具、运气好、不会恢复）也是坏 Agent；评测分任务成功（结果）与轨迹质量（过程）两层，且因非确定性必须统计化回归。

Agent eval vs Model eval

维度	Model Eval	Agent Eval
输入	一个 prompt	目标 + 环境
输出	文本响应	一连串动作（轨迹）
标准答案	期望答案	期望的最终状态
打分	字符串/向量匹配	状态比较 + 分步评分

为什么难

• 非确定性：同一任务多次运行结果可能不同 → 单次 pass/fail 不可靠
• 正确结果可来自坏路径：错工具、lucky 参数、无错误恢复
• 所以：评分轨迹 = 评估能力；只看最终回答 = 评估运气

三层评估（LangChain：Run / Trace / Thread）

1. Run 层：单次 LLM 调用或工具调用——"这步调对工具/参数了吗"
2. Trace 层：一次 Agent 回合完整执行——"流程对吗、恢复了吗、走了几步"
3. Thread 层：多轮对话跨时间——"长期目标达成了吗"

两类指标

• 任务成功（outcome）：最终目标是否达成 → "Agent 能不能用"
• 轨迹质量（trajectory）：步骤数、错误动作、循环、成本、恢复能力 → "Agent 为什么好/坏"

评测方法

方法	适用	局限
规则/确定性校验	结构（JSON 合法）、必要步骤、预算检查	判不了语义
LLM-as-Judge	主观质量：答非所问、遗漏、过度承诺	有偏差需防护
人工标注	高保真	慢、贵
基准集	横向对比	覆盖有限

LLM-as-Judge（Zheng 2023 范式）

• 流程：任务描述 + Agent 轨迹 + 最终输出 → 强 LLM（judge）按 rubric 打分
• 变体 Agent-as-a-Judge：judge 自身也是 Agent，能观察中间步、用工具、对动作日志推理，给分步反馈
• 已知陷阱：位置偏差、自我偏好（偏袒同源模型）、冗长偏差、rubric 不严谨
• 对策：rubric 细化、多次 judge 平均、交叉验证、关键结构用确定性校验兜底

主流基准

• AgentBench（清华，ICLR'24）：8 大环境（OS/数据库/知识图谱等），综合 LLM-as-Agent；结论：商业模型 vs 70B 以下开源差距明显
• τ-bench：业务 Agent（客服/零售）的黄金标尺
• SWE-bench：coding Agent 标尺
• WebArena：浏览器/网页 Agent 标尺
• AgencyBench：1M-token 真实长程任务、90+ 工具调用（贴近生产）
• AgentJudgeBench / MobileJudgeBench：专门评测"裁判"本身的可靠性

回归测试（生产关键）

• 传统回归没法直接套（Agent 无"一次 deploy 可 hook 的代码"）
• 做法：每次换模型/改 prompt/更新知识库，重跑一组已知好轨迹，对比聚合分数
• 非确定性处理：每 case 跑 N 次取平均分（非单次 pass/fail），对比基线；用置信区间/三值判定（PASS/FAIL/INCONCLUSIVE）
• 成本优化：AgentAssay 用随机测试语义 + 覆盖度量，回归成本降 78–100% 且保统计保证
• CI 集成：每次代码变更跑全量或快速子集，分数下降即报警

落地建议（golden set + CI）

1. 建 golden set：覆盖各工具路径、错误恢复、边界条件的已知任务
2. 每任务多次运行，记录任务成功率 + 轨迹质量分
3. 关键结构用确定性校验，语义用 LLM-as-Judge
4. 接入 CI：模型/prompt/知识库变更触发回归，非确定性取平均对比基线

面试要点

• 讲清"评估单位是轨迹不是响应" + 任务成功 vs 轨迹质量
• 说出 Run/Trace/Thread 三层各问什么
• 知道 LLM-as-Judge 的价值与四大偏差
• 知道基准定位：AgentBench 综合 / τ-bench 业务 / SWE-bench 代码 / WebArena 网页
• 知道非确定性回归：N 次取平均 + 基线对比 + 成本优化