多轮大模型应用的会话状态应该如何存储与裁剪？

面试时怎么答

会话状态不能等同于最近 N 条消息。回答时拆成不可变事件、当前工作记忆、可检索长期记忆和权威业务事实，并说明摘要与裁剪只负责构造上下文，订单等事实仍应回源。追问通常涉及并发写、版本冲突、隐私删除和摘要遗漏。

可以这样答：

会话状态不能等同于“最近 N 条消息”，我会拆成不可变事件、当前工作记忆、可检索长期记忆和权威业务事实。每次请求按会话版本追加事件，工作上下文由裁剪和摘要生成，关键订单状态仍从业务系统读取。同时，保留越多越连贯，但 Token、隐私和陈旧信息风险也越高。服务侧要做租户隔离、字段加密和并发版本检查，持续看上下文 Token、摘要事实遗漏率、写冲突率和故障恢复时间。

核心回答

把应用数据库中的会话事件作为事实来源，按顺序保存用户消息、模型回答、工具请求与结果、附件引用和版本元数据；每次调用模型时再构造一个受 token 预算约束的“上下文视图”，它可以由系统说明、最近若干轮、较早内容摘要和按需检索的事实组成。模型上下文不是可靠数据库，摘要也是有损派生数据，不能替代订单状态、权限或用户确认等业务事实。

会话记录要按用户和租户鉴权，设置加密、保留期、删除与导出策略。并发写入使用版本号或顺序号，重试使用幂等键，防止同一消息或工具结果重复追加。

展开说明

可把数据拆成三层：

• 原始事件层：追加式保存必要事件与来源，便于审计和重新构建；是否保存全文由隐私和合规策略决定。
• 派生记忆层：摘要、用户偏好和抽取事实都带来源、生成版本与更新时间，可失效和重算。
• 调用上下文层：根据本轮任务、权限和 token 预算临时拼装，不应把全部历史无条件发送给模型。

裁剪时优先保留当前任务约束、未完成工具状态和关键确认；旧闲聊可摘要，外部知识可重新检索。摘要应标记为模型生成，重要数字最好保留指向原事件的引用。跨设备恢复会话时，服务端顺序号比客户端时间更适合作为一致性依据。

工程实践

定义 conversation_id + sequence 唯一键和乐观并发控制，消息写入与异步生成状态分开。为每次上下文构建记录所选事件 ID、摘要版本和 token 数，以便复现；测试并发发送、重试、删除、超长会话、摘要错误和越权读取。缓存必须把租户与权限版本纳入键，退出登录或权限变化时及时失效。

常见追问

1. 为什么不能只把最近 N 条消息直接发给模型？ 固定窗口可能丢掉更早的约束和用户偏好，也会混入大量无关内容；应按相关性、时效性与业务重要度组合上下文。
2. 摘要压缩会丢信息，怎样降低对业务正确性的影响？ 对关键事实结构化保存并保留原事件引用，摘要做可追溯校验；高风险决策重新读取权威数据源。
3. 用户同时从两个设备发消息时如何保证会话顺序？ 使用单调版本号或事件序列配合乐观锁，冲突时重读并重放；不要依赖客户端时间戳直接排序。

一句话复习

数据库保存可追溯事件，模型只接收按任务和 token 预算生成的上下文视图。

参考资料

• 面试题来源：AI Engineering Interview Questions 的状态管理题
• 官方依据：OpenAI Conversation State 指南、OpenAI Context Management 指南