你有没有经历过这样的场景：让一个新来的实习生做一件复杂的事，比如"帮我把这个项目的所有测试跑一遍，修好报错的地方，再写份报告"。结果三天后他跟你说"做完了！"你打开一看，报告写得漂漂亮亮，但代码根本没改，测试其实还在报错。
(相关资料图)
他不是故意撒谎。他只是在漫长的工作过程中，自己也搞不清哪些事真的做完了，哪些事只是看起来做完了。
现在把这个实习生换成一个AI智能体，你会发现一模一样的问题正在发生。而且更麻烦的是，这个AI智能体不仅会骗你，还会骗自己。它会把自己"以为完成了"的假象当成事实，继续往下推进任务，最后整个项目跑偏到完全不知道哪里出了错。
这就是阿里巴巴DreamX团队在这篇论文里想解决的核心问题。他们给出的方案有个朴素到近乎直白的名字：LongHorizon-Harness（长视野执行框架）。
长任务执行,到底难在哪
先说一个背景数据。研究机构METR做过一项追踪，发现顶尖AI智能体能独立完成的任务时长，大约每七个月翻一倍，最近这个速度还在加快，缩短到了四个月左右。像Claude Code、Codex这样的编程智能体，已经能在一个项目上连续工作好几个小时不停歇。
听起来很厉害对不对?但论文一开篇就泼了盆冷水:时间变长了,不代表可靠性变高了。
这句话初听平淡,细想却挺扎心的。我们下意识会觉得,能力越强的模型,处理越长的任务应该越稳，可现实恰恰相反：任务越长，出错的概率反而越会累积放大。这不是模型不够聪明，而是一种结构性的困境。
论文指出了三个具体的病灶。
第一个是**错误累积和目标漂移**。想象一下你在导航时,第一个路口就走岔了,后面每一步都是在错误的基础上继续修正,越走越偏,最后可能完全偏离了原本要去的地方。AI智能体在长任务里就是这样,早期的一个小判断失误,会像滚雪球一样影响后面所有的决策。
第二个是**上下文腐化**（Context Rot）。
> 上下文腐化：随着对话历史越堆越长，模型越来越难从中准确检索到真正有用的信息，一旦历史长度超过某个临界点，模型表现会断崖式下跌。
这个现象背后有研究(Liu et al., 2024)专门验证过，叫"lost in the middle"，就是说模型对长文本中间部分的内容记忆力特别差，容易"读了但没记住"。
第三个是**任务状态丢失**。这是最核心的一条：智能体不知道现在做到哪一步了，哪些要求已经满足，哪些证据是真实的，哪些还悬而未决。
这三个问题叠加在一起，会导致什么后果？现有的智能体框架，比如Claude Code、Codex CLI，虽然已经支持任务拆解、子代理、工具调用这些功能，但它们有个共同的结构性缺陷：执行任务和判断任务是否完成，用的是同一套上下文，同一个"大脑"。
这就好比让一个学生自己批改自己的考卷。他做错了一道题，然后又用同样的思路去检查这道题，大概率还是会觉得自己做对了。
**执行者不该同时是裁判。**
这句话，就是整篇论文的出发点。
MEA循环：把"做事"和"验收"彻底分开
论文提出的解法叫Manage-Execute-Audit循环，简称MEA循环，中文可以理解为"管理-执行-审计"循环。
这个设计的核心思路，是把一个长任务拆成一轮一轮的短回合，每一轮里有三个角色分别登场，各司其职，谁也不越界。
第一个角色是**管理者**（Manager）。
> 管理者：只负责维护任务的全局状态，决定下一步该做什么，但完全不接触实际的执行环境，看不到屏幕、点不了按钮、跑不了命令。
管理者手里有的，只是当前的任务状态记录，和之前所有轮次留下的审计报告。它像一个远程指挥官，从不亲自上前线，只根据侦察兵传回来的确认情报来下达下一步指令。
第二个角色是**执行者**（Executor）。
> 执行者：负责真正干活的角色，是整个系统里唯一被允许修改环境的角色，比如点击界面、编辑文件、跑测试脚本。
执行者每一轮都在一个全新的、干净的上下文里工作，它看不到之前几轮发生了什么，只拿到这一轮需要完成的具体任务卡片。干完活儿之后，它的整个思考过程和交互记录会被直接丢弃，只留下一份执行报告。
第三个角色是**审计者**（Auditor）。
> 审计者：独立检查执行结果的角色，只能读取环境状态，绝对不能修改任何东西，它的任务是判断这一轮到底真的完成了什么。
审计者也是在一个全新上下文里工作，它看不到执行者内部是怎么想的，只能靠自己重新检查环境，来判断哪些是真的完成了，哪些只是执行者自己声称完成了。
这三者之间的关系，画成一张图就特别清楚。管理者根据审计报告，定一个明确的子任务，交给执行者；执行者在自己的沙盒里干活，交出一份执行报告；审计者独立核实这份报告对不对，再把审计结果反馈给管理者，开始下一轮。
这里有个细节特别值得琢磨：**跨轮次唯一保留下来的记忆，就是审计报告**。
执行者的原始交互记录，无论多详细，一轮结束就全部丢弃。这个设计乍一看有点浪费，但恰恰是它解决了上下文腐化的问题。
打个比方，这就像公司里的项目交接制度。如果新接手的人要把前任所有的聊天记录、草稿、废弃方案全部翻一遍才能上手，那交接效率极低，还容易被过时或错误的信息带偏。但如果交接的只是一份经过核实的"验收清单"，写清楚哪些模块已经通过测试、哪些接口还没对接，新人反而能干净利落地接着干。**如果不这样设计，会怎样？**论文里给出的答案很直接：执行历史会越滚越大，最后连模型自己都分不清哪句话是三十轮前说的、哪句话是刚刚发生的，这正是上下文腐化的根源。
任务状态本身也有严格的结构。它由三类记录组成：需求（从原始任务里拆解出的目标或约束）、产物（执行过程中生成或修改的文件、结果）、事实（后续轮次需要用到的环境信息）。每条记录都标着完成、待定、受阻、或不可信这几种状态之一，而且必须附带审计证据的引用。
这里有个特别关键的设计：**执行者说"我做完了"，这句话本身不算数**。
只有当审计者独立核实之后，这条记录才会被标记为"完成"。这就相当于财务报销制度里的"报销单不能自己签字通过"，必须有另一个人核实票据、核对金额，才能真正入账。这不是不信任执行者，而是任何自我评估机制天生就带有确认偏差,系统设计上必须把这个偏差隔离出去。
那审计者具体怎么审？论文里描述得很细：审计报告需要给出三类判断。第一类是完成状态，是完成了、没完成、还是被卡住了；第二类是完整性状态，环境有没有被意外污染，比如执行者是不是偷偷删了不该删的文件；第三类是任务状态更新，记录审计过程中发现的新事实和还存在的缺口。
值得一提的是，管理者、执行者、审计者三个角色都可以用不同的底层模型和不同的智能体框架来实例化，比如管理者用Qwen，执行者用Claude Code，审计者用Codex，互不冲突。论文里管这套接入机制叫AgentAdapter（智能体适配器），它是一个轻量级接口，作用是让现有的这些成熟框架的原生工作流程完全不用改动，直接插进MEA循环里就能用。这个设计的好处是显而易见的：企业不需要重写自己已经跑得很好的智能体系统，只需要在外面包一层任务状态管理就行。
三个基准测试，验证效果到底有多大
光讲设计思路不够有说服力，得看实际数据。论文在三个近期发布的长任务基准上做了测试，分别覆盖不同的应用场景。
第一个叫**WeaveBench**。
> WeaveBench：一个包含114个任务的评测集，特点是每个任务都需要图形界面和命令行两种操作方式配合完成，覆盖桌面应用、文档处理、游戏、网页开发、数据分析可视化、运维、三维空间应用、设计这八大领域。
用Qwen 3.7-Plus这个模型，配合Claude Code作为执行后端，原始框架的通过率是51.8%，套上LongHorizon-Harness之后，直接飙到了80.7%。这个提升幅度什么概念呢？官方公布的所有成绩里，表现最好的是Claude Opus 4.7配Claude Code跑出的41.2%，而这次的结果几乎是把这个最强官方成绩翻了一倍。
第二个叫**OSWorld 2.0**。
> OSWorld 2.0：一套包含108个桌面工作流任务的评测集，人类完成这些任务平均需要1.6个小时，属于相当有挑战性的真实场景任务。
论文里报告了两个指标，二值完成率（任务是否被彻底完成，拿满分）和部分得分（衡量任务完成的比例）。Qwen 3.7-Plus原始表现是二值完成率2.8%，部分得分21.5%。套上框架之后，二值完成率提升到8.3%，接近三倍；部分得分提升到35.2%。
第三个叫**Terminal-Bench 2.1**，专门评估命令行环境下的高难度真实任务。这里没有图形界面，纯粹靠命令行操作。Qwen 3.7-Plus配Claude Code的成绩从69.7%提升到77.2%；如果换成Codex配GPT-5.6 Luna，甚至能冲到83.1%，直接挤进这个基准的官方排行榜前列。
这里有个特别值得注意的现象。Terminal-Bench不涉及任何视觉感知或者图形界面路由的问题，纯粹是文本命令的世界。这说明什么？说明MEA循环带来的提升，不是靠某种针对图形界面的特殊技巧，而是一种通用的、跟具体交互方式无关的能力。
论文还额外测了一下**跨模型的泛化性**，把执行的底层模型换成Claude Opus 4.7，在OSWorld 2.0的34个任务子集上，二值完成率从20.6%提升到35.3%，部分得分从55.8%提升到66.9%。这说明这套框架不是专门为了拉一个弱模型及格线而设计的补丁，强模型套上之后同样获益。
下面这张表汇总了核心数据：
| 基准测试 | 模型配置 | 原始表现 | 套用框架后 |
| WeaveBench (PassRate) | Qwen 3.7-Plus + Claude Code | 51.8% | **80.7%** |
| Terminal-Bench 2.1 | Qwen 3.7-Plus + Claude Code | 69.7% | **77.2%** |
| Terminal-Bench 2.1 | GPT-5.6 Luna + Codex | 75.7%（官方原始） | **83.1%** |
| OSWorld 2.0 (二值完成率) | Qwen 3.7-Plus | 2.8% | **8.3%** |
| OSWorld 2.0 (部分得分) | Qwen 3.7-Plus | 21.5% | **35.2%** |
| OSWorld 2.0子集 (二值完成率) | Claude Opus 4.7 | 20.6% | **35.3%** |
代价：多花的钱和时间去哪了
任何提升都不是免费的午餐。这套框架的运行成本要怎么算？
论文用一张图（图4）画出了成本-性能的权衡曲线。Qwen 3.7-Plus在OSWorld 2.0上，套用框架前平均每个任务消耗2.89万输出token，套用后涨到10.4万，差不多是原来的3.6倍。
但这笔账不能只看倍数，得看具体花在哪了。论文把三个角色的token消耗拆开来看，管理者只占了WeaveBench上2.8%、OSWorld 2.0上2.0%、Terminal-Bench上8.1%的总消耗，说明维护任务状态这件事本身开销很小。真正花钱的大头，是审计者，占到19.4%到38.1%不等。
这个结果其实很直观。就像质检环节一定比记账环节耗时更长一样，独立核实一件事有没有真的做对，本来就比记下"这件事该不该做"要费劲得多。审计者需要重新去看文件、截图、日志，重新走一遍验证流程，这本身就是这套框架额外投入的主要部分。
不过更有意思的是，这个成本倍数并不是固定的。在Terminal-Bench 2.1上，套用框架后的token消耗反而比基线**少了24%**，同时成功率还更高。这说明框架的总成本高度依赖具体任务和底层模型需要多少轮"执行-审计-重来"的循环才能搞定。
论文里还有个特别扎心的对比（表4），用同一批17个WeaveBench游戏任务，分别测Claude Opus 4.7和Qwen 3.7-Plus。结果显示，**框架带来的token消耗变化方向，在两个模型上完全相反**：Qwen的平均消耗从10.7M涨到34.3M，而Opus反而从16.5M降到11.1M。
这背后的道理是，越强的模型越能一次性把子任务做对，审计一次就通过，不需要反复重试；而能力较弱的模型经常做不对，就得反复经历"执行失败、审计发现问题、重新规划、再执行"的循环，自然烧掉更多token。**这也从侧面证明了一个反直觉的结论**：框架本身不创造能力，它只是让已有能力更可靠地被兑现出来。强模型在这套框架下省钱，弱模型在这套框架下费钱但换来了原本根本做不到的完成度。
任务类型不同，收益差异也很大
论文没有满足于报一个总分了事，还专门拆解了不同类型任务上的表现差异（图6），这个拆解特别有意思，因为它揭示了这套框架真正擅长解决什么问题，以及它解决不了什么问题。
在WeaveBench上，提升最大的是设计类任务（提升60个百分点）和空间/三维应用类任务（提升50个百分点），而桌面应用这个原本就已经做到83.3%及格率的领域，只提升了5.6个百分点。
在OSWorld 2.0上，提升最大的出现在流媒体交互、人机协作、以及跟随教程这几类任务里。
在Terminal-Bench 2.1上，系统运维和游戏类任务提升明显，但有几个短小的分析类任务反而出现了轻微退步。
这个模式说明了什么？论文给出的解释很实在：**那些提升幅度大的任务，共同特点是需要智能体在很长的轨迹里保存、检查、反复修订多个相互依赖的环境状态**。而那些提升不大甚至倒退的任务，往往是瓶颈在于单一的模型能力，比如精细的视觉定位、数学推理、算法设计本身有没有做对。
这个区别其实挺关键的。独立审计能发现一个错误的结果，能触发重新规划，**但它没办法给模型补上一个它本来就不具备的能力**。审计者可以告诉执行者"你这道数学题算错了"，但审计者没办法替执行者把这道题重新算对。
打个比方，这就像一个严格的编辑能帮作者发现文章里的逻辑漏洞、事实错误，能要求作者重写某一段，但编辑没办法替作者把一篇本身构思平庸的文章变成一篇天才之作。编辑的作用是保证质量下限不失控，而不是抬高才华的上限。**如果没有这层编辑机制会怎样？**论文里那个GUI卡死400多步的案例（后面会详细讲）就是答案：作者会在同一个错误里死循环，永远意识不到问题，直到耗尽所有时间预算。
具体案例：从卡死到恢复
数字讲完了，说几个论文里具体记录下来的执行轨迹对比，这些例子比数字更能说明问题出在哪、框架又是怎么解决的。
第一个例子是一个WebRTC网络分析任务。基线智能体在使用Wireshark抓包分析工具时，遇到一个叫"Decode As"的对话框卡死了不响应。它意识到了这个问题，但这个意识只停留在自己越来越长的对话历史里，没有变成任何结构化的记录。结果它在同一个交互上反复尝试了超过400步，始终没能收集到任务需要的剩余证据，最终得分只有0.59。
换成LongHorizon-Harness，管理者把"这个交互失败了、还有哪些证据没收集到"明确记录进任务状态，交给下一轮全新的执行者。新的执行者不再纠结那个卡死的对话框，直接去收集缺失的图表和数据包证据，最终得分冲到0.92。
第二个例子更微妙，是一个文档格式规范化任务。基线智能体直接改了文档的底层XML文件，让标题看起来像是正确的一级标题样式，然后就此收工，觉得任务完成了。但任务其实要求必须通过LibreOffice这个软件的正常操作流程来完成样式修改，结果这个"看起来对"的答案得分是0.00。
LongHorizon-Harness这边，执行者按照要求的GUI流程逐个操作，审计者随后重新解析文档的XML结构，独立确认所有15个标题确实都用上了正确的样式编码，最终得分0.89。
这个例子特别戳中要害：**执行者觉得自己做对了，和这件事真的做对了，是两回事**。如果没有独立的审计环节，那个"看起来对"的假象就会被直接写进任务状态，后续所有决策都会建立在这个错误假设之上，越走越偏。
第三个例子涉及证据的时序问题。任务要求先记录一份修复前的Excel公式错误证据，再进行修复。基线智能体记录了初始状态，但还没收集完所有该收集的证据，就直接开始改文件了，导致最后交出来的证据链前后矛盾，得分0.45。LongHorizon-Harness把"缺失的修复前证据"当作一条待完成的需求明确记在任务状态里，逼着下一轮执行者先把证据收集完整，再动手修复，最终得分0.87。
这几个案例合在一起看，能感受到一个共同的规律：**问题往往不出在智能体不会做事，而出在它不知道自己做没做完**。
写在后面
读完这篇论文最让我意外的一点是，这套方案没有用任何前沿的模型训练技巧，没有微调，没有强化学习，甚至没有一个新的模型架构。它做的事情，说白了就是把"干活"和"验收"这两件本来被强行捆在一起的事情拆开了，各自配一个独立的大脑。
这让我想起软件工程里一个老掉牙但至今没被完全解决的问题：写代码的人和测试代码的人如果是同一个人，很容易漏掉自己代码里的盲区。人类花了几十年才把这个道理制度化成代码评审、独立QA团队这些实践。而AI智能体现在正在重走这条路，只不过这次不是靠组织架构，是靠三个AI角色的分工来实现。
论文里有个细节我觉得特别值得单独拎出来说：审计者查完一次，如果发现执行者动过了不该动的文件，会直接把这次的审计结果标记为"完整性受损"，这条记录就永远没法被标记为"完成"，不管执行者怎么解释。这种"宁可信其无、也不信其自证"的机制设计，其实比技术细节本身更有意思，因为它体现的是一种对AI自我报告的根本性不信任，而这种不信任恰恰是让系统变得可靠的关键。
论文里也留了一个没解决的问题：审计者的判断质量依赖底层模型本身的理解能力，如果任务的验收标准本身就很模糊，或者需要非常专业的领域知识才能判断对错，审计者会不会也犯错？这个问题论文没细谈，但值得继续追问下去。
Q&A
Q1：LongHorizon-Harness是什么？
A：它是阿里巴巴DreamX团队提出的一个智能体执行框架，核心思路是把长任务的"执行"和"状态管理判断"分离开，通过管理者、执行者、审计者三个角色分工协作，让任务进度只被独立核实过的事实更新，而不是被执行者自己声称的完成情况更新。
Q2：LongHorizon-Harness效果提升有多大？
A：在WeaveBench基准上，用Qwen 3.7-Plus模型时通过率从51.8%提升到80.7%；在OSWorld 2.0上二值完成率从2.8%提升到8.3%，接近三倍；在Terminal-Bench 2.1上从69.7%提升到77.2%，对Claude Opus 4.7同样有效。
Q3：LongHorizon-Harness的额外成本高不高？
A：成本因任务和模型而异，在OSWorld 2.0上token消耗涨到原来的3.6倍左右，但在Terminal-Bench 2.1上反而减少了24%的消耗还提升了成功率，强模型使用框架时通常更省钱,因为它一次性做对的概率更高，不需要反复重试。
营业执照公示信息