前阵子调试一个客服机器人同一个问题用户反复问了三遍三遍得到的回答角度完全不同而且越往后越“没记性”。查了很久才发现问题根本不在模型本身而藏在一个平时最容易被忽略的配置项里context-mode。这个参数在不少产品里就只是一个下拉框选项看起来改改就能用但真正决定多轮对话质量的恰恰是它背后那套“什么该留、什么该丢”的管理策略。策略选错了模型再强也白搭。这篇文章不打算做概念科普。我会从context-mode要解决的问题、四种主流实现、一个可以直接上手的代码框架、不同业务的模式选型再到我自己踩过的几个隐蔽的坑把这条链路完整过一遍。适合正在做对话类产品、或者刚接入大模型API想改善多轮体验的开发者内容偏工程实践读完可以直接抄作业。1. 无感知的对话失忆context-mode到底在解决什么问题1.1 从“上下文窗口”到“上下文模式”的思维转变先厘清两个容易混的概念。上下文窗口context window是模型能接受的最大输入范围比如某些模型的窗口是128k token有些是200k。而上下文模式是对窗口内历史内容的组织方式也就是你决定把哪些历史消息放进窗口、以什么形式放进去、放多少。很多人以为窗口越大越好于是无脑选长窗口模型。但只要做过真实对话产品就会发现窗口再大也有三个现实约束成本随输入长度线性上升延迟在长输入下明显变慢而且模型对长距离信息的注意力会衰减。就算把过去50轮对话全塞进去模型也可能记不住第3轮提到的关键约束。所以context-mode解决的不是“窗口不够大”的问题而是“窗口有限的情况下如何让最重要的信息留在里面”的问题。这个思维转变很重要它决定了你是在优化模型参数还是在优化信息管理策略。1.2 对话失忆的三个典型症状症状一跨轮指代丢失。用户说“刚才那个方案不太好”模型不知道“那个方案”指的是什么。这是最典型、最容易被感知到的失忆本质是早期信息没有进入上下文。症状二早期约束失效。用户在对话开头说“不要用数据库”聊到第20轮模型开始一本正经地给用户生成SQL。不是模型故意违抗而是开头那句约束早被后续内容挤出了窗口。症状三角色一致性漂移。你的系统提示词里写了“你是一名严谨的保险顾问”但长对话后期模型开始表现得像一个随意的闲聊机器人。原因同样是系统级指令被淹没在历史消息里。这三个症状的共同点在于从单轮看模型没毛病从多轮看体验完全断裂。大多数对话产品翻车翻的都是这种“不明显的失忆”。1.3 为什么默认配置必然翻车我拆过不少项目的context-mode配置发现绝大多数人用的都是默认值要么什么都没配要么一个简单的“只保留最近N轮”。短对话场景下这样确实没问题。一旦对话超过20轮问题就会像滚雪球一样累积。本质原因是默认策略没有区分“哪些历史信息具有长期价值”把闲聊和关键约束放在同一个优先级里处理。等窗口满了最先被挤出去的往往是开场那段包含了用户核心需求的内容。打个比方这就像一个店员同时接待很多顾客手里只有一张便利贴只能记下最后一句话前面的需求全凭运气。context-mode要做的事情就是决定这张便利贴怎么记、记哪些、记不下的时候怎么压缩。想清楚这一点后面所有实现思路都顺了。2. 四种主流实现截断、滑动窗口、摘要与向量记忆2.1 截断模式最朴素但也最容易丢关键信息截断模式的做法很直接只保留最近的一部分对话超过部分直接丢弃。代码上通常就是列表取尾部切片。def truncate_messages(messages, max_rounds10): return messages[-max_rounds:]它适合对话轮次短、单轮工具型、用户不依赖历史记忆的场景比如一次性问答、简单表单填写。优点是零额外开销、实现简单、行为可预测。代价也很明显早期所有信息无差别丢失。我曾经把一个“用户偏好记录”功能放在截断模式下测试第1轮用户明确说“回复控制在200字以内”到第8轮模型开始输出800字长文。原因不是模型没遵守指令而是这条指令根本不在输入里了。所以截断模式的使用前提是确认历史信息确实不重要或者你已经在业务层把关键信息另存了。把重要信息放在对话消息里、又用截断模式做上下文管理是必踩的坑。2.2 滑动窗口模式保留完整轮次动态向前滚动滑动窗口和截断很相似但思路上有个关键升级它通常按“轮次”或“对话块”滑动并且保证每个窗口内都是完整的问答对而不是从某条消息中间拦腰截断。def sliding_window_messages(messages, window_size12): # 保证保留完整轮次避免半组问答出现在上下文中 rounded messages[-(window_size * 2):] return rounded为什么强调“完整轮次”因为模型看到只回答了一半的问题、没有对应的用户输入时很容易产生“被要求续写”的错误理解导致回应前言不搭后语。滑动窗口还需要注意系统提示词的预算保护。如果窗口计算把system消息也算进去历史消息就可能把系统指令挤掉。我的做法是系统提示词单独预留不吃窗口预算窗口只作用在对话历史部分。实现了这点的滑动窗口已经可以覆盖绝大多数中短对话场景。2.3 摘要模式对旧对话做压缩保留语义而不是原文摘要模式的核心思路是把超出窗口的部分交给模型压缩成摘要新对话保持原文每次拼接时用“摘要 最近对话”的结构。这个结构很像人的工作记忆长期记忆存放结论短期记忆保留细节。摘要生成是这里的技术核心。最简单的方法是定期触发每N轮对全部历史做一次重写摘要。更省成本的是增量更新只把上一轮摘要和新对话一起丢给模型生成一份新摘要。def update_summary(previous_summary, recent_messages, llm): text f已有摘要{previous_summary}\n\n新增对话{recent_messages}\n\n请合并并更新摘要 return llm(text)摘要模式解决了截断模式“丢约束”的问题但也引入了新风险。我在实测中发现摘要经过多轮重写后信息会逐级衰减。第一轮生成时保留了“用户偏好简洁表达”第二轮重写后可能变成“用户有某些偏好”第三轮就直接没了。而且摘要生成本身是额外一次模型调用成本不可忽视。所以摘要模式适合对话轮次长、但还没有到需要检索级别的场景比如客服会话、顾问咨询、角色陪伴类产品。使用时要特别设计摘要模板强制模型保留约束性信息列表而不是让它自由发挥——这一点后面我会单独展开。2.4 向量记忆模式把对话切片存入向量库按需召回向量记忆模式严格说属于记忆增强memory-augmented generation但现在很多产品也把它作为一种context-mode挂在配置项里。做法是把历史消息按语义切块用embedding模型向量化后存入向量数据库每次对话前对用户当前输入做向量检索召回最相关的K块历史注入上下文。def retrieve_memory(query_embedding, top_k5): results vector_db.search(query_embedding, top_ktop_k) return sorted(results, keylambda x: x.timestamp) # 恢复原始顺序这种模式擅长回答“用户某次提到过什么”“之前某个偏好在哪轮出现过”这类问题相当于给对话产品加了长期记忆。但它的缺陷也很明显检索召回的是语义相关片段而不是完整的连续上下文模型可能看到三块碎片却不知道它们之间的先后关系。我的建议是向量记忆更适合作为“摘要模式 滑动窗口”的上层补充而不是完全替代。连续对话的连贯性靠窗口保留长线事实靠摘要兜底长尾细节靠检索召回。三层配合才接近一个合格的对话记忆架构。下面用表格快速对比一下四种模式模式保留策略优点主要缺点典型场景截断保留最近N条直接丢弃旧的零成本、实现最简单关键约束容易丢失短问答、表单工具滑动窗口保留完整轮次按轮次滑动行为可预测不破坏对话结构窗口外信息完全丢失10-20轮的中短对话摘要旧摘要 最近原文保留语义要点成本可控信息逐级衰减需额外调用模型客服、角色陪伴向量记忆语义切片入库按需检索长时记忆能力强检索结果碎片化有工程成本复杂知识类、个人助手3. 手写一个可切换的context-mode管理器3.1 先把需求定清楚我自己的做法是不在产品代码里到处写死上下文处理逻辑而是抽出一个独立的上下文管理器对外只暴露一个接口输入全部历史消息输出真正会发送给模型的消息列表。这样不同模式可以透明切换出问题时也能单独排查。这个管理器需要满足几个硬性要求token预算可配置、系统提示词受保护、支持按完整轮次截断、可以组合摘要、每个模式下都能打印“实际发送了什么”方便调试时看模型到底看到了什么。3.2 token预算怎么分配动手写代码前先解决一个基础问题怎么算预算。直接用字符数去估算token数在不同模型上误差会非常大。中文场景尤其明显同样一段话按字数和按token数的比例波动很大。稳妥的方式是用tiktoken库OpenAI系模型或各模型的官方tokenizer来估算。import tiktoken def estimate_tokens(text, modelgpt-4): enc tiktoken.encoding_for_model(model) return len(enc.encode(text))预算分配上我通常遵循一个经验公式历史预算 模型窗口上限 - 系统提示词占用 - 本次用户输入 - 输出预留输出预留通常给总窗口的20%30%因为模型生成的回答也要占窗口。如果历史预算算出来是负数说明要么系统提示词太长要么输入太长需要先做输入侧的压缩。3.3 模式实现的核心代码我写了一个简化版实现保留了最关键的取舍逻辑方便你直接改造。from enum import Enum from typing import List, Dict, Any class ContextMode(str, Enum): TRUNCATE truncate SLIDING_WINDOW sliding_window SUMMARY summary class ContextManager: def __init__(self, mode: ContextMode, token_budget: int, llmNone): self.mode mode self.token_budget token_budget self.llm llm self.summary def build_messages(self, messages: List[Dict], system_prompt: str) - List[Dict]: system_tokens estimate_tokens(system_prompt) history_budget self.token_budget - system_tokens # 预留给输出和用户输入的”安全垫” history_budget int(history_budget * 0.7) if self.mode ContextMode.TRUNCATE: return self._truncate(messages, history_budget) elif self.mode ContextMode.SLIDING_WINDOW: return self._sliding_window(messages, history_budget) elif self.mode ContextMode.SUMMARY: return self._summary_mode(messages, history_budget, system_prompt) else: raise ValueError(fUnknown mode: {self.mode}) def _truncate(self, messages, budget): # 从尾部往前收集直到超出预算 result [] used 0 for msg in reversed(messages): t estimate_tokens(msg[content]) if used t budget: break result.append(msg) used t return list(reversed(result)) def _sliding_window(self, messages, budget): # 从尾部往前按完整轮次收集简单场景按2条消息为一轮处理 result [] used 0 step 2 # 一个完整轮次user assistant for i in range(len(messages) - step, -1, -step): chunk messages[i:istep] chunk_tokens sum(estimate_tokens(m[content]) for m in chunk) if used chunk_tokens budget: break result chunk result used chunk_tokens return result def _summary_mode(self, messages, budget, system_prompt): # 摘要模式下窗口留给最近对话更早内容压缩进摘要 recent [] recent_tokens 0 threshold int(budget * 0.5) # 最近对话最多占一半预算 for msg in reversed(messages): t estimate_tokens(msg[content]) if recent_tokens t threshold: break recent.append(msg) recent_tokens t recent list(reversed(recent)) older messages[:len(messages) - len(recent)] if older: self.summary self._update_summary(self.summary, older) if self.summary: summary_msg { role: system, content: f以下是更早对话的摘要请把它作为长期记忆参考\n{self.summary} } return [summary_msg] recent return recent def _update_summary(self, old_summary, older_messages): # 实际项目里用LLM调用这里保留接口 pass代码里有一段需要注意摘要模式下最近对话占预算的比例我设为50%这是一个经验值。如果业务场景特别依赖最近对话细节比如用户正在描述一个复杂需求可以把阈值调高到60%70%如果更看重历史约束就调低。3.4 怎么验证模式真的生效写完代码先别急着上线用数据检验。我的习惯是做一个“失忆压力测试”脚本里模拟一段20轮以上的对话在第3轮埋下一条明确约束比如“所有回答必须用列表形式”然后坚持聊到第20轮检查模型输出是否还能遵守。更细一点的做法是打印每次请求的实际上下文。我在ContextManager里加了一个debug开关输出每条消息的role、内容前50个字符、以及token数。这样能看到截断发生在哪条消息上、摘要到底保留了哪些信息、预算有没有被突破。实测中我发现很多看起来像“模型变笨”的问题在这一步就原形毕露了不是模型的问题是上下文里根本没有该有的信息。4. 模式切换的边界不同业务到底该选哪一种4.1 按对话轮次和业务类型判断选型没有银弹但有一个基本判断框架先定对话轮次预期再定信息重要程度。我根据自己的项目经验整理了下面这个参考表业务类型典型轮次推荐模式理由一次性问答、翻译、改写1-3轮截断模式没有历史依赖最简单即为最优售后客服、简单表单5-15轮滑动窗口结构完整成本低响应快保险咨询、理财顾问20-40轮摘要模式用户偏好和早期条件务必保留角色陪伴、情感倾诉长会话摘要 窗口既保留连续性又控制成本研究助手、知识问答多轮且碎片化窗口 向量检索需要跨会话长线记忆每类业务其实都有一个核心矛盾。售后客服的矛盾是成本与响应速度用滑动窗口最划算保险咨询的矛盾是早期条件不能丢用摘要模式专门保护约束研究助手的矛盾是信息太散窗口记不住只能靠检索。4.2 按用户体验预期和隐私约束判断选模式不只是技术问题还取决于用户“是否期待AI记得我”。如果产品定位是工具用户不在乎AI记不记得刚才说过的话截断模式完全够用。但如果是陪伴类、顾问类产品用户对记忆的敏感度极高一句“你之前不是说过了吗”就会导致流失。隐私层面也需要提前评估。摘要模式意味着把用户对话发给大模型做二次加工摘要本身也可能包含敏感信息向量库里的历史切片同样需要明确的存储策略和删除机制。我在一个金融类项目里就直接放弃了向量记忆方案只做窗口内摘要并且把摘要内容限制在脱敏后的范围内。4.3 token成本与延迟的量化计算选型时还要算账。我用一个实际案例给你演示假设平均每轮对话500 token每小时100轮。滑动窗口模式如果窗口设为20轮那么每次请求固定携带20轮历史也就是平均每次约10000 token的输入。按输入价格粗略估算一小时100轮的成本大约是输入量乘以单价。摘要模式则多了一次摘要生成的调用假设每10轮触发一次摘要重写每次摘要消耗约1500 token那么每小时多出15次额外调用。两者相比摘要模式在输入token上更省但多了额外的模型调用次数和等待时间。延迟上也不同。滑动窗口的输入长度基本稳定延迟波动不大摘要模式在触发重写的那一次请求会有明显变慢因为要先完成摘要调用再走主调用。如果对响应速度敏感可以把摘要更新放到后台异步执行而不是阻塞主链路。4.4 动态切换按会话长度自动升级模式我目前比较推荐的做法不是固定单一模式而是设置“升级阈值”会话前10轮用滑动窗口超过20轮自动切换成摘要模式超过50轮再叠加向量检索。这样既避免了短会话白白支付摘要成本也保证了长会话不丢记忆。动态切换有一个关键细节切换时不能直接丢掉窗口里的内容而是要先生成一份“当前状态摘要”把已有会话的要点固化下来再切换到新模式。否则切换瞬间就是一次失忆。5. 踩坑实录让context-mode失效的五个隐蔽问题5.1 token统计口径不一致我只踩过一次就长记性了。当时图省事直接用len(content)当token数来算预算中文场景下误差大得离谱结果经常出现请求超长被API拒绝或者截断后上下文信息严重不足。不同模型对中文的切分方式差异很大同一段中文有的tokenizer算出来是60个有的是90个。解决方式就是前面代码里展示的使用模型官方tokenizer来统一计算。别嫌麻烦这一步省下来的调试时间远超实现成本。5.2 摘要多轮重写后的信息逐级衰减这是摘要模式最隐蔽的问题我花了不少时间才定位到。第一轮摘要可能保留了“用户偏好简洁回复”第二轮重写后变“用户有偏好”第三轮直接消失。更麻烦的是这类衰减是渐进式的不对比最初的对话根本发现不了。我的应对办法是在摘要模板里强制加一个“约束列表”字段让模型每次摘要都单独输出一个list包含用户明确提过的偏好、不能做的事、还没完成的任务。这个列表在每次重写时单独保留并比对即使摘要正文发生了变化约束列表也要完整继承。5.3 截断后拼接了半个问答对滑动窗口如果按“条数”而不是“轮次”去截很容易出现“只保留assistant回答、丢了user提问”的情况。模型看到孤零零的回答会以为自己在续写输出就容易跑偏。这个问题在日志里非常隐蔽因为单条消息看起来都很正常组合起来才觉得奇怪。修法就是前面代码里的按userassistant成对保留永远从轮次边界切。5.4 系统提示词被历史消息挤占有一段时间我的产品老是出现“角色漂移”排查后发现是上下文拼接时系统提示词被算进了可截断范围内。当历史消息超过预算截断逻辑从头部开始丢弃结果把system消息也丢掉了。解决思路很简单系统提示词单独从预算中划出永远不参与截断。并且在拼接消息时把system消息放在最前面session级别的摘要作为第二条system消息历史对话按时间顺序排在后面。5.5 向量召回后的排序与去重问题向量记忆模式上线后我发现模型输出的逻辑经常“跳来跳去”。后来打印上下文才看清召回的三段记忆被我按相关度倒序拼接了最早的记忆出现在最后面模型看到的时间线完全错乱。修复方式是把召回的片段先按相关度筛选再按原始消息时间戳升序排列。另外要去重因为同一段历史可能被切成多个相近的块同时召回来后会让模型以为用户在重复表达。去重逻辑我放在写入向量库之前按内容哈希做唯一性检查。最后分享一点个人体会我在这个项目上最深的感受是context-mode不是一个“选完就完事”的开关而是一套需要持续调优的记忆架构。每个产品的对话节奏、信息密度、用户预期都不同只有不断用压力测试和数据去验证才能找到那个平衡点。如果让我给刚起步的团队一个建议那就是先实现可切换的上下文管理器再根据业务数据慢慢调不要一上来就追求复杂的混合记忆方案。另外一个小技巧所有对话产品的联调环境里都放一个“固定脚本长期对话测试”每次修改上下文策略后跑一遍比临时聊天验证靠谱得多。