Long-Horizon-Terminal-Bench: 基于密集奖励评分的长周期终端任务中智能体极限测试

TL;DR Long-Horizon-Terminal-Bench 用密集子任务评分与长时任务考验 AI 智能体的长程规划与迭代调试能力，最强模型 pass@1 仅 15.2%，揭示现有系统的巨大短板。

问题

问题背景

AI agents 正从一次性简单任务向长期、开放式终端工作流演进，业界迫切需要能准确衡量其在长时程、多步骤交互中规划与执行能力的评估基准。

现有方法局限

现有终端基准（如 Terminal-Bench）主要面向几分钟内完成的短任务，仅采用最终结果匹配的二进制评分，奖励信号稀疏，忽略中间进展和部分正确解，导致：

• 无法捕捉 agent 的逐步推理和调试行为，丢失“接近成功”的关键反馈；
• 缺乏密集中间奖励机制，无法提供细粒度评估信号，阻碍强化学习或迭代改进；
• 任务分解与评分设计粗糙，使评估与真实长周期自动化需求脱节。

为什么这个问题难且重要

长程终端任务要求 agent 在数百个交互轮次中维持长上下文记忆、处理工具调用失败、执行多步规划与迭代调试，对模型推理和资源管理能力提出极高要求。实验显示，最强模型在完美奖励阈值下也仅有 10.9% 的通过率，平均消耗 9.8M tokens、耗时近 90 分钟，远超现有基准一个数量级。这一巨大性能落差表明当前 agent 距离可靠长期自主运行尚有本质差距，凸显引入密集奖励和部分评分的迫切性——只有精细度量“走了多远”，才能有效诊断失败模式、引导模型进化。

行业类比

类似 RLHF 中需设计密集奖励函数替代稀疏环境奖励以训练复杂策略，对长期终端 agent 的评估也必须提供中间步骤的细粒度反馈，正如自动驾驶评测需报告全程事件而非仅终点到达，才能真正驱动系统能力提升。

核心洞察

• **密集奖励揭示二元评估隐藏的能力断层**：传统终端基准仅看最终成功与否，信号稀疏且无法区分部分进展。LHTB 将任务拆解为细粒度子任务并给出累积奖励，实验显示有 11.5% 的试次在二元判定下为失败，但密集评分却达到 50% 以上的部分完成度，且模型间差距扩大 2.8 倍。这说明只看最终结果会严重低估模型在长期工作流中的实际进展，密集奖励是衡量长期自主性的必要条件。
• **长期终端任务的核心瓶颈不是单步能力，而是进度感知与终止判断**：LHTB 分析发现，模型常在中途停滞、重复无意义操作或过早宣称任务完成（假完成），即使在获得较高部分分数后仍会因过早退出而扣分。这指向当前 agent 普遍缺乏对自身进展的元认知和可靠的终止条件设计，工程上需要在长上下文与多轮交互中内置明确的里程碑检查与反思机制，而非仅依赖模型的一次性生成。

方法

任务定义与分解

Long-Horizon-Terminal-Bench (LHTB) 包含 46 个长时程终端任务，横跨 9 个领域：实验复现、软件工程、多模态分析、交互游戏、科学计算等。每个任务继承 Terminal-Bench 风格：提供自然语言目标、初始文件系统状态以及参考解决方案或仿真引擎。但与现有基准的关键不同在于，每个任务被人工拆解为一系列细粒度的子任务，形成有依赖或顺序关系的检查点序列。例如，一个“搭建机器学习实验”任务可能被分解为数据下载、预处理、模型搭建、训练、评估和报告生成等多个步骤。

基于子任务的密集评分

评估核心是子任务驱动的部分得分机制。为每个子任务预设一个中间奖励值和对应的状态验证逻辑（例如检查特定文件是否存在、命令是否成功执行、输出是否包含预期字段）。Agent 在执行过程中，每一步的终端输出和环境变动被记录，评分器按序对每个子任务进行检查：若子任务完成，则累加相应奖励；若失败或跳过，则停止后续评分或按规则给部分分数。最终，所有子任务奖励归一化为 0 到 1 之间的总分，代表任务进展程度。这种设计提供了密集的奖励信号，与传统的二进制通过/失败评判形成鲜明对比，能区分“完成 80% 但最终失败”与“一无所获”两种状态。

数据集构建与难度校准

任务来源包括真实世界软件故障报告、科学计算工作流、游戏环境（NetHack、Minigrid）等。构建流程分三步：

1. 专家验证：由研究人员亲自执行每个任务，确认子任务划分的合理性及参考解决方案的可复现性。
2. 规则 Agent 基线：运行简单的基于规则的代理，收集 episode 数、执行时间、子任务完成分布，据此调整子任务粒度，避免过细或过粗。
3. 多模型试运行：使用 GPT-4o 等早期前沿模型进行预评估，通过得分分布判断任务难度是否具有区分度——确保任务不会全部失败或全部成功。

经过校准，平均每个任务约包含 12.3 个子任务，Agent 执行一个任务平均耗费 9.9M tokens、231 episodes 和 85.3 分钟，远超现有终端基准（如 Terminal-Bench 的 20-30 分钟/任务）。

与同类方法的差异

LHTB 不同于 SWE-bench 或 Terminal-Bench 等仅关注最终产出的基准，它通过内置的中间检查点，将长程自主代理的能力评估从“能否成功”延伸到“如何逐步接近成功”，从而暴露模型在规划、错误恢复和停止判断上的细微差别。

实验

实验设计

LHTB 包含 46 个长周期终端任务，覆盖 9 个类别 (游戏、实验复现、软件工程、多模态分析、科学计算等)。每个任务配备参考解法或仿真引擎，并分解为细粒度可评分子任务。评分器提供密集中间奖励与部分分数，能追踪代理进展而不仅是最终成败。实验评估了 15 个前沿模型 (如 Grok 4.5)，统一使用终端代理框架 Terminal-Bench 风格环境。采用 pass@1 指标，并分别在全正确 (1.0) 和部分正确阈值 (0.95) 下统计通过率，同时记录 token 消耗、episode 数、执行时间等效率指标。

关键发现

• 极高资源消耗：平均每个任务需 9.9M tokens、231 episodes、85.3 分钟执行，远超先前基准。
• 低通过率：最强模型在 partial reward 0.95 时 pass@1 仅 15.2%，perfect 1.0 时 10.9%；模型平均通过率分别只有 4.3% 和 1.7%。
• 密集奖励的价值：二元通过/失败评估会隐藏模型间的真实差异；密集奖励能区分“接近完成”与“完全错误”，揭示模型在长周期任务中的真实进展。
• 失败模式诊断：密集奖励暴露了错误终止判断和虚假完成等问题，表明模型在长期规划和迭代调试上的严重不足。

与基线对比的深度解读

相比 Terminal-Bench 2 (TB2) 等先前终端基准 (通常 20-30 分钟、20-30 episodes)，LHTB 的执行时间和 episode 数增加一个数量级，更强调长期规划、长上下文管理和迭代调试，而非一次性解答。二元评分掩盖模型在部分任务上的努力 (例如模型完成了 90% 的子任务却被判失败)，而 LHTB 的 subtask-based grading 给予部分分数，能更细粒度地反映能力差异。实验证明，当前最强模型在长周期自主任务上仍有巨大提升空间，密集奖励为未来模型改进提供了更明确的信号。

行业影响

落地场景

Long-Horizon-Terminal-Bench 验证了长周期终端智能体的能力短板，直接对应三类工业界场景：

• 软件开发与运维：自动修复跨模块 Bug、重构遗留代码、执行复杂的 CI/CD 流程，这类任务常需数小时的多轮交互与验证。
• 科研与数据分析：端到端实验复现、大规模数据处理流水线，涉及多步骤工具调用与中间结果校验。
• 企业自动化：客服工单的跨系统跟踪、金融合规报告的自动生成，要求代理保持长上下文记忆与子目标拆解。

商业价值

该基准带来的商业价值集中在 增效而非直接降本：

• 更精准的模型选型：密集奖励排序能暴露模型在中间步骤的卡点，避免仅凭最终成功率误判，帮助技术决策者选择真正适合长流程任务的模型，减少试错成本。
• 缩短 Agent 产品化周期：通过细粒度失败模式分析（如错误停止判断、中间步骤丢失），团队可针对性优化提示词或工具链，加速 Agent 应用的迭代。
• 提升用户体验：在客服或自动化流程中，能识别代理的“部分完成”状态并给用户渐进式反馈，避免全有或全无的糟糕体验。

与现有产品/工作流的接口

该基准可嵌入现有 MLOps 和 Agent 研发流水线：

• CI/CD 评估层：集成到 LangChain、AutoGPT 等框架的测试套件中，作为长任务性能回归测试，每次更新模型或工具时自动运行。
• 强化学习奖励塑形：密集奖励结构可直接用作 RL 训练环境的 reward shaping，引导代理学习长程规划。
• 可观测性集成：结合现有 Agent 监控平台，输出中间奖励日志，辅助定位生产环境长任务执行异常的步骤。

具体落地 Use Case

1. 电商售后自动化
   某全球电商平台的售后 Agent 需处理“退货-退款-补偿券”长链路，涉及订单查询、物流对接、风控审核、财务打款等多个子系统。使用本基准评估 Agent 能在哪个子任务卡住（如风控审核未通过），从而针对性优化子模块，而非盲目替换整个模型。
2. 药物研发实验复现
   制药公司要求 AI 代理复现文献中的药物筛选实验，包括数据下载、预处理、模型训练、统计分析等多阶段计算。本基准的密集奖励可量化各阶段进展，帮助研发团队判断是环境配置问题还是算法实现缺陷，加速自动化科研流程。

局限

• **任务数量与覆盖度有限**：基准包含 46 项任务，虽跨越 9 个类别，但整体规模仍偏小，可能无法充分代表长程终端任务的全貌。部分类别（如科学计算、多模态分析）样例较少，导致评估结果的泛化性存疑。未来扩展更多样化、更具挑战的任务，并覆盖更多真实工作流，是提升基准代表性的必要方向。
• **密集奖励评分的潜在偏差**：子任务分解与奖励阈值设定依赖于人工设计，可能引入主观性与粒度不均问题。密集奖励虽能捕获部分进展，但未必能准确反映渐进式工作流中的所有有意义行为，且评分函数对某些任务类型的适用性仍需验证。此外，部分奖励阈值（如 0.95）可能掩盖模型间的细微差异，完美奖励（1.0）又过于严苛，导致通过率极低，区分度被压缩。
• **评估成本与模型覆盖的局限**：实验仅测试了当前前沿 LLM（如 Grok 4.5），每任务平均消耗 9.9M 令牌、约 85 分钟，极高的推理成本限制了复现与大规模扩展的可能性。同时，未涉及专为长程推理强化的模型（如带检索增强或计划能力的模型），结论可能仅反映通用模型在零样本设定下的表现，忽略了专门优化后的潜力。未来需纳入更多类型的代理架构，并探索高效评估策略。