先这样答
Agent 评测系统按评测集层、执行层、判定层和报告层进行分层设计。评测集层维护固定题集用于日常回归，并动态补充新题。执行层在沙箱环境中运行 Agent，对同一题目重复执行以对齐模型自身的随机性。判定层优先使用确定性判据，如测试通过状态、终态校验和格式校验，不可用代码量化的部分由 LLM 按评分标准打分，并辅以人工抽检校准。最后，报告层按不同维度输出指标与失败案例的归因分析。
Trace 数据需要按 trace_id 串联成可回放的时间线。具体记录内容包括每次模型调用的完整输入输出及工具定义，工具调用的请求参数、返回结果、耗时和错误信息。同时记录每步的上下文快照或摘要、分支与路由决策点、步数和 token 消耗，以及异常重试事件和最终判定结果。这些数据不仅用于算分，也是失败案例回放归因、回归测试复现以及线上真实失败模式回流挖掘新题的底稿。
在指标设计上，确定性指标看重任务成功率、格式合规率、工具调用正确率（选对工具且参数正确）、步数效率及成本延迟。当回复质量无法代码化时，采用 LLM-as-Judge 方案。通过提供详细的评分标准与参考答案、设定低温度、多评委投票来保证客观性，并持续监控其与人工标注的偏差指标。评测系统的核心在于把非确定性的生成过程拆解为可观测的具体步骤。
面试官会怎么追问
-
「Agent 回复质量无法通过代码直接衡量时，具体怎么打分保证客观？」 将评分标准细化为具体的 rubric，在提示词中提供明确的参考维度和基准答案。将打分模型的温度调低，采用多评委投票机制。同时必须定期做人工标注抽检，监控 LLM 评分与人工评分的偏差指标。
-
「大模型本身有随机性，同一个任务跑两次结果不一样，执行层怎么处理？」 在执行层对同一个题目进行多次重复运行。统计判定指标时采用多次运行的通过率或者 pass@k 来衡量任务的稳定性。这种机制可以避免单次运行的偶然失败干扰整体评测结果。
-
「记录那么多 Trace 数据，在日常迭代里有什么具体用处？」 Trace 数据是失败案例归因的直接依据，能像录像一样回放是哪一步路由选错或者工具参数传错。它还是回归测试的复现底稿，线上 Trace 中暴露的真实失败模式可以直接提取出来，补充到评测集的动态题库中。
回答的坑
- 把所有判定都交给 LLM 打分，正确方向是明确分层判定，优先校验格式合规、工具调用参数等确定性指标，主观题才用 LLM 评分。
- Trace 数据记录粒度太粗只记头尾，正确方向是强调按 trace_id 串联时间线，细化到记录中间每一步的上下文快照、路由决策和工具请求返回详情。
同系列的题