1. 长对话为什么会“崩”从一次线上事故说起去年年底我接手了一个客服工单系统的 AI 助手改造项目场景很典型用户进来描述问题助手多轮追问、查知识库、给方案整个会话可能持续几十轮。上线第一周就炸了——用户聊到第二十几轮的时候助手开始答非所问前面明确说过的订单号、产品型号全忘了甚至把两个不同用户的信息串在一起。更离谱的是有个用户在第 40 轮问“刚才你说的那个退款流程再讲一遍”助手直接回了一句“我们之前没有讨论过退款流程”。这不是模型不行是上下文管理没做好。很多人第一次做长对话应用脑子里只有一个朴素的想法把历史消息全塞进 prompt 里不就行了我一开始也这么干结果就是 token 爆炸、成本飙升、延迟感人而且模型在超长上下文里反而更容易“迷失”——业界管这叫lost in the middle中间那段信息它基本不看。后来我重新设计了一套记忆分层方案核心就一句话长对话先收口把“工作记忆”和“长期记忆”分开管。这套思路属于现在很热的上下文工程Context Engineering范畴跟提示词工程不是一回事——提示词工程关心“怎么问”上下文工程关心“模型此刻该看到什么”。这篇文章我就把这套方案完整拆开讲包括为什么这么分层、每层怎么实现、参数怎么定、踩过哪些坑做AI Agent、LLM 应用开发的朋友可以直接抄作业。先说清楚适合谁看如果你在做多轮对话机器人、AI 助手、Agent 类产品或者单纯想搞明白“为什么我的 AI 聊久了就变傻”这篇都适用。不需要你懂模型训练只要会写基本的后端代码就能落地。2. 先搞懂“记忆分层”到底在分什么2.1 工作记忆和长期记忆的本质区别这两个词借用了认知心理学的概念但落到工程上区别非常具体。我用一张表说清楚维度工作记忆Working Memory长期记忆Long-term Memory存什么当前会话的近期上下文跨会话沉淀的用户画像、事实、偏好生命周期单次会话会话结束即释放持久化跨会话、跨设备存储介质内存 / Redis带 TTL数据库 / 向量库容量严格受限按 token 预算控制理论上无限按需检索读取方式全量注入 prompt检索后按相关性注入更新频率每轮都变异步、批量、低频典型内容最近 N 轮对话、当前任务状态用户身份、历史订单、长期偏好关键洞察在这里工作记忆是“模型现在必须看到的”长期记忆是“模型可能需要知道的”。前者追求完整和即时后者追求精准和按需。把这两者混在一起就是灾难的开始。我见过太多项目把用户三年前的历史订单和当前这一句“帮我查下物流”一起塞进 prompt模型当然会懵。正确的做法是当前这句话 最近几轮对话构成工作记忆长期记忆里只捞跟“物流”相关的最近订单其余一律不注入。2.2 为什么不能只靠“加大上下文窗口”现在主流模型动辄 128K、200K 甚至 1M token 的上下文窗口很多人觉得“窗口够大就不用管记忆了”。我实测下来这个想法有三个致命问题。第一是成本。上下文窗口是按 token 计费的你把 10 万 token 的历史全塞进去每轮对话都在为这 10 万 token 付费。一个日活几千的应用一个月账单能差出十几倍。第二是延迟输入 token 越多首 token 响应时间越长用户体验直接崩。第三也是最容易被忽略的——注意力稀释。模型在超长上下文里的注意力是有限的无关信息越多真正关键的信息被“淹没”的概率越大。我做过对比测试同样一个问题把无关历史清掉之后回答准确率能提升 20% 以上。所以结论很明确上下文窗口大是好事但它不是让你偷懒的理由而是给你更多预算去精细管理。窗口越大越需要一套收口机制否则就是拿钱和性能换一个“看起来能用”的效果。2.3 三层记忆的完整模型在实际项目里我一般把记忆分成三层比标题里的两层更细一点但核心还是工作记忆和长期记忆的划分工作记忆当前会话的滑动窗口保留最近 N 轮完整对话加上当前任务的结构化状态比如“正在处理退款”“已收集订单号”。长期记忆跨会话的用户事实库包括身份信息、历史行为、偏好标签存在数据库里按需检索。永久记忆极少数几乎不变的核心事实比如用户注册时填的姓名、VIP 等级可以理解为长期记忆里“永远优先注入”的那一小撮。这个分层的好处是每一层有明确的读写策略和预算不会互相污染。下面我逐层拆解怎么落地。3. 工作记忆怎么设计滑动窗口 结构化状态3.1 滑动窗口的轮数怎么定工作记忆最朴素的实现就是滑动窗口只保留最近 N 轮对话。问题是 N 定多少我试过 5、10、20 轮最后发现没有万能值得按场景算。计算方法是这样先确定你给工作记忆的 token 预算比如 4000 token。然后估算平均每轮对话的 token 数中文大概 1 个字 1.5 token一轮用户问 助手答平均 200 字就是 300 token。4000 / 300 ≈ 13 轮。再留点余量给系统提示词和当前输入实际取 10 轮比较稳。但纯滑动窗口有个硬伤它会把重要的早期信息滑出去。比如用户第一轮说了“我要退的是上个月买的那台冰箱”聊到第 15 轮时这条信息早被滑走了助手就不知道退的是哪台。解决办法是引入结构化状态。3.2 结构化状态把关键信息“钉”在工作记忆里我的做法是维护一个 JSON 对象专门存当前任务的关键槽位每轮对话后让模型或规则引擎更新它然后始终注入到 prompt 里不参与滑动。举个例子{ task: 退款处理, order_id: ORD-20241120-8891, product: 冰箱 X200, reason: 制冷异常, collected_fields: [order_id, product, reason], missing_fields: [bank_account], turn_count: 12 }这个对象只有几十个 token但它把“任务进行到哪一步、还缺什么”钉死了。模型每轮都能看到就不会因为滑动窗口把早期信息滑走而失忆。实测下来这一招对任务型对话的提升最明显槽位填充准确率能从 70% 出头拉到 90% 以上。注意结构化状态不要每轮都让大模型重新生成那样又慢又贵还容易漂移。我的做法是规则优先——能从用户输入里正则抽的就正则抽抽不到再让模型补而且只让模型输出“增量更新”而不是全量重写。3.3 工作记忆的存储与过期策略工作记忆我一般放 Rediskey 用session:{session_id}:workingvalue 是序列化后的对话列表 结构化状态。TTL 设 30 分钟到 2 小时看业务。用户半小时没说话会话基本就断了没必要一直占内存。这里有个细节TTL 刷新时机。很多人只在用户发消息时刷新结果用户思考了 40 分钟才回会话已经过期体验很差。我的做法是每次读写都刷新 TTL并且在前端加一个“会话即将过期”的提示让用户知道。另外会话真正结束时用户点“结束咨询”或超时要把工作记忆里的关键信息异步沉淀到长期记忆这一步不能省否则下次用户再来又是从零开始。4. 长期记忆怎么落地检索 写入两条链路4.1 长期记忆存什么、不存什么长期记忆最容易犯的错是“什么都存”。我见过把每一轮对话原文都塞进向量库的项目结果检索出来的全是噪音。长期记忆要存的是经过提炼的事实不是原始对话。我一般存这几类用户画像姓名、等级、注册时间、常用地址。历史事实买过什么、退过什么、投诉过什么每条带时间戳。偏好标签喜欢什么沟通风格、常用语言、对哪些话题敏感。未完成事项上次没处理完的工单、待跟进的问题。不存的东西也很明确闲聊内容、一次性的临时信息、能从其他系统实时查到的数据比如订单状态直接查订单库比存向量库更准。4.2 检索策略向量 关键词 时间衰减长期记忆的读取靠检索。纯向量检索有个问题它对“精确匹配”不敏感。用户问“我上次那个 ORD-8891 的订单”向量检索可能给你捞出一堆语义相近但订单号不对的记录。所以我的方案是混合检索先用关键词/正则抽取查询里的实体订单号、产品名走精确匹配。再用向量检索捞语义相关的记忆。两路结果合并去重按相关性分数 × 时间衰减因子排序。时间衰减因子我一般用exp(-λ * days)λ 取 0.01 到 0.05。意思是越久远的记忆权重越低但不会归零。这样既保证近期记忆优先又不会完全丢掉历史。检索出来的记忆不能全注入要卡预算。我一般给长期记忆留 1000 到 1500 token按分数从高到低截断。注入时用明确的标记包起来比如[长期记忆] - 用户等级VIP22024-03 更新 - 历史订单ORD-8891 冰箱X2002024-11-20 申请退款 [/长期记忆]这样模型能清楚区分“这是背景知识”和“这是当前对话”。4.3 写入链路什么时候写、怎么写长期记忆的写入必须是异步的绝不能卡在主对话链路上。我的做法是会话结束后触发一个后台任务做三件事用模型对整段会话做摘要提炼出事实性信息。对每条事实做去重跟已有记忆比对相似的更新而不是新增。写入数据库 向量库打上时间戳和来源标记。这里有个坑摘要模型的选择。别用主对话那个大模型成本太高。我一般用一个小模型7B 级别专门做摘要效果够用成本能降一个数量级。另外摘要的 prompt 要写死输出格式让它输出结构化的 JSON方便后续解析。实操心得写入时一定要保留“来源会话 ID”这样以后发现某条记忆是错的能追溯回去删掉。我踩过一次坑用户误操作产生了一条错误记忆结果后面每次对话都被检索出来干扰找了半天才定位到。5. 上下文组装把两层记忆拼成最终 prompt5.1 组装顺序和预算分配所有记忆最终都要拼成一个 prompt 送给模型。顺序很重要我一般这么排系统提示词角色、规则、输出格式——固定200 到 500 token。长期记忆检索结果——1000 到 1500 token。结构化状态当前任务槽位——100 到 300 token。工作记忆最近 N 轮对话——剩余预算。当前用户输入——必须完整保留。总预算按模型窗口的 60% 到 70% 来卡留出余量给输出。比如 32K 窗口的模型输入控制在 20K 以内比较稳。这个比例不是拍脑袋是因为输出 token 也要占窗口而且留点余量能应对突发的长输入。5.2 一个真实的组装示例假设用户在第 12 轮说“那退款什么时候到账”组装出来的 prompt 大概长这样[系统] 你是客服助手回答要简洁准确... [长期记忆] - 用户等级VIP2 - 历史订单ORD-8891 冰箱X2002024-11-20 申请退款 [/长期记忆] [当前任务] {task:退款处理,order_id:ORD-8891,missing_fields:[bank_account]} [/当前任务] [对话历史] 用户我要退冰箱 助手好的请提供订单号 ...最近 10 轮 [/对话历史] [当前输入] 那退款什么时候到账模型看到这个结构既知道用户是谁、退的哪单又知道当前缺银行账号回答就不会跑偏。这套组装逻辑我封装成了一个ContextBuilder类输入是 session_id 和当前输入输出是最终 prompt所有对话入口都走它保证一致性。5.3 动态预算调整固定预算在简单场景够用但复杂场景需要动态调。比如用户突然发了一大段文字描述问题工作记忆的预算就得压缩优先保证当前输入完整。我的做法是优先级抢占当前输入 结构化状态 长期记忆 工作记忆。当总预算超了从工作记忆开始砍砍到最近 3 轮为止再超就砍长期记忆里分数最低的。这个逻辑用代码实现就是一个简单的贪心按优先级依次分配每层有最小保留量超了就截断。别搞太复杂实测下来这套贪心足够应对 95% 的场景。6. 常见问题与排查技巧实录6.1 记忆串号最危险也最常见现象A 用户的对话里出现了 B 用户的信息。原因99% 是 session_id 或 user_id 传错或者缓存 key 设计有歧义。排查在 ContextBuilder 入口打日志把 session_id、user_id、检索到的记忆 ID 全打出来对比一下就知道哪串了。预防缓存 key 一定要带 user_id 前缀检索长期记忆时强制带 user_id 过滤条件绝不能只按语义检索。6.2 模型“假装记得”现象用户问“我刚才说的订单号是多少”模型编了一个不存在的订单号。原因工作记忆里那条信息已经被滑走了但模型不知道就硬编。解决在系统提示词里明确写“如果对话历史里没有相关信息直接说不知道不要编造”。另外把结构化状态里的关键字段始终注入能大幅减少这种情况。6.3 长期记忆检索不准现象检索出来的记忆跟当前问题不相关。原因向量模型选得不对或者记忆条目写得太长太模糊。解决记忆条目要短、要具体一条一个事实。向量模型选中文效果好的别用纯英文模型。检索时加个相关性阈值低于阈值的一律不注入宁可少给也别给错。6.4 成本失控现象账单比预期高好几倍。排查顺序先看平均输入 token 数再看长期记忆注入量最后看摘要任务的调用频率。优化工作记忆轮数砍一半、长期记忆预算砍一半、摘要换小模型这三招下去成本一般能降 60% 以上。问题典型原因快速排查解决方向记忆串号key 设计歧义打日志看 session/userkey 带 user 前缀假装记得信息被滑走看工作记忆内容结构化状态常驻检索不准条目太模糊看检索结果条目短而具体成本失控注入太多统计 token砍预算换小模型响应变慢输入太长看首 token 延迟压缩工作记忆6.5 几个独家避坑技巧第一永远给工作记忆设上限哪怕模型窗口再大。我见过有人用 1M 窗口的模型就不设限结果延迟高到用户以为卡死了。第二长期记忆的写入要幂等同一条事实重复写入要能去重否则检索出来一堆重复。第三定期清理长期记忆超过一年没被检索到的记忆可以考虑归档减少检索噪音。第四给记忆加版本号用户信息变更时旧版本标记失效而不是删除方便回溯。7. 我在这套方案上的一些真实体会这套分层方案我在三个项目里跑过最长的已经稳定运行大半年。最大的感受是上下文工程的核心不是技术多复杂而是“克制”。新手总想把所有信息都塞给模型老手知道该给什么、不该给什么。工作记忆和长期记忆的划分本质上就是逼你做这个取舍。另一个体会是别追求一步到位。我第一版就是简单的滑动窗口跑通了再加结构化状态再加长期记忆检索一步步迭代。每加一层都要有明确的收益验证比如加了结构化状态后槽位准确率提升了多少加了长期记忆后用户重复描述问题的比例降了多少。没有数据支撑的优化都是自嗨。最后分享一个小技巧如果你刚开始做可以先只做工作记忆的滑动窗口 结构化状态长期记忆用最简单的“用户画像表”顶上等业务跑起来再上向量检索。这样能最快看到效果也不会一上来就被复杂度劝退。等这套跑顺了你会发现长对话其实没那么难管难的是忍住不把所有东西都塞进去。