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

长任务需要的不是更长记忆，而是可审计的状态推进

MANAGE · EXECUTE · AUDIT

Manager 把原任务拆成有验收条件的 bounded contract。Executor 每轮以 fresh context 做一次状态变化。Auditor 只读检查环境，只有审计通过的事实才能进入下一轮。

51.8 → 80.7WeaveBench PassRate
69.7 → 77.2Terminal-Bench 2.1
2.8 → 8.3OSWorld Binary
9.5 / 10作者兴趣度。和 Claude Code、Codex 这类完整 harness 的长期任务可靠性高度相关。
Ma et al., LongHorizon-Harness。
02 · MOTIVATION一个 context 同时执行、记账、给自己判分

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

COMPOUNDING ERROR
e₁ → e₂ → e₃

早期错误变成后续前提

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

CONTEXT ROT
8k → 80k → 800k

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

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

SELF-ASSESSMENT
do ≈ judge?

执行者也负责宣布完成

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

论文 §1。作者把问题归结为 compounding errors、context rot 与 task-state loss。
03 · RELATED WORK训练 harness、修改 harness、运行 harness 是三件事

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

路线主要改什么何时发生核心证据
Harness-Zero把 teacher harness 的策略蒸馏进模型训练阶段可执行任务的 RL / SFT 信号
Agentic Harness Engineering自动修改 prompt、tool、middleware、memory跨任务演化真实 rollout 与 task flip
LongHorizon-Harness外置 task state，按轮包裹现有 backend单次任务运行时环境中的独立只读审计
普通 Claude Code / Codex在一个会话中规划、执行、压缩上下文单次任务运行时自身工具结果与自我判断
边界来自本论文 §1–2；相邻论文为 blog 中的 Harness-Zero 与 AHE。
04 · OFFICIAL REPOSITORY FIGURE同模型 paired comparison 与参考榜单混合展示

先看提升，再看哪些比较真正 matched

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 · OFFICIAL REPOSITORY FIGUREManager 无环境权限，Executor 可写，Auditor 只读

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

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

Manager 维护两样东西：当前状态和稳定验收契约

CURRENT TASK STATE Sᵢ
  • Requirement：原任务中的目标或限制。
  • Artifact：执行中创建或修改的输出。
  • Fact：后续轮次需要依赖的环境事实。
  • 每条事实引用 round_003 一类审计轮次。
completedpendingblockeduntrusted
GOAL

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

ACCEPTANCE

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

BOUNDARIES

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

DEPENDENCIES

已满足与未满足的前置条件，以及路由理由。

EVIDENCE

只附上 contract 明确引用的 audit reports。

PERSISTENCE

最终状态必须写入用户或下游真正消费的位置。

论文 §2.2；源码 prompt_texts.py:8–18、70–103。
07 · ONE AUDITED TRANSITION默认最多 25 轮；executor 1800 秒，manager/auditor 各 300 秒

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

1 · READ

读取状态

Manager 看到原任务、task state 和历史 audit reports，看不到环境。

2 · CONTRACT

选一件事

写 goal、acceptance、boundary 和相关证据引用。

3 · EXECUTE

fresh context

Claude Code 或 Codex 只收到本轮上下文，并可修改环境。

4 · REPORT

自述结果

输出做了什么、产物在哪里、遇到什么问题。此时仍不可信。

5 · AUDIT

只读重查

从环境核验文件、应用状态、日志、截图与持久化结果。

6 · UPDATE

推进状态

Manager 采用 audit 支持的事实，保留 gaps 和 untrusted 项。

7 · ROUTE

下一轮

execute、ask、blocked 或 done。完成有硬条件。

论文 Equations 1–3；源码 manager.py:491–978。
08 · INTERNAL JUDGE过程审计，不是 benchmark 最终评分器

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

Auditor 的前三行是控制协议

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

随后逐项写 evidence、gaps、blocking constraints 和对 task state 的建议更新。Executor 的 claim 只能帮助定位证据。

源码层的硬 guard

  • 审计期间做 workspace snapshot diff；发生 mutation 会升级为 integrity violation。
  • 存在 blocking constraint 时，complete 会被降为 incomplete。
  • Manager 请求 done 时，最近一份有效报告必须同时是 complete、clean、aligned。
if status == complete
and integrity == clean
and contract_audit == aligned:
  accept done
else:
  inject synthetic repair feedback
源码 auditor_agent.py:276–314；manager.py:525–563、1522–1534。
09 · AGENTADAPTER保留 backend 内部 agent loop，只控制外层 episode

fresh context 来自新的 CLI episode，不是简单清空一段聊天

Claude Code--print --output-format stream-json，关闭 auto memory 与 prompt history；按角色禁用工具。
Codex CLIcodex exec --json，从 stdin 读取本轮 prompt；可注入 model、reasoning effort 与 MCP 配置。
Episode每轮生成唯一 prompt 文件，在同一任务 workspace 启动新进程，并设置独立 timeout。

真正跨轮保留什么？

原始任务、Manager 写下的 task state 与 stable contract。
当前 contract 明确引用的 audit reports。
不保留 Executor 的 raw trajectory 与内部 reasoning。
注意：Codex adapter 默认在隔离环境内 bypass 自身 sandbox；安全边界依赖外部环境和角色配置。
源码 cli_agent.py:47–119；adapters/claude_code.py:45–184；adapters/codex.py:47–104。
10 · EXTERNAL EVALUATION内部 auditor 推进过程，外部 judge 结算最终成绩

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

WeaveBench

114 tasks

Judge 读取 task spec、results artifacts 和完整 chat.jsonl。逐 artifact 拆 clause，再打 8 个维度。

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

OSWorld 2.0

108 tasks

使用官方 env.evaluate()。Binary 只认 final score = 1；Partial 是全部任务细粒度得分均值。

主表 baseline 是 single-action GUI，本文是 hybrid GUI+CLI。

Terminal-Bench 2.1

3 runs / task

Harbor + Docker，保留每题 CPU、memory 和环境限制；每题三次独立 trial 后取均值。

每个 trial 5 小时；论文 Figure 3 还混入官方外部成绩。
WeaveBench final_score = is_hack ? 0 : min(mean(8 dimension scores), deliverable_correctness)
论文 §3.1、Appendix A；WeaveBench official judge prompt。
11 · REAL CASE / WEB_TASK_16WebRTC simulcast-layer audit

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

任务与 judge 看什么

Agent 要在浏览器和 Wireshark 中完成 WebRTC 分析，留下多类证据。最终 WeaveBench judge 同时读任务要求、结果目录和完整轨迹，逐 clause 核验证据。

0.59 → 0.92论文 Figure 7
BASELINE

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

FAIL LOOP

仍围绕同一个按钮重试 400 多步，后续端口与证据没有补齐。

AUDITED STATE

Harness 把“已验证进度”和“GUI blocker”分别写入状态，避免下一轮重做前半段。

RECOVERY

Manager 改派剩余证据子任务，最后补齐 browser charts、JSON state 和 packet evidence。

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

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

DOC_task_2：heading normalization

Baseline 直接编辑 ODT，让标题看起来粗且大，却没有通过指定的 LibreOffice workflow，也没有正确写入底层 style/outline level，judge 给 0.00。

LongHorizon-Harness 用 CLI 检查 ODT 结构，再回到 GUI 完成应用内修改并复核，得分 0.89。

外观像 heading ≠ 底层 style 是 heading

DOC_task_4：修复 VLOOKUP

任务同时要求证明修复前的错误和修复后的正确结果。Baseline 修完再补前态截图，重开文件后错误状态已经不可恢复，证据链自相矛盾，得分 0.45。

Harness 把 pre-repair evidence 设为 pending prerequisite，先保存前态，再修改公式和复核，得分 0.87。

先保存不可逆前态，再执行 repair
论文 §3.4，Figures 8、9、12。
13 · TERMINAL-BENCH CASES最终 verifier 与内部 auditor 仍是两层

CLI 任务里，file exists 往往只满足了最弱的一条条件

SQLite gcov build

任务要求编译带 gcov instrumentation 的 SQLite。验收条件包含可执行文件可运行、覆盖率符号存在、.gcno 文件生成，以及约定路径下的持久化结果。

Baseline 得到 reward 0；Harness 把多条件 build 写进 contract，逐项编译、检查与修复，reward 1。

mystery binary

Agent 需要独立复刻目标二进制行为。字符串、strace 和局部输出只能作为 hypothesis。最终 artifact 还要能编译、在多类输入上行为一致，并满足大小和独立性约束。

Harness 把探索结果保存为 audited facts，直到 C 实现跨过最终 verifier，reward 1。

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

稳定提升出现在 matched pairs；最大数字未必是最干净的因果证据

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 executor；权限设置与官方榜单不同，所以 41.2 只能作参考。
Terminal-Bench69.7→77.2 为同模型、同 Claude Code 的主对比，每题三次。
OSWorld2.8→8.3 Binary、21.5→35.2 Partial；同时改变了 orchestration 与 GUI-only / hybrid tool pool。
论文 Tables 1–3。OSWorld Opus subset 的表格值是 20.6→35.3。
15 · COST AND TASK FITAuditor 是主要新增 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 · TAKEAWAYS强工程设计，因果拆分仍未完成

状态机与 judge 契约，才是这套方法可复用的部分

WHAT IS PROVENmatched harness 对比有明显增益WeaveBench 和 Terminal-Bench 的主 paired results 支持“外置状态 + fresh episode + 独立审计”的整套系统有效。
MISSING ABLATION三个组件没有拆开消融无法判断收益分别来自 task state、fresh context、Auditor，还是更长总预算与 GUI/CLI 路由。
PROTOCOL GAPOSWorld 同时改变 tool poolbaseline 是 single-action GUI，本文是 hybrid GUI+CLI，因此不能把全部提升归于 MEA。
RESEARCH NEXT让 audit 变便宜、可校准应测 auditor false positive、不同模型交叉审计、固定 compute 下的预算分配，以及各组件独立贡献。
论文 · 官方代码
论文结论 1 / 16