LongHorizon-Harness：面向真实世界任务的长时序智能体框架 LongHorizon-Harness: Advancing Long-Horizon Agents for Real-World Tasks
用管理-执行-审计循环把长时序执行重构为任务状态管理问题，跨轮次保持可验证进展
前置知识
智能体框架（Agent Harness）
智能体框架是围绕大语言模型构建的系统层，负责组织提示词、工具调用、上下文管理和多步执行。典型的框架如 Claude Code、Codex CLI、OpenClaw、Hermes Agent 等，它们保留了模型原生的规划与工具使用循环（agent loop），让模型能够在单次会话中反复进行推理、观察、修订。框架决定了模型如何与环境交互、如何积累历史、如何判断任务完成，是长时序任务可靠性的关键因素。本文的核心论点正是：长时序智能体能力不仅取决于模型本身，也取决于组织执行的框架设计。
本文提出的 LongHorizon-Harness 本质上是一种新型框架设计，理解现有框架的结构性局限（执行与状态共享上下文、执行与评估耦合）是读懂本文动机的前提。
长时序任务（Long-Horizon Task）
长时序任务指需要在许多相互依赖的步骤上反复推理、调用工具、观察结果并修订决策的任务，有时甚至跨越多个上下文窗口或多个会话。METR 的研究表明先进智能体的任务完成时序每约七个月翻倍，前沿编码智能体已能在单个项目上持续工作数小时。这类任务的难点不在于单个步骤，而在于在长序列上维持连贯进展，面临错误累积与目标漂移、上下文腐烂、任务状态丢失三大挑战。任务能完成的时长直接决定了可委托给智能体的工作量。
本文的研究对象就是长时序任务，三大挑战正是 LongHorizon-Harness 要解决的核心问题，理解这些挑战才能理解 MEA 循环的设计动机。
任务状态（Task State）
任务状态是本文定义的结构化记录集合，包含三类对象：需求（requirement，源自原始任务的目标或约束）、产物（artifact，执行中创建或修改的输出）、事实（fact，后续轮次所需的环境信息）。每个记录标记为 completed、pending、blocked 或 untrusted 状态，并保留支持其当前状态的审计证据引用。任务状态在执行之外显式维护，是 LongHorizon-Harness 的核心抽象。初始状态 $S_1$ 由原始任务 $T$ 构造，所有需求标记为 pending，之后每轮由管理器根据审计结果更新。
任务状态是本文方法的核心数据结构，管理器的所有决策、审计的所有更新都围绕它展开，理解它才能理解为什么 LongHorizon-Harness 能可靠地保持进展。
上下文腐烂（Context Rot）
上下文腐烂指随着交互历史增长，相关信息越来越难检索和使用，一旦上下文利用率超过某个临界阈值，智能体性能会急剧退化。这是长时序任务的核心挑战之一。其根本原因是：在单条不断增长的会话中，早期的错误判断可能被记录为任务状态的一部分，并作为后续决策的前提；同时随着历史堆积，关键信息被噪声淹没。LongHorizon-Harness 通过每轮在新鲜上下文中执行、丢弃执行器原始轨迹来规避这一问题，只让精简且经审计验证的任务状态跨轮次持久化。
理解上下文腐烂才能理解为什么本文坚持每轮执行器使用新鲜上下文、丢弃原始轨迹，这是 MEA 循环的关键设计原则之一。
研究动机
现有智能体框架（Claude Code、Codex CLI、OpenClaw 等）存在两个结构性局限。第一，任务执行与任务状态管理共享同一条不断增长的上下文：智能体用同一上下文既执行任务又维护任务状态，而不断增长的执行历史使任务状态越来越难以追踪。第二，任务执行与完成评估保持耦合：智能体既执行每个子任务又判断它是否完成，一个错误的判断可能被记录为任务状态的一部分，并作为后续决策的前提。这导致三大挑战：错误累积与目标漂移（早期错误沿轨迹累积并扭曲后续选择）、上下文腐烂（历史增长后相关信息难检索、性能在临界阈值后急剧退化）、任务状态丢失（智能体往往无法恢复、保留和更新需求、已完成动作、产物、环境事实等任务状态）。论文用案例说明：基线在 Wireshark「Decode As」对话框失灵后，对同一交互重试 400 多步，从未把失败外化为状态对象；又直接编辑文档 XML 看似完成实际得分 0.00。长时序任务的难点不在于任何单个步骤，而在于在长序列相互依赖的动作上维持连贯进展。
本文的目标是本文的具体目标是设计一种通用框架，使智能体能够在长时序任务上可靠地保持和积累进展。具体而言，作者希望将长时序执行从单一不断增长的轨迹重构为一个任务状态管理问题：任务状态在执行之外显式维护，只用从环境中独立验证的事实来更新，并根据当前状态和原始目标推导下一个子任务。框架应通过轻量级 AgentAdapter 支持可互换的模型（Claude Opus、GPT、Qwen）和框架后端（Codex CLI、Claude Code、OpenClaw、Hermes Agent），而不修改其原生智能体循环。最终在三个互补的长时序基准 WeaveBench（跨界面协作）、OSWorld 2.0（桌面工作流）和 Terminal-Bench 2.1（命令行任务）上验证：在相同模型后端和评估协议下，框架能否提升任务级性能，并证明长时序智能体能力是模型与框架共同决定的系统属性。
与已有工作不同的是，本文的独特切入角度是把任务状态从执行上下文中彻底外化，并用独立的审计者验证环境状态。与现有框架（已支持规划、任务分解、工具使用、在隔离上下文中执行或审查工作的子智能体）不同，LongHorizon-Harness 的本质区别有三点：第一，任务状态是执行之外的显式记录，执行器的原始交互轨迹每轮后即丢弃，只有精简且经审计验证的状态跨轮次持久；第二，完成判定与执行解耦——读写的审计者独立检查环境，结论必须由直接来自环境的证据支持而非执行器的完成声明，记录只有在干净审计证据支持下才标记为 completed；第三，每一轮的目标（子任务契约）由管理器从当前审计状态和原始目标推导，而非由执行器在自身不断增长的历史中决定下一步。这种把进展作为显式审计状态维护、每轮新鲜上下文执行、只携带独立验证结果的范式，是与已有方法的根本分野。
核心方法
LongHorizon-Harness 的整体思路是：把长时序执行组织成一串独立审计的任务状态转移。直觉上，与其让一条不断增长的会话自行判断进展，不如让一个不接触环境的管理器基于经审计的事实重新规划下一个子任务，让一个新鲜上下文的执行器去执行它，再让一个只读的审计者认证环境中实际发生了什么变化。技术路线是 Manage-Execute-Audit（MEA）循环。给定长时序任务 $T$ 和计算机环境，框架通过动态确定的轮次序列而非单条持续会话执行任务，在执行之外维护显式任务状态，只用从环境独立验证的证据推进它。设第 $i$ 轮初的任务状态为 $S_i$，当前环境为 $e_{i-1}\in E$，累计审计报告为 $V_{i-1}=(v_1,\ldots,v_{i-1})$。管理器构造有界子任务契约 $c_i$，新鲜上下文的执行器完成契约把环境从 $e_{i-1}$ 变为 $e_i$ 并返回执行报告 $o_i$，独立的审计者通过只读工具检查 $e_i$ 产出审计报告 $v_i$，管理器把 $v_i$ 纳入下一状态 $S_{i+1}$ 后决定是否继续。循环在审计状态满足原始任务、无许可子任务可推进剩余需求、需要用户输入或轮次预算耗尽时结束。最大轮次设为 $N_{\max}=25$。
核心创新点在于把长时序执行从单条不断增长的轨迹重构为任务状态管理问题，并为此设计 Manage-Execute-Audit 循环。与已有方法的本质区别有三：（1）管理器拥有持久任务状态但没有任何直接的环境接口——它不能观察应用状态、检查工作区、调用 GUI/CLI 工具或修改环境，决策完全基于任务状态和审计者记录的环境证据；（2）执行器每轮在新鲜、有预算的上下文中运行，只接收当前轮次所需信息，不接收早期轮次的原始轨迹，结束后原始轨迹和内部推理被丢弃，只有执行报告 $o_i$ 被转发；（3）审计者在排除执行器原始轨迹和内部推理的新鲜上下文中启动，它可以用 $o_i$ 定位相关文件/窗口/日志，但通过把结果环境与契约中的目标、验收标准和边界约束独立对比来判定完成。执行器的声明不直接改变持久状态：一条记录只有在干净审计证据支持下才标记为 completed，审计中检测到的任何任务相关变更都会被记为完整性违规（integrity violation）。这种分离使 $o_i$ 始终是未验证的执行摘要，而 $v_i$ 才是可能推进持久任务状态的环境锚定证据。
方法步骤详情
MEA 循环每轮分三角色。步骤一（管理器）：读取 $T$、当前任务状态 $S_i$ 与累计审计报告 $V_i$（无环境接口），更新状态并产出控制决策 $(S_{i+1},q_{i+1},c_{i+1})=\Phi_{mgr}(T,S_i,V_i)$，$q_{i+1}\in\{execute,done,blocked,ask\}$；它对 $S_i$ 应用 $v_i$ 中已验证的发现，增改 requirement/artifact/fact 记录，未决的保持 pending/blocked/untrusted，然后对比原始任务选一个可推进的未决目标、检查依赖与前置条件，构造有界契约 $c_{i+1}$（含目标、验收标准、边界约束及相关状态记录与先前审计报告）。步骤二（执行器）：接收 $T$、$S_i$、$c_i$ 与契约引用的先前审计报告，把环境从 $e_{i-1}$ 变为 $e_i$ 返回 $(e_i,o_i)=\Phi_{exec}(T,S_i,c_i;e_{i-1})$；每轮预算 1800 秒，是唯一可有意改环境的角色，GUI 执行器获截图/点击/滚动/输入等屏幕能力，CLI 执行器获 shell/文件编辑/编码/测试能力，经 AgentAdapter 启动 Claude Code、Codex CLI 或 OpenClaw 作有界 episode，后端保留原生循环。步骤三（审计者）：接收 $T$、$S_i$、$c_i$、引用的先前审计报告与 $o_i$（不收原始轨迹），检查 $e_i$ 产出 $v_i=\Phi_{aud}(T,S_i,c_i,o_i;e_i)$，预算 300 秒且只读，不能改/删受保护产物或执行状态变更命令；报告记录完成状态（complete/incomplete/blocked）、完整性状态（clean/suspect/violation）与状态更新。管理器把 $v_i$ 追加到持久审计历史并据此更新 $S_{i+1}$。
技术新颖性
技术新颖性体现在四个层面。第一，范式层面，首次将长时序执行严格重构为任务状态管理问题：任务状态在执行之外显式维护，只用独立验证的事实更新，每个子任务在当前记录与原始目标下推导。第二，架构层面，提出 MEA 循环把三种职责彻底分离到三个独立上下文的角色——管理器无环境接口、执行器在新鲜上下文且有界、审计者只读，三者职责互斥且都可通过 AgentAdapter 用不同后端实例化。第三，机制层面，引入完整性监控与 untrusted/blocked 等中间状态：审计者只能观察不能变更任务相关状态，任何检测到的变更被记为完整性违规，使执行器的完成声明 $o_i$ 与环境锚定的 $v_i$ 严格区分。第四，验证层面，通过匹配模型后端与评估协议的对照实验（如 Qwen 3.7-Plus + Claude Code 基线 vs 同模型同后端的 LongHorizon-Harness）隔离出框架层的贡献，并在跨模型（Qwen 3.7-Plus、Claude Opus 4.7、GPT-5.6 Luna）、跨后端（Claude Code、Codex）、跨界面（GUI、CLI、混合）的设置下证明增益的一致性。这把智能体能力重新定义为模型-框架系统的属性，而非单一模型的属性。
实验结果
核心发现四点。第一，匹配模型后端下显著提升：WeaveBench 上 Qwen 3.7-Plus + Claude Code 基线 PassRate 51.8%、Overall 0.702，LongHorizon-Harness 提到 80.7% 与 0.835，几乎翻倍 Claude Opus 4.7 + Claude Code 官方最强的 41.2%，八域全改善（Design +60.0、Spatial/3D +50.0 点最大）；OSWorld 2.0 binary 2.8%→8.3%（3 倍）、partial 21.5%→35.2%；Terminal-Bench 2.1 69.7%→77.2%，Codex + GPT-5.6 Luna 进一步达 83.1%。第二，与骨干互补：OSWorld 34 任务子集上 Claude Opus 4.7 从 20.6%→35.3%（binary）、55.8%→66.9%（partial），证明非仅补偿弱模型——模型决定每轮动作质量，框架决定已验证结果如何可靠维护与跨轮积累。第三，开销可控：管理器仅占 WeaveBench/OSWorld/Terminal-Bench 总 token 的 2.8%、2.0%、8.1%，审计者占 19.4%、24.8%、38.1%，总 token 在 WeaveBench 为基线 2.3 倍、OSWorld 输出 token 3.6 倍，但 Terminal-Bench 反少 24%。第四，效果取决于任务瓶颈：系统管理、游戏、流式交互、人在回路、教程跟随等需在长轨迹保持/检查/修订多个依赖状态的任务改善最大；视觉感知、数学推理、编码、算法设计等单步能力主导的任务改善小甚至回退——独立审计能检测错误并启动恢复，但无法提供模型不具备的能力。匹配案例得分 0.59→0.92、0.00→0.89、0.45→0.87、0.53→0.85。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| WeaveBench（114 个跨 GUI-CLI 协作任务） | PassRate（全任务通过率%） | 80.7%（Qwen 3.7-Plus + LongHorizon-Harness/Claude Code） | 51.8%（Qwen 3.7-Plus + Claude Code）；官方最强 41.2%（Claude Opus 4.7 + Claude Code） | 匹配对照 +28.9 点；相对官方最强近乎翻倍 |
| WeaveBench（全任务平均分） | Overall 平均分 | 0.835 | 0.702（Claude Code 基线） | +0.133 |
| OSWorld 2.0（108 个桌面任务） | Binary 完成率% | 8.3%（Qwen 3.7-Plus，hybrid） | 2.8%（Qwen 3.7-Plus，single action） | 3 倍 |
| OSWorld 2.0（108 个桌面任务） | Partial 平均分 | 35.2% | 21.5% | +13.7 点 |
| OSWorld 2.0 Opus 4.7 子集（34 任务） | Binary 完成率% | 35.3% | 20.6%（single action） | +14.7 点 |
| Terminal-Bench 2.1（命令行任务） | 成功率% | 77.2%（Qwen 3.7-Plus）；83.1%（Codex + GPT-5.6 Luna） | 69.7%（Qwen 3.7-Plus + Claude Code） | +7.5 点 |
局限与改进
作者承认的局限有四。第一，WeaveBench 匹配性受限：官方报告配置使用普通用户账号，而作者运行使用任务虚拟机内 root 权限，因此官方结果只能作为参考点而非严格匹配对照，主结论基于匹配的 Claude Code 比较。第二，Terminal-Bench 因预算有限只自跑了三个配置（Claude Code+Qwen、LongHorizon-Harness+Claude Code+Qwen、LongHorizon-Harness+Codex+GPT-5.6 Luna），其余引自官方榜单。第三，框架在单步能力主导的任务上收益有限：视觉感知、数学推理、编码、算法设计类任务改善小或回退——独立审计能检测错误结果并启动恢复，但无法提供模型不具备的能力。第四，token 成本因配置而异且对弱模型较高：Qwen 在 WeaveBench Games 子集单任务平均从 10.7M 涨到 34.3M，单任务最高达 97.2M。此外 OSWorld 全基准 absolute 性能仍偏低（binary 8.3%）。我自己的观察：审计者与管理器/执行器用同一骨干模型，相关失效可能导致「独立」审计的独立性打折；$N_{\max}=25$ 与每轮预算对超长任务可能不足；MEA 串行轮次带来延迟，难以满足严格实时场景。
独立分析的弱点
第一个弱点是审计者的独立性依赖骨干模型。当前管理器、执行器、审计者用同一模型，若模型在某类判断上系统性出错，审计者可能犯相同错误，「独立」审计实际存在相关失效；改进方向是审计者用更强或异构模型，或引入基于规则/程序化验证器（如直接解析文档 XML、运行测试套件）作为补充。第二个弱点是成本对弱模型不可控。Qwen 在 Games 子集单任务最高 97.2M token，瓶颈在于弱模型需更多审计-重规划轮次；改进方向是学习何时跳过审计、何时合并轮次，或让管理器学习一个轻量调度策略降低审计频率。第三个弱点是固定 $N_{\max}=25$ 与固定预算（执行器 1800s、管理/审计 300s）缺乏自适应性。短任务浪费预算、超长任务被截断；改进方向是引入基于剩余不确定度的动态预算分配。第四个弱点是 OSWorld 全基准 absolute 性能仍低（binary 8.3%），说明对真实复杂桌面工作流，单步能力（视觉感知、精细 GUI 操作）仍是瓶颈，框架无法替代模型能力提升。第五个弱点是 MEA 串行轮次带来高延迟，难以满足严格实时交互；改进方向是并行子任务、流水线化审计。
未来方向
作者隐含的方向包括：扩展到更多骨干与后端（已涵盖 Claude Opus、GPT、Qwen 与 Codex CLI、Claude Code、OpenClaw、Hermes Agent）、研究模型-框架如何联合决定系统能力、把框架应用于更广的真实工作流。基于成果可延伸的方向有：一是让管理器学习——把状态更新与下一子任务选择从规则式提升为学习策略（如用强化学习在审计反馈上训练管理器）；二是引入异构/程序化审计者，结合形式化验证器降低对同骨干模型的依赖；三是层次化任务状态，支持多层 Manage-Execute-Audit 嵌套以处理超长任务；四是在线学习「是否审计」与「审计深度」，把审计成本从固定开销变为基于风险的投入；五是把框架扩展到软件工程、科学发现等真实长期工作流并度量端到端的人类生产力提升；六是研究跨会话的持久任务状态，把单任务 MEA 推广到多日/多周的项目级智能体。
复现评估
复现性中等偏好。论文提供代码仓库（https://github.com/AMAP-ML/LongHorizon-Harness）与项目网站（https://lh-harness.pages.dev），使用标准公开基准 WeaveBench、OSWorld 2.0（osworld-v2-2026.06.24 官方 Docker VM 基础设施）、Terminal-Bench 2.1（Harbor + Docker 后端），并遵循各自官方评估协议（如 Terminal-Bench 每任务三次独立运行取均值）。实现细节给出了关键超参：执行器每轮预算 1800 秒、管理器与审计器各 300 秒、最大 MEA 轮次 $N_{\max}=25$、管理器/执行器/审计器默认用同一骨干。AgentAdapter 接口与角色职责描述清晰。但缺失的部分包括：管理器/审计器的具体提示词模板、状态更新与下一子任务选择的具体规则、完整性监控的实现、各基准上确切的轮次统计、token 成本明细的计算口径（WeaveBench/Terminal 报总 token，OSWorld 仅报输出 token），以及总体算力消耗未披露。完整复现需要可观的算力（大量智能体 episode）与工程实现，但核心 MEA 范式可在中等规模上原型验证。
论文图表
