多步任务为什么不能只在当轮写计划：update_plan 跨轮持久化的价值

多步任务最容易失败的地方，往往不是某一步执行报错，而是任务一跨轮、上下文一变长，系统就忘了自己原本打算怎么完成它。先说结论：如果一个 AI 助理只在当前这一轮临时写计划、下一轮又靠“重新理解上下文”继续，那么长任务几乎必然越来越漂；真正稳定的做法，是把计划作为跨轮持久化状态保存下来，并在每完成一步后显式更新。这正是 GoWork 里 update_plan 的价值。

对执行型 AI 来说，计划不是给用户看的装饰，也不是模型的思维草稿。计划本质上是任务的外部状态：它告诉系统已经做了什么、接下来该做什么、哪些结果已经验证、哪里发生了偏航。如果这层状态不能跨轮保存，那么每次续跑时，系统都得重新从聊天记录里“猜”任务主线，结果就是步骤顺序变形、已完成动作被重复执行、验证结论被忘掉。

如果你已经看过为什么 AI 助理应该在聊天里回答“任务到哪了”、失败后别重来：让 AI 助理从上次进度继续和追问之前先回忆：什么时候该读记忆，什么时候才该向用户补问题，这篇文章继续回答一个更底层的问题：为什么多步任务不能只在当轮写计划，而必须把计划跨轮持久化？

先给结论：长任务的真正问题不是“会不会规划”，而是“计划能不能留下来”

很多人讨论 AI 助理时，会把重点放在“模型会不会列步骤”。但在真实执行里，更关键的问题其实是：这些步骤在下一轮还在不在，状态有没有被更新，系统能不能继续沿着同一条主线推进。

可以把这件事想成三个层次：

会列计划：知道大概要分几步；
会按计划执行：不会一开始列完，转头就忘；
会把计划持续保存并更新：跨轮、续跑、失败恢复后仍然沿用同一个任务骨架。

只有第三层，才足以支撑真正的长任务。

因为多步任务最难的不是第一轮开始，而是第二轮、第三轮甚至更后面的继续执行。只靠模型在当前上下文里“临时记得”计划，任务一长就会出现两个典型问题：

重复做已完成的事：上轮已经查过目录、建过文件，这轮又从头做一遍；
跳过该做的验证：中间某步标成“做完了”，但没有验证，后面却把它当成稳定前提继续依赖。

所以真正决定执行质量的，不是“这轮会不会规划”，而是“这份计划能不能成为下一轮也看得见的状态”。

为什么“只在当轮写计划”对短任务还行，对长任务就会失真？

短任务通常有三个特点：

步骤少；
一个回合内就能走完；
中间没有太多需要回看和核对的里程碑。

在这种情况下，就算计划只是临时写在当前上下文里，问题也不大，因为任务还没来得及漂就结束了。

但长任务不一样。像内容流水线、批量改文件、部署与验证、桌面自动化、失败后续跑这类工作，常常会跨越多个阶段：前置检查、执行、回查、修正、提交、汇报。只要进入第二轮，计划如果没有持久化，就会开始出现信息衰减：

系统记得目标，但忘了路径；
系统记得部分结果，但忘了哪些已经验证；
系统记得“卡住过”，但忘了卡在第几步、为什么改了方案。

这就是为什么很多 AI 看起来第一轮挺像样，第二轮开始就变成“重新读题”。不是它完全不会做，而是它缺少一个跨轮保留任务骨架的地方。

update_plan 真正保存的，不只是步骤列表

把 update_plan 理解成“列待办清单”其实低估了它。

对执行系统来说，一份可持续的计划至少同时承载四类信息：

1. 当前任务的执行顺序

先查什么、后做什么、最后验什么，这决定了系统不会把依赖顺序搞反。比如内容流水线一定要先写作和质检，再部署，再提交收录，再分发，再更新日志和提交仓库；如果没有持久化的顺序骨架，系统就很容易中途把“记录和汇报”提前，或者把“发布前核验”忘掉。

2. 每一步的状态

pending、in_progress、done、verified、skipped 这些状态不是标签游戏，而是执行判断的依据。尤其 done 和 verified 的区别很重要：做完不等于验证通过。

如果系统只记得“上一步结束了”，却没记住它是否被验证，下一轮就可能把未验证成果当成稳定前提继续往下走，风险会被一层层放大。

3. 偏航与修订原因

真实任务里，计划几乎不会从头到尾原封不动。构建失败、平台限频、路径猜错、工具边界变化，都可能要求你改计划。此时如果只是悄悄换做法、不把修订原因写回计划，下一轮系统就很难理解：为什么现在走的是 B 路径，而不是最初的 A 路径？

4. 面向下一轮的交接语义

一份跨轮持久化的计划，本质上也是系统给未来自己的交接单。它让后续轮次不用再次从整段对话里逆向推理“前面到底发生了什么”，而是直接沿着当前任务结构接着推进。

为什么“计划跨轮可见”会直接改变任务续跑质量？

因为它把“继续这个任务”从一句模糊口头承诺，变成了可执行状态恢复。

假设一个任务跑到一半被打断，下一轮系统需要快速回答三个问题：

已经完成了哪些步骤？
哪些步骤只是做了，还没验证？
下一步应该接着做什么，而不是重做什么？

如果没有持久化计划，系统只能重新翻聊天记录、工具输出、文件改动和临时记忆来拼答案。这不仅慢，而且特别容易漏掉“验证状态”和“改计划原因”这两种最关键的信息。

而有了持续更新的计划，下一轮可以立刻看到：

哪些步骤已经 verified；
哪一步还在 in_progress；
哪个子步骤因为失败被改写过；
现在最自然的下一步是什么。

这会把续跑从“重新分析整段历史”变成“从当前状态继续执行”。

为什么说没有跨轮计划，状态回答也会变得不可靠？

因为用户问“现在到哪了”时，系统要回答的并不只是一个最终结果，而是任务主线上当前位置。

如果你读过为什么 AI 助理应该在聊天里回答“任务到哪了”，就会发现任务状态的核心不是安慰式语言，而是阶段、结果和下一步。这里的“阶段”其实高度依赖计划结构。

没有持久化计划时，系统很容易出现三种状态回答失真：

把最近做过的动作误当成当前阶段；
把一个失败尝试误当成真正完成的步骤；
回答“正在继续处理”，却说不清接下来具体做哪一步。

换句话说，任务状态是否可信，很大程度上取决于计划是不是一直被维护。计划丢了，状态就会退化成基于局部上下文的猜测。

为什么这对失败恢复尤其关键？

失败恢复最怕的不是失败本身，而是系统不知道该从哪一段继续。

例如：

构建失败后，是要修内容还是回滚配置？
发布中断后，是要重试当前平台，还是跳过它继续别的平台？
某步工具调用失败后，是参数错了、路径错了，还是前置条件没满足？

这些问题如果没有计划状态作为锚点，就很容易被简化成一句粗糙的“重新开始”。但很多时候，重新开始正是最差方案，因为：

会重复消耗时间；
可能触发额外副作用；
会覆盖掉对失败原因的精确判断。

跨轮持久化计划的价值，在于它让系统能明确区分：

什么已经完成，不该重做；
什么做了一半，需要续上；
什么验证失败，必须改计划后再走；
什么因为外部条件缺失，只能暂停等待。

这也是为什么真正能续跑的 AI，不只是“记得上次失败了”，而是记得失败发生在计划的哪一格，并把修正后的路径写回计划。

为什么把计划写在聊天文本里还不够？

因为聊天文本天然是叙述性的，不是结构化状态。

当然，聊天记录里也可能写过“我接下来会先 A 再 B”。但这类文字存在三个问题：

不稳定：后面说了更多话，原来的计划就被淹没了；
不可直接判断状态：用户和系统都得重新读一遍，才能知道哪一步已经完成；
不利于修订：计划一旦变化，聊天里会留下多个旧版本，系统反而更难知道当前该信哪个。

update_plan 这种机制的价值，正是在于它把计划从自然语言叙述，提升成一份持续更新的结构化任务状态。这样系统看到的不是“过去某一刻说过什么”，而是“现在这份计划的最新版是什么”。

一个实用标准：什么样的任务必须把计划跨轮持久化？

可以用一个很简单的判断：只要任务满足“3 步以上 + 中间结果需要验证 + 可能跨轮继续”这三项中的两项以上，就不该只靠当轮记忆，而应该显式维护跨轮计划。

特别典型的场景包括：

内容流水线：选题、写作、质检、部署、收录、分发、记录；
桌面自动化：打开应用、定位界面、执行操作、回看结果；
批量代码修改：搜点位、改文件、跑测试、修失败、再验证；
定时任务闭环：执行、记录观测值、命中条件后取消任务并汇报；
失败后续跑：识别上次卡点、调整路径、继续未完步骤。

这些任务都有一个共同点：你不仅要做事，还要知道自己现在处于哪一段。

对用户来说，跨轮计划持久化到底带来什么实际差异？

它带来的不是“计划看起来更完整”，而是协作体验的三个根本变化。

1. 任务更不容易漂

用户交代的是一个目标，不是让系统每一轮都重新自由发挥。计划持久化之后，系统更容易沿着同一目标骨架继续，而不是因为局部上下文变化就临时改主线。

2. 进度更可解释

当用户问“现在到哪了”，系统可以按计划结构回答：哪一步 verified、哪一步 in progress、哪一步因为什么被改了。这比泛泛地说“我还在处理”有可操作性得多。

3. 续跑和接手成本更低

无论是同一个系统进入下一轮，还是未来由另一次执行来接手，只要计划状态还在，接续成本都会显著降低。因为任务主线已经被显式保存，而不是藏在一大段历史文本里。

常见问题

FAQ 1：模型自己已经很聪明了，为什么还需要持久化计划？

因为聪明不等于稳定。模型可以在当前轮次里规划得很好，但长任务的核心问题是跨轮延续。没有持久化计划，下一轮仍然要重新依赖上下文理解，漂移风险不会自动消失。

FAQ 2：所有任务都要用 update_plan 吗？

不是。一步就能完成的短任务没必要。但只要任务步骤较多、存在验证环节、可能跨轮继续，显式维护计划通常比只靠当轮记忆稳得多。

FAQ 3：为什么 done 和 verified 必须分开？

因为“做完”只说明动作执行过，“verified”才说明结果已检查通过。很多长任务真正出问题，不是没做，而是把未经验证的结果当成可靠前提继续往下走。

FAQ 4：聊天记录本身不能当计划吗？

聊天记录更适合叙述发生过什么，不适合表示“当前最新版任务状态”。计划需要结构化、可更新、可直接回答下一步，而聊天文本天然会累积旧版本和噪声。

如果你已经发现：长任务最大的难点不是第一轮启动，而是第二轮以后还能不能稳稳接着做，那你看到的其实不是“模型规划能力”问题，而是“任务状态有没有跨轮保存”问题。GoWork 之所以把 update_plan 当成长任务纪律的一部分，就是为了让执行型 AI 不只会在这一轮列步骤，而能在下一轮继续沿着同一张任务地图往前走。想亲自试试，可以先看 GoWork 下载页、定时任务与自动跟进和失败后续跑。