context-mode：专治LLM长对话上下文失控的轻量级管理工具

如果你经常用大模型写代码、做方案或者处理文档，大概率遇到过这种场面：对话刚开始的十几分钟里，AI 稳得像一个带过多个大项目的资深专家，说话有依据、改代码有分寸；可一旦聊到第四十分钟、第五十分钟，它就开始"退化"——忘了你最早定下的技术选型，把你明确禁止过的方案重新拿出来推荐，甚至把两个文件的职责彻底搞混。我一开始以为是自己提问方式有问题，后来反复测试才发现，这是一个结构性的问题：上下文从头到尾都没有被管理，只是在被不断堆积。搜索 context-mode 这个关键词时，绝大多数结果都是讲 CPU 上下文切换的，跟我要解决的问题完全不搭边。于是我自己写了一个轻量工具，也命名为 context-mode，专治 LLM 对话中的上下文失控。这篇文章就是它的完整设计思路、关键实现、实测数据和踩坑记录，适合正在跟长对话、长文档"搏斗"的开发者参考。

1. 一次"失忆"事故，让我决定认真对待上下文管理

1.1 事故现场：从"专家"到"实习生"的对话崩溃

上个月我在做一个小型的数据清洗工具，需要把几十个来源混乱的 Excel 合并成统一格式的 CSV。项目不大，但规则很细：某些字段要保留原始值、某些字段要做类型推断、日期格式要统一、空值不能直接删而要打标记。我习惯用 AI 辅助编程，于是打开对话窗口，从"帮我写一个 pandas 数据清洗脚本"开始，一路聊需求。

前 10 轮都顺利得不像话。AI 主动提出了用流式处理来避免内存溢出，还建议我保留原始列名作为备份列，这些都是我本来要提的要求。但到了第 40 轮左右，当我在讨论"某个日期字段到底应该按 %Y-%m-%d 解析还是按 %Y/%m/%d 解析"的时候，AI 突然在另一个文件里开始推倒重来：它建议我把 pandas 换成 Spark，把保留原始字段的策略改成"规范化后直接删除"，还给我展示了一段完全违背最初约定的代码。

我当场就懵了。这句话在 15 轮之前明明已经讨论过、确认过、还写进了代码注释里，为什么它像完全没看见一样？更让我哭笑不得的是，当我翻聊天记录把当时的对话原样贴回去，它立刻道歉说"对不起，我忽略了之前约好的规则"。这不是能力问题，这是上下文管理问题。

1.2 为什么会"失忆"：上下文窗口不是硬盘，是白板

很多人对上下文窗口有一个错误的理解，以为它像硬盘一样，东西写进去就一直在，AI 随时能读出来。实际上它更像一块会议室里的白板：空间是有限的，每次有新内容写入，旧内容可能就被擦掉了。Transformer 模型处理长文本时，注意力机制虽然理论上能关注到所有 token，但实际效果会随着距离增加而衰减，更关键的是当输入长度接近模型的上限时，系统必须截断或者压缩掉一部分内容。

具体到我的案例里，前面关于技术选型的讨论发生在 15 轮之前，后面 25 轮的代码片段、错误日志、调试输出早就把前面那些关键决策挤到了窗口边缘。模型不是故意要忘，是物理上顾不过来。用大白话说：它脑子里同时装着 50 件事，最早装进去的那 10 件已经模糊了，而最新写上去的 20 件最清晰。把你的原始需求放进去，优先级自然就低了。

还有一个容易被忽略的点：系统提示词里那些"默认规则"不会因为你说了几句话就改变，但多轮对话里零散确认的决策没有固定存储位置。如果没人帮它把"已经确认过的结论"单独拎出来放到显眼位置，它就只能凭记忆去猜，猜错了也不自知。

1.3 context-mode 的定位：不是插件，是一套管理策略

搞清楚原因之后，我的第一个想法是找现成工具。市面上的上下文管理插件有很多，有的做自动压缩，有的做向量检索。但试了一圈发现两个问题：要么过度黑盒，你不知道它到底压缩了什么；要么太重，装一个工具比写项目本身还麻烦。

所以我决定自己写一个命令行工具，核心思路很朴素：把上下文当作资源来管理，而不是听天由命。它接管四件事——进（什么内容允许进入上下文）、存（压缩后的内容存在哪）、取（需要时如何检索回来）、忘（哪些内容应该主动丢弃）。以及一个附加功能：每次会话结束都留下可加载的检查点文件，让"失忆"这件事变得可追溯、可恢复。

这个工具不绑定任何特定的 AI 产品，可以把它理解为工作流外围的一个辅助层。配合任何主流模型服务使用都行，唯一的要求是你能拿到对话历史的结构化数据。文章后面我会给出完整的配置文件和实现伪代码，想直接用还是想改成适合自己的版本，都行。

2. context-mode 的核心设计：把上下文当成一份预算表

2.1 三层上下文结构

不同内容的"命"不一样。有些信息哪怕丢了几个字都会让整个任务崩掉，比如"禁止删除原始字段""数据库密码在 .env 里""目标输出编码是 UTF-8"；有些信息则丢了也无所谓，比如某次报错的具体堆栈、某段已经替换掉的老代码。把这两种内容同等对待，是很多上下文管理工具效果差的根本原因。

context-mode 把全部上下文拆成三层，每层采用完全不同的管理策略：

• 系统约束层：包含角色设定、硬性规则、技术栈约束、项目关键路径。这一层从会话开始写入，一直驻留到会话结束，任何人、任何情况都不能挤掉它。我的实现里给它设了"最高保留优先级"，压缩器永远跳过这一层。
• 会话记忆层：包含本轮对话中已经确认的决策、用户明确表达过的偏好、已经排除掉的方案。这一层用滑动窗口维护，窗口满了就触发摘要压缩，但压缩时必须保留可检索的关键词。
• 工作存储层：包含具体的代码片段、日志、长文档、临时数据。这一层是最大的，也是可以被无痕清除的。它默认不进主上下文，只在需要的时候通过检索召回。

这个结构解决了一个关键问题：过去我们总是想"怎么塞更多内容进去"，现在反过来问"哪些内容根本不配占用位置"。把预算留给真正重要的东西，比优化存储效率有效得多。

2.2 预算分配规则

上下文窗口有硬上限，我把它当成月度预算表来用，每一层有明确的占比和职责：

这个比例不是拍脑袋定的。系统约束层给到 15%，是因为如果规则太精简，遇到复杂的工程项目根本写不全；会话记忆层给到 30%，是给足"决策摘要 + 关键词索引"的空间；工作存储层占一半，是因为大部分真实任务的原始材料确实多，不主动管理就会瞬间爆窗。输出预留 5% 是我踩坑之后加上的，后面会专门讲为什么。

2.3 为什么不用"简单截断"

也许你会问：既然窗口有限，直接把最旧的内容丢掉不就行了？大多数对话工具就是这样干的。但问题是，最旧的内容里往往躺着最重要的决策。

我做过一个对照实验：同一个任务，A 组用 FIFO 截断，B 组用 context-mode 的分层管理。任务进行到 30 轮时，A 组的 AI 开始产生前后矛盾的输出，它把早期确定的数据模型推翻了至少两次，而 B 组始终稳定。原因很简单：FIFO 按位置删，不按价值删。一个重要的技术决策和一个临时调试日志挨在一起，按位置删永远先删重要的，因为它更早。

截断还会引发一个隐蔽的问题：AI 不知道东西被删了。它不会告诉你"这部分内容我不记得了"，相反，它会基于残缺的信息自信地编造补全。这种幻觉比"明确承认忘了"可怕得多。context-mode 的解决思路是压缩而非删除，把旧内容变成高度浓缩的决策摘要，放在会话记忆层，每次对话时模型都能看到"之前讨论过什么、结论是什么"，即使细节模糊了，结论还在。

3. 关键实现拆解：消息压缩、召回补偿和遗忘策略

3.1 滑动窗口加摘要压缩的完整管道

context-mode 的核心循环是：感知、压缩、决策、执行。下面这段是主逻辑的简化实现，我用 Python 伪代码展示：

import json from collections import deque class ContextManager: def __init__(self, config): self.system_layer = config["system_constraints"] self.memory_layer = deque(maxlen=config["memory_window_size"]) self.storage_layer = {} self.recall_index = {} self.checkpoint_dir = config["checkpoint_dir"] def ingest(self, new_message): # 1. 新消息进入工作存储层 self.storage_layer[new_message["id"]] = new_message # 2. 判断会话记忆层是否已满 if len(self.memory_layer) >= self.memory_layer.maxlen: self._compress_memory_layer() # 3. 把新消息的关键事实提取出来放入索引 facts = extract_facts(new_message) self._update_recall_index(facts) def _compress_memory_layer(self): # 取最旧的一半消息做摘要 oldest = list(self.memory_layer)[: self.memory_layer.maxlen // 2] summary = summarize_dialogue(oldest) # 保留硬性决策，丢弃过程性内容 for item in oldest: if is_hard_decision(item): self.memory_layer.append(item) # 把摘要作为新条目放入记忆层 self.memory_layer.append({ "type": "summary", "content": summary, "timestamp": now() }) def retrieve(self, query): # 先查索引，再查摘要，最后查工作存储层 candidates = self.recall_index.search(query) if not candidates: candidates = fuzzy_search_summaries(self.memory_layer, query) return candidates

这个循环里的关键动作是_compress_memory_layer。它不直接把最旧的丢掉，而是先把旧内容做摘要，再把摘要放回去。同时有个细节：摘要里要保留"硬性决策"，也就是那些带有明确结论的句子。判断依据很简单，正文里包含"决定、采用、放弃、禁止、必须、保持"这类词汇，或者有明确的 A/B 比较结果。在压缩过程中，AI 可能会把"我们最后决定保留 userId 字段"压缩成"讨论了 userId 字段"，这就不合格。因此我用了一个优先级标记，压缩前先给硬性决策打标签，压缩器看到标签必须保留原始句子结构，只允许去掉修饰成分。

3.2 关键事实检索：用小索引代替向量库

接下来是"取"的部分。工作存储层里的内容默认不驻留，但模型需要用时必须能找回来。最初的方案是给所有片段做 embedding，搞一个向量检索。实践了两天就放弃了——不是向量检索不好，是对于一个个人工具来说太重了，而且中文场景下 embedding 的切词、标点、同义表达都会影响召回准确率，调起来非常耗时。

我简化成了一个两级的轻量索引：

• 一级索引是结构化的"关键事实表"，每次对话中提到文件名、函数名、URL、专有名词、明确的数字参数时，自动提取成{"entity": "user_id", "context": "...", "timestamp": "...", "source_message_id": "..."}这样的条目。
• 二级索引是摘要库的模糊搜索，用简单的编辑距离加关键词命中来匹配，匹配度超过阈值再返回全量摘要。

这个方案的效果出乎意料地好。主要原因在于：LLM 对话中出现的关键信息通常都是有明显特征的——文件名有后缀、函数名有特定格式、参数名是驼峰或者下划线风格。这些特征足够让小索引完成大约 80% 的召回需求，剩下 20% 用模糊搜索兜底，整体已经够用。向量检索的精度优势，在我这种单机小工具场景里根本体现不出来。

3.3 遗忘策略与恢复机制：每步可回滚

上下文管理不能只管"塞"和"取"，还要管"扔"。扔得好不好，直接决定了长会话的质量。我的原则是：可以忘，但必须留痕迹。

每次触发压缩，context-mode 都会在 checkpoint 目录下生成一个快照文件，包含当前三层上下文的完整内容、压缩前的旧内容、压缩后的新内容以及触发原因。文件名带时间戳：

context-mode/checkpoints/2025-06-11-14-32-05-before-compress.json context-mode/checkpoints/2025-06-11-14-32-05-after-compress.json

这个设计让我在出问题时能做"上下文还原"。比如发现某个摘要把重要决策压缩丢了，我可以直接把 before-compress 版本恢复回去，而不是重新跟 AI 解释一遍。这样一来，压缩不再是不可逆的破坏性操作，而是一个有审计记录的管理动作。

除了快照，我还做了一个轻量级的恢复入口：当检测到上下文逻辑矛盾（AI 说了跟已确认决策冲突的内容）时，工具会弹出一行提示，列出冲突的两个来源，让我选择保留哪一个。这个功能最初是手动写的，后来发现触发频率太高，就做成了半自动。

4. 集成实测：把 context-mode 接到日常开发工作流

4.1 配置文件长什么样

context-mode 通过一个 YAML 文件来配置所有参数。这是我这套环境的实际配置：

# context-mode/config.yaml model: context_limit: 128000 # 模型上下文窗口总上限 output_reserve: 6000 # 输出预留 token 数，约等于 3-4 段代码 layer_budget: system: 0.15 # 系统约束层占比 memory: 0.30 # 会话记忆层占比 storage: 0.50 # 工作存储层占比 output: 0.05 # 输出预留 memory_window: size: 24 # 记忆层最多保留 24 条消息 compress_threshold: 18 # 超过 18 条触发压缩 compress_ratio: 0.5 # 压缩时取最旧的一半做摘要 recall: enabled: true fuzzy_threshold: 0.72 # 模糊搜索最低匹配度 max_results: 5 # 单次最多返回的召回片段数 checkpoint: enabled: true dir: "./checkpoints" keep_last: 20 # 最多保留 20 份快照文件

这里有两个参数特别说一下。memory_window.size设成 24，是反复试出来比较合适的值：太小了没意义，几乎每条消息都触发压缩，反而增加开销；太大了又会让摘要间隔过长，中途内容之间缺乏连贯性。recall.fuzzy_threshold默认 0.72，在中文场景下太低的阈值会召回一堆无关片段，太高的阈值又容易漏，0.72 是我测试了 200 多个查询之后取的平衡点。

4.2 实测数据：有管理和没管理的差别

为了让效果可度量，我做了一组对照测试。任务是一个模拟的 Web 后端改需求场景：初始需求是实现用户登录和权限校验，然后连续追加 15 个新需求，包括加缓存、加黑白名单、改数据库字段、增加限流等等。每个需求都要最终落到代码改动里。

最值得关注的是 token 消耗反而更少。这个反直觉的结果其实很好理解：没有管理时，对话越长，AI 越容易在前面的垃圾内容里打转，反复确认同一件事，来回改同一个 bug，这些都是额外的 token 开销。有管理之后，每轮输入更精简，模型的输出也更稳定，减少了无谓的返工。

延迟降低也很好解释：Transformer 生成速度跟输入长度强相关，把输入从几万 token 压到几千 token，生成第一个 token 的时间确实能快不少。

4.3 实际使用中的意外：召回命中率低的问题

集成后第一个星期，我发现一个问题：recall 模块的命中率只有不到 60%，很多时候 AI 明明需要某份旧文档的内容，检索回来的却是一堆无关片段。

排查了半天，罪魁祸首有三个：第一，对话里提到的文件名和我存放在工作存储层里的文件名不一致，比如对话里说"账号系统的配置文件"，而文件实际叫auth_settings.yaml；第二，中文分词在关键词提取阶段经常被切得支离破碎，比如"用户权限"被拆成"用""户权限"，索引里根本没存对；第三，模糊搜索对大小写和全半角符号太敏感，userId和user_id匹配不上。

针对这三个问题做了修复：提取实体时增加了同义归并规则，把userId、user_id、用户 ID归并到同一个实体；模糊搜索前先做规范化，统一转小写、统一标点；召回失败时允许降级去查完整对话记录，不再追求一次命中。修完之后召回率从 60% 提升到了 88%，虽然不能 100%，但配合 AI 的推理能力已经足够实用。

5. 我踩过的几个坑和调整后的使用规范

5.1 坑一：过度压缩，把关键指令压没了

用了一个月之后我发现，最危险的不是截断，而是压缩器"自作聪明"。有一回我在做数据迁移脚本，明确讨论过"迁移后保留原始数据的字段原值，不允许做类型转换"，这是核心业务硬规则。结果压缩摘要时模型把这句话概括成了"数据处理时注意字段类型"，等于把最关键的限制条件彻底丢了。后续所有代码都按照"类型要转换"来写，完全反了。

修复方案是引入"决策保留白名单"。在系统约束层里我手动维护了一张表，把所有硬规则以原文形式存放，压缩器在任何情况下都不允许改写这张表里的内容。同时，每当对话中出现"我要求""必须""禁止""无论如何"这类强约束词时，自动把整句挪进系统约束层。压缩器可以压缩过程性描述，但不准碰约束性语句。

5.2 坑二：频繁召回导致上下文漂移

另一个坑是检索模块太"勤快"。原先的设计是只要工作存储层有相关内容就召回，后来发现每轮对话可能要触发三四次召回，每次召回的内容都要塞进上下文窗口，窗口很快又满了，于是又触发压缩，压缩又产生新的摘要，摘要又触发新的召回……体系变成了一套自我消耗的循环，AI 的输出反而越来越不稳定，这就是上下文漂移。

解决办法是给召回加一个抑制机制：单轮对话内，同一个实体的召回结果只允许添加一次；召回内容占用的 token 直接计入工作存储层预算，用完就没了，不允许超支；只有当 AI 明确表达"信息不足"时才允许触发主动召回。简单说就是：召回到够用为止，不要无限投喂。

5.3 调整后的五条使用规范

工具只是辅助，真正决定性的是人的使用习惯。跑了两个月之后，我把自己的使用规则沉淀成了五条：

• 每个任务开始前先写决策日志。哪怕只有三行：目标、约束、已排除的方案。这条日志放入系统约束层，AI 永远看得到。
• 重大决策用固定格式确认。格式是"决定：xxx，原因：xxx，影响范围：xxx"。格式化的内容更容易被识别、被压缩、被检索。
• 不要请求 AI 重复已有信息。很多人习惯说"把我们之前讨论的再总结一遍"，这在没有管理工具时会消耗大量上下文预算。在 context-mode 下，摘要已经存在记忆层里，直接在回复中引用即可。
• 每轮结束前让 AI 输出一段"本轮结论"。这样就算压缩器判断失误，最后留下的结论也是完整的。
• 定期做一次"大脑复位"。会话太长时，关闭当前对话，加载 checkpoint 重新开一个新会话，把摘要作为初始上下文。不要让一个会话无限变长。

6. context-mode 的下一步：让记忆分层更细

6.1 想做的：运行时状态与长期知识分离

现在这套系统已经能解决我的日常需求，但我心里清楚它还有明显的改进空间。最大的问题是：当前的三层结构里，"会话记忆层"只管当前会话，跨会话的经验没有沉淀。我做过的项目、写过的最佳实践、踩过的坑，这些内容换了会话就归零了。

下一步我打算增加一个"长期知识层"，跟运行时状态彻底分开。它的定位相当于个人知识库：存的是跨项目复用的经验，比如"这个团队的代码风格是下划线命名""数据库连接必须用连接池""不要在生产环境执行 CREATE INDEX"这类规则。长期知识层在每次会话初始化时按需加载，不占固定预算，只有真正被需要时才进入上下文。

实现上也不复杂，把原来只按文件名索引的实体表扩展成带标签的知识条目，每天跑一次自动化整理，从检查点文件里抽取高频出现的规则片段。这项工作我刚开始做，目前的坑是"怎么判断一条经验是长期有效还是只适用于某个项目"，我暂时用了一个粗暴的标准：同一个规则在三个不同项目中重复出现，才进入长期知识层。

6.2 你可以怎么用它

如果你想直接上手，我的建议是：不要全盘照抄，从最小版本开始。先用配置文件控制预算，只保留系统约束层和截断机制，跑两个项目感受一下；再逐步加上压缩和召回。这套工具的设计取舍未必适合所有人，但"分层管理"这个思路是通用的。

代码和相关文档我整理完成后会放到仓库里，到时候会配一个使用示例和迁移指南。如果你也在跟 AI 长对话的"失忆"问题搏斗，不妨先做一件最简单的事：在下一次对话的最开头用一条系统消息写明目标、约束和已排除方案；每次讨论出结论后，把结论用固定格式粘贴进去。就这一个习惯，足以减少相当一部分上下文失控的问题。

最后再分享一个小技巧。我一度纠结于要不要把所有历史对话都保存下来，后来发现没必要。检查点文件留最近 20 份就够了，更早的对话直接删除，因为决策摘要已经在当前会话里了。真正有价值的不是历史全文，而是从历史里提炼出的结论。这个认识帮我省下了一大堆存储空间，也让每个新会话更轻、更稳。