原文参考：Justin Young, “Effective harnesses for long-running agents”。本文是原创解读，不是直译。

长时任务 Agent 真正缺的不是智力，而是交接、恢复与验收能力

如果你最近半年认真折腾过长时任务 agent，大概率会有一种很熟悉的崩溃感：它不是完全不会做，甚至常常一开始还做得挺像那么回事，但只要任务一拉长、会话一切换、上下文一重置，整个系统就开始松掉。

你会看到一些极其典型的场景：第一次会话像个天才，第二次会话像个实习生；明明写了很多代码，但你问”现在到底完成没”，没有人说得清；任务列表看起来一直在推进，结果真正该做的验收没做；代码改动很多，可一跑全流程，前面做的事跟后面根本接不上；每一轮 agent 都很努力，但整个项目没有形成一个可持续累积的结构。

这类问题，很多人第一反应会怪模型：上下文不够、推理不稳、工具用得不准。但 Anthropic 那篇《Effective harnesses for long-running agents》最有价值的地方，就是它把问题往前推了一层：长时任务 agent 的核心挑战，根本不是”让模型一次工作更久”，而是”如何让工作在多轮之间接得住”。

我几乎可以把这当作这一波 agent 工程里最重要的现实判断之一。因为今天大量系统还在错误地把”长时任务”理解成”超长单轮”。而真正进入工程现场后你会发现，复杂任务从来都不是靠一口气跑完的，它更像项目执行——必须能切分、能恢复、能交接、能验收、能继续。

所以，如果一定要把这篇文章的核心思想压成一句话，我会写成这样：

长时任务 agent 的竞争，不是谁的一轮更神，而是谁的多轮结构更稳。

一、为什么长时任务 agent 会反复死在”看起来快成功了”这一步

这篇文章开头最触动我的地方，不是它给了什么新框架，而是它准确描述了一类大家都见过、但很难总结清楚的失败模式：agent 看起来一直在干活，甚至一直在”有进展”，但最后你会发现系统并没有真正完成任务。

这其实是一种非常危险的错觉。

因为显性失败反而容易处理：报错、退出、崩溃、权限不足，这些都很好识别。最可怕的是那种假性成功：页面似乎改好了、文件似乎写出来了、某个测试似乎过了、backlog 似乎往前挪了、agent 自己也很自信。

但只要你换个视角检查，问题就出来了：真正的用户路径没跑、多轮上下文没接住、之前失败的尝试没人记录、当前改动破坏了系统别处、“完成”只存在于 agent 的叙述里，不存在于可验证的事实里。

这就是长时任务 agent 和单轮 assistant 最大的区别。单轮回答错了，通常只损失一次输出；长时任务如果一边错一边继续推进，最后会积累出一整片表面繁荣的废墟。

我越来越觉得，很多团队今天吃的最大亏，不是模型太弱，而是系统太容易制造这种”近似完成”的幻觉。

二、长时任务不是长上下文问题，而是长周期执行问题

很多人看到这类问题，第一反应都是继续加 context：用更长上下文窗口、保留更多历史消息、让 agent 记住更多中间过程、尽量别重置会话。

这些做法有时有帮助，但我认为它们经常把问题看偏了。

因为长时任务的真正难点，不在于”记住得更多”，而在于”如何让工作结构跨轮次保持一致”。

这也是为什么我很认同文中那种 implicit 的判断：长时任务更接近 long horizon execution，而不是 long context prompting。

两者的差别非常大。

如果你把问题理解成 long context，你的思路通常会是：怎么把更多东西留在上下文里、怎么让模型别忘、怎么减少会话切换、怎么延长一次执行周期。

但如果你把问题理解成 long horizon execution，你的思路会变成：如何把大任务切分成稳定的小阶段？如何让当前状态沉淀成可读的工件？如何让下一轮快速定位现状？如何让每轮的边界清晰可见？如何在结束时留下干净的交接结果？如何把验证真正绑定到”完成”的定义？

前一种思路，是在努力延长一次思考；后一种思路，是在设计一个可持续的工作系统。

我认为后者才是真正有前途的方向。

三、initializer agent / coding agent 的拆分，为什么看起来朴素却极其重要

文章里有一个我非常认同的模式：把首次进入项目的工作，和后续持续推进功能的工作，拆成不同角色。

这件事很多人会低估，觉得无非就是 TODO 列表，没什么好特别强调的。但在我看来，这几乎是长时任务 agent 能不能真正可续跑的核心分水岭。

因为它解决的不是”列几个待办事项”，而是建立一个feature contract。

所谓 contract，意思不是它长得像文档，而是它承担了合同式约束作用：哪些 feature 算在任务范围内、每个 feature 的完成标准是什么、哪些 feature 当前没过、哪些 feature 已通过验证、后续轮次是否允许擅自改写定义。

没有这种 contract，任务就会迅速漂移。agent 每轮都根据自己当下看到的东西重新解释需求，系统看起来在推进，实际上一直在变题。

为什么很多 agent 项目最后会变成”做了很多，但没做对”

因为它们从来没有稳定的 feature contract。于是需求边界越来越模糊、完成定义越来越主观、agent 每轮都在用自己的语言重写问题、团队也越来越难知道，到底哪些事是真的完成了。

为什么 JSON 这种格式反而更适合 agent

文章提到 JSON 比 markdown 更稳定，我非常认同。不是说 markdown 不好，而是在 agent 连续读写场景里，结构化字段真的有巨大优势。

Markdown 适合人读，JSON 更适合机器连续更新和校验。尤其当你需要明确标记 feature_name、description、verification_steps、status、passes 这些字段时，稳定数据结构远比”看起来好看”更重要。

我甚至想进一步说：未来很多成熟 agent 工作流，都会越来越像”代码 + contract + verification artifacts”的组合，而不只是”聊天 + 工具调用”。

四、progress file 的真正意义：不是记日记，而是降低认知重建成本

文章提到 claude-progress.txt 这种进度文件时，我觉得它说中了长时任务里一个非常现实、但经常被忽略的问题：每次重新接手任务时，最大的浪费不是写代码，而是重建理解。

一轮 agent 做完后，如果什么都不写回去，下一轮就必须重新搞清楚：仓库当前状态如何、上一轮做了什么、哪些文件被改了、哪些尝试失败了、还有什么没做完、接下来最值得做什么。

这些问题每轮都靠代码 diff 和会话残留去猜，成本非常高，而且误差很大。

一个好的 progress file，本质上是在给未来的 agent 留”交接笔记”，而不是在给过去做纪念册。它真正的功能不是记录历史，而是压缩接手成本。

进度文件最重要的不是完整，而是高价值可接续

我觉得很多团队会在这里犯一个错误：以为 progress file 要写得非常详尽，像日报一样罗列一切。其实不是。对长时任务 agent 来说，进度文件更像是一段高价值的 handoff memo。它应该优先保留以下信息：当前最可信的系统状态判断、这一轮完成了什么、哪些尝试失败过、失败的原因是什么、哪些地方不要重复踩坑、下一轮应该从哪一个 feature 接着做。

这些内容比”今天跑了几个命令、编辑了哪些段落”更有价值。

也正因为如此，我越来越觉得 context compression 最有用的形式，很多时候不是对聊天历史做摘要，而是把真正有用的状态直接沉淀成文件。

五、为什么”每轮只做一个 feature”是长时任务里最重要的范围纪律

文章里我最喜欢的一条建议，是后续 coding session 每次只做一个 feature。

很多人刚看到这条时会觉得保守，甚至会有点嫌慢。毕竟既然是 agent，为什么不让它多做几件、提高吞吐？

但真正做过几轮之后你会发现，这条建议几乎是长时任务 agent 的生存法则。

因为 agent 一旦在一轮里同时推动多个目标，就会同时污染好几层状态：上下文被多任务交错、验证范围变模糊、提交边界变脏、出错之后很难知道哪一步导致系统坏掉、下一轮接手的人也很难知道此刻最该继续什么。

单 feature 不是为了慢，而是为了让进展真实可累计

一个 feature 一次做完的好处非常具体：工作边界清楚、成功标准明确、验证路径可控、git diff 易于理解、回滚更容易、交接更干净。

这其实就是经典软件工程里”小步迭代”的逻辑，只不过 agent 更需要它。因为人类开发者即使同时处理多个问题，仍然有稳定的全局心智模型；agent 没有那么强的持续全局把握能力，所以更需要强约束来帮它保持轨道。

很多团队对 agent 最大的误解之一，就是以为它越 autonomous，就越适合大包大揽。实际上恰恰相反：越 autonomous，越需要范围纪律。

六、真正让”完成”这个词成立的，不是改动，而是验收

这篇文章让我特别认同的一点，是它对”完成”这个词的警惕。

在 agent 场景里，“完成”是最容易被滥用的词之一。因为 agent 非常擅长给出一种叙述上的完成感：功能已经实现、页面已经改好、测试已经通过、逻辑已经支持、下一步建议如何如何。

问题在于，这种完成感经常只是 narrative completion，不是 verified completion。

文章给的两个建议——启动前跑 smoke test、完成前做 browser verification——在我看来不是细节建议，而是长时任务 harness 的核心原则。

1. 启动前先做 smoke test，本质是在确认”你接的是活系统”

每一轮开始新工作前，先确认系统还活着，这一点太重要了。否则你很可能是在一个已经悄悄坏掉的环境上继续堆代码。

很多 agent 项目之所以越做越烂，不是因为后面的功能写错了，而是因为它们不断在坏状态之上叠新工作。你一旦不先确认基线健康，后面所有”新增进展”都可能是建在漂浮地面上的装修。

2. browser verification 不是锦上添花，而是把”用户真的能用”变成可验证事实

特别是 Web 场景，只靠 unit test 和局部命令远远不够。真正的用户路径，常常卡在组件组合层、路由跳转层、加载时序、浏览器行为、真实点击路径。

如果不做 browser-level 验证，“完成”很多时候只是代码层完成，不是产品层完成。

这也是为什么我越来越倾向把 verification 看作 harness 的硬约束，而不是开发末尾的礼貌步骤。礼貌步骤可以跳，硬约束不能跳。

七、真正可用的长时任务 agent，必须把”恢复能力”设计进去

我觉得这篇文章最容易被低估、但实际上最重要的一层，是它隐含地把”恢复”放到了系统中心。

很多人设计 agent 时，会把主要精力放在：如何让它做对、如何让它更快、如何让它用更多工具、如何让它少报错。

这些当然重要。但长时任务真正决定系统可用性的，往往是另一件事：出错后还能不能回到正轨。

因为长任务不可能不出错。现实里一定会遇到：上下文漂移、误判任务范围、写坏某个文件、环境突然不健康、工具调用失败、验证发现前面有问题。

这时候，真正成熟的系统不会把”不要犯错”当核心幻想，而是把”出错后还能恢复”当设计前提。

所以你会发现，文章里那些看似朴素的东西——git commit、progress file、feature JSON、smoke test、browser verification——其实都在为恢复能力服务。

它们共同构成的不是一个花哨 agent demo，而是一套可恢复工作流。

八、真正成熟的长时任务系统，最后拼的不是谁能不停跑，而是谁更会在合适的地方停下来

很多人对 long-running agent 的想象还是”越能持续跑越好”。但从工程角度看，我反而越来越觉得，真正成熟的系统不是最会一直跑的系统，而是最会在合适边界停下来的系统。

因为：该验证时不停，会制造错误积累；该交接时不停，会制造状态混乱；该回退时不停，会扩大事故范围；该让人接手时不停，会把修复成本抬高。

所以长时任务 agent 的成熟，最终不是”连续性无穷大”，而是”连续性和边界感同时存在”。

这一点特别像成熟工程团队的工作方式：真正强的团队，不是一直狂奔的团队，而是知道什么时候该继续、什么时候该验证、什么时候该切分、什么时候该停下来交接的团队。

我觉得 agent 也会越来越沿着这个方向进化。

九、一个可交接 agent workflow 的最低配置，到底应该长什么样

如果把这篇文章的所有建议压缩成一个真正可落地的最低配置，我会把它写成下面五件事。不是因为这五件事已经完美，而是因为少了其中任意一个，长时任务系统都很容易重新滑回”忙碌但不积累”的状态。

第一，task contract——先把范围锁住。没有 contract，后面所有连续执行都会不断重写问题。

第二，progress artifact——不是为了记录历史，而是为了让下一轮知道现在站在哪里。

第三，feature state——每个 feature 当前到底是未做、进行中、局部通过，还是已完成并验证，必须有清晰状态。

第四，validation step——每轮结束前必须留下真实验证痕迹，而不是只留下 agent 的叙述。

第五，clean handoff boundary——每轮必须有一个明确停止点：下一轮从哪进、先看什么、最该做什么。

我很喜欢用”最低配置”这个说法，因为它能提醒团队：连续执行的关键，不是先上最复杂系统，而是先别缺那些一缺就会反复翻车的基础件。

结语：真正成熟的 long-running agent，不是一直在跑的 agent，而是一直能把工作边界交代清楚的 agent

如果我要给这篇文章最后留一句最适合收尾的话，那会是：

一个 long-running agent 最终值不值得被信任，不在于它跑了多久，而在于它在每一个交接点，是否都还能把当前工作边界交代得足够清楚，让下一轮不用靠猜继续。

我觉得这就是长时任务 agent 真正会拉开差距的地方：不是连续输出本身，而是连续输出中始终没有丢掉可交接性。

---

谁应该读这篇

这篇适合下面几类读者：

• 正在尝试让 agent 持续做数小时或跨多会话任务的工程团队
• 正在设计 Claude Code / Cursor / OpenHands 类 coding workflow 的人
• 已经被”看起来快完成了但其实没完成”折磨过的人
• 想把 agent 从 demo 推向真实工程协作的人
• 对任务交接、恢复、验证设计有强烈痛感的 AI 工程师