当任务跨度从几分钟拉长到十几个小时，决定智能体成败的不再是提示词写得多漂亮，而在于有没有一个足够稳健的运行时底盘。

Agent跑了12小时，然后忘了自己在干嘛

上个月，我让Agent帮我重构一个跑了两年的老项目。

前一个小时，它表现得像个认认真真的实习生。拆模块、理依赖、写测试，一气呵成。我切到别的工作窗口，心想这活儿今晚就能收工。

到了三个小时后，我回来看终端输出，整个人愣住了。

它把上午刚写好的核心路由模块删了，又从零开始重写了一遍。新写的版本跟三小时前的几乎一模一样，但是把接口签名全改了，下游十几个调用点全报了错。我问它为什么这么做，它在终端里一本正经地返回了一句「根据当前上下文分析，该模块尚未实现」。

它跑了三个小时之后，彻底忘了自己三小时前干过什么。

权威机构METR的实测显示，2026年前沿智能体的任务完成时域已经从秒级推到了12到16小时，翻倍周期从6.5个月加速到了4.3个月。听起来进展飞快。

但这串数字背后藏着一道明显的断崖。时间跨度拉长了，可靠性并没有等比例跟上来。让它跑12小时，它确实能跑完全程，但交付出来的代码到底能不能用，实际通过率依然让人头疼。

更扎心的是成本消耗。人类工程师1小时搞定的活，Agent要花掉10倍以上的Token预算。上下文像滚雪球一样膨胀，算力烧进去了，活儿还没干利索。

单次推理能力再强，如果没有一套承载长途运行的底盘系统，任务一拉长必然散架。

最近中国人民大学高瓴人工智能学院团队发布了一篇149页的综述《迈向长程智能体》（Towards Long-Horizon Agents）。读完之后我发现，他们把长程任务中常见的翻车场景，从底层运行机制到系统解决方案，梳理得十分透彻。

AI Agent能跑12小时，为什么还是干不了活？《迈向长程智能体》人大高瓴149页重磅综述解读​

目标漂移、上下文腐烂与稀疏奖励

很多人第一反应会觉得，模型参数越大、上下文窗口越长，Agent 就能跑得越久。

实际跑起来往往相反。

综述把 Agent 在长程任务中容易掉链子的原因，归结为三个关键机制。

目标漂移。 让 Agent 去重构一个大型仓库，前 200 步思路清晰，到了第 800 步，它突然开始脱靶，把前面验证通过的代码当成垃圾删掉。其实是前面几百步累积的细微误差，随着执行步骤增加被成倍放大，导致最终偏离了原始目标。

上下文腐烂。 给模型塞进 100 万 Token 的上下文，并不意味着它能全部消化。学术界早就发现 Lost in the Middle 现象，模型对长文本中间段落的注意力衰减极快。执行过程中大量无用的终端输出和调试日志把核心信息淹没了，上下文越长，噪声干扰越严重。

稀疏延迟奖励。 Agent 连续跑了 500 步，中间没有任何报错提示，走到终点才发现第 12 步传错了一个环境参数。要修正就得推倒重来，前面 500 步的计算开销全都打了水漂。这种只能在最后判定成败的反馈方式，在长程场景下极其脆弱。

单步看来微不足道的偏差，在漫长的执行轨迹里，都会产生复合破坏力。

H1到H3三级分层，长程取决于逻辑依赖深度

综述对长程任务给出了一个很实在的界定。

它不单看跑了多少分钟，也不单看消耗了多少 Token，而是看任务内部各步骤之间的逻辑依赖有多深、多紧密。

综述把任务复杂度分成了三个台阶。

H1 属于单窗口短跑。 分钟级的局部操作，在一个上下文窗口内就能完成。比如写个独立函数、排查一个明确的报错，主流模型目前都能较好地胜任。

H2 属于跨会话状态接力。 小时到天级的连贯任务，必然要跨越多个上下文窗口。比如重构整个系统的模块划分，Agent 需要在不同会话间维持架构记忆，追踪依赖变化，并记住自己之前的取舍。目前大多数系统一到这个阶段就会频繁翻车。

H3 属于开放式终身自演化。 面对没有固定终点的开放任务流，Agent 需要从过往经历中自动提炼通用技能，沉淀出技能库，并在后续新任务中自我迭代。目前工业界在 H3 层面尚处于起步摸索阶段。

用一个生活场景来比喻。H1 相当于在一张桌子上把事情做完，H2 相当于在几个房间之间来回搬运和协调物料，H3 则相当于一名学徒在漫长职业生涯中持续积累手艺。

一旦跨入 H2 和 H3，单靠模型本身的单步预测已经兜不住了，必须靠整套系统工程来支撑。

模型是发动机，Harness负责托起整台车

综述提出了一个核心结构。

长程能力 = 基础模型 + 运行时系统 Harness

两者缺一不可，相互配合演进。

大模型就好比一台大马力发动机，负责提供每一步的推理动力。但只有发动机无法直接上路，跑长途还需要稳固的底盘、变速箱、刹车系统与油路调度。

模型决定单步输出的质量，Harness 则负责把状态持久化下来，调度多步骤流转，并在出错时提供回滚与安全拦截机制。

如果把 Harness 拆解到实际工程中，它就像米其林后厨的协作体系。执行流 Loops 相当于后厨排单表，控制做菜顺序。上下文 Context 相当于备菜冰箱，管理原料保鲜与取用。工具链 Tools 相当于灶台与刀具。多智能体 Orchestration 相当于前厅与后厨的传菜配合。安全钩子 Hooks 相当于卫生质检员。过程验证 Verification 则相当于主厨在出餐前的每道菜试吃。

后厨运转良好，顶级厨师的厨艺才能稳定发挥。这个逻辑放到 Agent 系统里完全相通。

从写提示词到搭运行时框架

回顾大模型落地的演进过程，过去几年行业里经历了三次明显的重心转移。

2020 年到 2023 年是提示词工程阶段。人与模型的沟通主要依赖自然语言微调，大家比拼思维链设计、Few-shot 样本编排与各种提示词模板。

2023 年到 2025 年进入上下文工程阶段。光靠调提示词已经解决不了复杂问题，行业开始普及 RAG 检索增强、Function Calling 与结构化输出，把模型作为核心组件嵌进信息流管道。

2025 年至今，重心全面转向运行时 Harness 工程。类似 Cursor、Devin 以及各类长程代码助手，核心竞争力已经转移到背后的运行时设计上，比如状态管理是否精细，分支探索是否高效，出错后能不能平滑自愈。

长程任务能不能稳定交付，关键考验的就是运行时系统的工程深度。

真正影响实操的四大机制

在 Harness 的诸多组成部分里，有四个模块对日常开发效果影响最为直接。

执行流，从单线跑到底到假设树探索

传统的 ReAct 循环是单线前进的，想一步，做一步，看一眼结果。只要中间有一步走岔，后面就会全盘崩塌。

现代长程架构在此基础上加入了更强的分支机制。

一方面引入类似 Arbor 的假设树搜索。Agent 遇到复杂决策时，可以像下棋一样向外展开分支探索。一旦发现死胡同，主动修剪无效路径，回溯到上一个合理的决策节点重新尝试。

另一方面采用 Maker-Checker 双轨协作。一个 Agent 专门负责生成具体方案，另一个 Agent 独立站在质检角度挑毛病。生成与检查拆开之后，低级逻辑错误明显减少。

工具链，MCP加上CodeAct沙箱调度

如果执行一个复杂任务需要串行发起 50 次外部工具调用，每次调用都把完整入参和回包塞回模型，上下文很快就会被撑爆。

更高效的做法是采用 MCP 协议规范接口，并结合 CodeAct 方式让 Agent 在沙箱里直接编写 Python 脚本。脚本在沙箱内单帧批量完成数据抓取、清洗与矩阵计算，只把精炼后的最终结果回传给上下文。

实测数据显示，这种方式能把冗余的 Token 消耗压降 80% 以上。

记忆管理，丢弃比保留更重要

面对长程记忆，很多人的习惯是尽可能把所有交互细节存下来。

但是在多轮长任务里，学会主动丢弃无用信息反而更为关键。

合理的做法包含三道工序。

第一道是丢弃，子任务一旦完成，立刻清理掉大段调试日志和中间临时文件。第二道是压缩，把几百轮交互流水折叠成结构化的事实依赖图谱。

第三道是按需选择，当前动作需要哪块背景，就定向检索关联片段。

把过期杂物及时清出工作台，核心事实才能保持清晰。

过程验证，装上实时导航仪

传统做法往往等到最后执行测试用例才判定结果，很容易在跑了几百步之后才发现早就偏航。

PRM 过程奖励模型改变了这种后验模式。它在执行的每一个关键动作节点打分，评估当前状态距离最终目标的推进质量。

当监测到得分异常下跌，系统会在第一时间触发回滚，切换候选路径重试，阻止错误继续向后扩散。

高频的过程把关，能显著改善长程任务的终点成功率。

先搭脚手架，再把能力蒸馏内化

把 Harness 这一套工程搭起来之后，下一步该怎么走？

综述给出的技术路线很明确。

先用完善的外部 Harness 作为工程脚手架，把长程任务跑顺，在这个过程中沉淀出大量高质量的真实执行轨迹。

随后通过 On-Policy 蒸馏或强化学习，把外部脚手架验证过的策略模式逐步蒸馏到模型权重中。

当基础模型内化了这些长程规划与自愈习惯，外部 Harness 就可以适度做减法，整体调用延时和推理成本也会同步下降。

Anthropic 在其工程指南中也表达过类似的观点，先搭好脚手架把业务跑通，再把验证过的能力逐步沉淀。不用干等所谓的终极模型出现，现在就该用合理的运行时去落地。

如果面对的是数小时级别的 H2 任务，做好主动丢弃、沙箱批量代码调度与双轨验证，就能建立起比较可信的生产管线。

撕开滤镜，聊聊目前真实存在的局限

综述梳理了大量方向，但在实际落地时，我们依然需要看清客观限制。

100 小时以上的任务仍然处于无人区。METR 的评测数据主要集中在 12 到 16 小时区间。任务时间进一步拉长之后，系统在跨天运行下的稳定性究竟如何，行业内尚缺乏充分的实测样本。

H3 终身学习目前缺乏规模化的工业实证。让 Agent 长期自主学习并跨任务演化，在学术上有很高的研究价值，但在严谨的企业级生产中，几乎还没有成熟方案能够直接开箱投产。

行业内各家系统的 Harness 实现仍然比较分散。不同产品虽然都在做状态管理与执行调度，但底层接口和设计理念各不相同，现阶段很难找到一套放之四海皆准的标准模版。

这篇综述真正的价值，在于给出了这样一张清晰的路线地图，标明了哪些技术手段已被证实有效，哪些假设仍需审慎求证。

对于工程开发而言，优先把 H2 级别的状态控制与过程验证做扎实，跑顺小时级的任务流，才是当下最具确定性的发力点。

你平时使用 Agent 处理长任务时，一般最长能稳定运行多久，通常在哪些环节容易出现偏差？欢迎在评论区分享你的实际体验。

参考来源

• 综述论文 Towards Long-Horizon Agents: A Survey (RUC GSAI, Preprints.org 2026-07-17, DOI 10.20944/preprints202607.1328.v1)

• 开源资源库 GitHub RUC-NLPIR/Awesome-Long-Horizon-Agents

• 任务时域评测 METR Task Horizon Scaling 公开数据

• 工程指南 Anthropic: Building Effective Agents