失败后别重来：让 AI 助理从上次进度继续

失败后别重来让 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 平台。