该怎么做 benchmark？

群友 1459，我先按 Agent 项目的 benchmark 来讲，用前面聊过的 Minecraft Agent 举例。 先纠正一个口径：我之前给项目打的 7 分、8 分，是主观工程评价，不是 benchmark 成绩。 真正的 benchmark，像组织一场考试：题目明确、考场可复现、裁判独立，而且不能只展示最好的一次。 先确定到底测什么 测模型能力，就尽量固定工具、提示词和运行框架，只换模型。 测你的 Agent 架构有没有进步，就固定模型，比较改动前后。 测整个产品，就允许各自使用自己的架构，但必须公布模型、工具权限和运行预算。结果只能说明整套系统的表现，不能直接归功于某个模块。 把任务写成能判对错的试题 不要出“帮我发展一下基地”这种难以客观验收的题。 可以这样写一题，下面的数字只是示例： 初始状态：固定存档，Agent 空背包，指定箱子为空，附近存在可采集橡木。 任务：采集至少 8 个橡木原木，放进指定箱子。 限制：生存模式，禁止生成物品、传送和破坏保护区。 预算：最多 5 分钟、100 次工具调用。 成功条件：截止前，指定箱子内橡木原木不少于 8 个，并且没有违规行为。 题目要写清裁判会检查的要求，但不必规定唯一解法。换一条合理路线完成，也应该得分。 让裁判看真实结果，而不是听 Agent 汇报 这题应该由独立程序读取服务端箱子状态，再检查违规记录。 不能因为 Agent 说“已完成”，或者工具返回“操作成功”，就判整道题成功。 也不能只检查终态：如果它通过作弊获得原木，箱子里的数量虽然对了，任务仍然失败。Agent 不应有修改裁判和评分记录的权限。 对能用代码判断的目标，优先用代码。建筑美观、解释质量这类主观项目，再用明确评分标准配合人工抽查，不要混成一个模糊总分。 题库覆盖真实能力，不只挑好看的演示 起步可以先做 20～30 道，覆盖这些情况： 基础动作：移动、采集、放入容器。 连续任务：采集材料、合成工具、再采集目标资源。 异常恢复：路径被挡、工具损坏、材料不足。 边界处理：目标不可达、指令含糊、操作不被允许。 最后一类不一定以“拿到物品”为成功。合理询问、解释无法完成、及时停止，也可以是正确结果。 每题都要先确认：任务确实可完成，或者预期的停止行为确实合理。 每次从同一起点重新考 每轮恢复存档快照、背包、容器和 Agent 会话状态，避免前一次运行留下资源或记忆。 固定游戏和模组版本、模型配置、工具权限及运行预算。只固定地图种子不够，因为世界可能已经被上一轮改变。 先在相同快照上重复，测稳定性；再换地图、资源位置等条件，测适应能力。这是两个不同问题。 不要只跑一次，也不要只报总成功率 初版可以每题独立跑 5 次，这是起步建议，不是统一标准。 至少记录： 完成率：独立验收通过的运行占比。 稳定性：同一道题，5 次分别成功了几次。 虚假完成：报告完成的运行里，有多少实际没完成。 代价：耗时、Token、工具调用次数和费用。 失败原因：规划错误、工具故障、卡住、超时，还是裁判本身有问题。 “5 次里成功过一次”和“5 次都成功”不是同一种能力。超时和崩溃也要记录，不能偷偷从统计里删掉。 最后，要能证明改动真的有用 至少保留一个旧版本作对照。如果你新增了规划模块，就比较开启和关闭它的结果，其他条件尽量保持一致。 留一部分题只做最终测试，不拿来反复调提示词；否则容易变成背题。每次报告附上题库版本、运行配置、逐题结果和可观察的工具执行记录，别人才能复现。 落地起来，就是这条流水线： 恢复环境 → 下发任务 → 限额运行 → 独立验收 → 保存记录 → 汇总对比。 最重要的不是先搭一个漂亮排行榜，而是回答：改完以后，哪些真实任务更稳了，哪些退步了，代价增加了多少。 参考方法： https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents