单看 context-mode 这个项目名你可能会以为它只是一个配置文件里的键名或者是某个命令行工具的可选参数。但在大模型应用这个语境下我把这几个字母理解为“上下文模式”——它就是决定我们如何组织、投喂和回收上下文的一套开关机制。作为一个在 LLM 应用层摸爬滚打过的开发者我非常清楚这个看似普通的词背后藏着一个极难处理的工程问题到底该给模型多少上下文给哪些什么时候丢弃旧的、什么时候去检索新内容这篇文章我想完整复盘一下自己在落地 context-mode 这套上下文管理模式时的设计思路和踩坑记录。方案不绑定具体框架用纯 Python 的思路把核心机制讲清楚目标是让正在做智能客服、AI 助手、知识库问答的团队能直接抄走里面的关键设计。不论你是负责架构的研发还是刚接触 LLM 应用的新手这篇内容都会让你少走好几段弯路。1. 为什么会需要一个“上下文模式”1.1 大模型上下文窗口的物理限制就算现在各家模型把上下文窗口卷到了 128K、200K 甚至 1M看起来能塞下整本书但真正做应用的人心里都清楚“有效上下文”远比纸面参数小。注意力机制在超长输入上会明显稀释模型对放在中间位置的信息常常记不住学术点说叫 lost in the middle。也就是说你把两万行的项目代码全部塞给模型它处理到后半部分时前面几行的细节可能已经变成“模糊印象”了。这意味着上下文本质上是一种会被“消耗”和“衰减”的资源不是塞得越多越好。我见过不少团队在初期犯同一个错误为了让回答质量更高把尽可能多的历史消息、文档片段、web 搜索结果全拼进 prompt 里喂给模型。结果 token 账单涨得飞快回答质量却没有明显提升甚至出现前后矛盾、指令被淹没的情况。上下文窗口看起来很大其实大多数时候我们只能把最核心、最相关的那部分放进去。1.2 无脑塞上下文带来的三个负面效应把问题拆开看不加节制地堆栈上下文会引发三个连锁反应。第一是费用失控。输入 token 的成本这几年降了不少但每天百万级请求量级的应用每多塞 1000 个 token 都是实打实的成本。如果每个请求都携带完整对话历史和待检索文档月底看账单时会有点肉疼。第二是响应延迟变长。模型在 prefill 阶段需要处理所有输入的 token上下文越长首 token 返回时间越慢。对 C 端产品来说几百毫秒的差异用户就能感受到“变卡了”。第三是输出质量下降。当系统指令被夹在一大堆无关历史中间模型对指令的执行优先级会降低。典型表现是用户问了一个全新问题模型却还在顺着旧话题往下聊或者回答里带上旧上下文中不相关的细节。这三个负面效应共同指向一个结论应用必须根据当前场景选择一种合适的上下文使用方式。这就是 context-mode 要解决的核心问题。它不是某个高深的算法而是把“用哪种方式组织上下文”沉淀成一组可枚举、可编程、可观测的模式。2. 四种主流上下文模式的设计拆解2.1 连续对话模式滑动窗口怎么定才合理先说我最早实现、也是最常用的模式——连续对话模式。它适用于客服、角色扮演、日常闲聊这类以多轮互动为主的产品。核心逻辑是把系统指令、用户身份、最近 N 轮对话组成一个滑动窗口一起送给模型。滑动窗口的长度不能拍脑袋定我建议用“经验轮数 token 上限”双限制。比如保留最近 10 轮用户与 AI 消息同时规定窗口内 token 总数不超过 6000一旦超过就淘汰最旧的消息。为什么要双限制因为有的用户一句话能写几百字有的则惜字如金。只按轮数截断可能塞爆 token只按 token 截断又可能把一段完整的问答拦腰截断。具体保留多少轮要看你产品的业务形态。客服场景里用户可能隔几轮就提到同一个订单号历史信息很关键建议保留 15 轮左右。角色扮演类应用更看重连贯性建议保留最近 20 轮同时让摘要模块做兜底。这里没有通用最优值只有适合你业务的值。2.2 检索增强模式top k 不是越大越好第二种是检索增强模式典型场景是知识库问答。流程是用户提问后先做意图解析再去向量数据库或外部知识库检索相关内容最后把检索结果和用户问题一起作为上下文送给模型。这里最关键的是“检索质量”而不是“检索数量”。我在落地时有一条特别深的体会不要把 top k 设得过高。很多人觉得检索出 10 条甚至 20 条结果喂给模型信息量大就一定好。但实际经验是当多个片段自相矛盾或来自不同文档时模型的“幻觉率”反而上升。更稳妥的做法是每个问题只取 35 个高相关片段每个片段控制在 500800 字在 prompt 中明确标注每个片段的来源标题。这样模型既能有足够的信息作答又能避免被互相干扰的内容带偏。推荐的做法是给每个检索片段加一个“相关性得分”字段低于某个阈值就直接丢弃而不是硬性塞满 top k。宁可让模型说“根据当前资料我无法回答”也不要让它拿低相关度的内容强行编造答案。2.3 摘要压缩模式用小模型换主模型的长文本开销第三种是摘要压缩模式用于长对话、长文档总结这类场景。本质是用一次额外的小模型调用把超长内容浓缩成带关键信息的摘要再用摘要替换原文进入主模型。这里有个成本陷阱你省下了主模型的长文本处理费用却多了一次摘要模型的调用。如果摘要模型选得不好摘要质量差主模型照样回答不好。我的做法是摘要模型选用比主模型小一个档次的快模型并且要求它输出结构化摘要——任务背景、已确认的信息、未解决的问题、最新进展四个板块。这样一来主模型拿到的不再是一团压缩过度的“浆糊”而是结构清晰、便于引用的信息骨架。还有一点要提醒摘要本身也是 token也会占用窗口预算。不要做“摘要套摘要”的层层嵌套最好只做一层必要时保留一份原文的检索索引等用户问细节时再跳到检索增强模式去捞原文。2.4 单发指令模式别让历史消息干扰无状态任务最后一种模式最简单但使用频率极高——单发指令模式。它只携带系统指令和用户当前输入不携带任何历史消息。适用于翻译、改写、结构化信息抽取、关键词生成这类无状态任务。这种模式经常被低估不少团队把这类请求也放进多轮历史里结果模型受到上一轮对话的影响输出忽好忽坏。比如用户先问了几个闲聊问题然后突然说“帮我把这句话翻译成英文”如果系统把上一段关于晚餐吃什么的闲聊也带进翻译场景模型翻译出的语气都可能带点主观色彩。把无状态任务和对话任务分开用独立的 context-mode 管理是架构上很小的调整收益却非常明显每次输出都像第一次调用一样干净。看到这里你可能会发现context-mode 并不是一个复杂的“新算法”它只是把几种常见策略整合成了一个可编程的字段。这就是它的价值所在让上层业务代码只需要传一个 mode 类型就能获得对应的上下文管理行为而不是每个业务线各自维护一套提示词拼接逻辑。3. 核心实现一个可落地的 ContextManager3.1 数据结构与模式判定先决定 mode再加载 context现在讲落地。我不打算把代码绑定到 LangChain 或其他框架用一个纯 Python 类把核心机制说清楚。首先定义一个枚举from enum import Enum class ContextMode(Enum): CONTINUATION continuation # 连续对话 RETRIEVAL retrieval # 检索增强 COMPRESSION compression # 摘要压缩 STATELESS stateless # 单发指令然后围绕这四个模式设计 ContextManager。最重要的一个设计原则是先判定模式再加载上下文。业务请求进来时系统除非显式指定 mode否则不要直接默认走连续对话。我通常用如下的判定方法class ContextManager: def __init__(self, mode_providerNone): self.mode ContextMode.CONTINUATION self._mode_provider mode_provider or self._default_mode_provider def _default_mode_provider(self, request) - ContextMode: # 优先级显式标记 规则特征 默认连续对话 if request.get(force_mode): return ContextMode(request[force_mode]) msg request.get(message, ) # 是否触发知识库检索 if request.get(retrieval_hit) or _need_search(msg): return ContextMode.RETRIEVAL # 是否为无状态任务 if _is_stateless_task(msg): return ContextMode.STATELESS # 历史过长则压缩 if request.get(history_tokens, 0) 10000: return ContextMode.COMPRESSION return ContextMode.CONTINUATION这里 _need_search 和 _is_stateless_task 需要根据业务填充可以用关键词表、正则、甚至一个小分类模型。但我必须强调模式判定本身不能引入太高延迟不要为了判断模式而先调用一次重量级模型。用轻量规则把大多数请求分好少数难以判定的再走模型兜底。这样的好处是整个上下文加载流程有了一个统一入口日志里可以记录每个请求进入了哪种模式后续优化和排查也有了抓手。3.2 窗口滑动与预算分配把钱花在刀刃上核心环节是窗口管理和 token 预算分配。无论哪种模式都要面对同一个问题一次模型调用的 token 预算怎么分。我把一次调用的上下文分成四部分system 指令、context模式内容、history历史消息、user input用户输入。class ContextManager: def build_prompt(self, request, budgets): # budgets 形如 {system: 800, context: 2000, history: 4000, input: 500} mode self.resolve_mode(request) if mode ContextMode.CONTINUATION: history self._sliding_window(request[history], budgets[history]) context_block [] elif mode ContextMode.RETRIEVAL: docs self._retrieve(request[query], top_k4) context_block self._compact_docs(docs, budgets[context]) history [] elif mode ContextMode.COMPRESSION: summary self._summarize(request[history]) context_block [summary] history [] else: # STATELESS context_block [] history [] return self._assemble(system_prompt, context_block, history, request[message])实操时budget 通常由模型名、请求 QPS、用户套餐共同决定。我强烈建议建立一个“模型有效上下文长度映射表”不要直接使用模型的纸面最大窗口。比如某模型声称支持 128K我给的配置可能只用到 90K预留一部分给输出 token 和突发情况。_token 预算宁可估得紧一点也不要满打满算。一旦触发 token 截断模型可能丢掉结尾附近的真实用户输入这种错误极难排查。我给系统定的规则是用户输入永远不截断System 指令永远不截断只对 history 和检索 context 做动态裁剪。3.3 模式切换状态机从闲聊切检索不翻车到这里还有一个必须解决的问题同一场会话中模式是会变化的。用户先聊了几句家常然后问一个需要查文档的问题之后又继续闲聊。如果模式切换处理不好会出现很糟糕的体验——模型在检索任务里沿用闲聊的轻松口吻或者把上一段闲聊误当作文档摘要来解读。我的方案是维护一个轻量状态机记录每个模式最近一次使用的上下文快照class ContextModeStateMachine: def __init__(self): self.history [] self.last_mode ContextMode.CONTINUATION self.mode_map {} # mode - context snapshot def transition(self, new_mode, retriever): # 保留新模式需要的最小上下文 if new_mode ContextMode.RETRIEVAL: # 只保留最近一轮对话作为背景不携带完整历史 snapshot self.history[-2:] if self.history else [] elif new_mode ContextMode.CONTINUATION: # 回到闲聊时恢复最近一小段记忆 snapshot self.history[-4:] else: snapshot [] self.mode_map[new_mode] snapshot if new_mode ContextMode.CONTINUATION: self.history.extend(snapshot) return self.mode_map[new_mode]这个状态机的核心思想是模式切换不是直接清空历史而是选择一个低干扰的上下文切片作为新模式的进入条件。比如从连续对话切到检索增强我可以把最近一轮用户问题带上作为检索的语义上下文但把前十几轮闲聊全部隔离在外。这样既保证了检索意图清晰又不会让模型被无关聊天记录带偏。我不建议在同一个请求内做多模式串联比如先摘要再检索再把两者拼接。虽然有些场景效果看着更“智能”但调试复杂度和 bug 率都会翻倍线上延迟也会变高。先把单模式跑稳再去想多模式串联的优化。4. 实操过程中踩过的坑与排查方法4.1 上下文污染AI 突然“人格分裂”第一个高频坑是上下文污染。典型现象用户刚聊完午饭吃什么紧接着发来一个新链接说“帮我总结这个”模型却回答出“根据我们刚才聊到的这个链接……”这类混搭话术。用户会觉得 AI 状态极其不稳定。排查思路很直接把实际发送给模型的 prompt 完整 dump 到日志里你会看到 history 字段里混入了大量与当前任务无关的消息。修复方式很简单对检索增强模式和摘要压缩模式开启“历史隔离”这两种模式的 prompt 默认不携带完整聊天记录只保留必要的一两句背景。我把常见症状和排查点整理在下表症状可能原因检查点模型在检索任务中沿用闲聊口吻检索模式上下文混杂多轮历史查看实际 prompt 是否包含 history 字段模型重复引用旧文档片段旧文档在模式切换后没有失效检查上下文快照是否按会话和模式双维度隔离回答内容跳跃、前言不搭后语多个模式片段被强行拼接检查是否在某次请求中使用了多模式串联摘要质量差主模型答非所问摘要模型选得太小或 prompt 不结构化审查摘要模型的输出格式是否要求了背景/信息/结论这个表中的每一条都是我实际遇到过的线上问题。修复它们不需要什么高深技巧核心就是保证每种模式只能看到自己该看的内容。4.2 Token 预算被低估中文按字符数估算必炸第二个高频坑是 token 预算被低估。很多新手按“字符数除以 4”来估算 token结果系统频繁报“超出最大长度”。原因很简单中文字符在多数主流模型的分词器里可能对应 1.52.5 个 token代码片段和 emoji 表情更是吃 token 大户。按字符数硬套长文本场景一定会炸。我的经验是在 ContextManager 里内置一个 token 预估器不依赖外部库也可以先做一个简单的启发式估算def estimate_tokens(text: str) - int: # 中文按 1.8 token/字符英文按 0.3 token/字符 if not text: return 0 zh sum(1 for ch in text if \u4e00 ch \u9fff) en len(text) - zh return int(zh * 1.8 en * 0.3) 1这个估算不精确但用在预算分配上已经足够。更精确的做法是集成对应模型的 tokenizer但远程调用有额外性能开销生产环境建议做成异步预计算。我最终采用的是双阈值机制先按启发式估算做粗分配真正组装 prompt 前再用精确 tokenizer 校验一次如果超限则优先裁减 history。另外使用 API 时要留意部分模型会对 max_tokens输出上限和输入 token 之和做整体限制。我见过明明输入只有 2000 token却因为设置了很大的 max_tokens 而报错的案例。输出预算也是预算千万别漏算。4.3 自动模式判定的抖动问题第三个坑来自自动模式判定。自动判定省心但会有抖动。典型场景用户问“你还在吗”规则引擎判成闲聊进入连续对话模式下一句“帮我在知识库找一份报销制度文档”又强烈触发检索增强模式。这种频繁来回切换会让用户觉得 AI 状态不稳定。我的解决办法是引入“模式粘性”机制如果当前会话已经处于某个模式并且新请求的特征没有强烈到必须切换就沿用当前模式而不是每轮都重新判定。具体实现可以加一个冷却窗口比如最近 3 轮内不做模式变更。这牺牲了一点“灵活性”但换来了输出基调的一致性。线上还建议在每次请求的 trace 日志中记录 mode 字段、判定置信度和上下文大小。这样一旦出问题落盘一条带完整 prompt 和 mode 的记录就能快速还原现场。上下文工程这条路没有日志做支撑排查问题就像蒙着眼睛走迷宫。结尾最后再分享一个我在生产环境常用的调试技巧临时打开“上下文可视模式”把每次请求的最终 prompt 以 JSON 形式记录到单独的表里带 mode、各段 token 占比和实际响应。这个小改动花不了半小时但能帮你回答一个最基础的问题——模型到底看到了什么。真实生产环境中大量所谓的“模型变笨了”“模型乱说话”追根溯源都是上下文组织出了问题而不是模型本身出了问题。context-mode 这套设计大的方向已经比较稳定但我仍在不断调优模式判定规则和 token 预算分配权重。如果你的业务也正在被上下文管理困扰不妨从这四种模式入手做一层抽象先把最核心的连续对话和检索增强两种模式落地再逐步扩展。踩过几次坑之后你会发现上下文管理不是杂活它本身就是 AI 产品质量的核心组成部分。