先聊一个有意思的观察。我搜 context-mode 这个关键词时发现圈子里起码有三种同名概念编辑器里的上下文模式、终端里的上下文执行模式还有 LLM 应用开发里的上下文管理模式。今天这篇只讲第三种也是目前最值得讲的一种。做聊天机器人、Agent、知识库问答的朋友大概率都遇到过同一个尴尬——对话一长模型就开始“失忆”不是记错前面的信息就是干脆无视系统约束而 Token 费用还在噌噌往上涨。context-mode 本质上是给大模型的对话记忆做的一套动态管理方案按模式自动决定哪些历史该留、哪些该压缩、哪些该检索。它不是某个框架的专有功能而是一组可以直接写进你自己代码里的工程套路。1. 为什么大家都在聊 context-mode1.1 上下文窗口不是“越大越好用”先说一个很多新手容易误判的点模型标的上下文窗口数字再大也不代表你能把全部内容无脑塞进去。拿常见的 128K 窗口模型来说真正能放心交出去的历史记录通常只有 60%70%因为你还要留出模型回复的空间还要考虑系统提示、工具返回结果、中间拼接格式带来的额外损耗。更重要的是上下文窗口越大模型对中间位置的注意力就越差。这个现象研究论文里叫 lost in the middle指大模型在处理超长上下文时对位于开头和结尾的信息利用率很高但对中间部分经常“视而不见”。换句话说你不做上下文管理哪怕窗口还有空余模型也已经在靠猜回答问题所谓的长对话能力只是一张有洞的网。1.2 Token 成本随长度非线性上涨用过云端模型 API 的人应该都有感觉输入 Token 越多账单越难看。多数厂商的计费逻辑是按输入 Token 数量计价对话一旦无限累积第一轮花 1 块钱的请求到第一百轮可能就要花 20 块。这不是多轮对话特有的问题而是所有长上下文应用的共同痛点。我测过一个客服场景不管理上下文的对话在第 30 轮时一次请求消耗了 8000 多 Token接入 context-mode 后历史记录被压缩摘要、溢出部分转成检索同一轮对话的 Token 消耗降到了原来的三分之一左右而且回复质量没有明显下降。1.3 长上下文的“不稳定性”比想象中严重除了成本和注意力问题还有一层更隐蔽的风险模型行为随上下文长度改变。同一个模型短上下文下严格遵守“只输出 JSON”的指令放到 50K 以上的长上下文里偶尔就会开始输出废话或者额外的 Markdown 代码块。这种“行为漂移”在自动化流程里非常致命因为它不是偶发错误而是结构性失效。context-mode 要解决的核心就是这个把上下文长度控制在一个模型行为最稳定的区间让每一次请求的可控性趋近短对话。1.4 context-mode 到底管什么一句话总结context-mode 是一个运行在 LLM 应用层的“记忆调度器”它接管对话历史的增删改查在每次请求发出前决定当前这个时刻哪些信息必须出现在 Prompt 里哪些可以被压缩哪些应该进向量库按需召回。它通常包含四个动作裁剪trim、摘要summarize、检索retrieve、重组rebuild。这四件事可以独立使用也可以组合成多种模式下面逐个展开。2. 四种主流实现模式与原理拆解2.1 紧凑模式用摘要换空间紧凑模式Compact Mode是所有方案里最简单、也最容易误用的一个。它的核心逻辑一句话就能说清当对话历史超过预设阈值调用一次 LLM把之前的对话压成摘要然后用摘要替换原始消息。原理上它做了一件事——“信息蒸馏”。原始对话里可能有一百轮用户和助手你来我往里面有大量寒暄、重复确认、冗余表达真正对后续回复有价值的信息往往只占一小部分。摘要就是这个蒸馏过程把“用户最初想解决什么问题、已经确认过什么结论、还剩哪些没完成”这种核心信息提炼出来。但这里有个关键点摘要模板决定了下限。如果只是丢一句“请总结以上对话”模型通常会输出一大段平平无奇的内容丢掉的恰恰是最关键的细节。我推荐在摘要任务里内置结构化字段要求模型输出 JSON包含用户目标、已提供的关键信息、已确认项、未完成项、当前代码/文档状态这样后续恢复上下文时会有用得多。适合场景客户支持对话、多轮代码调试、任何“过程不重要重要是结论和待办”的对话。2.2 滑动窗口模式只留最近几轮滑动窗口模式Sliding Window Mode更简单直接只保留最近 N 轮对话更早的全部丢弃。它模仿的是人类的短期记忆——太远的细节本来就不重要当前任务通常只依赖近期上下文。我用过一段时间的滑动窗口处理工具调用场景效果出乎意料地好。Agent 在执行任务时真正影响下一步决策的往往就是最近三五轮的观察结果和工具返回值早期那些“初始化配置”“定义目标”的消息丢了对结果几乎没有影响。滑动窗口实现成本最低不额外调用模型也不需要向量库纯粹在消息列表上做切片。但是滑动窗口有一个严重副作用它会把“系统级约束”一起丢出去。如果你把系统提示中的所有约束都放在 system message 里通常情况下系统消息不参与滑动这部分还安全。可如果你习惯了把一些关键指令当作对话开头塞进 user 消息里很多人为了调 prompt 方便这么干滑动到后面这些约束就全没了模型会表现出“人设漂移”——开始变得不像原来的助手甚至忘记自己不能做什么。所以滑动窗口的正确用法是把不可遗忘的约束固定在系统提示里滑动窗口只负责管理 user/assistant 的对话历史。2.3 检索增强模式全量保存按需召回检索增强模式Retrieval Mode是四种模式里最接近工程上“记忆系统”做法的一种。它的思路是不急着丢也不急着压缩把每一轮对话完整落库每次请求前用当前 query 去检索相关历史片段只把命中片段拼进 Prompt。这种模式和 RAG检索增强生成非常像本质就是一个退拽式记忆库。实现上有三个细节直接影响效果一是切块不能按固定长度硬切。对话按轮次保存每轮是一个独立片段而不是把多个轮次拼成一个大文本再切块。按轮次切块的语义边界清晰检索命中后拿到的直接是一段完整对话而不是一句话被拦腰截断。二是需要给每个片段打标签。用向量召回的相似度结果太粗糙我试过几次“看似相关其实错位”的情况比如用户问“之前说的费用是多少”向量检索可能把“费用包含什么”和“费用怎么支付”都召回模型反而被误导。正确的做法是把对话按“话题”“用户意图”“涉及实体”打标签检索时先过滤标签再向量排序。三是片段要附带元信息。每条检索命中的记录至少要包含时间戳、角色、话题标签这样拼进 Prompt 后模型才知道这段历史发生在什么时候不至于把过时的信息当成当前状态。2.4 分层混合模式把上面三种串起来真正生产环境最常用的是分层混合模式Hierarchical Mode。它同时利用短期记忆、中期压缩、长期检索大致动作链是最近的对话原样保留保证模型能精确拿到最新上下文超过近端窗口的历史触发摘要压缩保留核心脉络所有历史记录全量入库支持检索当摘要里缺细节时按需召回原文。你可以把它理解成一个“三级缓存”L1 是热数据最近 N 轮完整消息读取最快最准L2 是温数据经过压缩的摘要提供中粒度记忆L3 是冷数据全量历史向量库平时不占用上下文需要时再按关键词或语义拉回现场。这套设计能同时缓解三个痛点热层保证连续性、温层控制 Token 总量、冷层防止关键细节永久丢失。代价是复杂度明显上升你需要一个能写能查的存储、一套压缩触发策略还得做好摘要与原始消息之间的关联追溯。3. 手写一个可用的 context-mode核心代码与参数计算3.1 设计之前先定预算很多人一开始就写代码结果写出来的 memmory 管理模块无比复杂却连“多少 Token 该触发压缩”这个最基础问题都没想清楚。正确的做法是先定预算。给你一串我自己实际用下来的计算顺序第一步确定模型上下文窗口总量。假设你用的是 128K 窗口模型。第二步乘以安全系数 0.6得到这次请求里你愿意占用的“总操作空间”。为什么要留 40%因为输出也要 Token工具调用过程中还会产生中间结果系统提示有固定开销拼接格式也有损耗。安全系数取 0.6 是我试过比较保守的配置追求极限吞吐可以放宽到 0.7但超过 0.8 基本就是在赌运气。第三步从总空间里减去回复预留。如果你把 max_tokens 设为 4096那就减去 4096剩下的才是“历史预算”。第四步再减去系统提示的固定长度。假设系统提示 600 Token继续扣掉。第五步给“突发拼接”留 5%10% 缓冲。这个缓冲是留给检索结果、工具返回格式化后发现的额外 Token。算完你手上就有了一个 hard limit历史记录绝对不能超过多少 Token。这个数字就是后续所有触发判断的唯一依据。3.2 核心实现一个够用的 ContextManager我写过一个简化版实现你改造一下就能塞进现有代码。先看核心类import json import time from typing import List, Dict, Optional class ContextManager: def __init__( self, # 模型上下文窗口总量Token model_window: int 128000, # 安全系数 safety_ratio: float 0.6, # 回复预留 Token response_budget: int 4096, # 系统提示 Token 占用由外部估算后传入 system_budget: int 600, # 压缩触发比例历史占预算的多少时开始压缩 compact_threshold: float 0.7, # 压缩后历史要降到预算的多少比例 compact_target_ratio: float 0.25, # 最近多少轮不压缩始终保留原文 hot_rounds: int 10, # 模拟向量检索函数实际可替换成你的向量库 retriever: Optional[object] None, ): self.max_history_tokens int( model_window * safety_ratio - response_budget - system_budget - model_window * safety_ratio * 0.05 # 拼接缓冲 ) self.compact_threshold int(self.max_history_tokens * compact_threshold) self.compact_target int(self.max_history_tokens * compact_target_ratio) self.hot_rounds hot_rounds self.retriever retriever self.messages: List[Dict] [] # 原始消息 self.summary: Optional[str] None # 中程摘要 self.stored_segments: List[Dict] [] # 全量片段库模拟向量库存表 def _estimate_tokens(self, text: str) - int: # 粗略估算中文 1 字约 1~1.5 token英文 1 词约 1.3 token # 生产环境建议用 tiktoken 或模型自带的 tokenizer这里只是兜底 char_count len(text) return int(char_count * 0.8) if self._contains_cjk(text) else int(char_count * 1.1) def _contains_cjk(self, text: str) - bool: return any(\u4e00 ch \u9fff for ch in text) def add_message(self, role: str, content: str, meta: Optional[Dict] None) - None: msg { role: role, content: content, ts: time.time(), meta: meta or {}, } self.messages.append(msg) # 同步写片段库 self.stored_segments.append(msg) # 检查是否需要压缩 if self._current_history_tokens() self.compact_threshold: self._compact() def _current_history_tokens(self) - int: total 0 if self.summary: total self._estimate_tokens(self.summary) visible self.messages[-self.hot_rounds * 2:] for msg in visible: total self._estimate_tokens(msg[content]) return total def _compact(self) - None: # 取出所有非热点消息作为摘要原材料 non_hot self.messages[:-self.hot_rounds * 2] if not non_hot: return raw_text json.dumps(non_hot, ensure_asciiFalse, defaultstr) # 真实项目里这里调用 LLM返回结构化 JSON 摘要 new_summary self._summarize_with_llm(raw_text) if self.summary: new_summary f{self.summary}\n{new_summary} self.summary new_summary # 保留热点消息其余从内存消息列表释放 self.messages self.messages[-self.hot_rounds * 2:] self._log_compact(raw_text, new_summary) def _summarize_with_llm(self, raw_text: str) - str: # 这是一个抽象接口实际调用你的模型 # 返回建议保持 JSON 结构 # {user_goal: ..., confirmed: [...], pending: [...], key_state: {...}} # 示例返回真实场景请换成语义摘要后的结构化结果 return json.dumps({ user_goal: 待确认, confirmed: [], pending: [], key_state: {} }, ensure_asciiFalse) def _retrieve(self, query: str, top_k: int 5) - List[Dict]: if self.retriever is None: return [] # 假设 retriever 有 search_segments(query, top_k) 方法 return self.retriever.search_segments(query, top_k) def build_prompt(self, system_prompt: str, new_query: str) - List[Dict]: # 检索召回 retrieved self._retrieve(new_query, top_k5) retrieve_block \n.join( f[历史片段 {i}] ({seg[ts]}) {seg[role]}: {seg[content]} for i, seg in enumerate(retrieved) ) prompt [ {role: system, content: system_prompt}, ] if self.summary: prompt.append({role: system, content: f历史摘要{self.summary}}) # 热点消息原样拼接 for msg in self.messages[-self.hot_rounds * 2:]: prompt.append({role: msg[role], content: msg[content]}) if retrieve_block: prompt.append({role: system, content: f相关历史片段\n{retrieve_block}}) prompt.append({role: user, content: new_query}) return prompt def _log_compact(self, raw_text: str, new_summary: str) - None: # 压缩是改写记忆必须有日志否则线上问题无法复盘 print( json.dumps({ event: context_compact, ts: time.time(), raw_len: len(raw_text), summary_len: len(new_summary), }, ensure_asciiFalse) )这段代码里你重点看四个方法_compact负责触发压缩build_prompt负责组装最终 Prompt_retrieve提供检索能力_log_compact保证每次压缩有迹可循。真实项目里_summarize_with_llm要换成对你所使用模型的真实调用retriever换成向量数据库的客户端。3.3 参数怎么定128K 窗口的完整计算过程拿上面代码的默认参数跑一遍你就能看到完整的预算推导模型窗口 128000安全系数 0.6总操作空间 76800。减去回复预留 4096剩余 72704。减去系统提示 600剩余 72104。减去拼接缓冲 5%剩余约 68498。这个就是max_history_tokens。触发压缩阈值68498 × 0.7约 47949。也就是说当历史摘要加最近热点消息估到 4.8 万 Token 左右时就该触发压缩了。压缩目标68498 × 0.25约 17125。压缩后历史预算大约 1.7 万 Token相当于给后面的新对话留出了大约 3 万 Token 的成长空间。这个流程里最容易出问题的地方是真实 Token 估算。我上面代码用的字符估算只适合快速原型生产环境请务必用模型对应的分词器。不同模型的分词器差异很大同一个中文字符串A 模型的 tokenizer 算出来可能是 800 TokenB 模型可能就变成 1200 Token误差到 30% 以上毫不奇怪。3.4 接入 Agent 时要注意的两个细节第一工具调用消息不要进入长期记忆。Agent 每轮可能调用多个工具这些工具参数和返回值往往是临时数据一旦任务完成就没有复用价值。把这些消息进入全量片段库不仅浪费存储还会让检索结果里混入大量“过期的环境快照”干扰模型判断。我的习惯是普通对话消息进记忆系统工具调用消息只留在滑动窗口内滑动溢出后直接丢弃。第二系统提示中要写明“什么是当前最重要的状态”。这个技巧来自一次惨痛教训——我发现压缩摘要后模型经常分不清哪些信息是用户的核心诉求哪些只是沿途提到的边角料。后来我在系统提示里强制加了一段“用户最新一条消息中提到的目标优先级最高历史摘要中的待办事项次之检索片段仅作参考。”加了这句之后回复质量明显稳定下来说明上下文管理模式再优秀也离不开显式的指令引导。4. 实战踩坑这5个坑我帮你踩过了4.1 摘要越压越废关键细节全丢最开始我用的是“请用两百字总结以上对话”这种原始模板连续压几轮之后摘要里只剩一堆空话“用户想要一个支持多用户协作的任务面板”这种核心需求还在但“用户明确说不要用看板视图要列表视图”这种具体约束被丢得一干二净。排查后发现不是模型不聪明而是提示词没有引导模型保留“排除项”。类似“用户不要什么”“用户否定了什么方案”这类信息在压缩时天然容易被忽略因为它们不像“用户要什么”那样是正向信息但对后续回复的影响同样关键。解法很简单在摘要模板里加一个强制字段negative_requirements用户明确否定的内容。从那之后压缩丢信息的概率大大降低。还有一个替代方案是“差分摘要”每次压缩时除了输出摘要本身还要输出“相对上一版摘要新增了什么、删除了什么”成本略高但可追溯性极强。4.2 检索召回“看似相关其实错位”检索增强模式上线后的第一个效果问题不是召回太少而是召回太杂。用户问“银行卡什么时候扣款”向量检索召回的可能是“如何绑定银行卡”“扣款失败怎么办”“支持哪些银行卡”等多条相似片段。这些片段单独看都和“银行卡”相关却都不是当前需要的“扣款时间规则”。我判断问题的根子在于纯向量相似度对“意图粒度”不敏感。改进方案是引入意图标签过滤每存入一个片段先用 LLM 打标签比如“支付方式”“退款流程”“账户安全”检索时先用用户的 query 让一个小模型判断所属标签再在对应标签的片段集合里做向量排序。这套组合在实测里把检索精确率提升了接近一倍。4.3 滑动窗口把“人设”滑没了有段时间我在 Agent 里用滑动窗口处理历史窗口大小设为 20 轮。表面看起来一切正常直到某天模型开始在回复里夹带“作为 AI 助手我无法直接操作你的系统”——这句话出现在工具调用型 Agent 里意味着模型把对自己的身份设定给忘了。排查到最后发现约束它“你是具有系统操作权限的智能体可以直接执行命令”这段设定被写在了第一轮 user 消息里随着滑动窗口滚动它被排除了。这个坑提醒我凡是“不可遗忘的约束”必须放到 system prompt 或固定的消息块里绝不能放在会参与滑动的历史消息中。正确做法是把身份、能力边界、输出格式要求全写进系统消息滑动窗口只管 user/assistant 的交流内容。4.4 Token 估算不准不同模型差异很大做 Token 预算时我先用一个模型的分词器算出的数值定了阈值后来换了个国产模型同一个对话的 Token 数直接翻了一倍压缩逻辑频繁触发对话体验变得特别“神经质”——对话历史经常被压缩用户刚说完的话因为溢出被强制塞进摘要每轮都在丢信息。后来我做了个统一抽象层每个模型接入时先校准 token 估算函数确保历史预算里的数值和实际模型计费/窗口判定用的是同一把尺子。校准方法不复杂拿一百条真实对话文本分别用预估函数和真实 tokenizer 跑一遍计算误差曲线然后在代码里打一个补丁系数。4.5 模式切换时机判断失误我们最开始是硬编码模式前 10 轮用滑动窗口超过 10 轮切紧凑模式超过 50 轮切检索增强。结果在 12 轮附近频繁出问题——上下文结构刚要从完整消息切到摘要模式模型还没有适应摘要里缺失的粒度回复内容明显空洞。后来改成状态机根据“当前历史 Token 总量”和“当前轮次”双轴判断每次切换不直接跳变而是渐进式——先保留最近 6 轮原文再叠加新摘要平滑过渡。这个经验放在任何 context-mode 实现里都适用模式切换不能一刀切要留重叠区。4.6 问题速查表现象可能原因排查思路解决建议压缩后模型忘记用户偏好摘要模板没有强制保留偏好字段检查摘要 JSON 里有没有 user_preference 字段摘要模板增加固定字段列出用户偏好和排除项检索命中很多无关片段纯向量召回缺意图过滤查看召回片段的标签分布加意图标签过滤先过滤再向量排序模型突然忘记了角色设定约束被滑动窗口滑出检查系统提示之外的约束是否写进了对话消息把所有不可遗忘约束固定到 system prompt压缩触发过于频繁Token 估算误差导致阈值失真对比预估函数与实际 tokenizer 数值统一 tokenizer 校准写入补偿系数模式切换后回复质量跳水切换无重叠过渡观察切换点前后回复变化采用渐进式切换保留最近 N 轮原文5. 不同场景下怎么选模式5.1 按场景选型对照表为方便你直接抄作业我把常见场景和推荐模式整理成了对照表。注意这只是一个起点不同团队的数据质量和模型表现差异很大上线后还是要通过评估调整。应用场景推荐模式原因单轮问答、百科查询不需要 context-mode上下文本身很短管理反而增加延迟客服多轮对话紧凑模式 检索增强用户重复咨询时需要找回早期诉求结论用摘要、原始细节用检索代码助手、工具调用滑动窗口 紧凑模式最近几轮工具状态最关键早期历史只需保留结论长文档分析检索增强模式文档全量入库按章节和主题分段检索角色扮演 / 长剧情对话分层混合模式角色一致性依赖长期记忆必须保留摘要加关键片段多 Agent 协作紧凑模式 共享检索库各 Agent 共享摘要和检索库避免重复拉取全量历史5.2 一个进化的思路先简单后复杂看到这张表你可能会想要不要直接上分层混合模式一步到位我的建议恰恰相反先简单后复杂。第一步先用滑动窗口把窗口值调对看模型在最短上下文中能否完成核心任务第二步如果发现窗口截断丢信息再加紧凑模式做摘要第三步如果摘要不够用再上检索增强最后真有必要再串成完整的分层混合。这样做的好处是每一步你都能清楚地知道“这个复杂度带来了什么收益”而不是一开始就陷入全量链路出了问题根本不知道是哪一层拖了后腿。我自己也是从滑动窗口开始迭代的前两周连向量库都没接就用滑动窗口加摘要已经能覆盖八成需求。后面加检索增强只是因为一个知识库问答项目里用户的提问经常跨越十几轮之前的具体信息不检索根本找不回来。5.3 别忘了评估压缩到底丢了多少东西最后说一个很多项目最容易忽略的环节上下文管理也必须有评测。压缩摘要后你可以人为构造一批“需要依靠早期信息才能回答”的问题跑一遍系统统计正确率。我在项目里维护了一个只有 50 条问题的评测集覆盖用户偏好、关键约束、历史结论三类记忆点每次改动压缩逻辑或检索策略先跑这个评测集再上线。这个评测集救了我很多次。上次我把摘要模板里的“待办事项”字段改成“未完成事项”语义看起来差不多评测集跑出来正确率掉了 12 个百分点一查才发现模型对“未完成”这个词的理解偏差很大经常把已经完成的步骤也写进去。没有评测集这种隐性劣化几本不可能被肉眼发现。结尾一点个人体会我个人的体会是context-mode 的核心难点不在于技术复杂度而在于“如何在不牺牲关键信息的前提下控制 Token”。你做的每一轮压缩、每一次裁剪本质上都是在和模型的注意力与成本做权衡。真正好用的方案不是让你在窗口边缘心惊胆战而是让系统稳定地运行在一个模型表现最可靠的长度区间内。最后再分享一个小技巧压缩摘要时保留结构比保留措辞更有价值。让模型输出“用户目标 / 已确认信息 / 待办事项 / 排除项”这种结构化 JSON看起来比自然语言摘要费 Token但后续无论是检索、切换模式还是跨会话复用都清晰得多。这个细节让我后续所有迭代都轻松了不少也希望对你项目里的长对话稳定性有帮助。