让 AI Agent 干一件「几小时才能干完的活」，你会看到两种结局：要么它干得比人还稳，要么它跑到一半开始摆烂——忘了最开始的目标、重复做已经完成的事、把之前弄好的部分改坏。大多数团队遇到的是第二种。
这种需要长时间、多步骤、有依赖关系的任务，工程上叫长时任务（long-horizon task）。它跟单轮问答完全是两码事。最近微软和南京大学发布的 LoopsBench 基准给了一个扎心的数据：当前最强的 AI 编程 Agent 配置，跑长周期任务的成功率只有 25%，四分之三的长任务完不成。长时任务，才是 Agent 落地真正的门槛。
好消息是，长时任务翻车是有规律的，大部分坑都能用工程手段填平。这篇把长时任务设计的五个核心动作讲清楚。
先搞清楚：长时任务到底难在哪
长时任务和单轮问答的区别，不是「内容变多」，而是「有了时间维度」。任务一长，四个问题同时出现：一是目标漂移，干着干着忘了最初要什么；二是状态累积，已经完成的模块越多，要维护的正确状态就越多；三是依赖错乱，分不清哪些事能并行、哪些必须等前面的完成；四是回归风险，改了新的，把旧的弄坏了。
这四个问题单独看都不难，合在一起就是大麻烦。所以长时任务设计不是某一个技巧，而是一整套「别让 Agent 跑偏」的工程纪律。
解法一：任务拆解，把大任务切成有依赖关系的小块
长任务最大的敌人是「一口吞」。正确做法是先拆：把大目标拆成一组可以独立验证的子任务，再标出它们之间的依赖关系——哪个必须等哪个、哪些可以并行。
拆的时候记住一条原则：并行不是越多越好，而是要匹配真实依赖。把没有依赖关系的任务压成一条串行链，浪费算力；把有前置依赖的任务强行并行，必翻车。任务拆解的思路，和 AI Agent 上下文管理 里说的「分层」一个道理——先有结构，才谈得上管理。
解法二：进度检查点，让每一步都有据可查
长任务跑起来以后，最怕「黑箱」：Agent 干到哪了、完成没完成、卡在哪，全凭猜。解法是设检查点：在关键节点（每个子任务完成时、每个阶段结束时）强制记录状态——已完成、进行中、阻塞、待办，以及每项的证据。
检查点不是记给 Agent 看的，是记给人看的。出了问题能回放、能定位，这就是 OpenClaw 回放对照 那篇讲的逻辑：同一任务别只看最后一次结果，过程要对得上。检查点记录得越细，长任务越可控。
解法三：状态持久化，跨轮次别失忆
长任务通常要跨多轮执行，甚至跨会话。每轮都从零开始，就是灾难。解法是把状态持久化：当前目标、已完成清单、当前假设、下一步计划，全部存到 Agent 外部，每轮开始先恢复状态再动手。
存的时候别只存结论，要把证据一起存——为什么这么做、依据是什么。这和 AI Agent 证据包怎么留 是同一个原则：状态可追溯，Agent 才不会把「以为完成」当成「真的完成」。
解法四：回归保护，别改了新的弄坏旧的
长任务越往后，越容易出现一个阴险的问题：Agent 为了完成新功能，把之前已经做好的部分改坏了，而且它自己不知道。原因很简单——它只验证了新功能，没复测旧功能。
解法是回归保护：任何一次修改之后，把「已完成的子任务」也纳入验证范围。改了多少，就复测多少。这其实就是 质量门禁 和 变更后验证清单 的组合用法：放行新改动之前，先确认旧成果没被破坏。宁可慢一点，别让 Agent 白干。
解法五：中断恢复，停下来还能接着跑
长任务一定会中断：token 耗尽、会话超时、Agent 自己觉得「干完了」提前收工。LoopsBench 的实验显示，光是加一个「外部续跑」机制，成功率就能从 16.96% 提到 25%——相当一部分任务没完成，纯粹是因为 Agent 提前停了。
所以长时任务必须设计恢复机制：中断后能接着跑，而不是从头再来。恢复时要告诉 Agent 三件事——已完成什么、当前停在哪、哪些约束必须保持。如果任务实在跑不下去，就按 失败升级规则 升级给人工，别让它无限重试死循环。
适合人群与落地建议
长时任务设计值得投入的，是所有让 Agent「连续干活」的团队：AI 编程 Agent、数据整理流水线、跨周项目跟进、长时间运行的业务流程。如果你的 Agent 只做单轮问答，可以先不动这套。
落地顺序从便宜的开始：先做「进度检查点」——成本最低、收益立竿见影；再做「回归保护」，把已完成的成果钉住；然后上「状态持久化」和「中断恢复」，解决续跑问题；最后才优化「任务拆解」策略。别一上来就上重装备。
总结
AI Agent 长时任务设计，核心五招：任务拆解匹配真实依赖、进度检查点让过程有据可查、状态持久化让跨轮不失忆、回归保护别弄坏旧成果、中断恢复让任务能接着跑。记住一句话——长时任务的胜负手不在模型多聪明，而在系统能不能让 Agent 稳定地把活干完。就像 AI Agent 评测怎么做 那篇说的：能跑多远、为什么停在那里，比跑没跑完更重要。
