会话历史、模型上下文和业务记忆有何不同

会话历史、模型上下文和业务记忆经常被统称为“上下文”，但三者解决的是不同问题：会话历史回答“发生过什么”，模型上下文回答“本轮生成回答时看到了什么”，业务记忆回答“哪些事实值得在未来继续使用”。如果把它们混为一谈，系统就容易出现一种假象：记录保存得很完整，模型却答非所问，甚至把过期信息当成当前事实。

三种信息的职责边界

会话历史是用户可查看的消息轨迹，重点在可读性、连续性和追溯性。它可以完整保留，也可以按需加载或折叠较早内容，但页面上能看到，不等于模型每次都需要读取。历史记录承担的是“留档”职责，而不是自动成为回答依据。

模型上下文是生成当前回答时实际进入模型的信息集合。它应围绕当前任务筛选，通常优先保留最近的有效对话、当前要求、相关知识和必要约束。重复追问、已经终结的分支以及过时判断，即使存在于历史中，也可能降低相关性。上下文的核心指标不是长度，而是与当前问题的匹配程度。

业务记忆则是跨会话复用的事实或状态，例如已确认的身份信息、项目阶段、有效偏好、流程状态和授权范围。它不应是聊天记录的永久复制品，更不能把模型的临时推断直接当作事实保存。只有经过确认、具有明确适用范围、能够被后续更新的信息，才适合进入业务记忆。

管理时先区分，再流转

实际设计中，三者应形成受控流转，而不是自动互相升级。历史消息可以为当前上下文提供材料；上下文中的信息只有在被确认后，才可能写入业务记忆；业务记忆被新事实覆盖后，应停止默认参与后续回答，但必要的审计痕迹仍可保留。

处理长对话时，较稳妥的顺序是先压缩，再确认，最后清理。摘要只保留当前诉求、已完成事项、限制条件、未解决问题和待确认事项；关键事实需要确认其是否仍然有效；旧排期、撤回要求和已完成待办则应从默认上下文中移除。

判断系统是否可靠，不应只看界面加载速度，而要追问：本轮回答依据了哪些信息？哪些是当前任务必需的？哪些已经过期？哪些只是模型推断？只有边界清楚，长对话才会从“记得很多”变成“用得准确”。