1. 项目起点为什么需要 context-mode做 AI 应用开发的朋友应该都有这个体会模型能力再强上下文窗口一满对话质量立刻断崖式下跌。我今年主要精力放在一个客服机器人项目上跑了几个月之后发现一个很尴尬的问题——用户问得越深入、历史对话越长模型的回答就越“失忆”。前几轮说好的价格、规则、订单号后几轮就开始编。后来我把这个问题抽象出来本质上就是缺一个能统一管理的“上下文模式”也就是标题里说的 context-mode。简单说context-mode 是一套上下文管理模式它解决三个核心问题上下文窗口被无关内容撑爆、重要信息被淹没、长对话下记忆衰减。它不做模型训练不做微调只做一件事——在每一轮请求发起之前决定“当前这轮对话模型应该看到哪些信息”。这篇文章面向两类读者一类是正在做对话式 AI 产品、被长上下文折磨的开发者另一类是刚接触 LLM 应用、想理解工程上怎么管理上下文的同学。我会把设计思路、核心实现、参数调优和踩坑实录都摊开来讲所有方案都是我实际跑过、验证过的不是那种只讲概念的文章。2. 整体设计上下文管理的三种主流方案2.1 方案对比滑动窗口、全文摘要、检索增强在动手写代码之前我先把市面常见的上下文管理方案走了一遍最后收敛成三条路线。第一种是滑动窗口Sliding Window思路最简单只保留最近 N 轮对话老消息直接丢。优点是无状态、开销小、实现快缺点是丢信息太粗暴早上聊的订单编号下午就没了。第二种是全文摘要Global Summary每轮结束后把历史压缩成摘要保留全局信息。优点是信息密度高缺点是摘要过程本身会丢细节用户报出的手机号、地址这类精确信息经不起二次压缩。第三种是检索增强RAG-Based Retrieval把所有历史消息切片向量化每次根据当前问题去检索相关片段。优点是精准缺点是要维护向量库延迟和成本都会增加。这三种方案不是互斥的真实场景里往往是组合使用。我的做法是“分层路由”系统指令和核心用户档案永久保留最近几轮完整保留更早的历史走摘要需要精确细节时再走检索。这个设计思路我后面展开讲。2.2 为什么我放弃“全量硬塞”有过一个很自然的偷懒方案反正现在模型上下文窗口大了把历史全塞进去不就完了我一开始也这么干过实测下来三个问题把我劝退了。第一是成本问题。上下文按 token 计费全量塞入意味着每一轮都要为历史买单。客服场景平均会话 30 轮全量塞入大约是只保留核心信息的 6 倍成本一个月下来是笔不小的开销。第二是注意力稀释。模型对超长上下文的注意力是有限的塞进去 5 万 token 和 8 万 token不是效果等比例提升而是等比例下降。长文本中间区域经常被模型“选择性忽略”业内叫 lost in the middle。第三是延迟恶化。上下文越长首 token 延迟越明显交互体验很快变差。所以我最后的结论是上下文管理的目标不是“塞得下”而是“放得精”。每一次请求都给模型提供最有效的一条信息组合这才是 context-mode 的核心价值。2.3 分层路由架构的确定经过几轮折腾我把架构稳定成了四层常驻层、会话层、摘要层、检索层。常驻层放的是永远不该丢的东西系统提示词、用户档案、业务规则。会话层是最近几轮完整对话保证当前话题的连贯性。摘要层是更早历史的压缩版本让模型对来龙去脉有基本感知。检索层是一个可选增强当摘要里找不到精确细节时才从向量库里捞原文。这个架构最大的好处是每一层职责单一出了问题能快速定位。常驻层太长就压缩提示词会话层太长就调窗口值摘要层丢信息就优化摘要策略互不干扰。如果你也要做 context-mode我建议先按这个四层结构搭骨架别上来就搞复杂的动态方案。3. 核心实现从零搭建 context-mode 的完整步骤3.1 消息结构设计与数据存储动手第一步先把消息数据结构定清楚。我建议不要直接用字符串拼接历史而是用结构化的消息列表每条消息带元信息。from dataclasses import dataclass, field from datetime import datetime from typing import Optional dataclass class Message: role: str # system / user / assistant / tool content: str # 消息正文 msg_id: str # 全局唯一ID timestamp: datetime # 消息时间 category: str # 普通 / 关键信息 / 工具结果 importance: float 0.5 # 0~1 重要度评分 summary: Optional[str] None # 该消息的摘要缓存这个结构里 category 和 importance 是我后期加的。一开始只有 role 和 content后来发现消息的价值差异太大了——用户随口说的“好的”和报出的手机号在上下文里不应该享受同样的待遇。有了这两个字段后面做裁剪和排序才有依据。存储上我用 Redis 存会话状态TTL 设为 7 天每个会话的完整消息列表持久化到 MongoDB。Redis 里只存“当前活跃上下文”的组装结果这样每次请求不用重新组装直接从缓存拿延迟能省下 30% 左右。3.2 核心管线组装上下文的五步流程上下文组装不是简单拼接我整理成五个步骤每一轮请求都会走一遍。第一步拉取当前会话的完整消息列表。第二步计算 token 预算确定这次请求最多可以用多少 token。第三步按优先级排序把消息分到四层。第四步逐层填充先塞常驻层再塞会话层剩余空间给摘要层最后从检索层补充。第五步拼接成最终的 messages 列表发给模型。这里最关键的逻辑在第四步我写了一个简化版函数来演示填充逻辑def assemble_context(session_id: str, token_budget: int, current_query: str): # 1. 获取完整历史 messages load_messages(session_id) # 2. 分配各层预算 budget_layer { resident: int(token_budget * 0.25), # 常驻层 25% recent: int(token_budget * 0.30), # 会话层 30% summary: int(token_budget * 0.30), # 摘要层 30% retrieval: int(token_budget * 0.15) # 检索层 15% } # 3. 常驻层系统提示 用户档案永不裁剪 final_messages load_resident_messages() used count_tokens(final_messages) # 4. 会话层最近 N 轮超出部分交给摘要层 recent [m for m in messages if m.category ! system] recent recent[-8:] # 最近 8 条完整保留 recent trim_to_budget(recent, budget_layer[recent]) final_messages.extend(recent) used count_tokens(recent) # 5. 摘要层早期消息生成或复用摘要 older messages[:-8] if older: summary_text get_or_create_summary(older) summary_msg {role: system, content: f以下是更早对话的摘要\n{summary_text}} if used count_tokens([summary_msg]) token_budget: final_messages.append(summary_msg) # 6. 检索层针对当前问题补充精确信息 retrieved retrieve_related(older, current_query, max_tokensbudget_layer[retrieval]) final_messages.extend(retrieved) return final_messages注意这个填充顺序是刻意的常驻层永远优先因为它丢了系统就崩会话层其次保证连续性摘要和检索属于补充空间不够就先牺牲。预算分配比例我用的是 25/30/30/15具体值不是拍脑袋定的后面参数调优部分细说。3.3 摘要生成策略轮转摘要与深链摘要摘要层是整个 context-mode 里最容易翻车的部分。一开始我用最简单的做法每满 20 轮就把前 10 轮扔给模型生成一段摘要替换掉原文。试了一个月发现信息丢失很严重具体表现是用户中途改过口径的规则被保留成旧版本精确数字被“一些”“大概”替代。后来我改成双层摘要轮转摘要负责粗粒度概括深链摘要负责保留精确信息。轮转摘要是每轮增量更新的新来的消息加入旧摘要后重新生成一段压缩文本深链摘要是对每条高 importance 消息单独做一个短摘要并且把原文全文存到向量库检索层可以随时捞出来。这里有一个很关键的技巧摘要生成的 prompt 里必须明确要求“保留所有数字、日期、专有名词”并且“不要评价不要推理只做事实压缩”。不加这两句模型会自由发挥摘要里出现幻觉内容后续对话全部被污染。3.4 检索层的轻量实现很多文章一说到检索就上全套 RAG 基础设施实际上如果历史消息量不大完全可以用更轻的方案。我初期把每一条高价值历史消息用 embedding 模型离线向量化存到一个独立的集合里检索的时候用当前 query 做向量搜索取 top 3 条按时间顺序插回上下文。后来会话量上来之后我在向量检索前面加了一道关键词预筛用 BM25 先粗筛一遍再用向量精排召回率提升了一些。这个方案的好处是可以不用外部向量数据库直接用内存索引或者轻量的向量存储就能跑部署成本很低。有一点要提醒检索层是把双刃剑。检索到的历史消息如果跟当前问题相关性判断错误会把错误信息带进上下文反而误导模型。所以检索结果进来之后我加了一个置信度阈值相似度低于 0.75 的一律不采用。宁可检索不到也不要检索错。4. 参数调优怎么把上下文利用率拉满4.1 Token 预算的计算方法token 预算不能拍脑袋设死得根据模型上下文窗口和执行任务动态算。我的公式是这样的token_budget min(窗口上限 * 0.85 - 预留输出空间, 业务安全值)窗口上限是模型本身的上下文长度0.85 是给系统预留的缓冲防止极端情况溢出。预留输出空间很关键——你要给模型的回答留出空间一般至少留 1/4 的窗口给模型生成。如果输入把窗口占满了模型连回答的空间都没有直接报错或者输出截断。业务安全值是从成本角度设的红线比如客服场景我设成 12k token超过这个值宁可裁剪历史也不硬撑。因为它直接关联到每次请求的费用这个值最好按月成本反推先算平均每天请求量再倒推单次可以接受的 token 上限。4.2 会话窗口长度与信息重要度评分会话层的窗口长度和重要度评分是两个需要配合调优的参数。窗口太短当前话题稍一拐弯就断层窗口太长成本上去了但收益不线性。我的经验窗口长度的下限是“能覆盖一个完整子话题”。客服场景里一个用户从问价到确认下单大概 5 到 8 轮所以我最初设 6 轮实测不够经常出现用户在第十轮问“那刚才说的赠品还有吗”模型已经不记得最后定在 8 轮。重要度评分我给每条消息打一个 0 到 1 的分值规则很朴素但有奇效包含手机号、订单号、地址、金额的消息直接给 0.9用户明确表达意图的消息给 0.7寒暄、确认类消息给 0.3系统提示和工具结果按实际价值给 0.4 到 0.8。实现上用关键词命中加长度判断就够不需要上大模型打分成本扛不住。4.3 自适应调节与效果评估固定参数永远不够用。我最后加了一层自适应调节根据上一轮对话的“困惑度变化”来调整窗口长度。具体做法是记录每次请求后模型的困惑度分数如果连续三轮困惑度上升说明上下文的信息不够支撑回答自动把会话层窗口扩大两轮如果困惑度持续稳定说明当前信息充足逐步缩回来省成本。效果评估我用的是固定的回归测试集收集 200 个真实客服对话样本标注标准答案每次改动参数跑一遍测试集看准确率变化。这个测试集非常关键没有它调参就是在盲调。我吃了很多亏——凭感觉调了一天参数上线后被用户一句话打回原形就是因为没有先跑回归测试。5. 实战中的坑与排查实录5.1 上下文污染摘要把错误信息带进了后续对话这是我在 context-mode 迭代中遇到的最严重的问题。现象是某用户在第二轮说过“我要 A 套餐”第五轮改口“算了换 B 套餐”但到第十五轮模型还在推荐 A 套餐。查下来发现是摘要层把第二轮的信息固化了——轮转摘要里写着“用户选择 A 套餐”后续所有请求都带上这句摘要模型自然被带偏了。处理办法有两个层面。第一在摘要 prompt 里强行加规则如果同一实体对象的信息有冲突在摘要里同时保留最新版本和冲突标记比如“用户最初选 A 套餐后改为 B 套餐以最新为准”。第二增加消息的 mutation 追踪对同一订单号、同一产品 ID 的多条消息只保留最后一条状态为有效旧状态只在需要核对时通过检索层取原文。这个坑让我意识到上下文管理不是“存什么”的问题更是“信什么”的问题。5.2 摘要丢失精确信息手机号变成“一个号码”第二轮迭代时测试集里的电话号码召回率掉了一大截。原因很直接模型在做摘要压缩时会把“138xxxx8808”这种数字串改写成“用户留了手机号”因为它觉得这样更“通顺”。这在摘要生成里是模型的天然倾向很难靠 prompt 根除。我用的解决方案是把精确信息从摘要候选里提前摘出来单独放一层“关键实体库”。具体实现是用正则和简单的 NER 把手机号、订单号、金额、日期提取出来存成结构化字段跟随常驻层一起注入上下文。摘要层只处理语义信息不再承担精确信息保存的职责。这样改动后电话号码召回率从 68% 提升到了 94%效果非常明显。5.3 长会话性能衰退与检索误召回还有一个低频但致命的问题会话超过 80 轮后模型回答质量会整体下滑即使上下文组装逻辑看起来都正常。排查后发现不是单次请求的问题而是摘要层层层叠加导致的“摘要漂移”——早期信息经过多次摘要每次丢失一点细节十几次之后核心事实已经被扭曲得面目全非。我的解决方案是限制摘要嵌套深度最多做三层摘要超过三层后直接归档不再参与上下文组装改为只走检索层捞原文。也就是明确给摘要设置一个保鲜期过期信息不靠摘要续命靠原文检索。这个思路也在帮我控制成本因为摘要每次生成也要花 token。检索误召回的坑前面提过这里再补充一个真实案例用户问“退款什么时候到账”向量检索把“退款”这个关键词权重拉高召回了另一条“退款失败”的历史结果模型一本正经地告诉用户“退款失败了”实际那条消息根本不是这个订单的。加了实体过滤之后召回时会先校验订单号或者会话 ID 是否匹配不匹配的直接丢弃这个问题基本绝迹。5.4 排查工具集日志、可视化与回放做 context-mode 这类系统最怕黑盒。我建议从一开始就把上下文组装过程完整记录下来否则出了问题根本无从下手。我在项目里加了一个 debug 模式每次请求会在日志里输出所有注入消息的前 100 个字符和 token 数用不同前缀标记层级。排查长对话问题的时候光看日志不够我写了一个简单的回放工具把一个完整会话的所有轮次按时间顺序渲染出来标注出每一轮的上下文组成和模型输出。这样就能直观看到“上下文某条消息是什么时候丢失的”“模型是在哪一轮开始被错误摘要带偏的”。这些工具都不复杂加起来不到 500 行代码但调试效率提升是十倍级别的。6. context-mode 的扩展方向与个人经验6.1 从客服场景扩展到通用 agent我最初把 context-mode 定位成客服专用后来发现核心逻辑完全可以通用化。只要是长任务、多轮交互的 agent 场景都需要回答“模型到底该看什么”。我现在把核心模块抽成了一个独立的服务输入是消息流和业务配置输出是组装好的上下文。接入新场景时只需要换掉常驻层的内容和重要度评分规则四层架构不用动。一个让我印象深刻的例子是代码生成 agent。它的常驻层是项目代码库的索引摘要会话层是最近几个文件的修改记录摘要层是历史任务的执行概述检索层是具体函数签名和调用关系的向量库。结构和客服场景一模一样只是换了内容类型。6.2 上下文成本意识的培养做这个项目的最大收获其实是建立起了“上下文成本意识”。很多开发者习惯性忽视上下文消耗觉得模型便宜、窗口大无所谓。实际上一旦产品进入规模化上下文 token 是最大的隐形成本。context-mode 的核心价值之一就是用工程手段把每一分 token 花在刀刃上。我养成的一个习惯是每一条注入上下文的消息都问自己三个问题——它对当前这轮回答有没有贡献有没有更省 token 的表达方式如果去掉它会怎样这套思考方式比任何现成方案都重要。6.3 最后分享两个落地技巧一个是渐进式上线。context-mode 这种改动牵一发动全身不要一次性全量替换旧逻辑。我先用了两周灰度把新逻辑只应用到 10% 的会话量和旧逻辑并行跑对比回答质量指标。确认稳定后再逐步放量报错率明显可控。另一个是兜底开关。我在系统里加了一个紧急开关一旦发现组装后的上下文异常比如 token 超限、摘要为空自动降级为只发送最近两轮消息加系统提示。这个降级方案效果虽然一般但至少保证了服务不挂。线上系统没有兜底方案就是裸奔这是我从多次线上事故里得出的最深刻的教训。context-mode 做到现在我的体会是上下文管理的本质不是技术炫技而是给模型的信息做减法决定在每一轮对话里让模型看什么、不看什么。这套思路的价值会随着模型能力的提升越来越大——模型越聪明喂给它的信息质量就越重要。如果你的产品也受困于长对话失忆或成本失控不妨从分层路由开始搭一套属于自己的 context-mode。