先这样答
从零构建 Agent Benchmark 主要围绕任务定义、环境与数据构建、指标设计、防污染及校准这四个阶段展开。核心目标是保证评估结果客观、可复现，并且能真实反映模型在复杂交互中的能力。
首先要界定任务域并确立客观的成功判据。通常选择结果能自动校验的场景，例如缺陷修复看单元测试是否通过，数据问答看答案匹配度，工具调用看最终状态是否符合预期。在此基础上构建数据集，每个任务实例需包含输入、环境初始态和验收标准。为了保证同一实例多次运行结果一致，必须搭建可控、可重置的运行环境，如使用独立容器、沙箱或 mock 服务。数据规模上，初期先保证小而准，覆盖核心难度梯度后再做扩充。
其次是设计合理的评估指标。除了严格判据下的成功率，考虑到大模型输出的随机性，常引入 pass@k 或多次运行通过率。同时需记录步数、token 消耗和运行时长等过程指标，并将结果划分为完全成功、部分完成和失败，这比单一的二值判断更有区分度。在发布前，必须让人类专家先做一遍测试，排除不可解的实例，确定合理的长时阈值。
最后是建立防污染机制。为了防止评测集泄露导致被针对性优化，任务实例应避开公开训练语料，预留不对外的 holdout 测试集，并建立定期换新实例的机制。总体而言，构建 Benchmark 的重心在于环境的可控性与判据的严谨性。
面试官会怎么追问
-
「如果具体到代码缺陷修复场景，你会怎么设计环境和判据？」 缺陷修复场景的环境需要基于容器构建，内置特定版本的语言运行环境和依赖库。判据主要依赖单元测试，以补丁应用后能否通过测试用例为准。同时要限制 Agent 的运行时间和执行步数，防止陷入死循环。
-
「Agent 运行有很大的随机性，如何保证评测结果的稳定性？」 可以通过增加单实例的运行次数来计算多次运行的平均通过率，或者采用 pass@k 指标来衡量。在环境层面，需要确保所有外部接口都被 mock 处理，消除网络延迟或第三方服务状态变化带来的干扰。
-
「怎么判断现在的模型是不是在你的评测集上刷过榜？」 可以通过保留不对外公开的 holdout 测试集来做交叉验证，对比模型在公开集和隐藏集上的表现差异。另外可以定期更新评测实例中的具体实体名称或数值，如果模型依然输出旧答案，说明存在数据污染。
回答的坑
- 误以为评测 Agent 就像评测传统 NLP 模型一样只需要问答对，正确方向是强调 Agent 评测必须依赖可交互且可重置的动态环境。
- 在指标设计上只关注最终任务是否成功，正确方向是补充步数、token 开销等过程指标，并采用多梯度的评分机制来区分模型能力。
同系列的题