任务走偏了用检查点倒回去重来

长任务跑了几十分钟，你发现第三步的一个决策就不对——后面的所有工作都建立在这个错误上。怎么办？MiniMax Agent 给的答案是版本控制：Restore Checkpoint（恢复检查点）和 Edit & Regenerate（编辑并重新生成），让 Agent 回到上一个节点重新执行任务。

检查点是什么

Agent 执行任务时的每个关键节点（一次规划、一轮生成、一个子任务的完成）都可理解为存档点。回溯到某个检查点，意味着任务状态回到那个时刻——之后的执行作废，从那里带着修正重新往下走。这和代码版本管理里「回退到某个提交」是同一个思想。

什么时候用回溯，什么时候用插话

两个机制常被混用，其实边界清晰：

方向没错，补充细节 → 插话。比如「图表配色换成暖色系」，在当前状态上改就行，机制见任务跑到一半还能插话改需求吗。
早前的决策错了，后面全歪 → 回溯。比如「最初选的分析框架就不对，重来」，插话救不回来，回溯到选框架的节点之前。

判断口诀：问题出现在过去，回溯；问题出现在现在，插话。

回溯的代价与收益

回溯不是免费的——被回溯掉的那段执行，积分已经消耗；重走的路会再消耗一次。所以：

发现越早，代价越小：子任务刚完成就发现的错误，回溯成本低；拖到最后成品阶段才发现的根本性错误，回溯代价大。
这就是为什么要盯活：长任务定期看一眼中间产物，错误在早期拦截——盯活的具体手法见出门在外盯任务的三个典型场景。

实操建议

大方向定稿前（选题、框架、技术路线）多花一分钟确认，这些节点的错误代价最高。
回溯前把「哪里错了、该怎么改」想清楚，回溯后立刻给出修正指令，避免原地重蹈覆辙。
应用类任务的迭代同理——结构性返工用回溯，增量调整用插话，见应用生成后怎么继续改迭代。

检查点机制依据官方使用指南「版本控制」技巧整理，具体交互入口以实际版本为准。