如何做coding agent的评测

我的评测集里的每项任务都来自上游的一次改动或 issue。我通常会把修复前的最后一个完整commit作为起点，再写一份内容完备、可以独立理解的任务说明，只描述预期结果，不透露原始补丁。

每项评测任务都会记录一个完整的commit ID，我称之为评测种子。这个种子精确指向应当交给agent的代码树。

评测工具会导出这棵代码树，把它导入一个全新的仓库，创建一个基线commit。这样就得到了准备好的工作区，里面只有当时的源码快照，没有上游远程仓库、后续commit或者评测者的笔记。新仓库中会保留一个基线引用，即使agent提交了自己的修改，评分器仍然可以检查它改动了哪些文件。

这样同时解决了两个问题：每次运行都从完全相同的代码开始，agent也无法通过本地历史找到当时的修复方案。已知的修复方案放在准备好的工作区之外，另存为一份评测参考文件。

评测运行器只需向agent提供一个可执行程序、工作区路径，以及任务文本或临时提示词文件，这样评测集就不依赖某一个agent。Froe可以运行这些任务，其他能够接收工作目录和提示词的agent也可以。

防止答案泄漏还取决于周边环境。如果第三方agent可以不受限制地访问网络，它就有可能搜索到上游issue或commit。要让不同agent的运行结果可比，就要为它们采用同样的文件系统和网络策略，只允许访问准备好的工作区，并把参考材料放在它们无法读取的地方。

结果方面，我会评测代码的行为、修改范围和用户体验。我不要求agent复现某个特定的“标准答案”。

编程agent的输出有随机性，一次严肃的比较需要重复试验。每轮评测都会固定agent版本、模型、推理强度、时间限制和审批策略。每个agent都会在同样的环境和任务顺序策略下拿到一个全新的工作区。

每组agent和任务的组合至少运行三次。报告会列出整项任务的通过率，得分和耗时取中位数，用户干预则单独记录。