【Managed Agent】可恢复任务：暂停、回退与现场复现

本文暂为大纲，正文待补充。

Agent任务不是一次不可中断的函数调用。用户可能在执行中补充要求、改变主意、切换对话后再回来；系统也可能遇到Worker重启、Sandbox异常或外部调用失败。这里要讨论的是：如何把一轮任务保存成可解释、可继续推进的现场。

要回答的问题

• 一段对话、一次Run、一个Session和Sandbox分别保存什么状态？
• 为什么要把关键变化记录为原子事件，并在关键位置保存Snapshot？
• 任务暂停、失败或服务重启后，如何找到可以恢复的检查点？

消息进入正在执行任务时的选择

• QUEUE：等待当前Agent Loop收束，再顺序处理下一条消息。
• STEER：把新消息作为对当前任务的补充，在合适的衔接点带入后续推理。
• SUPERSEDE：用户改变主意，停止当前路径，回退到上一个可恢复检查点，再按新消息继续。

现场复现与回退

• Snapshot包含哪些可复现信息：配置版本、消息历史、工具结果、工作区与Session指针。
• 怎样区分“恢复阅读结果”和“恢复执行任务”。
• 回退后如何避免旧事件、旧工具输出继续污染新的执行路径。

用户主动改变历史时发生什么

• Saki编辑一条已经发送过的历史消息：编辑不是覆盖旧事实，而是从该消息所在节点创建新的后续分支；旧分支仍可审计和复现。
• Saki选择“回到这里”：从某个历史节点恢复当时的对话、配置和执行现场，并把后续交互接到新的分支上。
• Saki在正在执行的任务中选择回退：先停止或隔离当前尚未收束的执行，再以选中的检查点重新开始，避免旧任务的流式输出继续写入新分支。
• 用户可见的界面应该怎样表达“当前所在分支”“正在回退”“已从历史节点继续”，避免把回退误解成删除历史。

和其他专题的边界

• 事件主干与可靠投递见《事件主干：为什么是Kafka》。
• 用户如何看到持续更新，见《流式交付与可恢复阅读》。
• Sandbox的快照、重建与回收，见《Sandbox选型与生命周期》。