做了大半年AI应用踩过最深的坑就是上下文管理。“context-mode”这个热词翻译过来就是“上下文模式”看着像个普通的开关但真正做对了能把AI应用的准确率、成本和响应速度一起优化。如果你正在做聊天机器人、文档问答、智能体这类项目这篇文章就当是同行之间的经验交流我会把从设计到落地的全过程包括参数怎么定、坑在哪、怎么排查全部摊开来讲。1. 为什么需要context-mode先搞定“记忆”这个老大难1.1 大模型的“工作记忆”到底怎么算大语言模型本身没有记忆它每次回答都只看到你塞进上下文窗口里的那堆文本。这个窗口就是它的“工作记忆”你给它什么它就看到什么。常见的模型上下文长度从几千到几十万token不等比如一些主流模型的窗口是128K或200K听起来很大但实际使用时会发现窗口越大问题越复杂。我做过一个文档问答类项目第一版特别天真把用户上传的文档、历史对话、系统提示词一股脑全塞进模型。结果调用费用蹭蹭往上涨响应时间从2秒拖到8秒最致命的是模型会在长上下文中“迷失”——它对文档中段的信息记得很清楚反而漏掉了用户最新提出的问题重点。这就好比开会时给每个人发了一百页资料真到提问环节没人记得第一页讲了什么。上下文窗口的大小不只要看模型支持的上限更要看你实际愿意花多少钱、等多久。很多模型的收费是按Input token计费的对话轮数一多每轮都把历史全部重发一遍成本是指数级上升的。这就是我需要一个“context-mode”来管理的核心原因不是所有上下文都值得保留也不是所有对话都适合用同一种策略。1.2 没上context-mode之前我踩过的三类坑先说第一个坑记忆混淆。用户在一轮对话里先问了“帮我分析上季度销售数据”接着又问“这两个产品方案哪个更值得做”。如果不做处理模型很可能还陷在销售数据里把产品方案的对比也往销售角度扯。因为模型没有定向能力它会尽量从所有上下文里找看起来相关的内容。这时候必须有一种机制告诉它旧话题的上下文该退场了。第二个坑叫上下文膨胀。这个我印象最深一个客服机器人用户问了七八个问题每个问题都带着两三轮历史来回我把所有历史原封不动地传给模型一轮请求就吃掉了七八千token。当时用的是按量付费的模型内测了一周账单出来我差点以为是计费系统出了问题。后来一查90%的费用都浪费在反复搬运历史对话上。第三个坑是“对不上焦”。大模型的注意力会被后加入的上下文影响尤其是那些细节丰富但不相关的信息。比如用户在一个协助写周报的场景里突然问“明天天气怎么样”如果上下文里全是上周的工作内容和KPI数据模型可能会一本正经地用周报风格回答天气问题看起来很荒谬但实际测试里经常出现。这三个坑让我意识到上下文管理不是“要不要带历史”的判断题而是“怎么带、带多少、何时切换”的设计题。context-mode就是为解决这个问题而设计的一层控制逻辑。1.3 为什么现成方案解决不了RAG、摘要、缓存各自的死角很多人的第一反应是用RAG检索增强生成来管理上下文。RAG确实能把外部知识库变成可检索的内容但它解决的是“知识从哪来”的问题解决不了“对话上下文怎么取舍”的问题。文档里检索到的片段和历史对话混在一起如果不对历史做分级处理模型照样会在新旧信息之间无所适从。也有人说可以用摘要压缩历史。这思路对了一部分但盲目的摘要有一个致命问题——它会丢掉细节。用户可能说“上次讨论的XX方案中的那个参数”如果参数名出现在被折叠掉的旧对话里摘要又没提取到模型就只能瞎编。摘要适合保留“故事主线”不适合保留“精确数据”和“用户身份信息”。还有缓存方案。缓存能加速重复请求但缓存是针对相同输入的用户每次提问都不完全一样缓存命中率其实并不高。我后来把这三类方案都试了一圈结论是需要一个在上层做统筹的功能让不同的对话场景有不同的上下文保留策略。这也就是context-mode出现的理由它不是和RAG对抗而是负责决定哪部分内容值得被RAG检索、哪部分历史可以直接丢掉、哪部分信息需要长期记住。2. context-mode的三种模式设计思路与选型依据2.1 Strict Mode模式一只盯着当前诉求我给第一个模式起名叫Strict Mode中文就是严格模式。在这种模式下系统只保留当前用户输入、必要的系统提示词以及最近一两轮对话中的“指代信息”。其他历史一律不进入模型。这个模式适用于什么场景呢最典型的就是工具调用和单轮问答。比如用户对着文档问“第二章讲什么”模型只需要根据当前问题和文档内容回答完全不需要前面五轮用户聊了什么。这时候如果带上大量历史反而容易让模型把第二章的回答案扯到之前聊过的某个例子上。Strict Mode的代价也很明显用户如果说“刚才那个方案我们再讨论一下”模型根本不知道“刚才”指什么。所以这个模式不能是用户手动选的唯一选项它更适合作为系统内部策略例如检测到用户发来一个独立完整的问题时自动切换过去省成本又提速。2.2 Auto Mode模式二自动裁切与摘要折叠Auto Mode是我用得最多的模式也是context-mode里最核心的部分。它的策略是最近的N轮对话原样保留更早的历史则触发摘要折叠折叠后的摘要和最近对话一起送入模型。这里的N不是拍脑袋定的。我实测下来常见的开放式对话场景里保留最近8到12轮效果最好。少于8轮模型容易丢失用户早些时候提到的重要偏好多于12轮Token消耗开始明显增加而且旧信息会分散注意力。N的具体值还要结合模型窗口大小和数据量来调我后面会讲如何用Token预算来反推。Auto Mode的难度在摘要折叠。如果只是简单让模型把旧对话“压缩总结一下”很容易丢关键实体和数字。我的做法是把摘要拆成两层一层是“全局摘要”记录对话主题、已确定事项和用户偏好另一层是“最近细节”保留最近几轮的原始消息。这样模型既有全局主线又有局部细节可用。2.3 Memory Mode模式三分层管理长期记忆Memory Mode面向的是需要跨会话记忆的场景比如私人助理、长期健康记录助手。光靠Auto Mode不够因为用户昨天说过“我用的咖啡机是德龙”今天再来对话历史已经分页不清了。Memory Mode的做法是把上下文拆成两层长期记忆层和短期会话层。长期记忆层可以存到一个轻量级的数据库或者向量库里记录用户的基本信息、偏好、历史承诺等等。短期会话层则沿用Auto Mode的策略只管当前这一轮对话的上下文。每次请求时先把长期记忆里和当前问题相关的条目取出来拼在系统提示词后面再组装当前会话的近期消息。Memory Mode最需要设计的是更新策略什么时候写入长期记忆如果每次对话都往里写很快就会变成一个大杂烩。我的规则很简单只有出现明确的陈述性信息比如“我喜欢”“我住在”“我的目标是”时才写入而且需要同一条信息被重复两次以上才写得进去。这样能避免用户随口一句话成了永久记忆。2.4 模式选择的判断逻辑手动触发和自动检测三种模式设计好之后还得有一个“选择器”。我做了两层第一层是用户手动触发界面里放一个开关让用户自己选“标准模式”或者“严格模式”高级用户可以用第二层是系统自动判断默认用Auto Mode但通过规则去识别该不该切换。自动判断我最初想用模型来做后来发现成本高、延迟大。最后用的是一组轻量规则用户消息里出现“记住”“我的名字是”这类持久化指令时触发Memory Mode的写入流程检测到消息是独立、完整的提问并且历史轮数超过一个阈值时触发Strict Mode其余时候保持Auto Mode。这套规则在准确率上当然不如模型判断但胜在又快又便宜。如果项目预算充足可以考虑在“是否切换模式”这个节点上调一次小模型把规则判断升级为语义判断。三种模式各有各的适用场景关键是在正确的时间用正确的模式而不是一边倒地全上Auto Mode。下面的表格把核心差异列出来了模式保留内容典型场景成本主要风险Strict当前输入 必要系统提示工具调用、独立问答最低指代失忆Auto最近N轮 摘要折叠日常多轮对话中等摘要丢细节Memory长期记忆 滚动会话跨会话助手较高记忆写入污染3. 实操落地从零实现一个可用的context-mode3.1 项目结构与核心依赖这一节我直接给出一个可运行的最小实现。你只需要一个LLM API的SDK、一个Token计数库以及Python 3.9以上环境。我用OpenAI风格的接口来写但逻辑完全通用换成其他厂商的SDK也一样。项目结构不用复杂三个文件就够了context_packer.py核心类负责把原始消息列表按模式打包成最终发往模型的Prompt。summarizer.py调用模型生成历史摘要。main.py一个FastAPI接口示例展示如何接入调用链。依赖方面我用tiktoken来计算Token数量用openai或者anthropic的SDK发请求。如果你用的是国产模型把SDK换掉、接口地址改一下就行核心逻辑不变。3.2 实现上下文打包器ContextPackerContextPacker是核心。它的输入是完整的消息历史输出是按模式过滤、裁剪、折叠后的消息列表。我先把严格模式说清楚只保留系统提示和当前用户消息但为了应对“刚才那个方案”这类指代我会额外保留最近一轮用户消息和最近一轮助手消息。import tiktoken class ContextPacker: def __init__(self, max_context_tokens: int 3000, system_prompt: str ): self.max_context_tokens max_context_tokens self.system_prompt system_prompt self.encoder tiktoken.get_encoding(cl100k_base) def _count_tokens(self, messages: list[dict]) - int: return sum(len(self.encoder.encode(m[content])) for m in messages) def pack(self, history: list[dict], mode: str auto, memory: dict | None None) - list[dict]: if mode strict: return self._pack_strict(history) if mode memory: return self._pack_memory(history, memory or {}) return self._pack_auto(history)_pack_strict的实现思路是固定带上系统提示词然后从历史尾部往前找保留当前用户提问和最近一轮助手回复其余丢弃。这里有一个容易被忽略的细节消息列表里一条“用户消息”之后可能跟着一条“工具执行结果”消息如果只保留用户消息而丢掉工具结果模型会看到用户提问却看不到工具输出逻辑上是不完整的。def _pack_strict(self, history: list[dict]) - list[dict]: result [{role: system, content: self.system_prompt}] # 从后往前收集最近一条用户消息和其后的所有消息 for i in range(len(history) - 1, -1, -1): if history[i][role] user: result.extend(history[i:]) break else: result.extend(history) return resultAuto Mode相对复杂先把系统提示词放好然后给历史消息做预算分配。我会先保留最近的原始消息即最近N轮把剩余预算分配给更早历史用来生成摘要。具体数值我会在3.3节里说。3.3 Token预算怎么算一个3000 tokens预算的实例我强烈建议你给上下文模式设一个硬性预算不要直接依赖模型的全部窗口。拿一个max_tokens4096的常见配置举例系统提示词预留 300 tokens模型输出预留 1000 tokens防止长回答中途截断剩余约 2800 tokens 给上下文。这2800 tokens怎么分我建议把70%留给最近的原始消息30%留给折叠摘要。也就是最近原始消息占约1900 tokens历史摘要占约900 tokens。这个比例不是绝对的早期我把摘要比例调得太高结果模型总是“记得大概意思但记不得细节”后来改成反向比例把更多预算给最近原始消息效果明显好了。那1900 tokens能装下多少轮对话用tiktoken数一下发现一个中文字大约占1.5到2个token。一条用户消息加一条助手回复打印出来平均消耗150到300 tokens不等。所以1900 tokens大概能装下8到12轮对话这正好呼应了我前面说的N值。你可以用自己的历史消息实测然后把这个参数写进配置不要凭空估计。def _pack_auto(self, history: list[dict]) - list[dict]: # 保留系统提示 result [{role: system, content: self.system_prompt}] raw_budget int(self.max_context_tokens * 0.7) # 收集最近原始消息 raw_lines [] used 0 for msg in reversed(history): cost self._count_tokens([msg]) if used cost raw_budget: break raw_lines.append(msg) used cost older history[: len(history) - len(raw_lines)] result.extend(list(reversed(raw_lines))) # 对更早的历史生成摘要记得留出摘要预算 summary_budget self.max_context_tokens - used - self._count_tokens(result) - 200 if older and summary_budget 200: summary summarize_hist(older, self.encoder, summary_budget) result.insert(1, {role: system, content: f[历史摘要] {summary}}) return result这里有个小技巧插入的摘要消息放在索引1也就是紧跟系统提示词之后。模型读消息的顺序对注意力有影响把摘要放前面相当于给它一个“全局故事线”再让它读最近对话细节推导效果更稳定。3.4 把打包器接入LLM调用链打包器本身不依赖任何框架你可以把它插到任意调用链里。我有一个FastAPI接口请求体直接接收前端传来的历史消息和模式参数然后调用打包器最后把组装好的消息发给模型。from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class ChatRequest(BaseModel): history: list[dict] mode: str auto app.post(/chat) def chat(req: ChatRequest): packer ContextPacker(max_context_tokens3000, system_prompt你是一个项目助理) messages packer.pack(req.history, req.mode) # 调用模型这里用官方 SDK 示例 response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, max_tokens1000, ) return {reply: response.choices[0].message.content}接入的时候有个容易踩的坑前端传过来的history可能已经是大而全的你需要在存history时就同时存每条消息的时间戳和Token数。如果等请求到了再临时数一遍Token多花了时间不说还会因为编码不同而算不准。3.5 自动切换器的实现思路自动切换器可以写成一个独立函数输入是当前模式、历史长度、消息内容输出是要切换到的模式。我的规则如下如果当前模式是Auto且历史超过12轮并且消息里没有“记住”这类持久化关键词就切到Strict如果消息里出现“记住”“我叫”“以后”等词就切到Memory并且写入一条长期记忆如果当前是Memory没有新信息就保持Auto。def decide_mode(message: str, mode: str, history_len: int) - str: if any(k in message for k in [记住, 我叫, 我喜欢, 我住在]): return memory if mode auto and history_len 12 and len(message) 80: return strict return auto这个规则相当粗糙但是胜在零成本。如果你想更精确可以用一个小分类器模型替换decide_mode判断力度会好很多。我做第一版时就是这么干的后来发现规则足够应付80%的场景剩下的靠用户手动切换兜底。4. 常见问题与排查技巧实录4.1 摘要折叠后关键信息丢失症状用户在Auto Mode下聊了二十轮然后问“我之前说的那个离职率数字是多少”模型回复“根据您之前的描述离职率大约在百分之十几”。这就是摘要把精确数字丢了。排查思路不要只保存“总结性摘要”还要保存一个“实体清单”。我会让摘要生成时额外输出JSON格式的实体列表比如“离职率: 17%”“咖啡机: 德龙”。实体清单和摘要一起放进去。这样即使摘要本身不够精确模型在回答精确数字时也能从实体列表里找到答案。4.2 Token预估不准导致输出被截断症状模型回答到一半突然停了没有正常收尾。排查后发现max_context_tokens设置得太满模型输出预算被挤压到只剩几百token。解决办法给上下文预算留出10%到15%的余量别压到极限。比如模型窗口是4096你设max_context_tokens3000实际传给模型的总消息token最好控制在2600左右剩下400留作缓冲。这样即使消息里有几个特长的字词也不至于把输出预算挤掉。4.3 Strict模式下的“指代失忆”症状用户说“把刚才那封邮件再润色一下”结果Strict模式只保留了当前消息模型完全不知道邮件内容。排查思路这是Strict模式的天然缺陷不能靠修代码解决。我在这个模式下额外保留最近一条用户消息和助手响应能在一定程度上缓解指代问题。如果检测到用户消息以“它”“那个”“刚才”等指代词开头我会自动把模式升级为Auto并补传最近几轮历史。这里我建议你在日志里记录一下“Strict下被强制升级为Auto”的次数方便评估是否需要调整升级规则的阈值。4.4 日志与线上排查给context-mode装上仪表盘context-mode上线之后最重要的不是看用户反馈而是看运行日志。我给每条请求加了三组字段mode_used实际用的模式、prompt_tokens组装后消息的token数、truncated是否发生截断。线上排查时只要把这些字段汇总起来就能发现很多问题。举个例子某个用户反馈“AI总忘记我说过的话”查日志发现他几乎每轮都触发了Strict Mode因为我的规则里“历史超过12轮且消息超过80字”经常成立。但该用户习惯一次性输入大段背景而不是分开几轮说所以被误判为独立问题。看到这个规律后我把“消息超过80字”这个条件去掉了改成了“消息超过300字才切Strict”误判率立刻降下来。4.5 性能与成本优化建议最后说下成本。我试过把系统提示词也做Token压缩效果一般因为提示词本身不长省不出多少。真正的成本大头在历史消息反复重发。上线context-mode之后我的Token消耗平均降了40%响应时间缩短了30%。如果你想更进一步可以把摘要缓存起来同一个会话如果历史没有新增消息就直接复用上一次生成的摘要不再重新调用大模型。还有一个不起眼但很有用的优化在存储历史时同时存一份压缩后的消息版本。比如用户消息原样存一份用于展示另外存一份去掉停用词和口语词的版本用于发送给模型。这样消息Token数能再降一截。注意这个压缩版本只用于生成上下文不用于存储和检索否则会影响后续的全文搜索。5. 给同样在做context-mode的人一些实在建议我最后想说的是context-mode不是一个功能点而是一种思考方式。它逼着你去回答“什么信息值得保留、什么信息应该丢、什么信息要长期记住”这三个问题。这三个问题在每个项目里答案都不一样但设计框架是相通的。我的体会是不要一开始就想把所有情况都照顾到先落地一个Auto模式跑几周真实数据再根据日志里的问题去加其他模式。模式多了之后一定要给每个模式配日志和告警否则你根本不知道用户走得是哪条路。最怕的不是模式不够用而是模式切错了你还不知道。这套东西做完我自己再回去看那些没做context-mode的AI应用总觉得它们像是个没有短期记忆的人聊着聊着就接不上话了。赶紧去试试你会回来谢我的。