Context-Mode这个词这两年做AI应用的人应该不陌生。我在自己的几个项目里反复折腾过上下文管理一开始是把所有对话记录一股脑塞给模型结果token爆表、回复跑偏、成本还高得离谱。后来才慢慢摸清楚所谓context-mode本质上是给大模型应用设计一套可切换的上下文组织方式什么时候用完整历史什么时候只带关键片段什么时候干脆清空重来。这篇文章我把自己的设计思路、核心实现和踩过的坑完整梳理一遍适合正在做AI助手、智能客服、Agent类应用的开发者参考也适合刚接触LLM工程化、对上下文管理还没形成体系的朋友。1. 先搞清楚Context-Mode到底在解决什么问题1.1 一句话说清楚Context-ModeContext-Mode翻译过来就是“上下文模式”。它不是一个开源框架的名字也不是某个模型的特性而是一套应用层的设计方案给对话系统或Agent定义多个上下文处理模式让系统根据当前任务需求动态决定往模型输入里塞什么、不塞什么、塞多少。你可以把它类比成手机上的“专注模式”和“普通模式”。专注模式只保留白名单应用的通知普通模式全部放行。Context-Mode也一样聚焦模式只保留和当前任务强相关的上下文全局模式才把完整的会话历史带进模型。目的只有一个让模型在有限上下文窗口内看到最该看的信息产出最准的回复。1.2 没有上下文模式的痛我先说没有这套设计时踩过的坑。最典型的场景是智能客服。用户进来问“我的订单什么时候到”然后聊了几轮又跳到“你们退货政策是什么”再跳回“那我的订单还送不送赠品”。我把所有聊天记录全部拼接进Prompt模型回答倒是没乱但问题来了Token成本直线上升。一次请求带上几千上万的历史token一个月下来账单很难看。关键信息被稀释。模型注意力是有限的历史里杂七杂八的内容太多真正重要的订单号、用户意图反而被淹没。实测下来上下文越长回复模板化越严重。响应变慢。输入token多首token延迟明显增加用户体感就是“转圈圈转半天”。多轮切换场景容易串味。用户已经在聊退货了模型还惦记着之前快递的事情答非所问。单上下文的问题在于它是一种“有损但多数时候够用”的方案。真正要做生产级应用需要的是按场景切换上下文策略。1.3 Context-Mode适合哪些场景不是所有应用都需要Context-Mode。如果你的应用是单轮问答、每次请求独立、不需要记忆那直接带固定Prompt就行。需要这套设计的大概是这几类多轮对话型AI助手需要记忆前文但不同阶段关注点不同。Agent式任务执行系统Agent需要多步规划每步要携带任务相关的中间信息但不需要全部历史。客服/销售类业务系统会话长、话题切换频繁用户资料和当前问题要优先保证。RAG增强的问答应用检索出来的文档片段需要和会话历史做融合但融合方式要按模式区分。核心判断标准就一句话如果你的应用存在“上下文带少了不行、带多了浪费且影响效果”的权衡那就值得上Context-Mode。2. 整体设计模式怎么划分、切换谁说了算2.1 三种基础模式聚焦、全局、临时我自己在设计时没有一上来搞太多花哨的模式而是先定了三种基础模式覆盖绝大多数业务场景模式上下文范围典型使用场景Token开销聚焦模式Focused当前任务相关上下文 用户核心画像客服处理订单、Agent执行单步任务低全局模式Global全部会话历史 用户画像 业务知识深度闲聊、需要完整理清前因后果的复杂对话高临时模式Ephemeral仅当前轮输入 固定系统提示独立问答、意图识别、敏感操作确认极低聚焦模式是主力。用户在客服对话里查订单我就把最近的订单信息、用户ID、当前问题相关的历史轮次带进去更早的寒暄内容直接丢掉。全局模式则是兜底——当系统判断对话进入复杂协调阶段比如用户反复修改需求、需要跨多轮信息整合时才切换成完整上下文。临时模式用于那些本来就不该带记忆的操作比如用户问一句“今天天气怎么样”你没必要把上周的对话都塞给它。2.2 模式切换的触发逻辑模式切换有两种触发方式显式路由和隐式判断。显式路由最简单由业务逻辑直接指定。用户在界面点了一个“新对话”按钮系统就把上下文重置成临时模式用户发起投诉工单业务层指定走聚焦模式只带投诉相关的历史记录。隐式判断则需要一个模式决策器。我常做的做法是用一个轻量模型对当前轮输入做意图分类判断属于“继续当前话题”“切换新话题”还是“独立请求”再结合会话状态机决定模式。比如# 伪代码模式决策 def decide_mode(session, current_input): intent classify_intent(current_input) # 轻量分类模型 if intent independent_query: return Mode.EPHEMERAL if intent topic_switch: return Mode.FOCUSED # 丢弃旧话题重建焦点 if session.ambiguity_score 0.7: return Mode.GLOBAL # 当前话题复杂度高需要完整历史 return Mode.FOCUSED这里有个容易忽略的点切换之后要通知下游做上下文的“重建”而不是简单换一个枚举值。Context-Mode真正的工作量在重建逻辑里。2.3 为什么不做成单一上下文有人会问为什么不干脆维护一份“高质量上下文”每次请求都用它省去切换的麻烦我在项目早期也是这么想的结果发现“高质量上下文”这个概念本身就是伪命题。同一个会话里不同任务对上下文的需求是冲突的。查订单的状态只关心最近的物流记录但讨论退货退款时需要原始的支付信息、订单创建时间、历史沟通记录。你用同一份上下文去满足两种需求必然有一方被牺牲。单一上下文还会带来“上下文漂移”问题——随着会话推进早期信息逐渐被挤出窗口等真正需要它们的时候已经没了。Context-Mode的实质不是优化上下文本身而是优化上下文与任务之间的匹配度。模式划分越贴合业务类型这种匹配就越准。3. 核心实现跑通一套Context-Mode需要做哪些事3.1 定义上下文的数据结构落地第一步是定义上下文的数据结构。我用的方案是分层的Context对象分为三个层级全局层GlobalLayer用户画像、业务偏好、长期不变的静态信息。会话层SessionLayer最近N轮对话、当前活跃话题、临时状态变量。任务层TaskLayer当前任务相关的实体、目标、中间产物。dataclass class Context: global_layer: dict # 用户ID、会员等级、偏好标签 session_layer: SessionMemory # 最近K轮、话题栈、意图历史 task_layer: dict # 当前订单号、退货单状态、待确认项 mode: Mode # 当前使用哪种模式三个层级对应三种模式的不同装配策略。聚焦模式 全局层 任务层 会话层截断到最近3轮全局模式 三层全量临时模式 只带全局层的必要字段。这种结构化设计的好处是上下文不再是“一片对话记录”而是可以被程序化加工的数据。3.2 实现模式路由与上下文装配器有了数据结构接下来要写装配器Assembler。它的职责是根据模式和业务需求把三层数据按规则组装成最终送给模型的Prompt前缀。class ContextAssembler: def assemble(self, ctx: Context) - str: parts [] if ctx.mode in (Mode.FOCUSED, Mode.GLOBAL): parts.append(self._render_global(ctx.global_layer)) if ctx.mode Mode.FOCUSED: task_block self._render_task(ctx.task_layer) recent self._slice_session(ctx.session_layer, max_rounds3) parts.append(task_block) parts.append(recent) elif ctx.mode Mode.GLOBAL: parts.append(self._render_session_full(ctx.session_layer)) parts.append(self._render_task(ctx.task_layer)) return SEPARATOR.join(parts)装配器的关键原则是确定性排序。全局层放最前面任务层紧跟其后会话历史放最后。因为模型的注意力对Prompt开头和结尾更敏感把关键信息放前面能一定程度减少被稀释的几率。我在实测中发现任务实体放在会话历史之前模型对订单号的记忆准确率会明显提升。3.3 上下文压缩控制Token的核心手段模式切换解决了“带什么”的问题但聚焦模式下也可能出现任务上下文太长的情况。这时候需要配合压缩策略。我用过三种按性价比排序截断只保留最近N轮最早的直接丢弃。实现最简单适合聊天内容本身价值递减的场景。摘要压缩对超过阈值的早期对话做一次摘要把摘要作为一层轻量记忆放回会话层。适合长会话但需要保留脉络的场景。结构化提取从对话中提取关键实体、决策点、待办事项形成结构化记录替换原始文本。适合客服、工单这类强业务场景。def compress_session(session, max_rounds10, max_tokens2000): if session.estimate_tokens() max_tokens: return session recent session.rounds[-max_rounds:] # 保留最近 older session.rounds[:-max_rounds] # 压缩更早的 summary summarize_rounds(older, target_tokens400) return SessionMemory( roundsrecent, summarysummary, original_countsession.estimate_rounds() )摘要压缩我推荐用独立的轻量模型跑不要占用主对话的生成tokens。压缩可以异步做用户说话间隙触发避免增加首token延迟。3.4 与外部系统的衔接RAG和记忆库怎么融入模式Context-Mode不等于RAG但两者经常要配合。我的做法是把RAG检索也纳入模式路由聚焦模式 RAG根据任务层的关键实体生成检索词只检索与当前任务相关的文档片段默认返回前3条。全局模式 RAG检索词的范围放宽到用户完整话题历史返回更多文档允许交叉验证。临时模式默认不做检索除非当前输入自带明确的知识查询意图。长期记忆库比如向量库里的用户偏好、历史订单统一挂在全局层。每次会话开始时用用户ID检索出最相关的记忆片段作为GlobalLayer的一部分注入。这里要注意记忆检索结果本身要设上限否则全局层也会膨胀。我习惯把全局层的token预算控制在500以内只放最核心的信息。4. 实操案例一个订单客服助手的Context-Mode全流程4.1 场景设定为了讲清楚这套机制的实际运作我用一个订单客服机器人做例子。业务需求很常见用户查订单、问物流、提退换货。会话可能很长但每个时间点用户关注的问题相对集中。技术栈假设是LangChain或自研Pipeline OpenAI兼容接口 Redis做会话存储 轻量意图模型做模式分类。下面只讲Context-Mode相关的核心逻辑完整工程代码太长不贴。4.2 核心代码与流程整个请求处理流程分四步读取旧上下文、决策模式、装配新上下文、调用模型。def handle_message(user_id, content): # 1. 从Redis恢复上下文 ctx load_context(user_id) # 2. 决策模式 ctx.mode decide_mode(ctx, content) # 3. 根据模式装配Prompt prompt assembler.assemble(ctx) # 4. 调用模型并更新上下文 reply chat_completion(messages[{role: user, content: prompt}]) update_context(user_id, ctx, content, reply) return reply同时在处理逻辑里要维护一个话题栈。用户问“我的订单到哪了”话题栈压入“订单查询-订单号xxx”。用户接着问“这款支持退吗”分类模型判定为关联但不同话题系统切换到聚焦模式把商品信息注入任务层但保留订单号以备用户跳回来接着问。这就是话题栈的价值模式切换时不是暴力清空而是有迹可循地换焦点。def update_context(user_id, ctx, user_input, reply): # 新话题压栈旧话题保留在浅层 topic extract_topic(user_input) ctx.session_layer.topic_stack.push(topic) # 任务层更新提取当前轮实体 entities extract_entities(user_input) ctx.task_layer.merge(entities) # 限制栈深度超过3层时压缩最底层 if len(ctx.session_layer.topic_stack) 3: ctx.session_layer.summary summarize_topic( ctx.session_layer.topic_stack.pop(0) ) save_context(user_id, ctx)4.3 效果对比这套上线后我对比了三种方案无上下文管理只带最近2轮、全量上下文、Context-Mode。数据来自内部压测500组真实客服对话回放方案平均每次请求Token数回答准确率(人工盲评)首token延迟(中位数)只带最近2轮78076.4%240ms全量历史420081.1%420msContext-Mode135088.7%260msToken开销比全量历史降了约68%准确率还更高。原因很直接聚焦模式把用户画像和当前任务实体放在Prompt前部模型更容易抓住重点。这个结果也印证了我前面说的——上下文管理不是信息越多越好关键是匹配任务。5. 常见问题与排查心得5.1 上下文污染旧话题干扰新话题这是最常见的问题。用户跳话题后旧任务的信息残留在上下文里模型容易把两个话题搅在一起。典型表现用户问退货政策模型回复里还在提物流时效。我的排查方法是盯任务层的实体变化。每次模式切换时把task_layer中与旧话题关联的实体清掉只保留跨话题仍然有效的全局实体用户ID、订单号。同时给Prompt加一道显式指令“当前用户关注的问题是【xxx】请只围绕该问题回答”实测能显著压低串味率。5.2 Token超限与成本失控全局模式下超长会话很容易撑爆上下文窗口。我遇到过最极端的情况是用户连续聊了50多轮全量上下文超过12k token直接触发模型报错。处理方案是双保险一是软性预算每次装配前估算token数超过阈值自动降级全局→聚焦→临时二是异步压缩会话空闲时后台把早期对话摘要化替换原始轮次。我建议预算设成模型窗口的70%留足输出空间。5.3 模式切换导致的信息丢失切换模式太激进会让模型“失忆”。比如聚焦模式只带3轮历史用户在第5轮突然问“我刚才说的那个颜色你没记住吗”模型一脸懵。这个问题要从话题栈上解决。切换模式时旧话题不直接销毁而是压缩成一句话摘要放入会话层的summary字段。后续如果用户提起“刚才说的”系统能通过语义匹配找回摘要内容。相当于给上下文加了一层“低成本的长期记忆”。5.4 排查速查表症状可能原因处理建议回复张冠李戴任务层旧实体未清理切换话题时清空任务层只保留全局实体Token超限全局模式兜底太频繁降低切换全局模式的阈值分数响应慢摘要压缩阻塞了主流程压缩改为异步任务不占用请求链路关键信息丢失聚焦模式截断太狠把业务关键实体提升到全局层不依赖会话层模式频繁跳动意图模型不稳定增加切换冷却时间至少停留2轮6. 个人经验补充几个容易忽略的细节最后分享几个我在实际开发中发现的小细节都是踩过坑才学到的。第一模式的枚举值不要硬编码在业务代码里。把模式定义成配置项支持线上动态调参。我试过把聚焦模式的“最近3轮”改成“最近5轮”业务效果有明显变化如果不能快速调整这类优化只能等发版很被动。第二上下文装配要支持可视化调试。我开发时做了个调试面板线上每个请求的Prompt都记录在案可以看到当前使用的是哪种模式、任务层放了什么、历史被压缩了多少。遇到效果问题时第一步永远先看这个面板基本能定位一半以上的问题。第三Context-Mode和缓存可以联动。同一个用户在同一模式下如果任务层的核心标识没变比如订单号没变系统提示、全局层这些前缀部分完全可以做缓存复用省掉重复序列化开销。这部分优化在高并发场景下效果挺明显。这套方案我后续还在扩展比如把模式决策从规则式改成可学习的排序模型根据历史效果反馈自动调整模式切换阈值。核心思路不变上下文不是越多越好最贵的一定要花在最关键的信息上。如果你们也在做带会话记忆的AI应用可以从最简单的三种模式开始尝试跑通链路后再逐步加细节。
Context-Mode这个词这两年做AI应用的人应该不陌生。我在自己的几个项目里反复折腾过上下文管理一开始是把所有对话记录一股脑塞给模型结果token爆表、回复跑偏、成本还高得离谱。后来才慢慢摸清楚所谓context-mode本质上是给大模型应用设计一套可切换的上下文组织方式什么时候用完整历史什么时候只带关键片段什么时候干脆清空重来。这篇文章我把自己的设计思路、核心实现和踩过的坑完整梳理一遍适合正在做AI助手、智能客服、Agent类应用的开发者参考也适合刚接触LLM工程化、对上下文管理还没形成体系的朋友。1. 先搞清楚Context-Mode到底在解决什么问题1.1 一句话说清楚Context-ModeContext-Mode翻译过来就是“上下文模式”。它不是一个开源框架的名字也不是某个模型的特性而是一套应用层的设计方案给对话系统或Agent定义多个上下文处理模式让系统根据当前任务需求动态决定往模型输入里塞什么、不塞什么、塞多少。你可以把它类比成手机上的“专注模式”和“普通模式”。专注模式只保留白名单应用的通知普通模式全部放行。Context-Mode也一样聚焦模式只保留和当前任务强相关的上下文全局模式才把完整的会话历史带进模型。目的只有一个让模型在有限上下文窗口内看到最该看的信息产出最准的回复。1.2 没有上下文模式的痛我先说没有这套设计时踩过的坑。最典型的场景是智能客服。用户进来问“我的订单什么时候到”然后聊了几轮又跳到“你们退货政策是什么”再跳回“那我的订单还送不送赠品”。我把所有聊天记录全部拼接进Prompt模型回答倒是没乱但问题来了Token成本直线上升。一次请求带上几千上万的历史token一个月下来账单很难看。关键信息被稀释。模型注意力是有限的历史里杂七杂八的内容太多真正重要的订单号、用户意图反而被淹没。实测下来上下文越长回复模板化越严重。响应变慢。输入token多首token延迟明显增加用户体感就是“转圈圈转半天”。多轮切换场景容易串味。用户已经在聊退货了模型还惦记着之前快递的事情答非所问。单上下文的问题在于它是一种“有损但多数时候够用”的方案。真正要做生产级应用需要的是按场景切换上下文策略。1.3 Context-Mode适合哪些场景不是所有应用都需要Context-Mode。如果你的应用是单轮问答、每次请求独立、不需要记忆那直接带固定Prompt就行。需要这套设计的大概是这几类多轮对话型AI助手需要记忆前文但不同阶段关注点不同。Agent式任务执行系统Agent需要多步规划每步要携带任务相关的中间信息但不需要全部历史。客服/销售类业务系统会话长、话题切换频繁用户资料和当前问题要优先保证。RAG增强的问答应用检索出来的文档片段需要和会话历史做融合但融合方式要按模式区分。核心判断标准就一句话如果你的应用存在“上下文带少了不行、带多了浪费且影响效果”的权衡那就值得上Context-Mode。2. 整体设计模式怎么划分、切换谁说了算2.1 三种基础模式聚焦、全局、临时我自己在设计时没有一上来搞太多花哨的模式而是先定了三种基础模式覆盖绝大多数业务场景模式上下文范围典型使用场景Token开销聚焦模式Focused当前任务相关上下文 用户核心画像客服处理订单、Agent执行单步任务低全局模式Global全部会话历史 用户画像 业务知识深度闲聊、需要完整理清前因后果的复杂对话高临时模式Ephemeral仅当前轮输入 固定系统提示独立问答、意图识别、敏感操作确认极低聚焦模式是主力。用户在客服对话里查订单我就把最近的订单信息、用户ID、当前问题相关的历史轮次带进去更早的寒暄内容直接丢掉。全局模式则是兜底——当系统判断对话进入复杂协调阶段比如用户反复修改需求、需要跨多轮信息整合时才切换成完整上下文。临时模式用于那些本来就不该带记忆的操作比如用户问一句“今天天气怎么样”你没必要把上周的对话都塞给它。2.2 模式切换的触发逻辑模式切换有两种触发方式显式路由和隐式判断。显式路由最简单由业务逻辑直接指定。用户在界面点了一个“新对话”按钮系统就把上下文重置成临时模式用户发起投诉工单业务层指定走聚焦模式只带投诉相关的历史记录。隐式判断则需要一个模式决策器。我常做的做法是用一个轻量模型对当前轮输入做意图分类判断属于“继续当前话题”“切换新话题”还是“独立请求”再结合会话状态机决定模式。比如# 伪代码模式决策 def decide_mode(session, current_input): intent classify_intent(current_input) # 轻量分类模型 if intent independent_query: return Mode.EPHEMERAL if intent topic_switch: return Mode.FOCUSED # 丢弃旧话题重建焦点 if session.ambiguity_score 0.7: return Mode.GLOBAL # 当前话题复杂度高需要完整历史 return Mode.FOCUSED这里有个容易忽略的点切换之后要通知下游做上下文的“重建”而不是简单换一个枚举值。Context-Mode真正的工作量在重建逻辑里。2.3 为什么不做成单一上下文有人会问为什么不干脆维护一份“高质量上下文”每次请求都用它省去切换的麻烦我在项目早期也是这么想的结果发现“高质量上下文”这个概念本身就是伪命题。同一个会话里不同任务对上下文的需求是冲突的。查订单的状态只关心最近的物流记录但讨论退货退款时需要原始的支付信息、订单创建时间、历史沟通记录。你用同一份上下文去满足两种需求必然有一方被牺牲。单一上下文还会带来“上下文漂移”问题——随着会话推进早期信息逐渐被挤出窗口等真正需要它们的时候已经没了。Context-Mode的实质不是优化上下文本身而是优化上下文与任务之间的匹配度。模式划分越贴合业务类型这种匹配就越准。3. 核心实现跑通一套Context-Mode需要做哪些事3.1 定义上下文的数据结构落地第一步是定义上下文的数据结构。我用的方案是分层的Context对象分为三个层级全局层GlobalLayer用户画像、业务偏好、长期不变的静态信息。会话层SessionLayer最近N轮对话、当前活跃话题、临时状态变量。任务层TaskLayer当前任务相关的实体、目标、中间产物。dataclass class Context: global_layer: dict # 用户ID、会员等级、偏好标签 session_layer: SessionMemory # 最近K轮、话题栈、意图历史 task_layer: dict # 当前订单号、退货单状态、待确认项 mode: Mode # 当前使用哪种模式三个层级对应三种模式的不同装配策略。聚焦模式 全局层 任务层 会话层截断到最近3轮全局模式 三层全量临时模式 只带全局层的必要字段。这种结构化设计的好处是上下文不再是“一片对话记录”而是可以被程序化加工的数据。3.2 实现模式路由与上下文装配器有了数据结构接下来要写装配器Assembler。它的职责是根据模式和业务需求把三层数据按规则组装成最终送给模型的Prompt前缀。class ContextAssembler: def assemble(self, ctx: Context) - str: parts [] if ctx.mode in (Mode.FOCUSED, Mode.GLOBAL): parts.append(self._render_global(ctx.global_layer)) if ctx.mode Mode.FOCUSED: task_block self._render_task(ctx.task_layer) recent self._slice_session(ctx.session_layer, max_rounds3) parts.append(task_block) parts.append(recent) elif ctx.mode Mode.GLOBAL: parts.append(self._render_session_full(ctx.session_layer)) parts.append(self._render_task(ctx.task_layer)) return SEPARATOR.join(parts)装配器的关键原则是确定性排序。全局层放最前面任务层紧跟其后会话历史放最后。因为模型的注意力对Prompt开头和结尾更敏感把关键信息放前面能一定程度减少被稀释的几率。我在实测中发现任务实体放在会话历史之前模型对订单号的记忆准确率会明显提升。3.3 上下文压缩控制Token的核心手段模式切换解决了“带什么”的问题但聚焦模式下也可能出现任务上下文太长的情况。这时候需要配合压缩策略。我用过三种按性价比排序截断只保留最近N轮最早的直接丢弃。实现最简单适合聊天内容本身价值递减的场景。摘要压缩对超过阈值的早期对话做一次摘要把摘要作为一层轻量记忆放回会话层。适合长会话但需要保留脉络的场景。结构化提取从对话中提取关键实体、决策点、待办事项形成结构化记录替换原始文本。适合客服、工单这类强业务场景。def compress_session(session, max_rounds10, max_tokens2000): if session.estimate_tokens() max_tokens: return session recent session.rounds[-max_rounds:] # 保留最近 older session.rounds[:-max_rounds] # 压缩更早的 summary summarize_rounds(older, target_tokens400) return SessionMemory( roundsrecent, summarysummary, original_countsession.estimate_rounds() )摘要压缩我推荐用独立的轻量模型跑不要占用主对话的生成tokens。压缩可以异步做用户说话间隙触发避免增加首token延迟。3.4 与外部系统的衔接RAG和记忆库怎么融入模式Context-Mode不等于RAG但两者经常要配合。我的做法是把RAG检索也纳入模式路由聚焦模式 RAG根据任务层的关键实体生成检索词只检索与当前任务相关的文档片段默认返回前3条。全局模式 RAG检索词的范围放宽到用户完整话题历史返回更多文档允许交叉验证。临时模式默认不做检索除非当前输入自带明确的知识查询意图。长期记忆库比如向量库里的用户偏好、历史订单统一挂在全局层。每次会话开始时用用户ID检索出最相关的记忆片段作为GlobalLayer的一部分注入。这里要注意记忆检索结果本身要设上限否则全局层也会膨胀。我习惯把全局层的token预算控制在500以内只放最核心的信息。4. 实操案例一个订单客服助手的Context-Mode全流程4.1 场景设定为了讲清楚这套机制的实际运作我用一个订单客服机器人做例子。业务需求很常见用户查订单、问物流、提退换货。会话可能很长但每个时间点用户关注的问题相对集中。技术栈假设是LangChain或自研Pipeline OpenAI兼容接口 Redis做会话存储 轻量意图模型做模式分类。下面只讲Context-Mode相关的核心逻辑完整工程代码太长不贴。4.2 核心代码与流程整个请求处理流程分四步读取旧上下文、决策模式、装配新上下文、调用模型。def handle_message(user_id, content): # 1. 从Redis恢复上下文 ctx load_context(user_id) # 2. 决策模式 ctx.mode decide_mode(ctx, content) # 3. 根据模式装配Prompt prompt assembler.assemble(ctx) # 4. 调用模型并更新上下文 reply chat_completion(messages[{role: user, content: prompt}]) update_context(user_id, ctx, content, reply) return reply同时在处理逻辑里要维护一个话题栈。用户问“我的订单到哪了”话题栈压入“订单查询-订单号xxx”。用户接着问“这款支持退吗”分类模型判定为关联但不同话题系统切换到聚焦模式把商品信息注入任务层但保留订单号以备用户跳回来接着问。这就是话题栈的价值模式切换时不是暴力清空而是有迹可循地换焦点。def update_context(user_id, ctx, user_input, reply): # 新话题压栈旧话题保留在浅层 topic extract_topic(user_input) ctx.session_layer.topic_stack.push(topic) # 任务层更新提取当前轮实体 entities extract_entities(user_input) ctx.task_layer.merge(entities) # 限制栈深度超过3层时压缩最底层 if len(ctx.session_layer.topic_stack) 3: ctx.session_layer.summary summarize_topic( ctx.session_layer.topic_stack.pop(0) ) save_context(user_id, ctx)4.3 效果对比这套上线后我对比了三种方案无上下文管理只带最近2轮、全量上下文、Context-Mode。数据来自内部压测500组真实客服对话回放方案平均每次请求Token数回答准确率(人工盲评)首token延迟(中位数)只带最近2轮78076.4%240ms全量历史420081.1%420msContext-Mode135088.7%260msToken开销比全量历史降了约68%准确率还更高。原因很直接聚焦模式把用户画像和当前任务实体放在Prompt前部模型更容易抓住重点。这个结果也印证了我前面说的——上下文管理不是信息越多越好关键是匹配任务。5. 常见问题与排查心得5.1 上下文污染旧话题干扰新话题这是最常见的问题。用户跳话题后旧任务的信息残留在上下文里模型容易把两个话题搅在一起。典型表现用户问退货政策模型回复里还在提物流时效。我的排查方法是盯任务层的实体变化。每次模式切换时把task_layer中与旧话题关联的实体清掉只保留跨话题仍然有效的全局实体用户ID、订单号。同时给Prompt加一道显式指令“当前用户关注的问题是【xxx】请只围绕该问题回答”实测能显著压低串味率。5.2 Token超限与成本失控全局模式下超长会话很容易撑爆上下文窗口。我遇到过最极端的情况是用户连续聊了50多轮全量上下文超过12k token直接触发模型报错。处理方案是双保险一是软性预算每次装配前估算token数超过阈值自动降级全局→聚焦→临时二是异步压缩会话空闲时后台把早期对话摘要化替换原始轮次。我建议预算设成模型窗口的70%留足输出空间。5.3 模式切换导致的信息丢失切换模式太激进会让模型“失忆”。比如聚焦模式只带3轮历史用户在第5轮突然问“我刚才说的那个颜色你没记住吗”模型一脸懵。这个问题要从话题栈上解决。切换模式时旧话题不直接销毁而是压缩成一句话摘要放入会话层的summary字段。后续如果用户提起“刚才说的”系统能通过语义匹配找回摘要内容。相当于给上下文加了一层“低成本的长期记忆”。5.4 排查速查表症状可能原因处理建议回复张冠李戴任务层旧实体未清理切换话题时清空任务层只保留全局实体Token超限全局模式兜底太频繁降低切换全局模式的阈值分数响应慢摘要压缩阻塞了主流程压缩改为异步任务不占用请求链路关键信息丢失聚焦模式截断太狠把业务关键实体提升到全局层不依赖会话层模式频繁跳动意图模型不稳定增加切换冷却时间至少停留2轮6. 个人经验补充几个容易忽略的细节最后分享几个我在实际开发中发现的小细节都是踩过坑才学到的。第一模式的枚举值不要硬编码在业务代码里。把模式定义成配置项支持线上动态调参。我试过把聚焦模式的“最近3轮”改成“最近5轮”业务效果有明显变化如果不能快速调整这类优化只能等发版很被动。第二上下文装配要支持可视化调试。我开发时做了个调试面板线上每个请求的Prompt都记录在案可以看到当前使用的是哪种模式、任务层放了什么、历史被压缩了多少。遇到效果问题时第一步永远先看这个面板基本能定位一半以上的问题。第三Context-Mode和缓存可以联动。同一个用户在同一模式下如果任务层的核心标识没变比如订单号没变系统提示、全局层这些前缀部分完全可以做缓存复用省掉重复序列化开销。这部分优化在高并发场景下效果挺明显。这套方案我后续还在扩展比如把模式决策从规则式改成可学习的排序模型根据历史效果反馈自动调整模式切换阈值。核心思路不变上下文不是越多越好最贵的一定要花在最关键的信息上。如果你们也在做带会话记忆的AI应用可以从最简单的三种模式开始尝试跑通链路后再逐步加细节。
