面试题库

30 天从前端工程师到 Agent 工程师

D6 消息、上下文工程与压缩、会话存储/恢复/分叉（dg M06/M08/M09/M10）

• 会话的持久化、恢复和分叉分别解决什么问题？实现时各有什么坑？What problems do session persistence, restore, and forking each solve, and what goes wrong in each?

  国内高频海外高频进阶#session-management#persistence#forking

  分析过程 · 先想清楚再作答

  1. 题干把三件事并列，考的其实是你能不能分清它们各自的动机——很多人会把三个都答成「存下来」，那就丢掉了全部区分度。
  2. 先一句话各给一个动机：持久化解决「进程重启和跨机器请求」，恢复解决「加载回来还能接着聊」，分叉解决「同一段历史要走出两条不同的后续」。动机不同，所以数据结构的要求也不同。
  3. 持久化的关键选择是只追加还是快照。答只追加并给理由：写入不受历史长度影响、能回放到任意一步、有审计轨迹；快照只是读加速手段，工程上常见的是「只追加为准 + 定期快照」。这一条直接决定了分叉能不能做。
  4. 恢复的两个坑要主动说。一是把当时的系统提示词一起存进了历史，里面有「现在时间」这类动态上下文，三天后读出来模型的日期判断全错——系统提示词不进持久化历史，每次现拼。二是存档存在了工具调用中途，最后一条是没有配对结果的 tool_calls，直接发出去就是 400，加载后必须做完整性校验，补一条「执行被中断」的结果或丢弃这条尾巴。
  5. 分叉最容易被忽视的是「父会话只读」这条语义。分叉不是回滚：回滚砍掉历史继续用，是破坏性的；分叉复制前 k 条长出新枝，两边都能继续。实现上要深拷贝，直接引用父会话的消息对象会让两条分支互相污染。
  6. 可以预期的追问：分叉多了存储怎么办？答按父引用加偏移存、读时拼接，代价是读路径变复杂；再顺手补一句成本要能顺着 parentId 聚合成一棵树，否则账算不清是哪个用户的哪次重试花的钱。

  How to reason about it · think before answering

  1. The question lists three things side by side, so it is really testing whether you can separate their motivations. Answering 'they all save the conversation' throws away the entire signal.
  2. Give one motivation each in a sentence: persistence survives process restarts and multi-instance routing, restore lets a loaded history keep the conversation going, forking lets one history grow two different futures. Different motivations imply different data structures.
  3. The key persistence choice is append-only versus snapshot. Choose append-only and justify it: writes are independent of history length, any point can be replayed, and you keep an audit trail. Snapshots are a read optimization, so production usually means append-only as the source of truth plus periodic snapshots. This choice is what makes forking possible at all.
  4. Volunteer the two restore traps. First, persisting the system prompt inside the history: it carries dynamic context like the current time, so a session loaded three days later has the model reasoning from a stale date. Rebuild the system prompt fresh on every load. Second, a session saved mid tool call ends with an unmatched tool_calls message; replaying it verbatim gets a 400, so validate on load and either append an 'execution interrupted' tool result or drop the dangling tail.
  5. For forking, the overlooked point is that the parent stays read-only. Forking is not rollback: rollback truncates and mutates, forking copies the first k messages into a new branch and both sides continue. Deep-copy the messages — sharing the parent's objects lets the branches contaminate each other.
  6. Expect the follow-up on storage: reference the parent plus an offset and stitch on read, at the cost of a more complex read path. Add that cost must aggregate up the parentId tree, or you cannot tell which user's retry burned which tokens.

  答题要点

  • 持久化解决进程重启与跨实例，选只追加：写入不受历史长度影响、可回放任意一步、有审计轨迹；快照只是读加速
  • 恢复要现拼系统提示词，不能把带「现在时间」的那份存进历史，否则读出来日期判断全错
  • 恢复必须做完整性校验：尾部悬空的 tool_calls 要补一条中断结果或丢弃，否则下一次请求返回 400；压缩水位也要一起恢复
  • 分叉是复制前 k 条并记住父会话与切点，父会话只读——这是它和破坏性回滚的根本区别，实现上必须深拷贝
  • 分叉的代价是存储放大与成本归属，规模上来后改成存父引用加偏移，账要能顺着 parentId 聚合成树

  Key points

  • Persistence handles restarts and multiple instances; prefer append-only for constant-cost writes, replayability and an audit trail, with snapshots purely as a read optimization
  • On restore, rebuild the system prompt fresh — persisting the one containing the current time makes the model reason from a stale date
  • Validate on restore: a dangling tool_calls tail needs an 'interrupted' tool result or must be dropped, or the next request returns 400; restore the compression watermark too
  • A fork copies the first k messages and records parent and cut point, leaving the parent read-only — that is what separates it from destructive rollback, and it requires a deep copy
  • Forking costs storage amplification and muddled cost attribution; at scale store a parent reference plus offset and aggregate spend up the parentId tree