做LLM应用开发最让人头疼的问题之一就是上下文窗口总是不够用。不管你用的是4K窗口还是128K窗口的模型在真实的多轮对话场景里往往撑不过几十轮就开始“失忆”。一开始我以为是模型能力不行后来踩坑踩多了才明白很多时候问题不在窗口大小而在我们怎么分配和使用这个窗口——这就是今天想聊的context-mode一套专门管理LLM上下文空间的设计思路。Context Mode直译过来是“上下文模式”。它不指某个具体算法而是一整套管理上下文空间的方法论决定哪些内容能留在窗口里、哪些内容被压缩成摘要、哪些内容直接被丢弃。这套机制在智能客服、编程助手、RAG问答、Agent工作流里都是核心环节。这篇文章写给所有正在用大模型做实际项目的开发者不管你是刚入门还是在生产环境里被上下文问题折磨过都应该能从里面翻出点能直接用的东西。1. Context Mode到底在解决什么问题1.1 一次线上事故的复盘去年我做过一个客服机器人最初版本很粗暴——把所有对话历史全部拼接然后一股脑发给模型。上线第一天就出了问题用户多聊几轮之后接口疯狂报错不是超时就是超出最大token限制。我查了日志发现最长的一轮对话历史加起来有两万多token而当时用的模型上下文窗口是8K不爆才怪。更讽刺的是我后来换成了支持128K窗口的模型问题依然存在。虽然不再报错了但模型回答质量下降得厉害经常把前面对话里的细枝末节当成当前主题甚至重复问已经回答过的问题。后来我翻了相关的技术资料才知道这跟AI领域里说的“中间迷失”现象有关——模型对长上下文中间位置的内容注意力明显减弱。也就是说窗口变长不意味着信息都被充分利用了。这次事故让我意识到对话系统不是“把完整聊天记录堆进去”就行而是需要在有限的窗口空间里组织出一份“高信息密度”的上下文。之后我花了整整两周重构方案核心就是围绕context-mode做了一套上下文管理机制才算真正把这个问题解决掉。1.2 上下文管理的本质所谓上下文管理本质上是在做一个信息筛选和压缩的决策。每个token都是钱也是模型有限的注意力资源。你的目标是在预算内把对当前回复最有价值的信息塞进窗口。这里有两个关键约束。第一是硬性约束——模型的token上限超过就只能报错第二是软性约束——注意力质量就算上限够了塞太多无关信息模型照样瞎。所以context-mode要解决的问题说白了就是“什么该留、什么该扔、什么该压缩”。我在项目里把需要保留的信息分成了四类系统指令角色的设定、回复规则、安全边界这一类永远不能丢用户核心需求用户这次来的目的、已经明确的诉求、关键约束条件已确认的事实聊过的结论、确认过的订单信息、用户提供的资料近期对话细节最近几轮的具体措辞和语气直接影响模型回复的连贯性其他内容比如客套话、重复确认、与当前问题无关的闲聊都属于可以被裁剪掉的部分。context-mode的价值就是自动完成这套分类和取舍。2. 为什么不能无脑塞上下文Token与注意力瓶颈2.1 Token成本的真实账本先算一笔实际账。以常见的商用模型为例输入价格大约是每百万token几美元到几十美元不等。假设你做一个日活一万的客服机器人每次请求平均携带5000 token的历史上下文用户平均每天发20条消息那光是输入token的开销就是10000 × 20 × 5000 10亿token/天。这还只是保守估算。如果不对上下文做控制两三轮对话就能把历史撑到几万token成本直接翻好几倍。更隐蔽的开销在响应延迟。模型处理输入token需要做预填充计算输入越多首字延迟越高。在我的实测中一个4K token的请求首字延迟大约是1.2秒但撑到20K token时延迟能到4秒以上。用户可不会耐心等你七八秒才蹦出第一个字。所以无论从成本还是体验看上下文都必须被“管起来”而不是放任自流。2.2 长上下文的“中间迷失”现象我最初以为模型上下文窗口扩大后只要不超上限就能有效利用。实际测试打破了这个幻想。我把一段20K token的对话放在一个128K窗口模型里测试结果发现模型对放置在中间段落的“关键用户需求”几乎无视反而紧盯着最后一轮对话里的无关调侃。后来我找到了相关的解释模型对长文本中不同位置的注意力权重并不均匀开头和结尾的内容更容易被模型关注中间的细节容易被稀释。这种现象在专业圈里被称为“lost in the middle”。这意味着即使你的窗口足够大也不能把历史记录原封不动地塞进去。你需要主动设计上下文的内容布局把关键信息放在显眼位置——也就是开头和靠近当前查询的地方。这也是为什么context-mode不是简单搞个“截断旧消息”的粗暴逻辑而是需要一套完整的编排策略。2.3 Context Mode的定位到这里context-mode的定位就很清晰了它是你在大模型应用和模型之间加的一层“内容处理器”。它负责把原始的对话流、检索结果、业务数据加工成一份精简、有序、对模型友好的上下文内容。你可以把它想象成一个给模型汇报工作的助手。原始材料堆了满满一桌子你不可能让老板全都看完再决策而是应该把背景、重点、待决事项提炼成一页纸放在他面前。context-mode做的就是这件事——在token预算内提炼出最值得让“模型老板”看的内容。它的核心构成通常是三个模块内容筛选器决定留哪些类型的信息、压缩器把长篇历史变成结构化摘要、窗口编排器决定内容在上下文里的先后顺序和位置分配。这三者配合才能让模型在有限窗口内达到最好的理解效果。3. 三种主流Context Mode方案拆解3.1 滑动窗口模式最朴素但有效先说最简单的滑动窗口方案。它的思路是只保留最近N轮对话更早的内容直接丢弃。实现非常简单维护一个列表新消息来了就追加超过阈值就把最旧的整条移除。用伪代码表达就是class SlidingWindowContext: def __init__(self, max_rounds: int 10): self.max_rounds max_rounds self.messages [] def add_message(self, role: str, content: str): self.messages.append({role: role, content: content}) if len(self.messages) self.max_rounds * 2: # 丢弃最旧的一条用户消息和对应助手回复 del self.messages[:2]这种方案在什么场景下好用答案是当每轮对话之间关联性弱时。比如一个翻译工具、一个单轮问答系统或者一个纯粹的工具调用Agent用户问完一个问题就结束了不需要模型记住十分钟前聊了什么。这种情况下滑动窗口是最经济的选择既没有额外的摘要成本也不会因为压缩把信息弄丢。但它有个很明显的坑一旦用户在中途提过一个关键需求比如“我的预算是5000元”然后在第15轮又提了一个相关诉求如果窗口只有10轮前面的预算信息早就被丢干净了。模型就会“失忆”把对话引向错误方向。3.2 摘要压缩模式用理解换记忆摘要压缩模式的核心思路是当历史消息即将超出预算时不再简单丢弃而是调用模型或规则算法把旧历史提炼成一段摘要作为长期记忆保留下来。我曾经在客服机器人上试过这个方案。大致的流程是系统维护一个独立的摘要字段初始为空每次新对话进来先检查当前历史是否超过阈值超过阈值时把最早的一部分消息取出来和现有摘要拼接一起发给模型生成新摘要新摘要覆盖旧摘要被处理完的原始消息从历史列表里移除摘要模式的优点是信息密度高可以把100轮对话压缩成几百字的要点对历史记忆的跨度几乎没有上限。但它也有两个比较烦人的问题。第一个是摘要本身会失真。模型总结时容易把“用户说想对比三款产品”概括成“用户想买产品”丢失了具体的产品名。我后来不得不在摘要模板强制要求保留实体名词和数字。第二个是延迟每次触发压缩都要额外调用一次模型如果压缩频率太高接口响应会变慢费用也上涨。3.3 混合模式生产环境的首选在实际生产环境里我最终用的都是混合模式结合了滑动窗口、摘要压缩和关键信息钉住三种策略。混合模式的基本规则是区域内容分配预算比例系统提示区角色设定、回复规则、安全边界10%摘要区压缩后的长期记忆结构化摘要20%钉住区用户关键信息、核心需求、已确认事实15%滑动窗口区最近3-5轮完整对话35%当前输入区用户当前问题、检索结果20%这样既保留了对近期对话的完整“临场感”又通过摘要维持了长期记忆同时还专门划出一块“怎么都不会丢”的区域用来记住用户的核心诉求。你可以理解为滑动窗口负责“记住刚说的话”摘要负责“记住之前聊了什么”钉住区负责“记住绝对不能忘的事”。这套方案上线后客服机器人的上下文相关问题明显减少而且每次请求的token消耗被控制在一个稳定的水位线上不再忽高忽低。4. 手写一个Context Manager实现细节4.1 数据结构与核心类设计光聊思路不写代码就是耍流氓。下面我把我实际用到的一个简化版Context Manager实现思路分享出来。完整版会结合业务表结构这里保留核心逻辑。首先设计一个ContextManager类它内部主要维护四个字段class ContextManager: def __init__( self, max_context_tokens: int 8000, max_recent_rounds: int 3, summary_threshold_ratio: float 0.8, ): self.max_tokens max_context_tokens self.max_recent_rounds max_recent_rounds self.summary_threshold_ratio summary_threshold_ratio self.system_prompt self.summary_text self.pinned_items [] self.recent_messages []这里的设计有几个关键点。recent_messages只保存最近的若干轮对话超过max_recent_rounds的轮次在add_message时会被移入待压缩区。pinned_items是一个字符串列表存储用户的关键信息排重逻辑按关键词做匹配。整个类对外只暴露add_message、add_pinned_item、build_context三个方法业务层不需要关心内部如何压缩。build_context方法负责把全部内容拼装成最终的messages数组返回给模型调用前使用def build_context(self): messages [] if self.system_prompt: messages.append({role: system, content: self.system_prompt}) if self.summary_text: messages.append({role: system, content: f历史对话摘要\n{self.summary_text}}) if self.pinned_items: messages.append({role: system, content: f用户关键信息\n \n.join(self.pinned_items)}) messages.extend(self.recent_messages) return messages把摘要、关键信息都放在system角色里是为了让模型在生成时优先把这些内容当作背景知识。这些信息位于上下文的开头位置也更容易被模型利用。4.2 Token估算与窗口预算分配实现context-mode最基础的能力是token估算。很多初学者用字符数或字节数来估算这对英文还好中文会偏差巨大。同一个中文字符在主流分词器里可能是1到2个token标点、空格也会占位置。我建议直接用tiktoken库它是OpenAI开放的分词器库对主流模型做了适配。使用方法非常简单import tiktoken def estimate_tokens(text: str, model: str gpt-4) - int: try: encoding tiktoken.encoding_for_model(model) except KeyError: encoding tiktoken.get_encoding(cl100k_base) return len(encoding.encode(text))有了这个函数就可以做窗口预算分配了。我习惯写一个BudgetAllocator工具类它根据总预算max_context_tokens按比例分配到各个内容区域。在拼装消息前先检查所有内容的总token数是否超预算如果超了就按优先级做裁剪。裁剪优先级我个人设置为当前用户消息 近期对话完整轮次 钉住信息 摘要 系统提示词。也就是说系统提示词和摘要这种低成本高价值的内容最后才被裁剪近期对话轮次被裁剪掉后就进入摘要压缩流程。这里特别提醒一下你写的prompt被token化后中英混合和纯中文的token数差异很大。我测试过一长段中文业务说明平均一个字符约等于0.7个token而英文一个单词约1.3个token。实际开发时不要凭感觉拍脑袋最好用真实文本多测几次给自己留出15%-20%的buffer避免模型输出时撑爆窗口。4.3 压缩触发与摘要生成压缩触发不能等窗口彻底满了才做那样容易来不及。我设置了一个阈值比例默认是0.8。只要build_context时发现总token数超过max_tokens的80%就先执行一次压缩动作。压缩动作的步骤是把最近的recent_messages里超出max_recent_rounds的部分取出来和当前的summary_text拼接然后调用模型生成新的摘要。def _compress(self): if len(self.recent_messages) self.max_recent_rounds * 2: return overflow self.recent_messages[:-self.max_recent_rounds * 2] self.recent_messages self.recent_messages[-self.max_recent_rounds * 2:] text_to_summarize self.summary_text \n self._messages_to_text(overflow) self.summary_text self._summarize(text_to_summarize)要注意的是我把_summarize设计为一个可替换的抽象方法。生产环境里你可以在这里调用大模型接口也可以调用更便宜的小模型甚至可以用规则抽取关键实体。如果你的token预算足够我建议用专门的摘要模型而不是跟主对话共用同一个模型这样可以让模型“术业有专攻”。摘要模板我固定成这样你是对话摘要引擎。请从以下对话记录中提取 1. 用户明确表达的核心目标/诉求 2. 所有实体名词人名、产品名、地名、订单号等 3. 已确认的结论和待办事项 4. 用户的情绪或态度变化如有 要求使用简洁的中文要点保留原始数字和名称不要添加推断内容。加了“保留原始数字和名称”这句话之后实体丢失的问题大幅减少。4.4 关键信息钉住机制光靠摘要还不够总有些信息是绝对不能丢的比如用户的会员等级、订单编号、当前使用的产品版本。这些信息一旦被摘要压缩成“一个高价值客户”后面模型就彻底没法做针对性的回答。所以我在ContextManager里单独加了一个钉住区。业务层可以在任何时机调用add_pinned_item来写入必须保留的内容def add_pinned_item(self, item: str): for existing in self.pinned_items: if existing item: return self.pinned_items.append(item)钉住区也做长度控制最多保存20条超出时按时间先后淘汰但不会对钉住内容做语义压缩。这部分的token开销算进整体预算里优先保留。这个机制在实际项目里帮了大忙。比如客服机器人在第一轮就问用户“你的订单号是多少”得到答复后写入钉住区后面无论过多少轮、历史被压缩多少次订单号始终在上下文中。模型后续查物流、改地址、申请售后都能精确引用到这个订单号不会出现“请再次提供订单号”这种让用户抓狂的对话。5. 上线后常见的坑与排查思路5.1 压缩摘要把关键信息丢了摘要模式最大的坑就是信息丢失。我遇到过的情况是用户第3轮说“我不要XX品牌的手机”结果第18轮模型推荐了一款XX品牌的手机。原因是摘要生成时模型把“不要XX品牌”这个否定信息当成了无关内容滤掉了只保留了“用户对手机有需求”。排查这类问题时最有效的做法是做一个摘要回放测试定期把原始对话和对应摘要放在一起让评估模型判断摘要是否遗漏了关键实体和否定修饰词。我在项目里专门写了一个脚本把摘要发生丢失的样本收集起来定期看是模板问题还是模型理解问题。如果你的项目对信息保真要求很高可以在摘要模板里加入“必须保留所有否定句和限制条件”这个强制约束。另外对绝对不能丢的字段比如金额、日期、型号走钉住机制而不是依赖摘要。5.2 Token数估错导致请求直接报错我早期犯过的一个低级错误估算token时用的是非模型专用的分词器导致严重低估。等到真正调用模型时输入长度超限接口直接返回400。尤其是并发量上来之后这种报错的排查成本非常高。解决思路只有一个不要用字符长度做估算也不要信多个分词器之间的近似转换。如果你用的是OpenAI系模型就用tiktoken如果你用了其他厂商模型通常也有对应的分词器库比如transformers里的tokenizer或者模型服务商提供的token计数接口。还要注意预留空间要足够。我给自己的硬规则是输入内容总token数不得超过max_context_tokens的85%剩下的15%永远留给模型输出。否则模型回复稍微长一点总的输入输出token数就会超过上限同样会报错。5.3 并发场景下上下文串味如果只是一个单用户对话context-mode实现起来还算简单。但一旦上线成多用户服务共享内存的上下文就是大事故。我测试阶段就遇到过用户A在1号会话里问了订单问题结果用户B的回复里出现了A的订单号。原因是我把ContextManager设计成了全局单例所有用户的对话共用同一个recent_messages列表。这个问题的解决方案很常规但容易忽略为每个会话单独实例化一个ContextManager用会话ID做唯一键存储在一个字典或独立的缓存里并设置过期清理策略。或者干脆把上下文拼装逻辑做成无状态函数每次从持久化存储里取出对应当前会话的消息和摘要再执行压缩和拼装。我后来的做法是会话ID作为redis的key值存ContextManager序列化后的数据。每次请求一来先从redis读取处理完再写回。同时设置expire时间比如24小时没有活跃就清理掉防止内存无限膨胀。5.4 摘要递归压缩导致话题漂移还有一个隐蔽问题当对话轮次非常多摘要会被反复压缩。第一次压缩把100轮对话变成500字摘要第二次压缩又把500字摘要和新对话一起压成300字。两三轮之后原始信息被层层加工模型生成的内容质量呈断崖式下降我管这叫“话题漂移”。排查这个话题漂移时我把每次压缩前的输入和输出都保存下来对比发现模型在压缩时倾向于用更抽象的词汇替换具体词汇比如“用户想了解产品功能”代替“用户想知道A产品是否支持蓝牙5.0”。层级越多丢失越严重。应对办法是给摘要设定一个“最低保真度”每次生成新摘要时强制要求必须包含关键实体名词且总长度不低于初始摘要的60%。如果发现要压缩的文本太长宁可增加摘要生成模型的输出长度也不要强行浓缩成极短一段。我现在的摘要区通常保留1000到1500 token的容量低于500 token时就不再压缩而是把最早的消息直接丢弃。6. 我的一些实操体会做context-mode这件事技术上其实没有太多高深的东西难点全在取舍和细节上。我最大的体会是不要一开始就追求“最优方案”先从一个简单的滑动窗口跑起来把对话流程打通再逐步加入摘要和钉住机制。你才会真正理解哪些信息在你的业务场景里是不可丢的。另外一个小技巧是强烈建议给每次请求打上trace_id记录这次请求的上下文快照包含多少token、摘要占多少、钉住区有哪些内容、压缩触发了几次。出问题的时候这些日志比任何调试器都管用。我线上出故障时基本都是靠查trace日志里的token分布来定位是哪个环节出了问题。最后想说的是context-mode不是一次做完就一劳永逸的东西。用户行为会变模型会升级窗口大小也在变。我每隔一段时间就会拿一批真实对话样本重新评估摘要质量和窗口预算分配是否合理。把它当成一个持续迭代的模块而不是一个写一次就永久运行的组件这可能是整个项目里最重要的一条经验了。