失败后别重来：让 AI 助理从上次进度继续
很多团队刚开始把 AI 接进工作流时，最容易忽略的一点是：**任务失败以后怎么办。**如果系统一旦失败就要求你重新描述需求、重新补上下文、重新跑整条链路，那它节省下来的时间很快又会被"重来成本"吃掉。
对执行型任务来说，真正高效的能力不是"失败后再试一次"，而是失败后从上次进度继续。也就是它知道上次卡在哪、哪些步骤已经完成、哪些结果已经验证，这次应该从哪里恢复最省事。OmniGoAI 的 GoWork 之所以更适合承接这类场景，关键也在这里。
为什么"从头再跑"通常很浪费？
很多真实任务都是多步骤链路，例如：
- 读取上下文；
- 修改文件或调用外部工具；
- 构建、测试或部署；
- 回传结果；
- 更新日志、状态和后续动作。
如果前面几个步骤已经成功，只有最后一步失败，再从第 1 步重来通常会造成两件事：
- 重新消耗已经花过的时间；
- 把已经验证过的状态重新搅乱。
比如：
- 文章已经写好、构建通过，只是在分发时某平台掉登录；
- 代码已经修好并通过测试，只是在 push 时网络失败；
- 定时巡检已经观察了很多轮，只是最后一次通知没发出去；
- 桌面自动化已经走到最终页面，只在最后确认动作被验证码挡住。
这些情况里，正确策略应该是在失败点附近恢复，不是整条链路归零。
失败续跑依赖哪些信息？
这件事不是靠聊天记录就能解决的。
一个系统想支持失败续跑，至少要保留这些层次：
- 任务状态：queued、running、waiting、failed；
- 步骤进度：哪些完成了，哪些已经验证，哪些未完成；
- 运行细节：跑过什么命令、改过哪些文件、生成了什么结果；
- 失败证据：登录失效、网络波动、路径错误还是参数问题；
- 恢复锚点：下次最省事的继续位置。
换句话说，失败续跑的本质不是"自动重试"，而是只重做必须重做的那一段。
为什么"已验证成果不能重做"是核心原则？
因为执行型任务里最有价值的是已经确认过的进展。
通常可以把成果分成三种：
- 已完成且已验证；
- 已完成但未验证；
- 未完成。
一个可靠的系统，应该尽量从最后一个已验证节点继续。这样可以：
- 减少重复工作；
- 降低再次引入错误的概率；
- 让用户更容易理解当前真实状态；
- 让后续排障更聚焦。
哪些任务最需要失败续跑能力？
1. 长任务
例如部署、批量改文件、内容流水线、跨系统操作。它们天然不可能总在一轮里完美收尾。
2. 定时和后台任务
它们最大的风险不是单次失败，而是失败后把之前的观测和进度全部丢掉。
3. 依赖登录态或人工接力的任务
像平台发布、扫码登录、桌面操作，经常会在最后一段被外部条件打断。这时最合理的方式就是等条件补齐后继续，而不是从头来。
4. 用户会中途回来追问或改向的任务
当用户说"继续上次那个"时，系统若接不上，协作成本会立刻升高。
为什么这和任务状态能力是连着的？
因为你只有先知道任务停在哪，才能决定从哪里续跑。
如果一个系统说不清：
- 哪一步已经完成；
- 哪一步失败；
- 当前缺什么；
- 下次准备从哪里接着做；
那它通常也做不好失败续跑。反过来，只要这些信息是清晰可见的，用户就能快速判断是继续等、补资料、改方向，还是暂停任务。
一个简单判断：你的 AI 是会重试，还是会续跑？
可以直接问自己这 5 个问题：
- 失败后，系统能否说清上次失败在第几步？
- 它能否指出哪些成果已经完成并验证？
- 它能否基于真实命令、文件和错误记录决定下一步？
- 它能否理解"继续上次那个"指的是哪条任务？
- 它能否在同一会话里说明下次从哪里继续？
如果其中多数答案是否，那它更像一个会重试的聊天机器人，而不是一个真正可协作的执行型 AI 助理。
常见问题
失败续跑和自动重试一样吗？
不一样。自动重试只是重复动作；失败续跑是基于历史进度和验证节点，从最合理的位置恢复。
为什么仅有聊天记录还不够？
因为聊天记录只记录"说过什么"，而失败续跑需要知道"做过什么、做到哪一步、失败证据是什么"。
哪些任务最依赖这项能力？
长任务、定时任务、平台发布、桌面自动化、构建和部署，以及任何会被登录态、网络或人工确认打断的流程。
本文首发于 OmniGoAI 官网：https://omnigoai.com/zh/blog/gowork-follow-up-after-failure/ ------OmniPost，把内容一键分发到 30+ 平台。