Session、State 与恢复
用户停止一次综述生成，可能只是想暂时中断，已经完成的检索仍然有用。Lito 把对话和执行分别保存：Session 组织用户看到的消息，Run 记录某一次执行，Checkpoint 保存可以继续使用的工作进度。恢复时，系统据此决定能否接着写。
一、Lito 如何保存对话与执行进度
一个 Session 可以包含多轮问答，同一个问题也可以重新运行或继续执行。每次执行都有独立的 Run，分别保存输入条件、过程和结果，原有记录继续保留。
| 对象 | 保存内容 | 在产品中的作用 |
|---|---|---|
| Session / Message | 对话归属、用户问题、回答及消息关联 | 让用户沿同一话题继续提问 |
| Run | 本次配置、起止时间、状态、用量和 resume_from |
区分每次执行与恢复来源 |
| Checkpoint | 已完成循环的历史、工具结果、引用映射和研究进展 | 给后续执行提供可复用的起点 |
| Evidence | 原文快照、文献与片段标识、出现阶段和引用标记 | 在恢复和排查时找回当时使用的材料 |
Checkpoint 在一轮工具结果加入历史后保存，包含模型已经请求了什么、工具返回了什么，以及当前引用编号对应哪些来源。恢复会复用这个完整步骤。模型正在输出但尚未形成检查点的内容，不作为可恢复的工作进度。
二、一次运行会经历哪些状态
运行创建后先排队，获得运行名额后开始执行。结束时，Run 保存完成、用户停止、预算耗尽或执行失败等状态；进程中断通过心跳超时识别。
图中“预算耗尽”在记录里进一步区分时间、调用、工具、token 和已知费用。重复返回相同结果会记录为 no_progress；发起检索但最终没有收集到可引用文献的运行可以记录为 evidence_insufficient。这些状态描述执行结果，回答的学术质量另由评测判断。任务能从哪里继续，则取决于已经保存的 Checkpoint。
三、用户如何继续任务或重新运行
恢复沿用已有进度，重新运行从原问题开始。恢复会复用 Checkpoint 中已完成的工具结果；重新运行则创建新的回答分支，再走研究循环。两种操作都生成新的 Run，原始记录继续保留。恢复适合短暂中断后的接续，重跑适合更换模型、调整检索设计或重新核查结果。
恢复前会比较会话归属、项目、可用文件集合、语料签名、检索配置、模型、提供商和代码版本。已有历史中的工具只允许 internal_search、read_file、web_search、open_url 等只读操作；当前恢复路径适用于普通本地研究对话，专门的 Deep Research 分支不在其中。
语料签名覆盖 PostgreSQL 中全部相关分块表的内容、向量和权限载荷。它把证据是否过期作为恢复前提，但粒度较粗：即使改动的是本次问题范围外的文献，也可能要求重新研究。后续若要减少这类中断，需要把检查缩小到实际依赖的资料。
任务恢复由用户发起，以最后一个完整 Checkpoint 为起点。进程超过 90 秒没有心跳时，系统在读取运行列表或接收新任务时将其标记为 interrupted，用户可以据此判断需要继续还是重新运行。