长程任务的两种失败
短任务里，智能体只要把一步做对就够了；长程任务里，它必须记住自己做到哪、哪些前提已经成立、哪些结论已经被推翻。这个差别看似只是长度问题，实际上会引入两类特定的失败。
一类是状态漂移。随着上下文持续增长，智能体难以稳定追踪任务状态，早先确认过的约束会在后续步骤里被遗忘或改写。另一类是错误传播。当智能体对自身进展的判断本身出错时，这个错误会成为后续决策的依据，导致偏差沿着执行链一路放大。
阿里巴巴 DreamX 团队针对这两类问题提出了 LongHorizon-Harness，核心思路是把长程任务执行重新定义为显式的状态管理问题，而不是把它当作更长的上下文推理。
把执行重定义为状态管理：管理、执行、审计的循环
该方法的运转结构是一个被称为管理、执行、审计的循环。三个环节各承担一部分职责：管理环节维护任务状态，明确当前处于哪一步、已完成什么、还有哪些未决事项；执行环节在状态约束下推进具体操作；审计环节检查执行结果，并决定状态如何更新。
这个方法里更值得注意的是它给状态更新设定的条件：仅依据环境中可独立验证的事实来更新后续决策。
这句话看起来像一句原则，实际是一条相当具体的工程纪律。它把智能体对自身进展的判断从「我觉得已经完成了」改成「环境中存在可核验的证据表明这一步完成了」——例如文件确实存在、命令确实返回成功、测试确实通过、接口确实返回了预期结构。凡是无法在环境中找到证据的自述，都不能作为状态推进的依据。
这条纪律直接针对错误传播问题。当智能体的自我评估出错时，如果状态更新依赖的是自述而非证据，错误就会被固化；而如果更新必须通过环境证据这一关，错误就更容易在审计环节被拦下。
公开数据：三个基准上的变化
公开信息给出了三组结果。
在 WeaveBench 上，Qwen 3.7-Plus 的得分从 51.8% 提升到 80.7%，增幅接近 29 个百分点。这个幅度值得留意，因为它是在同一模型上取得的——变化来自 harness 层，而不是模型能力。
在 Terminal-Bench 2.1 与 OSWorld 2.0 上，该方法也报告了明显增益。此外，Claude Opus 4.7 在 OSWorld 2.0 的一个子集上，表现从 20.0% 提升到 34.3%。
跨模型的提升是这组数据里信息量较大的部分。它说明该方法的效果并非绑定在某个特定模型上，而更像是补上了一层通用能力：无论底座模型是谁，把状态管理显式化都能带来改善。论文将其描述为良好的跨模型与跨框架泛化能力。
为什么这件事和近期的 Harness 研究连在一起
LongHorizon-Harness 不是孤立出现的。2026 年 9 月前后，Agent Harness 成为一个密集讨论的方向，多个团队从不同角度切入同一组问题。
有的工作在澄清概念：通过追溯从传统测试 harness 到机器学习评估 harness 再到智能体 harness 的谱系，给出系统成为智能体 harness 的必要与充分条件，并用 Claude Code、Codex CLI、Aider、Cline、OpenHands 与 SWE-agent 等真实系统验证分类的一致性。这类工作的价值在于让「harness」这个被滥用的词有了边界。
有的工作在解决上下文与经验的组织方式：把原始执行轨迹、从中提炼的模式知识、以及当前生效的操作指南分成不同层次，避免把所有历史都塞进上下文，也避免每次都要从零重新分析原始记录。
有的工作则在质疑自我改进的评估方式：指出多数研究各测各的，忽略了一个现实问题——部署环境里任务类型是混杂的，在单一基准里表现良好的进化机制，换到任务交替出现的场景里可能失效。
把这些工作放在一起看，会发现它们共同指向一个判断：在需要正确性的长程任务上，编排与状态管理的贡献可能不亚于模型能力本身。LongHorizon-Harness 提供的正是其中一块相对具体的拼图——如何让状态可信。
中立思辨
需要辩证看待几件事。其一，公开数据来自对该研究的整理，工程团队在采纳前应查阅论文原文核对实验设置，包括任务数量、评测协议与是否使用相同提示词，因为这些条件会显著影响可比的幅度。其二，WeaveBench 等基准虽然设计用于长程任务，但与真实生产流程之间仍存在差距——真实任务的失败往往是外部依赖变化、权限不足或数据缺失造成的，而不是状态管理问题，这类失败该 harness 未必覆盖。其三，「仅依据可独立验证的事实更新状态」这条纪律有一个隐含前提：环境中确实存在可验证的证据。在探索性任务里，例如判断一个技术方案是否可行，往往不存在可以即时验证的事实，此时该机制的作用会减弱。其四，显式状态管理会引入额外开销，包括状态维护本身的调用、审计环节的执行以及更长的链路；在短任务上使用这套机制可能得不偿失，适用性判断应基于任务的步骤数量与失败代价。其五，跨模型泛化是正面信号，但 20.0% 到 34.3% 这样的绝对水平说明该类任务整体仍处于较低完成度，harness 的改善并没有把问题变成已解决。其六，该方法的开源状态、许可协议与工程化封装程度，公开信息中尚未完整披露，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
趋势研判
短期看，这类方法更可能先被吸收进编码 Agent 与自动化运维工具里，因为这两类场景的证据天然存在于环境中——文件、日志、测试结果都是可核验的；中期看，关键变量是状态表示能否标准化，如果不同框架各自定义状态格式，跨工具协作时仍会出现状态不可互认的问题；长期看，长程任务的可靠性可能沿着与分布式系统相似的路径演进：从依赖单点判断，转向依赖可验证的状态机与审计日志。
对正在搭建长程 Agent 的团队，一个务实的起点是把最近一次失败的长任务复盘一遍，逐个标出哪些中间结论是「智能体自己说完成了」而没有环境证据支撑的。这份清单往往能直接指出最该先补的审计点。