这篇文章不讨论“怎么把一个聊天机器人做出来”。

我更想讨论一个更容易被做糊的工程问题。

当一个系统开始同时承载闲聊、知识问答、数据分析三类任务时，我们到底该怎么设计它的上下文、记忆层和知识库。

在 OpsMind 里，我后来越来越确定一件事：

这三者如果不分开，系统一定会越来越重、越来越慢、越来越不准。

一、为什么我要重新想“上下文”这件事

做 LLM 产品时，一个很常见的偷懒方式，是把所有相关信息都叫作“上下文”。

最近几轮聊天是上下文。

用户偏好是上下文。

企业制度文档是上下文。

某次分析结论是上下文。

会话摘要也是上下文。

表面上它们都能进 prompt。

但从工程角度看，它们根本不是同一种东西。

在我的项目里，系统逐渐长出了三类典型请求：

• CHAT：解释、建议、润色、头脑风暴
• RAG：制度、流程、规则、组织知识问答
• DATA：文件分析、图表生成、趋势判断、业务洞察

这三类能力混在同一个产品里后，一个问题就会变得非常具体：

到底什么该进入模型当前上下文，什么该变成长期记忆，什么又应该进入知识库。

如果这个边界想不清楚，后面的问题会一串串地冒出来：

• 简单聊天也很慢，因为每轮都背着一堆历史和工具状态
• 数据分析越聊越乱，因为真正重要的是“分析状态”而不是聊天原文
• 知识问答会被会话里的临时结论污染
• 记忆越存越多，召回质量反而越来越差

所以我后来不再问“要不要存上下文”。

我更关心的是：

不同类型的信息，应该以什么形式进入哪一层，又该在什么时候失效。

二、先把概念拆开：上下文、记忆、知识库不是一回事

我现在更倾向于把系统里的信息层拆成三层。

1. 短期上下文

这是模型在当前一次回答里直接看到的内容。

它通常来自当前输入、最近几轮消息，以及这一次任务的即时状态。

它解决的问题是：

这一轮到底该怎么答。

对 CHAT 来说，它往往就是最近几轮自然对话。

对 DATA 来说，它不该只是消息，还应该包含当前文件、最近分析任务和生成状态。

2. 记忆层

这是系统为了跨轮、跨会话保持连续性，而保留下来的高价值信息。

它不应该等于“全部历史”。

它更像是被筛选后的偏好、目标、约定、摘要和关键结论。

它解决的问题是：

之后还要不要继续记得。

3. 知识库

知识库存的是稳定事实，而不是对话状态。

比如企业制度、流程文档、规范说明和组织级知识。

它解决的问题是：

事实依据到底是什么。

这三层最关键的区别，不在于数据长什么样。

而在于它们服务的问题根本不同。

如果把这三层混成一个系统，结果通常就是：

• 该短的东西变长
• 该稳的东西变脏
• 该快的东西变慢

三、为什么“上下文入库”既可行，又危险

从技术上说，把上下文做成可检索对象，当然是可行的。

一个已经具备向量检索能力的系统，本来就有切块、嵌入、持久化、召回和元数据过滤这些基础设施。

所以“高价值上下文入库”这件事，本身没有问题。

危险在于：

可行，不等于应该直接混进现有知识库。

如果把会话上下文直接塞进企业知识库，至少会出现四类污染。

1. 语义污染

用户问“报销制度是什么”，第一条召回却是某次会话里的总结，而不是制度原文。

系统会慢慢从“问制度”滑向“问模型之前是怎么总结制度的”。

2. 时效污染

知识库偏稳定，记忆层偏时效。

如果系统不区分长期事实和短期状态，就会出现旧结论覆盖新结论，临时约定覆盖稳定规则。

3. 检索污染

知识问答要找的是相关事实。

记忆召回要找的是对当前用户仍然有帮助的信息。

这两个目标不一样，排序标准也不一样。

4. 安全边界污染

企业知识库更接近共享资源。

上下文记忆更接近用户或会话私有资源。

它们混在一起后，权限和隔离会立刻复杂起来。

所以我现在的结论很明确：

上下文可以入库，但应该进入独立的记忆层，而不是直接混进知识库。

四、什么才算高价值上下文

这是整个设计里最关键，也最容易被低估的问题。

我现在对高价值上下文的定义是：

未来大概率还会有用，且不容易靠最近几轮自然恢复的信息。

如果一条信息下次还会影响回答，不存就容易丢，丢了以后模型也很难自己推回来，那它就值得考虑进入记忆层。

我自己会优先看五个维度。

1. 未来复用价值

它以后还会不会再用到。

比如“以后都先给结论，再解释原因”，复用价值就很高。

2. 不可重建性

如果不存，下次是否很难恢复这条信息。

用户偏好、项目目标、团队约定，通常都比上一轮普通提问更值得存。

3. 稳定性

这条信息会持续多久。

“以后都用中文回复”通常稳定。

“我今天有点烦”通常不稳定。

4. 行为影响力

它会不会明显改变系统后续行为。

比如是否显示工具过程、检索优先级、先走聊天还是先走分析。

5. 信息密度

一小段内容里，是否包含明确约束、偏好、目标或结论。

像“纯聊天不要显示工具过程，只有数据分析才显示步骤卡片”这种话，信息密度就非常高。

为了避免“什么都存”，我会给候选记忆做一个轻量评分：

• 未来复用性：0-3
• 不可重建性：0-2
• 稳定性：0-2
• 行为影响力：0-3

总分 >= 6 再考虑进入记忆层。

这不是学术最优解。

但工程上很实用，因为它至少能把“全量入库”的冲动压住。

五、哪些信息最值得被记住

在 OpsMind 这种系统里，我最想留下来的通常是四类信息。

1. 用户偏好

比如偏好中文、偏好简洁、喜欢先结论后展开、不喜欢看到工具过程。

2. 长期目标

比如用户正在做企业内部智能助手，重点关注知识问答和数据分析体验。

3. 关键约定

比如 CHAT 不显示工具过程，DATA 需要显示多步骤进度。

4. 重要结论

比如一次分析已经得出稳定判断，或者一次设计讨论已经明确某条策略。

这些内容如果不保存，系统要么忘掉，要么每次重新推一遍。

六、不值得进入记忆层的内容

工程上最危险的，其实不是存少了。

而是存多了。

下面这些内容，我通常不会让它们进入记忆层：

• 寒暄：你好、谢谢、在吗
• 短时情绪：今天有点烦
• 工具运行日志：第几轮调用了什么函数
• 冗长中间过程：长篇推理草稿
• 低密度重复信息：没有新增约束的重复要求

这类内容一旦大量入库，系统会出现一个很讨厌的错觉：

召回命中率看起来上去了。

但实际回答质量却在下降。

因为模型被一堆“看起来相关、其实无用”的内容淹掉了。

七、我更认可的架构：分层存储，分层读取

如果从系统设计角度重新整理，我会把这件事拆成四层。

1. 短期上下文层

只放最近几轮原始消息和当前轮必要状态。

它负责保证当前对话连贯。

2. 会话摘要层

每个会话定期压缩，只保留当前任务、关键结论、已做决策和用户偏好。

这层可以先放 SQLite，也可以同时写入记忆库。

3. 记忆向量层

单独建 collection，比如 opsmind_memory，或者继续按 user / session 再细分。

这层不存所有历史，只存筛过的高价值记忆。

4. 企业知识库层

继续存制度、流程、文档和组织级知识。

它不应该和记忆混用。

八、如果真正落地，我会怎么定义记忆结构

工程上最忌讳“把原文整段扔进去”。

我更倾向于把记忆条目结构化保存。

{
  "memory_id": "mem_20260324_001",
  "scope": "session",
  "session_id": "abc123",
  "memory_type": "preference",
  "summary": "用户希望纯聊天时不展示工具过程，数据分析时展示步骤卡片。",
  "importance": 0.86,
  "confidence": 0.91,
  "created_at": "2026-03-24T11:30:00",
  "updated_at": "2026-03-24T11:30:00",
  "expires_at": null,
  "source_message_ids": [101, 103],
  "supersedes": null
}

我至少会保留这些字段：

• scope：session / user / workspace
• memory_type：preference / goal / agreement / conclusion / summary
• summary：规范化短摘要，而不是长原文
• importance：重要程度
• confidence：这条记忆是否可靠
• expires_at：是否有时效
• supersedes：是否覆盖旧记忆

这样做的好处是：

• 可检索
• 可更新
• 可过期
• 可治理

九、写入策略：候选提取，不是每轮硬写

我不太认同“每轮都自动写记忆”。

更稳的路线是四步：

第一步：候选提取

先从当前轮里找出可能有价值的信息片段。

第二步：价值判断

判断它是否真的属于高价值上下文。

第三步：去重与合并

像“以后用中文”和“继续中文回复”，大概率应该合并，而不是存两次。

第四步：结构化入库

只把最终筛过、归一化过的摘要写入记忆层。

这个过程比“全部原文入库”复杂。

但它换来的，是可维护性和后续检索质量。

十、读取策略必须按意图分层

记忆层也不该每次全取。

不同请求，应该读不同层。

CHAT

纯聊天时，我更看重用户偏好、当前会话摘要和长期目标。

这会让系统更像一个连续的助手。

但它不该背太多分析细节。

RAG

知识问答时，我会读用户最近追问的主题，以及之前已经查到过的结论。

但企业知识库仍然应该保持更高的事实优先级。

DATA

数据分析时，最重要的通常不是聊天原文。

而是结构化分析上下文。

比如当前文件、字段理解、用户确认过的配置、最近一次分析结论和已生成图表索引。

对 DATA 来说，真正需要的不是“更多消息条数”。

而是“更像状态对象的上下文”。

十一、CHAT / RAG / DATA 不只是分流，更是上下文治理的开始

我后来越来越认同一个判断：

一个系统之所以显得聪明，很多时候不是因为模型更强，而是因为它知道什么时候该看什么，不该看什么。

这也是我为什么越来越坚持把系统拆成 CHAT / RAG / DATA 三条路径。

一旦这样拆开，很多工程决策才会变得清晰：

• 纯聊天不该启动 heavy agent
• 知识问答不该被会话临时结论污染
• 数据分析不该只靠最近十条消息

真正好的产品，不是把所有能力都堆在一起。

而是在正确的时候，调用正确的能力，并读取正确层级的上下文。

十二、如果只给我一句总结

如果把这篇文章压缩成一句话，我会这样说：

上下文决定当前回答，记忆决定长期连续性，知识库决定事实边界；把三者混在一起，系统一定会越来越重、越来越慢、越来越不准。

对企业智能助手来说，成熟的架构从来不是“一个大模型 + 一个大知识库”。

它更像是：

• 短期上下文层
• 会话摘要层
• 记忆向量层
• 企业知识库层
• 按意图分流的执行路径

而“高价值上下文”也不是玄学判断。

它完全可以被工程化：

• 定义标准
• 制定评分
• 结构化写入
• 去重、过期和覆盖

这才是一个系统从“能回答”走向“像一个真正助手”的分水岭。

十三、一个务实建议

如果你也在做类似产品，我不建议一开始就追求“万能上下文系统”。

更现实的路线通常是：

1. 先把 CHAT / RAG / DATA 分流做好
2. 再做会话摘要
3. 再做高价值记忆写入
4. 最后再做跨会话记忆召回

这样每一步都可验证、可回滚、可观察。

这更像专业工程，而不是一次性豪赌。

结语

我越来越相信，LLM 产品真正的壁垒不只是模型能力。

更是信息治理能力。

模型决定“会不会说”。

上下文决定“这次说什么”。

记忆决定“下次还记不记得”。

知识库决定“说得准不准”。

当这三者各司其职，一个系统才开始真正具备“助手感”。