第七章：对话结束后，状态保存在哪里
草稿已经出现，你关闭窗口，第二天回来追问“为什么没有采用 B”。系统要回答这个问题，需要找回原来是哪段对话、读到了哪些材料，以及最后形成了什么结论。
如果这些只存在于进程内存里，程序退出后就可能消失。若全部保存却没有归属和状态，重新打开时也未必能正确延续。本章从会话、一次运行和持久记录的关系出发，理解“还记得刚才”依赖什么。
本章的产物是一张会话与运行状态图。它为后面的长期记忆、身份隔离和定时执行提供基础。
7.1 窗口、进程、运行与会话
先把四件事分开：窗口是交互呈现；进程是正在执行的软件；一次运行处理某项要求；会话组织连续交流的历史与相关状态。
关闭窗口不一定表示后台进程退出；进程重启也不一定表示历史被删除；一次草稿生成结束，更不意味着这段会话再也不能继续。
这一区分直接影响恢复方式。只是界面断开，可能重新连接就能继续看正在执行的任务；进程退出后，则要从持久记录恢复；用户主动新建会话，通常需要选择另一段历史，而不是假定所有旧对话自动接续。
7.2 为什么不只保存最终答复
只保存“两条草稿”可以让用户看到结果，却很难回答为什么排除 B、哪次读取失败、后来改短过没有。恢复工作还需要过程和状态。
| 需要保存的内容 | 它帮助回答什么 |
|---|---|
| 会话身份与配置 | 继续哪段交流，使用什么运行条件 |
| 用户输入与模型响应 | 当时要求和交付是什么 |
| 工具请求及实际返回 | 哪些动作提出过、执行过、得到什么 |
| 结束原因与运行状态 | 是正常交付、取消、失败还是达到限制 |
| 用量与归属信息 | 哪次工作产生了开销，哪些结果属于它 |
另一方面，保存所有原始内容也会增加体积、检索和隐私管理的责任。完整历史并不适合每次全部交给模型，因此持久化需要与第六章的选择和压缩配合。
这形成一项基本设计：长期保存的记录可以比当前模型输入更完整，而两者之间要能追溯。
7.3 Hermes 怎样组织历史
本版 Hermes 使用 SQLite 这样的轻量本地数据库组织会话元信息、消息和相关用量，并提供全文检索能力。可以把它理解为带归属和查询规则的记录系统，无需先学习数据库语法。
会话记录使系统能把消息归到正确位置；消息记录保留角色、内容、工具调用等信息；检索则帮助找回过去的片段。历史也可以导出或用于其他用途，但那不意味着所有数据都属于同一个存储系统。
状态还与所用的 Profile 关联。不同持久身份有各自的配置与状态范围，不能只凭“同一台电脑”判断使用了同一份历史。第十一章会进一步展开身份和入口。
为什么不只是把每次结果追加到一个文本文件？简单文件容易起步，但跨会话查询、并发写入、用量归属和生命周期都需要另外管理。数据库提供组织与查询能力，同时也引入结构、迁移和写入协调的成本。
7.4 谁拥有一次输入的写入责任
多个入口接入时，一条消息可能经过入口、会话服务和运行实例。若每个环节都独立写一遍，就可能出现重复输入；若每个环节都以为其他人会写，则可能丢失。
本版规范的会话路径强调由相应会话权威接收输入和组织规范记录，托管工作进程通过所属会话服务写入，而不随意直写同一份数据库。这里的会话权威是承担归属与协调的运行责任，不是指模型具有更高权限。
需要判断“这条输入已经由谁保存”。来源标识、归属信息和保存结果比“文字与上一条一样”更可靠：用户可能真的连续发送相同要求，不能按内容相同就直接删除。
这是一种减少重复与缺口的设计，并不是对所有外部事件都保证绝对只处理一次。中断发生在哪里、写入是否成功，以及重放的是否为同一项输入，仍然需要具体记录。
7.5 保存要与实际执行对齐
假设系统准备读取 A，记录调用请求后执行，取得结果，再保存返回。后续判断就可以知道这份正文对应哪次行动。
若关键保存失败，继续推进可能让模型使用到一份事后无法恢复的结果。旧版深化循环时已经讨论过这一取舍：本版工具路径在执行前保存调用，并在关键记录失败时停止相应推进，避免状态继续分叉。
但保存失败不会天然撤销外部动作。读取通常只取得内容，发送或写入则可能已经改变环境。历史帮助我们判断发生了什么，不能代替外部系统自己的确认和恢复方式。
7.6 压缩之后，旧内容是否消失
第六章改变的是模型后续使用的上下文表示。持久历史可能保留更早内容与压缩关系，供恢复和检索。
本版既有围绕压缩延续的会话关联，也有在稳定会话标识内保留不同活跃代次的处理。理解时先分清两件事：哪份内容正在进入模型请求，哪份属于保留的历史。
同一句话出现在旧归档和新活跃表示里，不一定表示用户输入被执行了两次。贸然按文字去重，可能删掉合法的历史关联。应结合归属、活跃状态与压缩边界检查。
这说明恢复不只是把最近几行重新显示。它还需要找到正确会话、当前有效状态和相应运行配置，必要时沿关联找回更早材料。
7.7 为简报写一份恢复检查单
假设窗口重新打开，只显示“草稿生成完成”。要回答为什么排除 B，可以先确认会话身份，再找对应运行、材料 A 与 B 的返回、核对结论和最终草稿。
如果只找到一个“准备读取 B”的请求，没有结果，就不能推断读取成功；如果结果在另一段会话，也不能直接拼进当前任务。若原始材料仍存在，可以重新取得并明确这是一次新的核对。
本章的恢复检查单包括：接续哪个会话、最后确认的状态、已经执行的动作、尚未确认的动作、需要重新取得的材料。它既支持后续工作，也帮助解释系统为什么不能无条件恢复到“和没中断过一样”。
本章要点
- 交互窗口、软件进程、一次运行与会话需要分别理解。
- 历史应组织输入、行动、结果、状态与归属，而不仅保存最终文字。
- Hermes 用持久数据库和检索承接历史，并需要明确写入与会话协调责任。
- 当前上下文与完整历史不同，压缩后的活跃表示可以与保留记录并存。
- 恢复需要证据与正确归属，记录不提供对所有外部动作的自动撤销。
理解题
1. 重启程序后还能追问刚才的草稿，是否足以证明长期记忆发挥了作用？
不足以。可能只是原会话历史从持久记录恢复了。应区分会话接续、精选记忆加载与历史检索，确认材料究竟通过哪条路径进入当前请求。
2. 两条用户消息内容完全相同，是否应该自动删掉一条？
不能仅凭文字相同决定。它们可能是重复投递，也可能是用户真的提出了两次要求。需要结合来源和输入归属判断；历史压缩产生的不同代次，也不能混同为重复执行。
3. 记录里有读取请求但没有返回，恢复时能否写“材料已查到”？
不能。请求只表示行动曾被提出，缺少返回可能意味着未执行、执行失败或结果未能保存。应核对实际状态，必要时重新读取，并说明哪部分依据是新取得的。
下一章：新会话怎样找回偏好与旧事。