如果你正在做AI应用不管是聊天机器人、文档问答、智能客服还是Agent类项目大概率迟早会撞上同一个问题上下文到底该怎么管。context-mode这个配置项我以前一直以为只是个开关——切一下模式就行直到在真实项目里被上下文爆掉、模型失忆、账单飙升这几件事轮番教育之后才意识到它背后其实是一整套策略体系。这篇文章会把我在一个企业知识库问答机器人项目里从0到1实现context-mode的完整过程写下来。内容包括三件事为什么一定要做上下文模式、核心的窗口分配和压缩策略怎么选、以及一套可以直接抄作业的代码实现和排查清单。做AI应用的产品经理、后端开发、独立开发者都可以拿来参考尤其是那种对话轮数一多就出错、一长就超时、一复杂就烧钱的项目基本都能在这里找到解法。1. context-mode到底在解决什么问题1.1 上下文是AI应用最大的隐形瓶颈先说一个很多人忽略的事实大语言模型本身的能力再强也架不住你把上下文窗口塞爆。当前主流模型的上下文窗口虽然越做越大从4K、8K到128K甚至更长但“能容纳”和“能精准使用”完全是两回事。窗口一长模型对关键信息的注意力会被稀释生成质量下降响应延迟变大tokens消耗成倍增加。更麻烦的是大部分模型对超长上下文的计费毫不留情一轮对话塞进去几万tokens成本直接肉眼可见地涨。context-mode要解决的就是这个问题在模型能力不变的前提下通过一套策略决定哪些信息进窗口、以什么形式进、在窗口里保留多久。它不是某个函数或配置项那么简单它决定了你的AI应用是“聪明但贵”还是“便宜且稳”。我们团队做的那个知识库问答机器人最开始就是简单粗暴地把所有聊天记录和检索文档一股脑丢给模型。Demo阶段一切正常一上生产就现原形用户在第八轮追问的时候响应开始明显变慢到第十五轮模型已经开始回答一些和当前问题无关的内容明显是记录太多、上下文混乱了到第二十轮直接报错超时。那段时间每天都被业务方反馈“机器人是不是傻了”。1.2 从一次失败案例说起我们是怎么被上下文逼疯的这个项目最大的痛点是用户问问题不是一次性的而是像真实对话一样反复追问、纠正、补充。比如用户先问“这个季度的销售数据怎么样”接着会问“那华东区呢”“为什么华东区下滑”“和上个季度比呢”“主要产品线哪些跌了”这些问题之间有关联性模型必须记住前面的对话才能准确回答。问题在于问答系统的每一步都会叠加“系统提示词 历史对话 检索到的文档片段 当前问题”四样东西加起来非常可观。销售数据相关的文档可能一次检索就塞进3000多个tokens而历史对话每轮又要几百tokens。十几轮对话下来单次请求直接上万tokens。当时我们用的模型上下文窗口是8K超过就报错。项目最紧急的时候我直接写了个最粗暴的截断逻辑只保留最近5条历史消息。结果是上下文不再超限了但模型开始频繁“失忆”。用户问“那华东区呢”模型根本不知道“那”指的是哪个季度开始一本正经地胡说八道。就是那一刻我意识到context-mode不是简单“砍掉历史”而是要在信息保留、生成质量、成本控制之间找平衡。后来我才认真去梳理了命名空间里那一堆看似高级的模式short、balanced、long、auto每个都不是拍脑袋来的背后对应的是完全不同的取舍逻辑。1.3 三种基础模式short / balanced / long我建议不要把context-mode理解成“大小档位”而是理解成三种信息管理策略模式窗口利用策略适合场景优点风险short只保留最近消息摘要严格控制总token高频短对话、简单问答、客服转接响应快、成本低、稳定复杂多轮推理容易失忆balanced最近消息全量保留中间消息摘要压缩关键实体清单大多数业务场景推荐默认兼顾质量与成本摘要质量直接影响效果long大量保留原始历史尽量少压缩长文档分析、需要逐句核对原文的场景信息完整、事实还原度高贵、慢、窗口压力大三种模式不是固定不变的更合理的做法是让同一套系统支持任意切换同时还能做到切换后不丢关键信息。这就引出了下一个问题窗口资源到底该怎么分配以及用什么技术手段来做这种分配。2. 设计context-mode时最关键的几个决策2.1 窗口资源怎么分配才不浪费大模型的上下文窗口就像一张办公桌桌面空间有限你不能把所有文件都摊在上面得想清楚哪些放桌上、哪些收进抽屉、哪些只留一份目录索引。我在具体实现时把窗口分成四个区段系统提示词System Prompt固定角色的行为设定比如“你是销售数据分析助手回答必须基于提供的资料”。这部分是每次请求都带的原则上要用最精简的表述把规则说清不能把长篇大论的说明塞进去。检索注入块RAG Block根据当前问题从知识库检索出来的文档片段。这是动态变化的通常会占用大头。历史对话History用户和助手的多轮对话记录。最占空间也是最需要策略处理的部分。当前问题Current Query用户这一轮刚输入的内容必须完整保留。分配顺序上有个经验法则系统提示词要控制在总窗口的10%以内当前问题和检索注入块加起来不要超过40%剩下的50%左右留给历史对话和摘要。如果你的系统提示词动不动就占2000 tokens那说明规则写得太啰嗦了该精简的是它而不是去压缩历史。2.2 压缩策略截断、摘要、结构化记忆三件套核心决策在历史对话这一块。说白了就三种做法第一种是截断Truncation保留最近的N条消息更早的彻底丢掉。优点是简单、零成本缺点是模型对前面的关键信息完全失忆。这种方案适合那种每轮对话相对独立、不牵扯太多前情提要求的场景。第二种是摘要Summarization把早期对话交给模型压缩成一小段摘要保留重要结论和动作项。比如用户在第10轮说过“我要的是2025年的数据不是2024年的”这条信息如果被截断掉后面所有回答都会跑偏但如果写进摘要“用户已明确要求2025年数据”后面就能一直用对。缺点是摘要本身有损而且多轮摘要后可能出现事实模糊。第三种是结构化记忆Structured Memory从对话里提取结构化信息比如用户偏好、关键实体、约束条件以KV列表或JSON形式存下来每次请求时直接作为上下文携带。这个我和摘要会结合用摘要负责压缩叙述性内容结构化记忆负责锁定事实性信息比如“客户名称某企业”、“对比基准去年同期”、“时间范围2025年Q1”。真正好用的context-mode不是三选一而是三件事配合近期的、和当前话题直接相关的历史 → 全量保留较早的、仍然有参考价值的历史 → 摘要压缩所有对话中出现的实体、偏好、决策 → 结构化记忆单独保存2.3 成本控制缓存命中与token复用聊完信息分配必须单独说成本。上下文管理做不好最直接的结果就是账单爆炸。我们上线第一周光模型调用费用就比预估高了40%后面才发现是缓存没做。现在的模型供应商基本都提供提示缓存prompt caching原理很简单如果请求的开头部分和上一次请求完全一样这部分tokens就可以用缓存价结算比正常价格便宜很多。举个例子我们用的模型正常输入价格是0.003元/千tokens缓存命中后只要0.0003元/千tokens差了整整一个量级。要做缓存命中设计上有几个讲究把固定内容放在最前面。系统提示词、结构化记忆这些稳定的内容放在消息数组最前面这样它们永远可以命中缓存。把动态内容尽量往后放。最新检索到的文档、最近的消息放在后面因为它们每次都在变。保持格式稳定。同一批历史消息不要今天放在system角色里、明天放在user角色里前缀的变化会导致整段缓存失效。context-mode里加上缓存开关后我们每月的模型调用成本直接降了接近一半。这笔账只要算一次就知道上下文策略绝不只是一个技术细节它是和成本强相关的架构设计。3. 从0到1实现一个context-mode模块3.1 定义配置与数据结构先把模式配置定义清楚。我用的语言是Python配置类长这样from dataclasses import dataclass, field dataclass class ContextModeConfig: mode: str balanced # short / balanced / long / auto max_total_tokens: int 8000 # 模型上下文上限留10%余量 system_prompt_tokens: int 800 max_history_messages: int 20 # 最近消息全量保留的条数 max_summary_tokens: int 1800 # 压缩摘要的最大token数 max_rag_tokens: int 2500 # 检索注入块的最大token数 enable_rag: bool True rag_top_k: int 3 enable_summary: bool True enable_memory: bool True enable_cache: bool True def __post_init__(self): if self.mode short: self.max_history_messages 8 self.max_summary_tokens 600 self.max_rag_tokens 1200 elif self.mode long: self.max_history_messages 60 self.max_summary_tokens 3000 self.max_rag_tokens 4000提示max_total_tokens不要顶格设到模型上限要给输出预留空间。如果模型窗口是8K建议配置7K左右剩下的留给生成回答的部分不然会出现“输入端刚够、输出端爆掉”的尴尬。数据层面每次请求的上下文消息最后统一转成OpenAI风格的消息列表方便对接不同模型。3.2 滑动窗口裁剪的实现先写最基础的滑动窗口。思想很直接系统提示词永远保留最近的N条消息保留更早的踢出但踢出之前会先触发下一步的摘要归档避免纯截断带来的信息丢失。class ContextManager: def __init__(self, config: ContextModeConfig): self.config config self.summary_store SummaryStore() # 摘要存储建议落库 self.memory_store MemoryStore() # 结构化记忆存储 def build_messages(self, history, current_query): # 组装最终发送给模型的消息列表 system [{role: system, content: SYSTEM_PROMPT}] # 1. 结构化记忆转成一段稳定的上下文放在最前有利于缓存命中 memory_text self.memory_store.render() if memory_text: system.append({ role: system, content: 用户关键信息备忘\n memory_text }) # 2. 带上历史摘要比raw history更省token summary_text self.summary_store.load() if self.config.enable_summary and summary_text: system.append({ role: system, content: 前期对话摘要\n summary_text }) # 3. RAG检索块 if self.config.enable_rag: rag_text self._retrieve(current_query) if rag_text: system.append({ role: system, content: 参考知识片段\n rag_text }) # 4. 最近的对话消息只保留最近N条 recent_history history[-self.config.max_history_messages:] # 5. 超过窗口的旧历史先做压缩归档 older_history history[:-self.config.max_history_messages] if older_history and self.config.enable_summary: new_summary self._summarize(older_history) self.summary_store.merge(new_summary) return system recent_history [ {role: user, content: current_query} ]这段代码是核心骨架逻辑上把四个区块组装在了一起。这里有个容易被忽略的细节older_history是在每次请求时处理的意思是说哪怕用户不提问题只要ContextManager被调一次就会触发一次压缩这在业务上会浪费调用费。更稳妥的做法是设置一个归档阈值比如“历史消息超过40条才触发压缩”或者“每次调用最多只压缩最早的一半”避免重复处理。3.3 摘要压缩的实现摘要压缩是整个机制里影响质量最大的一环。我试过直接用文本截断、用简单拼接、用模型总结结论是必须用模型总结但提示词要设计得足够严格不然摘要会越来越“懒”——越后面生成的摘要越笼统丢失细节。def _summarize(self, messages, budget_tokens1800): content \n.join( f{m[role]}: {m[content]} for m in messages ) prompt f请将以下对话压缩为结构化摘要要求 1. 保留所有事实性信息时间、数字、用户明确表达的偏好和约束 2. 保留所有未完成的动作和待办 3. 压缩叙述性文字不要复述无关寒暄 4. 按事实、偏好、待办三个小节组织输出 5. 不要猜测原文没有的信息不要写 对话内容 {content} resp call_llm(prompt, max_tokensbudget_tokens) return parse_response(resp)注意摘要里面坚决不能出现“推测”、“也许”、“可能”这类臆测信息。一旦摘要塞进了幻觉内容它就会污染后续每一轮回答而且因为是二次加工错误还会被放大。我在实际运行中还加了一层校验规则用关键词检查摘要里有没有“用户说/用户认为”这类伪事实发现疑似内容就重新生成。摘要存储时我会带上created_at和消息范围id方便以后回溯。这样如果某一轮回答质量异常可以查到当时用的是哪份摘要定位是不是摘要被污染了。3.4 混合模式RAG外部上下文注入知识库问答离不开检索增强生成也就是RAG。“context-mode”和RAG的关系很容易搞混我理一下RAG解决的是“把外部知识放进来”的问题context-mode解决的是“放进来之后如何管理窗口”的问题。两者要配合而不是二选一。RAG部分有一个非常影响上下文质量的参数窗口检索数量。不是检索越多越好检索多了会带来两个问题一是挤占上下文空间二是不同文档之间可能互相矛盾模型会被带偏。def _retrieve(self, query): docs vector_store.search(query, top_kself.config.rag_top_k) # 限制注入量超出部分宁可截断也不全塞 total_tokens estimate_tokens(docs) if total_tokens self.config.max_rag_tokens: docs self._trim_to_budget(docs, self.config.max_rag_tokens) return format_docs(docs)排序方面我也踩过坑向量检索得分最高的文档并不一定是最需要的。后来我在RAG注入前加了一步非常轻量的重排rerank用一个小的交叉编码器模型对Top-K候选重新打分。重排后相同token预算下回答准确率提升了不止一点。这个步骤不算复杂但对最终效果的影响比调整摘要提示词还要明显。3.5 一次真实压测的数据方案落地后我专门做了一轮对比压测模拟同一用户连续提问30轮分别跑无上下文管理、纯截断、balanced模式三组。数据如下方案平均单轮输入tokens平均响应时间30轮总成本(相对)30轮后回答准确率全部历史无脑塞入逐步增长到爆窗口越来越慢后段不可用4.2x不可用纯截断保留最近5条约2.1K稳定快1.0x58%明显失忆balanced完整实现约3.8K稳定中1.8x86%可接受cost那个相对值是基于纯截断为1.0算的balanced虽然贵了一些但因为不会爆窗口、不会超时重试综合成功率反而更高。准确率是我自己标注的40个重复追问场景让另外一位同事盲评pass率。这个数据基本验证了balanced模式是大多数业务场景的最优解。同时也说明完全没有上下文策略的应用跑不了真实业务而只会截断的应用虽然便宜但用户体验会快速崩坏。4. 常见问题与排查技巧实录无论设计多完美real-world系统的毛病永远比预想多。这章列几个我真实遇到过的坑每个都附带排查思路。4.1 截断后模型“失忆”怎么定位是哪一段被切了症状用户之前明确说过“对比要用去年四季度”到了第20轮模型开始用今年的数据对比。排查方法说话类问题先把ContextManager生成的最终消息列表dump下来人工检查系统提示词和历史消息里到底还有没有“去年四季度”这几个字。没有就是被丢掉了有的是模型自己没注意。修复思路这种信息属于事实性约束不应该寄希望于它在历史消息里存活应该在每轮对话后跑一次实体和约束提取把“去年四季度”写进结构化记忆区。这样哪怕历史被截断、摘要被压缩关键约束永远跟着请求走。4.2 摘要越滚越失真问到最后开始胡说八道症状前5轮回答很准到第40轮模型开始把一个用户根本没说过的需求当作前提来回答。原因摘要层叠累积后产生了“信息熵增”。摘要A到摘要B再到摘要C每层都会有信息损耗到了用户真正需要的时候原始事实已经被加工得面目全非。修复方案给摘要存储加一个refresh机制当同一天的摘要超过两轮更新就用原始对话重新生成而不是在旧摘要上继续叠加。关键事实用户姓名、时间范围、数字指标单独存结构化记忆不参与摘要压缩。定期清理摘要对话超过48小时但没结束的重新从原始记录生成一份完整摘要。4.3 缓存命中率上不去钱总在莫名燃烧症状开了缓存账单还是不对劲查日志发现缓存命中率只有个位数。原因系统提示词里拼接了动态内容比如把当前时间写进了system prompt最前面导致每次请求前缀都不同缓存全部失效。修复固定内容的顺序时间、会话ID这类动态信息放在消息列表靠后的位置如果要记录时间让模型在回答时自行注明时间判断或者单独放在最后一条user消息里。还有一个隐蔽的坑结构化记忆区虽然放在前面但如果记忆内容每轮都变整个前缀也全部失效。解决方法是记忆区也设计成“先取缓存快照再计算增量”虽然实现麻烦一些但缓存收益足以覆盖开发成本。4.4 RAG注入的知识互相矛盾模型被带偏症状一篇文档说“项目周期为3个月”另一篇说“项目周期为6个月”模型大概率会取最近注入的那篇但哪篇近是随机的于是回答忽左忽右。解法给每篇注入给到一个权重标注系统提示词里写明“如果资料冲突以最新发布日期为准”。在检索时按发布时间元数据进行过滤把同一主题的更早版本直接过滤掉。把conflict的情况当成一个显式Prompt任务先让模型识别冲突再让它说明采纳了哪条信息这个策略对复杂问答特别有用。5. 几个值得长期坚持的设计原则5.1 上下文管理一定要做成可观测的我刚开始做这个模块时调试全靠print痛苦得要命。后来给ContextManager加了三个埋点组装后的消息总tokens、系统提示词占比、摘要触发次数和耗时。有了这些指标用户反馈“机器人变笨了”时我可以先看系统监控基本一眼就能定位是不是上下文策略某天被改动导致的。如果只是给自己用可以把每次请求的组装结果落一份JSON日志。排查问题时先看这份JSON再去看模型返回结果会比盲猜高效非常多。5.2 模式切换一定要保持可回滚context-mode上线后如果新方案让准确率下降你得有能力一键切回旧方案。我建议把配置持久化到配置中心不要写死在代码里。业务方在后台可以直接调整当前项目的模式比如新项目默认short等数据积累后再切balanced。另外每次压缩策略升级时我会保留旧策略的代码分支一段时间。线上跑新逻辑的同时流量打一份到旧逻辑做对比。宁可多费点服务器资源也要保证策略改动是可对比、可回滚的。这是做AI应用和做普通后端服务很大的一个区别模型行为有不确定性没有A/B验证之前任何“优化”都可能其实是劣化。最后再分享一个小技巧context-mode里的“auto”模式我现在的实现其实很简单——根据当前问题里的关键词判断复杂度比如出现“对比、为什么、分析、总结”这类词就走balanced或long简单事实问句就走short。这不算什么高深算法但在真实用户场景里已经足够好用。上下文管理这个难题从来没有银弹只有一整套组合策略并且在真实数据上反复打磨细节。希望这篇文章能帮你少走一段弯路。