一句话总结

阿里巴巴集团DreamX团队的研究人员提出了LongHorizon-Harness，它将长时域agent执行视为显式任务状态管理，使用管理-执行-审计循环，含全新上下文执行器、只读审计器以及可插拔的AgentAdapter，将Qwen 3.7-Plus在WeaveBench上的表现从$51.8\%$51.8%提升至$80.7\%$80.7%，在Terminal-Bench 2.1上从$69.7\%$69.7%提升至$77.2\%$77.2%，在OSWorld 2.0上从$2.8\%$2.8%提升至$8.3\%$8.3%，同时将Claude Opus 4.7在一个OSWorld 2.0子集上的表现从$20.0\%$20.0%提升至$34.3\%$34.3%。

核心贡献

• 将长时域agent执行重新表述为任务状态管理问题，在任务执行之外维护显式状态记录中的进度，并仅使用从环境独立验证的事实进行更新。
• LongHorizon-Harness实现了一个管理-执行-审计循环，其中管理器根据当前状态定义一个子任务，执行器在全新上下文中完成该子任务，只读审计器独立检查环境，然后管理器更新状态以进行下一轮。
• 在WeaveBench、OSWorld 2.0和Terminal-Bench 2.1上，LongHorizon-Harness将Qwen 3.7-Plus的分数分别从51.8%提升至80.7%，从2.8%提升至8.3%，从69.7%提升至77.2%，并将Claude Opus 4.7在OSWorld 2.0子集上从20.0%提升至34.3%。

引言

作者致力于将复杂多步骤工作委托给基于大型语言模型的自主agent，其成功取决于在长时域上保持连贯的进展。先前的agent框架有助于管理规划和工具使用，但存在两个结构性问题：执行历史和任务状态共享一个不断扩展的上下文，导致难以跟踪进展，且子任务执行与完成评估耦合在一起，因此错误判断可能持续存在。他们贡献了LongHorizon-Harness，一个将长时域执行重新定义为任务状态管理问题的框架。它在执行之外维护一个独立的、经过审计的显式任务状态，仅使用从环境验证的事实进行更新，并将工作组织到管理-执行-审计循环中，其中每个子任务在全新上下文中运行，丢弃原始交互历史，仅传递紧凑的、已确认的状态。这种解耦在WeaveBench、OSWorld 2.0和Terminal-Bench 2.1上带来了大幅改进，在某些场景下几乎将之前的最佳结果翻倍。

方法

作者提出了LongHorizon-Harness，这是一个旨在通过一系列动态确定的轮次（而非单个持续增长的会话）来执行计算机环境中的长时域任务的框架。系统在任务执行之外维护一个显式任务状态，并且仅使用从环境独立验证的证据来推进该状态。跨轮次，只有任务状态及其支持的审计报告持续存在，而执行器的原始交互轨迹在每轮后被丢弃。

每轮遵循管理-执行-审计（MEA）循环。令 $S_i$Si​ 表示第 $i$i 轮开始时可用的任务状态，$e_{i-1} \in \mathcal{E}$ei−1​∈E 表示当前环境状态，$V_{i-1} = (v_1, \dots, v_{i-1})$Vi−1​=(v1​,…,vi−1​) 表示累积的审计报告。管理器构建一个有界的子任务合约 $c_i$ci​。一个全新上下文执行器执行该合约，将环境从 $e_{i-1}$ei−1​ 转换为 $e_i$ei​，并返回执行报告 $o_i$oi​。然后一个独立的审计器通过只读工具检查 $e_i$ei​，并生成审计报告 $v_i$vi​。管理器将 $v_i$vi​ 纳入下一个任务状态 $S_{i+1}$Si+1​，然后判断是否需要下一轮。当已审计的状态满足原始任务，或者没有允许的子任务能推进剩余需求，或者需要用户输入，或者轮次预算耗尽时，循环终止。

如下图所示：

管理器拥有持久化的任务状态，并决定任务应如何进行。它可以访问原始任务 $\tau$τ、当前任务状态以及所有累积的审计报告，但没有直接操作计算机环境的接口。其决策完全基于任务状态和审计器记录的环境证据。在第 $i$i 轮之后，管理器更新任务状态并生成下一个控制决策：

$$(S_{i+1}, q_{i+1}, c_{i+1}) = \Phi_{\mathrm{mgr}}(\mathcal{T}, S_i, V_i),$$(Si+1​,qi+1​,ci+1​)=Φmgr​(T,Si​,Vi​),

其中 $V_i = (v_1, \ldots, v_i)$Vi​=(v1​,…,vi​)，$q_{i+1}$qi+1​ 为执行（execute）、完成（done）、阻塞（blocked）和询问（ask）之一。合约 $c_{i+1}$ci+1​ 仅在需要进一步执行时才返回。任务状态是任务相关记录的结构化集合，包括需求、产物和事实。每条记录标记为已完成、待处理、阻塞或不可信，并保留指向支持其当前状态的审计证据的引用。执行器的声明不会直接改变持久状态；只有当有干净的审计证据支持时，记录才会被标记为已完成。

执行器执行管理器选择的合约，并且是唯一允许有意修改环境的角色。在第 $i$i 轮中，它接收原始任务 $\tau$τ、当前任务状态 $S_i$Si​、子任务合约 $c_i$ci​，以及仅合同所引用的先前审计报告。它将环境从 $e_{i-1}$ei−1​ 转换为 $e_i$ei​：

$$(e_i, o_i) = \Phi_{\mathrm{exec}}(\mathcal{T}, S_i, c_i; e_{i-1}),$$(ei​,oi​)=Φexec​(T,Si​,ci​;ei−1​),

其中 $o_i$oi​ 总结了执行的操作、结果状态、生成或修改的产物以及遇到的问题。每次执行器调用都以一次全新的、受预算限制的片段运行，仅包含为当前轮次提供的信息。GUI执行器和CLI执行器通过不同的环境接口操作。GUI执行器处理面向屏幕的功能，而CLI执行器处理shell执行、文件编辑、编码和测试。执行器通过通用agent适配器接口实例化，将现有后端作为有界片段启动。

审计器独立验证执行器产生的环境状态。它接收原始任务 $\tau$τ、任务状态 $S_i$Si​、合约 $c_i$ci​、合同引用的先前审计报告以及执行器报告 $o_i$oi​。它检查结果环境 $e_i$ei​ 并生成：

$$v_i = \Phi_{\mathrm{aud}}(\mathcal{T}, S_i, c_i, o_i; e_i),$$vi​=Φaud​(T,Si​,ci​,oi​;ei​),

其中 $v_i$vi​ 被附加到持久化审计历史中并返回给管理器。审计器从排除执行器原始交互轨迹的全新上下文开始。它通过将结果环境与目标、验收标准和 $c_i$ci​ 中的边界约束进行独立比较来确定完成情况。审计器拥有只读权限，不能修改与任务相关的环境状态。审计报告记录完成状态、完整性状态以及检查支持的任务状态更新。

实验

评估涵盖了WeaveBench、OSWorld 2.0和Terminal-Bench 2.1，比较了LongHorizon-Harness与具有相同Qwen和Claude Opus主干的匹配Claude Code基线。显式任务状态管理和独立审计提高了所有三个环境中的成功率，管理器开销保持在token的10%以下，而对于更强的模型，总成本可能降低。收益在需要持续验证和恢复多个依赖状态的任务上最大，案例研究证实，在执行历史之外持久化审计进展可以使全新上下文执行器将接近失败的轨迹转化为完整结果。

使用Qwen 3.7-Plus并以Claude Code作为执行器，LongHorizon-Harness将WeaveBench上的全任务通过率从51.8%提升至80.7%，平均分数从0.702提升至0.835。这种增益出现在所有八个任务领域中，表明显式任务状态管理带来了广泛的改进，而不仅限于特定类别。在与相同模型和执行器后端的匹配比较中，LongHorizon-Harness将通过率从51.8%提升至80.7%。添加任务状态管理层后，平均任务分数从0.702增加到0.835。性能在所有八个基准领域中都得到提升，证实了收益并不集中在单个应用领域。

使用Qwen 3.7-Plus的LongHorizon-Harness在OSWorld 2.0上将二元完成率提高了两倍（从2.8%提升至8.3%），并将部分分数从21.5%提升至35.2%，表明显式任务状态管理显著改善了长时域计算机使用。官方结果显示，即使是最强的模型Claude Opus 4.8，也仅达到20.6%的二元完成率，凸显了基准的难度。使用Qwen 3.7-Plus的LongHorizon-Harness将二元完成率提高了两倍，从2.8%提升至8.3%。部分分数从21.5%上升至35.2%，表明agent平均而言满足了更大份额的任务需求。最佳官方配置（带有批量动作的Claude Opus 4.8）实现了20.6%的二元完成率，强调了OSWorld 2.0的挑战。批量动作的Claude Opus 4.8优于其单动作版本（20.6% vs 18.5%二元完成率），但两者都远低于全任务完成。

在包含34个任务的OSWorld 2.0子集上，LongHorizon-Harness将Claude Opus 4.7的二元完成率从20.6%提升至35.3%，部分分数从55.8%提升至66.9%。这些改进与使用不同主干模型时取得的改进相似，表明显式任务状态管理提供了超越更强模型动作的互补价值。二元完成率急剧上升，从20.6%升至35.3%，意味着agent更频繁地完全完成工作流。部分分数提高超过11个百分点，确认了更多的任务需求得到满足，并且增益在不同主干模型中是一致的。

在WeaveBench Games子集上，LongHorizon-Harness将Qwen 3.7-Plus几乎为零的分数转化为中等成功，但付出了巨大的token成本。对于更强的Claude Opus 4.7，该框架仅带来小幅分数变化，同时持续减少token消耗。这表明框架的成本-性能权衡在很大程度上取决于执行器模型的能力。对于Qwen 3.7-Plus，LongHorizon-Harness改进了所有五个任务的得分，其中在基线模型得分为零（stockfish_puzzle, mines_visual）或接近零（mines_solve）的任务上增益最大。Qwen的token使用量在该框架下激增，每个任务从0.9M–10.0M增加到13.9M–97.2M，而Claude在每个任务上的token使用量都有所下降。Claude Opus 4.7在mines_solve和stockfish_puzzle上经历了得分下降，但所有任务的token使用量下降了44–85%。在game_ui_bug上，两个模型都从该框架中获益（Claude +0.08，Qwen +0.10），但Claude使用的token减少了29%，而Qwen使用的token增至原来的3.4倍。

在WeaveBench和OSWorld 2.0上的评估表明，LongHorizon-Harness大幅提升了任务完成率和平均分数，在所有八个任务领域以及与不同基础模型搭配时都观察到了改进。在WeaveBench Games子集上，该框架以巨大的token成本大幅提升了较弱模型的分数，而对于较强的模型，则主要减少了token使用量，但分数效果不一，这表明随着模型能力的增长，显式任务状态管理从实现完成转向提升效率。