1. context-mode为什么需要给大模型对话加一个“上下文模式”最近手头一直在做一个大模型对话类应用的迭代其中一个让我纠结最久、改动次数最多的模块就是这个名为 context-mode 的上下文管理功能。简单说它解决的是大模型对话中一个特别基础、但特别容易被忽视的问题每一次请求该把哪些历史对话发给模型发多少以什么形式发。有过实际开发经验的朋友应该能秒懂我在说什么。现在的大模型上下文窗口虽然越做越大从早期的 4K、8K 一路卷到 128K、200K甚至百万级。但窗口大不代表你可以无脑往里面塞东西。Token 就是钱每轮对话都全量携带历史延迟和成本会一起失控。而且模型对超长上下文的注意力分布并不均匀塞得太多太杂反而会导致关键信息被淹没回答质量直线下降。context-mode 这个项目要做的就是给对话系统设计一套可配置、可切换的上下文管理机制让它能根据不同的使用场景和用户需求自动选择最合适的上下文构建策略。这篇文章我想把整个设计和实现过程完整拆开聊包括模式划分的思路、每个模式下具体的上下文构建策略、Token 成本核算、路由切换逻辑以及我在实际开发和压测中踩过的一堆坑。无论你是在做大模型应用开发、对话系统架构设计还是单纯对上下文工程Context Engineering感兴趣这篇文章应该都能给你一些可以直接落地的参考。2. 上下文模式的整体设计与模式划分思路2.1 先搞清楚上下文管理到底在管什么设计 context-mode 之前我先把问题拆解了一遍。一个对话系统的上下文管理实际上要处理三件事。第一是历史消息的筛选与组织。用户和 AI 聊了 100 轮哪些轮次需要保留哪些可以丢弃哪些需要压缩后再保留这是最核心的问题。第二是窗口资源的分配与预算。模型的上下文窗口是有限的不能一直往里面堆。每一轮请求都需要规划用户当前输入占多少 Token、回复预留多少 Token、历史消息最多能占多少 Token。第三是信息形态的转换与重构。原始对话历史太长直接塞进窗口会超出预算这时候就需要用摘要、结构化标签、关键信息抽取等方式把“原始对话”转换成更紧凑的“上下文表示”。在最初的原型版本里我其实没考虑这么细。当时的做法很粗暴维护一个 Python 列表存最近的 20 轮对话每次请求全部拼接进 Prompt。用起来倒是简单但到了 30 轮、40 轮对话之后问题就暴露了——Token 消耗越来越大响应越来越慢而且模型开始“忘记”早先对话里的关键约束比如用户在第一轮说过“不要用太正式的语气”聊到后面模型明显把这个要求给丢了。所以当我决定正式把 context-mode 做成一个独立模块时心里最明确的一个目标就是不再用一刀切的策略应对所有场景。2.2 三档模式划分compact / balanced / deep借鉴了我在多个项目里的一些实践最终把模式定为三档compact、balanced、deep。这个划分思路的核心依据是对话场景对历史信息密度的不同需求而不是简单地按对话轮数一刀切。compact紧凑模式适合轻量问答、工具调用、意图识别这类短平快场景。对话历史上限 6 轮超出的部分直接裁掉不做摘要。核心逻辑是“快”和“省”宁可牺牲一点对早期语境的记忆也要保证响应速度和 Token 成本可控。balanced平衡模式适合大多数常规聊天场景。对话历史上限 20 轮超过上限的最早 10 轮会触发一次轻量摘要用摘要信息替换原始内容新的对话继续累积。这个模式在上下文“保鲜度”和 Token 消耗之间做了折中。deep深度模式适合长文分析、复杂逻辑推理、创意写作这类需要完整理解上下文的场景。对话历史上限 80 轮超过上限后才会触发分层摘要底层做分段摘要顶层做全局摘要同时保留关键用户指令和关键事实标签。这三档模式在同一个系统里可以独立配置也支持根据对话类型、用户标签、接入渠道等因素做自动路由。2.3 为什么设计成三档而不是自适应单档有些朋友可能会问为什么不直接做一个全自动的智能模式让系统自己判断该给多少上下文我也考虑过这个方案调研了一圈市面上已有的做法包括用内容向量化之后做相似度召回、给每条消息打重要性分数、甚至用一个小模型预测上下文窗口的合适大小。但最终放弃“全自动单档”路线原因有三点。第一自动策略的可解释性太差。用户遇到回答质量下降的时候如果是手动模式你能清晰地告诉他“因为当前处于 compact 模式早期对话被裁剪了所以模型不记得第一轮的关键要求”。但如果是全自动的你很难给用户一个准确的解释排查问题的时候也无从下手。第二不同场景对实时性的要求差距悬殊。用户用对话系统查个天气、算个加减法你给他塞 50 轮历史进去完全是浪费。但用户丢给你一份一万字的合同让你分析你却只给他保留最近 10 轮对话他肯定会觉得 AI 是鱼的记忆。这种差异是场景层面就决定了的靠模型事后推断不如靠策略事先约定。第三自动判断本身有额外开销。你需要先分析当前对话的内容和意图这个分析过程本身就要消耗 Token 和延迟。如果整个请求平均只要 800ms你光判断模式就花了 300ms这是不划算的。当然三种模式的分界值并不是拍脑袋定的具体数值是从日志统计和实测压测里反推出来的。关于这些数值怎么定的我在下一节详细拆解。3. 核心细节解析上下文构建策略与关键参数设计3.1 两种基础技术滑窗裁剪与摘要压缩context-mode 的底层实现主要依赖两种技术滑窗裁剪Sliding Window Truncation和摘要压缩Summarization Compression。滑窗裁剪非常好理解就是只保留最近的 N 轮对话超出部分直接丢弃。实现起来最简单成本最低但缺点是会硬生生切掉早期信息。如果用户在非常早的时候给过一个关键指令比如“请用中文回答”而这个指令随着滑窗被裁掉了模型后续就可能会切换语言造成很差的体验。摘要压缩则是另一条路用一次独立的 LLM 调用把超出窗口上限的早期对话“提炼”成几百字的摘要然后用摘要替换原始内容。比如用户聊了 60 轮前 40 轮内容经过摘要压缩成一段 200 字的梗概后 20 轮作为原始消息保留。这样既不超预算又保留了历史的关键信息。我在实际开发中这两个技术不是二选一而是组合使用的。不同的 context-mode组合的方式和阈值不一样模式窗口上限触发策略摘要频率典型延迟增量compact6 轮超限直接裁剪不摘要接近 0balanced20 轮超限时最早 10 轮摘要每超 10 轮一次200ms 左右deep80 轮超限时做分层摘要每超 20 轮一次500ms 左右这个设计的核心逻辑是让会话早期的重要信息以“摘要”的形态继续存活而不是被直接删除。关于真正的滑动窗口实现其实还有一个比较经典的细节是每次请求并不是只保留 N 轮而是每轮对话都会拆成 user 消息和 assistant 消息两条在构建上下文时要按交错顺序排列。最容易写的 bug 就是把 user 消息全排前面、assistant 消息全排后面模型读到的是“所有用户提问在一起、然后是回答”这种顺序在 Transformer 自注意力机制下会严重破坏对话语义结构。3.2 摘要压缩的两种层粒度在 deep 模式中我采用了分层摘要Hierarchical Summarization。这里有个很关键的细节摘要不能只做一个全局摘要要分两层。原因是当对话轮数特别多时单一摘要的压缩比会过高早期信息在压缩过程中会严重失真的。分层摘要是这么做的底层先把 80 轮对话分割成若干段每段 10 轮左右对每段各做一次摘要得到若干个“分段摘要”。顶层再把这些分段摘要拼起来做一次全局概要。这样做的好处是每层摘要的压缩比控制在约 5:1 到 8:1 之间比一次性把 4000 Token 压到 200 Token 的 20:1 压缩比要稳得多。实测下来信息丢失率明显更低。这个过程中还要注意摘要模型的输出要规范我一般会在 prompt 里要求使用固定格式的 Markdown 列表每行一条摘要前缀标注时间段或者主题标签例如- [1-5轮] 用户咨询了价格方案重点关注企业版的按量计费模式。 - [6-10轮] 用户提出希望增加权限管理功能当前方案已给出初步设计。这种格式化输出对上层重新组织上下文非常有用直接按段落拼接进去就行不需要再做二次解析。3.3 Token 预算的计算方法Token 预算是 context-mode 里最容易被忽略、却最影响效果的部分。我在设计时参考了比较通用的估算方式并结合实测做了修正。先说通行的估算公式。通常我们按“1 个汉字 ≈ 1.5~2 个 Token”来估算英文按“1 个单词 ≈ 1.3 个 Token”来估算。这只是粗估实际要准确的话最好用模型配套的分词器Tokenizer离线数一遍。我在服务启动时会预先加载 tokenizer请求到达时先用encode方法计算用户输入的 token 数再按照当前模式的配置计算剩余可用 token决定历史消息的保留量。在计算预算时我会把上下文窗口拆分为三块总窗口预算 用户输入 Tokens 历史上下文 Tokens 输出预留 Tokens以 balanced 模式、window 8K 为例用户输入假设当前对话有 200 Tokens先减去输出预留固定预留 1024 Tokens历史上下文剩余预算 8192 - 200 - 1024 6968 Tokens然后从最近的对话开始往前倒推把每轮的消息累加进去一直加到累计超过 6968 Tokens 为止。超出部分改为做摘要压缩而不是硬塞。这一步很关键很多人做上下文管理时只数轮数不数 Token 数。但不同消息的长度差异非常大用户可能某轮粘了一大段代码直接吃掉几千 Token轮数阈值根本控制不住成本。所以 context-mode 里轮数只是一个粗筛条件Token 预算才是硬约束。3.4 模式切换的自动路由逻辑模式除了手动指定我还设计了一个很轻量的自动路由逻辑。这个路由不是靠大模型判断而是用规则完成的成本可以忽略不计。路由规则有四个判断维度单条消息长度超过 3000 Tokens大概率是长文分析场景直接走 deep消息类型标识客户端显式携带的意图标签例如 choose_plan、invoice_check 这类工具类意图走 compactessay_write、contract_review 走 deep历史对话轮数超过 8 轮还在持续对话自动从 compact 升级到 balanced当前模式反馈如果模型连续出现两次低置信度响应由置信度评分模块判断自动降级到低一级模式清理上下文噪音这种基于规则的路由方式好处是稳定、可控、没有额外延迟。在我个人的实践里处理上下文模式这类基础架构问题宁可用简单规则也不要一上来就引入复杂的模型判断性价比完全不是一个量级。4. 实操过程从原型到可上线实现的完整拆解4.1 服务端功能模块划分在正式写代码之前我先确定了一个前端界面配合的模块结构。context-mode 不是一个单一函数而是由四个子模块组成的mode_config.py模式定义和参数配置管理三档模式的所有阈值history_store.py对话历史存储与读取负责维护原始消息队列和索引context_builder.py上下文构建器根据模式配置读取历史、执行裁剪或摘要、组装 Promptsummarizer.py摘要服务封装对摘要模型的调用支持单段摘要和分层摘要在最早期版本里这四个功能是散落在不同主流程里的代码非常难维护。后来我花了一个周末把相关逻辑统一收敛到这四个模块中依赖关系一下清晰了很多。如果你也在做类似功能建议第一时间就把模块边界切好避免后续改动牵一发动全身。4.2 关键实现context_builder 的组装逻辑context_builder 是整个模块的核心它的组装流程是这样的第一步从 history_store 中取出当前会话的完整历史消息列表messages每一条都带 role、content、timestamp 字段。第二步根据当前模式 mode 读取对应配置。第三步从最新消息开始倒序遍历历史累加 token 数直到达到 Token 预算上限。第四步判断被“挤出去”的早期消息是否需要摘要。第五步把摘要结果放在系统指令之后、原始消息之前组成最终的上下文。用伪代码描述大致是这样def build_context(mode, current_input, history_messages): # 读取模式配置 cfg MODE_CONFIG[mode] # 计算 token 预算 input_tokens count_tokens(current_input) history_budget cfg.max_window_tokens - input_tokens - cfg.reserved_output_tokens # 从最新消息倒序筛选 keep_history [] truncated_messages [] budget_used 0 for msg in reversed(history_messages): msg_tokens count_tokens(msg.content) if budget_used msg_tokens history_budget: keep_history.append(msg) budget_used msg_tokens else: truncated_messages.append(msg) keep_history.reverse() truncated_messages.reverse() # 对挤出去的消息做摘要 summary if truncated_messages: if mode balanced: summary summarize_once(truncated_messages) elif mode deep: summary hierarchical_summarize(truncated_messages) # 组装最终上下文 return assemble_prompt(summary, keep_history, current_input)这里有一个我特别想强调的细节摘要触发不应发生在每一轮请求里而应该在历史即将超出阈值时才触发一次并对摘要结果做缓存。如果每轮对话都重新摘要一遍浪费的 Token 会非常可观。我在实现中加入了一个 deduplication 机制摘要的输入是一批消息的 hash 值如果 hash 没变就直接从缓存读取摘要结果不再调用摘要模型。4.3 前端展示让用户看得见上下文的状态设计 context-mode 的时候我加上了一个前端联动的功能对话界面增加了一个上下文状态指示器显示当前处于哪个模式以及本次请求使用了多少 Token、保留了多少轮历史消息。为什么需要这个因为在使用过程中用户最常见的困惑是“AI 怎么忘了我说过的话”。有了模式标识和 token 消耗展示用户至少能理解当前处于 compact 模式历史保留有限所以 AI 对早期内容记忆模糊是预期行为而不是系统 bug。展示形式很轻一个小角标形如“context: balanced (18轮 / 4.2K tokens)”。用户点击后能看到模式的简单说明和当前会话的关键参数。这个设计上线后收到的正面反馈超出预期很多用户说自己更愿意信任这种“把决策过程透明化”的产品。4.4 缓存策略上下文重建不等于每次都全量重算在实际高并发场景里有一个必须处理的性能问题如果每个请求都需要重新读取 80 轮对话历史、重新做 token 统计、重新构造上下文那么一个高频会话会白白消耗大量 CPU 和 IO。context-mode 的解决方案是引入“对话状态快照”机制。每当一次上下文构建完成之后把构建结果连同对应的版本号一起缓存起来。当新的用户消息到达时对比版本号如果历史没有变化就直接从上一次的上下文基础上增量追加不需要重新构造全部内容。这个优化把单个请求的上下文构建耗时从平均 150ms 降到了 20ms 左右。对于那种连续多轮快速问答的会话场景收益非常明显。4.5 监控与日志每个模式的表现都要有数据支撑最后不管功能设计得多好没有监控数据佐证就是裸奔。我在 context-mode 里打了一套完整的日志体系每个请求都会记录以下关键指标当前模式、总 Token 数、上下文裁剪比例、摘要耗时、摘要 Token 消耗、模型响应延迟、用户反馈评分如果有一个专门的 dashboard 展示三档模式的使用分布和平均响应延迟这些数据非常有用。我在初期上线时发现balanced 模式的平均响应延迟比 compact 高了 30%但用户满意度评分却几乎没有差异。这说明有相当大比例的用户对话并不需要那么长的历史上下文我随后直接把一部分流量从 balanced 切到了 compact整体资源消耗降了一截而用户体验没有明显下降。5. 常见问题与排查技巧实录5.1 问题速查表我在开发和使用 context-mode 的过程中踩了不少坑。这里整理成一张速查表方便大家对照排查。现象可能原因排查与解决方式模型“忘记”早期用户指令滑窗裁剪过早丢弃关键指令消息检查模式配置的轮数上限开启摘要保留关键指令或对含指令的轮次设置免裁剪标记Token 消耗异常偏高未按 token 预算裁剪只按轮数裁剪用 tokenizer 统计实际 token 数检查是否有超长消息未单独处理摘要内容失真、丢失关键约定单次摘要压缩比过大改用分层摘要控制每段摘要的输入规模避免一次压缩过多摘要调用频繁拖慢响应每轮请求都触发摘要增加摘要缓存用消息 hash 做去重上下文顺序错乱模型回答前言不搭后语消息组装时 user/assistant 顺序颠倒检查组装逻辑确保按时间轴交错排列compact 模式下回答质量波动大阈值太小导致关键信息被过早截断结合日志统计每轮对话的 token 分布反过来调整阈值高并发下上下文构建成为瓶颈每次请求全量重建上下文引入增量缓存机制如我上面提到的版本快照方式5.2 排查日志的经典案例举一个我实际排查过的问题。上线的第二天有用户反馈说 deep 模式下模型忘记了他一开始要求的“输出格式用表格”。我第一反应是摘要出了问题。拉出日志一看果然在对话进行到第 40 轮时第 1 轮“请用表格输出”的原始消息被裁掉了系统生成的分层摘要里也没有记下这个要求。原因是摘要模型的 prompt 里没有强调“保留用户对输出格式的指令”结果摘要就忽略了它。修复方式是在摘要 prompt 里专门加了一段请特别注意原始对话中用户对以下内容的指令 - 输出格式要求表格、列表、代码块、语气等 - 角色设定要求 - 禁止事项 上述内容必须原样保留在摘要中。加了这一条之后这个案例的复现率基本降到 0。这个问题的价值在于它说明了一个道理摘要策略不仅要考虑压缩内容也要考虑“保什么”。关键指令需要设置较高的保真级别不能和普通寒暄内容混在一起被同等对待。5.3 上下文模式的扩展思路我的下一步方向当前 context-mode 的三种模式已经跑了大半年稳定性没问题。但围绕这个机制有几个方向我打算后续继续做。一个方向是“用户级自适应模式”。现在模式的粒度是会话级的同一个用户的所有对话都独立判断。未来可以通过分析某个用户的历史使用习惯预设他更常用的模式偏好形成个人默认配置。比如有些人就问简单问题长期活跃在 compact 模式就不必每次都经过自动路由逻辑了。另一个方向是“多模态消息的上下文处理”。现在的大模型对话已经不只是文本了很多系统里已经可以传图片、语音文件。这些媒体消息在上下文里的权重和截断策略又不一样。二进制内容不能直接塞 prompt需要的是提取视觉描述或者转写文字。未来 context-mode 需要把多模态消息纳入统一管理。最后我还想试试“模式自动微调”。基于实时反馈数据让系统在运行过程中能够动态调整各模式的阈值参数。比如发现 deep 模式下 80 轮上限经常触发摘要而摘要压缩比偏高导致信息有损可以自动把上限微调到 90 轮或者优化摘要触发点。这个方向对系统稳定性要求较高需要在灰度评估上做一些设计。6. 最后分享一条真实的经验如果要我给正在做类似功能的人一条建议大概会是这样不要迷信各种花哨的上下文压缩算法先把你对话数据的轮次分布和 Token 分布统计出来用数据定阈值。我最初设计的 deep 模式上限是 50 轮后来拉了一周生产环境的日志发现真正超过 50 轮的会话只占不到 3%而超过 20 轮的会话大概占 15%。于是我把 deep 的上限调到了 80 轮balanced 的触发阈值调得更灵敏——这样改完之后deep 模式下摘要触发频率下降了 40%而用户感知到的“AI 记忆力”反而更强了。阈值不是拍脑袋出来的是从真实的使用模式里长出来的。context-mode 这个项目做到现在我自己最大的感受是上下文管理没有一套放之四海而皆准的方案关键是在特定的业务场景里找到那个性价比最高的平衡点。你要对模型的窗口限制心里有数对用户的对话习惯有数对自己的成本预算有数然后在这几个约束之间做一个尽量优雅的取舍。希望这篇文章能帮你在自己的项目里少踩几个坑。