全局上下文管理器：LLM 应用的“记忆中枢”该怎么设计？

全局上下文管理器：LLM 应用的“记忆中枢”该怎么设计？

当 LLM 应用从单轮问答走向多轮对话、工具调用和长任务执行，上下文管理就不再是“把聊天记录拼起来”这么简单。
窗口有限，但历史会增长；任务会切换，但用户偏好要保留；单步执行要精确，长期记忆又要可恢复。

这时就需要一个全局上下文管理器。它的核心任务可以概括为：

用滑动窗口控制长度，用指代消解保证语义清晰，用 Token 压缩提升信息密度，用快照持久化保证可恢复；同时按“会话级—任务级—原子执行级”分层管理上下文。

下面拆开讲。

---

一、四种核心上下文处理手段

全局上下文管理器通常不会只用一种策略，而是组合使用以下四种能力。

方式	核心作用	常用做法	注意点
滑动窗口上下文截断	控制单次注入模型的上下文长度	只保留最近 N 轮或最近 K 个 Token；旧内容丢弃、摘要或转为检索	简单高效，但容易丢远期关键信息
指代消解	消除“它、这个、上述、该方案”等歧义	把代词、省略、指代还原成明确实体、事件、任务或变量	提升一致性，但可能消解错误，最好保留原文或置信度
Token 压缩	在有限窗口内保留更多有效信息	摘要、关键事实抽取、结构化表格、去重、向量检索、模板化	本质是“用更少 Token 表达同等信息”，会损失细节，需可回溯
历史快照持久化	支持恢复、审计、回放、迁移	按会话、任务、步骤定期或事件触发保存状态、版本、时间线	解决“存下来、可恢复”，不是“少占窗口”

一句话区分：

• 滑动窗口决定“哪些留下”；
• 指代消解决定“到底指谁”；
• Token 压缩决定“怎么更省空间”；
• 快照持久化决定“怎么不丢、可恢复”。

---

二、三层上下文模型

除了处理手段，上下文还需要分层。不同层级的信息，生命周期、抽象程度和注入策略都不一样。

层级	范围与生命周期	主要内容	管理策略
会话级上下文	整个用户会话，可能跨任务、长期存在	用户身份、偏好、长期目标、历史摘要、跨任务记忆	长期持久化；多用摘要、向量库、用户画像；注入时只取相关部分
任务级上下文	当前任务/工单/项目，从开始到结束	任务目标、约束、计划、进度、中间结果、工具输出	任务内维护状态机；阶段快照；任务结束后归档为会话记忆
原子执行上下文	单次 LLM 调用、工具调用或单步执行	当前输入、局部变量、即时观察、单步输出	生命周期最短；通常用滑动窗口；要求精确、小体积、低延迟

它们的关系可以理解为：

原子执行上下文 → 汇总成任务级上下文 → 再抽象成会话级上下文。

越往上越抽象、越持久、越跨任务；
越往下越具体、越临时、越精确。

---

三、一个典型协作流程

假设用户问：“它现在还能用吗？”

全局上下文管理器可以这样工作：

1. 指代消解：结合上一轮对话，把“它”还原成“刚才提到的支付服务 v2”。
2. 更新原子执行上下文：只保留当前步骤必要信息，比如当前问题、工具参数、局部变量。
3. 滑动窗口选择：取最近几轮对话，加上任务摘要和用户偏好。
4. Token 压缩：如果工具日志太长，就压缩成关键结果、错误码、时间线。
5. 分层注入：
   • 原子层给细节；
   • 任务层给状态；
   • 会话层给偏好和长期记忆。
6. 历史快照持久化：在关键节点保存任务状态，支持恢复、回放和审计。
7. 任务结束沉淀：把任务级摘要写回会话级记忆。

这样，模型既不会“失忆”，也不会被历史淹没。

---

四、落地时的几个关键点

1. 不要只做滑动窗口
   只保留最近几轮，很容易丢掉早期关键约束。最好配合摘要、检索和任务状态。

2. 指代消解要保留原文或置信度
   消解错了，后面全错。可以记录“原句 + 消解结果 + 置信度”，方便回退。

3. Token 压缩要可回溯
   摘要、结构化输出能省 Token，但不能让系统彻底丢失原始信息。压缩结果最好能指向原始日志或快照。

4. 快照不是压缩
   快照解决持久化和恢复，不解决窗口占用。两者经常一起用，但职责不同。

5. 任务结束要沉淀
   任务级上下文结束后，不要把全部细节塞进会话级。只抽象出偏好、结论、长期目标等可复用信息。

---

五、总结

全局上下文管理器不是简单的“聊天历史拼接器”，而是一套组合策略：

• 用滑动窗口控制长度；
• 用指代消解保证语义清晰；
• 用Token 压缩提升信息密度；
• 用快照持久化保证可恢复；
• 按会话级、任务级、原子执行级分层管理。

最终目标只有一个：

在有限的上下文窗口里，放入最有效的信息，同时让系统可恢复、可审计、可扩展。