RE-Bench：研发型 AI 代理评测的使用边界
RE-Bench 用受控研究工程任务比较人类与模型代理表现，适合补充研发风险评测，而非替代内部上线验证。
RE-Bench evaluation research ai-safety RE-Bench 用受控研究工程任务比较人类与模型代理表现，适合补充研发风险评测，而非替代内部上线验证。
1. 产品定位
RE-Bench 是 METR 发布的研发工程型评测：代理或人类在给定计算机、资源、评分函数和时间预算的环境中完成优化任务。[S1][S2] 首批公开集合有七个环境，任务包括拟合 scaling law、优化 GPU kernel 等。[S1] 它衡量的是受控条件下的研究工程表现，不能直接证明模型在公司代码库、长期研发项目或真实安全流程中的自主能力。
2. 评测问题与边界
采用 RE-Bench 前先把问题写清楚：是比较模型版本、检验脚手架、观察时间预算效应，还是给高风险研发自动化设基线？官方说明指出，真实 ML 研发常有目标模糊、反馈周期长、启动困难等差异。[S1] 因而报告必须保留任务集合、模型、提示词、工具、预算和运行次数；不得把单次最高分、公开榜单或短预算结果表述为“能替代研发人员”。
3. 环境复现与隔离
从官方仓库建立独立评测环境，固定提交版本、容器镜像、GPU 型号、驱动、依赖和随机种子。[S2] 代理只使用评测所给账户和目录，不能访问公司源码、云凭据、内部论文或生产网络。网络是否开放、可用工具及计算配额都应纳入运行记录；这些变量改变时应视为新实验，而不是把不同条件的分数放在同一张趋势图中。
4. 人类基线的解释
RE-Bench 的特点之一是让人类与 AI 在相同环境和资源下比较。[S1] 复用其方法时，要记录参与者经验、熟悉程度、工具权限和尝试次数，避免让一方拥有额外上下文。人类基线的价值是校准任务难度和评分函数，不是为每个研发岗位生成一个可替代性的排名。涉及员工评价时，必须取得参与者知情同意，并对原始操作记录做最小化留存。
5. 时间预算与重复试验
官方结果显示，代理在不同时间预算下的相对表现并不相同，且中位数尝试未必取得明显进展。[S1] 因此每个模型至少运行多个独立种子，分别报告中位数、分位数、最高分和失败率；将短预算与长预算分开分析。若使用 best-of-k，只能将其作为资源允许时的上界，且必须公开 k、总计算成本和选择规则，不能与单次尝试混为一谈。
6. 评分函数与反作弊
评测前人工审查每个评分函数是否奖励了真正的研究工程改进，而非硬编码答案、利用测试漏洞或牺牲可维护性。官方环境强调新颖性、可获得反馈和难以饱和等设计取向。[S1] 本地扩展题应至少保留一组未公开测试，并把数据、参考答案和评分服务与代理隔离。发现异常高分时，先复跑并审计提交差异，再决定是否计入结果。
7. 风险信号与人工复核
对代理命令、网络请求、代码改动、资源消耗和评分轨迹做结构化记录。需要人工复核的信号包括：反复尝试绕过限制、读取非任务路径、异常 GPU 消耗、修改评分器、或生成无法复现的高分。评测运行应可被立即停止，且停止后回收临时凭据和计算资源。评测系统的权限设计要比被测代理更严格，防止“为了测能力”意外开放真实研发资产。
8. 结果报告
报告先写实验条件，再写结论：任务覆盖了什么、没有覆盖什么、表现波动多大、成本是多少，以及与人类基线的可比性。METR 也指出公开环境数量有限，并与真实世界存在系统性差异。[S1] 内部决策可将结果与代码评审质量、事故率、研究周期等本地指标并列，但不能从基准得分推出安全性、可靠性或商业收益。
9. 验收与发布门槛
一次可信运行至少满足：仓库与依赖可复现、权限隔离有效、评分器未被改动、运行日志完整、关键结果可复跑。拟把评测用于模型准入时，再增加红队题、长期任务和内部代表性任务，并设置人工审批。只有当结论在预先定义的预算和重复次数下稳定，才允许将它作为风险评审的一个输入；最终上线仍需通过独立的产品、隐私与安全验证。
10. 来源与更新时间
本文以 METR 的发布说明和 RE-Bench 官方仓库为依据。[S1][S2] 环境数量、代码、模型适配和评测结论可能更新；每次复用前应锁定版本并重新核验。所有结论均限于对应任务和资源条件。