LongHorizon-Harness：别再让智能体自己骗自己了——把长任务拆成"管、干、验"三权分立
那个跑了 400 步还在点同一个按钮的智能体
你让 Claude Code 帮你跑一个长任务，比如"审计这个 WebRTC 通话的 simulcast 分层质量"。它打开 Wireshark，发现一个对话框没响应，点 OK，没反应，再点，还是没反应——然后它就那么点了 400 多步，直到预算烧完。
这不是我编的段子，是这篇论文里实打实的案例（WEB_task_16，基线得分 0.59）。做 Agent 的同学对这种画面应该太熟悉了：任务一长，智能体就开始鬼打墙——在同一个坑里反复横跳，自己宣布"完成了"但其实没完成，或者干脆忘了最初的任务是啥。
说实话，过去一年大家解决这个问题的思路基本都是"等更强的模型"。模型上下文更长了、推理更强了，问题自然就好了，对吧？这篇 LongHorizon-Harness 给了一个不太一样的答案：问题可能不在模型，而在框架——我们让智能体一边干活、一边记账、一边给自己打绩效，这三件事本来就不该由同一个上下文来干。
核心摘要
这篇论文把长时域执行重新定义为任务状态管理问题，提出 LongHorizon-Harness 框架：把单次不断膨胀的会话拆成一轮轮 Manage-Execute-Audit 循环，Manager 持有持久任务状态并派活，Executor 在全新上下文里干活，Auditor 以只读权限独立验收。同一个 Qwen 3.7-Plus 模型，换框架不换模型，WeaveBench 通过率从 51.8% 直接干到 80.7%，OSWorld binary completion 翻了三倍。我的判断：这不是底层算法突破，是一套非常扎实的系统工程整合，但它戳中的痛点是真的——"自我报告进度"确实是当前长任务智能体最脆弱的环节。值得做 Agent 工程的人细读。
论文信息
- 标题：LongHorizon-Harness: Advancing Long-Horizon Agents for Real-World Tasks
- 作者：Ziyu Ma, Hailang Huang, Shun Zou, Yong Wang, Shidong Yang, Yiming Hu, Fei Wei, XiangXiang Chu
- arXiv：2608.01964，2026 年 8 月 3 日提交，29 页
📖 为什么长任务会崩：不是模型笨，是记账方式错了
先看一个大背景。METR 的报告显示，高级智能体能完成的任务时域大约每 7 个月翻一倍，最近几代模型已经加速到 4 个月翻一倍。任务越来越长，原本能糊弄过去的设计缺陷就藏不住了。
论文把长时域执行的崩溃归成三个互相纠缠的病：
复合错误与目标漂移——早期一个小错沿着轨迹滚雪球，后面的决策全建立在错误前提上；上下文腐化——交互历史越堆越长，真正相关的信息反而捞不出来，过了某个阈值性能断崖式下跌；任务状态丢失——智能体根本没能力在整个执行过程中维护一份"我到底干到哪了"的准确账本。
这三个病大家多少都有体感。但我觉得论文最尖锐的观察是下面这个——现有框架有两个结构性缺陷：
其一，任务执行和任务状态管理共享同一个不断膨胀的上下文。你想想看，执行历史越长，"现在进行到哪一步"这个状态就越难从历史的垃圾堆里翻出来。其二，执行和验收是耦合的——智能体自己判断"我做完了"，这个自我判断被写进状态，再传给后面的决策。错误的自我评估就这么一路传下去。
打个比方——这就好比让施工队自己盖楼、自己记施工日志、自己验收签字。楼盖歪了他会在日志里写"盖歪了"吗？不会的，他会写"基本完成"。
我之前在做内部一个 Agent 项目时踩过一模一样的坑：executor 报"文件已生成"，下游拿这个声明当事实用，结果文件名对但内容是空壳。后来我们加了独立的验证步骤才稳住。所以看到这篇论文把这个直觉系统化，我的第一反应是——对，就该这么干。
🏗️ MEA 循环：把盖楼、记账、验收拆给三个人
先给一句话的直觉：别再让一条无限变长的对话从头跑到尾，改成一轮轮"派活—干活—验收"的短循环，跨轮只传递经过验证的状态。
图1：论文的总览图。左边是传统模式——一个智能体被不断增长的交互记录淹没，靠"自我报告的进度"判断完成度，最终 drift（漂移）。右边是 LongHorizon-Harness：Manager 拿着任务状态蓝图派活，Executor 在脚手架上干完一轮后上下文直接进垃圾桶，Auditor 拿放大镜独立检查并盖章"Certified"，跨轮唯一保留下来的记忆就是任务状态和审计报告。底下还画了三个角色都可以热插拔不同后端（Claude Code、Codex 等）。
这张图把核心思想画得挺清楚的。下面是更工程向的完整架构：
图2：MEA 循环的技术细节。左侧 Manage 模块：输入是原始任务和历史审计报告 V₁...Vᵢ₋₁，内部做状态读取、依赖判断，输出子任务合约 cᵢ——注意它标注了"never sees environment"和"不能改文件、点 GUI、跑命令"。中间 Execute 模块：GUI Agent（截图/点击/滚动/输入）和 CLI Agent（shell/文件编辑/编码/测试）两类，每轮全新上下文，预算 20 turns / 1800s，轨迹用完即弃。右侧 Audit 模块：只读检查环境，产出报告 Vᵢ，包含完成状态（complete/incomplete/blocked）和完整性状态（clean/suspect/violation）。底部是 AgentAdapter 接口层，同一套后端、不同的角色边界。终止条件写着：status = complete AND integrity = clean。
Manager：只动嘴，不动手
Manager 持有持久任务状态，决定下一步干什么。它能看到原始任务、当前状态、所有累积的审计报告，但没有任何环境接口——不能改文件、不能点按钮、不能跑命令。
每轮的转移写成公式是这样：
工程上怎么理解？Manager 就是一个纯函数式的状态机：吃进去任务 \(\mathcal{T}\)、当前状态 \(S_i\)、上一轮的审计报告 \(V_i\)，吐出来新状态、一个动作决策 \(q\)（execute / done / blocked / ask 四选一）和一份子任务合约 \(c\)。它不接触环境，所以它没法"亲眼看到"什么，它对世界的全部认知都必须来自审计报告——这就从机制上逼它只信验证过的事实。
任务状态里的记录分三种：requirement（从原始任务拆出来的目标和约束）、artifact（执行中产出或修改的东西）、fact（后续轮次需要的环境信息）。每条记录标着 completed / pending / blocked / untrusted，而且只有在干净审计证据支持下才能标 completed。子任务合约 \(c_{i+1}\) 则包含即时目标、验收标准、边界约束和相关审计报告引用——相当于给 Executor 发一张带验收单的工作票。
Executor：每轮都是第一天上班
Executor 是唯一被允许真正改动环境的角色：
注意这个公式的输入里没有之前轮次的交互轨迹。每次调用都是全新上下文，只拿着合约 \(c_i\)、当前状态 \(S_i\) 和相关报告进场。几十步的操作压缩成一份输出报告 \(o_i\)，然后轨迹直接丢弃。
这个设计真的挺反直觉的——扔掉历史轨迹，不怕丢信息吗？作者的回答很干脆：该留下的信息应该已经被 Auditor 验证并写进任务状态了，留在原始轨迹里的全是噪音。上下文腐化这个病，治本的办法就是不给它腐化的机会。
Executor 分 GUI 和 CLI 两种能力面，通过 AgentAdapter 接口可以直接套现有后端——Claude Code、Codex CLI、OpenClaw，保留它们各自的工具使用循环。这也是我觉得这套东西工程上最务实的地方：它没有要求你重写 agent，只是在现有 agent 外面包了一层角色边界。
Auditor：拿着放大镜的只读质检员
Auditor 从一个排除执行器内部推理的全新上下文出发，独立验证执行结果：
三条硬约束：只读权限（任何对环境状态的改动都会被记为完整性违规）、独立判断（自己拿环境跟验收标准对比，不听 Executor 的一面之词）、能力分化（GUI Auditor 只做观察性交互，CLI Auditor 只跑非变异性命令）。
审计报告 \(v_i\) 里有三样东西：完成状态（complete / incomplete / blocked）、完整性状态（clean / suspect / violation）、以及支持的任务状态更新——已验证事实、证据、剩余差距。
整个循环的终止条件也值得一说：审计状态满足原始任务、没有可推进的子任务、需要人类输入、或者 25 轮预算耗尽——四者其一即停。
🧪 实验：同一个模型，换个框架能涨多少
实验配置先交代一下：主力模型 Qwen 3.7-Plus，额外用 Claude Opus 4.7 做泛化验证。Executor 每轮 1800 秒超时，Manager/Auditor 各 300 秒，最多 25 轮。三个基准：WeaveBench（114 个 GUI+CLI 混合长任务，8 个领域）、OSWorld 2.0（108 个桌面工作流，人类完成中位时间约 1.6 小时）、Terminal-Bench 2.1（237 个纯命令行任务，每任务跑三次）。
图3：四联柱状图。左上 WeaveBench：LH-Harness 加持的 Qwen 3.7+ 拿到 80.7，比同模型裸 Claude Code 的 51.8 高出 28.9 个点，也压过 Opus 4.7 裸框架的 41.2。右上 Terminal-Bench 2.1：77.2 vs 基线 69.7。左下 OSWorld 2.0 binary completion：8.3 vs 2.8，三倍。右下 WeaveBench Games 子集：Opus 4.7 加框架 80.9 vs 裸框架 68.0，Qwen 加框架 73.3 vs 裸框架 52.4。
WeaveBench：涨 28.9 个点，弱模型反杀强模型
| 模型 | 框架 | PassRate↑ | Overall↑ |
|---|---|---|---|
| Claude Opus 4.7 | Claude Code | 41.2% | 0.532 |
| GPT-5.5 | Codex CLI | 35.1% | 0.499 |
| Qwen 3.7-Plus | Claude Code | 51.8% | 0.702 |
| Qwen 3.7-Plus | LongHorizon-Harness | 80.7 个百分点 | 0.835 |
80.7% 对 41.2%——同一个基准上，Qwen 加框架比 Opus 4.7 裸跑高出将近一倍。这个数字还是很能打的。
分领域看更有意思：
| 领域 | 基线 | LH-Harness | 提升 |
|---|---|---|---|
| Desktop | 83.3% | 88.9% | +5.6pp |
| Document | 76.5% | 100.0% | +23.5pp |
| Games | 29.4% | 58.8% | +29.4pp |
| Web | 46.7% | 73.3% | +26.7pp |
| Data Analysis | 53.8% | 84.6% | +30.8pp |
| DevOps | 66.7% | 91.7% | +25.0pp |
| Spatial/3D | 16.7% | 66.7% | +50.0pp |
| Design | 20.0% | 80.0% | +60.0pp |
我的第一反应是去看提升最小的那一行。Desktop 只涨了 5.6 个点，因为基线本来就有 83.3%，天花板近了。而 Design 从 20% 涨到 80%——基线越烂的任务，框架救回来的越多。这个 pattern 和论文自己的解释一致：框架主要在"打捞那些本来会彻底失败的轨迹"，拉的是下限，不是上限。
不过得泼一点冷水：Design 和 Spatial/3D 这两个暴涨的领域样本量很小（从百分比反推大概就 5-6 个任务），+50pp、+60pp 这种数字统计噪声不小。大样本的领域（如 Games 17 个任务）涨 29.4 个点，这个更可信。
OSWorld 2.0：三倍提升，但绝对值仍然难看
| 模型 | 框架 | Binary↑ | Partial↑ |
|---|---|---|---|
| Claude Opus 4.8 | Batched actions | 20.6% | 54.8% |
| Qwen 3.7-Plus | Single action | 2.8% | 21.5% |
| Qwen 3.7-Plus | LongHorizon-Harness | 8.3 个百分点 | 35.2 个百分点 |
| Claude Opus 4.7 | Single action | 20.6% | 55.8% |
| Claude Opus 4.7 | LongHorizon-Harness | 35.3 个百分点 | 66.9 个百分点 |
"翻三倍"听起来很唬人，但说实话，2.8% 到 8.3% 的绝对水平依然很惨——OSWorld 的 binary completion 本身就是业界公认的地狱难度，最强的 Opus 4.7 加框架也就 35.3%。GUI 长任务离"可用"还差得远。
有意思的是 Partial 分数：Qwen 从 21.5% 涨到 35.2%。很多任务没完全做成，但做对了更多步骤。这也呼应前面的判断——框架在打捞下限。
Terminal-Bench 2.1：挤进排行榜第一梯队
| 模型 | 框架 | 平均分 |
|---|---|---|
| Qwen 3.7-Plus | Claude Code（基线） | 69.7% |
| Qwen 3.7-Plus | LongHorizon-Harness | 77.2 个百分点 |
| GPT-5.6 Luna | LongHorizon-Harness (Codex) | 83.1 个百分点 |
图4：Terminal-Bench 官方排行榜截图。LH-Harness + Codex（GPT-5.6 Luna, max）拿到 83.1，与 Codex 裸跑 GPT-5.5 xhigh 的 83.1 并列，仅次于 Claude Code (Fable 5) 的 83.8。LH-Harness + Claude Code（Qwen 3.7-Plus）的 77.2 排在第十名左右，比同模型裸 Claude Code 的 69.7 高了 7.5 个点。
这张排行榜值得多看一眼。Qwen 3.7-Plus 裸跑只有 69.7%，在榜上属于中下游；套上框架后 77.2%，直接超过了 Codex 裸跑 GPT-5.6 Luna 的 75.7% 和 mini-SWE-agent 的 76.2%。框架把二线模型送进了第一梯队的尾巴。
不过我也注意到一个细节：榜上带星号的条目是官方跑的，LH-Harness 的条目没带星号——说明是作者自己复现的评测。分数大概率没问题，但严谨起见，这个区分读者应该知情。
按任务类别拆开看：框架不是万能药
Terminal-Bench 的分类数据我觉得比总分更有信息量：
| 类别 | 任务数 | 基线 | LH-Harness | 变化 |
|---|---|---|---|---|
| system-administration | 27 | 59.3% | 88.9% | +29.6pp |
| games | 3 | 0.0% | 33.3% | +33.3pp |
| data-processing | 12 | 75.0% | 91.7% | +16.7pp |
| scientific-computing | 24 | 37.5% | 54.2% | +16.7pp |
| software-engineering | 78 | 70.5% | 83.3% | +12.8pp |
| debugging | 15 | 93.3% | 100.0% | +6.7pp |
| security | 24 | 83.3% | 87.5% | +4.2pp |
| data-science | 24 | 79.2% | 66.7% | 降 12.5pp |
| mathematics | 12 | 91.7% | 75.0% | 降 16.7pp |
看到最后两行没有？data-science 掉了 12.5 个点，mathematics 掉了 16.7 个点。框架不是白赚的。
作者的解释我基本买账：math 和 data-science 这类任务，性能瓶颈在模型的单次推理能力本身，不在状态管理。你给它加 25 轮的 Manager-Auditor 开销，等于在一个本来一步就能想明白的问题上强行套流程，反而引入了干扰——Manager 的派活可能把一个连贯的推理链切碎。这其实给工程落地划了一条很重要的边界：状态管理框架只在"失败主要来自状态丢失"的任务上有效，对"失败主要来自能力不足"的任务是负资产。
按难度拆开看则符合预期：Easy 从 83.3% 到 100%，Hard 从 53.3% 到 65.6%（涨 12.2 个点），Medium 只涨 4.2 个点。难点任务才是这套框架的主战场。
💰 天下没有免费的验收：成本账单
聊完成效，得聊聊账单。这部分论文给得挺坦诚，我觉得比主结果更有决策价值。
图5：两张散点图，横轴都是每任务输出 token 数。左图 OSWorld binary completion：LH-Harness（蓝色五角星，Qwen 3.7-Plus）大约烧 100K token 拿到 8.3%，对比之下 GPT-5.5 用约 50K 就拿到 13%，Claude 系沿着右上方的效率前沿排布。右图 Score 维度：LH-Harness 同样偏离效率前沿——同样的 token 预算，强模型裸跑拿的分更高。
这张图其实挺扎心的。LH-Harness + Qwen 的组合不在成本-性能前沿上——它用 3.6 倍的 token（28.9K → 104K/任务）换来了三倍的 binary completion，但这个性价比打不过直接换强模型。
但故事还有另一面，也是我觉得全文最有意思的一个发现：
| 模型组合 | Token 消耗变化 |
|---|---|
| Opus + 框架 | 16.5M → 11.1M（省了约三分之一） |
| Qwen + 框架 | 10.7M → 34.3M（涨了 3 倍多） |
强模型套框架反而省 token。原因想通了其实很顺：强模型一两轮就能把子任务合约做干净，审计一次过，不用反复重规划；弱模型每轮都留下一堆 gap，Manager 就得不停地派活、审计、返工，轮次越滚越多。
所以这套框架的成本结构是"惩罚弱者、奖励强者"的。它不是一个让弱模型变便宜的方案，而是一个让强模型变稳（甚至更省）的方案。这个结论对选型太关键了——如果你因为成本原因用不起 Opus 才选 Qwen，那套上 LH-Harness 可能反而把你的 token 账单炸上天。
再看计算量在三个角色间怎么分布：
图6：三个基准上 Manager / Executor / Auditor 的 token 占比，以及和基线的总量对比。WeaveBench：Manager 3%、Executor 78%、Auditor 19%，总量 27.4M vs 基线 12.0M。OSWorld：2% / 73% / 25%，104K vs 28.9K。Terminal-Bench：8% / 54% / 38%，3.5M vs 4.6M——注意这个基准上框架反而比基线省 token。
Manager 的开销出奇地低（不到 10%），这说明"做计划"这件事根本不需要多少算力。真正吃 token 的是 Auditor（19%-38%）——独立验证不便宜。而 Terminal-Bench 上框架总 token 反而比基线低，又一次验证了"任务越吃状态管理，框架越划算"的规律。
🔬 案例研究：框架到底救回了什么
数字之外，论文给了几个轨迹级的案例，我觉得这是全文最能建立直觉的部分。
案例一：400 步鬼打墙 vs 证据驱动恢复
图7：上半部分是基线（得分 0.59）：Wireshark 的 "Decode As" 对话框无响应，智能体反复点 OK 按钮，400 多步后预算耗尽——失败从未被外化记录，任务原地空转。下半部分是 LH-Harness（得分 0.92）：渲染三层码率曲线、悬停采集 fps=0 的掉层证据、每张截图对应报告里一条可验证命题，最后加载 21018 个包做交叉验证。
基线的死法很典型：局部失败（对话框卡死）被注意到了，但只存在于执行上下文里，从来没有变成一个"状态对象"。上下文一长，这个失败信息被淹没，智能体又回到了同一个对话框。
LH-Harness 的差别在于：第一轮没搞定，Auditor 报告里就写下了"缺少 f-layer 掉帧证据"这个 gap，Manager 下一轮直接从 gap 派生新子任务——换个路径去收集证据。失败被物化成了状态，就不会被遗忘。
案例二：先取证，再修复
图8：基线（得分 0.45）急着修公式，直接改 XML，把"修复前"的取证现场破坏了——前后状态对不上，证据链断了。LH-Harness（得分 0.87）先锁定修复前的截图证据，再修复，再逐单元格验证 VLOOKUP 公式，最后由 verifier 审查完整 9 张截图序列，确认时间一致的证据链。
这个案例戳中的是另一个微妙问题：有些任务要求的不只是"结果对"，还有"过程合规"。基线直接上手修，结果确实修好了，但任务要求的取证流程没走完，得分照样腰斩。Manager 把"先取证"写成了子任务的依赖关系，顺序就不会乱。
案例三：CLI 环境下的 6 轮攻坚
图9：Terminal-Bench 上一个编译 SQLite 并启用 gcov 插桩的任务。左边基线（reward=0）：一整条raw命令流水，中途 PATH 设置错了没人发现，三个验证测试挂了一个。右边 LH-Harness（reward=1）：6 轮 MEA 循环，每轮的合约、阻塞项、审计报告都显式记录，中途审计发现 "cannot access /app/sqlite: No such file or directory" 这类问题后逐轮修正，最终三个测试全绿。
基线在这里的死因特别隐蔽：命令流中间有一步 PATH 设错了，后面的步骤在错误前提下继续跑，没人回头检查。这就是复合错误的教科书样本。而右边每一轮审计都在问"合约里的验收标准现在满足了吗"，错误活不过一轮。
🤔 我的判断：一套值钱的工程框架，但别当成能力突破
聊完数据和案例，说说我的整体看法。
最值钱的地方：把"自我报告进度"这个隐性依赖给干掉了。当前主流 agent 框架（包括 Claude Code 这种生产级工具）的完成度判断基本都是 executor 自说自话。这篇论文用角色隔离 + 只读审计 + 状态物化三板斧，把进度判断变成了一个需要外部证据支撑的显式对象。这不是什么高深的算法，但它直指长任务智能体最脆弱的那根肋骨。WeaveBench 上 28.9 个点的提升、Games 子集上弱模型反杀强模型，都说明这个痛点是真实的、大的。
要泼的冷水：一是成本。弱模型套框架 token 涨 3 倍，而且不在成本-性能前沿上——很多时候直接换强模型更划算。二是适用边界比论文标题暗示的要窄，math、data-science 这类吃单次推理能力的任务上框架是负收益，掉了 12-17 个点。三是小样本领域的暴涨数字（+50pp、+60pp）看看就好，别当结论。四是 Terminal-Bench 的分数是作者自测的，缺官方星标背书。
跟前人工作的位置：Manager-Worker 的多智能体划分并不新鲜，AutoGen、MetaGPT 那一波早就玩过。这篇的增量不在"分工"，在于两点——Auditor 的只读独立验证（以前的多智能体框架里 verifier 通常能看到 executor 的推理过程，容易被带偏），以及"轨迹丢弃、状态永存"这个激进的信息架构。说实话这块我也不是特别确定它跟最新的 Reflexion 类自我反思方法的边界在哪——论文里对这类工作的对比不够充分，算是个小遗憾。可能我的理解有偏差，但我倾向于认为：自我反思是在同一个上下文里打补丁，而这篇是直接把上下文本身当成耗材，这是范式层面的区别。
工程启发，如果你在做长任务 Agent：
如果你发现智能体在长任务里"自己骗自己"——别急着换模型，先检查进度判断是不是自我报告的。加一个独立的只读 verifier，成本大约占总 token 的 20%-40%，但可能救回一大批死掉的轨迹。
如果你的任务以 math、单次推理为主——别套重型状态框架，它带来的切碎效应可能让你掉 10 个点以上。
如果你在选型——记住那个反直觉结论：状态管理框架是强模型的放大器，不是弱模型的救命稻草。强模型套它更稳还可能更省，弱模型套它账单先炸。
还有一个更本质的问题这篇没回答：Manager 自己也是个 LLM，它对审计报告的理解出错怎么办？谁来审计 Manager？论文没说，我猜是下一轮再说。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我