做过AI应用的人基本都遇到过同一个尴尬模型单看一条请求逻辑完全正确一旦用户追问几句、或者任务带上了项目背景回答就开始“失忆”前言不搭后语。业内管这类问题叫“无状态”解法其实就落在标题这俩词上context-mode上下文模式。说白了就是让程序在把请求交给模型之前先想清楚“该带哪些背景信息、怎么组织这些信息”而不是傻乎乎把所有历史一股脑塞进提示词。这篇内容适合正在做对话机器人、AI知识库问答、代码助手这类项目的开发者也适合刚接触Prompt工程、想搞明白“为什么我的机器人记不住话”的入门选手。我会从概念拆解、方案选型、代码实现到调优坑点完整讲一遍我自己落地context-mode的全过程。这不只是教你怎么接API而是把上下文从“玄学”变成可量化、可维护的工程模块。1. 上下文模式到底在解决什么问题1.1 从“单轮问答”到“带记忆的助手”模型本身是不带记忆的你每次调用API传过去的只是一段静态文本。用户说“帮我看看昨天那个报错”如果你只把这句话发给模型它根本不知道“昨天那个报错”是什么。这时候必须由业务系统主动把相关历史记录、项目背景、当前状态一起塞进请求里模型才能给出像样的回复。context-mode的核心动作就是把“决定带哪些上下文、以什么顺序组织、控制在多少token以内”这件事从拍脑袋变成一套可执行规则。它不是某个特定模型的新功能而是应用层的一种设计模式可以用在任何对话型、生成型模型上。我在团队内部做技术文档问答机器人时一开始也偷懒过直接把用户session里的所有聊天记录拼接起来发给模型。结果就是前几轮还挺聪明聊到第10轮时token飙到几万模型开始东拉西扯响应时间从2秒变成15秒费用也肉眼可见地涨。后来我意识到上下文管理的本质不是“记更多”而是“记对、记少、记新鲜”。1.2 context-mode与普通模式的本质差异普通模式无上下文模式下每次请求都是独立的系统只处理用户当前这条输入适合翻译、改写、分类这类无状态任务。context-mode则是在请求前加了一层“上下文装配”环节系统需要完成四件事识别当前请求依赖哪些历史信息或背景知识从存储中拉取相关片段按优先级和时序组装成提示词对超长内容做截断或压缩保证请求体积可控。你可以把普通模式理解成“每次打电话都重新自我介绍”context-mode则是“接起电话就知道对方是谁、上次聊到哪、手头有什么材料”。后者显然更像一个合格的助手但代价是要维护一套上下文存储与检索机制。1.3 适合上context-mode的典型场景不是所有功能都需要context-mode。我建议按这三个特征判断用户会在同一会话内连续提出多个相关任务回答质量依赖项目背景、历史决策或用户偏好单轮输入信息量不足需要外部知识补齐。符合这三个特征的典型场景包括代码仓库问答助手要知道你问的是哪个文件、什么语言、最近改了啥、客服工单系统要知道客户之前报修过什么、当前订单状态、写作辅助工具要保持风格一致、记住前文设定。反过来像关键词提取、文本润色、内容审核这类单次任务强行套上下文模式反而会引入噪声降低准确率。2. 实现context-mode的两条路线与方案选型2.1 显式上下文把状态装进每条请求显式上下文是最容易理解、也最容易实现的方式。系统把需要携带的信息以文本形式直接拼进提示词包括对话历史、检索到的知识片段、用户画像标签等。一切都放在明面上模型看到什么就是什么可解释性强。我第一次落地时就用的这种方案。结构大概是[系统设定] 你是某项目的技术助手以下是项目背景... [知识片段] 根据用户问题检索到的相关文档... [对话历史] 用户... 助手...最近N轮 [当前输入] 用户...好处是逻辑简单、出问题好排查prompt里有什么内容直接打印出来就能复盘。坏处也很明显token消耗大超出窗口就面临截断策略的麻烦如果历史很长靠简单拼接很快会撞上上限。显式上下文适合对话轮次有限、知识库文档量可控的中小型项目也是我建议大多数团队先尝试的路线。2.2 隐式上下文用检索和缓存构建动态上下文隐式上下文不把所有信息都塞进提示词而是让模型或系统通过检索、向量召回、缓存命中等方式按需获取信息。典型实现是RAG检索增强生成把文档切成块、向量化入库用户提问后先做相似度检索把命中的top-k片段拼进提示词而不是把整本手册扔进去。这块是我后期重点优化的方向。只靠显式上下文拼凑历史一旦知识库超过几百个文档根本拼不下。切块、向量化、召回这个链路跑通之后context-mode才真正有了“按需取用”的味道。隐式上下文的工程量主要在前置要做离线索引、切块策略要调、embedding模型要选、检索阈值要定。效果上限也更高适合知识库问答、代码搜索这类“不可能把所有东西都塞进提示词”的场景。2.3 方案选型我为什么不推荐一上来就堆大缓存很多团队一听context-mode第一反应就是“做个大缓存把用户历史全存Redis里每次请求全捞出来”。这个方向不完全是错的但容易走偏。缓存解决的是“存储”问题而上下文模式的核心瓶颈通常在“取舍”问题——历史信息不是越多越好最新不一定最相关。我的建议是先小后大先实现一个基于轮次和token上限的显式上下文管理器把主要流程跑通再去接向量检索。如果一上来就搞一堆基础设施向量库、缓存集群、消息队列很可能模型质量没提升多少反而被基建复杂度拖死。我们内部就是先用一个Python文件实现了上下文装配逻辑验证效果后才逐步引入向量检索。3. context-mode从零落地一个可复现的小项目3.1 项目目标与目录结构为了让你能直接对照操作我写了一个极简的“文档问答助手 context-mode”实现。目标场景用户连续提问系统返回基于文档内容的回答能记住本会话前文并能在文档库中检索相关内容。项目结构如下context-mode-demo/ ├── documents/ # 存放知识库文档txt/md ├── context_manager.py # 上下文装配核心 ├── retriever.py # 关键词检索先用简单BM25 ├── llm_client.py # 模型API调用封装 ├── main.py # 交互入口 └── config.py # 配置参数我用了一个极简的BM25检索来做隐式上下文部分纯粹是为了让你理解链路。真正产品级项目可以换成向量检索后面第4节我会讲两者的取舍。3.2 核心实现上下文管理器的关键代码context_manager.py是整个模式的核心。它的职责是维护会话历史、按策略截断、拼装最终提示词。# config.py MAX_HISTORY_ROUNDS 10 # 最多携带几轮对话 MAX_HISTORY_TOKENS 2000 # 历史区域token上限 MAX_TOTAL_TOKENS 8000 # 整个请求token上限 MAX_RETRIEVED_CHUNKS 3 # 检索返回几段文档 # context_manager.py import tiktoken class ContextManager: def __init__(self, max_rounds, max_history_tokens, max_total_tokens): self.max_rounds max_rounds self.max_history_tokens max_history_tokens self.max_total_tokens max_total_tokens self.history [] self.encoder tiktoken.get_encoding(cl100k_base) def add_turn(self, user_msg, assistant_msg): self.history.append({ user: user_msg, assistant: assistant_msg, timestamp: time.time() }) self._trim_history() def _num_tokens(self, text): return len(self.encoder.encode(text)) def _trim_history(self): # 先按轮次截断 if len(self.history) self.max_rounds: self.history self.history[-self.max_rounds:] # 再按token截断从最老的开始丢直到满足预算 while len(self.history) 1: serialized self._serialize_history() if self._num_tokens(serialized) self.max_history_tokens: break self.history.pop(0) def _serialize_history(self): parts [] for turn in self.history: parts.append(f用户{turn[user]}) parts.append(f助手{turn[assistant]}) return \n.join(parts) def build_prompt(self, current_input, retrieved_chunksNone): system_prompt 你是一个技术文档助手基于提供的资料回答问题。 # 知识片段区域 knowledge if retrieved_chunks: joined \n\n.join(retrieved_chunks) knowledge f以下是参考资料\n{joined}\n # 历史区域 history_text self._serialize_history() ... # 用token预算控制三个区域的配比 ...你注意看这个实现里的两处细节。第一先截轮次再截token。只按轮次截可能10轮里有一轮是用户贴了一大段代码token直接爆只按token截可能出现历史只剩半轮对话导致语义断裂。两层限制叠起来才能既保证长度可控又保证完整性。第二tiktoken是OpenAI官方的tokenizer本地算token不需要调API。不同模型有不同的tokenizer如果你用的不是cl100k_base记得换成对应模型家族的分词器否则估算偏差会比较大。3.3 触发判断与模式切换逻辑不是所有请求都需要完整上下文模式的装配。我在main.py里加了一个简单的触发判断如果用户消息里包含“打开上下文模式”或会话轮次超过2轮且问题中出现“刚才”“之前”“它”“那个”这类指代词就进入完整装配流程否则走轻量路径只带当前输入加系统提示词。实际上更稳的做法是把上下文检索和装配做成默认开启但装配强度按问题复杂度做分级。比如单轮指令类问题只带当前输入涉及指代、追问、项目背景的问题自动触发检索和完整历史组装。判断用什么策略可以用简单规则也可以用一个小分类模型但初期规则够用不值得为这个专门训模型。有个很直接的判断技巧看用户输入里有没有实体指代。出现“这个”“那边”“你刚说”“上次”这类词基本可以断定产生了上下文依赖。这比单纯看轮次可靠得多因为用户可能隔了很久回来追问轮次上算新一轮但语义上仍是连着的。3.4 token预算与窗口控制这里要说一个具体的计算过程。假设你使用的模型上下文窗口是16K token以常见的gpt-3.5-turbo-16k为例安全余量建议大家只用到70%也就是约11000 token因为模型处理接近窗口上限时性能会下降响应也更慢。11000 token怎么分配给各区域我会按比例拆系统提示词固定500 token 检索知识片段3段 × 500 token 1500 token 对话历史2000 token配置里MAX_HISTORY_TOKENS 当前输入假设用户输入300 token 剩余约6700 token槽位给回答输出这个分配的核心原则是宁可压缩历史也要给“检索到的资料”和“回答空间”留足额度。模型回答质量依赖两样东西——依据和发挥空间。历史信息是参考没必要全给而当前问题的答案长度决定了输出token压太狠会得到“挤牙膏式”回答。实际操作中你可以把各区域token用量打日志跑几天统计出真实分布再微调配比。我第一次跑的时候就发现用户输入经常超过300知识片段里有一份表格特别长导致回答被截断。后来给检索模块加了“按token裁剪chunk”的逻辑超出500的内容优先从中间截掉保住开头和结尾很多关键信息在首尾。4. 实战中的调优经验与坑点4.1 上下文污染最大隐形杀手这是我在实际项目中踩过最深的一个坑也是观察身边团队最容易忽略的问题。所谓上下文污染就是你带给模型的上下文里混入了不相关、甚至错误的内容。比如用户问“这个函数怎么优化”你从知识库里召回了3段文档其中两段是日志格式规范只有一段是性能优化指南——模型大概率会被那两段无关内容带偏回答里莫名其妙开始讲日志。为避免这个问题我做了三件事检索模块增加相关性阈值低于阈值的chunk直接扔掉按文档类型做标签过滤只召回与问题领域同标签的chunk在提示词里明确写出“只依据参考资料回答资料未提及的内容要说明”。第三点最容易被忽视。你以为带了上下文模型就会用其实模型经常把检索来的背景当成周边信息而不是权威依据。明确指令约束它“只依据参考”能明显减少幻觉。4.2 时效性问题陈旧上下文的处理另一个高频坑是陈旧上下文。用户昨天问过“部署脚本改好了吗”你今天把昨天的历史原封不动带进新请求模型会认为“改好了”是当前状态但实际可能已经变了。context-mode带着旧信息参与新推理比不带更危险。我在ContextManager里加了一个简单的时效衰减机制每条历史记录带timestamp超过24小时的压缩成一句话摘要只保留主题和结论24小时内的完整保留。如果后续引入向量检索还可以按时间过滤器控制召回范围不是所有文档都从最早开始召回。再补充一个小技巧系统提示词里可以带一条“当前用户会话的时间戳”。模型很多情况下不知道当天日期你给它一个准确坐标它处理“上周”“昨天”这类时间表达时才不会算错。这个细节成本几乎为零但对答案准确率帮助明显。4.3 性能与成本减少重复传输的缓存技巧context-mode说白了就是提示词变长每次调用都要把同样的背景、同样的文档、同样的历史传输给模型。按字符计费的模型下重复传输意味着重复烧钱。我用的一个有效优化是“分段缓存”。具体做法把系统提示词知识片段历史分别缓存每次只更新变化的那段。比如知识片段按用户意图分组缓存同一类问题在一段时间内共享同一份检索结果历史部分只在真正新增轮次时才重新序列化不每次从头拼。这个缓存切换成代码大概就是class ContextCache: def __init__(self): self.cache {} def get_or_build(self, key, build_fn): if key not in self.cache or self.cache[key][expire] time.time(): self.cache[key] { value: build_fn(), expire: time.time() 300 # 5分钟过期 } return self.cache[key][value]实测下来接入缓存后相同会话重复提问的成本下降了差不多40%。唯一要注意的是缓存的失效策略知识库更新后要主动清掉相关缓存键不然会出现“新资料没生效”的诡异bug。5. 常见问题排查速查表症状可能原因针对性解法上下文经常丢失回答像失忆历史截断策略过于激进或者会话ID传错检查ContextManager的trim逻辑核对请求中session_id是否一致回答开始跑题检索带入不相关内容上下文被污染提高相关性阈值给检索结果增加类型过滤提示词强调“只依据参考资料”token超限知识库chunk过大或检索结果过多对chunk做token裁剪降低召回数量历史区域用摘要替代全文回答内容过时缓存未失效或陈旧历史未做时效处理给缓存设过期时间对超过24h的历史压缩成摘要更新知识库时主动清缓存延迟变高提示词过长或检索链路重复触发统计各区域token占比对检索结果做缓存触发判断增加分类规则成本明显上涨每次请求都带全量上下文用段落缓存只按需携带信息非所有请求都进入完整context-mode这份速查表背后是我踩过几轮坑之后总结的查问题顺序先看提示词里实际拼出了什么再查检索召回的是什么最后查缓存是否干净。很多人一遇到模型回答变差就怀疑是模型问题实际上多半是上面这一层上下文装配出了状况。6. 实践中的一点心得我自己做过好几个带context-mode的项目从最开始只会拼历史到后来能精细控制token配比最大的体会是上下文模式不是一个开箱即用的功能而是一套需要持续调优的工程机制。它真正的价值不在于“记住”而在于“选择”——在正确的时机带正确的信息把不重要的信息果断丢掉。如果你准备在项目里引入context-mode我的建议是先别急着上向量库、上复杂缓存。照着第3节这个极简实现把链路跑通打印出每一次的实际调用prompt观察几轮真实用户对话你就大概能明白问题出在哪一环节了。等摸清了瓶颈再决定要不要加检索增强要不要引入更智能的触发判断。最后分享一个可以立刻用上的小技巧在你的Prompt末尾加一句话——“如果上述信息不足以回答用户问题请直接说明缺少哪些信息不要推测。”这句话帮我省掉了大量排查幻觉的精力成本几乎为零但效果立竿见影。