context-mode：给本地对话工具加上可切换的上下文管理模式

最近在做一个本地的命令行AI助手，发现一个特别尴尬的问题：聊到第30轮的时候，模型开始把我两个小时前交代的约束忘得干干净净。我明明把历史消息全部塞给它了，但它就是不认账。直到我把context-mode这个概念理顺，实现了一套可以手动切换的上下文管理策略，这个问题才算是彻底解决。这期内容我就把整套思路和代码拆开讲清楚，适合那些在折腾自有AI工具、或者想深入理解对话上下文机制的人参考。

先说结论：context-mode本质上解决的是“上下文资源分配”的问题。你的模型窗口就那么大，历史越长，有效信息被稀释得越厉害。与其无脑塞全部历史，不如设计两种模式——一种全量保真，适合短对话；一种智能压缩，适合长对话。这个思路不限于LLM，任何需要状态管理的系统都能用上。

1. 为什么要折腾context-mode：一次会话里的丢三落四

我最初的做法特别简单粗暴：把每一条用户消息和助手回复都追加到一个数组里，构建提示词的时候直接全部拼接。在最开始的十几轮里效果还行，但一旦对话超过一段时间，问题就冒出来了。

1.1 全量历史的稀释效应

举个例子，我在一次会话里先让模型以“简洁、专业”的风格回复，然后聊了二十轮技术细节，中间还夹杂了几次文件路径的修改。到第三十轮我问它“刚才说的第一个方案的缺点是什么”，它居然开始一本正经地编造，给出的方案和我最初描述的根本不是一回事。原因在于，那个最初的约束已经被淹没在几千个token的中间段落里了，注意力机制天然偏向靠近提示词末尾的内容。

我拿tiktoken数了一下，那段四十轮的对话历史已经超过8000个token，而模型的有效上下文窗口虽然标称很大，但真正能稳定约束行为的其实就是窗口后半段的几千个token。前面那些重要指令，早被后续的技术讨论挤出了注意力范围。

1.2 丢上下文与乱上下文的双重打击

更麻烦的是乱上下文。当历史里同时存在“聊天风格应该轻松”和“聊天风格应该严肃”这类互相矛盾的指令时，模型常常会取后面那一条，无视前面那一条，哪怕前者是用户特别强调过的。这种矛盾不一定是字面冲突，也可能是某个早期临时参数在后来被遗忘了，导致后续回复完全不匹配。

我当时就在想，如果有一个明确的“上下文模式”开关，让用户自己决定当前轮次重视哪些历史记忆，而不是让模型去混沌中自己猜，那该多好。这就是context-mode最初的动机。

2. context-mode的核心设计：全量模式与摘要模式

经过几轮重构，我把context-mode设计成两种明确的状态，类似相机的手动挡和自动挡。用户可以通过指令随时切换，切换逻辑并不复杂，但效果立竿见影。

2.1 全量模式：LongForm，短对话的保真方案

全量模式（我内部叫LongForm）做的事情就是把所有历史消息原样拼接进提示词，不做任何删减和改写。这个模式适合对话轮次少、关键约束密度高的场景。因为模型看到的都是原始表述，语义保真度最高，不会因为压缩损失细节。

实现上，这个模式只需要一个数组维护消息列表，然后构建时直接遍历即可。代码简单到不值得单独写一个类，但它的价值在于和摘要模式形成对比。

2.2 摘要模式：ShortForm，长对话的压缩方案

摘要模式（ShortForm）的核心思想是：不再把冗长的历史逐字传递给模型，而是由本地维护一份动态更新的对话摘要，每次构建提示词时只携带这份摘要加上最近几轮完整对话。

这里有个关键取舍：摘要不是给模型看的，而是由用户或离线小模型生成的。我用的做法是，每当模式切到ShortForm，或者每追加五轮对话，就把从上次摘要位置到当前的全部消息交给一个便宜的本地模型（比如一个较小的嵌入模型或者简单的规则抽取器）生成一段三百字以内的要点总结。然后清空中间消息，只保留摘要和最后两轮完整对话。

对比一下这两种模式的表现：

这个设计最妙的地方在于，两种模式互不干扰。你可以在严肃的技术讨论中用全量模式，在闲聊或大规模代码复盘时切到摘要模式。

3. 实现一个可切换的上下文管理器

光有概念不行，得落地。下面这套代码我用Python写了一个完整的ContextManager，跑了快一个月，稳定性和效果都符合预期。设计上参考了常见聊天套接字和消息队列的思想，但剥掉了所有外部依赖，方便你在自己的项目里直接复用。

3.1 核心类结构与初始化参数

import tiktoken from collections import deque from typing import List, Dict, Optional class ContextManager: def __init__( self, system_prompt: str = "You are a helpful assistant.", token_budget: int = 4000, max_history_pairs: int = 5, summarizer=None, ): self.system_prompt = system_prompt self.mode = "long" # "long" 或 "short" self.token_budget = token_budget self.max_history_pairs = max_history_pairs self.summarizer = summarizer self._long_history: deque = deque(maxlen=20) # 全量历史 self._short_summary: str = "" self._short_recent: deque = deque(maxlen=2) # 摘要模式保留的最近轮次 self._tokenizer = tiktoken.get_encoding("cl100k_base") self._last_switch_at = 0

几个初始化参数解释一下：

• token_budget是构建提示词后允许占用的最大token数，我根据自己的模型窗口设定为4000，你换成128k的模型可以拉高。
• max_history_pairs控制全量模式下最多携带几轮对话，超出部分会被截断，而不是无限堆积。
• summarizer是一个可调用对象，接收消息列表，返回字符串摘要。没有摘要器的场景下，ShortForm会自动退化为只保留最近两轮的全量模式。

3.2 模式切换与消息追加

def switch_mode(self, target: str): if target not in ("long", "short"): raise ValueError("mode must be 'long' or 'short'") if target == self.mode: return if target == "short" and self.mode == "long": # 切换到摘要模式时，立即压缩长历史 self._short_summary = self._summarize_history(self._long_history) self._long_history.clear() self.mode = target self._last_switch_at = len(self._get_all_messages()) def add_message(self, role: str, content: str): if self.mode == "long": self._long_history.append({ "role": role, "content": content, }) else: self._short_recent.append({ "role": role, "content": content, }) # 一旦最近两轮满了，就把最早的消息并进摘要 if len(self._short_recent) >= 2: old = self._short_recent.popleft() self._short_summary = self._summarize([self._short_summary, old], max_tokens=200)

这段代码有个小心机：切换到短模式时，先对全量历史做一次摘要，然后立刻清空长历史，避免旧消息继续占据内存和token。之后每次新消息进来，都坚守“最多保留最近两轮完整对话”的规则，其余历史一律通过增量摘要收敛。

3.3 构建最终提示词

def build_prompt(self) -> List[Dict[str, str]]: messages = [{"role": "system", "content": self.system_prompt}] if self.mode == "long": for m in self._long_history: messages.append(m) else: if self._short_summary: messages.append({ "role": "system", "content": f"[Previous conversation summary] {self._short_summary}", }) for m in self._short_recent: messages.append(m) # 超出预算时按从旧到新的顺序截掉中间部分 while self._count_tokens(messages) > self.token_budget and len(messages) > 2: messages.pop(1) return messages

这个while循环是我踩了多次坑才想清楚的关键点。一开始我写了根据消息体量估算的裁剪逻辑，结果频繁把最新轮次给裁掉了，模型根本不知道用户说了啥。后来改成始终从索引1开始删（保留system和最新消息），只删中间的旧轮次，才真正符合直觉。

3.4 摘要器与token计数

def _summarize_history(self, history: deque) -> str: if not self.summarizer: return "" combined = "\n".join(f"{m['role']}: {m['content']}" for m in history) return self.summarizer(combined) def _summarize(self, items: List[str], max_tokens: int) -> str: if not self.summarizer: return items[-1] if items else "" return self.summarizer("\n".join(items)) def _count_tokens(self, messages: List[Dict[str, str]]) -> int: text = "\n".join(m["content"] for m in messages) return len(self._tokenizer.encode(text))

生产环境里，summarizer可以直接接一个开源的轻量模型（比如本地跑的embedding模型或者更小号的对话模型）。我没有在代码里绑定特定库，就是为了让你自由替换。

4. 实测过程中的坑：token计算、截断策略与模式切换时机

任何项目只要一跑真实场景，漏洞就全冒出来了。以下是我在context-mode落地过程中记录的三个最有代表性的问题，每个都花了大半天才定位。

4.1 token数量不一致引发的中途截断灾难

我一开始用角色字符串长度估算token，比如一句话10个汉字算10个token，结果在实际调用API时频繁收到超出上限的错误。后来换成tiktoken才意识到，中英文混排的token开销差异极大，一个英文单词可能只占1到2个token，而一段中文代码注释可能占据好几十。

这个估算不准直接导致我的裁剪逻辑在边界上疯狂误删，要么删光了用户刚发的消息，要么留着一条超长的代码块什么都不干。结论就是工具必须用真实tokenize结果作为截断依据，别舍不得那一次编码运算。

4.2 自动切换时机的权衡：别让摘要器成为瓶颈

最初的版本里，我把“每超过10轮就自动切到短模式”写成了硬逻辑。结果发现，一旦切过去，摘要器需要处理大量历史，本地小模型的推理时间长达好几秒，用户看到的是明显的卡顿。

调整之后，我把切换改成显式指令触发，由用户自己决定何时执行。同时我保留了“切换前先看token预算”的检查：

def smart_switch(self): usage = self._count_tokens(self.build_prompt()) if usage > self.token_budget * 0.8: self.switch_mode("short") else: self.switch_mode("long")

这个smart_switch拿80%阈值作为触发线，既避免了每次都做昂贵的摘要，也不会让提示词超长。我测试下来，在本地小模型上，摘要耗时控制在0.5秒以内时，体验最自然。

4.3 摘要本身的上下文遗失：反复提及与渐进压缩

第三个坑比较隐蔽。摘要模式运行久了之后，我发现模型开始遗忘一些早期的重要约束，比如“不允许生成超过十行的代码”。我查了一下摘要器生成的文本，发现它确实忠实记录了对话内容，但在多轮增量压缩的过程中，那些“约束类”信息被后续技术细节逐渐挤掉了。

解决办法是给摘要器增加一个优先级提示，让它在压缩时优先保留包含以下关键词的句子：约束、必须、禁止、要求、不要、风格、路径、版本。我直接在摘要器提示词里写死了这些词，实测保留率从70%提升到95%以上。

def _summarize(self, items: List[str], max_tokens: int) -> str: if not self.summarizer: return items[-1] if items else "" priority_terms = ["约束", "必须", "禁止", "要求", "不要", "风格", "路径", "版本"] weighted = [] for item in items: score = sum(1 for term in priority_terms if term in item) weighted.append(f"[priority={score}] {item}") return self.summarizer("\n".join(weighted))

优先级得分并不会直接改变内容，但它能在摘要器的输入里把重要句子排在前面，从而诱导模型优先概括这些内容。这个技巧简单有效，强烈推荐。

5. 与现成对话工具的对照体验：什么时候该用哪套方案

很多人可能会问，我现在用ChatGPT或Claude的官方客户端，它们本身就带着上下文记忆，为什么还要自己折腾context-mode？这个问题我在实际对比之后有了明确答案。

5.1 官方工具的隐藏式管理 vs 手动开关

官方产品通常采取自动的上下文管理，比如根据对话轮次自动折叠历史，或者由模型自己判断是否需要查看旧消息。好处是无感，坏处是不可控。以前我在一个连续12小时的长会话里，模型突然把一个小时后才提到的要求当成默认设定，导致中间阶段的回复全部跑偏。

使用我自己的context-mode后，我可以在关键节点手动切回LongForm，强制模型重新读取完整历史，不需要依赖它自己的注意力机制。这种“确定性优先”的做法，对于追求结果可复现的开发场景特别有价值。

5.2 我的使用习惯：跨会话缓存与续聊

另一个我长期稳定使用的场景是跨天续聊。每天开始新会话时，模型完全没有昨天的记忆。这时候我把昨天的_short_summary序列化到本地JSON文件，第二天加载进来作为system prompt的一部分。相当于给模型注入了“昨天到底聊了啥”的压缩记忆，有效减少了重复陈述背景的烦琐。

import json def save_context(cm: ContextManager, path: str): data = { "mode": cm.mode, "summary": cm._short_summary, "long_history": list(cm._long_history), "short_recent": list(cm._short_recent), } with open(path, "w") as f: json.dump(data, f) def load_context(path: str) -> ContextManager: with open(path, "r") as f: data = json.load(f) cm = ContextManager() cm.mode = data["mode"] cm._short_summary = data["summary"] cm._long_history = deque(data["long_history"], maxlen=20) cm._short_recent = deque(data["short_recent"], maxlen=2) return cm

这一套序列化逻辑我到现在还在用，唯一的代价是每次续聊前需要把摘要重新喂给模型，但这几十个token的成本完全可以接受。

6. 把context-mode再向前一步：动态阈值与混合模式

写到最后，再分享一个我目前正在实验的进阶形态。现在的模式切换是二元的，要么全量要么摘要。但我发现真实对话是渐变的：前五轮完全不需要摘要，二十轮之后才开始出现记忆压力。所以我在尝试一种动态混合模式，根据token使用率自动调整“保留最近完整轮次”的数量。

6.1 动态保留轮次

思路很简单：初始化时允许一个full_history_turns参数，比如3轮。当token预算还剩很多时，保留5轮完整历史；当预算紧张时，只保留1轮完整历史，其余全部压进摘要。

def build_hybrid_prompt(self, max_turns: int): messages = [{"role": "system", "content": self.system_prompt}] all_history = list(self._long_history) + list(self._short_recent) recent_turns = max_turns * 2 if len(all_history) > recent_turns: old_part = all_history[:-recent_turns] messages.append({ "role": "system", "content": self._summarize([self._short_summary] + old_part), }) for m in all_history[-recent_turns:]: messages.append(m) return messages

6.2 实测效果与局限

跑了两周之后，我发现混合模式在“代码评审”这类任务上表现最好，因为最近几轮代码变更需要精确引用，而更早的设计讨论只需要大意。但在“逐行讲解算法”这类全程依赖细节的场景里，混合模式仍然不够，必须手动切回纯全量模式。

所以最终结论是：context-mode的价值不在于全自动，而在于把选择权交还给使用者。官方工具给你的是黑盒优化，我做的这个实现给你的是透明开关，你知道每一步发生了什么，也就知道该在哪里动手调整。如果你也在烦AI助手记性差，不妨照着这套思路，先给最低成本的全量模式和摘要模式做起来，再慢慢调整压缩策略。踩过几个坑之后，你大概率也会觉得这个小小的模式切换功能，比什么花哨提示词都来得实在。