context-mode实战：让AI产品真正记得住事、接得上话

我前段时间跟一个做对话产品的同行聊天他吐槽了一个特别典型的线上问题用户刚问完订单状态接着又问怎么退款系统居然接不上“订单状态”这个上下文回答得像个第一次见面的陌生人。这个问题表面看是模型能力不足但实际排查后发现根子出在项目里压根没有一套成体系的context-mode——也就是“上下文模式”。context-mode这个概念翻译成中文就是上下文模式。它做的事情很实在定义系统在什么场景下、记住哪些信息、忘掉哪些信息、切换场景时又该带走什么。没有这套机制AI产品就会陷入“每次对话都失忆”的尴尬有了它产品才能在不同业务场景之间无缝切换保持连贯的用户体验。这篇文章我想从设计思路到落地实操完整聊一遍我在实际项目里怎么拆解和实现context-mode以及踩过的坑。适合正在做对话类产品、智能客服、AI助手或任何需要记忆能力的应用的开发者、产品经理和架构师参考。1. 先搞清楚context-mode到底在解决什么问题1.1 没有上下文模式的系统长什么样先说个生活化类比。你去医院挂科先到导诊台问了骨科在哪等真正见到医生时医生还得再问你一遍“哪里不舒服”。这不是医生笨而是信息没有跟着患者流转。很多AI产品就是这样每一次交互都是全新的开始用户上一秒说过的话、选过的条件、偏好的表达方式系统统统不记得。我见过不少项目所谓“上下文”就是往prompt里拼一个最近N轮对话的数组。看起来好像有上下文但问题一大堆用户A问过什么用户B可能共享同一份历史记录用户从“售前咨询”聊到“售后投诉”系统还把售前的商品偏好往投诉场景里塞上下文只存在内存里服务一重启全没了。这些问题的共同点在于上下文是在“顺手”和“偶然”的状态下被使用的而不是被当作一类需要专门设计的数据来管理。缺少一个显式的模式边界系统就分不清“现在处于什么场景”以及“该加载哪份上下文”。1.2 有上下文模式的产品差异在哪我做过一个对比实验同一个智能客服机器人开启和关闭context-mode用户体验差别非常大。关闭时用户必须反复重复自己的订单号、地址、问题描述每轮对话都像“重新报案”。一轮会话平均要9到13次交互才能解决问题用户流失率明显偏高。开启后系统能够识别“当前用户正处于售后投诉模式”自动从长期存储里加载该用户近期的订单信息并把会话内的最新描述持续更新进模式上下文里。这时用户只需要说“还是刚才那个订单的问题我觉得赔偿方案不合理”系统就能准确理解“刚才那个订单”指的是哪个订单、问题背景是什么。平均交互次数下降到4次左右处理时长减少了近60%。差别不是模型变聪明了而是应用层给了模型一份“当下最该知道的信息”。模型还是那个模型但喂养它的上下文变精准了。1.3 一句话定义把“该记什么”从偶然变成设计所以context-mode的核心理念我总结成一句话上下文不是对话历史而是与当前模式相关的、被结构化管理的记忆单元。很多团队看到“上下文”两个字就以为是聊天记录拼接其实真正的设计核心是“模式”两个字。模式 当前的业务场景 该场景需要的信息范围 该信息的生命周期和优先级。同一个用户在同一产品里可能同时存在多个上下文模式购物模式、售后模式、账号管理模式、闲聊模式。它们之间可以共存、隔离、按需切换而不能被简单粗暴地塞进同一个字符串里。理解到这个层面后面所有设计才立得住。2. 动手前先拆解上下文模式的核心设计与维度2.1 上下文的四种来源类型我习惯把上下文按来源拆成四类每一类的采集方式、可信度、时效性都不一样设计时得区别对待。会话内上下文用户在本次连续对话中产生的信息比如刚说过的订单号、选过的选项、情绪状态。特征是高时效、强相关但容易过时。环境上下文设备信息、当前时间、地理位置、网络状态、所处页面。比如用户晚上11点在售后页面发起会话环境上下文提示这可能是一个紧急投诉。画像上下文用户的长期属性比如会员等级、常用地址、历史偏好、称呼方式。这类信息相对稳定但也要注意隐私边界。领域上下文当前模式对应的知识库、行业规则、产品SKU、FAQ集合。比如客服的售前模式需要加载商品知识库售后模式则要加载售后政策文档。这里有一个新手常踩的坑把画像上下文当作会话上文去管理导致每次对话都塞入大量静态信息白白消耗token还稀释了当前会话中真正重要的动态信息。正确做法是分类型管理、分优先级注入。2.2 上下文模式的三个关键维度设计一个context-mode体系至少要定义清楚三个维度作用域。这份上下文属于谁是一个用户、一个会话、一个设备还是一个团队作用域决定了存储的key怎么设计也决定了隔离边界。最常见也最危险的是作用域错配——比如单用户会话的上下文被存到了全局作用域造成用户与用户之间的信息串扰。生存周期。上下文应该存活多久实时会话级别的可以以天为单位业务订单级别的应该存活到订单完结用户偏好级别的可以保留数月。每条上下文都需要一个明确的过期策略不设过期就等于制造脏数据。优先级与容量。真正能注入模型的上下文是有限的。你不能把所有的历史都搬进去必须定义哪些信息的高优先级必须带哪些低优先级可以先省略或压缩。我通常会在上下文管理模块里给每条记录一个weight字段按权重排序后截断或摘要。维度关键问题典型配置作用域上下文属于谁user_id session_id mode_id生存周期多久过期会话级/订单级/偏好级优先级超出容量时丢谁weight字段结构化的核心信息优先2.3 为什么不能用“全局缓存”糊弄有朋友说搞那么复杂干嘛我直接在Redis里放一个keyvalue就是用户的历史记录每次拼上不就行了这个方案看起来快但真正用起来会非常痛苦。首先是污染问题。全局缓存没有模式边界售前咨询的数据会被带到售后流程里。我见过一个真实case客服机器人把用户售前问“这款手机有没有绿色”的信息当成售后信息去判断“手机变绿是质量问题”闹出笑话。其次是版本混乱。同一个用户的三路并发会话如果共享同一个全局上下文key后写的会覆盖先写的整个逻辑完全不可控。用户在三端同时找客服会互相踩踏。第三是难以解释。出了问题没有模式标记你就说不清楚系统当时为什么带上了那段不相关的内容。对AI应用来说可解释性就是可维护性。数据没有结构和归属故障排查就会变成“盲人摸象”。所以我坚持要有一个显式的上下文管理层而不是简单用一个缓存key糊弄过去。这个管理层就是context-mode的核心。3. 实操落地给智能客服做一个context-mode3.1 第一步定义模式清单与默认模式任何产品都不可能一上来就把所有场景的模式都做全。我的建议是先盘点高频业务场景按“用户目的差异度”和“共享上下文重合度”来切分模式。以智能客服为例我通常会把模式分成三到五个order_query订单查询模式加载用户最近订单列表和物流信息。after_sale售后处理模式加载订单详情、售后政策、历史工单。product_consult商品咨询模式加载知识库、SKU参数、优惠活动。account_manage账号管理模式加载账号安全信息、实名状态。切分的判断标准是如果一个模式里需要的信息跟另一个模式的重合度很低并且注入方式差别很大那就值得拆开。反之如果两个场景高度相似就不要为了拆而拆模式多了管理成本是指数上升的。每个用户必须有一个默认模式。默认模式不一定是“什么都不加载”我通常设为product_consult因为大部分进线用户的第一需求是了解商品。3.2 第二步设计上下文的存储结构我建议用结构化JSON来存上下文而不是纯文本拼接。因为纯文本无法支撑后续的排序、过滤、压缩和查询。以下是一个简化版结构我在项目里实际用过{ user_id: u_123456, mode_id: after_sale, updated_at: 2025-06-18T10:24:00Z, entries: [ { id: e_001, type: order_info, source: session_embed, weight: 0.9, expire_at: 2025-06-25T00:00:00Z, payload: { order_id: SO20250618001, status: 已发货, item: 智能手环标准版, amount: 199.0 } }, { id: e_002, type: user_stated_preference, source: session_embed, weight: 0.6, expire_at: 2025-06-18T12:00:00Z, payload: { tone_preference: 希望回复简短直接 } } ] }每个字段有它的用途type用来分类处理source用来追溯数据来源weight决定它被注入时的优先级expire_at保证它不会永久占用容量。这里有一点要注意payload里只存“模型需要直接知道的对象”不要冗余存一大堆与当前模式无关的原始日志。宁可在需要时回查也不要提前塞满。3.3 第三步上下文如何写入和更新我采用了一个“短时缓冲 长期固化”的两层机制类似人脑的工作记忆和长时记忆。每一次用户消息进来先用一个轻量级的短时缓冲比如一个固定大小的队列保存最近几轮摘要和关键词。这一步的目的是让模型在实时对话时有“短时记忆”。然后异步判断这些短时信息里有没有需要“固化”进模式的条目——比如用户提供了订单号、明确表达了一个偏好、确认了一个实体信息。有则写入结构化存储并更新updated_at。固化的触发条件不能太宽松否则所有噪声都会被写入上下文会很快变得又臭又杂。我常用的是一条规则信息在短时缓冲中出现两次或用户主动确认无误才固化。注入的时候我按weight排序取前N条再换算成一个context_block拼进系统提示词里。N的大小由模型上下文窗口减去核心指令、历史对话后的剩余空间决定。比如上下文窗口总容量约8000 token系统指令占1200最近对话占4000那就剩2800 token给结构化上下文。3.4 第四步模式切换时怎么处理记忆模式切换是context-mode最核心的机制也是最容易出bug的地方。我早期的实现是直接清空当前缓冲结果用户切模式之后说“刚才那个订单”系统完全不知所云。后来我改成了“快照 按需恢复”策略。流程大概是这样的伪代码def switch_mode(user_id, new_mode): db get_context_store(user_id) if db.current_mode new_mode: return # 1. 把当前模式的短时缓冲打包进快照但不丢掉历史 snapshot pack_buffer(db.short_term_buffer) db.mode_snapshots[db.current_mode] snapshot # 2. 切换当前模式指针 db.current_mode new_mode # 3. 尝试恢复新模式的历史快照 prev db.mode_snapshots.get(new_mode) if prev: for entry in prev: rehydrate_entry(entry) else: init_mode_context(new_mode) save_context_store(user_id, db)这样用户在售前咨询聊到一半临时去售后查一下物流回来切回售前模式时之前的商品偏好和浏览历史都还在。这个“回来还记得”的体验对用户的信任建立极其重要很多人性化感受都来自这一点。3.5 模式变量在prompt里怎么落地上下文模式最终要体现在模型输入上。我在系统提示词里会显式声明当前模式和可用信息让模型知道自己处于什么角色、能依据哪些信息。一个简化的system prompt片段你是一名智能助手当前处于【售后处理模式】。 你可以使用以下用户上下文信息作为对话依据 订单号 SO20250618001状态已发货商品智能手环标准版。 用户偏好回复简短直接。 如果用户问的是订单查询以外的内容请提示当前模式仅支持售后处理并引导用户切换。这个写法的好处是给模型一个“边界感”。模型不会胡猜也不会把不相关的知识硬往上套。同时我在prompt里会加一句“如果上下文中存在与当前问题矛盾的信息以上下文最新时间为准”防止过期数据误导生成。3.6 效果评估指标做了这么多设计怎么知道context-mode好不好用我习惯跟踪几个指标用数据说话上下文命中率模型回答中实际使用了注入上下文的比例。偏低说明注入的信息没被用上可能是表达方式不对也可能是信息不是用户当前需要的。往返交互次数用户完成一个任务所需的对话轮数。这是最直观的体验指标。模式切换成功率用户在切换模式后系统恢复到正确上下文的成功率。低于90%说明快照或恢复链路有漏洞。上下文覆盖率上下文中被模型实际引用的信息条数 / 注入的总条数。用来判断是不是塞了太多冗余信息。这些指标可以每两周复盘一次结合真实会话日志找趋势。我见过优化完上下文注入方式后往返次数立竿见影下降了三分之一的情况这种正反馈也是团队愿意持续投入的原因。4. 常见问题与排查技巧实录4.1 上下文越堆越乱模型反而变笨了现象刚开始模式跑起来效果很好半个月后用户反馈回答变差模型像“犯迷糊”。原因写入的上下文条目只增不减大量低价值的旧信息占据容量高价值的新信息被挤掉。我把它称作“上下文膨胀”。根本原因是固化和淘汰机制没配套。排查方法导出这个用户的上下文存储看entries数量和weight分布。如果大量条目的weight都是0.5以下还长期存在就是淘汰逻辑失效了。解决方案增加两步——定期衰减条目随时间自动降权比如每过24小时weight打八折容量淘汰当条目超过上限比如50条按weight排序删除尾部条目。记住一个原则上下文管理要像冰箱清理一样每周不清理一定会发臭。4.2 上下文窗口放不下报错或者被暴力截断现象用户聊了很多轮注入内容较多最终拼接时超过模型窗口限制要么请求失败要么模型丢失了前面的对话。原因上下文的注入不是按token算的而是按条数硬塞单位消耗估计不足。排查方法给每条上下文加一个估算token字段日志里记录每次请求的token消耗超限时报警。解决方案加一层“动态压缩”机制。具体做法是当注入内容超过预算时不再简单截断而是让模型或规则引擎先对低权重条目做摘要比如把三条历史query合并成一句“用户询问过物流和价格问题”。摘要后的信息仍然保留语义但体积大幅缩小。这是我用下来性价比最高的优化方式。4.3 模式切换后用户说“你忘记我说的了”现象用户在售后模式里提到过“损坏的配件是表带”切到咨询模式再切回来系统完全不记得表带的事。原因快照保存的是“结构化条目”但用户会话中可能只有一句口语描述未被固化成条目切换时被清空了。排查方法查看切换时点的快照日志对比用户原话是否存在但未进入结构化存储。解决方案在快照打包时不只保存结构化entries把最近短时缓冲里的原始消息也一并打包恢复时重新走一次“信息抽取”流程。也就是让原始信息有机会被二次理解而不是一刀切丢掉。4.4 多设备切换导致上下文不同步现象用户在手机端跟客服聊到一半换到电脑端继续结果电脑端没有手机端的上下文。原因上下文存储以session_id为维度但同一个用户的session在不同设备上是不同的。排查方法是先明确业务语义上下文应该跟user_id绑定还是session绑定我认为长期画像和订单信息跟user_id绑定实时的对话轮次跟session绑定。多设备切换时至少要保证user_id级的结构化上下文能跨端读取。解决方案在存储层做双层key设计。user_id:mode_id存长期结构化上下文user_id:session_id存短时缓冲。设备切换时先恢复长期上下文再根据用户最近的session记录拼接短时记忆。4.5 性能开销太大每个请求都查库现象接入context-mode后接口RT涨了很多因为每次请求都要查存储、做摘要、拼接。原因所有逻辑都放在同步链路里执行没有做缓存和异步化。解决方案三层优化一是把用户在当前模式下最常用的上下文做内存缓存设置TTL为1分钟避免反复查库二是把“固化”这类写操作放到异步队列不阻塞主流程三是给摘要操作加一层“摘要缓存”相同来源的上下文短时间内不重复摘要。这一套组合下来我实测上下文加载从平均120ms降到了35ms左右。下面是常见问题速查表方便直接对照问题表现可能原因排查入口解决方案模型回答前后矛盾上下文条目冲突或过期检查entries的update时间按时间覆盖旧值冲突时以新为准请求token超限注入容量没有按token预算查看请求日志token消耗动态摘要低权重裁剪切换后记忆丢失快照没保存短时缓冲检查切换日志的snapshot内容快照同时保存原始消息并二次抽取跨设备上下文缺失key作用域绑定错误检查存储key结构user级与session级双层key接口响应变慢缺少缓存和异步化分析RT耗时分布内存缓存异步固化摘要缓存5. 我总结的几点经验5.1 从“少而准”开始别一开始就搞全局感知很多团队一听context-mode第一反应是“把所有上下文都收集起来让模型无所不知”。我的亲身经验是这条路基本必死。上下文不是越多越好而是越准越好。第一版设计哪怕只支持一两个模式、每模式只存五条结构化信息都比做一个大而全的“上下文池”强。先把链路跑顺再在迭代里逐步增加信息来源。5.2 给用户一个“记忆可见性”我在实际运营中发现用户对AI最不信任的一点是“它到底记了我什么”。如果上下文管理得当不妨在界面上提供“我了解的信息”面板让用户看到系统记住了什么、可以修改和删除。这个设计不仅能增加信任感还能倒逼自己的上下文存储保持结构化因为它要直接展示给用户看。凡是不敢展示给用户的上下文多半是脏数据。5.3 每次迭代都要回看切换日志最后一个小技巧上线context-mode后把主动切换模式的日志当作核心数据来关注。用户从什么模式切到什么模式、切换前最后说了什么、恢复上下文后有没有追问旧信息——这些日志是优化上下文策略最好的素材远比看整体平均指标有用。我在实际操刀时很多次“模式边界应该怎么调整”的判断都是从切换日志里看出来的。context-mode其实不难做难的是克制、隔离、让上下文有序地流动。从一个场景、一个模式、十来个字段开始你也能让自己的AI产品真正“记得住事、接得上话”。