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

很多 AI 助理看起来第一轮很聪明：能把任务拆成几步，也能说清接下来打算做什么。但一旦任务跨轮，它们就开始出现同样的问题——重新理解上下文、重复做已经完成的动作、忘记哪些结果已经验证。

这说明问题不在“会不会规划”，而在计划是不是被保存成了可持续的任务状态。

对执行型系统来说，update_plan 的价值不是列一个好看的待办清单，而是让计划本身跨轮持久化。它保存的至少包括四件事：

1. 执行顺序

先查什么、后做什么、最后验证什么，决定了系统不会把依赖关系搞反。比如内容流水线必须先写作和质检，再部署，再收录，再分发，再更新日志和提交仓库。

2. 步骤状态

pending、in_progress、done、verified、skipped 不是装饰性字段，而是执行判断的依据。

尤其 done 和 verified 的区别必须保留：

• done = 动作已经执行；
• verified = 结果已经检查通过。

长任务里最危险的错误之一，就是把“刚做完”的结果当成“已经可靠”的前提继续往下走。

3. 修订原因

真实任务几乎不会一路按初版计划完美执行。构建失败、平台限频、路径猜错、前置条件缺失，都会让你调整做法。

如果系统只是默默换路径，却不把原因写回计划，下一轮就很难知道：为什么现在走的是 B 路，而不是原来的 A 路？

4. 跨轮交接语义

一份持续更新的计划，本质上就是系统给下一轮执行的交接单。这样下一轮不用重新翻整段历史，而是直接从当前任务结构继续往下走。

为什么聊天记录不能替代计划？

聊天里当然可能写过“接下来先 A 再 B”，但聊天文本有天然问题：

1. 后续消息一多，计划就被淹没；
2. 没法一眼看出最新版状态；
3. 多次修订后，旧版本和新版本会混在一起。

所以聊天适合叙述过程，不适合表示“当前 authoritative 的任务状态”。

为什么失败恢复尤其依赖计划持久化？

失败后最重要的问题，不是“有没有失败”，而是该从哪里继续。

例如：

• 构建失败后，是改内容还是改配置？
• 发布中断后，是重试当前平台还是跳过并记录？
• 某个命令失败，是参数错、路径错，还是前置条件没满足？

如果没有计划状态，这些问题往往会被粗暴地简化成“重新开始”。但真正稳妥的做法，是明确区分：

• 什么已经完成，不该重做；
• 什么做了一半，需要续上；
• 什么验证失败，必须先修订计划；
• 什么只是外部条件未满足，只能等待。

对用户的直接收益

计划跨轮持久化，对用户最实际的价值主要有三点：

• 任务不容易漂：系统不会每一轮都重新自由发挥；
• 进度更可解释：用户问“到哪了”时，可以明确回答哪一步 verified、哪一步 in progress；
• 续跑成本更低：失败后或中断后不需要重新分析整段历史。

所以，多步任务真正需要的不是“会规划一次”的模型，而是会把计划当成持续维护状态的执行系统。

FAQ

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

不是。一步就能完成的任务没必要。但只要任务超过 3 步、包含验证、或者很可能跨轮继续，就应该显式维护计划。

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

因为动作执行过，不代表结果已确认。很多长任务的问题，就出在把未验证产物当成稳定前提继续往下走。

FAQ 3：为什么状态回答也依赖计划？

因为状态回答不是一句“还在处理”，而是要说清当前阶段、最近结果和下一步。没有计划结构，这些都会退化成猜测。

本文首发于 OmniGoAI 官网：https://omnigoai.com/zh/blog/gowork-update-plan-cross-run-persistence/ ——OmniPost，把内容一键分发到 30+ 平台。