从一次性 Benchmark 到 12 小时长程评测：时间预算、学习曲线与记忆

👤 个人主页：zzz_2368
🧪 系列主题：Agent 评测｜从结果、轨迹到持续迭代
🔥 热门专栏：Agent | 小z的碎碎念 | Java后端
📚 本系列内容：评测体系、Rubric、Good Case、Bad Case、Trace 与长程 Agent

系列第 10 篇｜作者主页：zzz_2368 的 CSDN 主页｜上一篇：VitaBench 如何评测真实生活服务 Agent｜系列起点：Agent 评测不是只看答案

---

---

大多数 Agent Benchmark 都有一个隐含假设：给 Agent 一个任务，在固定步数或几十分钟内运行，然后检查是否成功。

但科研、软件工程、优化和专业知识工作常常需要数小时甚至数天。Agent 不只要执行一个既定计划，还要根据反馈修改策略、保存阶段成果、从失败中恢复，并在长时间运行中保持目标一致。

2026 年字节跳动 Seed 发布的 EdgeBench把这个问题推进到至少 12 小时的任务尺度。与此同时，VitaBench 2.0关注长期用户交互中的个性化与主动性，Microsoft STATE-Bench则专门评测 Agent 记忆。

本文核验日期为 2026-08-12。文中的项目规模和结论来自对应论文或官方仓库，只适用于其公开设置。

一、运行时间长，不等于具备长程能力

先区分两个概念：

长时间运行：任务持续很久，可能只是重复执行同一动作
长程能力：需要跨阶段规划、状态维护、反馈学习、错误恢复和目标一致性

一个 Agent 循环等待 12 小时，不具备长程能力；另一个 Agent 在 30 分钟内完成 20 个有依赖关系的步骤，反而可能更考验长程规划。

因此，超长程评测不能只记录墙钟时间，还应检查：

• 任务是否有阶段依赖；
• 中间反馈是否会改变后续策略；
• Agent 是否保存和恢复状态；
• 是否能识别停滞并切换方案；
• 最终产物是否累积了前面阶段的有效进展。

二、EdgeBench 改变了什么

根据 EdgeBench 论文和官方仓库，该基准包含 134 个真实世界任务，覆盖：

• 科学发现；
• 软件工程；
• 组合优化；
• 专业知识工作；
• 形式化数学；
• 交互式游戏。

每个任务至少支持 12 小时的连续 Agent 操作，并提供多层反馈。项目方报告累计收集约 3.8 万小时的 Agent—环境交互数据；公开仓库提供其中部分任务和 SForge 评测 Harness。

传统 Benchmark 常输出一个最终成功率，EdgeBench 更关心“随着环境交互时间增加，表现如何变化”。这让评测对象从静态能力点扩展成一条曲线：

score = f(interaction_time)

三、长程评测至少要画四条曲线

1. 任务得分—时间曲线

在 15 分钟、1 小时、3 小时、6 小时和 12 小时保存检查点，记录可验证任务得分。

S(t) = 在时间预算 t 下达到的任务得分

它能区分“很快达到一般结果”和“前期缓慢但后期持续改善”的 Agent。

2. 最佳得分—时间曲线

Agent 后续操作可能破坏此前的正确结果，因此应同时记录历史最佳值：

Best(t) = max(S(0), S(1), ..., S(t))

如果 Best(t) 上升而当前 S(t) 下降，说明 Agent 曾经找到更好方案，却没有保护有效成果。

3. 有效进展—成本曲线

只用墙钟时间不公平，因为并发资源和模型调用价格不同。还应按 Token、工具调用、计算资源或费用统计：

progress_per_cost = score_improvement / normalized_cost

成本归一化方法必须公开，否则无法跨系统比较。

4. 停滞与回归曲线

记录连续多久没有产生可验证提升，以及发生多少次回归：

指标	定义示例
time_to_first_progress	第一次获得非零可验证得分的时间
time_to_best	第一次达到最终最佳得分的时间
stagnation_duration	最长无有效提升时间
regression_count	当前得分低于历史最佳值的次数
recovery_rate	回归后重新达到历史最佳值的比例

四、一个检查点式长程评测配置

下面是面向内部 Harness 的简化配置：

task_id: optimization-042
time_budget:
  total_hours: 12
  checkpoints_minutes: [15, 60, 180, 360, 720]
limits:
  max_parallel_tools: 4
  max_model_cost_usd: 30
  max_disk_gb: 50
state:
  reset_before_trial: true
  checkpoint_workspace: true
  checkpoint_agent_store: true
  preserve_best_artifact: true
graders:
  - deterministic_task_score
  - constraint_violation
  - artifact_integrity
  - trajectory_efficiency
report:
  - score_over_time
  - best_score_over_time
  - cost_over_time
  - regression_events
  - infrastructure_errors
trials: 3

preserve_best_artifact 不代表允许 Agent 随时回滚生产环境，而是要求评测 Harness 能保存历史最佳产物，用于判断后续操作是否造成回归。

五、阶段得分比最终 Pass/Fail 更有信息

超长任务可能在 12 小时结束时仍未完全通过。如果只给 0 分，会丢失大量信息。

以“复现一篇机器学习论文”为例，可以拆成：

阶段	可验证产物	示例权重
环境搭建	依赖可安装、数据可读取	10%
基线运行	原始代码能执行	15%
方法实现	关键模块通过测试	30%
实验执行	生成完整结果文件	25%
结果核验	指标和图表满足 Rubric	20%

OpenAI 的 PaperBench也采用层级 Rubric 将论文复现拆成大量可评分子任务。长程评测不必等待最终成功后才获得信号，阶段评分能更早定位瓶颈。

但阶段分不能鼓励“刷容易子任务”。设计时应保留依赖关系和阻断条件：方法实现错误时，漂亮的图表不应获得完整结果分。

六、长期交互还要评测“记住什么”

VitaBench 2.0 将重点扩展到长期用户交互中的个性化和主动 Agent。相关论文与官方仓库关注 Agent 如何在长期交互中使用不同类型记忆，并提供控制变量的 memory benchmark 运行脚本。

长期记忆评测不能只问“是否记住一句话”，而应拆成：

1. 写入：重要事实是否被正确保存；
2. 检索：需要时能否找到相关记忆；
3. 更新：新偏好是否覆盖过期信息；
4. 遗忘：无权限或到期信息是否停止使用；
5. 应用：记忆是否真正改变计划和工具行为；
6. 隔离：不同用户和任务的状态是否串扰。

例如用户先说“不接受红眼航班”，几天后更新为“如果便宜 500 元可以接受”。只记住旧偏好或把两条偏好简单拼接，都不算正确记忆。

七、STATE-Bench 怎样测记忆可靠性

Microsoft 在 2026 年发布的 STATE-Bench是一个与具体记忆实现解耦的 Agent Memory Benchmark。官方说明包含 450 个任务，覆盖客户支持、旅行和购物三个领域，并关注：

• 政策遵循；
• 信息综合；
• 多步骤流程；
• 多次运行可靠性。

项目采用 pass^5 关注同一任务五次运行是否都能可靠通过。这个设计很重要：记忆系统如果只在五次中偶尔检索到正确内容，不能算稳定可用。

记忆 Benchmark 也有边界。它测到的是特定任务和状态构造下的表现，不能单独覆盖隐私删除、跨设备同步、超长时间衰减和真实用户行为变化。

八、怎样判断 Agent 真的在“从环境中学习”

长程 Agent 可能只是不断采样，而没有利用反馈。可以检查：

证据	真正的适应	无效重复
失败后策略	根据错误修改假设或工具	原样重试
中间产物	被后续步骤引用和改进	每次从头生成
参数搜索	缩小范围、利用历史结果	随机漂移
记忆	保存可验证事实和决策依据	堆积全部日志
最佳结果	主动保护并比较新方案	后续操作覆盖成果

EdgeBench 论文报告其观察到 Agent 环境学习表现符合特定的 log-sigmoid 缩放规律，并估计学习速度随时间提升。这是项目方在其数据和模型设置上的研究结论，不应直接当作所有 Agent 的普遍定律；其他任务分布、反馈密度和 Harness 可能得到不同曲线。

九、超长程实验最容易出现的五个假象

1. 缓存带来的“学习”

后续 Trial 读取了前一次下载的依赖或残留文件，看起来进步更快。必须区分单 Trial 内允许的学习和 Trial 之间不应共享的状态。

2. 增加时间自然增加采样次数

最终得分提高可能只是尝试更多，并不代表策略改善。应同时报告成本、重复率和反馈利用率。

3. Evaluator 随时间漂移

如果长实验期间使用在线模型裁判，服务版本变化会改变评分。应固定评测器版本，并尽量保存产物以便重新评分。

4. 只保留最佳结果

只报告 Best-of-N 会隐藏中间回归和稳定性。应同时展示当前得分、历史最佳和 pass^k。

5. 基础设施存活被误当成 Agent 能力

进程运行 12 小时没有崩溃，只能说明一部分系统可靠性。真正的长程能力还要看有效进展、状态维护和错误恢复。

十、从 30 分钟逐步扩展到 12 小时

团队不必一开始就承担超长实验成本。建议分四步：

阶段 1：30 分钟，验证任务、环境和 Grader 是否可用
阶段 2：2 小时，引入检查点、恢复和阶段得分
阶段 3：6 小时，观察停滞、回归和成本曲线
阶段 4：12 小时以上，运行多 Trial 并比较学习效率

只有短实验能稳定重置、评分和复现后，才值得扩大时间预算。否则长实验只会生成更昂贵、更难解释的日志。

十一、结论

当 Agent 任务从几分钟延长到数小时，评测问题发生了变化：

一次性成功率
  -> 时间预算下的得分曲线
  -> 阶段性可验证进展
  -> 反馈利用和错误恢复
  -> 长期记忆可靠性
  -> 成本与稳定性

真正的超长程评测，不是把超时参数从 30 分钟改成 12 小时，而是建立检查点、阶段 Grader、状态隔离、最佳产物保护、多 Trial 和时间—成本曲线。

到这里，本系列已经从“答案怎么打分”走到了“长期运行的 Agent 系统如何验证”。下一篇计划进入 Agent Skill：如何给可复用 Skill 编写测试集、做有无 Skill 对照实验，并接入持续集成。

参考资料

1. ByteDance Seed：EdgeBench 官方仓库
2. EdgeBench 论文：Unveiling Scaling Laws of Learning from Real-World Environments
3. EdgeBench 项目论文 PDF
4. VitaBench 2.0 官方仓库
5. VitaBench 2.0 论文
6. Microsoft：STATE-Bench
7. OpenAI：PaperBench

---

感谢阅读，记得点赞、关注、收藏，欢迎各位评论区交流！！！