Session、State 与恢复

用户停止一次综述生成，可能只是想暂时中断，已经完成的检索仍然有用。Lito 把对话和执行分别保存：Session 组织用户看到的消息，Run 记录某一次执行，Checkpoint 保存可以继续使用的工作进度。恢复时，系统据此决定能否接着写。

一、会话与执行记录

一个 Session 可以包含多轮问答，同一个问题也可以重新运行或继续执行。每次执行都有独立的 Run，分别保存输入条件、过程和结果，原有记录继续保留。

可恢复的 Checkpoint 在一轮工具结果加入历史后保存，包含已完成的工具调用、返回结果和引用映射。模型正在输出但尚未形成检查点的内容，不作为恢复起点。综述稿件另行保存，供交付与排查使用；保存草稿不代表可以从任意一句话或检查阶段继续执行。

运行记录与检查点依赖运行记录功能开启。隐身会话不进入这套持久化记录和恢复流程。

二、运行状态

运行创建后先排队，获得运行名额后开始执行。结束时，Run 保存完成、用户停止、预算耗尽或执行失败等状态；进程中断通过心跳超时识别。

图中“预算耗尽”在记录里进一步区分时间、调用、工具、token 和已知费用。重复返回相同结果会记录为 no_progress；发起检索但最终没有收集到可引用文献的运行可以记录为 evidence_insufficient。这些状态描述执行结果，回答的学术质量另由评测判断。任务能从哪里继续，则取决于已经保存的 Checkpoint。

三、稿件与核验记录

综述工作流将证据整理、补查计划、各版稿件和核验结果追加到本次运行记录。稿件在检查前保存，检查器超时、格式错误或预算结束时保留已有正文与引用，并记录未完成的检查。已经确认的事实错误仍须修正，不能因为保留稿件就视为通过；尚未生成正文时，如实记录未完成。

修订意见、证据缺口和技术故障分别记录。复核结果更新后，已撤销的意见从待修清单移除，保留尚未解决的问题。检查结果的复用仅限同一次运行；恢复任务仍从兼容的 Checkpoint 开始，不直接续接原来的检查阶段。

四、任务恢复与重新运行

恢复复用 Checkpoint 中已完成的工具结果；重新运行从保存的原请求开始，再执行研究循环。请求提交后，两种操作都会创建新的 Run 和回答分支，原始记录继续保留。

恢复要求原运行已经结束、状态不是完成，并且至少保存过一轮完整工具步骤。排队或运行中的任务需先停止；没有可恢复步骤时只能重新发起。重新运行默认沿用原请求，不会自动改变模型或检索设计，需要调整时应在新请求中明确设置。

恢复前会比较会话归属、项目、可用文件集合、语料签名、检索配置、模型、提供商和代码版本。已有历史中的工具只允许 internal_search、read_file、web_search、open_url 等只读操作；当前恢复路径适用于普通本地研究对话，专门的 Deep Research 分支不在其中。

语料签名覆盖 PostgreSQL 中全部相关分块表的内容、向量和权限载荷。系统据此检查资料是否变化，粒度较粗：即使改动的是本次问题范围外的文献，也可能拒绝恢复并要求重新研究。

任务恢复由用户发起，以最后一个可恢复的 Checkpoint 为起点。排队或运行中的任务超过 90 秒没有心跳时，系统在读取运行列表或进行排队准入检查时将其标记为 interrupted。这一标记不自动重启任务，也不保证一定存在可恢复的进度。