做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之前，必须先弄清自己服务的场景最看重哪种上下文类型。我一般把使用场景分成三大类，每一类的侧重完全不同。

对话助手最怕的是“忘记刚才说过的偏好”。用户在第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_ascii=False) 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_k=5): # 向量检索部分 query_vec = client.embeddings.create( model="text-embedding-3-small", input=query ).data[0].embedding vector_hits = vector_db.search(query_vec, top_k=top_k) # 关键词检索部分（简化版BM25，实际可用Elasticsearch或sqlite_fts） keyword_hits = bm25_search(query, top_k=top_k) # 加权融合 fused = weighted_fusion(vector_hits, keyword_hits, alpha=0.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轮指的是在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条多轮对话测试集，覆盖售前咨询、售后问题、订单修改、退款咨询四类。

为什么token消耗反而下降了？因为Context Mode做了摘要和结构化之后，去掉了大量重复历史；而没做上下文管理时，每次请求都携带全量历史，Token一直在膨胀。这是我最初没想到的收益，原本以为加检索会变贵，实际整体算下来反而便宜了。

当然，只测一轮还不够。我加了“长会话稳定性”测试，连续对话20轮后观察第20轮的回答质量，完整方案在20轮后仍保持在第10轮的水平，而无方案组到第15轮基本就“忘了”前面所有关键决定。这套机制对长会话场景带来的收益，甚至比短对话更大。

5. 常见问题与排查技巧实录

5.1 上下文污染导致答案漂移

这是Context Mode落地后最常遇到的问题。客户反馈说“聊着聊着突然开始讲旧话题了”，翻日志发现注入的是第1轮的历史记忆片段，和当前问题只是表面的语义相关，实际上早已被用户否定。

排查步骤我按下面这套来：

1. 记录每次请求实际注入的memory_chunk列表，带ID。
2. 命中问题后，把这几个片段的原文调出来，人工判断是否和当前问题相关。
3. 如果确实是检索误召，检查重排阈值是不是太低了。
4. 如果是历史片段本身没问题但干扰了当前任务，则降低注入上限，或者把该片段改为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 快速问题速查表

这套速查表是我内部debug时用的，遇到问题先看表，基本能覆盖80%的Context Mode异常场景。真正难排查的往往不是单点故障，而是几个问题叠加：又丢记忆、又召回了错误内容、注入顺序还不对。这时候不要乱调参，先把每一层的数据打出来逐一排查，找到主因再动手。

手机打下这一大段的时候，我又想起自己最早踩的坑——第一版Context Mode把所有“上下文处理”都堆在一个函数里，摘要、检索、注入逻辑互相纠缠，改一处坏一处。后来把记忆分层、把流程拆成独立的处理步骤，才终于理清头绪。这个经验放到读者自己的项目里也是一样：Context Mode不是让你把所有的历史都记住，而是让你在恰当的时机忘掉不重要的东西，同时记住最关键的少数。

如果想把这套思路再往前推一步，可以试试把整个会话状态结构序列化之后存进文件或对象存储，让Agent在任何设备、任何时候都能恢复到同一份“记忆”。这相当于给对话系统装了一块可移植的硬盘，跨会话、跨任务复用上下文会变得异常顺滑。

对我来说，一个AI应用的气质是否专业，往往不在模型多聪明，而在于它记住什么、忘掉什么、何时把哪段记忆端出来。Context Mode就是围绕这件事做的最系统的工程化尝试，值得反复打磨。