AI客服智能体上一句刚说的订单号，下一句就接不上，2026年问题多半出在哪？

结论前置：AI客服智能体聊到第三轮就接不上订单号，2026年多数项目不是模型变笨，而是会话状态没接住：会话ID不稳定、只传当前一轮、摘要把数字压掉、槽位没落库。先按「会话ID—窗口—摘要—槽位」查一遍，再决定要不要加向量库；直接上RAG常把成本抬上去，却仍然答不准。

为什么2026年智能体还在丢上下文

大模型本身无状态，每次请求对它都是新对话。对话系统要自己把历史消息、用户身份和关键实体在请求之间传下去。2026年常见载体有网页、小程序、APP和H5，不同载体请求方式不同：小程序页面跳转可能重新初始化，APP可能多端登录，H5可能被浏览器回收。只要会话ID没有稳定贯穿请求，后端取不到历史，智能体就会像第一次见用户。

• 模型无状态：上下文靠应用层拼装，不靠模型自己记住。
• 载体差异：小程序、APP、H5会话保持能力不同，需要统一封装。
• 成本约束：历史不能无限塞入，要在窗口和摘要之间取舍。

先分清：会话记忆和长期知识不是一回事

用户说「刚才那个订单改地址」，这是会话记忆；用户问「退货政策几天」，这是长期知识。两者混在一起，就会出现把当前对话拿去向量库搜，或把旧文档当成当前答案。判断方法：看用户是否在指代本轮或近期对话里出现过的信息。

会话记忆放在会话表、缓存或上下文里，长期知识才适合进向量库。分开后，排查时能快速定位是编排问题还是检索问题，而不是一上来就换模型或加库。

• 会话记忆：近几轮消息、刚说的订单号、当前意图、临时偏好。
• 长期知识：产品手册、FAQ、政策条款、跨用户共用知识。
• 常见误判：用户说「它」「上面那个」，却去向量库检索，搜出一堆无关文档。

排查顺序：会话ID、窗口、摘要与槽位

项目交付里，可把会话记忆拆成三层：即时窗口、会话摘要、事实槽位。近几轮原文最准但占token，摘要省token但会丢细节，槽位最稳但只覆盖结构化信息。谁出问题就查谁。

1. 即时窗口：保留近5到10轮原文，按token预算动态截断，不要只按轮数截。
2. 会话摘要：超出窗口后做滚动摘要，摘要要保留数字、订单号、否定词和时间；模板尽量固定。
3. 事实槽位：把用户身份、订单号、地址、偏好抽成结构化字段落库，用户改口后以新值为准。
4. 长期知识：只有跨会话、跨用户的通用知识才进向量库，并加版本过滤。

排查顺序建议：先查会话ID是否稳定，再查窗口是否只传当前轮，再查摘要和槽位有没有丢关键实体。这个顺序能把改动控制在较小范围。

• 查会话ID：前端每次请求是否新建ID？后端是否用同一ID取历史？
• 查窗口：是否只传当前一句？窗口是否按token而不是按轮数？
• 查摘要与槽位：摘要是否丢数字和否定？槽位是否落库、可更新？

加向量库和改会话编排，成本与周期差多少

这两件事常被混为一谈。改会话编排是修记忆链路，加向量库是补知识检索能力，解决的问题不同。2026年项目交付里，如果用户只是抱怨刚说的就忘，先做会话编排通常更快见效；如果问的是文档里才有的政策细节，才需要把向量库排上日程。

• 改会话编排：周期常见区间约3到10个工作日；成本主要是开发人力，云成本增加有限；适合指代失败、多轮断片、槽位丢失。
• 加向量库：周期常见区间约2到6周；需要嵌入模型、向量库、切分与检索调优；月度云成本常见区间约几百到几千元；适合文档量大、知识问答占比高的场景。
• 两者结合：适合既要多轮记忆又要知识检索的客服、导购类智能体；顺序建议先编排后检索，避免检索层掩盖记忆层问题。

判断标准可以用一个简单测试：用户说「刚才那个订单」，系统答不上来，先查会话记忆；用户说「退货要几天」，答错，先查知识库版本和检索。把两类问题分开统计，才知道预算花在哪。

适用与不适用边界

不是所有AI智能体都需要完整记忆体系。单轮问答、翻译、OCR识别、批量摘要，每次请求本身独立，强行加会话表反而增加复杂度。低频内部工具用简单窗口加会话ID就够，不必上向量库。

• 适合做会话记忆：客服、售后、导购、教育答疑、订票改签等需要多轮指代和状态延续的场景。
• 适合加向量库：产品文档多、政策更新频繁、知识问答占比高、跨用户共用答案的场景。
• 不必上记忆库：单轮工具、翻译、图像识别、固定FAQ、一次性任务，以及使用频率很低的内部小工具。
• 边界提醒：用户问题里没有指代、没有状态延续，加记忆层只会抬高token成本，不提升答案质量。

交付现场：两周约束下先修哪一层

在项目里常见一种情况：预算有限、周期压到两周、素材只有一份FAQ，用户常卡在「刚才那个订单，智能体答非所问」。做法是先把会话ID统一、加滑动窗口和事实槽位，不急着买向量库。代价是前端要改请求封装、后端加一张会话表，返工常见区间约两到三天；但省掉了向量库调优的两三周和每月一笔云成本，上线后回指类问题明显减少。

验收不要只看「聊得像不像人」，要看可复现测试。回指测试让用户说「它」「刚才那个」，看能否指到正确对象；槽位断点测试是中间插入无关话题，再回来问之前的信息，看槽位有没有被冲掉。这些测试能在上线前暴露大部分记忆问题。

• 每次请求新建会话ID：历史全丢，用户感觉智能体失忆。
• 只传当前一轮：模型看不到上文，指代容易失败。
• 摘要太激进：数字、订单号、否定词被压掉，答案自然错。
• 向量库没版本过滤：旧文档被召回，答出已下线政策。
• 无脑塞历史：token成本上升，响应变慢，还可能被无关内容干扰。

验收口径可以设为：五轮以内关键实体留存达到常见区间九成左右，回指测试通过，单轮token消耗控制在预算区间内。做不到就先修编排，而不是继续调提示词。

常见问题

AI智能体的记忆和向量库是一回事吗？

不是。记忆管当前会话里发生过什么，向量库管跨用户共用的长期知识。混用会导致指代问题查错方向，也会让旧文档污染当前对话。

多轮对话保留几轮上下文比较合适？

常见做法是保留近5到10轮原文，再叠加摘要和槽位；具体轮数按token预算调整，长消息多时少留，短消息多时可多留。

会话ID不稳定会有什么后果？

每次请求都会被后端当成新用户，历史消息取不到，智能体表现像失忆。先看前端请求是否复用同一个会话ID，再看后端有没有按它取历史。

智能体记不住用户偏好，只存全部聊天记录行吗？

不一定划算。把偏好抽成结构化槽位，比如语言、尺码、常用地址，落库后按需注入，通常比每次塞全量聊天记录更省token，也更稳定。

加了向量库以后，智能体反而答出别的产品，怎么回事？

常见原因是知识库没做版本过滤和产品线隔离，旧文档或无关文档被检索进来。先给文档打版本、产品线和生效时间标签，再限制检索范围。

如果智能体是客服、导购或工具型对话，先按「会话ID—窗口—摘要—槽位」排查，再评估向量库；单轮问答、翻译或低频内部工具不必上记忆库。上线前用回指测试和槽位断点测试验收，并按官方文档核对所用模型的上下文长度与计费口径，避免把记忆问题和知识问题混在一起花钱。