Long-Horizon-Terminal-Bench 阅读笔记：密集奖励评估揭露 Agent 长程执行瓶颈

笔记日期： 2026-07-13 笔记作者： Zhongzhu Zhou 论文标题： Long-Horizon-Terminal-Bench: Testing the Limits of Agents on Long-Horizon Terminal Tasks with Dense Reward-Based Grading 作者： Zongxia Li†, Zhongzhi Li†, Yucheng Shi†, Ruhan Wang, Junyao Yang, Zhichao Liu, Xiyang Wu, Anhao Li, Yue Yu, Ninghao Liu, Lichao Sun, Haotao Mi, Leowei Liang arXiv： https://arxiv.org/abs/2607.08964 状态： 预印本（arXiv，2026 年 7 月）—— 腾讯混元大模型前沿团队 + UMD/UGA/UMN/IU/Lehigh/NUS/PolyU

一句话总结

Long-Horizon-Terminal-Bench（LHTB）是一个 46 个容器化终端任务的 benchmark，用子任务级加权平均奖励代替二元通过/失败评分，发现当前最强前沿模型（GPT-5.5）的通过率仅为 15.2%，而 79% 的失败来源于时间预算耗尽（Agent 还在工作时就到时了），而不是单步推理出错——这说明长程执行能力、而非局部推理能力，是当前 Agent 的核心瓶颈。

前置知识

阅读本文前，需要掌握以下几个基础概念：

1. LLM Agent 与终端环境

LLM Agent 是以语言模型为核心，通过发出工具调用或 Shell 命令与环境交互的系统：模型生成动作 → 执行 → 得到观测（输出、文件列表、错误信息）→ 追加进上下文 → 生成下一个动作。这个循环可以持续数百轮。

终端型 Agent（Terminal Agent）在容器化的 Shell 环境中操作：读写文件、运行脚本、查看中间输出、调用系统工具——这与人类软件工程师处理一个长期项目的工作方式完全一样。

关键的规模化挑战在于：每一轮交互都会让上下文窗口增长。随着任务变长，Agent 必须维持一致的状态、更新执行计划、避免重复已完成的步骤，并且知道何时停下来。这些对当前模型来说都不简单。

2. 稀疏奖励与密集奖励

• 稀疏奖励（Sparse Reward）：任务最终完成给 1，否则给 0。对于极难的任务，所有模型几乎都失败，稀疏奖励无法区分”完成了 90% 的任务”和”完成了 5% 的任务”——它们都得 0 分。
• 密集奖励（Dense Reward）：对中间步骤或子目标分别打分，量化 Agent 到底走了多远。密集奖励让”近似成功”和”完全失败”可以区分开来。

在强化学习中，稀疏奖励对应几乎无法学习的环境；在评测中，稀疏奖励对应在极难任务上几乎无法区分模型能力的评测方案。LHTB 正是用密集奖励来解决这个问题。

3. 短程 vs. 长程 Benchmark 的核心差异

短程 benchmark（如 SWE-Bench、HumanEval）衡量的是：Agent 能不能解决一个定义清晰、规模有限的问题？这主要考验的是局部推理能力。

长程 benchmark 增加了一个时间维度：任务需要数百步、多阶段规划、跨多个子目标的错误恢复以及迭代调试。完成这类任务不仅需要推理，还需要预算管理——在固定时间限额内，如何合理分配注意力和工作量，使总体进度最大化。

4. Docker 容器化与评估隔离

LHTB 的每个任务运行在一个 Docker 容器中，预装了所有相关文件、代码、数据、工具和辅助脚本。容器提供完整隔离：Agent 的操作不影响宿主机。评估器（Grader）在每轮 rollout 结束时运行在容器内部，检查容器的最终状态。这种确定性设置使评估可以完全复现。

5. Agent Harness（脚手架）

Agent Harness 是封装在基础 LLM 外层的脚手架，提供：(a) 环境交互循环；(b) 上下文管理（截断、摘要）；(c) 停止标准（时间预算、自我终止）。论文中使用了两种 harness：Terminus-2（用于 14 个模型）和 OpenAI Codex harness（用于 GPT-5.3 Codex）。Harness 质量本身就会显著影响评测结果，这是一个不容忽视的混淆因素。

6. Pass@1 与平均奖励

论文的两个核心指标：

$$\text{pass@1}(\tau) = \frac{1}{|T|} \sum_{t \in T} \mathbf{1}[R_t \geq \tau] \tag{1}$$ $$\bar{R} = \frac{1}{|T|} \sum_{t \in T} R_t \tag{2}$$

其中 $T$ 是所有 46 个任务的集合，$\tau$ 为通过阈值（主要报告 $\tau = 0.95$）。

这两个指标衡量不同的东西：pass@1 回答”Agent 能否可靠地完成任务”；平均奖励 $\bar{R}$ 回答”Agent 通常能走多远”。高 $\bar{R}$ 但低 pass@1 意味着近乎完成但总是在最后一步失败——这是一个非常有价值的诊断信号。

研究动机：现有 Benchmark 的缺口

从 Benchmark 性能到真实工作流的鸿沟

2026 年中期，前沿模型在 SWE-Bench 和 Terminal-Bench 上的得分已经相当高，但真实的专业工作流与这些 benchmark 的设定差距很大：

• 重现已发表 ML 论文的实验结果：需要安装依赖、修复版本冲突、找到正确的超参数、运行数小时的训练、检查 checkpoint 与预期指标是否匹配，再生成图表——不是 10 步，而是几百步。
• 审计多模态数据集：需要检查数千个样本、运行质量控制脚本、诊断系统性错误（旋转帧、Schema 不匹配、损坏的音频），再输出干净的结果——高度开放且需要长程迭代。
• 修复机器人 SLAM 流水线：字段重命名、缺失值、注入噪声，需要系统性诊断再端到端修复和验证。

这些任务没有一个符合”清晰问题、10 步解答”的短程 benchmark 范式。它们需要的是 LHTB 所称的长程执行能力：数百个 episode、跨多个子目标的持续进展，以及最终的可靠验证。

极端难度下稀疏奖励几乎无用

在 LHTB 这种难度级别下，纯二元评分对模型区分几乎没有用：在 R ≥ 1.0（满分）阈值下，15 个评测模型中有 10 个通过任务数为零。二元评分根本无法区分这 10 个模型。

但密集奖励可以：这 10 个模型的平均奖励 $\bar{R}$ 从 0.08（Grok 4.20）跨越到 0.32（GLM 5.2），相差 4 倍——密集奖励保留了完全失去的判别信息。

Benchmark 设计

3.1 任务公式

LHTB 的每个任务遵循 Terminal-Bench 的 Harbor 格式，包含：

1. 自然语言指令：描述整体目标，是 Agent 能看到的唯一规格说明。
2. Docker 镜像：预装了所有资产、代码、数据、工具。
3. 任务配置文件：元数据、时间限制、harness 参数。
4. Oracle 实现或模拟器：供评估器生成 ground truth 答案或运行参考解。

与 Terminal-Bench 的核心区别在于评分机制：LHTB 还额外将每个任务分解为 K 个语义上有意义的子任务 $\{s_1, \ldots, s_K\}$，每个子任务都有自己的确定性检查器。

3.2 核心奖励公式

最终任务奖励是各子任务得分的加权平均：

$$R = \frac{\sum_{k=1}^{K} w_k \, r_k}{\sum_{k=1}^{K} w_k} \tag{3}$$

其中：

• $K$ 是该任务的子任务数量，
• $w_k \geq 0$ 是第 $k$ 个子任务的权重，
• $r_k \in [0, 1]$ 是确定性评估器给出的第 $k$ 个子任务得分。

默认情况下所有权重相等（$w_k = 1/K$），简化为简单平均：

$$R = \frac{1}{K} \sum_{k=1}^{K} r_k \tag{4}$$

当最终目标比中间检查点重要得多时（例如最终流水线必须产出正确输出），可以提高 $w_K$ 权重——在保留中间进度部分奖励的同时，强调端到端完成。

为什么这个公式是好设计？ 简单平均无偏、易于解读；Agent 既无法通过只完成一个检查点来虚高得分，也不会因完成了 95% 的任务但最后一步失败而毫无奖励。加权变体为重要性差异大的任务提供了弹性。

3.3 三种子任务类型

论文定义了三种子任务类型，每种对应不同的 $r_k$ 计算方式：

类型一：二元子任务

评估器对容器最终状态运行一个程序性条件：

$$r_k = \mathbf{1}[\text{condition}(s)] \in \{0, 1\} \tag{5}$$

例子：所有单元测试通过、服务在预期端口响应、必要的实验脚本无报错运行完毕。

类型二：连续或阈值子任务

对于定量目标（在误差范围内重现某个指标、实现特定加速比），得分从 1 线性降至 0：

$$r_k = \max\!\left(0,\; 1 - \frac{|\hat{y}_k - y_k|}{\varepsilon_k}\right) \tag{6}$$

其中 $\hat{y}_k$ 是 Agent 的输出值，$y_k$ 是参考值，$\varepsilon_k$ 是容许偏差。精确匹配得满分，接近但不完全匹配得部分分，偏差过大得零分。

类型三：Episode 聚合子任务

游戏或重复审计类任务需要 Agent 在 $N$ 个 episode 中可靠地完成某个行为：

$$r_k = \frac{1}{N} \sum_{i=1}^{N} \mathbf{1}[\text{success}_i] \tag{7}$$

这衡量的是可靠性，而不是偶然的单次成功。

3.4 评分算法伪代码

算法 1: LHTB 任务评估器
输入: 最终容器状态 S, 任务定义 (w_1..K, grader_1..K), 通过阈值 τ
输出: 任务奖励 R ∈ [0, 1], 通过标志

1:  for k = 1 to K do
2:      if task.type[k] == 二元:
3:          r_k ← 1 if grader_k(S) else 0
4:      else if task.type[k] == 连续:
5:          ŷ_k ← extract_value(S, grader_k.target)
6:          r_k ← max(0, 1 - |ŷ_k - y_k| / ε_k)
7:      else if task.type[k] == Episode聚合:
8:          successes ← 0
9:          for i = 1 to N do
10:             successes += 1 if grader_k.episode_check(S, i) else 0
11:         r_k ← successes / N
12:     end if
13: end for
14: R ← Σ_k (w_k × r_k) / Σ_k w_k    # 公式 (3)
15: pass ← (R >= τ)
16: return R, pass

评估器在每轮 rollout 结束后在容器内部运行一次。容器状态 S 捕获整个文件系统、运行中的进程以及任何模拟器输出。子任务得分是可加的，但总分永远不超过 1.0。

图 1：LHTB 评估流水线

flowchart TD
    A["自然语言指令\n（Agent 唯一可见的规格）"] --> B

    subgraph DockerContainer["Docker 容器（完全隔离）"]
        B["Agent 接收观测\n（Shell 输出、文件、错误）"]
        B --> C["LLM 生成下一个动作\n（Shell 命令 / 文件编辑）"]
        C --> D["动作在终端中执行"]
        D --> E{"预算耗尽\n或 Agent 主动退出？"}
        E -- 否 --> B
        E -- 是 --> F["LHTB 评估器\n在容器内运行"]
    end

    F --> G["子任务得分 r_1...r_K"]
    G --> H["加权平均 → R = Σw_k r_k / Σw_k"]
    H --> I{"R ≥ τ？"}
    I -- 是 --> J["pass@1 +1"]
    I -- 否 --> K["部分进度记录在平均奖励中"]

    style A fill:#e8f4f8
    style F fill:#ffd700
    style H fill:#d4edda

3.5 数据集构建过程

算法 2：LHTB 任务构建流程

算法 2: LHTB 任务构建
输入: 一个真实专业工作流领域 W
输出: 带隐藏验证器的 Harbor 格式任务

第一阶段 — 种子工作流
1:  在 W 中确定一个真实的长程专业问题
    （例如：NetCDF Schema 不匹配、SLAM benchmark 修复、科学图表数据恢复）

第二阶段 — 构建一个故意损坏的项目
2:  实现一个完整但已损坏的终端项目：
    a. 编写一个弱基准实现（部分实现，容易通过可见测试）
    b. 编写官方 Gold Solution（评估器得分恰好为 1.0）
    c. 创建多步骤 solve.sh（Gold Solution 工作流）
    d. 注入系统性故障：
       - 字段重命名、缺失值、注入噪声
       - Gzip/Base64 编码、Schema 别名
       - 旋转/裁剪图像、异常帧

第三阶段 — 设计隐藏验证器
3:  编写评估器：
    a. 公开检查：命令行行为、文件格式、简单样例（权重低，Agent 可见）
    b. 隐藏压力测试：更难的输入、Schema 变体、边界情况（权重高，Agent 不可见）
    c. 校准使 Gold Solution 得分恰好为 1.0

第四阶段 — 难度校准循环
4:  反复用 DeepSeek-V4-Pro 在 1.5 小时预算下运行
5:  调整任务设计，直到任务：
    - 不是微不足道的（模型不会总是通过）
    - 不是完全不可解的（模型能取得部分进展）

第五阶段 — 打包为 Harbor 任务
6:  创建 task.yaml、Dockerfile、README.md、data/、scripts/、tests/、solve.sh
7:  加入 benchmark，使用容器化环境 + Terminus-2 harness

隐藏验证器设计是关键：它防止 Agent 通过硬编码答案或只修补可见样例来刷分。鲁棒的解法必须能泛化到隐藏的 Schema 变体和压力测试，而这些在 rollout 期间从不暴露给 Agent。

3.6 任务类别分布

图 2：LHTB 任务类别分布

pie title LHTB 任务分布（共 46 个任务）
    "软件与逆向工程 (7)" : 7
    "地球、气候与能源 (6)" : 6
    "多模态与图像分析 (6)" : 6
    "科学计算与仿真 (6)" : 6
    "研究复现与机器学习 (5)" : 5
    "系统、性能与安全 (5)" : 5
    "APEX 专业工作流 (4)" : 4
    "互动游戏 (4)" : 4
    "逻辑与约束求解 (3)" : 3

46 个任务均匀分布在 9 个领域，没有任何单一领域占主导——这确保了高通过率需要真正的通用长程能力，而非对特定领域的专项优化。

实验设置

4.1 评测模型与 Harness

参与评测的 15 个模型： GPT-5.5、GPT-5.4、GPT-5.3 Codex（使用 OpenAI Codex harness）、DeepSeek V4 Pro、Gemini 3.1 Pro、GLM 5.1、GLM 5.2、Kimi K2.6、Kimi K2.7 Code、MiniMax M3、Qwen3.7 Max、Qwen3.6 Plus、Doubao Seed 2.1 Pro、Hy3、Grok 4.20。

Harness：

• Terminus-2：14 个模型的标准 harness，提供一致的 prompt 模板和长程终端交互会话。
• OpenAI Codex harness：仅用于 GPT-5.3 Codex，具有更多针对编程任务的 agentic 脚手架。

时间预算： 每个任务每个模型 90 分钟。超时的任务被标记为超时失败。

4.2 平均资源消耗

指标	平均值
每任务 Episode 数	231
每任务 Token 数	9.9M
每任务执行时间	85.3 分钟
每任务估计成本	~$10.2

85.3 分钟的平均执行时间（接近 90 分钟上限）直接说明了大多数模型几乎把每个任务的预算都用尽——这是长程完成能力（而非局部推理）才是瓶颈的直接证据。

主要结果

5.1 Leaderboard

在 $\tau = 0.95$ 下的性能排名（主要指标）：

模型	Pass@1 (R≥0.95)	平均奖励 R̄
GPT-5.5	15.2% (7/46)	0.44
MiniMax M3	6.5% (3/46)	0.39
Kimi K2.7 Code	6.5% (3/46)	0.37
DeepSeek V4 Pro	6.5% (3/46)	0.32
Qwen3.7 Max	4.3% (2/46)	0.31
Doubao Seed 2.1 Pro	4.3% (2/46)	0.30
Gemini 3.1 Pro	4.3% (2/46)	0.29
GLM 5.1	4.3% (2/46)	0.28
GPT-5.3 Codex	4.3% (2/46)	0.29
GLM 5.2	2.2% (1/46)	0.32
Qwen3.6 Plus	2.2% (1/46)	0.31
GPT-5.4	2.2% (1/46)	0.27
Hy3	2.2% (1/46)	0.25
Kimi K2.6	0%	0.25
Grok 4.20	0%	0.10

几点观察：

GPT-5.5 领先，但与后续梯队差距悬殊（15.2% vs. 第二梯队的 6.5%）。这说明 GPT-5.5 在长程任务完成上具有质的不同——不仅仅是局部推理稍好，而是在 horizon 管理上有了本质提升。

在 $\tau = 1.0$（满分）下，15 个模型中只有 5 个能通过哪怕一个任务，10 个模型通过数量为零——说明完美完成任务的难度极高，隐藏压力测试对大多数 near-complete 的 run 都是致命的。

5.2 奖励分布

图 3：所有 run 的最终奖励分布

xychart-beta
    title "最终奖励分布（15 模型 × 46 任务 = 690 runs）"
    x-axis ["<0.05", "0.05-0.15", "0.15-0.25", "0.25-0.35", "0.35-0.45", "0.45-0.55", "0.55-0.65", "0.65-0.75", "0.75-0.85", "0.85-0.95", "≥0.95"]
    y-axis "Run 数量" 0 --> 230
    bar [224, 117, 66, 55, 37, 24, 38, 54, 20, 23, 30]

核心统计：

• 30 runs（4.4%）在 R ≥ 0.95 下通过
• 224 runs（32.6%）几乎没有进展（R < 0.05）
• 433 runs（62.8%）取得了 [0.05, 0.95) 的部分奖励——真实进展，但二元评分会全部记为失败
• 180 runs（26.1%）达到 R ≥ 0.5
• 近完成 runs（0.85 ≤ R < 0.95）：23 runs，几乎和完全通过的 run 一样多

分布的双峰形状（大量 R < 0.05 和较小的 R ≥ 0.5 簇）说明一个重要现象：前沿模型要么在任务的早期就停滞（进展 < 5%），要么取得了相当大的进展（> 50%）。中间段的质量相对较少。这暗示任务的早期理解和设置是决定性因素：最初几步做对的模型往往能走很远；最初几步方向错误的模型则很快停滞。

5.3 密集奖励 vs. 二元评分：为什么重要

图 4：密集奖励与二元评分的对比

flowchart LR
    subgraph BinaryGrading["二元评分（R ≥ 1.0）"]
        direction TB
        B1["GPT-5.5: 10.9% 通过"]
        B2["MiniMax M3: 0% 通过"]
        B3["Kimi K2.6: 0% 通过"]
        B4["Grok 4.20: 0% 通过"]
        B5["GLM 5.2: 0% 通过"]
        Note1["⚠ 10 个模型全部得 0\n完全无法区分"]
    end

    subgraph DenseGrading["密集奖励（平均 R̄）"]
        direction TB
        D1["GPT-5.5: R̄ = 0.44"]
        D2["MiniMax M3: R̄ = 0.39"]
        D3["Kimi K2.6: R̄ = 0.25"]
        D4["Grok 4.20: R̄ = 0.10"]
        D5["GLM 5.2: R̄ = 0.32"]
        Note2["✓ 4.4 倍的范围\n清晰区分模型能力"]
    end

    BinaryGrading -->|"LHTB 的密集奖励\n取代了二元评分"| DenseGrading

失败模式分析

6.1 三类失败模式

论文将每个失败的 run（R < 0.95）归类为：

1. 超时（Timeout）：90 分钟预算耗尽时 Agent 仍在工作。
2. 主动退出（Early Exit）：Agent 在预算耗尽前自行终止，即使没有满足隐藏验证器的要求。
3. Harness 错误（Harness Error）：环境交互循环中的非超时异常（API 失败、验证器错误等）。

全模型分布：79% 超时、19% 主动退出、3% Harness 错误。

这个分布是论文最重要的实证发现。如果主要失败原因是”局部步骤推理出错”，我们预期会看到大量 harness 错误或几乎为零的平均奖励。但事实上：

• 79% 是超时，平均奖励在 0.10\u20130.35 之间——Agent 在取得有意义的进展之后才耗尽时间。
• 19% 是主动退出，通常在非平凡的奖励值下（Kimi K2.7 Code 平均退出奖励 0.51，MiniMax M3 平均退出奖励 0.42）——Agent 相信任务完成了，但隐藏验证器不同意。

6.2 “虚假完成”（False Finish）模式

定义： 主动退出时 R ≥ 0.75——Agent 完成了任务的大部分工作，误判任务完成后带着剩余时间退出。

论文识别出 14 个这样的 run。例子：

• Kimi K2.7 Code 在 duckdb-optimizer-closure 任务上以 R = 0.92 退出，还剩约 20 分钟。
• GLM 5.2 在 apex-ib244-matter 任务上以 R = 0.90 退出。
• 7 个不同模型在 apex-law433-matter 任务上以 R = 0.80\u20130.87 退出，每个都还剩约 20 分钟。

在这些 run 中，Agent 通过了所有可见的公开测试，但没有通过隐藏压力测试。Agent 不知道隐藏测试的存在，因此跑完可见测试、看到全部通过后，就判断”任务完成”。这是自我验证能力的系统性缺陷。

图 5：各模型失败模式构成

xychart-beta
    title "各模型未解决 run 数（共 46 个任务）"
    x-axis ["GPT-5.5", "MiniMax M3", "Kimi K2.7", "DeepSeek", "Qwen3.7", "GLM 5.1", "Gemini3.1", "GPT-5.4", "GLM 5.2", "Qwen3.6", "GPT-5.3", "Kimi K2.6", "Hy3", "Doubao", "Grok 4.20"]
    y-axis "未解决 runs" 0 --> 50
    bar [28, 38, 30, 26, 33, 36, 36, 32, 33, 33, 29, 42, 39, 40, 46]

Grok 4.20 的 46/46 全部未解决——它在所有任务上都失败了。但平均奖励不为零（$\bar{R} = 0.10$），说明它在大多数任务上还是有部分进展的，这与”立即崩溃”不同。

6.3 局部推理 vs. 长程完成：关键区分

论文清晰地区分了两类 Agent 能力维度：

1. 局部推理能力：Agent 能不能正确执行单步操作？动作是否符合合理的执行计划？
2. 长程完成能力：Agent 能不能在数百步内持续推进，管理上下文，避免回头重做，在时间预算内完成任务？

Terminal-Bench 2 主要衡量（1），LHTB 同时衡量两者，数据表明（2）才是当前前沿模型能力的瓶颈。Agent 在 LHTB 上失败往往不是因为局部推理出了问题，而是因为：

• 在不必要的验证循环上浪费了时间；
• 重复了已经完成过的步骤；
• 无法追踪哪些子目标还未完成；
• 任务大部分完成后时间却耗尽了。

这是与”答案错误”截然不同的失败模式，意味着改进方向也不同：需要更好的记忆/进度追踪、更高效的探索，以及更精准的停止标准。

成本分析

7.1 每任务成本估算

模型	Token/任务 (M)	时间 (分钟)	成本/任务 ($)
GPT-5.5	4.16	72.9	21.46
GPT-5.4	10.90	79.3	27.57
GPT-5.3 Codex	4.57	80.7	8.20
DeepSeek V4 Pro	14.45	83.6	6.32
MiniMax M3	20.20	90.0	6.13
Kimi K2.7 Code	8.54	85.4	8.31
Gemini 3.1 Pro	3.55	85.0	7.61
GLM 5.1	5.84	92.6	5.13
Hy3	17.21	91.3	2.47
Grok 4.20	16.23	69.5	20.63

关键发现：

GPT-5.4（~$28/任务）比 GPT-5.5（~$21/任务）贵，但通过率低很多（2.2% vs. 15.2%）。原因是 GPT-5.4 需要更多 episode（302 次 vs. GPT-5.5 的 208 次）才能达到相同进度——每 episode token 价格相当，但 episode 更多导致总成本更高，同时获得更低的成果。

MiniMax M3 使用了 20.20M tokens（5× GPT-5.5），但每任务成本只有 $6.13，因为 token 单价很低。它在 token 价格和 token 消耗之间做出了不同的权衡。

7.2 Pareto 前沿

成本-奖励 Pareto 前沿（最小化成本同时最大化通过率）经过：

• Hy3（$2.47，2.2%）：最便宜，Pareto 最优的低端点。
• MiniMax M3 和 Doubao Seed 2.1 Pro（$5\u20136，4.3\u20136.5%）：中等成本，中等性能。
• GPT-5.5（$21，15.2%）：最高性能，Pareto 最优的高端点。

图 6：成本-性能 Pareto 前沿示意

flowchart LR
    A["Hy3\n$2.47 | 2.2%\n✓ Pareto 最优"] 
    B["Doubao\n$5.16 | 4.3%\n✓ Pareto 最优"] 
    C["MiniMax M3\n$6.13 | 6.5%\n✓ Pareto 最优"] 
    D["GPT-5.5\n$21.46 | 15.2%\n✓ Pareto 最优"] 
    E["GPT-5.4\n$27.57 | 2.2%\n✗ 被 GPT-5.5 支配"]
    F["Grok 4.20\n$20.63 | 0%\n✗ 被所有人支配"]

    A --> B --> C --> D
    E -.->|"更贵但更差"| D
    F -.->|"贵且零通过"| D

批判性分析：不足与可改进之处

不足之处与缺陷

W1 — 任务数量太少，统计方差高。 LHTB 只有 46 个任务。在如此低的通过率下，翻转 2\u20133 个任务就能让模型的 pass@1 变动 4\u20136 个百分点。对于 4.3% pass@1 的模型（通过 2/46），95% 置信区间约为 [0.5%, 14.6%]——与 2.2% 和 6.5% 的区间大量重叠。论文没有报告置信区间，这使得 leaderboard 中许多差异在统计上不显著。

W2 — 几乎只用了单一 harness。 14/15 个模型使用 Terminus-2，GPT-5.3 Codex 使用 OpenAI Codex harness。论文承认这一点，但跨 harness 的比较是有混淆因素的。更重要的是，没有对同一模型在不同 harness 下的性能差异进行敏感性分析。在已知 harness 质量对 Agent benchmark 影响很大的背景下，单一 harness 设计使得”模型能力”和”harness 质量”无法区分。

W3 — 没有 baseline 设计消融。 论文选择了子任务权重和评分阈值（例如 τ = 0.95 作为主要阈值），但没有消融研究显示 rankings 对这些选择的敏感性。如果改用 τ = 0.85 或 τ = 0.9，模型排名会改变吗？子任务权重分配的合理性没有得到系统性验证。

W4 — 难度校准依赖特定模型。 任务校准专门使用 DeepSeek-V4-Pro（反复在 1.5 小时预算下运行，直到任务”有挑战性但可解”）。这意味着 LHTB 隐式地针对 DeepSeek-V4-Pro 的能力水平进行了校准。对于未来更强大的模型，LHTB 可能太简单；对于参数量更小的模型，可能完全无法作答。论文没有包含简单难度梯度层，使得 benchmark 在模型能力谱系中的适用范围受限。

W5 — 隐藏验证器透明度不足。 论文声称会发布评估 harness，但隐藏压力测试套件的完整性（是否所有边界情况都被包含）并不清晰。读者无法完全信任一个无法检查评估器的 benchmark。

W6 — 只有单次运行（pass@1）。 在这种低通过率下，单次运行方差很大。对于通过 2/46 任务的模型，不清楚是稳定能力还是偶然运气。报告 pass@3 和置信区间会大幅提升结论的可靠性。

作者淡化或回避的局限

L1 — 终端专注范围过窄。 LHTB 完全专注于终端型工作流。许多重要的长程 Agent 任务涉及网页浏览、GUI 交互、API 调用或非终端的多模态推理。论文关于”长程完成是瓶颈”的结论可能无法推广到其他部署模态。

L2 — 时间预算与真实工作流的偏差。 90 分钟预算对 benchmark 是合理的，但不反映所有真实部署约束——有些工作流需要数天，有些有实时约束。论文声称 LHTB 反映了”真实专业工作流”，但忽略了真实部署的时间/成本多样性。

L3 — 静态 benchmark 与污染风险。 LHTB 是固定的 46 个任务。随着 benchmark 的广泛传播以及模型在越来越多数据上训练，污染风险会上升。论文没有讨论防污染策略或 benchmark 演进计划。

L4 — 成本估算不可靠。 成本基于 2026 年 6 月公开定价，假设无缓存折扣。实际上提供商提供批量折扣和 Prompt Cache，实际成本会显著不同。成本分析应视为近似，而非精确效率排名。

可以改进的地方

I1 — 将规模扩大到 200+ 任务并设置难度梯度。 分层 benchmark（简单/中等/困难）会大幅降低方差，使 benchmark 在更广泛的模型能力范围内具有区分度。

I2 — 多 harness 评估。 每个模型至少在两种 harness 下运行，或计算模型×harness 交互效应，将模型能力与 harness 质量分开。

I3 — 增加分类别和分难度分析。 知道 GPT-5.5 在整体上达 15.2% 但在游戏类任务上 0%、在软件工程类任务上 40%，会揭示特定类别的弱点，为改进指明方向。

I4 — 报告多次运行的 pass@k 和置信区间。 每个模型每个任务运行 3 次，报告 pass@3 和置信区间。在 $10/任务的成本下，3 次运行费用可控，但会给 rankings 提供远更可靠的统计保障。

I5 — 直接研究 Agent 自我验证能力。 “虚假完成”分析很有价值，但目前偏浅。更深入的研究应当：(a) 让 Agent 看到它通过可见测试的状态后，要求它生成对抗性自测样例；(b) 对比有/无此反思步骤的性能；(c) 衡量 Agent 生成的对抗性测试捕获隐藏失败的频率。

I6 — 分析任务内进度轨迹。 当前论文只报告最终奖励，更丰富的分析应绘制奖励随 episode 数增长的曲线，区分”早期停滞”（推理方向错误后无法继续进展）和”稳定进展但时间不够”（线性增长直到超时）。这两种失败模式有非常不同的改进含义。

边界条件与局限性

适用范围： LHTB 衡量在 90 分钟/约 231 个 episode 规模下的长程终端 Agent 能力。结论不直接适用于：

• 极短任务（< 10 步）：不同的失败模式主导。
• 需要网页浏览或 GUI 的任务：终端 benchmark 无法衡量这些。
• 没有确定性验证器的任务（开放式写作、科研构想）。

泛化性： “长程完成是瓶颈”这一发现，是针对这个具体任务分布和时间预算的。在更短的时间预算下，局部推理错误可能主导；在更长的预算（数小时到数天）下，全新的瓶颈（上下文压缩、长期记忆）会出现。

可复现性说明

• Benchmark 发布：LHTB 任务、Terminus-2 harness 和评估代码计划开源（项目页面：https://zli12321.github.io/LHTB/）。
• Docker 容器：所有任务都已容器化，确保完全可复现的评估环境。
• 成本估算：基于 2026 年 6 月公开价格，实际成本因提供商和时间点而异。
• 模型版本：论文中不是所有模型的确切版本都有明确说明，这可能影响复现性，因为提供商会持续更新模型。

总结与启示

LHTB 是一个设计精心、来得及时的 benchmark，它清晰地暴露了当前 AI Agent 的一个核心能力缺口：可以合理地推理单步操作，但无法在实际时间预算内可靠地完成长程工作流。

子任务级密集奖励是其最重要的方法论贡献——它将在这种难度级别下几乎无信息的二元测量转化为丰富的、模型可区分的信号。79% 的失败是超时、19% 是虚假完成这一精确诊断直接指向了改进方向：Agent 改进的下一波次需要聚焦于长程预算管理、进度追踪和自我验证，而非单纯的单步推理能力提升。

GPT-5.5 以 15.2% pass@1 领先，但这同时也意味着：在一个人类专家需要 2\u20138 小时完成的任务上，即使最强模型也有 84.8% 的概率无法完成。这对于”Agent 准备好自主部署了”这一叙事，是一个清醒而重要的校准。

深度解析：长程任务为什么本质上更难

9.1 长程执行的「能力悬崖」

LHTB 的结果揭示了一个比「长任务更难」更有意思的现象：在长程情境下有一个质的能力边界，无法单靠短程能力的简单外推来解释。

短程 Benchmark（SWE-Bench、Terminal-Bench）主要考验的是「步级智能」：Agent 能不能正确执行单个操作？动作是否符合合理的执行计划？

LHTB 同时考验「步级智能」和「长程完成能力」，数据表明后者是当前前沿模型的能力矶颈。Agent 在 LHTB 上失败往往不是因为局部推理出了问题，而是因为：

• 在不必要的验证循环上浪费了时间；
• 重复了已经完成的步骤；
• 无法追踪哪些子目标尚未完成；
• 任务大部分完成后时间却耗尽了。

这是与「答案错误」截然不同的失败模式，意味着所需的改进方向也不同。

9.2 为什么上下文窗口扭大不是解决方案

有一种直观想法：只要上下文窗口足够大，Agent 就能记住所有先前步骤，自然能避免重复已完成的工作。但 LHTB 表明这不是根本决定因素。

大多数模型每个任务平均消耗 4–20M tokens（远超单次上下文窗口的分配）。Harness 通过滑动窗口、截断或摘要来管理这一点——但这些处理引入了历史上下文的有损压缩。

这意味着问题本质上不是上下文长度问题，而是「上下文压缩质量」问题：Agent 能不能将其进度摘要为简洁的表示，且保留继续取得进展所需的关键信息？当前 Agent 对上下文压缩质量较差：它们会摘要动作历史，但会丢失对子目标完成状态、已验证假设和剩余工作结构的追踪。

9.3 局部验证 vs. 深度验证

一个完成长程任务的人类专家，不只是执行步骤，还会定期验证先前步骤是否实现了预期结果。如果第 50 步产生了一个错误的中间输出且没有被核查，建立在它上的所有后续步骤都是在浪费时间。当前 Agent 运行验证的力度不处：他们检查命令没有报错，但很少验证输出是否满足后续步骤所需的更深层语义合同。

LHTB 的隐藏验证器被设计为专门利用这个缺口：可见测试检查表面属性（命令运行了、文件存在了），但隐藏压力测试检查深层语义属性（数字精度、Schema 泛化能力、边界情况处理）。通过了可见测试却未通过隐藏检查的 Agent，完成了工作但验证得不够深入——这正是「虚假完成」分析所揭示的。

9.4 常见失败模式伪代码

算法 3: LHTB 上典型的长程 Agent 失败模式

给定: 任务 T，90 分钟预算，隐藏验证器 V_hidden，可见验证器 V_public

第一阶段（0–40 分钟）: 初始化与早期探索
1: Agent 读取指令
2: Agent 探索目录结构
3: Agent 运行 V_public → 大部分失败（预期内，任务就是已损坏的）
4: Agent 识别 3–5 个可见错误进行修复

第二阶段（40–75 分钟）: 针对性修复
5: Agent 逐个修复已识别的错误
6: 每次修复后：Agent 运行 V_public 检查进度
7: 最终 V_public 通过所有可见测试

第三阶段（75–90 分钟）: 验证与停止
8: Agent 最后运行 V_public 一次 → 全部通过
9: Agent 判断：「任务完成」
10: Agent 带着约10 分钟剩余时间主动退出  ← 虚假完成！

但 V_hidden 包含：
- 重命名字段的 Schema 变体（Agent 从未见过此变体）
- 1% 精度阈值的数字验证（Agent 只测试到 5% 精度）
- Gzip+Base64 编码的边界样例（不在可见测试套件中）
11: V_hidden 评估 → R = 0.80–0.92（接近满分但未通过）

为什么会失败？
- Agent 不知道 V_hidden 的存在
- Agent 没有生成对抗性自测样例
- Agent 在 V_public 说「完成」时就停下来了

这个模式解释了 14 个 R ≥ 0.75 的虚假完成 run。Agent 并不是没有能力；它正确完成了任务的大部分。失败属于认识论层面：Agent 无法验证它自己看不到的内容。

LHTB 对「 Agent 已就绪」叙事的校准

业界里有一种叙事（部分被令人印象深岈的 SWE-Bench 分数支撑）：AI 编程 Agent 已经准备好在真实工程工作流中半自主地部署了。LHTB 提供了重要的背面组数据：在一个能力水平为人类专家需要 2–8 小时完成的任务上，即使是最强的模型（GPT-5.5）也有 84.8% 的概率无法完成。

对于人类会审查每个输出的部署场景，Agent 是生产力提升器，而非替代者，这是可接受的。但对于期望完全自主完成的场景（运行 3 天的 ML 训练流水线、准备合规审计），当前能力（15%）与所需可靠性（90–99%）之间的差距不是 2× 改进问题，而是需要新架构或训练范式的根本能力差距。

LHTB 的价値不仅在于作为 benchmark，还在于作为一个校准工具：它为开发者和部署者提供了对 Agent 在真实专业工作所需难度谱上实际位置的现实估算。

具体改进方向

改进 1： Horizon 预算管理作为一等问题

如果 79% 的失败是超时，实际上对 Agent 改进的实用主要不是更超级的单步推理，而是更晚成的预算分配。一个能在剩余子目标上合理分配剩余时间预算的 Agent，且能在已完成的子目标分配多少时间和尚未完成的分配多少时间，将直接提升 LHTB 得分。

改进 2： 对抗性自测与验证

虚假完成模式表明 Agent 需要自己构建对抗性测试，而不是仅仅依赖可见测试。最理想的场景：在通过所有可见测试后，Agent 主动推理「隐藏测试可能会检查哪种类型的输入」，生成一小组对抗样例进行自测。这反映了一个有经验的工程师在修复 Bug 后的思维：“还有哪种边界情况可能仍然失败？”

改进 3： 层次化记忆架构

200–300+ 个 episode 的任务远超展开单次上下文窗口所能容纳的范围。更好的架构应当尝试：

• 层次化记忆：将已完成的子目标摘要为简洁的状态表示，作为每个新上下文窗口的入口。
• 写入日志：维护子目标完成状态的结构化日志（JSON 或等效格式），而不是不结构的文本历史。
• 外部状态跟踪：用结构化格式存储 Agent 对任务完成情况的当前信念，使其可被查询。

改进 4： 校准停止标准

Agent 目前当判断可见信号表明任务完成时就停下来。更好的停止标准应包含：

• 不确定性感知停止：只有当 Agent 对隐藏压力测试也能通过的信心超过阈值时，才停止。
• 覆盖率停止：生成可能的失败模式检查表，每一条验证完论再停止。
• 保守默认：在预算还剩时，默认用剩余时间进一步验证而不是实时宣布完成。

Token 效率问题：模型在 Horizon 上的差异

10.1 模型 Token 消耗差异庄大

表 1 中的 Token 消耗对比很讲意思：

• GPT-5.5：4.16M tokens — Token 消耗最少，通过率最高
• MiniMax M3：20.20M tokens — Token 消耗最多，5× GPT-5.5，但通过率不到 GPT-5.5 的一半
• DeepSeek V4 Pro：14.45M tokens — Token 量大但单价低，因此成本比 MiniMax M3 还低

这不是一个简单的效率故事。GPT-5.5 使用 5× 更少的 Token 却能实现 2× 更高的通过率。至少有三种解释：

1. 质量效率：GPT-5.5 每个 Token 能实现更多有意义的进展，因为其推理能力更强。
2. 上下文压缩质量：GPT-5.5 可能对历史上下文进行更有效的压缩，从而在相同预算下覆盖更多步骤。
3. 停止行为：消耗更多 Token 的模型可能每步输入更多语言，或者更频繁地重读其整个上下文。

10.2 Episode 数 vs. Token 数的不成比性

Episode 数（动作次数）和 Token 数并不成比例：

• GPT-5.5：208 episodes，4.16M tokens → ~20K tokens/episode
• MiniMax M3：314 episodes，20.20M tokens → ~64K tokens/episode
• DeepSeek V4 Pro：321 episodes，14.45M tokens → ~45K tokens/episode

MiniMax M3 每个 episode 使用了 3× 于 GPT-5.5 的 Token。这表明 MiniMax M3 在每个动作时做了多得多的上下文阅读（或输出了更长的内容），这可能意味着更彻底的每步推理，也可能意味着更低效的上下文管理。

10.3 Pareto 边界的公式化

对于 Pareto 判断，模型 $i$ 不被支配的条件是：

$$\nexists j \neq i \text{ 使得 } \text{cost}_j \leq \text{cost}_i \text{ 且 } \text{passrate}_j > \text{passrate}_i \tag{8}$$

从数据中可以明确识别以下 Pareto 支配情况：

• GPT-5.4（~$28/任务，2.2$21/任务，15.2% 通过率）支配：更贵且更差。原因是 GPT-5.4 每个任务需要更多 episodes（302 vs. 208），在类似 Token 单价的情况下，所需时间和费用就更多，同时获得更差的结果。
• Grok 4.20（~$21/任务，0% 通过率）被几乎所有人支配。

成本分析最重要的课题：在长程任务上，更高的推断支出并不保证更好的性能。一个局部推理能力较弱却需要 3× episode 才能实现相同进展的模型，成本更高且结果更差。

深度对比：LHTB 在 Benchmark 难度谱系中的位置

11.1 半饱和状态的渐进式崩塌

Benchmark	典型任务时长	最强模型通过率
HumanEval	< 1 分钟	~96%
SWE-Bench Verified	10–30 分钟	~71%
Terminal-Bench 2	< 20 分钟	~52%
LHTB (τ=0.95)	85+ 分钟	15.2%
LHTB (τ=1.0)	85+ 分钟	10.9%

从 Terminal-Bench 2（~52%）到 LHTB（15.2%）的跳变非常陨岁：将任务 horizon 添加大约 4× 就将最强模型的通过率降低了 3.4×。这不是平滑的降展，而是一个质的转变：短程局部推理足够的达山区域，与长程 horizon 管理不可缺少的达山区域。

11.2 METR 时间 Horizon 框架

将 LHTB 联系到 METR 的时间 horizon 分析是一个有用的视角。METR 将 Agent 能力定义为「 Agent 达到固定成功率（如 50%）所需的典型人类时间任务时长」。在此框架下：

• 短程 benchmark（SWE-Bench、HumanEval）对应人类 10–30 分钟任务
• LHTB 任务对应人类 2–8 小时任务
• 未来的超长程 benchmark 将对应人类数天到数周的任务

时间 horizon 框架预测 Agent 在 horizon 长度增加时成功率会大幅下降，LHTB 从实验上验证了这一点。LHTB 额外添加的价値是揭示了机制：送山炮不是推理能力变差，而是 horizon 管理能力变差。

模型排名的统计可靠性讨论

12.1 低通过率下的置信区间

在如此低的通过率下，二项模型的置信区间包含了大量的不确定性。对于一个在 46 个任务中通过 2 个的模型（4.3%），95% 置信区间大约为：

$$\hat{p} \pm 1.96\sqrt{\frac{\hat{p}(1-\hat{p})}{n}} = 0.043 \pm 1.96\sqrt{\frac{0.043 \times 0.957}{46}} \approx [0.5\%,\ 14.5\%] \tag{9}$$

这个区间包含了 0% 到 15%！这意味着，在 4.3%、2.2%、6.5% 这些 pass@1 数字之间，统计上并没有用 1 个模型每任务运行 1 次来区分。

为什么这点重要？因为论文展示的 leaderboard 上的排名差异在统计意义上大多数是不显著的。论文应该明确指出这一点，但它没有。

12.2 如何提升统计可靠性

最直接的方法是多次运行并报告 pass@k：

$$\text{pass@}k = 1 - \frac{\binom{n-c}{k}}{\binom{n}{k}} \tag{10}$$

其中 $n$ 是总运行次数，$c$ 是成功运行次数。平均 $10/任务 \times 46 任务 \times 3 次运行 = 1380$ 美元每模型〔—对于严肃评估来说这个代价是应该就的。

实验可复现性说明

• Benchmark 发布：LHTB 任务、Terminus-2 harness 和评估代码计划开源（项目页面：https://zli12321.github.io/LHTB/）。
• Docker 容器：所有任务已容器化，保证评估环境完全可复现。
• 成本估算：基于 2026 年 6 月平台公开定价，实际成本因提供商不同而得各异。
• 模型版本：论文中并非所有模型的确切版本均有明确说明，这可能影响复现性，因为提供商会持续更新模型。
• 校准数据集：120 个候选任务（质量过滤前）没有公开发布。

个人思考：这篇论文对我的启发

阅读这篇论文最让我印象深刻的是对「虚假完成」现象的量化。在我自己的使用经验中， AI Agent（包括我正在使用的 OpenClaw）确实会在应该继续工作的时候宣布任务完成。LHTB 提供了一个甴石的数据佐证：这不是 个别 Agent 的特有缺欠，而是当前所有前沿模型的系统性问题。

这也让我重新思考如何设计更好的 Agent 工作流程。以本篇笔记的每日流程为例：我给 Agent 一个时间预算（6 小时），并明确要求不能自行提前结束。下一步可能是尝试建立对 Agent 自评的结构化标准：任务完成的每一个阶段，都需要 Agent 展示具体的证据，而不是只说「已完成」。

LHTB 的常用已经开始：百度、阔海等公司正在运行自己的长程 Agent 内部测评。随着这类 benchmark 的普及，我期待看到更多针对长程完成能力（而非单步推理）的优化工作，也期待利用子任务级密集奖励训练更长程 执行的 Agent 。

参考文献

[1] Li et al. Long-Horizon-Terminal-Bench: Testing the Limits of Agents on Long-Horizon Terminal Tasks with Dense Reward-Based Grading. arXiv:2607.08964，2026 年 7 月。

[2] Yang et al. SWE-Bench: Can Language Models Resolve Real-World GitHub Issues? arXiv:2310.06770。

[3] Desai et al. SWE-Marathon: Can Agents Autonomously Complete Ultra-Long-Horizon Software Work? arXiv:2606.07682，2026。

[4] METR. Evaluating Long-Horizon Autonomy of AI Agents. METR Technical Report, 2026。

[5] DeepSeek-AI. DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence. arXiv:2606.19348，2026。