比原生Claude Code强近一倍？阿里LongHorizon-Harness让长周期Agent任务通过率飙升近30%

在日常使用AI智能体处理复杂任务时，很多人都遇到过类似的问题：让AI完成一个包含多步操作的桌面办公任务，前几步还能正常推进，但随着步骤增加，要么前面的小错误不断累积导致最终结果完全偏离目标，要么AI忘记了已经完成的内容反复做无用功，甚至会自己判定已经完成任务，实际漏了不少关键要求。这类问题正是当前长周期智能体落地的核心阻碍之一，最近阿里DreamX团队推出的LongHorizon-Harness框架，就针对这些痛点给出了系统化的解决方案。

论文标题：LongHorizon-Harness: Advancing Long-Horizon Agents for Real-World Tasks

论文链接：https://arxiv.org/pdf/2608.01964

开源仓库地址：https://github.com/AMAP-ML/LongHorizon-Harness

研究背景

近年来，大语言模型已经从单纯的对话工具进化为智能体的决策核心，被广泛应用在软件工程、通用办公助手、科学发现、电脑操作、多模态交互等多个领域。这些场景下的任务往往需要智能体在多个相互依赖的步骤中持续推理、调用工具、调整方案，属于典型的长周期执行任务。智能体能完成的任务长度，直接决定了人类可以向其委托的工作量上限。

相关行业报告显示，先进智能体的任务完成周期大约每7个月就会翻一倍，最近的模型更是将这个周期缩短到了4个月，前沿的代码智能体已经可以持续数小时处理同一个项目的工作。

但任务周期变长并不代表执行可靠性同步提升，当前长周期智能体仍然面临三个普遍的核心挑战：

• 首先是错误累积与目标漂移，前期动作或决策的误差会沿着执行路径不断积累，扭曲后续的选择，逐渐让智能体偏离最初的任务目标；
• 其次是上下文腐烂，随着交互历史不断变长，相关信息越来越难被检索和使用，一旦上下文利用率超过某个临界阈值，智能体的性能会急剧下降；
• 最后是任务状态丢失，长周期任务需要准确、实时的任务状态支撑，包括待满足的需求、已经完成的动作、生成的产物、从环境中发现的事实等，但现有智能体往往很难在整个执行过程中恢复、保留和更新这些状态。

行业内已经从模型和框架两个层面做了大量优化，前沿模型不断扩大参数规模、拓展上下文窗口，通过大规模高质量训练数据获得更强的编码和智能体能力。同时Claude Code、Codex CLI、OpenClaw等智能体框架也已经成为标准系统层，负责组织提示词、工具调用、上下文管理和多步执行逻辑。

但现有框架仍然存在两个结构性局限：

• 一是任务执行和任务状态管理共享同一个不断增长的上下文，智能体用同一个上下文执行任务和维护状态，不断变长的执行历史让任务状态越来越难被追踪；
• 二是任务执行和完成评估相互耦合，智能体自己执行子任务，同时自己判断是否完成，一旦判断错误就会被记录为任务状态的一部分，作为后续决策的前提，进一步放大误差。

框架设计核心思路

为了解决上述局限，研究团队提出了LongHorizon-Harness框架，将长周期执行重构为一系列独立审计的任务状态转换流程，核心思路是将任务状态作为独立记录保存在执行流程之外，仅用从环境中独立验证过的事实更新状态，每个后续的子任务都基于当前记录和原始目标推导而来。

整个框架的核心是Manage-Execute-Audit（MEA）循环，每次循环包含三个独立的角色：管理者、执行者和审计者。管理者读取当前任务状态，定义下一个子任务的依赖、约束和验收标准；执行者在全新的上下文中仅执行这个子任务；只读的审计者独立检查环境状态，在进入下一轮循环前验证本次执行产生的环境变化。管理者会根据审计结果更新任务状态，再开启下一轮循环，执行者的交互历史会在每轮结束后被丢弃，只有紧凑的、经过验证的任务状态会在整个任务过程中保留。同时框架提供了轻量的AgentAdapter，保留现有系统的原生智能体循环，支持三个角色替换不同的后端，兼容Claude Opus、GPT、通义千问等模型，也支持Codex CLI、Claude Code、OpenClaw等现有框架，不需要修改原有系统的逻辑。

其中管理者是唯一持有持久化任务状态的角色，负责决定任务的推进路径，它没有直接访问计算机环境的接口，所有决策都完全基于任务状态和审计者记录的环境证据。每次循环结束后，管理者会更新任务状态，判断接下来是继续执行、任务完成、任务阻塞还是需要询问用户，只有需要继续执行时才会生成下一个子任务的合约。任务状态是结构化的任务相关记录集合，每条记录都会被标记为完成、待办、阻塞或不可信，同时保留支持其当前状态的审计证据，只有当有明确的审计证据支持时，记录才会被标记为完成，执行者的声明不会直接改变持久化状态。

执行者是唯一被允许主动修改环境的角色，每次调用都会运行在全新的、有预算限制的会话中，仅接收当前轮次需要的信息，不会获取之前轮次的原始交互轨迹。会话结束后，执行者的原始轨迹和内部推理都会被丢弃，只有执行报告会被提交用于审计。框架还划分了GUI和CLI执行者的能力边界，GUI执行者负责应用和界面状态相关的转换，CLI执行者负责工作区、进程、程序状态相关的转换，管理者可以根据子任务的需求选择合适的执行接口。

审计者负责独立验证执行者产生的环境状态，它从全新的上下文启动，不接收执行者的原始交互轨迹和内部推理，可以参考执行报告定位相关的文件、窗口、日志等内容，但最终会通过独立对比环境状态和子任务合约中的目标、验收标准、边界约束来判断完成情况。审计者只有查看环境的权限，不能修改任务相关的环境状态，所有结论都必须有直接从环境获取的证据支撑，不能依赖执行者的完成声明。审计报告会记录子任务的完成状态、环境完整性状态以及支持的任务状态更新内容，提交给管理者用于更新全局任务状态。

多基准测试验证效果

研究团队在三个主流的长周期智能体基准测试上验证了LongHorizon-Harness的效果，分别是覆盖跨界面协同的WeaveBench、覆盖桌面工作流的OSWorld 2.0、覆盖高难度命令行任务的Terminal-Bench 2.1，所有测试都使用相同的模型后端和评估协议，确保对比结果仅反映框架本身的效果。

在WeaveBench测试中，使用通义千问3.7-Plus作为模型后端、Claude Code作为执行后端的情况下，LongHorizon-Harness将任务通过率从51.8%提升到了80.7%，平均任务得分从0.702提升到0.835，在所有8个任务领域的表现都有提升，远高于Claude Opus 4.7搭配Claude Code得到的41.2%的官方最好结果。在OSWorld 2.0测试中，同样使用通义千问3.7-Plus的情况下，框架将完全完成率从2.8%提升到了8.3%，部分完成得分从21.5%提升到了35.2%，说明智能体可以满足更多的任务要求，也更容易完成完整的工作流。在34个任务组成的OSWorld 2.0子集上使用Claude Opus 4.7测试，框架也将完全完成率从20.6%提升到了35.3%，部分得分从55.8%提升到了66.9%，证明性能提升不依赖特定的模型后端。

在完全基于命令行的Terminal-Bench 2.1测试中，LongHorizon-Harness将通义千问3.7-Plus的成功率从69.7%提升到了77.2%，搭配Codex执行后端和GPT-5.6 Luna模型时可以达到83.1%的成功率。由于Terminal-Bench的任务完全不需要视觉感知和GUI-CLI路由，这个结果也说明框架的收益不是来自于计算机操作智能体的特定机制，显式任务状态维护、有限执行上下文、独立审计的设计对通用长周期智能体执行都有帮助。

研究团队也分析了框架的成本性能 trade-off，在OSWorld 2.0测试中，通义千问3.7-Plus的平均输出词元消耗从每个任务28.9K提升到了104K，但也换来了性能的大幅跃升，相当于用可控的成本提升换得了任务完成率的明显上涨。词元消耗的拆分显示，管理者仅消耗了不到10%的总词元，显式任务状态维护带来的计算开销很小，审计模块占比在19%到38%之间，是主要的额外成本来源。总词元消耗随任务类型有明显差异，在Terminal-Bench 2.1上框架甚至比基线少消耗24%的词元，同时还获得了更高的成功率，说明框架不会带来固定的成本倍数，总成本取决于任务本身和底层模型需要的执行、恢复轮次数量。

不同任务类型的收益差异也十分明显，设计、空间/3D、游戏等需要在长轨迹中保存、检查、修改多个依赖环境状态的任务提升幅度最大，而以视觉感知、数学推理、编码、算法设计等单步模型能力为核心瓶颈的任务提升幅度较小，甚至会有轻微下降。这也说明框架的核心价值是提升长周期执行的可靠性，当任务的瓶颈在于单步能力时，框架能提供的帮助相对有限。

实际应用场景案例

研究团队还通过具体案例展示了框架在实际场景中的作用，比如在一个WebRTC层审计任务中，普通框架遇到Wireshark的"Decode As"对话框无响应后，会在同一个会话中反复尝试同一个交互超过400步，最终只得到0.59的得分。而LongHorizon-Harness会将失败的交互和未解决的证据缺口记录在任务状态中，后续的执行者会直接聚焦在缺失的证据收集上，最终得分提升到0.92，不需要从之前的失败轨迹中恢复，直接从最新的审计状态继续推进即可。

在一个文档标题样式标准化的任务中，普通框架直接修改文档XML，得到看起来符合要求的结果就终止执行，但由于没有按照要求使用LibreOffice工作流，最终得分只有0.00。而LongHorizon-Harness会按照规定的GUI流程应用标题样式，审计者会解析文档XML确认所有15个标题的底层样式都符合要求，最终得分达到0.89，避免了将看起来正确但不符合规范的结果计入任务状态。

这些案例都显示，LongHorizon-Harness通过将任务状态独立管理、执行和审计分离的设计，有效解决了现有长周期智能体常见的假完成、错误累积、状态丢失等问题，能够更可靠地将单步的模型能力积累为完整的任务完成结果。

总结

LongHorizon-Harness框架通过MEA循环将任务状态管理和环境交互分离，将执行进度保存为显式的、经过审计的任务状态，每个子任务都在全新的上下文中执行，仅在轮次之间传递经过独立验证的结果。在多个基准测试中的表现证明，框架在混合GUI-CLI工作流、专业桌面任务、纯命令行环境以及不同模型后端上都能带来稳定的性能提升。这也说明长周期智能体的能力不仅仅由底层模型决定，组织、验证、将单步能力转化为端到端任务完成结果的框架设计同样重要，更合理的框架设计可以在不增加模型能力的前提下，大幅提升智能体的任务级表现。