标题只有“context-mode”一个词确实很考验人。我先说结论这不是一个只能停留在概念层面的术语它是每个做 AI 应用的人迟早都要正面刚的问题。如果你正在开发智能客服、AI 助手、文档问答这类产品你会发现模型能力再强上下文这块处理不好效果可以直接拉胯一整条链路。这篇文章我把自己在项目中反复踩坑、反复调整之后沉淀下来的完整方案整理出来从原理到核心代码再到排查实录尽量讲透。1. 先搞明白context-mode 到底是什么解决什么问题1.1 从“对话记忆”说起我最早接触“context-mode”这个词是在做大模型应用的时候。你给模型发一段请求模型只能看到你这一次请求里装了什么它本身是没有“记忆”的。所谓 context-mode翻译成大白话就是你用什么样的方式把历史对话、背景信息、用户偏好这些东西组织起来塞进每一次请求里。打个比方你和一个新同事对接工作你不可能每次都从自我介绍、项目背景开始讲。你会默认这个同事已经知道一些事只需要把增量信息说清楚就行。但大模型没有这个“默认”每一次请求它都像是第一天上班的新人。所以需要有一套机制把“它应该知道的背景”和“本次要解决的新问题”拼装在一起。这套机制的运作方式就是上下文模式。做得好的上下文模式用户会觉得这个 AI“懂我”做得不好的用户会觉得这个 AI“失忆了”。实际体验差距非常大这也是为什么看起来只是技术细节的事情最后变成了产品体验的分水岭。1.2 为什么不能一次性把所有内容都塞给模型很多人第一反应是上下文模式那我把所有历史记录都怼给模型不就行了听起来简单但实际上有几个硬约束。第一个是 Token 上限。任何模型都有上下文窗口就像你手里只有一张有限的便签纸GPT-4o 这类模型一般能写十几万 token一些开源小模型可能只有几千。超过窗口的请求直接报错或者被静默截断。第二个是成本。Token 是按输入量计费的你每次请求塞进去的内容越多账上的钱烧得越快。假设你的客服机器人平均每轮对话塞入 5000 token 历史每个用户每天聊 30 轮一个月下来光是输入 token 的费用就是一笔不小的开销。很多团队上线第一天没注意月底看到账单直接被吓到。第三个是效果。这是最容易忽视的。模型在超长上下文里并不是“全部都能注意到”大量研究结果表明模型对中间部分的信息利用率明显低于开头和结尾。你塞了 50 轮历史进去模型可能只记住了最早的一句和最晚的一句中间用户明确说过的要求反而被忽略。所以与其无脑堆积不如设计一套上下文管理模式把真正重要的信息精准地放进窗口里。1.3 常见的四种上下文模式选型项目做久了我总结下来实际可用的上下文模式基本就四类固定窗口模式、滑动窗口模式、摘要压缩模式、检索增强模式。它们各有适用场景很多成熟产品用的是它们的组合而不是单一模式。固定窗口模式最简单只保留最近 N 轮对话更早的不管。优点是稳定、成本可控缺点是如果用户很早之前提过一个偏好比如“我不吃辣”聊了 20 轮之后这个信息就被挤出了窗口模型就会忘掉这个偏好。滑动窗口模式其实就是固定窗口的变体区别在于窗口不是按“轮数”算而是按 token 数算。每来一条新消息就往消息队列里追加同时把超出 token 上限的旧消息从头部弹出。摘要压缩模式是另一个思路当历史消息超过阈值不再保留原始消息而是让模型把前面所有内容浓缩成一段摘要。下次请求时系统提示词里带这段摘要再加最近几轮的原始消息。这种模式在长对话场景下表现很好但摘要本身会丢失细节。检索增强模式就是 RAG 的思路把历史消息向量化存入数据库每次请求前先做语义检索把和当前问题最相关的历史片段召回再拼进上下文。这种方式解决的是“跨时间段的信息关联”比如用户三天前提过一个需求今天又问起相关事情只有这种模式能找回来。做一个项目核心问题不是“用哪种模式”而是“怎么组合”。我会在实操部分给出一个组合方案。2. 核心细节拆解窗口、Token 与信息优先级2.1 上下文窗口到底怎么算token 是硬通货要落地上下文模式第一件事就是得懂 token。Token 不是一个“字”或一个“单词”而是模型内部用来处理文本的基本单位。拿中文来说一个汉字大约对应 0.6 到 1.5 个 token具体取决于模型分词器。英文一个常见单词大约 1 到 1.3 个 token。所以我做上下文模式时第一步永远是给项目定一个“token 预算”而不是“消息条数预算”。上下文窗口是 8000 token我的分配方案一般是系统提示词占 800 到 1000 token业务背景信息占 1500 到 2000 token历史对话占 3000 到 4000 token剩下的预留空间给模型输出和突发内容。预算定了后续的所有截断和压缩逻辑就有了标尺。没有 token 预算是很多新手项目混乱的根源——今天塞 10 条记录明天塞 20 条最后模型报错或者行为不稳定还不知道问题出在哪。还有一个很关键的细节模型请求里除了 messages 内容系统提示词、工具定义、示例对话都会被计入 token。很多人只算用户对话把提示词漏了结果每次请求都在超限边缘疯狂试探。我通常在代码里封装一个 token 估算函数把所有要发送的内容统一计算而不是只看 messages。2.2 哪些信息必须留哪些信息可以丢搞清楚了 token 预算下一步就是给信息分门别类。我习惯把上下文里的信息分成三个优先级级别。最高优先级是“当前会话的即时目标”。用户这一轮问了什么、需要模型做什么这是必留的。其次是“跨轮的关键约束”。用户明确说过的偏好、强调过的事情比如“答案是给非技术人员看的别写代码”“我只关心近 30 天数据”这种信息一旦丢失整个对话就会跑偏必须单独保存。最低优先级是“纯过程性寒暄和流水账”比如“好的”“嗯”“让我想一下”这类信息尽早丢弃。我给一个很直观的场景。用户说“帮我写个邮件模板语气正式一点不要用 emoji。”这句话里的关键约束是“语气正式”“不要 emoji”如果系统只在当前窗口里保留这句原话那还好但如果这句是在第 2 轮说的到第 20 轮才用到普通的固定窗口早就把它挤出去了。所以我建议把关键约束单独抽出来放进一个“长期记忆”对象里每一轮都拼进系统提示词。这条经验是我在真实项目里踩了无数次坑之后总结出来的。之前我用最简单的滑动窗口结果用户经常抱怨“我都说过不要 emoji 了为什么还给我加”原因就是关键约束被窗口挤掉了。单独存储之后这个问题基本绝迹。2.3 上下文截断的三种手段直接切、摘要压、检索补当上下文超限处理手段就三种每一种效果和成本都不同。直接切是最粗暴的就是把最早的消息从窗口里删掉。操作成本最低但很容易误伤因为最早的对话里可能藏着用户的关键需求。我的建议是直接切可以但要结合优先级——先切寒暄类消息再切无结论的讨论过程最后才切带约束的消息。摘要压是让模型把一段对话浓缩成几百字。成本相对高一些因为每次压缩都要多一次模型调用但效果显著。这个手段的关键点在于摘要的“格式”不要存成一段流水账建议用条目化的要点比如“用户偏好正式语气当前状态等待价格确认历史结论已排除 A 方案”。结构化摘要后续检索和拼装都更容易。检索补是成本最高的方案也是效果上限最高的方案。把历史消息向量化按需召回。它适合会话轮数特别多、信息跨度特别大的场景。但要提醒一点检索补的召回率直接依赖向量模型质量如果模型不行召回的内容和问题不相关效果反而比直接切还差。我自己落地的方案是“摘要为主、检索为辅”大部分会话用摘要压缩保住长期记忆遇到模糊的关联型问题再启用检索召回历史片段。两者结合既能控制成本又能照顾到信息关联场景。3. 实操手写一个可用的上下文模式管理器3.1 设计目标与数据结构这部分我直接上手写代码。为了让方案可落地我设计了一个 ContextModeManager 类支持切换“滑动窗口模式”和“摘要压缩模式”并且把关键约束单独维护。它的目标只有一个输入新的对话输出一份符合 token 预算、且信息不塌陷的消息列表。数据结构我分了四块system_prompt系统提示词固定内容。context_memory关键约束和长期记忆用键值对保存。messages原始对话消息列表。summary历史摘要文本进入摘要模式后启用。使用过程就是每次新消息进来先正常 append 到 messages再调用 prepare_messages() 方法在这个方法里做窗口裁剪、摘要压缩、关键约束拼装最后返回真正要发给模型的消息数组。from typing import List, Dict, Optional class ContextModeManager: def __init__( self, max_tokens: int 8000, mode: str sliding, summary_threshold: int 6000, reserve_tokens: int 1000 ): self.max_tokens max_tokens self.mode mode # sliding or summary self.summary_threshold summary_threshold self.reserve_tokens reserve_tokens self.system_prompt self.context_memory: Dict[str, str] {} self.messages: List[Dict[str, str]] [] self.summary def add_message(self, role: str, content: str) - None: self.messages.append({role: role, content: content}) def set_context_memory(self, key: str, value: str) - None: self.context_memory[key] value def estimate_tokens(self, text: str) - int: # 中文场景的粗略估算英文可以按 len(text) / 4 计算 return max(1, int(len(text) * 0.8))3.2 核心代码实现接下来实现 prepare_messages 方法。这个方法里做了三件事检查总 token 数是否超限在超限时根据模式进入裁剪或压缩逻辑始终在消息数组开头拼上系统提示词和上下文记忆。def _build_system_messages(self) - List[Dict[str, str]]: memory_text .join( f{key}: {value} for key, value in self.context_memory.items() ) system_content self.system_prompt if memory_text: system_content \n\n长期约束与关键记忆:\n memory_text return [{role: system, content: system_content}] def _trim_to_sliding_window(self) - None: # 计算当前消息总 token total sum(self.estimate_tokens(msg[content]) for msg in self.messages) budget self.max_tokens - self.reserve_tokens - sum( self.estimate_tokens(msg[content]) for msg in self._build_system_messages() ) while total budget and len(self.messages) 1: removed self.messages.pop(0) total - self.estimate_tokens(removed[content]) def _update_summary(self) - None: if len(self.messages) 4: return history_for_summary self.messages[:-4] joined \n.join( f{m[role]}: {m[content]} for m in history_for_summary ) # 实际项目里这里调用 LLM 做摘要为了演示用简单截断 # 生产代码请接一个真实 LLM例如 llm.summarize(joined) candidate_summary joined[:300] ... self.summary candidate_summary self.messages self.messages[-4:] def prepare_messages(self) - List[Dict[str, str]]: if self.mode summary: # 先看历史消息是否超出阈值超出则生成摘要 total sum(self.estimate_tokens(msg[content]) for msg in self.messages) if total self.summary_threshold: self._update_summary() elif self.mode sliding: self._trim_to_sliding_window() system_messages self._build_system_messages() # 如果启用摘要模式且已有摘要追加为一条 user 消息 if self.summary: return system_messages [ {role: user, content: f历史对话摘要:\n{self.summary}} ] self.messages return system_messages self.messages有几个细节我得强调一下。_build_system_messages 里把 context_memory 放在系统提示词的尾部这是因为模型对开头和结尾的内容注意力更高把关键约束放在系统提示词最后相当于放在整个请求的“次开头”位置被注意到的概率更大。_trim_to_sliding_window 里的预算计算是动态的先用总预算减去系统消息费用得到历史消息的可用预算。这样不会因为系统提示词变长导致主消息超限。_update_summary 里的 300 字截断只是代码演示生产环境必须换成真实 LLM 调用否则摘要会丢失大量语义。我后面章节会单独讲这一点。3.3 参数计算你的场景该选多大窗口参数这东西直接抄答案没有意义我给你推导一遍。假设我做一个电商客服助手。用户每轮对话平均长度按 1000 token 算用户问题 助手回复上下文窗口是 8000 token。我的系统提示词约 500 token关键记忆约 200 token。那么留给历史消息的预算就是 8000 - 1000预留输出 - 500 - 200 6300 token。这个预算大约能容纳 6 轮完整对话。对客服场景来说6 轮对话通常够用。但如果是“帮客户选型”的复杂销售场景一次要对比多个产品的参数聊 20 轮很正常。6 轮肯定不够所以这时候我会换用摘要模式保留最近 4 轮原始消息约 4000 token再加上之前的摘要约 800 token这样模型既能感知最近细节又不会丢失更早的结论。再给一个公式你可以拿去直接用历史预算 上下文窗口 - 系统提示词 token - 长期记忆 token - 预留输出 token 可保留轮数 历史预算 / 单轮平均 token如果你算出来可保留轮数小于你的业务最低值说明要么窗口选小了要么需要切换摘要模式。这一步的推导逻辑我在每个项目里都会做一遍算是上下文模式设计的“第一性原理”。3.4 接入 API 请求代码写好后接入大模型 API 就很简单了。我用一个典型的 OpenAI 兼容接口演示。需要强调的是我不在这里涉及任何具体服务的配置只给出一段标准用法你根据自己的模型服务商替换 endpoint 即可。from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlyour-endpoint-url ) manager ContextModeManager( max_tokens8000, modesummary, summary_threshold6000, reserve_tokens1000 ) manager.system_prompt 你是电商客服助手回答简洁礼貌不编造价格信息。 manager.set_context_memory(用户偏好, 喜欢性价比高的商品预算 300 左右) manager.add_message(user, 帮我看看有没有适合办公的机械键盘) manager.add_message(assistant, 可以考虑 A 款红轴约 280 元。) # 最新一轮用户输入 manager.add_message(user, 有静音的吗我在办公室用) response client.chat.completions.create( modelyour-model-name, messagesmanager.prepare_messages() ) print(response.choices[0].message.content)这里最关键的一点是每次发送请求前必须临时调用 prepare_messages() 来生成 messages而不是直接把 manager.messages 原样发出去。因为上下文管理是在发送前即时发生的动态过程消息列表会随 token 总量变化而变化。很多人容易在这里踩坑——消息是动态裁剪的如果缓存了旧列表就会出现上下文不一致。还有一个建议把上下文管理器状态持久化到 Redis 或者数据库。因为实际服务都是多请求的用户每次发一条消息都是一个独立的 HTTP 请求。如果不持久化消息列表和摘要下一次请求就变成“失忆”状态了。我在生产项目里一般按 session_id 为维度把 ContextModeManager 对象序列化存到 Redis每次请求加载处理完再存回去。这样既保证效率又保证上下文连贯。4. 常见问题与排查技巧实录4.1 上下文“越聊越笨”信息被挤丢了这是最普遍的投诉“一开始聊得好好的后面发现它忘了之前说的事。”排查方向就一条看它是不是把关键约束挤出去了。用我上面的 ContextModeManager先检查 context_memory 里有没有命中关键约束。没有的话说明你可能把它放在了普通消息流里然后被滑动窗口弹出了。解决方案就是严格执行我上面说的分级方案。所有能定义为“约束”“偏好”“决策”的信息一旦识别出来立刻写入 context_memory而不是依赖对话原话。这里涉及到一个信息抽取的环节。我的做法是在系统提示词里加一条指令让模型在对话过程中持续产出结构化记忆。比如“当用户表达明确的偏好、约束或决策时输出一个 JSON 块内容格式为 memory_key/memory_value。”然后我用代码解析这个 JSON写入 context_memory。有读者可能觉得这样做会增加 token 消耗。确实会但不多。相比整个对话被遗忘带来的体验崩溃和重问率这点成本非常划算。4.2 并发场景下上下文串味上下文串味这个坑多线程或者微服务项目特别容易踩。典型症状是用户 A 的对话框里出现了用户 B 说过的话。排查时先别怀疑模型出了幻觉直接查你的上下文存储隔离。我在代码审计时看到最常见的错误是把 manager 对象定义成了模块级全局变量。这种单例对象在多用户场景下必炸。每个用户的请求都会往同一个 messages 列表里追加消息谁都拿别人的历史当自己的上下文。正确的做法是每个 session_id 一个 manager 实例存放在 Redis 这类带过期时间的存储里。Redis key 的过期时间建议设 30 分钟到 1 小时避免长期占用存储空间。我通常会把 key 设计成 session:{user_id}:{conversation_id} 这种三级结构方便跨设备同步和历史回溯。4.3 成本突然飙升上下文模式做得越好成本控制一般越好。但如果代码没写好成本反而更高。我见过一个项目核心问题在于每次都把完整历史发出去却没有任何裁剪逻辑。明明只需要最近 4 轮前 40 轮也全带上输入 token 直接翻五倍。排查成本问题有个回追技巧给每次请求打好日志记录 request_message_tokens 和 response_message_tokens。不需要逐条分析哪天账单异常直接按 session_id 聚合请求找 token 消耗最大的会话基本一眼就能定位问题。加日志不会让系统变慢多少但能救命。我之前做一个上线项目前端页面明明没有几个人用账单却涨得离谱。查日志发现是某个定时任务没有清空 manager 状态导致历史消息不断累加。这个 bug 如果不做 token 日志光靠猜估计要折腾一周。另一个隐蔽的成本杀手是摘要模式下的重复压缩。如果阈值设得太低比如历史到 3000 token 就去生成摘要每几轮对话就触发一次摘要调用摘要调用的 token 成本会像滚雪球一样越滚越大。解决办法是加一个冷却机制摘要生成成功后至少再积累 2000 token 才允许下一次摘要。这个“冷却距离”我一般取历史预算的四分之一左右。4.4 token 估算不准导致请求报错我上面代码里的 estimate_tokens 用的是粗略估算生产环境绝对不能依赖这个。不同模型的分词器差异巨大最常见的情况是你估算 7000 token实际一发出去变成 8200直接超出窗口API 报参数错误。解决方案分两步。第一步不要自己写估算法直接用模型 SDK 自带的分词器比如 tiktoken。中文、英文、代码混合的内容用不同编码方式测量误差都能控制在 5% 以内。第二步也是更稳妥的方案——在请求外层包一层试运行逻辑。先用 prepare_messages 算出消息如果发现超限强迫进入 trim 模式不要直接报错。我在生产环境处理这个问题的方式是在 ContextModeManager 的 prepare_messages 末尾加一个保险检查。如果最终消息总 token 超出 max_tokens 减去输出预留就把 mode 强制切换成摘要模式再跑一遍确保发送到 API 的消息一定在窗口内。虽然这会让极端场景下多一次摘要调用但至少不会因为报错导致用户请求直接失败。4.5 摘要模式丢了关键用户偏好摘要压缩虽然能保住“语义”但保不住“细节”。我在客服项目里遇到过一个案例用户在第 3 轮说“我的收货地址是北京市朝阳区 XX 路 XX 号”后面聊了 30 轮推荐商品没有再用到地址。第 33 轮用户说“下单吧”模型回复确认时地址已经不在上下文里了。这种敏感信息摘要模型不一定会原样保留。不能指望摘要帮你记住地址、手机号、身份证号这些必须走结构化记忆。我给项目的约定是凡涉及实体信息地址、电话、邮箱、日期、订单号、用户偏好价格区间、风格、忌口、状态决策已决定、已放弃、待确认必须同时写入 context_memory。摘要只负责记录“情感脉络”和“对话进展”不承担关键实体存储责任。这样设计的另一个好处是摘要不再需要输出过长内容300 到 500 token 就够。也正因为摘要更精简token 预算会更宽裕形成一个良性循环。我个人在实际操作中还有一个习惯每次会话结束把最终的 context_memory 快照保存到数据库。这样即使用户隔了几天再来继续聊也能从数据库加载他的长期约束。很多团队把注意力放在了“窗口内如何组织”忽略了“窗口外如何持久化”其实窗口外的功夫才是正题。长期记忆的存取策略决定了你这个上下文模式的上限在哪一层。这个点值得每个做 AI 应用的同仁认真对待。