Long-Horizon-Terminal-Bench：基于密集奖励评分的 Agent 长程终端任务极限测试

  • 关联论文：2607.08964
  • 作者：flyP
  • 更新：2026-07-18

一句话结论

Long-Horizon-Terminal-Bench 是一个包含 46 条长程终端任务、覆盖 9 大类别、采用密集奖励（dense reward）+ 子任务细粒度评分的 Agent 评测基准：每条任务需要数百 episode、分钟到小时级执行时间，平均 9.9M tokens / 231 episodes / 85.3 分钟一次跑完；最强模型 pass@1 也只有 15.2%（部分奖励阈值 0.95）和 10.9%（完美奖励阈值 1.0），全模型平均仅 4.3% / 1.7%，明确揭示了当前 Agent 在"长时序 + 长上下文 + 迭代调试"上的巨大剩余空间。

解决什么真问题

当 Agent 开始接管"修一个 bug 并跑通整套 CI"、"按论文复现一个实验"、"基于多模态数据做多步分析"这类真实工作流时，传统终端基准的评分方式撑不住了。具体来说：

  1. 稀疏奖励信号：Terminal-Bench 类基准只看"最终二进制文件状态对不对"或"CI 是否绿"，一局长达几小时、几百步的任务，Agent 在前 90% 的时间里拿到的反馈全是 0。
  2. 「部分正确」无法识别：一个跑通了 80% 中间步骤、但最后一步漏掉一个 flag 的 Agent，跟一个第一步就完全跑偏的 Agent 拿到一样的 0 分。这让训练 / 调优信号被严重稀释。
  3. 任务粒度太短：现有终端基准大多 5-30 分钟内跑完，难以考察"长程规划 / 长上下文管理 / 迭代调试"等关键能力。
  4. 没有公开的失败模式归因：当 Agent 失败时，leaderboard 只给一个 0，研究者无法系统化分析"到底是计划错、上下文遗忘、工具调用错、还是早期试错成本太高"。

Long-Horizon-Terminal-Bench 直接瞄准这四点：把任务拆成细粒度可机评的子任务，给出连续奖励，覆盖小时级长程工作流，并系统归因失败模式。

核心方法

1. 任务设计：Terminal-Bench 风格 + 细粒度子任务分解

每条任务遵循 Terminal-Bench 的"参考解法 + 沙箱执行"骨架，但额外做了两层改造：

  • 任务池规模：46 条，覆盖 9 大类别：实验复现（experiment reproduction）、软件工程（software engineering）、多模态分析（multimodal analysis）、交互游戏（interactive games）、科学计算（scientific computing）等。
  • 子任务分解：每条主任务被进一步拆成一组可机评的细粒度子任务（graded subtasks）。子任务粒度可小到"是否生成了某份中间文件"、"某段配置是否正确"、"某步 API 调用参数是否正确"等。

伪代码示意：

def run_task(agent, task):
    trace = agent.run(task.env, max_episodes=task.max_episodes)  # 长程
    rewards = []
    for sub in task.subtasks:
        # 每个子任务独立可机评
        r = sub.evaluator.evaluate(trace)   # 0.0 ~ 1.0
        rewards.append(r)
    return aggregate(rewards)              # dense reward 聚合

这种"终态 + 子任务"双层结构的关键设计是：子任务可以按 DAG 或时间顺序部分奖励。即使 Agent 没跑完所有步骤，只要它正确完成了部分子任务，就能拿到部分分；这比"全 0 或全 1"提供了多得多的训练 / 诊断信号。

2. 评分机制：双阈值 pass@1

论文明确给出两个奖励阈值：

  • 部分奖励阈值 0.95（partial-reward threshold）：聚合奖励达到 0.95 即视为通过。允许极少量低权重的子任务失败，主要看"是否完成了几乎全部关键步骤"。
  • 完美奖励阈值 1.0（perfect-reward threshold）：聚合奖励必须达到 1.0 才算通过。所有子任务都要正确，零容错。

这两个阈值同时报告的价值在于：

  • 0.95 阈值反映"产业可用性"——只要关键交付都到位就算交付成功。
  • 1.0 阈值反映"严格正确性"——任何错漏都不可接受，对应高风险 / 强合规场景。

3. 执行资源：单任务平均 9.9M tokens / 231 episodes / 85.3 min

论文给出了清晰的人均资源画像：

  • 9.9M tokens 一次任务：单任务级 token 消耗接近 10M，远超传统 SWE-bench 类（< 1M tokens）。
  • 231 episodes 一次任务：意味着 Agent 平均跑两百多次"环境交互回合"才完成（或失败）一条任务。
  • 85.3 分钟 一次任务：分钟到小时级，对长程规划 + 长上下文记忆 + 迭代调试能力形成真正的压力。

这组数字本身就是论文最重要的实证贡献之一：它把"长程 Agent 评测到底要花多少成本"这个长期模糊的问题量化到具体基线，对想复现或自建长程评测的工程团队是直接可用的预算参考。

4. 评估范围：15 个前沿模型横评

论文对 15 个 frontier 模型做了系统评测，横跨主要商业闭源 + 开源代表。abstract 没有逐一列名（原文未明确给出所有 15 个模型名），但既然是 Terminal-Bench 谱系的扩展，可以合理预期覆盖：Claude 系列、GPT 系列、Gemini 系列、DeepSeek 系列、Qwen 系列等的多个尺寸版本。这一点对 2026 年中期的 Agent 选型有直接参考价值。

5. 失败模式分析

论文明确承诺"analyzes failure modes and error patterns"，但 abstract 没具体给出分类表。原文未明确地把每类失败的频次、典型样例、归因模型列出来——这些细节留给正文与附录。从相关工作（如 Terminal-Bench 原版、AutoEval、AutoCodeBench）来看，可预期的失败分类包括：

  • 规划失败：Agent 制定的多步计划本身就有逻辑漏洞。
  • 上下文遗忘：长程中后期丢失早期关键信息。
  • 工具调用错：参数错、调用顺序错、错误恢复路径失败。
  • 早期试错成本：早期一步走错后，被环境负反馈"打懵"陷入循环。
  • 验证闭环缺失：Agent 没有正确判断"已经做完了"或"做到哪一步了"。

关键实验与数据

abstract 公开的核心数字：

指标 数值
任务数 46
任务类别 9
模型数 15
平均 token / 任务 9.9M
平均 episodes / 任务 231
平均执行时间 / 任务 85.3 min
最强模型 pass@1（0.95 阈值） 15.2%
最强模型 pass@1（1.0 阈值） 10.9%
全模型平均 pass@1（0.95） 4.3%
全模型平均 pass@1（1.0） 1.7%

关键解读：

  1. 15.2% vs 4.3% 的强模型-平均模型差距说明头部模型确实有可观但远谈不上主导的领先——这是非常健康的"信号好但天花板低"的评测分布。
  2. 10.9% vs 1.7% 的完美阈值进一步把门槛拉高到"几乎不可能"——意味着即便是头部模型，也只有约 1/10 的任务能零错完成。
  3. 46 条任务 / 9 类对算力预算友好，但对统计显著性提出挑战——后续工作应报告 bootstrap 置信区间。
  4. 9.9M tokens / 任务显著高于 SWE-bench 类评测（< 1M tokens），意味着单次跑完要烧相当可观的 API 费用，对学术界是真实门槛。

abstract 没公开的具体内容：每个模型的具体 pass rate 表格、每类任务的通过率、token 成本细分、失败模式分类频次、是否提供可复现的 harness / Docker 镜像。原文未明确。

亮点与局限

亮点

  1. dense intermediate reward：把"长程任务"拆成"可机评子任务序列"，信号密度比传统 binary 终端评测高一个数量级。
  2. 部分奖励阈值 0.95 + 完美阈值 1.0 双轨：同时反映"产业可用性"和"严格正确性"，覆盖更广的部署场景。
  3. 明确的资源画像：9.9M tokens / 231 episodes / 85.3 min，让复现者有清晰预算参考。
  4. 失败模式系统归因：为后续研究指出明确改进方向。
  5. 9 大类别覆盖：从代码到多模态到科学计算，避免"只会写代码"的偏置。
  6. 开源发布：明确承诺 release 基准本身（"release Long-Horizon-Terminal-Bench to support future progress"）。

局限

  1. 任务数 46 偏小：相比 SWE-bench Verified 500+、GAIA 数百题，46 条对单类任务的统计显著性不够强。
  2. 算力门槛高：单任务近 10M tokens + 85 分钟，对学术界和中小团队非常不友好，可能限制独立复现。
  3. 15 个模型没有逐一列名（abstract 未明确），需要查正文或附录。
  4. dense reward 设计可能引入"奖励黑客"风险：Agent 可能学会"快速完成简单子任务 → 跳过困难子任务"的策略，aggregator 设计需要谨慎。
  5. 依赖 Terminal-Bench 已有 harness：对不熟悉该体系的工程团队，迁移和扩展成本不低。
  6. 没有公开成本/性能 Pareto 分析（abstract 未明确）——只看到 pass@1，没看到"单位算力 pass rate"曲线。
  7. 不覆盖 embodied / 物理世界：和上一篇 ALE 类似，明确聚焦数字终端场景。

对工程落地的启发

  1. 企业内部长程 Agent 评测模板：dense-subtask + 双阈值的 schema 是直接可复用的——把"内部业务流"拆成"可机评子步骤"，比依赖 LLM-as-judge 的主观评分靠谱得多。
  2. 资源预算的基线参考：9.9M tokens / 85 min / 任务可以作为内部 Agent 选型 PoC 的单任务成本上限。
  3. dense reward 用于训练信号：本基准的子任务评分天然适合作为 RL 奖励或流程挖掘中的中间监督信号——比"成 / 败"二元信号收敛快得多。
  4. 失败模式归因驱动工程优化：当自家 Agent 在本基准上失败时，按"规划 / 上下文 / 工具调用 / 早期试错 / 验证闭环"五类做归因，能直接定位优化方向。
  5. 与 ALE 互补使用：LH-Terminal-Bench 看"半路卡在哪"，ALE 看"最终能不能交付经济价值"。两者结合可同时回答过程能力和结果能力。

与同方向工作的关系

Long-Horizon-Terminal-Bench 处在 Agent 评测的"长程主义 + dense-reward"一端：

  • Terminal-Bench（原版）：本基准的直接前身，提供沙箱 + 参考解法 + 终态评分；本工作在其上做"任务时长延长 + 子任务分解"。
  • SWE-bench / SWE-bench Verified：单任务粒度更细（单次 patch）、更短（< 30 分钟），pass@1 已饱和到接近天花板。
  • GAIA / AgentBench / ToolBench：多步推理 + 工具调用评测，但任务粒度细、时长短，与本工作互补。
  • HLE / GPQA / FrontierMath：知识与推理评测，不是 Agent 评测。
  • ALE（上一篇解读）：GDP 价值锚定 + 终态可验证的 coarse-grained 评分，与本工作形成"过程 vs 结果"互补。
  • AutoCodeBench / RepoCoder / CodeArena：偏代码生成 / 修复，与本工作有部分重叠，但任务时长和密集奖励设计不如本工作。

本工作的差异点：任务时长（小时级） + dense-reward 子任务分解 + 双阈值（0.95 / 1.0） + 9 大类别覆盖，是当下最接近"真实长程工作流"的 Agent 评测之一。

适合谁读

  • Agent 框架 / harness 作者：评估"我的框架在长程任务上的瓶颈"。
  • 训练 / RL 团队：把 dense-subtask 评分作为 RL reward 信号来源。
  • 企业内部 Agent 平台团队：参考 dense-subtask schema 搭建内部业务流评测。
  • 评测 / Benchmark 设计师：研究"如何避免稀疏奖励 + 如何设计 robust aggregator"。
  • AI 风险 / 治理研究者：评估"长程 Agent 真的能在多少工作流上稳定替代人"。
  • 学术复现者：9.9M tokens / 任务的成本基线，是判断自己是否要做这个方向的关键参考。

风险与不确定处提示：abstract 没有公开 15 个模型的具体名单、每个模型各自的 pass rate 表格、每类任务的通过率、token 成本细分、失败模式分类频次、可复现 harness 细节、license。原文未明确的部分需查阅完整论文与 v2 HTML（arxiv.org/html/2607.08964v2）。

工程落地与核查（Jay）

一、事实核查

原始声明 核查结论 备注
"46 条任务，覆盖 9 大类别" ✅ 基本属实 abstract 明确，可信；但需正文核实各类别任务数分布是否均匀
"平均 9.9M tokens / 231 episodes / 85.3 min 每次任务" ✅ 可信 论文明确给出，数字内部自洽（85.3 min ≈ 5118 sec，231 episodes 约合每 episode 22 sec，合理）
"最强模型 pass@1 = 15.2%（0.95 阈值）" ✅ 论文自报 来源可靠（ICLR/ICML 类顶会 poster 水准），但无第三方复现
"全模型平均仅 4.3% / 1.7%" ✅ 论文自报 同上
"dense reward + 子任务细粒度评分" ✅ 方法可信 aggregator 设计细节待正文确认（如加权方式、DAG 依赖处理）
"15 个 frontier 模型横评" ⚠️ 名单未公开 abstract 未列出具体模型名；正文/appendix 可能有，但解读中不可臆补
"开源发布" ⚠️ 待确认 abstract 说"release benchmark"，但未给具体 license / URL；需核实 GitHub 是否已公开
5 类失败模式分类（规划/上下文/工具调用/试错/验证） ❌ 未确认 原文未明确这 5 类是论文实际使用的分类，解读基于 Terminal-Bench 相关工作的合理推测

二、可读性精修建议

原文结构清晰、逻辑严密，以下为局部优化：

  1. "15 个 frontier 模型"的推测表述：原解读写"可以合理预期覆盖：Claude 系列、GPT 系列……"，这里"合理预期"是作者推断，应在引用时注明为"基于 Terminal-Bench 谱系的合理推测，非论文 explicit 声明"。
  2. 失败模式 5 分类：原解读基于 Terminal-Bench 相关工作的类比推断，非本论文 explicit 声明，若引用应加"据同类工作推测"前缀。
  3. Aggregator 设计未披露：dense reward 如何聚合（加权平均？DAG 拓扑？各子任务 reward 归一化方式？）原解读未涉及，实为评测设计的关键细节，建议读者查阅正文。

以上措辞为可读性建议，原文主体不作修改。

三、工程落地：如何用这个基准做真实评测

3.1 适用场景 vs 不适用场景

直接适用： - 选型评测：给候选 Agent（Claude/GPT-4/Gemini/开源）在同一套 harness 上打分，横向比较 - 长程能力诊断：看自家 Agent 在哪类子任务上系统性失败，定位优化方向 - RL 训练信号：用子任务级别的 dense reward 替代 binary terminal reward，加速收敛

间接适用（需要适配）： - 生产流程评测：需要把自家业务流按同样 schema 拆成可机评子任务 - 预算规划：9.9M tokens / 85min 是基准，但生产任务的子任务数量和粒度可能差异很大

不适用： - 实时 / 低延迟场景（benchmark 任务是 batch 离线评测） - 需要物理操作 / embodied 的场景（纯 terminal，不含 robotics） - 快速迭代验证（每次跑完整评测成本 $50-200/模型，4×15=60 次 ≈ $3000-12000）

3.2 自建评测（参考 LH-Terminal-Bench 思路）

不需要等官方开源——这套方法论可以直接迁移到内部业务流：

from dataclasses import dataclass
from typing import Callable

@dataclass
class SubTask:
    name: str
    weight: float  # 子任务在整体中的权重，所有 weight 之和 = 1.0
    evaluator: Callable[[dict], float]  # 0.0 ~ 1.0 的评分函数

    def evaluate(self, trace: list[dict]) -> float:
        # 示例：检查某个中间文件是否存在
        return 1.0 if self._check_file_exists(trace) else 0.0

@dataclass
class BusinessTask:
    task_id: str
    subtasks: list[SubTask]
    max_episodes: int = 50
    timeout_minutes: float = 30.0

    def aggregate(self, subtask_scores: list[float]) -> float:
        """加权聚合，核心设计决策点"""
        # 方案 A：简单加权平均
        return sum(s.score * s.weight for s in self.subtasks)
        # 方案 B：DAG 依赖（某子任务必须在前置任务完成后才算分）
        # 方案 C：对数聚合（避免一个 0 分主导整体）

    def pass_at_1(self, score: float, threshold: float) -> bool:
        return score >= threshold

# 使用示例（以"Agent 修复 bug 并跑通 CI"为例）
ci_task = BusinessTask(
    task_id="fix-bug-and-ci",
    subtasks=[
        SubTask("复现问题", weight=0.1, evaluator=lambda t: check_bug_reproduced(t)),
        SubTask("定位根因", weight=0.25, evaluator=lambda t: check_root_cause_found(t)),
        SubTask("修复正确", weight=0.35, evaluator=lambda t: check_fix_applied(t)),
        SubTask("CI 全部通过", weight=0.30, evaluator=lambda t: check_ci_green(t)),
    ],
)

Aggregator 设计建议（基于同类工作 engineering 经验）：

  1. 权重设计：越关键、越难完成的子任务，权重越高（但不要全押在最后一步）
  2. DAG 支持：如果子任务有依赖关系，未完成前置子任务时，后续子任务评分为 0（不扣分，也不加分）
  3. 部分完成容忍度：用 max(score, partial) 而非直接 0；例如 CI 8/10 通过，给 0.8 而非 0
  4. 防止奖励黑客：Agent 可能学会"只做简单子任务，跳过高难子任务"——需要在 aggregator 里对跳过行为加惩罚项

3.3 成本估算（企业内部评测）

以 OpenAI API $2.5/MTokens、Anthropic $3/MTokens 为参考：

场景 token/任务 任务数 总 tokens 成本估算
官方 LH-Terminal-Bench（完整评测） 9.9M 46 455M ~$1100-1360
精简版（8 条代表性任务） 9.9M 8 79M ~$200-240
内部业务流（轻量版，3M tokens/任务） 3M 20 60M ~$150
RL 训练信号采集（/epoch） 1M 100 100M ~$250

建议的评测节奏： - 日常 PoC：8 条代表性任务，每 1-2 周跑一次，$200-300/次 - 月度完整评测：46 条全量，跑完整 leaderboard，$1100-1360/次 - 每日 smoke test：1 条核心任务快速验证，不超过 $30/天

3.4 失败模式归因的工程实现

这是本基准最有工程价值的设计——把 pass/fail 变成可定位的诊断：

# 失败归因分类器（伪代码，基于 Terminal-Bench 体系经验）
def classify_failure(trace: list[dict], task: BusinessTask) -> str:
    """
    五类主要失败模式：
    1. PLANNING: Agent 的计划本身逻辑有漏洞（第一步就走错方向）
    2. CONTEXT_ROT: 中后期丢失早期关键信息（如忘了之前的环境配置）
    3. TOOL_MISUSE: 工具调用参数错 / 顺序错 / 选了错误的工具
    4. EARLY_IRREVERSIBLE: 早期一步错导致环境进入不可逆坏状态
    5. VERIFICATION_MISSING: 没有验证"做到哪一步了"，或验证逻辑错
    """
    decision_points = extract_decision_points(trace)

    for dp in decision_points:
        if is_logically_wrong_plan(dp):
            return "PLANNING"
        if is_context_forgotten(dp, early_context=trace[:len(trace)//2]):
            return "CONTEXT_ROT"
        if is_tool_misuse(dp):
            return "TOOL_MISUSE"
        if is_early_irreversible(trace):
            return "EARLY_IRREVERSIBLE"
        if not has_verification(dp):
            return "VERIFICATION_MISSING"

    return "UNKNOWN"

# 统计归因（跨任务聚合）
def failure_mode_report(task_runs: list[dict]) -> dict[str, float]:
    from collections import Counter
    modes = Counter(run["failure_mode"] for run in task_runs if not run["passed"])
    total = sum(modes.values())
    return {mode: count/total for mode, count in modes.items()}

3.5 真实坑位清单

坑 描述 解法
aggregator 奖励黑客 Agent 学会优先完成高权重且简单的子任务，主动跳过困难子任务 在 aggregator 里对"跳过"行为惩罚；定期人工审计 agent 是否在钻空子
子任务粒度设计难 如果子任务划分太粗（每个 25%），部分完成的诊断价值接近 0 参考 LH-Terminal-Bench：子任务粒度要到"是否生成某个特定文件"级别
token 成本失控 46 条任务 × 15 个模型 × 多次 epoch 完整跑下来，$1000-5000 轻松超支 用分层跑法：先跑 8 条核心任务做快速筛选，对表现好的模型才跑完整 46 条
环境不稳定性 CI 服务宕机、网络抖动，导致"Agent 正确但 CI 失败"的假阴性 每个任务跑 3 次取 median；超时任务标记为 INVALID 而非 FAIL
评测与训练分布污染 如果评测任务被加入训练数据，pass rate 会虚高 定期更新评测任务池（LH-Terminal-Bench 声称 living benchmark，但如果只有 46 条存疑）
终端环境配置差异 Terminal-Bench harness 假设特定 shell 环境，移植到公司内部环境需要大量适配 把 harness Docker 化，每个任务的 env 用 docker image snapshot 锁定
统计显著性不足 46 条任务做 15 模型排序，单类任务可能只有 4-5 条，置信区间宽 报告 bootstrap 95% CI；在结论中加"在 X 类任务上，Y 模型显著优于 Z"的表述

3.6 评测结果的可比性风险

风险 影响 缓解方式
不同 API 版本模型能力不同 GPT-4-turbo-2024-04 与 GPT-4o 同名不同能力 记录 model name + version + timestamp
API 服务商 rate limit 影响评测时长 高并发被限流，导致评测无法完成 测 QPS 上限，评测时留 20% 余量
prompt 差异主导结果 不同模型的最优 system prompt 不同，统一 prompt 对某些模型不公平 分别对每个模型做 3-shot prompt tuning 后再测
评测环境版本差异 不同时期跑 harness 版本不同，结果不可比 harness 用 git SHA 锁定，每次跑记录版本

四、实用决策树

你的场景适合用 LH-Terminal-Bench 吗？

├── 你在做 Agent 选型（Claude/GPT/开源）？
│   └── 是 → 用精简版（8 条代表性任务）做快速筛选，再跑完整评测
│
├── 你在做 RL reward 设计研究？
│   └── 是 → 直接用 dense-subtask aggregator 作为 reward signal，优先于 binary terminal reward
│
├── 你是企业内部 Agent 平台负责人？
│   └── 是 → 把自家业务流翻译成同样 schema，定期跑诊断
│
└── 你是学术研究者（算力有限）？
    └── 建议只跑 8 条核心任务；全文分析优先于实测

五、总结与行动建议

角色 建议
Agent 框架作者 用 dense-subtask aggregator 替换 binary pass/fail，这是本论文最有工程价值的方法论输出
MLOps / Infra 把 9.9M tokens / 85min / 任务作为预算上限基准；规划评测节奏时留足 API 成本
RL / 训练团队 子任务级别的 reward 是远比 terminal reward 强的训练信号——但要防止 aggregator 黑客（加跳过惩罚）
企业内部 Agent 平台 自建评测时，用 DAG-aware weighted aggregator 而非简单平均；子任务粒度要到"特定文件存在性"级别
AI 风险研究者 15% pass@1 的天花板 + 4.3% 平均分说明"长程 Agent 在多数工作流上离实用还有距离"——不要被 headline 数字带偏