1. 这届AI应用为什么都在死磕context-mode做AI应用开发的这半年我踩过最多的坑不是模型选型也不是Prompt怎么写而是context-mode——这个词翻译过来是“上下文模式”但真正做起来远比字面意思复杂。我见过太多人包括我自己一开始都天真地以为把模型能力拉满、把提示词写得天花乱坠应用就能变得聪明。但实际上大模型能看到的输入是有上限的。不管你是接OpenAI的API还是用开源的ChatGLM、Qwen都会碰到一个叫“上下文窗口”的天花板。这个天花板决定了模型一次性能“看到”多少东西决定了它能不能记住你半小时前说的一句话也决定了你的多轮对话会不会聊着聊着就“失忆”。context-mode这个模式本质就是为了解决这个天花板而设计的一套方案。它管理的是哪些历史内容应该保留、哪些应该压缩、哪些应该彻底丢弃、以及如何在不同模式下切换策略保证模型在有限窗口内始终握有最重要的信息。这篇东西不聊虚的我把自己在项目里用过的几种context-mode实现、关键参数怎么调、踩过的坑全部分享出来。适合正在做AI Chat应用、Agent工作流、知识库问答的开发者参考也适合第一次接触上下文管理、想搞明白“为什么我的AI聊天机器聊几句就傻”的新手朋友。2. context-mode的本质是什么一次对“注意力”的物理妥协2.1 为什么上下文窗口是硬天花板先搞清楚一个问题为什么要有context-mode为什么不能把所有的对话历史一股脑全传给模型这涉及到Transformer架构的核心机制——自注意力。简单说模型在生成每一个词的时候都要回头“看”一遍输入序列里的所有词计算它们之间的关联权重。这个计算量的复杂度近似是O(n²)n就是输入序列的长度。也就是说输入长度翻一倍计算量翻四倍输入长度翻两倍计算量不是翻两倍而是直接翻十六倍。这是一个物理性的瓶颈不是某个厂商抠门。即便现在有各种稀疏注意力、线性注意力的优化方法但模型能承载的上下文长度依旧有限。GPT-3.5时代是4K tokenClaude 3早期是200K tokenGoogle Gemini一度做到了1M token。看起来数字在涨但别忘了窗口长了单次调用的成本和延迟也在涨。而且更长的窗口并不意味着更聪明注意力会被稀释模型可能会“看了后面忘了前面”这也是业界常说的“lost in the middle”现象——放在长文正中间的内容模型反而最容易忽略。2.2 context-mode解决的是“记忆经济”问题我个人的理解是context-mode本质上是在做“记忆经济”。就像你没办法把一个图书馆塞进脑子里但你可以提炼出一张张索引卡保证关键时刻能找到对应的书架。在AI应用里这个记忆经济表现为三级结构原始数据层完整对话记录、知识库原文、文档内容体积最大、信息最全。上下文管理层处于原始数据和应用之间的调度逻辑负责筛选、压缩、排序、注入。模型感知层模型真正“看到”的内容经过裁剪之后的最终输入的token序列。context-mode就是中间那一层的实现策略。你的业务不同、场景不同选择的模式就不一样。比如一辆聊天机器人小车它只需要知道“用户刚才说了什么”就能做对当前的回复那用全量对话历史就行。但如果你做一个长期陪伴的情感助手用户上周说“我最近失眠很严重”这周你必须还记得否则用户信任感瞬间垮掉。那你就不能只做滑动窗口你还需要记忆的持久化和优先召回。很多开发者写的所谓“AI应用”本质上就是往API里塞历史消息这不算实现了context-mode。真正常见的context-mode必须是有设计感的什么时候全量携带、什么时候压缩摘要、什么时候从向量库里捞东西、什么时候彻底丢弃——这几个决策点就是整个应用智能水平的分水岭。3. 我在项目中实测的4种context-mode实现3.1 全量上下文最简单也最先翻车全量模式是入门级方案实现上就是维护一个消息列表每次请求把整个列表拼进messages参数发给模型。def build_messages_full(history: list) - list: return [{role: system, content: SYSTEM_PROMPT}] history就这么简单前期demo阶段特别爽。但一旦用户聊起来问题马上暴露。假设平均每轮对话消耗400个token一轮问题一轮回答5轮就是2000token20轮之后就到了8K token如果用的是4K窗口的模型早就爆了。而且我实测下来全量模式还有一个隐性毒点模型不一定会focus你最早的对话内容。你塞进去30轮历史模型往往只记住最后几轮的状态中间被覆盖了。所以作为开发者别以为“模型什么都能看到”就是好事有时候信息太多等于信息冗余。适合场景短期任务型对话比如客服自助查询、单次翻译、代码调试助手这类不依赖太长记忆的场景。一个会话控制在10轮以内全量没问题。3.2 滑动窗口机械但实用的保命方案滑动窗口是目前最实用的压舱石方法几乎每个生产环境都会用到。它的核心逻辑是只保留最近N轮消息更早的直接删掉。MAX_CONTEXT_TURNS 10 def build_messages_sliding(history: list) - list: recent history[-MAX_CONTEXT_TURNS:] return [{role: system, content: SYSTEM_PROMPT}] recent对于大部分应用用户当前关心的事情基本集中在最近几轮。比如问天气、查订单用户不会指望AI记得他上周查过什么。滑动窗口能保证每次请求的token数量可控延迟和成本都比较稳定。但这个方案有明显短板——它对“连续性记忆”零容忍。用户两周前让你每天帮他推荐一个学习英语的App今天又问“上次说的那个App叫什么名字”滑动窗口早就把两周前的记录冲掉了AI只能一脸茫然。这就引出一个经验滑动窗口是做地基但地基本身不能解决记忆持久性问题它只解决“近因优先”的短期交互。做真实的长期记忆产品还要往上层加东西。3.3 摘要压缩把对话“压扁”成记忆卡片摘要模式的核心思路是不保留全部历史而是定期让模型把已经滚出滑动窗口的内容提炼成一段摘要。这样做的好处是长对话的早期信息不会彻底丢失而是以高度浓缩的形式继续存活在上下文里。我自己的实现大概是这样的设定一个水位线比如当历史消息总数超过20轮就触发摘要。每10轮用一次模型调用把“当前摘要 最近10轮详情”压缩成新的摘要。最终每次请求的上下文结构是system: 你是知识助手以下是这段对话的历史摘要 {historical_summary} {system_prompt} user: 今天最新的问题这个方案的成本要注意每10轮触发一次摘要每次摘要调用大约消耗500-800token。如果用户一天聊200轮摘要触发了20次额外消耗的token差不就是1万-1.6万不便宜。但换来的是长达数百轮对话的连续性记忆很多产品场景下是值得的。3.4 向量检索把记忆交给“编年史档案馆”向量检索模式是我目前最看好的context-mode实现也是做知识库问答的标配做法。它的思路也很清晰每一条历史消息或文档切片先通过嵌入模型转成一个高维向量存进向量数据库我项目里用的是chroma。每次用户发起提问把用户的问题也转成向量在向量库里做相似度检索找出最相关的Top-K记录然后拼到当前上下文里喂给模型。import chromadb client chromadb.PersistentClient(path./memory_store) col client.get_or_create_collection(chat_memory) # 存储记忆 col.add( ids[fmsg_{msg_id}], embeddings[embedding_model.encode(content).tolist()], documents[content], metadatas[{timestamp: timestamp, session_id: session_id}] ) # 检索召回 results col.query( query_embeddings[embedding_model.encode(user_question).tolist()], n_results5, where{session_id: session_id} )这里面有几个坑要提前说。第一相似度检索不等于语义理解用户问“那本书叫什么”如果你只做过字面向量匹配很可能召回不到“推荐过的《原子习惯》”这条记录。所以有条件的话可以在检索前加一层意图改写比如把笼统的代词“那个”“它”“上次说的”替换成具体的实体词。第二召回结果不要直接一股脑塞给模型最好设定一个最低相关性阈值低于阈值的记录直接过滤不然反而给模型添乱。向量检索模式最适配的是知识库问答和长期记忆Agent这类场景几乎每个以“长时间陪伴”“跨会话记忆”为核心卖点的产品底层都逃不开这套设计。3.5 分层混合我实测下来最稳的生产级方案不要以为上面四种模式是非此即彼的。我目前生产环境里跑的最稳的其实是“滑动窗口摘要向量检索”三层组合的模式。我把它叫做“分层记忆调度”。工作流程是第一层滑动窗口兜底总是携带最近8轮消息保证近因连续性。第二层超过8轮的历史消息每满15轮触发一次摘要压缩最新摘要永远保留在上下文中。第三层每天对话结束后把当天的关键信息做关键词抽取、向量化存入长期记忆库。每次新对话启动时先在长期记忆库里检索与当前主题相关的历史信息拼到上下文中。这三个层级解决的是不同的时间尺度问题滑动窗口管“秒到分钟级”的即时对话摘要管“小时到天级”的中期记忆向量库管“周到月级”的长期记忆。现实中我观察到的效果是多层存储比单一方案在长会话场景下稳定得多用户体验的“断片感”明显下降。4. context-mode的实操配置与参数调优心得4.1 怎样设定你的上下文预算很多教程教Parameter Tuning讲模型参数、temperature等等。但很少有人教你如何规划上下文预算。我自己的经验是在上线之前先画一张“token预算表”避免上线之后因为上下文超限而手忙脚乱。实操中我是这样定义的假设使用4K窗口的模型4096 token则系统提示词预留 600 token。滑动窗口预留 1600 token最近8轮每轮约200 token。摘要缓冲 400 token。向量检索召回拼装 800 token。模型输出预留 700 token。加起来是4100 token刚好控制在4096以内。如果你的模型窗口更大比如8K或32K比例可以调整但原则不变给输入分配的空间必须留出余量不要写到100%满。我自己吃过亏有一次正好把所有token都用满了结果那句话多了一个空格请求直接400报错。现在我的习惯是每一项预留10%-20%的buffer。4.2 摘要触发的时机别让摘要本身成为开销黑洞摘要模式最容易被忽视的问题是触发频率。触发太频繁模型一直在干“总结”这件事成本爆炸触发太稀疏早期信息遗失过多摘要质量也没保障。我调试下来一个相对合理的策略是用对话轮数时间戳双条件触发。假设一组对话每10轮或每过30分钟触发一次摘要谁先到就先执行。在用户连续提问的高频场景中轮数触发优先在用户分时段断续聊的场景中时间戳触发优先。两种触发条件互补体验上更平滑。还有一个细节摘要生成时不要把全部对话历史一股脑全塞进去。最好分段生成第一次先总结前半段第二次再总结后半段再合并。实测这个方法比一次性长文本总结的效果好不少长文摘要的遗忘率会明显降低。核心原因在于摘要模型本身也受上下文窗口限制塞得越多越容易丢关键信息。4.3 向量检索的TOP-K怎么选不要拍脑袋向量检索里面有个很经典的“K值玄学”。K太小召回的上下文太少模型缺上下文信息K太大噪音记录混进来反而拉低回答质量。我的经验是从K5开始调观察两点——召回结果的语义相关性和问答准确率。如果问答经常出现“模型答非所问”先检查K是不是太小如果回答里频繁出现上下文矛盾比如模型同时引用了两个互相冲突的信息多半是K太大混入了不相关的内容。目前大部分场景下K3到K8是比较稳妥的区间。需要特别注意Top-K的结果在拼装进prompt时应该按时间从旧到新排列而不是按相似度从高到低排列。这是很多新手容易踩的坑。模型阅读习惯于连贯叙事如果把最相似的记录放在最前面中间突然跳转到一条时间更早但相关性次之的记录模型理解起来容易混乱。我一般把召回结果先按时间戳排序再拼进上下文实测效果稳定很多。5. 常见问题排障实录context-mode翻车现场5.1 症状一模型有时“忘记”用户早期的关键需求典型场景用户第一天让AI规划了一个培训计划第二周回来说“继续我们的计划”AI完全不知道计划是什么。排查步骤先看请求日志里携带的上下文历史确认早期对话是否还在。如果没在说明滑动窗口冲掉了。检查摘要机制是否触发。如果根本没实现摘要/向量库那“失忆”是必然的。确认向量检索的召回是否包含早期会话记录。如果向量库只存了“当天”的记录跨天回忆会失败。修复建议把长期记忆的写入逻辑从“当天对话结束”改成“每轮对话都异步写入”并给每条记忆打上session_id时间戳。检索时不要只按当前session_id干查还要允许跨session召回相关度高的历史记录。5.2 症状二回答质量越来越差明显“变傻”很多人以为是模型抽风其实往往是上下文被污染了。我把这类问题统称为“上下文污染”。污染的表现形式包括历史消息里的错误信息被当成事实反复引用模型模仿了历史消息里的坏语气某条过长的历史信息占据了上下文的大半空间挤压了当前有效信息的比例。这时候用我前文提到的“记忆经济”思维来排队先砍掉最不重要的部分。优先检查是不是摘要有错误——摘要模型有时候会把用户的情绪表达总结成“用户不满”然后后续对话中模型就会以用户不满为前提去回复越回越拧巴。5.3 症状四明明用了向量检索为什么还是答非所问其实是K值和文本切片的问题 
长河君 · 2026/10/29 23:56:02 · 阅读 1.2k AI应用上下文管理：从滑动窗口到向量检索的context-mode实战
1. 这届AI应用为什么都在死磕context-mode做AI应用开发的这半年我踩过最多的坑不是模型选型也不是Prompt怎么写而是context-mode——这个词翻译过来是“上下文模式”但真正做起来远比字面意思复杂。我见过太多人包括我自己一开始都天真地以为把模型能力拉满、把提示词写得天花乱坠应用就能变得聪明。但实际上大模型能看到的输入是有上限的。不管你是接OpenAI的API还是用开源的ChatGLM、Qwen都会碰到一个叫“上下文窗口”的天花板。这个天花板决定了模型一次性能“看到”多少东西决定了它能不能记住你半小时前说的一句话也决定了你的多轮对话会不会聊着聊着就“失忆”。context-mode这个模式本质就是为了解决这个天花板而设计的一套方案。它管理的是哪些历史内容应该保留、哪些应该压缩、哪些应该彻底丢弃、以及如何在不同模式下切换策略保证模型在有限窗口内始终握有最重要的信息。这篇东西不聊虚的我把自己在项目里用过的几种context-mode实现、关键参数怎么调、踩过的坑全部分享出来。适合正在做AI Chat应用、Agent工作流、知识库问答的开发者参考也适合第一次接触上下文管理、想搞明白“为什么我的AI聊天机器聊几句就傻”的新手朋友。2. context-mode的本质是什么一次对“注意力”的物理妥协2.1 为什么上下文窗口是硬天花板先搞清楚一个问题为什么要有context-mode为什么不能把所有的对话历史一股脑全传给模型这涉及到Transformer架构的核心机制——自注意力。简单说模型在生成每一个词的时候都要回头“看”一遍输入序列里的所有词计算它们之间的关联权重。这个计算量的复杂度近似是O(n²)n就是输入序列的长度。也就是说输入长度翻一倍计算量翻四倍输入长度翻两倍计算量不是翻两倍而是直接翻十六倍。这是一个物理性的瓶颈不是某个厂商抠门。即便现在有各种稀疏注意力、线性注意力的优化方法但模型能承载的上下文长度依旧有限。GPT-3.5时代是4K tokenClaude 3早期是200K tokenGoogle Gemini一度做到了1M token。看起来数字在涨但别忘了窗口长了单次调用的成本和延迟也在涨。而且更长的窗口并不意味着更聪明注意力会被稀释模型可能会“看了后面忘了前面”这也是业界常说的“lost in the middle”现象——放在长文正中间的内容模型反而最容易忽略。2.2 context-mode解决的是“记忆经济”问题我个人的理解是context-mode本质上是在做“记忆经济”。就像你没办法把一个图书馆塞进脑子里但你可以提炼出一张张索引卡保证关键时刻能找到对应的书架。在AI应用里这个记忆经济表现为三级结构原始数据层完整对话记录、知识库原文、文档内容体积最大、信息最全。上下文管理层处于原始数据和应用之间的调度逻辑负责筛选、压缩、排序、注入。模型感知层模型真正“看到”的内容经过裁剪之后的最终输入的token序列。context-mode就是中间那一层的实现策略。你的业务不同、场景不同选择的模式就不一样。比如一辆聊天机器人小车它只需要知道“用户刚才说了什么”就能做对当前的回复那用全量对话历史就行。但如果你做一个长期陪伴的情感助手用户上周说“我最近失眠很严重”这周你必须还记得否则用户信任感瞬间垮掉。那你就不能只做滑动窗口你还需要记忆的持久化和优先召回。很多开发者写的所谓“AI应用”本质上就是往API里塞历史消息这不算实现了context-mode。真正常见的context-mode必须是有设计感的什么时候全量携带、什么时候压缩摘要、什么时候从向量库里捞东西、什么时候彻底丢弃——这几个决策点就是整个应用智能水平的分水岭。3. 我在项目中实测的4种context-mode实现3.1 全量上下文最简单也最先翻车全量模式是入门级方案实现上就是维护一个消息列表每次请求把整个列表拼进messages参数发给模型。def build_messages_full(history: list) - list: return [{role: system, content: SYSTEM_PROMPT}] history就这么简单前期demo阶段特别爽。但一旦用户聊起来问题马上暴露。假设平均每轮对话消耗400个token一轮问题一轮回答5轮就是2000token20轮之后就到了8K token如果用的是4K窗口的模型早就爆了。而且我实测下来全量模式还有一个隐性毒点模型不一定会focus你最早的对话内容。你塞进去30轮历史模型往往只记住最后几轮的状态中间被覆盖了。所以作为开发者别以为“模型什么都能看到”就是好事有时候信息太多等于信息冗余。适合场景短期任务型对话比如客服自助查询、单次翻译、代码调试助手这类不依赖太长记忆的场景。一个会话控制在10轮以内全量没问题。3.2 滑动窗口机械但实用的保命方案滑动窗口是目前最实用的压舱石方法几乎每个生产环境都会用到。它的核心逻辑是只保留最近N轮消息更早的直接删掉。MAX_CONTEXT_TURNS 10 def build_messages_sliding(history: list) - list: recent history[-MAX_CONTEXT_TURNS:] return [{role: system, content: SYSTEM_PROMPT}] recent对于大部分应用用户当前关心的事情基本集中在最近几轮。比如问天气、查订单用户不会指望AI记得他上周查过什么。滑动窗口能保证每次请求的token数量可控延迟和成本都比较稳定。但这个方案有明显短板——它对“连续性记忆”零容忍。用户两周前让你每天帮他推荐一个学习英语的App今天又问“上次说的那个App叫什么名字”滑动窗口早就把两周前的记录冲掉了AI只能一脸茫然。这就引出一个经验滑动窗口是做地基但地基本身不能解决记忆持久性问题它只解决“近因优先”的短期交互。做真实的长期记忆产品还要往上层加东西。3.3 摘要压缩把对话“压扁”成记忆卡片摘要模式的核心思路是不保留全部历史而是定期让模型把已经滚出滑动窗口的内容提炼成一段摘要。这样做的好处是长对话的早期信息不会彻底丢失而是以高度浓缩的形式继续存活在上下文里。我自己的实现大概是这样的设定一个水位线比如当历史消息总数超过20轮就触发摘要。每10轮用一次模型调用把“当前摘要 最近10轮详情”压缩成新的摘要。最终每次请求的上下文结构是system: 你是知识助手以下是这段对话的历史摘要 {historical_summary} {system_prompt} user: 今天最新的问题这个方案的成本要注意每10轮触发一次摘要每次摘要调用大约消耗500-800token。如果用户一天聊200轮摘要触发了20次额外消耗的token差不就是1万-1.6万不便宜。但换来的是长达数百轮对话的连续性记忆很多产品场景下是值得的。3.4 向量检索把记忆交给“编年史档案馆”向量检索模式是我目前最看好的context-mode实现也是做知识库问答的标配做法。它的思路也很清晰每一条历史消息或文档切片先通过嵌入模型转成一个高维向量存进向量数据库我项目里用的是chroma。每次用户发起提问把用户的问题也转成向量在向量库里做相似度检索找出最相关的Top-K记录然后拼到当前上下文里喂给模型。import chromadb client chromadb.PersistentClient(path./memory_store) col client.get_or_create_collection(chat_memory) # 存储记忆 col.add( ids[fmsg_{msg_id}], embeddings[embedding_model.encode(content).tolist()], documents[content], metadatas[{timestamp: timestamp, session_id: session_id}] ) # 检索召回 results col.query( query_embeddings[embedding_model.encode(user_question).tolist()], n_results5, where{session_id: session_id} )这里面有几个坑要提前说。第一相似度检索不等于语义理解用户问“那本书叫什么”如果你只做过字面向量匹配很可能召回不到“推荐过的《原子习惯》”这条记录。所以有条件的话可以在检索前加一层意图改写比如把笼统的代词“那个”“它”“上次说的”替换成具体的实体词。第二召回结果不要直接一股脑塞给模型最好设定一个最低相关性阈值低于阈值的记录直接过滤不然反而给模型添乱。向量检索模式最适配的是知识库问答和长期记忆Agent这类场景几乎每个以“长时间陪伴”“跨会话记忆”为核心卖点的产品底层都逃不开这套设计。3.5 分层混合我实测下来最稳的生产级方案不要以为上面四种模式是非此即彼的。我目前生产环境里跑的最稳的其实是“滑动窗口摘要向量检索”三层组合的模式。我把它叫做“分层记忆调度”。工作流程是第一层滑动窗口兜底总是携带最近8轮消息保证近因连续性。第二层超过8轮的历史消息每满15轮触发一次摘要压缩最新摘要永远保留在上下文中。第三层每天对话结束后把当天的关键信息做关键词抽取、向量化存入长期记忆库。每次新对话启动时先在长期记忆库里检索与当前主题相关的历史信息拼到上下文中。这三个层级解决的是不同的时间尺度问题滑动窗口管“秒到分钟级”的即时对话摘要管“小时到天级”的中期记忆向量库管“周到月级”的长期记忆。现实中我观察到的效果是多层存储比单一方案在长会话场景下稳定得多用户体验的“断片感”明显下降。4. context-mode的实操配置与参数调优心得4.1 怎样设定你的上下文预算很多教程教Parameter Tuning讲模型参数、temperature等等。但很少有人教你如何规划上下文预算。我自己的经验是在上线之前先画一张“token预算表”避免上线之后因为上下文超限而手忙脚乱。实操中我是这样定义的假设使用4K窗口的模型4096 token则系统提示词预留 600 token。滑动窗口预留 1600 token最近8轮每轮约200 token。摘要缓冲 400 token。向量检索召回拼装 800 token。模型输出预留 700 token。加起来是4100 token刚好控制在4096以内。如果你的模型窗口更大比如8K或32K比例可以调整但原则不变给输入分配的空间必须留出余量不要写到100%满。我自己吃过亏有一次正好把所有token都用满了结果那句话多了一个空格请求直接400报错。现在我的习惯是每一项预留10%-20%的buffer。4.2 摘要触发的时机别让摘要本身成为开销黑洞摘要模式最容易被忽视的问题是触发频率。触发太频繁模型一直在干“总结”这件事成本爆炸触发太稀疏早期信息遗失过多摘要质量也没保障。我调试下来一个相对合理的策略是用对话轮数时间戳双条件触发。假设一组对话每10轮或每过30分钟触发一次摘要谁先到就先执行。在用户连续提问的高频场景中轮数触发优先在用户分时段断续聊的场景中时间戳触发优先。两种触发条件互补体验上更平滑。还有一个细节摘要生成时不要把全部对话历史一股脑全塞进去。最好分段生成第一次先总结前半段第二次再总结后半段再合并。实测这个方法比一次性长文本总结的效果好不少长文摘要的遗忘率会明显降低。核心原因在于摘要模型本身也受上下文窗口限制塞得越多越容易丢关键信息。4.3 向量检索的TOP-K怎么选不要拍脑袋向量检索里面有个很经典的“K值玄学”。K太小召回的上下文太少模型缺上下文信息K太大噪音记录混进来反而拉低回答质量。我的经验是从K5开始调观察两点——召回结果的语义相关性和问答准确率。如果问答经常出现“模型答非所问”先检查K是不是太小如果回答里频繁出现上下文矛盾比如模型同时引用了两个互相冲突的信息多半是K太大混入了不相关的内容。目前大部分场景下K3到K8是比较稳妥的区间。需要特别注意Top-K的结果在拼装进prompt时应该按时间从旧到新排列而不是按相似度从高到低排列。这是很多新手容易踩的坑。模型阅读习惯于连贯叙事如果把最相似的记录放在最前面中间突然跳转到一条时间更早但相关性次之的记录模型理解起来容易混乱。我一般把召回结果先按时间戳排序再拼进上下文实测效果稳定很多。5. 常见问题排障实录context-mode翻车现场5.1 症状一模型有时“忘记”用户早期的关键需求典型场景用户第一天让AI规划了一个培训计划第二周回来说“继续我们的计划”AI完全不知道计划是什么。排查步骤先看请求日志里携带的上下文历史确认早期对话是否还在。如果没在说明滑动窗口冲掉了。检查摘要机制是否触发。如果根本没实现摘要/向量库那“失忆”是必然的。确认向量检索的召回是否包含早期会话记录。如果向量库只存了“当天”的记录跨天回忆会失败。修复建议把长期记忆的写入逻辑从“当天对话结束”改成“每轮对话都异步写入”并给每条记忆打上session_id时间戳。检索时不要只按当前session_id干查还要允许跨session召回相关度高的历史记录。5.2 症状二回答质量越来越差明显“变傻”很多人以为是模型抽风其实往往是上下文被污染了。我把这类问题统称为“上下文污染”。污染的表现形式包括历史消息里的错误信息被当成事实反复引用模型模仿了历史消息里的坏语气某条过长的历史信息占据了上下文的大半空间挤压了当前有效信息的比例。这时候用我前文提到的“记忆经济”思维来排队先砍掉最不重要的部分。优先检查是不是摘要有错误——摘要模型有时候会把用户的情绪表达总结成“用户不满”然后后续对话中模型就会以用户不满为前提去回复越回越拧巴。5.3 症状四明明用了向量检索为什么还是答非所问其实是K值和文本切片的问题