LongHorizon-Harness：长任务 Agent 为什么要把“记忆”从上下文里拿出来？

8 月初 Hugging Face Papers 上的 LongHorizon-Harness 很值得写。它不是又一个炫榜单的 Agent benchmark，而是直接击中了长任务 Agent 的核心问题：如果你把执行过程、任务状态和完成判断都塞进同一个不断增长的上下文，Agent 会越来越难知道自己到底做到了哪一步。

这听起来像小问题，其实是 Agent 生产化的大问题。

短任务里，模型可以靠上下文记住历史。用户说了什么、工具返回了什么、自己刚才计划了什么，都还在窗口里。但长任务不一样。Agent 可能要跨几十步操作文件、终端、浏览器、GUI 或远程环境。中间一旦产生错误自评，比如“我已经安装好了依赖”“测试通过了”“文件保存了”，后面的步骤就会建立在错误状态上。

LongHorizon-Harness 的思路是：不要让模型把状态都放在脑子里。它把长周期执行重构成 task-state management，用一个 Manage-Execute-Audit loop 来拆分角色。

第一步是 Manage。manager 维护显式 task state，决定下一步子任务。它不只是继续聊天，而是更新一个结构化的任务状态。

第二步是 Execute。executor 用 fresh context 执行当前子任务。这很关键，executor 不需要背着全部历史包袱，它只拿到当前要做的事情和必要状态，减少上下文污染。

第三步是 Audit。auditor 是只读角色，只根据环境事实验证执行结果，比如文件是否真的存在、测试是否真的通过、界面是否真的变化。只有被环境独立验证过的事实，才会写回任务状态。

这套设计的核心是把“模型自我感觉”换成“环境可验证状态”。Agent 不再说“我觉得做完了”，而是必须让 auditor 看见证据。

论文给出的结果也说明这种 harness 改动很有价值。LongHorizon-Harness 把 Qwen 3.7-Plus 在 WeaveBench 上从 51.8% 提到 80.7%，Terminal-Bench 2.1 从 69.7% 提到 77.2%，OSWorld 2.0 从 2.8% 提到 8.3%。Claude Opus 4.7 在 OSWorld 2.0 子集上也从 20.0% 提到 34.3%。这不是换模型，而是换运行方式。

它和最近几条线能连起来看。OpenAI 在 ARC-AGI-3 上发现 harness 设置能让分数大幅提升；LangChain Deep Agents v0.7 在做上下文减肥；Stripe Kai 用虚拟文件系统、沙箱和 summarization middleware 管理企业 Agent；GPT-Live 把实时语音状态和异步工具调用拆开。大家都在回答同一个问题：模型之外的运行系统，正在成为能力的一部分。

对开发者来说，这篇论文的启发很直接：

• 长任务不要只依赖聊天历史。
• 关键状态要结构化、外置、可更新。
• 执行器可以短上下文运行，避免被旧错误污染。
• 完成判断要由环境验证，而不是模型自己说了算。
• 日志、文件、测试、页面状态、数据库结果都应该成为 auditor 的证据源。

我的判断是，Agent harness 会从“prompt + tool loop”进化成“小型操作系统”。它需要状态管理、任务调度、审计器、权限边界、记忆层和错误恢复机制。模型仍然是大脑，但如果没有可靠的状态系统，大脑会在长任务里迷路。

LongHorizon-Harness 最好的地方，是它把问题说清楚了：长任务 Agent 的记忆不应该只存在上下文里，而应该存在一个可验证、可审计、可修正的外部状态里。

参考来源：LongHorizon-Harness: Advancing Long-Horizon Agents for Real-World Tasks。