LHTB 上榜 HF Daily：长程终端 Agent 仍吃力

Long-Horizon Terminal-Bench 这次值得写，不是因为它给出了又一个模型排名，而是因为它把 Agent 评测拉到更接近真实工作流的时间尺度。7 月 13 日，HF Daily Papers 收录 arXiv:2607.08964；论文的 arXiv 提交日期是 7 月 9 日，因此本期新闻锚点应写成 HF Daily 上榜与项目页跟进。

可确认的事实有三层。第一，Hugging Face 页面写明论文 Published on Jul 9，并由 LZX 在 Daily Jul 13 提交。第二，项目页介绍 LHTB 是 46 个任务、9 个类别、18 个模型、每题 90 分钟预算的长程终端评测。第三，arXiv 摘要给出的实验口径是 15 个 frontier models，并报告 9.9M tokens、231 episodes、85.3 分钟等平均运行数字。

不确定部分也要前置。项目页榜单与 arXiv 摘要的模型数量不同，本文分别标注“项目页口径”和“arXiv 摘要口径”。榜单结果来自项目方与论文材料，尚未看到第三方完整复跑。GitHub API 能确认仓库在 7 月 13 日有推送，但不能证明榜单每个数值都在同一天首次出现。

对开发者和企业买方来说，LHTB 的实用价值在于它把“Agent 能否完成短题”改成“Agent 在几十到上百步之后还剩多少有效进展”。这会影响编码代理、运维代理和科研工作流代理的选型：只看短 benchmark 的 pass rate，已经不足以评估长任务成本和失败模式。

三套口径先拆开

这篇稿最容易写错的地方，是把 HF、项目页和 arXiv 摘要混成一个来源。它们证明的事情不同，时间也不同。

来源	可确认内容	关键数字	写作边界
HF Daily Paper	Daily Jul 13 提交，论文 Published on Jul 9	46 upvotes，#1 Paper of the day	新闻锚点是上榜，不是论文首发
项目页	46 任务、9 类别、18 模型、90 分钟预算	Grok 4.5 平均 0.51，solve count 13/46	榜单数字按项目页口径引用
arXiv 摘要	15 模型实验与方法描述	9.9M tokens、231 episodes、85.3 分钟	不与项目页 18 模型榜单合并
GitHub API	仓库创建、推送、星标和许可证	pushed_at 为 2026-07-13T21:02:38Z	只能说明仓库活动，不能单独证明榜单

项目页的说法更像 benchmark 发布页：它强调 46 个可复现终端任务、隐藏 verifier、连续部分分和统一 harness。项目页榜单里，Grok 4.5 平均分约 0.51，在 46 题中解出 13 题；同时，29/46 任务从未被任何模型在严格线通过。它还把 MiniMax M3 写成一个性价比信号：平均约 0.39，每任务成本约 6 美元；GPT-5.4 则列在约 28 美元每任务的口径下。

arXiv 摘要的说法更像论文摘要：它强调既有 terminal benchmarks 多为分钟级短题，并且只看最终结果，容易忽略中间进展。LHTB 的设计是把任务拆成细粒度 graded subtasks，用 dense intermediate rewards 记录 Agent 走到哪里。摘要说实验覆盖 15 个 frontier models，平均每任务消耗 9.9M tokens，约 231 episodes，执行 85.3 分钟。最强模型在 reward threshold 0.95 的 pass@1 为 15.2%，在完美阈值 1.0 的 pass@1 为 10.9%。

这两个口径并不必然矛盾。项目页可能展示更新后的 leaderboard，arXiv 摘要则保留论文提交时的实验摘要。问题在于新闻写作必须让读者知道数字从哪里来。把“18 模型榜单”和“15 模型摘要”合写成一个结果，会让后续复核变得困难。

LHTB 测的不是会不会写命令

LHTB 的目标不是测试模型能否生成一条 shell 命令。它测试的是 Agent 能否在一个有状态容器里持续推进任务：读文件、跑测试、改代码、调参数、观察失败，再决定下一步。短题里经常被掩盖的上下文漂移、重复试错、提前放弃和假完成，会在 90 分钟预算里暴露出来。

项目页把任务覆盖到交互游戏、多模态分析、软件与逆向工程、科研计算、地球和能源系统、性能与安全、研究复现、专业 APEX workflow 等类别。这个范围说明 LHTB 不只是 coding benchmark，也不只是 command-line toy task。它试图覆盖更接近真实工作台的长链路。

隐藏 verifier 是这里的关键设计。Agent 自称完成没有用，必须由任务目录里的验证逻辑检查产物。arXiv 摘要还强调，这些任务会进一步拆成可评分子任务，因此分数能反映中间进展。对长任务来说，这比二元 pass/fail 更有解释力，因为很多模型距离最终成功仍很远，但它们失败的位置并不相同。

项目页的“从未通过任务”数字也说明了难度：29/46 任务没有任何模型通过严格线。这类 benchmark 的价值不在于制造低分，而在于让低分仍然可分析。如果所有模型都只得到 0，榜单没有信息；如果部分分能显示哪些模型会推进环境搭建、哪些模型会卡在调试循环，评测才对工程迭代有用。

榜单信号：强模型也只到半程

项目页口径下，Grok 4.5 位居榜首，平均 reward 约 0.51，solve count 为 13/46。这不是一个接近饱和的成绩。按这个尺度，最强模型在不少任务中仍只能推进一部分，且多数任务没有被稳定解决。

榜单还给出一个对采购更有用的信号：价格和长程表现并非单调关系。MiniMax M3 的项目页平均分约 0.39，每任务成本约 6 美元；GPT-5.4 的每任务成本约 28 美元，项目页得分低于 MiniMax M3。这个结论不应被外推成“便宜模型一定更好”，但它提醒买方不要只按模型品牌或单价排序。

arXiv 摘要的平均运行数字进一步说明成本压力。平均 9.9M tokens、231 episodes、85.3 分钟，意味着每一次完整任务评测都接近真实工作会话。短 benchmark 上的差异可能只体现在几秒或几十次 token 调用；LHTB 这类任务会把缓存、上下文管理、工具选择和错误恢复成本全部放大。

这里还要看 pass@1 阈值。arXiv 摘要说最强模型在 0.95 部分奖励阈值的 pass@1 是 15.2%，在 1.0 完美阈值是 10.9%。这两个数字的距离说明，接近完成和完全完成之间仍有明显落差。真实企业任务往往按最终可用性验收，差一点也可能等于失败。

为什么这比普通榜单更有用

短题评测的主要问题，是失败模式太少。模型答错一道题，通常只能说明它没有找到最终答案。长程终端评测会留下更丰富的轨迹：它是否正确安装依赖，是否读懂失败日志，是否复用前一步发现，是否在预算耗尽前停止无效循环。

这对 Agent 产品很关键。一个编码代理如果只能在简单 bug 上表现好，进入大型迁移、科研复现、数据清洗和安全排查时就会迅速退化。LHTB 这类任务把评测变量从“单次生成质量”推向“持续执行可靠性”。企业真正需要采购的，往往是后者。

对模型团队来说，dense reward 的价值在诊断。二元通过率只能告诉团队某个模型没有解完；部分分可以告诉团队它在哪个子目标上卡住。若评分设计足够稳健，训练和工具链团队可以据此区分规划失败、工具调用失败、上下文遗忘和验证误判。

对开源生态来说，LHTB 的公开任务目录也有意义。GitHub 仓库显示它采用 Apache-2.0 许可证，并给出任务目录与示例配置入口。只要数据版本和隐藏 verifier 能保持清晰边界，社区就有机会复跑、扩展和审计任务。

接下来看什么

第一，看口径是否对齐。项目页写 18 个模型，arXiv 摘要写 15 个模型，公开仓库后续还可能更新榜单。后续版本应明确每张图、每个 leaderboard 和每个 pass@1 数字对应的数据快照。

第二，看复跑是否独立。最有价值的验证不是复述项目页分数，而是用同一任务版本、同一 harness、同一预算复跑至少一组模型，并公开失败轨迹和 verifier 输出。若第三方复跑能重现大体排序，LHTB 的可信度会明显提升。

第三，看 hidden verifier 的防护。长程 benchmark 一旦流行，任务记忆和过拟合风险会上升。项目需要说明测试是否能防止直接读取答案、硬编码 verifier、利用数据泄漏或借助公开轨迹投机。

第四，看部分分是否稳定。Dense reward 可以提升信号密度，也可能引入评分偏好。真正稳健的设计应让部分分对应可解释的工作进展，并且在不同任务类别之间保持可比性。

第五，看成本表如何更新。项目页的 MiniMax M3 与 GPT-5.4 对比很醒目，但成本会受到 API 定价、缓存命中、重试次数和并发策略影响。后续若能给出敏感性分析，这个 benchmark 对企业买方会更有用。

所以，本期更稳妥的结论是：LHTB 借 HF Daily 上榜获得了新的可见度，它提出的长程终端评测方向值得跟踪；项目页榜单显示前沿 Agent 仍远未饱和；但所有核心性能数字都应按来源口径引用，并等待独立复跑。