做AI助手和大模型应用开发这段时间最折磨人的往往不是模型选型也不是prompt润色而是上下文。同一个模型、同样一套提示词上下文管理做得好与不好效果能差出一大截。最近在各个AI开发群里被反复提起的context-mode本质上就是围绕“上下文如何存储、压缩、召回和注入”的一套工程化打法。这篇文章我会把我实际项目里落地的一套Context Mode方案完整拆开涵盖分层记忆、摘要压缩、检索注入、token预算分配和踩坑记录适合正在做AI助手、知识库问答、Agent任务链的同学参考。不保证最高级但保证可以直接照着改。1. Context Mode到底在解决什么先理解上下文痛点1.1 为什么“多轮对话”总是答非所问很多刚接大模型API的同学会有一个错觉模型是“记得住”之前的对话的。实际上LLM是个无状态函数它每次生成时看到的只有你塞进上下文窗口的token序列。所谓多轮对话不过是把历史消息原样拼接再丢给它。这个机制带来三个典型痛点。第一个痛点是有效信息密度太低。用户连续聊了半小时里面有寒暄、有重复表述、有中途改主意这些噪声全部进入上下文之后模型注意力被分散越往后越容易出现答非所问。我做过一个客服助手前5轮回答质量很高到第9轮时它突然开始引用第2轮已经被用户否定的方案就是典型的上下文噪声干扰。第二个痛点是窗口有硬上限。常见的上下文窗口是32K、64K、128K token看起来很大但如果是代码文件、长文档、日志分析这类场景一次调用就能吃掉大半窗口。对话还没进行几轮窗口满了要么强制截断最前面的内容要么直接报错整个过程体验非常割裂。第三个痛点是检索和注入脱节。很多方案嘴上说“我有RAG”实际操作却是把搜索到的内容一股脑塞进system prompt不管相不相关。搜索返回5000字就塞5000字结果核心指令被挤到几乎看不到的位置模型行为自然不稳定。我见过太多团队把精力花在选模型、调prompt上却对上下文管理几乎没有任何设计。而context-mode这个思路就是把上下文当成系统里一等公民的资源定义清楚谁写、谁读、何时压缩、何时丢弃。它解决的并不是单点故障而是整套对话系统的可持续性。1.2 不同场景下的上下文分类落地Context Mode之前必须先弄清自己服务的场景最看重哪种上下文类型。我一般把使用场景分成三大类每一类的侧重完全不同。场景类型典型应用上下文重点常见失效方式Context Mode核心动作对话助手客服、陪伴、闲聊最近几轮一致性、用户偏好历史噪声稀释当前意图短时原文窗口 摘要记忆知识库问答RAG、企业搜索、文档问答检索相关性、引用准确性召回内容语义偏离分层检索 重排后注入Agent任务链代码生成、多步工具调用任务进度、中间结果、依赖状态状态断裂、重复操作结构化工作记忆 快照对话助手最怕的是“忘记刚才说过的偏好”。用户在第3轮说“我不吃辣”第10轮却推荐了辣菜这属于短时一致性没做好。知识库问答最怕的是检索回来的内容看似相关实际对当前问题毫无帮助这属于召回精度问题。Agent任务链最怕的是前面工具调用产生的中间状态丢失比如第1步拿到了一个用户ID第5步要用的时候模型已经完全“不知道”这个ID从哪来的。context-mode对不同场景的处理并不一样。对话助手更适合保留最近N轮原文加上滚动摘要。知识库问答则应该把system prompt里的静态知识拿掉换成动态检索注入。Agent任务链必须有显式的状态管理用结构化JSON记录step、变量、依赖关系而不是靠模型在自然语言里“回忆”。很多人一上来就套一套通用方案结果哪个场景都没做好。正确的做法是先明确自己属于哪一类再决定上下文分层策略。2. 上下文模式的核心设计记忆分层与状态管理2.1 短时上下文、工作上下文与长期记忆的划分做Context Mode时我最先做的一件事就是把“上下文”拆成三层而不是让所有信息挤在同一条历史消息队列里。这三层我用一个比喻帮助团队理解工作台、笔记本和档案室。短时上下文对应的是工作台面上的东西就是最近几轮对话原文。这类信息要求高保真、低延迟直接进入模型的context窗口一般保留最近6到10轮。它负责保证当前对话的自然衔接比如用户上一句提了一个名词这一句用“它”来指代模型能正确解析。工作上下文对应笔记本里的记录。这是当前任务进行中产生的中间状态比如“正在读取的文件名”“已经确认的字段列表”“用户最后选择的方案”。这类信息通常用结构化形式保存比如JSON数组或键值对而不是自然语言段落。它会在每次请求时注入但只注入需要的那一部分。长期记忆对应档案室。比如用户的长期偏好、项目历史背景、过去对话中沉淀下来的结论。这类信息不进每次请求而是先做切块、向量化存到检索系统里等下次任务需要时临时取回。取回的方式是语义检索不是全量注入。我把这三层的存储职责画得很清楚短时上下文只存在于运行时内存工作上下文放在会话状态对象里长期记忆落到向量数据库。很多失败的AI应用问题就出在把长期记忆当成短时上下文用每次请求把用户所有历史记录全塞进去很快token就爆了而且模型还抓不住重点。2.2 上下文压缩摘要化、结构化、向量化三层在Context Mode里压缩不是“删东西”而是把原始信息转换成更经济的形式。我通常做三层压缩。第一层是摘要化。当对话超过保留轮数之后最老的那部分原文不再直接进入上下文而是交给LLM生成一段滚动摘要。比如用户前面聊了10轮配置服务器的过程摘要写成“用户已完成nginx安装确认使用8080端口尚未配置SSL证书”。这段摘要替代原始对话参与后续推理信息丢失可控token占用大幅下降。第二层是结构化。摘要仍然有不确定性所以对于关键状态我会额外抽成结构化字段。比如“端口8080”“SSL未完成”以JSON形式存进工作上下文。这样后面无论模型怎么发挥关键变量始终在显式状态里。自然语言摘要给模型“理解力”结构化字段给系统“确定性”两者配合而不是互相替代。第三层是向量化。这是给长期记忆用的。历史对话清洗之后切成固定大小的文本块每块通过embedding模型转成向量。查询时把当前问题也转成向量计算相似度取回TopK。向量化解决的是“语义相关”的检索问题传统关键词搜索很难匹配“帮我弄一下上次说的那个证书”这种说法但向量检索可以。三层各司其职但真正落地时要注意顺序。摘要化和结构化必须在对话进行的实时链路里做向量化则可以异步做。我实际项目里是把摘要生成放进对话流程中把向量化放到后台队列这样不阻塞主响应链路。2.3 上下文注入策略哪些内容该进、哪些不该进Context Mode最关键的设计不是“存了什么”而是“每次请求注入了什么”。站在模型视角注入内容就是它的全部记忆。所以注入策略的优先级必须明确我已经沉淀出一套顺序。优先级从高到低是当前任务指令 工作上下文关键变量 短时对话提取摘要 长期记忆检索片段。当前任务指令是核心比如“请根据用户上传的文件生成周报”这类内容必须完整、不能被压缩。工作上下文关键变量是可控状态能保真就保真。短时对话的原文轮次一旦超过预算就换成摘要。长期记忆检索片段是锦上添花相关才注入不相关宁可不注入。与优先级配套的是几个“该不该进”的判断原则。原文历史只保留最近N轮超过部分的原文永远不进上下文只留摘要。已经在之前对话里确认过的内容在当前轮里如果再次出现不需要重复注入。检索回来的片段如果相似度低于阈值直接丢弃。系统内置的知识、说明文档这类静态内容不要每次都塞应该放到检索库里按需取用。这里有一个常见的反面案例很多人做知识库问答时把全部产品手册都烧进system prompt结果上下文窗口全被静态知识占满用户真正的问题反而得不到足够的注意力权重。把静态内容拿出来做检索把动态结果按需注入这才是Context Mode的正确姿势。3. 实操从零搭建一个Context Mode模块3.1 确定会话状态结构与存储方案理论讲完直接进入能落地的部分。我先定义一份会话状态结构这是Context Mode的“地基”。我的做法是让这份结构同时承担短时上下文和工作上下文的存储职责。{ session_id: chat_8f3a9c, created_at: 2025-01-12T10:00:00Z, updated_at: 2025-01-12T10:32:10Z, short_term: [ {role: user, content: 帮我把接口超时时间调大一点}, {role: assistant, content: 当前的超时时间配置在client.yaml默认是3秒需要改成多少} ], work_context: { current_file: client.yaml, confirmed_changes: [timeout: 3s - 10s], pending_steps: [修改配置后重启服务] }, summary: 用户正在处理微服务客户端配置主要诉求是调大接口超时时间。, memory_refs: [memory_8831, memory_9927] }短时间short_term里放最近几轮原文超过轮数后把最老的移到summary里。work_context是结构化状态比自然语言描述更可靠。memory_refs是长期记忆的ID列表模型用到时再去查详情。存储方案我分三档。最简单是内存存储用Python的dict或者Redis适合单机原型缺点是重启即失。第二档是SQLite或MySQL持久化会话数据写进表重启后还能恢复。第三档是把工作上下文做成独立状态服务比如用PostgreSQL JSONB字段适合分布式部署。我建议从Redis起步因为Context Mode本身需要频繁读写和过期管理Redis的TTL机制刚好能处理会话过期。3.2 关键实现记忆摘要与增量更新记忆摘要是一个看似简单、坑非常多的事情。很多新手会把“所有历史对话”一次性丢给模型生成摘要这在上下文少时没问题但对话超过30轮后旧摘要本身已经包含了大量早期信息再叠加全部原文去生成摘要token消耗巨大而且模型容易在超长输入里迷失重点。我实践下来比较稳的做法是增量摘要每次只拿“旧摘要 新增的几轮对话”去生成新摘要。旧摘要代表了过去所有对话的知识沉淀新对话是最新发生的增量两者压缩成一份新摘要既不会丢失关键背景也不会让输入无限膨胀。import json def update_summary(old_summary, recent_messages, llm_client): token_count count_tokens(old_summary) count_tokens(recent_messages) if token_count 1200: return old_summary # 增量太小时跳过更新 user_payload json.dumps({ old_summary: old_summary, new_messages: recent_messages }, ensure_asciiFalse) prompt f 你是对话记忆管理器。请根据【旧摘要】和【新增对话】生成一份新的对话摘要。 要求 1. 保留所有关键事实、已确认决定、用户偏好 2. 移除已经失效的中间信息 3. 摘要控制在300字以内 4. 直接用正文输出不要其他解释 【旧摘要】 {old_summary} 【新增对话】 {user_payload} new_summary llm_client.chat(prompt) return new_summary摘要更新不能每次都跑要设置阈值。我设定的触发条件是新增对话的token数超过旧摘要token数的20%时才更新否则摘要变化太小白白浪费一次LLM调用。另一个心得是摘要里不要写“用户说”“用户表示”这类叙述腔直接记录事实和决定比如“端口改为8080”而不是“用户表示想把端口改成8080”。压缩出的每一分信息密度都很珍贵。3.3 关键实现语义检索与按需注入长期记忆提取是Context Mode里最能拉开效果差距的一环。单纯用向量检索会有漏召回的问题比如问题和记忆里有完全相同的关键词但语义指向不同。我用的是混合检索向量相似度 关键词BM25得分最后加权融合效果比单路检索稳定很多。from openai import OpenAI client OpenAI() def retrieve_memory(query, top_k5): # 向量检索部分 query_vec client.embeddings.create( modeltext-embedding-3-small, inputquery ).data[0].embedding vector_hits vector_db.search(query_vec, top_ktop_k) # 关键词检索部分简化版BM25实际可用Elasticsearch或sqlite_fts keyword_hits bm25_search(query, top_ktop_k) # 加权融合 fused weighted_fusion(vector_hits, keyword_hits, alpha0.6) return fused重排这一步是我强烈建议加的但我自己初期经常忽略。向量检索出来的Top5真正有用的可能只有2条。如果不重排模型会读到一堆干扰项。我用一个轻量级方案把召回的候选块连同当前问题一起让LLM做一次快速相关性打分分数低于0.5的丢弃。逻辑上很直观先宽进再严出。向量检索保证“差不多相关的内容都进来了”重排保证“最后真正进入上下文的只有高相关部分”。这个过程会带来额外延迟大概增加200到500毫秒但换来的是回答稳定性的明显提升。对于非实时场景这个延迟完全在可接受范围内。注入顺序也很重要。检索到的记忆不是一股脑拼在prompt最后而是放在system prompt中“知识区”的位置并且要标注来源。模型对贴了来源碎片的信息引用准确率明显更高。def build_system_prompt(task_instruction, memory_chunks): parts [ 你是一个可靠的工作助手。请严格按照以下信息完成用户任务。, f【任务指令】\n{task_instruction}, 【相关历史记忆】, ] for idx, chunk in enumerate(memory_chunks, 1): parts.append(f[记忆{idx}]\n{chunk[content]}\n来源: {chunk[source]}) parts.append(【注意】只引用上面给出的记忆内容不要凭空捏造历史细节。) return \n\n.join(parts)3.4 关键实现角色指令固化为系统提示词Context Mode最后一个关键动作是把通用的“角色指令”固化成稳定模板与动态注入数据分离。这样做的原因是我发现很多prompt不稳定是因为每次把用户问题、历史、知识碎片全部混在一个字符串里系统指令被不断稀释。我的模板分成三个区。第一区是固定角色区定义你是谁、可以调用什么工具、回答风格约束。第二区是动态知识区放当前检索到的记忆和任务相关文档。第三区是当前输入区放本次用户消息以及必要的短时对话摘要。这种分层带来的一个直接好处是角色指令永远稳定无论下面怎么变模型的“人设”和输出规范不会跑偏。我把角色指令单独存成版本化配置改行为规范时只改一处不用动检索链路和上下文存储逻辑。说到版本化还有一个细节值得提给每次LLM调用打上tag记录用的是哪一版系统提示词模板、哪一版摘要算法、哪一版检索参数。排查问题时能快速定位“是检索变了导致效果下降还是摘要逻辑变了”这在反复调试Context Mode时能省下大量时间。4. 实战中的参数与调优记录4.1 我的一组可复现参数参数配置是这个方案从“能跑”到“好用”的分水岭。下面这组参数是我在64K上下文窗口的模型上实测调出来的一套基准不同场景可以在此基础上微调。参数项我的基准值调整建议短时原文保留轮数8轮任务型对话可降到4轮闲聊可升到12轮工作上下文JSON大小不超过2K token超出时拆分只注入当前步骤相关部分滚动摘要目标长度300字约400 token复杂度高任务可放大到500字摘要更新触发阈值新增增量旧摘要20%追求省token可提高阈值检索召回数量TopK5条文档问答可提到8条但重排后只留3条重排保留阈值相关性0.5我实际用0.55更稳系统提示词总长度3K内角色指令尽量压缩不要把文档内容固化进去这些参数不是拍脑袋定的。短时8轮指的是在64K窗口下8轮原文大约占4到8K token既能保证对话衔接又不至于挤压检索注入空间。摘要300字的依据是大多数任务的必要事实在300字内能覆盖80%以上再长边际收益很低。4.2 Token预算怎么分配我认为这是整个Context Mode里最需要花心思的地方。模型有个输出预留空间如果上下文塞满了生成到一半直接截断。我给的分配原则是输出预留占总窗口的20%到30%剩下的70%到80%才拿来放上下文。以64K窗口为例输出预留16K剩下48K供上下文使用。这48K里我大致按“1:2:3”的比例分给角色指令区、动态知识区、历史会话区。角色指令控制在3K内动态知识控制在10K左右历史会话摘要短时原文占用剩余空间。如果检索出来的内容特别长我宁可减少历史会话保留轮数也要保证当前任务相关的知识完整注入。很多同学容易犯的错误是把窗口当成仓库告诉团队“我们有128K可以塞很多”结果塞到110K时模型开始“精神涣散”回答逻辑明显下降。实测下来上下文使用率超过85%之后模型效果会断崖式下跌因为注意力已经被超长内容稀释。控制使用率在75%以内效果才稳定。我调参时有一个小技巧给每个环节单独算token加和然后打印出来。一眼就能看出哪个环节吃掉了太多预算。4.3 效果的量化对比没有数据支撑的调优不具备说服力我把自己内部测试的一组结果整理出来。场景是客服问答一共准备200条多轮对话测试集覆盖售前咨询、售后问题、订单修改、退款咨询四类。指标不使用Context Mode使用完整Context Mode变化首次回答正确率63.2%81.5%18.3个百分点关键信息漏报率17%6.5%-10.5个百分点平均单次调用token消耗6.8K4.1K-39.7%用户身份记忆正确率42%89%47个百分点为什么token消耗反而下降了因为Context Mode做了摘要和结构化之后去掉了大量重复历史而没做上下文管理时每次请求都携带全量历史Token一直在膨胀。这是我最初没想到的收益原本以为加检索会变贵实际整体算下来反而便宜了。当然只测一轮还不够。我加了“长会话稳定性”测试连续对话20轮后观察第20轮的回答质量完整方案在20轮后仍保持在第10轮的水平而无方案组到第15轮基本就“忘了”前面所有关键决定。这套机制对长会话场景带来的收益甚至比短对话更大。5. 常见问题与排查技巧实录5.1 上下文污染导致答案漂移这是Context Mode落地后最常遇到的问题。客户反馈说“聊着聊着突然开始讲旧话题了”翻日志发现注入的是第1轮的历史记忆片段和当前问题只是表面的语义相关实际上早已被用户否定。排查步骤我按下面这套来记录每次请求实际注入的memory_chunk列表带ID。命中问题后把这几个片段的原文调出来人工判断是否和当前问题相关。如果确实是检索误召检查重排阈值是不是太低了。如果是历史片段本身没问题但干扰了当前任务则降低注入上限或者把该片段改为summary中的一句话。我这边有一次问题是重排阈值设成0.4导致的低分内容混进来后模型被带偏调到0.55后问题直接消失。上下文污染首先要盯住“注入内容的质量”而不是急着调prompt。5.2 检索召回的不是想要的内容向量召回偶尔会返回和用户问题“字面上很像但实际不是同一件事”的内容比如用户问“如何部署”召回里却包含“部署失败如何回滚”模型引用了这段内容后回答变成“建议直接回滚”严重偏离用户意图。我的解法是混合检索重排的双保险两个环节处理的问题不同。混合检索解决“向量只认语义不认关键词”的漏召问题。重排解决“候选中混入低质内容”的误召问题。另一个小经验是长期记忆在写入时要打结构化标签比如“问题类别部署”“状态成功/失败”。检索时如果用户当前问题已经能确定类别可以直接在标签层面过滤比纯靠向量相似度更可控。5.3 上下文一直膨胀最后越聊越空这个问题典型症状第1轮回答600字言之有物第20轮虽然上下文变长了但回答反而只有一两句废话。我们把token使用量拉出来看发现每次请求都超长上下文使用率长期在90%以上。原因是摘要没有及时生效或者短时原文保留太多。我用过一套方案是每5轮触发一次强制摘要超过5轮的原文必须进摘要不留在原文区。还要给工作上下文做“剪枝”已经完成的步骤标记为done下一次请求就不注入。给Context Mode加上类似checkpoint的机制很管用。每10轮存一次全量快照之后每次请求都基于快照做增量。这样即使某次请求异常也能从最近的快照恢复而不是从头开始。这个机制对Agent任务链尤其重要任务中断后能恢复到完整状态不用重新跑前面步骤。5.4 快速问题速查表问题现象可能原因快速排查手段推荐解决回答“失忆”摘要更新不及时检查summary字段是否为空或过期缩短摘要间隔强制5轮更新回答被旧话题带偏检索召回低相关片段打印注入的memory_chunks列表调高重排阈值到0.55上下文越来越慢历史原文未及时压缩看请求体大小变化趋势强制轮次截断增量摘要一开始好后面差上下文使用率超85%计算每请求上下文token占比压缩短时原文控制使用率75%以内同一问题答案每次不同检索结果不稳定对比两次请求的注入差异固定记忆排序减少随机性任务进行到一半断掉工作上下文缺失查看work_context是否为空引入快照恢复机制这套速查表是我内部debug时用的遇到问题先看表基本能覆盖80%的Context Mode异常场景。真正难排查的往往不是单点故障而是几个问题叠加又丢记忆、又召回了错误内容、注入顺序还不对。这时候不要乱调参先把每一层的数据打出来逐一排查找到主因再动手。手机打下这一大段的时候我又想起自己最早踩的坑——第一版Context Mode把所有“上下文处理”都堆在一个函数里摘要、检索、注入逻辑互相纠缠改一处坏一处。后来把记忆分层、把流程拆成独立的处理步骤才终于理清头绪。这个经验放到读者自己的项目里也是一样Context Mode不是让你把所有的历史都记住而是让你在恰当的时机忘掉不重要的东西同时记住最关键的少数。如果想把这套思路再往前推一步可以试试把整个会话状态结构序列化之后存进文件或对象存储让Agent在任何设备、任何时候都能恢复到同一份“记忆”。这相当于给对话系统装了一块可移植的硬盘跨会话、跨任务复用上下文会变得异常顺滑。对我来说一个AI应用的气质是否专业往往不在模型多聪明而在于它记住什么、忘掉什么、何时把哪段记忆端出来。Context Mode就是围绕这件事做的最系统的工程化尝试值得反复打磨。