第 7 章：从 “堆上下文” 到 “管理上下文”

在上一章中，我们已经明确否定了一种做法：

把上下文当作“无限可用的记忆容器”。

那么一个更难、也更重要的问题随之出现：

在有限的上下文窗口里，哪些信息值得被保留？

这并不是一个模型问题，而是一个系统设计决策 —— 它直接决定了多轮对话中系统的稳定性。

---

7.1 技术决策的第一步：承认信息是有“等级”的

在企业知识库助手的真实对话中，并不是所有信息都同等重要。

如果你不主动区分，模型就会被迫“平均对待”。

从工程角度，我们至少需要区分三类信息，它们的优先级和保留策略完全不同：

1.不变约束（最高优先级）

指系统必须始终遵守的核心规则，不随对话内容变化而改变。

例如：

• 系统角色定义（“你是 XX 公司的内部知识库助手，不对外提供服务”）
• 行为边界（“仅回答员工手册、财务制度中的内容，超出范围需明确拒绝”）
• 安全规则（“禁止泄露员工个人信息、未公开的业务数据”）

这类信息必须永远保留在上下文窗口中，且位置要尽可能靠前（减少注意力衰减影响）。

2.会话状态（中高优先级）

指当前对话中形成的关键共识、未完成的任务或用户的核心意图，是维持对话连贯性的基础。

例如：

• 当前讨论主题（“用户正在咨询 2024 年新版差旅报销政策”）
• 已确认事实（“用户是销售部员工，经常出差至华东地区”）
• 待解决问题（“需确认‘高铁一等座是否可报销’”）

这类信息需要持续维护和更新，确保模型了解对话的 “当前阶段”。

3. 瞬时上下文（低优先级）

指对话中的临时交互、举例说明或过渡性内容，对长期连贯性影响较小。例如：

• 用户的临时追问（“那二等座呢？”）
• 辅助说明（“比如我上次去上海的高铁票是一等座”）
• 无关寒暄（“谢谢，我再看看”）

这类信息可以按需保留最近几轮，超出范围后可直接丢弃。

上下文失控的本质，不是信息太多，而是信息没有被分层。 —— 让低优先级的内容挤占了高优先级信息的 “生存空间”。

---

7.2 为什么“直接摘要历史”并不是银弹？

在意识到上下文有限后，很多团队会做出第二个直觉决策：

那就把历史对话总结一下，再塞回去。

这个思路的方向是对的（减少冗余信息），但如果不区分信息等级，简单做 “全量摘要”，会引入新的系统风险：

• 约束信息被压缩：比如原系统提示中的 “5 条核心规则” 可能被摘要简化为 “遵守公司规定”，丢失关键细节。
• 错误结论被固化：如果某轮回答存在错误（比如 “年假可累计 15 天” 实际应为 10 天），摘要可能会保留这个错误并持续传递。
• 决策过程被抹平：用户曾明确拒绝的方向（比如 “我不想了解北京的政策”）可能在摘要中被忽略，导致模型重复无效信息。

这意味着：

我们需要的不是“一个摘要”，而是“结构化状态”。 —— 即针对不同等级的信息，设计专门的保留和更新策略。

---

7.3 本章小结：上下文开始变成工程对象

到这里，你应该已经意识到：

• 上下文不再是自然增长的聊天记录，而是一个需要被主动设计、分层管理、动态维护的系统状态
• 多轮对话的可靠性，取决于 “高优先级信息是否能稳定地影响模型决策”。

这一步认知转变，会直接引出下一个问题：

既然信息需要被分层管理，那“记忆”是否也应该分层？

这正是下一章要探讨的核心问题 —— 记忆策略的工程化选择。