昨天下午，我给开源 Agent 派了一个跨应用重构的活。本以为睡一觉起来能直接收工，结果早上睁眼一看，终端还卡在第47步死循环里，Token 烧了七十多块钱，最后卡死的原因居然是网络闪断。

这种抓狂的经历相信写过 Agent 任务的人都深有体会。其实问题并不是模型不够聪明，而是当前的 Agent 缺少一个能够面对长周期任务的运作机制。

在长任务场景下，现有的 Agent 架构普遍存在三个致命的结构性缺陷。第一个缺陷是上下文漂移（Context Drift）。随着执行步骤拉长，对话历史会像滚雪球一样越来越多。这种冗余导致原本的目标在长对话中被稀释，Agent 终极目标慢慢就跑偏了。

其次是状态丢失（No Checkpoint）。

现在的任务状态都存在对话内容 and 临时内存里，缺乏一个能跨 Session 留存的独立任务状态机制。这导致一旦网络断连或模型崩溃，整条执行轨迹必须推倒重来。

而第三个缺陷是自验证偏差（Self-Evaluation Bias），也就是自己既当裁判又当运动员，哪怕文件写错了或者测试没过，它也能强行自我宣布任务圆满完成。

针对这些痛点，高德团队开源的 LongHorizon-Harness 给出了另一个解法：不是让 Agent 更聪明，而是限制它的权力。

为此，它在系统中设计了由 Manager、Executor、Auditor 组成的多角色协作系统，并且引入了“GUI/CLI双轨执行”与“人机门禁（Human Gate）”机制。

双轨执行：任务状态控制器

这套系统底层的双轨执行机制极其硬核。

调度核心 Manager 本质上扮演了任务状态控制器的角色。

它不仅负责拆解目标、定义每一步的执行契约，还会根据以往的所有审计报告，智能决策下一步是分发给 CLI 轨道（跑终端、命令或文件）还是 GUI 轨道（操作桌面 App 或浏览器）。

为了防止对话上下文无限膨胀，它只读取上一轮的契约和 Auditor 的只读审计报告，自己绝对不能操作系统终端或修改文件。

执行器：一次性临时工

执行具体任务的 Executor 则定位为“一次性临时工”。

它根据 Manager 派发的单步 CLI 或 GUI 契约，在完全隔离的全新上下文里启动。一旦单步任务跑完，其历史执行记录立刻被销毁，只向后递交一份执行摘要。为了让审计绝对客观真实，系统引入了独立且禁写了修改工具的 Auditor 角色。系统会在执行前后对全局工作区做物理级的文件快照对比，一旦发现哈希变动即判定为验证污染（Verification Contamination），并强行把步骤判定为 incomplete 并进行回滚，杜绝了蒙混过关的可能性。

审计员：客观守门人

细化到数据契约上，Auditor 输出的报告必须带有严格的三行控制头（Control Headers）。

这三行分别标志了当前的任务状态（Status）、数据完整性（Integrity）和契约对齐度（Contract audit）。如果控制头错误或缺失，系统会启动重新规划来纠正。

只有在三项指标均显示正常时，系统才会将其归档为 Checkpoint 供后续回滚；如果是失败的段落，只会留作下一步 Manager 规划时的上下文证据，不会推进全局进度。

人机门禁：该停就停

除了自动控制，系统在轮次结束时还留有重要的人机干预门禁（Human Gate）。

通过在运行中插入 human_hook，当遇到运行轮次超配、Manager 报告 blocked 无法推进、或是发生连续重复失败时，系统会在本地的 FastAPI 与 React 网页工作台上自动暂停，允许人类介入。操作员可以在可视化面板上直接阅读多 Round 的规划与审计结果，选择动态追加配额注入新指令支持其 continue 运行，或者直接执行 stop 中断。

与传统 Agent 的本质差异

这种多角色闭环，与现有的 Claude Code 或 Codex 有着本质不同。

传统 Agent 遵循的是以模型为中心的循环——单模型包揽规划、操作和自己确认。

而 LongHorizon 则是以任务为中心的循环，把状态和验证剥离到外部。底层Codex当做执行器

• 状态管理：传统 Agent 依赖会话上下文，LongHorizon 依赖外部持久化的状态表（Task State）
• 确认机制：传统 Agent 由模型自我宣布完成，LongHorizon 必须经由 Auditor 进行独立差分哈希验证
• 异常恢复：传统 Agent 出错后需要人工引导或重新建立对话，LongHorizon 具备物理 Checkpoint 可直接恢复
• 执行模式：传统 Agent 使用连续会话大上下文，LongHorizon 动态销毁执行器历史并进行状态摘要压缩（State Compression）

核心认知：工程问题，不是智力问题

传统 Agent 的底层运行机制正在发生质的转变。

过去大家觉得有一套大模型加上 Prompt 和 Tools 就能解决问题。

但真正在复杂工程里落地时，才发现稳定的任务调度框架、独立的校验审计以及物理级状态管理缺一不可。

同样的 Qwen 3.7-Plus 模型搭载 Claude Code 后端，套上 LongHorizon 框架后，WeaveBench 的通过率从 51.8% 提升到了 80.7%，而在 OSWorld 2.0 上的任务完成数更是取得了三倍的增长。

这不是模型变强了，是架构变稳了。

未来 Agent 的进化，比拼的可能客观上不再是单模型纯智力，而是谁能给 Agent 搭建一套生产级的工作运行守护系统。

不过 LongHorizon 并不是解决长程任务的终极方案。

作为一个新项目（v0.1.4，今年8月刚刚发布），它仍有未开发的空白地带。

比如在多 Agent 协同下的状态同步、企业内部复杂知识的高效检索记忆、敏感接口的权限治理，以及长周期目标动态调整上，都还有很长的路要走。

未完成的拼图

但作为一个方向，大模型想要从“聊天玩具”变成“可靠劳动力”，这套为管理任务状态而设的外部框架显然迈出了扎实的一步。

项目地址：https://github.com/AMAP-ML/LongHorizon-Harness论文：https://arxiv.org/abs/2608.01964