最近在接手一个对话类系统项目时被context-mode的设计狠狠上了一课。同一个模型、同一份Prompt模板只因为上下文的组装方式不同输出从废话文学直接变成精准命中。这个东西说白了就是上下文模式——决定模型每一轮对话能看到哪些信息、以什么顺序看到、以及哪些旧信息该被忘掉。凡是做过聊天机器人、AI客服、Copilot类应用的人基本都会被这三个问题追着跑上下文放少了模型失忆放多了Token爆炸放错了直接带偏答案。这篇文章我按自己在项目里踩过的坑来写先把context-mode到底是什么、为什么它这么关键讲清楚再拆四种常用模式的选择逻辑和实现细节最后给一份能直接抄走的实操代码和问题排查清单。无论你是刚接触大模型应用开发还是已经在做生产级系统优化这都算一份可以对照着用的参考资料。1. 理解context-mode它到底在解决什么问题1.1 无状态与有状态的差异要理解context-mode先得搞清楚一个基础事实绝大多数大模型本身是无状态的。你发一条请求过去模型看到的就是这一次请求里的全部内容它不记得你五分钟前问了什么更不记得你昨天设置过什么偏好。所谓记忆完全靠调用方在每次请求时把历史信息拼进上下文。无状态带来的问题很直接。用户问帮我查一下上周的订单模型能回答用户紧接着问那再帮我改一下地址模型立刻就懵了——那指代的是什么上次订单的哪个地址改到什么地址这些信息不在当前请求里它只能靠猜。这种体验放在问答Demo里还能忍放到客服、销售、办公助手这类真实场景里基本就是不可用。context-mode做的就是这件事它规定了如何从过去的历史中筛选、组织信息然后注入到当前请求。这里面的核心不只是一个技术方案而是一套取舍策略——保留多少历史、怎么样保留、多久之前的还需要、多细的内容该丢弃每一项都直接影响回答质量和成本。1.2 四种context-mode的总体图谱我在不同项目里试过很多种上下文组织方式归类下来真正实用的是四种单次会话模式static、滑动窗口模式window、摘要记忆模式summary、检索增强模式retrieval。static模式每次请求只带当前用户输入系统Prompt不带任何历史。最省钱也最省事适合翻译、分类、抽取这类单回合任务。window模式把最近N轮对话拼进上下文旧的直接丢掉。实现最简单适合闲聊、短对话场景但窗口长度不好定太长费钱太短记不住。summary模式每聊几轮就把历史总结成一段摘要下次请求带摘要最近几轮原文。适合长对话、需要长期记忆的场景但总结本身有信息损耗也会消耗额外Token。retrieval模式把知识库/历史会话向量化存起来每次根据当前问题检索最相关的片段拼进上下文。适合知识问答、企业资料检索、客服助手这类上下文需要按需召回的场景。四种模式不是互斥的实际生产里经常组合使用——比如summary做长期记忆window做短期记忆retrieval做实时知识注入。理解了这一点后面看代码会轻松很多。2. 模式选型不同场景该用哪种context-mode2.1 单次会话模式接口即上下文先把最简单的static模式说透。它的逻辑就是每次调用模型时上下文中只有系统Prompt当前这一次的用户输入。没有历史拼接没有记忆存储一锤子买卖。什么时候该用它我举个例子一个内容审核接口输入是一篇文章输出是分类标签。这种任务用户不会指望模型记得上一篇文章是什么它的判断依据只有当前文本。另一个典型场景是批量处理比如把一万条工单逐条做意图识别每条之间完全独立。你要是给这种场景强行加记忆反而会引入污染——上一条的背景信息可能干扰当前判断而且白白多花Token。static的核心优势是可控性和隔离性。每次请求的输入输出完全独立你不需要考虑历史状态的一致性也很容易做并发和重试。缺点也显而易见没有多轮能力用户一绕弯它就掉线。所以我的经验是能用static解决的别急着上记忆方案。记忆是一种能力也是一种负担。2.2 滑动窗口模式最朴素的记忆方案接着是window模式也是很多人做多轮对话的第一选择。简单说就是维护一个消息列表每次请求带上最近N条消息。N可以按轮数算也可以按Token数算。用代码来感受一下# 滑动窗口实现示例 class SlidingWindowMemory: def __init__(self, max_turns6): self.max_turns max_turns self.history [] def add(self, role, content): self.history.append({role: role, content: content}) # 只保留最近max_turns轮一轮一条user一条assistant if len(self.history) self.max_turns * 2: self.history self.history[-self.max_turns * 2:] def build_messages(self, system_prompt): return [{role: system, content: system_prompt}] self.history看着很简单但有个问题——按轮数截断其实不准确。用户一个问题可能带超长文本Assistant答案也可能很长两轮就把窗口塞满了。更合理的做法是按Token预算截断后面第3章会细说。window模式适合的场合是对话轮次不多、历史不会太长、用户问题相对独立。像闲聊机器人、简单的售前咨询助手6到10轮的窗口通常够用了。再往下走用户一旦开始聊长篇内容窗口模式就会频繁截断这时就该升级模式了。2.3 摘要记忆模式用缓存换容量窗口模式的短板是忘得快summary模式就是为了补这个短板。它的思路不难理解当对话超过一定长度时不再简单丢弃旧消息而是让模型把旧消息压缩成一段摘要之后每次请求带上摘要最近几轮的原文。这个模式的效果很直观用户把一本书的内容分段粘贴进来聊了几十轮之后模型仍然记得核心观点是A和用户在第5章提出了B要求因为它们被保存进了摘要。代价是两部分每次做摘要会消耗额外Token摘要是一次有损压缩细节可能丢。实现上要注意摘要的更新方式。最粗暴的做法是定期把全部历史丢给模型重新总结简单但费钱又慢。更实际的是增量式新摘要 旧摘要 新增对话片段让模型提炼合并。参考写法def compress_summary(old_summary, new_messages): 把旧摘要和新消息合并成一段新摘要 prompt ( f已有摘要{old_summary}\n f新增对话{new_messages}\n 请合并以上信息生成一段不超过200字的更新摘要 保留人物、关键事件、用户明确表达的要求和偏好。 ) # 调用模型返回摘要文本 return call_llm(prompt)summary适合长对话场景比如用户分二十轮讲述一个方案需求、AI辅助写作的长篇协作、带有角色扮演的互动产品。但要注意摘要里的信息一旦丢失后面再想捞回来基本不可能所以很多系统是summary做长期记忆 window做短期记忆组合着用。2.4 检索增强模式把外部知识变成上下文retrieval模式也常被叫做RAGRetrieval-Augmented Generation。它的核心思想是不把所有知识都塞进上下文而是每次根据当前问题从外部存储数据库、向量库、文档库里召回最相关的片段和问题拼在一起送进模型。举个例子一个企业内部知识库助手资料有十万条。你不可能把它们全部放进上下文模型窗口装不下就算装得下成本也离谱。retrieval的做法是用户提问报销流程是什么先通过向量检索找出最相关的三到五条文档片段只把这几个片段用户问题交给模型回答。回答质量取决于检索准不准而不只是模型本身强不强。跑通一个最简版retrieval不复杂但要做到生产可用很吃细节。文本怎么切块、向量用什么模型、检索用相似度还是重排、召回多少条、阈值定多少每一个参数都在真实场景里反复调试过才稳定。这部分我会在第4章的实操代码里给出一个能跑的示例。模式选型这块我最后给一个个人经验不要一上来就选最复杂的方案。从static起步发现用户需要长期记忆就加summary发现需要实时知识就加retrieval发现自己其实只需要最近几轮就停在window。每次加复杂度都必须问自己哪个指标变好了如果没有砍回去。3. 核心参数与实现细节从原理到代码3.1 窗口长度与token预算无论用哪种context-mode绕不开一个核心变量Token预算。大模型的上下文长度是固定的比如8K、32K、128K实际能用的是总窗口长度 - 系统Prompt长度 - 输出预留长度剩下的才分给历史和检索片段。这里有个很多人首次做项目会踩的坑把模型的最大上下文长度直接当成可用长度。模型文档说128K你就敢往里面塞128K结果调用直接报错或者输出被截断。原因很简单——模型输出也要占窗口系统Prompt也要占窗口。我一般预留四分之一到三分之一给输出剩余才给输入侧。用一个例子算笔账。假设模型上下文上限是32K Token系统Prompt固定占1K你希望每个回答最多生成2K Token。那么输入侧可用预算是32K总窗口 - 1KSystem - 2K输出预留 29K这29K中如果走的window模式存最近对话如果走retrieval存检索片段。如果两者都要那得先定好比例比如历史和检索片段各一半。Token预算定下来后历史裁剪就好办了。不管是按轮数还是按条数最终都要换算成Token数去检查。def trim_history(history, max_tokens8000): 从尾部向前保留消息直到超出max_tokens为止 used 0 kept [] for msg in reversed(history): msg_tokens estimate_tokens(msg[content]) if used msg_tokens max_tokens: break kept.append(msg) used msg_tokens return list(reversed(kept))3.2 截断策略如何选窗口满了要截断从哪头丢是个学问。最简单的策略是从最旧的开始丢保留最新的对话——这符合直觉但也意味着用户一开始说的重要信息可能被丢掉。这时候需要更细的分层策略。我做过的比较有效的方案是把消息按重要性分两层。系统指令、用户明确表达的需求比如记住我的偏好是……、涉及任务目标的关键信息放永不清除层普通的寒暄、重复内容、Assistant的旧回答放可丢弃层。清理时先丢可丢弃层再丢最旧的一般消息。另外要特别提醒一个点Assistant的旧回答占的Token通常比用户问题多得多。如果预算不够优先丢Assistant的历史回答只保留用户的问题和自己的关键回复效果往往比全都留着更好。原因是模型更依赖最近的指令而过长的旧回复反而会引入噪声。截断策略没有绝对最优必须结合场景测试。我自己习惯维护一份测试问答集每次改策略后跑一遍记录回答质量打分而不是凭感觉调。3.3 记忆持久化存到哪里、怎么序列化上下文模式落地到生产环境时除了组装Messages还需要解决存储问题。记忆放在内存里服务一重启就丢了记忆存到数据库又要考虑读写性能和序列化格式。两个常见的持久化方案Redis适合快速读写TTL自动过期。把对话历史序列化成JSON字符串以会话ID作为Key设置有效期。适合window和短期记忆。关系型数据库/文档库存结构化记录每轮对话一条数据。方便按时间查询、按类型过滤、统计分析。适合summary和retrieval的底座。序列化格式方面我建议不要只存裸文本。每一条消息记录里至少要包含role、content、timestamp、token数可估算。timestamp很有用——有些记忆要在一定时间后失效token数可以在组装上下文时快速累加不用重新估算。一条典型记录的示意{ id: msg_001, session_id: session_abc, role: user, content: 把明天的会议纪要发给王总, ts: 1734567890, tokens: 18 }值得一提的是对大模型应用来说记忆存储本身就是一部分架构设计。如果项目有long-term记忆需求比如让AI记住用户的偏好、历史行为那可以考虑把记忆实体化——比如维护一个用户画像字段每次对话后让模型抽取更新。这种做法比无限堆历史更经济也是很多成熟产品在用的方案。4. 实操搭一个带context-mode的对话服务4.1 基础代码结构下面我给出一个可以本地跑通的示例完整演示四种context-mode怎么组装。为了保持通用性这里的模型调用部分用一个假的call_llm()占位你可以替换成任意大模型API。import json import hashlib def call_llm(messages): 实际使用时替换为你的模型调用。 参数messages是OpenAI风格的消息列表每个元素为 {role: system/user/assistant, content: 文本} # 这里仅为演示真实项目请接入模型服务 prompt \n.join([f{m[role]}: {m[content]} for m in messages]) return [模拟回答] prompt[-100:] def estimate_tokens(text): # 简易估算中文场景一般1字≈1.5个token英文1词≈1.3个token # 生产环境建议直接用Token计数库 return int(len(text) * 1.3) class ContextModeChat: def __init__(self, modewindow, system_prompt你是一个乐于助人的AI助手。, window_max_tokens6000, summary_threshold4000): self.mode mode self.system_prompt system_prompt self.window_max_tokens window_max_tokens self.summary_threshold summary_threshold self.history [] # 最近对话原文 self.summary # 长期摘要 self.knowledge_base [] # 检索模式的文档库 self.kb_embeddings [] # 向量化后的文档示例中用hash代替 def add_message(self, role, content): self.history.append({ role: role, content: content, tokens: estimate_tokens(content) }) def build_messages(self, user_input): 统一入口根据不同的context-mode组装messages if self.mode static: return [ {role: system, content: self.system_prompt}, {role: user, content: user_input}, ] if self.mode window: fitted self._fit_window(self.history, self.window_max_tokens) return [ {role: system, content: self.system_prompt}, *fitted, {role: user, content: user_input}, ] if self.mode summary: # 如果历史太长先触发摘要压缩 return self._build_summary_messages(user_input) if self.mode retrieval: return self._build_retrieval_messages(user_input) raise ValueError(f未知模式: {self.mode}) def _fit_window(self, messages, max_tokens): 从最新消息往回装直到预算用完 used, kept 0, [] for msg in reversed(messages): if used msg[tokens] max_tokens: break kept.append({role: msg[role], content: msg[content]}) used msg[tokens] return list(reversed(kept)) def _build_summary_messages(self, user_input): history_tokens sum(m[tokens] for m in self.history) if history_tokens self.summary_threshold and self.history: new_summary self._compress(self.summary, self.history) self.summary new_summary # 压缩后只保留最近2轮原文 self.history self.history[-4:] self.history[0][tokens] estimate_tokens(self.history[0][content]) messages [ {role: system, content: self.system_prompt}, ] if self.summary: messages.append({role: system, content: f以下是此前对话的摘要请据此理解用户上下文\n{self.summary}}) messages.extend([ {role: m[role], content: m[content]} for m in self.history[-4:] ]) messages.append({role: user, content: user_input}) return messages def _compress(self, old_summary, messages): compact_text \n.join(f{m[role]}: {m[content]} for m in messages) merge_prompt ( f已有摘要{old_summary}\n f新内容{compact_text}\n 请生成一段不超过200字的合并摘要必须保留用户身份信息、 用户明确要求、已经达成的结论、待办事项。 ) return call_llm([ {role: system, content: 你是一个专业的对话摘要器。}, {role: user, content: merge_prompt}, ]) def _build_retrieval_messages(self, user_input): docs self._search(user_input, top_k3) knowledge_text \n\n.join(docs) messages [ {role: system, content: self.system_prompt}, ] # 把检索到的文档作为system上下文注入而不是放user里 if knowledge_text: messages.append({role: system, content: f参考知识片段\n{knowledge_text}}) # 保留最近几轮对话能更好地理解指代 messages.extend(self._fit_window(self.history, self.window_max_tokens)) messages.append({role: user, content: user_input}) return messages def _search(self, query, top_k3): 简化版检索按关键词打分返回最相关的文档 query_word_set set(query) scored [] for doc in self.knowledge_base: doc_word_set set(doc) score len(query_word_set doc_word_set) scored.append((score, doc)) scored.sort(reverseTrue) return [doc for score, doc in scored[:top_k] if score 0]这个类把四种模式统一到了一个接口里切换模式只需要改初始化参数。实际工程中我还习惯再加一个modehybrid内部把summary和retrieval合起来算是当前生产环境里最稳的组合。4.2 接入检索增强上下文上面代码里的_search是简化版实际项目中检索这一环通常是接向量库。这里我把步骤拆细一点。第一步文档预处理。把知识库的长文档切块块与块之间要有一定的overlap否则关键句子可能会被从中间切断。块大小我常用200到500字超出这个范围检索精度会波动太小语义不完整太大检索噪声多。第二步向量化存储。每块文本通过Embedding模型转成向量存入向量数据库。现在有不少开源向量库可以直接用个人项目选轻量级的企业项目考虑分布式方案。第三步检索重排。用户提问后先向量相似度召回top50再用重排模型精排选top3到5。不差钱的就直接上大模型做精排效果最稳就是慢。这里有个经验把检索结果直接塞进prompt前最好按与问题相关度从高到低排列模型对排在前面的信息关注度更高。第四步拼装。看上面的_build_retrieval_messages我把检索片段放进了system列表里而不是和用户问题拼接。原因是模型在处理时system段的信息会被当作必须遵守的背景知识比夹在对话里更容易被利用。用下来这个细节对正确率的提升挺明显。4.3 测试与效果对比代码写完最重要的环节是验证——不是跑通就结束要量化对比。我找一个典型的多轮场景跑一遍用户先问帮我写一份项目周报的模板接着问加上上周的进度再问把负责人改成我自己。三种模式的表现差异如下模式能否记住周报模板能否记住上周进度能否正确改负责人Token消耗备注static否否否最低每问都像新用户window是是在窗口内是在窗口内较低窗口超了就忘summary是是是中依赖摘要质量retrieval是若资料在库部分部分中更偏知识问答这个表是我自己项目中实测出来的规律不代表所有场景一致但它能说明一个核心结论context-mode的选型本质上是在记忆能力、token成本、实现复杂度之间找平衡。测试时别忘了边界场景用户发超长文本用户连续对话30轮用户要求修改很早之前说过的一句话多用户并发时会话隔离是否正确。这些才是生产环境真正会出问题的地方。5. 常见问题与排查记录5.1 上下文被截断后答非所问现象对话超过十几轮后模型开始失忆连用户两分钟前说的话都记不住。这种情况绝大多数是window模式触发截断旧消息被丢了。排查分两步先看实际发送了多少Token给模型、窗口上限是多少再在日志里把发送前的消息列表打出来检查被丢的是哪些。处理方案有三个方向一加大窗口预算前提是不超模型上限、成本可接受二换成summary模式让核心信息进摘要而不是被丢弃三对用户明确表达的需求做标记这些消息不进可丢弃层。5.2 模式切换导致记忆错乱现象同一个会话第一段用window第二段代码里改成summary结果用户发现AI把时间顺序搞混了把新信息当旧信息或者把摘要里的内容当成刚发生的。原因在于摘要和历史拼接顺序不对。常见错误是把摘要放在user消息之后模型容易把摘要当成用户新输入正确做法永远是把摘要放在system段并且明确标注这是历史摘要。第二个原因是切换模式时没有重建记忆两套机制存的内容格式不兼容。解决思路很简单——生产环境不要动态切换模式必须切换时重建会话上下文并告诉模型以下是此前对话的摘要。5.3 token消耗爆炸现象没改什么代码账单突然翻了几倍。排查时不要只看输入长度还要看是不是summary模式触发了重复压缩。我踩过一个很现实的坑每次请求都执行_compress()等于每轮对话都额外调用一次模型做摘要钱当然蹭蹭涨。正确的做法是设定触发条件比如历史超过多少Token才压缩压缩后记录last_compressed_at没有新消息进来就不重复压缩。另一个隐蔽的消耗点是历史中明明可以裁剪的Assistant长回复。如果回答内容里包含大段代码或日志这类回复占的Token非常高。处理办法是保存记录时直接截断过长的Assistant输出只留前几百字很多场景完全够用。5.4 排查思路速查表症状优先检查项常见根因解决方向模型忘记早期信息发送前的messages日志窗口截断丢旧消息启用summary或标记重要信息回答引用错误事实检索召回内容检索片段不相关或过旧调整Embedding、加重排、限制知识时间范围Token费用飙升一次请求的Token明细重复压缩、旧回复过长加触发条件、裁剪Assistant输出多用户之间串话会话ID与存储Key缓存的Key设计错误统一用会话ID用户ID双维度隔离回答越来越散检查历史里的噪声无关的历史干扰当前判断减小窗口或增加相关性过滤排查context-mode问题我觉得最有效的习惯是把每次发送给模型的完整消息序列记录下来。哪怕只记下来前200个字排查时都比猜强太多。我就靠这个习惯解决过不少诡异问题核心原则是先看模型到底看到了什么再谈模型为什么答成这样。4有个容易被忽略的细节不同厂商的模型对system消息的敏感度差别很大。同一套上下文结构在A模型上把检索片段放system效果很好换到B模型上可能完全无效。所以模式设计时要留好开关方便针对模型调优。最后再分享一个实践中的体会context-mode说到底不是某一个算法的胜利而是一套围绕让模型在有限窗口里看到最该看的信息的工程方法。我见过不少项目一开始疯狂追求复杂方案但真正稳定跑生产的大多是先把基础模式做扎实再加上一层恰到好处的检索或摘要。先从最简单的做起用数据说话再逐步加复杂度。这个顺序能帮你少走很多弯路。