01 · LONGHORIZON-HARNESSarXiv:2608.01964 · 2026-08-03

把已核验进度单独保存，再分轮执行长任务

分派 · 执行 · 核验

任务管理者 Manager 写本轮目标和验收要求；Executor 在新会话执行；Auditor 独立检查环境。三者构成外层运行系统（harness），不更新模型。

51.8 → 80.7%Weave：分数 ≥ 0.8 的任务比例
69.7 → 77.2%Terminal：测试通过率，89 题 × 3 次
2.8 → 8.3%OSWorld：分数 = 1 的任务比例
9.5 / 10作者兴趣度。直接涉及 Claude Code、Codex 这类完整执行系统在长任务中的可靠性。
Ma et al., LongHorizon-Harness。
02 · 问题来源同一上下文同时执行、记进度、给自己判分

失败往往发生在步骤之间，而不是某一步做不会

错误被反复沿用
e₁ → e₂ → e₃

早期错误变成后续前提

Agent 把一次误判写进计划，后面的动作都围绕错误状态继续推进。

关键信息难找
历史不断变长

历史越长，关键状态越难取回

工具输出、截图和试错淹没当前目标；上下文长度增长不等于状态更清楚。

缺少独立核验
执行 ≠ 验收

执行者也负责宣布完成

文件“看起来存在”、界面“看起来正确”，都可能被当作已经满足任务。

论文 §1。作者把问题归结为 compounding errors、context rot 与 task-state loss（任务状态丢失）。
03 · 相邻研究训练 harness、修改 harness、运行 harness 是三件事

LongHorizon-Harness 不改模型，也不改 Claude Code/Codex 的内部循环

路线主要改什么何时发生核心证据
Harness-Zero把专用程序示范的操作蒸馏进模型训练阶段执行成功的示范及模型自己尝试的结果
Agentic Harness Engineering自动修改提示、工具、中间处理逻辑和记忆跨任务演化真实执行记录与逐题成败变化
LongHorizon-Harness外置任务状态，分轮调用现有执行程序单次任务运行时环境中的独立只读审计
普通 Claude Code / Codex在一个会话中规划、执行、压缩上下文单次任务运行时自身工具结果与自我判断
边界来自本论文 §1–2；相邻论文为 blog 中的 Harness-Zero 与 AHE。
04 · 官方仓库图同模型配对结果与参考榜单混合展示

先看提升，再确认哪些比较条件相同

LongHorizon-Harness 官方仓库性能总览图
官方仓库 assets/harness_perf.png，MIT License。WeaveBench 的 51.8→80.7 和 Terminal-Bench 的 69.7→77.2 是同 Qwen 3.7-Plus、同 Claude Code backend 的直接对比；OSWorld 主表把 single-action baseline 与 hybrid GUI+CLI 放在一起。
官方仓库 revision a1dd930；论文 Tables 1–4。
05 · 官方仓库图论文设计：Manager 不访问环境，Executor 可写，Auditor 只读

一轮只允许一个主要状态变化

LongHorizon-Harness Manage Execute Audit 架构图
官方仓库 assets/mea_main.png，MIT License。图中的 report 是跨轮证据；当前源码还增加了 contract audit，最终完成需要 complete、clean、aligned 同时成立。
论文 Figure 2；官方仓库 README 与源码。
06 · 跨轮保留什么保留核验过的任务进度，不保留完整聊天记录

Manager 维护当前进度，以及每轮的验收要求

任务进度 Task state Sᵢ
  • Requirement：原任务中的目标或限制。
  • Artifact：执行中创建或修改的输出。
  • Fact：后续轮次需要依赖的环境事实。
  • 每条事实引用 round_003 一类审计轮次。
已完成待完成受阻尚不可信
目标

这一轮要改变的一个主要环境状态。

验收

哪些可观察条件同时成立才算完成。

边界

不能碰哪些对象，允许用什么流程。

依赖

已满足与未满足的前置条件，以及执行方式的选择理由。

证据

只附上本轮验收要求（contract）明确引用的核验报告。

保存位置

结果必须写入用户或下游真正使用的位置。

论文 §2.2；源码 prompt_texts.py:8–18、70–103。
07 · 一轮执行默认最多 25 轮；Executor 1800 秒，Manager/Auditor 各 300 秒

Executor 的“我做完了”只能触发审计，不能直接改 task state

1 · 读取

读取进度

Manager 看到原任务、当前进度和历史核验报告。论文设计不让它访问环境。

2 · 分派

选一件事

写目标、验收条件、不能改的对象和相关证据引用。

3 · 执行

新会话

Claude Code 或 Codex 只收到本轮信息，并可修改环境。

4 · 报告

自述结果

输出做了什么、产物在哪里、遇到什么问题。此时仍未验证。

5 · 核验

只读重查

从环境核验文件、应用状态、日志、截图与已保存结果。

6 · 更新

更新进度

Manager 采用核验支持的事实，保留缺项和尚未可信的结论。

7 · 决定

下一轮

继续执行、询问用户、报告受阻，或结束。

论文 Equations 1–3；Figure 20 另展示 Auditor 600 秒／命令 660 秒超时，不能混同默认预算。
08 · 内部核验过程审计，不是 benchmark 最终评分器

Next: done 必须跨过三个独立条件

当前源码解析前三行

Status: complete | incomplete | blockedIntegrity: clean | suspect | violationContract audit: aligned | unknown | needs_revision | invalid

分别判断是否完成、核验是否违规、验收要求是否忠于原任务。正文再列证据、缺项、阻断条件和进度更新建议。

源码明确拒绝哪些结束请求

  • Claude Code 适配器比较工作区前后快照；发现写入就标为违规。
  • 仍有阻断项时，complete 会被改成 incomplete。
  • Manager 请求结束，最近报告必须同时是 complete、clean、aligned。
complete：已完成
clean：未发现核验违规
aligned：验收要求与原任务一致
缺一项 → 拒绝结束，送回缺项
源码 auditor_agent.py:276–314；manager.py:525–563、1522–1534。第三行是仓库附加条件，论文 §2.4 没有同样列出。
09 · 代码适配保留原执行程序的内部循环，外层每次启动新会话

上下文不继承旧聊天，任务文件仍保留

Claude Code--print --output-format stream-json，关闭自动记忆和提示历史；按角色禁用部分工具。
Codex CLIcodex exec --json，从标准输入读取本轮提示；可配置模型、思考档位与 MCP 工具连接。
新会话每轮生成唯一提示文件，在同一任务工作区启动新进程，设置独立超时。

设计边界不等于硬沙箱

保留原任务、当前进度、验收要求和明确引用的核验报告；不传完整执行轨迹。
固定源码允许 GUI/CLI Executor 使用重叠工具；Auditor 仍可调用 Bash 和计算机操作工具。
Codex 默认绕过自身沙箱；Claude Code 的角色禁用名单和快照检测也不是进程隔离。
源码 cli_agent.py:47–119；adapters/claude_code.py:45–184；adapters/codex.py:47–104。
10 · 最终评分内部 Auditor 更新进度，外部 judge 结算最终成绩

三套 benchmark 使用三种不同的最终评分路径

WeaveBench

114 题

Opus 4.7 读取任务、产物和完整 chat.jsonl，逐项核对要求，再给 8 个维度打分。

PassRate = 分数 ≥ 0.8 的任务比例；Overall = 114 题平均分。

OSWorld 2.0

108 题

官方 env.evaluate() 给每题得分。Binary 只认分数 = 1；Partial 为 108 题平均分。

对照仅用单动作 GUI，本文结合 GUI 与命令行。

Terminal-Bench 2.1

89 题 × 3 次

Harbor + Docker 保留 CPU、内存和环境限制。267 条记录中，测试全部通过才得 1。

每次最多 5 小时；success rate = 全部 reward 之和 / 267。
WeaveBench：利用评分漏洞则为 0；否则 final_score = min(八维平均分, 产物正确性)
论文 §3.1、Appendix A；WeaveBench official judge prompt。
11 · 真实案例 / WEB_TASK_16检查 WebRTC 同时发送的不同质量视频层

识别出 GUI 卡住还不够，必须把失败转成下一轮可执行状态

任务与最终 judge

WeaveBench 官方任务要求用浏览器图表、JSON 和抓包交叉检查视频层。最终 judge 核对任务、产物和完整轨迹。

0.59 → 0.92论文 Figure 7
对照诊断

已识别 Decode As 对话框无响应。

重复失败

仍重试 400 多步，只解码一条流，缺失证据未补齐。

保存进度

把已核验结果与未解决的界面阻碍分开，下一轮只补缺项。

完成交叉检查

约 46.5 秒的 f 层 fps=0、frameWidth=0×0；帧率图的 38–52 秒区间为 0；再核查 21,018 个包。

论文 §3.4，Figures 7 与 14。分数由 WeaveBench trajectory-aware judge 给出。
12 · 真实案例 / DOC_TASK_2 + DOC_TASK_4LibreOffice Writer / Calc

视觉完成、文件语义、修复前证据是三种不同的验收条件

DOC_task_2：统一标题样式

Baseline 发现 FakeBoldParagraph 后直接编辑 XML，没有按要求在 LibreOffice 中操作，也未证实 PDF 导出，judge 给 0.00。

LongHorizon 通过 GUI 应用 Heading 1，逐页复查；Auditor 随后解析 XML，确认 15 个标题为 Heading_20_1、outline-level=1，得 0.89。

先 GUI 修改，再 XML 核验

DOC_task_4：修复 VLOOKUP

Baseline 已保存部分初始错误截图，但证据未收全就改 XML；重开仍有 Err:510，文件与截图序列不一致，得 0.45。

LongHorizon 把缺失的修复前截图留作待办，收全后才修改，再核验九张前后截图，得 0.87。

先收全修复前证据，再修改
论文 §3.4，Figures 8、9、12。
13 · TERMINAL-BENCH 案例最终测试与内部核验仍是两层

文件存在、可以编译，不等于所有测试通过

SQLite：编译并启用覆盖率

gcov 用于检查代码哪些部分运行过。对照的编译和 PATH 测试通过，但覆盖率测试失败，reward 0。

LongHorizon 在六轮中检查源码、编译位置、覆盖率符号、.gcno 文件和最终保存位置，三项测试全过，reward 1。

mystery binary：独立复刻图像

对照文件存在且能编译，但图像相似度测试失败。LongHorizon 交付独立 C 程序，静态编译，gzip 后小于 2000 字节，不调用原程序。

公开案例中图像一致，移走原程序后 MD5 仍一致；九轮后 reward 1。未展示多类输入，不据此宣称普遍等价。

论文 Appendix C.2，Figures 19–20。Terminal-Bench 任务的最终 reward 由官方 tests 产生。
14 · 主结果蓝色只表示本文配置，不表示所有行都能直接比较

稳定提升出现在条件相同的配对实验；最大数字未必是最干净的因果证据

Weave baseline
51.8
Weave + LH
80.7
Terminal baseline
69.7
Terminal + LH
77.2
OSWorld baseline
21.5
OSWorld + LH
35.2
WeaveBench同 Qwen 3.7-Plus、同 Claude Code 执行后端；权限设置与官方榜单不同，所以 41.2 只能作参考。
Terminal-Bench69.7→77.2 为同模型、同 Claude Code 的主对比，每题三次。
OSWorld2.8→8.3 Binary、21.5→35.2 Partial；同时改变了多角色编排和可用工具：仅图形操作，或图形界面加命令行。
论文 Tables 1–3。OSWorld Opus subset 的表格值是 20.6→35.3。
15 · 成本与适用范围Auditor 是主要新增 token 支出

可靠性来自更多核验，但成本不是固定倍数

按 benchmark 看总成本

WeaveBench2.3×
OSWorld output3.6×
Terminal-Bench-24%

Terminal-Bench 中，分轮和审计减少了无效重试；OSWorld 则付出更多观察与恢复。

谁在花新增 token？

Manager2–8%
Auditor19–38%

效果更偏向需要保留、检查、修订多个环境状态的任务。纯数学、短算法或单步感知瓶颈受益较小，部分细分类别还会回退。

论文 Figures 4–6；§3.3；Table 4。
16 · 结论与边界整套系统有增益，各组件贡献仍未拆清

可复用的是任务状态与明确验收条件

已有证据同模型、同执行程序有总体增益WeaveBench 和 Terminal-Bench 的配对结果支持整套系统有效，尚未控制相同总 token 成本。
缺少消融三个组件没有拆开检验无法判断收益分别来自进度记录、新会话、Auditor，还是更多计算与 GUI/CLI 分派。
最强反例原本满分也会被做坏OSWorld Opus 子集的 021、030 都从 1 降到 0；Weave Desktop 平均分 0.8671→0.8465。
下一步实验检验核验准确性与成本测误放行、跨模型互审、固定总预算和各组件贡献；OSWorld 的工具变化也要单独控制。
论文 · 官方代码
论文结论 1 / 16