本页目录5
这个考点是什么
会话生命周期考的是“一次探索或调查过程，在时间和空间上如何延续”。同一天内可以用 checkpoint 做局部回退，跨天、跨环境延续时则要在 resume（在同一条时间线上继续）、fork（从共享基线分叉出互不干扰的多条时间线）、以及重开新会话（放弃旧对话、注入结构化摘要重新开始）之间做选择。
三者解决的是完全不同的问题：resume 恢复的是对话历史、已经产生的推理和工具结果，但不会重新读取文件系统——外部世界（代码、文档）一旦在此期间发生变化，resume 出来的会话仍然带着“旧快照”，除非显式告知发生了什么变化。
fork 解决的是“同一起点、多条独立探索路径”的问题，两条分支各自拥有独立的 session id，彼此不污染，也不影响原会话。重开新会话则用于原会话已经不可信、或规模太大不适合整体延续时，人工提炼出仍然有效的结论、写成结构化摘要注入新会话。
这个考点还会延伸到更大规模的编排场景：orchestrator 如何在多个 agent turn 之间传递状态而不撑爆上下文窗口，以及大规模并发下 session 状态该放在进程内还是外部持久化存储。
这些问题的本质是同一件事——哪些状态属于“对话/推理”层面、该交给 session 机制处理，哪些状态属于“事实/进度”层面、必须外部化成结构化、可核查的持久数据。
为什么考
出题角度集中在“给一个场景，判断该用 resume、fork、重开会话，还是外部化 checkpoint 中的哪一个”，干扰项常见套路是把机制的字面定义换个包装塞回题干，或者利用“resume 会自动感知文件变化”“fork 会隔离文件系统”“compact/摘要是可靠的持久化手段”这类常见误解设陷阱。
另一类高频考法给出崩溃恢复、千级并发这类工程场景，考察是否知道 session 内的对话状态和应用层的持久化状态要分开管理，不能用 resume/fork 硬顶替真正的状态存储。
核心辨析
- 1
resume 恢复对话不恢复文件系统
resumed 会话里，agent 之前读过的文件仍以“读取时的快照”存在于 context 中，不会自动重新扫描磁盘。文件在此期间被外部修改后，必须在 resume 之后显式告诉 agent 哪些文件变了，否则它会拿旧内容继续推理，悄悄产出针对已不存在代码的结论。
- 2
resume 与 fork 语义相反，容易混淆
resume 是在同一条历史上继续追加；fork（
fork_session/--fork-session//branch）是从当前状态复制出一个新 session id，原会话保持不变，新分支独立发展。判断标准是任务是否需要“分叉”——只有一条延续路线时 fork 只是多余的记账，需要从同一基线探索多个互不污染的方向时才该用 fork。 - 3
fork 隔离的是对话历史，不是文件系统
分支互不污染指各自的推理和发现不会串台；如果多条分支都会把代码改动写到同一份工作目录，文件层面的冲突依然存在，需要额外的隔离手段。
- 4
崩溃或中断恢复不等于会话恢复
pipeline 崩溃后正确做法是把已核实完成的结果写成结构化 checkpoint 文件，新开一个干净会话把 checkpoint 作为显式上下文注入，而不是 resume 崩溃前的会话（会带着未经验证的部分工具结果），也不是给每个未完成任务分别 fork（会把污染的上下文复制到每条分支）。
- 5
compact/摘要是有损的上下文管理，不是持久化机制
/compact以及跨 turn 传递状态时用的“结构化摘要 + delta”模式都是为了控制 token 预算，天然会丢信息，不能当作保证正确性或完整性的存储层；需要保真的进度记录必须落到会话之外的结构化数据里。 - 6
跨会话记忆要分清层级
in-context memory 只在当前 session 的 context window 内有效，session 结束或被压缩后即失效；真正跨多个独立 session 保留信息的是外部持久化存储（向量库/数据库），读写发生在 session 之外。
规模化到千级并发 session 时，这条原则会升级为架构要求——agent worker 应设计为无状态，session 状态整体外置到持久化存储，而不是塞进单个进程或模型 context。
反模式对照
外部文件在会话间发生了变化，直接 resume 旧会话，假设 agent 会自己发现改动
resume 之后显式告知 agent 哪些文件被修改，让它带着已有理解重新读取这些文件
resume 只重放对话历史，不会重新扫描文件系统；不说明变化就会导致 agent 静默地在过时快照上继续推理
想在同一基线上探索多个方向，对同一个 session 分别发起多次 resume
用 fork_session/--fork-session//branch 从共享基线分出独立的新 session id
多次 resume 写入的是同一条历史，会互相覆盖冲突；只有 fork 才会产生互不干扰的独立分支
pipeline 中途崩溃后，直接 resume 崩溃前的会话继续跑剩余任务
把已核实完成的部分写成结构化 checkpoint 文件，开新会话注入 checkpoint 后继续
resume 恢复的是包含崩溃前未验证工具结果的完整对话，无法区分哪些部分真正可信；checkpoint 把“进度”这一事实从“对话”这一媒介中剥离出来，才具备可核查的可靠性
把 /compact 或跨 turn 摘要传递当作长期保存关键进度的手段
需要保真、可核查的进度记录时落到会话外的结构化存储，session 内的摘要只用来控制 token 预算
compact 类机制以丢信息为代价换取上下文空间，是有损操作，不是持久化保证
练这个考点
练习模式支持按考点专练（需 Google 登录，不占用正式考机会）。
专练考点 1.7该考点的公开题（免登录，含完整解析）：