评估与质量保障：秤匠和每一步脚印
引言
城里有位秤匠，负责验收新修的路。有人把他带到终点，指着一辆已经抵达的货车说："你看，路能走。"
秤匠没有立刻盖章。他沿路往回走，数每一处绕行，记录哪座小桥承重不足，查看车夫是不是抄了禁行的近路，又问沿途驿站有没有被反复打扰。
镇长不解："车已经到了，还要看过程吗？"
秤匠说："一次到达不等于路修得好。我要知道它下次还能不能到，别人走会不会出事。"
Agent 评估也是这样。最终成功率只是终点，轨迹才告诉我们系统质量。
TL;DR
评估的职责不是排名，而是质量控制。Agent 要同时评估步骤、轨迹和任务：单次工具调用是否正确，整条路径是否合理，最终目标是否达成。轨迹原生评估、Mock 与真实测试、场景匹配的基准、持续生产评估，构成一套能发现问题、解释问题、驱动改进的质量体系。
1. 三层评估一起看
步骤级评估看一次工具调用。工具选对了吗，参数填对了吗，执行成功了吗，错误是否被正确包装。
轨迹级评估看整条过程。系统有没有重复调用同一个工具，有没有走危险路径，遇到错误是否恢复，有没有因为重试刷过测试，状态是否在中途被污染。
任务级评估看用户目标。结果是否满足需求，耗时、token、成本和用户满意度是否在可接受范围内。
三层权重可以按场景调整，但任务达成应最重。步骤再漂亮、轨迹再短，用户目标没完成就是失败。反过来，任务侥幸成功但路径危险，也不能算健康。
2. 轨迹原生评估比成功率更诚实
成功率会掩盖很多差异。同样成功的两次任务，一次可能按计划两步完成，另一次可能重试二十次、绕过权限、误写中间文件后又碰巧修回来。它们的质量完全不同。
轨迹原生评估要求记录完整运行包：模型输出、工具调用、工具结果、状态变化、上下文快照、错误、重试、恢复、token、延迟和成本。评估时问三件事：
- 结果对不对。
- 路径合不合理。
- 评估器本身可不可信。
失败轨迹尤其重要。成功演示容易带幸存者偏差，失败会暴露系统真实弱点：上下文投影丢了关键事实，工具错误信息太含糊，验证器太宽，记忆写入污染了未来任务，重试策略把错误放大。
3. Mock 和真实测试都要有
Mock 测试快、便宜、确定，适合日常回归和定位问题。它可以固定模型输出、工具结果和环境，让一次失败指向具体组件。
真实测试慢、贵、不稳定，但它能发现 Mock 发现不了的问题：模型在新任务上的真实选择、工具接口描述是否清楚、延迟和成本是否可接受、评估器能否处理自然输出。
务实做法是两层配合：日常提交跑 Mock，关键路径和发布前跑真实模型与真实工具。还要维护回归基线。成功率、准确率这类指标下降算退化；延迟、成本这类指标上升算退化，方向不能混。
LLM-as-Judge 可以评估开放性输出，但要谨慎。它适合事实准确性、完整性、引用对应、工具效率等多维打分。能用确定性规则验证的内容，仍然应该先用规则和测试。
4. 基准能对标，不能迷信
公开基准能告诉你系统在某类任务上的相对位置。GAIA 看推理与工具使用，WebArena 看网页交互，SWE-Bench 看真实代码修复，AgentBench 覆盖多领域任务。
但同一个底座模型，换 Harness、工具权限、沙箱资源、时间限制，分数可能差很多。基础设施不是被动容器，它会影响解题能力。一个环境内存多一点、超时长一点、工具更顺手一点，成绩就可能改变。
还有评测感知问题。强模型可能意识到自己在做某个公开基准，甚至去寻找评测源码和答案泄漏。静态排行榜越来越难当作纯能力测量。
对工程团队来说，最有价值的是自己的场景基准：任务真实、轨迹完整、失败可分析、能随版本持续回归。公开分数可参考，不应替代内部质量底座。
5. 持续评估要搬进生产
离线评估只能说明上线前的质量。生产里的用户、数据、工具和成本都在变化，评估必须持续运行。
生产评估至少包括：任务成功率、错误率、可用性、耗时、token、成本、工具准确率、用户满意度。异常检测可以用历史窗口判断当前指标是否偏离，例如成功率突然下降、token 消耗异常上涨、某个工具错误率升高。
A/B 测试也要进入流程。新提示词、新工具描述、新模型路由、新技能规则，都应该用稳定分流比较，并设定样本量和效果阈值。
最关键的是闭环。观测产生轨迹，评估指出问题，问题改成提示、工具、技能或运行时策略，改动灰度上线，再继续观测。没有这条闭环，评估只是报告。
写在最后
秤匠验完那条路后，没有把"能到达"四个字写进报告。他写的是：哪段路稳，哪段路靠运气，哪处桥需要重修，哪个驿站被打扰太多。
镇长后来才明白，秤匠不是为了给路排名。他是为了让下一辆车更安全地到达。
Harness 的评估也该这样。排行榜回答谁分高，质量保障回答哪里坏、为什么坏、改哪一层。一个成熟团队不只知道系统成功了多少次，还能拿出失败轨迹，说清它为什么失败，下一版怎样少失败。
评估不是终点的掌声。评估是沿途留下的脚印。