LongHorizon-Harness：引入MEA循环，长周期Agent成功率升至80.7%！
LongHorizon-Harness: Advancing Long-Horizon Agents for Real-World Tasks
随着大语言模型（LLM）能力的跃升，我们对自主智能体（Agent）的期待早已超越了简单的多轮对话或单步问答。如今的 Agent 被部署在软件工程、科学发现和通用桌面控制等复杂的真实世界场景中，这就要求它们必须具备执行长周期（long-horizon）任务的能力。长周期任务往往需要 Agent 在相互依赖的数十个步骤中，持续进行推理、工具调用、环境观察和自我修正。然而，令人遗憾的是，即使是最前沿的模型，在面对长周期任务时也常常表现出脆弱性，最终在漫长的执行链路中迷失方向或陷入死循环。
ArXiv URL：https://arxiv.org/abs/2608.01964
针对这一困境，最新研究工作提出了一种全新的框架设计 LongHorizon-Harness。该研究敏锐地指出，长周期 Agent 的失败往往并不源于单步推理能力的匮乏，而是现有 Agent 框架在架构设计上的根本性缺陷：它们将任务执行、状态追踪和完成度评估全部耦合在一个不断膨胀的上下文中。为了打破这一瓶颈，LongHorizon-Harness 将长周期执行重构为一个纯粹的“任务状态管理”问题，并引入了“管理-执行-审计”（Manage-Execute-Audit，简称 MEA）循环机制。
实验结果展现了这种架构重构带来的巨大红利。在严格控制底层模型的前提下，引入 LongHorizon-Harness 使得 Qwen 3.7-Plus 在 WeaveBench 基准上的成功率从 51.8% 提升至 80.7%，并在严苛的桌面操作基准 OSWorld 2.0 上实现了任务完成率的显著增长。这项工作向我们揭示了一个重要的工程启示：在模型原生上下文窗口不断拉长的今天，单纯依靠“堆 Context”无法解决长程执行的稳定性问题，机制层面的状态隔离和独立交叉验证才是走向实用化的必由之路。
为什么不断拉长的上下文成为了“死胡同”？
在详细解析 LongHorizon-Harness 的机制之前，我们需要先理解现有系统到底在哪里跌倒。无论底层的模型是 GPT-4 还是 Claude Opus，目前主流的 Agent 支架框架（如 Claude Code、Codex CLI 等）在处理复杂任务时，基本都遵循一种“滚雪球”式的运行模式。系统维持一个不断延长的对话历史，Agent 每做完一个动作、看到一个反馈，就将其追加到这个历史中。
研究作者明确指出了这种模式在长周期任务中不可避免会遭遇的三大结构性危机。
第一是误差累积与目标漂移（Compounding errors and goal drift）。在长达几十步的执行中，如果 Agent 在第五步做出了一个微小的错误判断，这个错误信息会作为上下文的一部分，扭曲第六步的推理。随着轨迹变长，初期的微小偏差会不断放大，最终导致 Agent 完全偏离了用户最初设定的目标。
第二是上下文腐化（Context rot）。虽然现代模型的理论上下文长度已经可以达到百万级别，但理论长度并不等于有效利用率。当交互历史变得极其庞大时，真正与当前决策相关的信息被淹没在海量的中间试错日志中。一旦上下文信息的信噪比越过某个临界点，Agent 提取关键信息的能力就会断崖式下跌。
第三，也是最致命的一点，是任务状态的丢失与错误自我评估的传播。在传统框架中，任务执行和完成状态的评估是高度耦合的。Agent 既当运动员又当裁判：它自己执行了一个命令，然后自己在同一个上下文中判断“这个任务做完了”。如果它产生了幻觉，错误地认为某个尚未实现的功能已经完成，这种“虚假的状态”就会被固化在上下文中，成为后续所有决策的错误前提。
LongHorizon-Harness 核心架构：解耦执行与状态管理
为了彻底解决上述痛点，LongHorizon-Harness 放弃了“维护单一超长执行轨迹”的传统思路，将核心转变为“在外部维护显式的任务状态”。框架的设计哲学非常清晰：当前的状态必须且只能由环境产生的客观事实来更新，而绝不能依赖执行者主观的“自述”。
如上图所示，LongHorizon-Harness 的核心引擎是被称为 MEA 的控制循环，即 Manager（管理者）、Executor（执行者）和 Auditor（审计者）三个核心角色的协同工作。这三个角色不仅在功能上严格分工，在信息隔离和权限控制上也做到了极致。
掌握全局但无权行动的 Manager
在每次循环的开端，Manager 负责阅读当前的全局任务状态 $S_{i}$。这里的任务状态是一个高度结构化的数据集合，包括拆解出来的需求（requirements）、执行过程中产生的文件或工件（artifacts），以及从环境中验证过的事实（facts）。Manager 的职责是对比当前状态和最终目标，从中挑选出一个尚未解决的目标，并为其制定一份详细的子任务契约（Contract）。这份契约必须包含清晰的目标、验收标准以及边界约束。
值得注意的是，Manager 是一个没有“手”的角色。它没有直接操作计算机环境的权限，无法点击屏幕、无法运行终端命令。它的所有决策只能基于已验证的审计报告和明确的状态记录。通过这种方式，框架保证了全局规划不会受到具体执行细节中大量冗余信息的干扰。
每次都“重新做人”的 Executor
接到子任务契约后，任务会被分配给具体的 Executor，这通常根据环境类型分为负责屏幕交互的 GUI 执行者和负责命令行的 CLI 执行者。
Executor 最核心的机制是“全新上下文（fresh-context）”。每次它启动时，都不知道过去几十轮发生了什么，它的记忆里只有当前这份子任务契约以及 Manager 特意附带的少量背景事实。这意味着，哪怕前一轮的执行产生了海量的错误日志，也不会污染这一轮的执行空间。Executor 专注于在受限的预算内，通过自身的规划和工具调用，尝试完成契约上的任务，最终产生一个环境的转换，并提交一份执行报告。但请注意，这份报告仅仅代表 Executor “认为”自己做了什么，框架并不会据此去更新全局任务状态。
只读且冷酷的独立 Auditor
为了打破“既当运动员又当裁判”的僵局，LongHorizon-Harness 引入了 Auditor 这一关键角色。在 Executor 提交工作后，Auditor 登场。它同样处于一个全新的上下文中，没有看过 Executor 具体的中间试错过程，从而避免了被 Executor 的思维链带偏。
Auditor 的权限被严格限制为“只读”。它可以通过观察屏幕、读取文件内容、检查系统进程等方式，去客观比对当前环境状态与子任务契约中的验收标准。它输出的审计报告会明确判定：任务是完成、未完成还是被阻塞，并且会指出是否发生了破坏完整性的违规操作（比如不小心删除了核心文件）。最终，Manager 只根据 Auditor 提交的这份独立且经过环境交叉验证的审计报告，来更新全局任务状态。
通过这样精妙的机制，整个长周期任务被切分成了多个干净的、被独立验证的步进，只有经过审计的事实才能跨越轮次保留下来。
突破性的实验结果：在多形态任务中验证架构优势
这种架构上的解耦是否真的能转化为直观的性能提升？研究团队在三大具有挑战性的前沿长周期基准测试上给出了明确的答案。这些测试涵盖了纯命令行环境、桌面 GUI 流程控制以及混合界面的复杂操作。实验不仅验证了单一模型的提升，还探讨了框架与不同基础模型之间的兼容性。
在聚焦于跨界面长周期代码和工具使用的 WeaveBench 上，原始的 Claude Code 框架配合 Qwen 3.7-Plus 模型，只能达到 51.8% 的完整任务通过率。当底层执行引擎和基础模型保持完全一致，仅仅通过引入 LongHorizon-Harness 作为任务状态管理层，通过率直接跃升至 80.7%。这一惊人的增长幅度证明了，此前大量任务失败并非因为模型缺乏解决局部问题的能力，而是因为框架未能有效地固化中途取得的进展，导致在漫长的执行中功亏一篑。
在旨在评估真实计算机操作的 OSWorld 2.0 基准测试中，挑战更加严苛。这类任务要求 Agent 控制操作系统完成一系列依赖视觉观察的深度任务。在此环境下，Qwen 3.7-Plus 原本的二元任务完成率仅为 2.8%，在 LongHorizon-Harness 的加持下，完成率提升至 8.3%。更值得关注的是其部分得分（partial score）从 21.5% 上升到了 35.2%。这两个数据的对比揭示了一个深刻的现象：新的框架不仅让模型“摸到”了更多任务的需求，更让这种中间进展有了更高的概率成功转化为任务的彻底终结，极大缓解了长周期任务中常见的“烂尾”现象。
这种提升效应并不依赖于某一个特定模型的偏好。当研究团队将基础模型替换为 Claude Opus 4.7 并在 OSWorld 2.0 的一个挑战性子集上进行测试时，二元完成率同样从 20.6% 跃升到了 35.3%。这有力地证明了，强大的底层基础模型与显式的任务状态管理架构是高度互补的。模型决定了单轮执行时的智商上限，而 LongHorizon-Harness 决定了这股智商在长程执行中是否会随着时间流逝而衰减。
成本、效率与框架边界的深度剖析
对于工业界而言，任何精妙的架构如果带来了不可接受的计算开销，其实用价值都会大打折扣。引入了独立的 Manager 和 Auditor，是否意味着 Token 消耗量会成倍爆炸？本文给出了详细的开销拆解分析。
通过分析 Token 的消耗占比，研究者发现，负责运筹帷幄的 Manager 其实非常“轻量”，它在各个基准测试中占用的总 Token 量仅在 2.0% 到 8.1% 之间波动。这说明将全局状态从冗杂的执行日志中提纯出来，本身并不会带来过高的计算负担。新增的主要成本源于 Auditor，它占据了约 20% 到 38% 的 Token 消耗，这是为了获取客观环境真相所必须支付的独立验证代价。
然而，总体 Token 消耗并非总是线性增加。在 WeaveBench 和 OSWorld 2.0 上，由于模型成功走到了更深的任务阶段并经历了更多轮次的重试与验证，总消耗确实有所增加。但在纯命令行的 Terminal-Bench 2.1 上，引入该框架后总 Token 消耗反而下降了 24%，同时成功率却获得了提升。这是因为在传统模式下，模型常常在一个错误的环境状态中陷入死循环，白白消耗大量无意义的上下文；而 MEA 循环能在错误发生后及时通过审计发现，并强制剥离无效的历史包袱，从而在宏观上实现了“少走弯路即是省钱”。
此外，作者对不同任务领域的增量分析也清晰地划定了该框架的能力边界。在需要维护、检查和修改多个关联环境状态的任务（如设计开发、系统管理）中，LongHorizon-Harness 带来的收益最为显著，提升幅度甚至高达 50 到 60 个百分点。但在一些主要考验纯粹算法设计或单步复杂数学推理的任务中，提升幅度相对较小。这就指向了一个非常理性的结论：独立审计可以敏锐地察觉错误并督促重试，但它无法无中生有地赋予模型本身不具备的推理深度。只有当模型的单步能力足以解决局部问题时，该框架才能最大化其长程调度的价值。
结语与工程启示
长期以来，长上下文窗口技术被视为解决长周期 Agent 任务的银弹。然而，LongHorizon-Harness 的研究结果犹如一剂清醒剂。它告诉我们，在极其复杂的真实物理或数字环境交互中，执行动作、环境观察和自我评估交织在一起的超长文本流，不仅是不必要的，甚至是危险的。
将复杂的动态过程凝练为离散的、经过独立交叉验证的状态节点，采用类似人类组织协作中“规划、执行、质检”三权分立的架构，或许才是构建高可靠性自主智能体的真正工程出路。LongHorizon-Harness 为我们提供了一个极具潜力的架构范式，随着未来底层执行器的效率进一步提升和审计工具链的完善，这类解耦设计的框架必将在软件开发自动化和通用计算机操控领域释放出更强大的能量。