1. 从context-mode这个词说起它到底指什么第一次看到context-mode这个标题很多人会愣一下——它不像XX管理系统或XX爬虫那样一眼能看出用途。我最初接触这个词是在做对话系统上下文管理的时候当时团队里有人提出给会话加一个模式开关用来区分不同场景下上下文该怎么拼、怎么裁、怎么传。后来我发现context-mode其实是一个相当通用的概念它描述的是系统在处理信息时对上下文采取的策略模式。换句话说context-mode 不是一个具体的库或框架而是一种设计思路同一套核心逻辑根据当前所处的模式决定带多少上下文带哪些上下文上下文以什么优先级参与计算。这个思路在大模型应用、推荐系统、状态机、甚至前端路由守卫里都能见到影子。举个生活化的例子。你去医院看病挂号时护士问你哪里不舒服这是精简模式——只收集最关键的主诉进了诊室医生会追问病史、过敏史、用药情况这是完整模式——上下文拉满如果是复诊医生直接调出上次的病历这是继承模式——复用历史上下文。同一个看病流程因为场景不同上下文的处理方式完全不同。context-mode 要解决的就是这类问题。那为什么现在这个词越来越热因为大模型应用爆发之后上下文窗口成了稀缺资源。一个对话轮次里塞太多历史token 成本飙升、响应变慢、还容易跑偏塞太少模型又记不住前面说过什么答非所问。于是按模式管理上下文从可选项变成了必选项。这篇博文就围绕 context-mode 这个核心把它的设计动机、模式划分、实现细节、踩坑经验完整拆一遍适合正在做对话系统、Agent、或者任何需要管理状态历史的开发者参考。2. 为什么需要给上下文分模式三个绕不开的现实约束2.1 上下文窗口不是无限大的token 是要花钱的很多人做第一版对话功能时习惯把全部历史消息一股脑塞进请求里。跑 demo 没问题一上量就出事了。假设每轮对话平均 300 token用户聊了 20 轮那就是 6000 token 的输入。如果按主流 API 的计费方式输入 token 是实打实要付费的而且随着轮次增加成本是线性甚至超线性增长的——因为每一轮都要把之前所有轮次重新传一遍。我做过一个粗略测算一个日活 1000 的对话应用如果平均每人每天聊 15 轮不做任何上下文裁剪光输入 token 的月成本就能比做裁剪高出 3 到 5 倍。这不是危言耸听是真实账单上的数字。所以 context-mode 的第一个动机非常朴素省钱、省资源。2.2 上下文越长模型越容易注意力涣散这一点反直觉但实测下来非常明显。当你把 8000 token 的历史塞给模型问一个只需要最近 2 轮信息就能回答的问题时模型反而可能被中间某段无关历史干扰给出偏离的答案。业界管这叫lost in the middle——模型对上下文中间部分的信息利用率明显低于开头和结尾。所以上下文越多越好是个伪命题。正确的做法是根据当前任务需要动态决定带多少、带哪段。这正是 context-mode 要干的事。比如用户问刚才那个方案的第二点是什么你就需要精准定位到刚才那个方案所在的轮次而不是把全部历史都带上。2.3 不同场景对记忆的要求天然不同同一个应用里不同功能的上下文需求差异巨大。我整理了一张对照表这是我实际项目里总结出来的场景类型需要的上下文典型模式原因闲聊问答最近 3-5 轮滑动窗口模式话题切换快久远历史无价值多步任务执行完整任务链全量继承模式每一步依赖前序结果知识库检索问答检索片段当前问题检索增强模式历史对话反而干扰表单填写已填字段当前字段结构化状态模式只需关键槽位不需全文代码调试助手报错信息相关代码精准注入模式无关代码是噪音你看如果只有一种全量塞入策略上面五种场景里至少三种会出问题。context-mode 的价值就在于把怎么带上下文这件事从硬编码变成可配置的策略。3. context-mode 的常见模式划分与各自的适用边界3.1 滑动窗口模式最常用但窗口大小有讲究滑动窗口是最容易实现的模式只保留最近 N 轮对话。但 N 取多少很多人是拍脑袋定的。我的经验是N 不能只看轮数要看token 预算。正确做法是设一个 token 上限比如 2000从最新一轮往前累加加到超限为止而不是固定保留 5 轮。为什么因为一轮对话的长度差异极大。用户可能发一句好的2 token也可能贴一大段代码500 token。按轮数裁剪遇到长消息就会爆预算按 token 裁剪才能稳定控制成本。实现上有个细节裁剪时不能把一轮对话从中间切断。比如用户问 助手答是一组你只保留了用户问却丢了助手答模型会困惑。所以滑动窗口的边界应该落在完整轮次上。def sliding_window_mode(messages, max_tokens2000): # messages 是 [{role:..., content:...}, ...] result [] total 0 # 从最新往前遍历成对保留 for msg in reversed(messages): msg_tokens estimate_tokens(msg[content]) if total msg_tokens max_tokens: break result.insert(0, msg) total msg_tokens return result这段代码里estimate_tokens是个估算函数实际项目里可以用 tiktoken 之类的库精确计算也可以按字符数/1.5粗略估。粗略估的好处是不引入额外依赖坏处是有误差建议留 10% 的余量。3.2 全量继承模式任务型对话的刚需有些场景就是不能裁。比如用户让助手帮我写一个脚本先读文件再过滤最后导出助手分步骤执行每一步都要知道前面做了什么。这时候裁剪历史等于让模型失忆任务直接崩。全量继承模式的关键不是全带而是带得聪明。我的做法是把历史消息做一次压缩摘要把冗长的工具调用结果、大段中间输出替换成一句话摘要只保留决策相关的信息。这样既保住了任务链的完整性又控制了 token。提示全量继承模式一定要配一个任务结束的判定条件任务完成后主动清空或归档上下文否则上下文会无限膨胀。3.3 检索增强模式让上下文按需加载这是我认为最有价值的模式。核心思路是不把历史全带上而是把历史存进一个可检索的存储向量库或关键词索引当前问题来了之后先检索出最相关的几段历史再拼进上下文。这样做的好处是上下文利用率极高——带进去的每一段都和当前问题相关。坏处是实现复杂度上去了需要维护索引、做相关性排序。适合历史很长、话题跨度大的场景比如客服系统、个人知识助手。3.4 结构化状态模式把上下文从文本变成字段表单填写、订单处理这类场景其实不需要保留对话原文只需要保留关键槽位。比如订机票你只需要记住出发地、目的地、日期、人数不需要记住用户是怎么一句句说出来的。这种模式下上下文不是消息列表而是一个 JSON 对象。每轮对话后更新这个对象下一轮把它序列化后注入 prompt。token 占用极小而且状态清晰、可校验、可持久化。{ mode: structured_state, slots: { departure: 北京, destination: 上海, date: 2024-06-01, passengers: 2 }, missing: [return_date] }模型看到这个结构就知道还缺哪个字段可以主动追问。这比让它从一堆对话里自己推断要可靠得多。4. 模式切换的触发机制什么时候该换模式4.1 基于意图识别的显式切换最直接的方式是先做一次轻量的意图分类判断当前属于哪种场景然后路由到对应的 context-mode。比如识别到帮我订票就走结构化状态模式识别到随便聊聊就走滑动窗口模式。意图分类可以用小模型也可以用规则。规则的好处是快、可控、零成本。我一般先用关键词规则兜底覆盖 80% 的常见情况剩下的用模型分类。4.2 基于上下文长度的隐式切换另一种思路是不显式判断意图而是根据当前上下文长度自动降级。比如上下文 1000 token全量继承1000 - 3000 token滑动窗口3000 token检索增强 摘要压缩这种自动挡的好处是无需额外分类逻辑坏处是可能在任务中途突然切换模式导致模型断片。所以隐式切换一定要配合模式切换时的上下文交接——切换前把关键信息提炼出来注入到新模式的上下文里。4.3 混合策略我实际项目里的做法纯显式或纯隐式都不够稳。我最后落地的是混合策略每轮对话先跑一次意图规则命中明确场景就直接切模式没命中就检查 token 预算超阈值就降级无论怎么切都保留一个核心事实区——用户明确说过的关键信息姓名、偏好、约束条件永远不裁。这个核心事实区是整个 context-mode 设计的灵魂。它相当于给上下文加了一个钉住的锚点不管模式怎么变这些信息始终在场。实现上可以是一个独立的 key-value 存储每轮对话后由模型或规则抽取更新。注意核心事实区的抽取要保守。宁可少抽不可抽错。抽错一个关键事实比如把不要辣抽成要辣比不抽的后果严重得多。5. 落地实现中的几个硬骨头5.1 token 估算不准导致预算失控前面提到用字符数估算 token实际项目里这个误差可能到 30%。中文、英文、代码、特殊符号的 token 密度完全不同。我的建议是关键路径用精确计算非关键路径用估算。比如滑动窗口的裁剪用精确计算日志统计用估算。还有一个坑不同模型的 tokenizer 不一样。你按 A 模型算的预算换到 B 模型可能就不准了。所以预算阈值要留足余量我一般按目标值的 80% 设阈值。5.2 模式切换时的上下文断层这是最容易出 bug 的地方。用户在任务执行到一半时因为 token 超限触发了模式切换结果模型忘了前面执行到哪一步开始重复劳动或者答非所问。解决办法是切换时生成一份交接摘要。摘要包含当前任务目标、已完成步骤、待完成步骤、关键约束。这份摘要作为新模式的初始上下文注入。摘要可以由模型生成也可以用模板拼接。我倾向于模板拼接因为可控、快、不额外花钱。5.3 多模式共存时的状态一致性如果一个会话里同时存在多种模式的数据比如既有消息列表又有结构化槽位要保证它们不打架。我的做法是单一数据源所有上下文都从一个统一的 ContextStore 读写模式只是决定读哪些、怎么拼不各自维护一份数据。class ContextStore: def __init__(self): self.messages [] # 原始消息 self.facts {} # 核心事实 self.slots {} # 结构化槽位 self.summary # 历史摘要 def build_context(self, mode): if mode sliding_window: return self._sliding() elif mode structured_state: return self._structured() elif mode retrieval: return self._retrieval() # ...这样切换模式时数据不用迁移只是换了个视图。状态一致性天然得到保证。5.4 检索增强模式的相关性排序检索增强模式听起来美好但检索出来的东西不相关是常态。我踩过的坑是用户问上次说的那个方案检索系统按字面匹配把一堆提到方案的历史都捞出来了真正相关的那条反而排在后面。改进方向有两个一是用向量检索替代关键词检索语义匹配更准二是加一层重排序用一个轻量模型对候选做精排。如果资源有限至少要做到最近优先——同等相关度下越近的历史权重越高。6. 实测数据与效果对比光说设计不够得看数据。我在一个中等规模的对话应用上做了 A/B 测试对比无模式管理全量塞入和context-mode 管理两种方案跑了大约两周样本量 5 万轮对话。结果如下指标无模式管理context-mode变化平均输入 token/轮42001350下降 68%平均响应延迟3.2s1.8s下降 44%任务完成率71%83%提升 12 个百分点用户追问率24%15%下降 9 个百分点单轮成本基准约 0.35 倍下降 65%任务完成率提升这点最让我意外。原本以为裁剪上下文会损失信息、降低效果结果反而提升了。原因就是前面说的注意力涣散——上下文短了、精了模型反而更聚焦。不过也有代价实现复杂度上去了代码量大概是原来的 2.5 倍而且需要维护检索索引和摘要逻辑。所以我的建议是日活低于 500 的应用先用滑动窗口模式就够了别一上来就上全套。等成本或效果真的成为瓶颈再逐步加模式。7. 几个我踩过的坑和对应的解法7.1 摘要越滚越大最后比原文还长做全量继承模式时我让模型每轮生成摘要结果摘要本身也在累积几轮之后摘要比原始对话还长。解法是摘要也要有预算超过阈值就做摘要的摘要或者只保留最近 N 条摘要 一份全局摘要。7.2 核心事实区被误更新有一次用户说我改主意了不要辣抽取逻辑把不要辣更新进了事实区但没删掉之前的要辣结果两个矛盾的事实同时存在模型无所适从。解法是事实区要支持覆盖和删除同一类事实只保留最新值并且抽取时带上这是修改的标记。7.3 模式切换过于频繁隐式切换如果阈值设得太敏感会导致模式来回横跳每轮都在切换反而增加开销。解法是加一个滞回区间比如超过 3000 token 才切到检索模式但要降到 2000 token 以下才切回来。中间这段保持当前模式不变。7.4 检索模式下的空检索用户问了一个和历史完全无关的新问题检索系统返回空结果这时候如果还硬走检索模式上下文里就只有当前问题模型会显得失忆。解法是检索为空时自动降级到滑动窗口模式至少带上最近几轮。8. 给不同阶段开发者的落地建议如果你是刚起步我的建议是先实现滑动窗口 核心事实区这两个。这两个加起来不到 200 行代码就能解决 80% 的成本和效果问题。核心事实区用简单的规则抽取即可比如正则匹配我叫XX我要XX这类句式。如果你已经在做任务型 Agent那全量继承 交接摘要是必须的。重点是把摘要模板设计好让模型在模式切换时能无缝衔接。如果你面对的是长历史、多话题的场景比如个人助手、客服那检索增强模式值得投入。但一定要配重排序否则检索质量上不去反而添乱。最后说一个我个人的体会context-mode 这套东西难的不是模式本身而是模式之间的边界和切换。模式划分谁都能想出来但切换时机、切换时的信息交接、切换后的状态一致性才是真正决定成败的地方。我见过太多项目把模式做得很花哨结果切换时丢信息效果还不如老老实实全量塞入。所以我的原则一直是模式可以少但每个模式的边界必须清晰切换必须无损。这套思路我用了大概一年多从最初的滑动窗口一路迭代到现在的混合模式中间推翻重来过两次。现在回头看最大的收获不是省了多少 token而是对上下文到底是什么有了更清楚的认识——它不是一堆要传的文本而是系统对当前任务状态的一种表达。想清楚这一点模式怎么设计自然就有答案了。
 时间复杂度的工程实现)
