大模型应用里的会话状态应该如何管理？

简化版

会话状态管理要区分短期上下文、摘要状态、长期记忆、业务状态和审计日志。不能把所有历史原样塞进 prompt，而要按 token 预算、相关性、权限和新旧冲突进行压缩与检索。

详细版

• 短期上下文保存最近交互，适合当前连续对话。
• 摘要状态把长历史压缩成可恢复的任务信息。
• 长期记忆保存用户偏好、项目事实等可复用信息，但要可删除。
• 业务状态来自订单、工单、数据库等权威系统，不能被模型随意覆盖。
• 状态拼装前要做权限过滤、过期判断和冲突处理。

完整版教学

记忆钩子：上下文是“这次要看的材料”，状态管理是“决定哪些材料能上桌”。

一、这题真正考什么

记忆钩子：上下文是“这次要看的材料”，状态管理是“决定哪些材料能上桌”。

状态管理的核心不是保存更多文本，而是让每类状态有权威来源、生命周期和权限边界。摘要是有损派生数据，业务状态来自数据库，长期记忆则必须支持用户查看、更正和删除。

二、核心原理和工程边界

LLM 每次请求只看到当前输入 token，因此会话状态本质上是应用层在请求前拼装上下文。好的状态管理会把历史消息、摘要、长期记忆和业务事实分开存放，并在每次请求前按任务意图检索。这样能降低成本，也能减少旧信息误导模型。

三、带数字的工程算例

用户连续聊了 50 轮，原始历史有 45000 token，而模型窗口只有 16000 token。系统可以保留最近 4000 token、摘要 1000 token、检索 6 条相关记忆共 1200 token，再给当前问题和输出预留 4000 token。

上下文预算 = 窗口上限 - 系统提示 - 工具说明 - 当前输入 - 输出预留
历史压缩率 = 摘要 token / 原历史 token
状态可信度：业务数据库 > 工具返回 > 长期记忆 > 用户口述历史

四、典型链路怎么跑

可以把这类问题拆成下面的链路来理解：

新请求进入
   |
读取最近消息
   |
加载摘要状态
   |
检索长期记忆
   |
查询业务事实
   |
权限过滤与冲突解决
   |
拼装 prompt

五、方案对比和选择标准

状态类型	来源	处理方式
短期上下文	最近对话	截断或窗口保留
摘要状态	历史压缩	持续更新并校验
长期记忆	外部存储	检索、过期、可删除
业务状态	权威系统	工具查询，不靠模型猜

六、上线后最容易出问题的地方

• 旧状态和新指令冲突时，要明确优先级，否则模型可能沿用过期偏好。

• 长期记忆涉及隐私，必须有用户可见、可改、可删的产品机制。

• 摘要更新要保留上一版与触发消息，避免一次错误压缩后无法追查信息何时丢失。

七、常见误区与追问

• 误区：多轮对话就是把历史全拼上。 窗口会被旧信息占满并引入冲突；应保留近期消息、结构化状态和按需检索的长期记忆。
• 误区：摘要状态一定不会丢关键信息。 摘要是有损压缩，要用关键槽位校验、版本记录和原文回链防止事实被省略或改写。
• 误区：模型记忆可以替代业务数据库。 订单、余额和权限必须以权威系统为准，模型记忆只能提供对话线索，不能覆盖真实状态。
• 追问：状态过期应该怎么设计？ 为记忆记录来源、写入时间、TTL 和业务版本；读取时检查新旧冲突，过期后重新查询权威数据。
• 追问：如何处理用户纠正旧信息？ 把纠正写成新版本并让旧值失效，同时保留审计关系；后续检索必须优先返回已确认的新值。
• 追问：为什么状态管理会影响幻觉率？ 过期或冲突状态会把错误前提注入上下文，模型会围绕它生成连贯但错误的后续内容。

八、加强记忆

按“短期、摘要、长期、业务、审计”五类记。回答时强调状态不是越多越好，而是相关、可信、合规、可控。