做AI应用开发的人十有八九会在同一个地方翻车——就是对话上下文的管理。我自己在做一个客服问答机器人的时候就深有体会用户连续问了几轮问题模型突然开始“失忆”把前面聊过的内容忘得一干二净。后来排查才发现问题不在模型本身而在于我怎么喂上下文给模型。那段折腾经历让我彻底搞明白了一个概念Context-Mode上下文模式。Context-Mode不是什么高深莫测的框架它就是一套管理“你给模型看多少历史内容、以什么形式看”的策略集合。在LLM应用里上下文直接影响回答质量、Token成本、响应速度这三件事。调不好轻则回答逻辑断裂重则直接超出模型上下文窗口报错。这篇文章我就把这套模式从设计思路到代码实现、从参数调优到生产环境踩坑完整梳理一遍希望能帮你少走几个月的弯路。1. 先说结论Context-Mode到底是什么1.1 从一次线上故障说起先讲一个真实的事。我之前维护过一个智能客服项目用的模型上下文窗口是8K Token。系统上线头两周一切正常第三周开始陆续有用户投诉说机器人“变笨了”明明前面几轮已经确认了订单号下一轮它又问一遍用户反复强调过退款原因模型在后续回答里还是会给出完全相反的方案。我一开始以为是模型版本的锅换了几个prompt都不见好。最后把某次完整会话的请求体打出来才发现问题一目了然——我每次请求都把全部聊天记录直接塞给模型包括系统提示词、用户历史消息、客服备注等内容。当会话累积到十几轮总Token早就超过8K了请求直接被截断最前面的系统指令和用户核心诉求反而被切掉了。你想想模型拿到的是一个“开头被砍掉一半”的对话历史它能回答好才怪。这个故障的核心就是当时没有设计任何上下文管理策略也就是没有定义业务的Context-Mode。1.2 Context-Mode要解决的三个核心问题经过那次事故我把Context-Mode拆解成三个问题来看给模型什么内容。不是所有对话记录都有价值系统提示词、用户当前问题、关键历史语义、中间过程的工具调用记录它们权重完全不同。以什么形式给。原始文本直接拼接还是先做摘要压缩或者把多轮对话转成结构化信息。给多少量。受限于模型的上下文窗口必须回答“在有限空间里优先级最高的是什么”。如果把这三个问题想清楚再抽象成代码里可以切换的模式其实就是在不同的业务场景下动态决定上下文的裁剪策略。后面说的四种模式本质就是这个问题在不同约束下的方案组合。2. 四种上下文模式的设计思路与取舍2.1 Full模式简单但烧钱Full模式也就是全量上下文最省事但最不省钱。做法就是保留会话开始以来的所有对话记录每次请求全部发给模型。优点也很明显理论上模型看到的信息最完整不会因为截断而误判“用户前面说过什么”。而且实现起来几乎没有额外逻辑拿个列表存消息请求时join一下就行。但缺点在实际项目中非常致命。举几个数字你就明白假设平均每轮问答消耗200 Token90轮对话后就是18K Token很多模型的上下文窗口直接爆掉。就算窗口撑得住按现在的API计费方式输入Token越多成本越高而且首字响应时间也会随着输入长度显著变慢。你想想用户问一句“你好”你每次都把十几K的历史全传过去这体验和成本都很难接受。Full模式比较适合的窗口期是短会话场景比如一次性问答、表单辅助填写、内部工具调用、或者用户明确要求“必须记住我说过的每一句话”的强一致性场景。大部分2C的聊天机器人一定不会长期跑Full。2.2 Window模式最通用的底线方案Window模式是我最推荐入门团队先落地的方案因为它简单、稳定、见效快。它的核心思路是只保留最近N轮或者最近M个Token的对话。超出窗口的那部分历史直接丢弃。听起来很粗暴但很多时候用户当前问题的答案确实只依赖最近几轮对话。比如下面这种场景用户我要退掉昨天买的耳机 助手请问您的订单号是 用户怎么查订单号这种对话模型只需要知道“用户要退耳机”以及“用户在问怎么查订单号”更早之前的寒暄和商品咨询记录其实都不重要。Window模式的关键是N的取值。我通常建议先按Token数来控制而不是按轮数。因为轮数和Token数并不线性相关用户一句话可能是5个Token也可能是500个Token。按Token做滑动窗口能更精确地控制在模型上下文窗口的占比一般设置成模型窗口的50%-70%左右比较稳剩下的空间要留给系统提示词、工具定义和当前问题的完整输入。不过Window模式有明显的天花板一旦关键信息出现在被窗口丢弃的那部分历史里模型就会“失忆”。所以如果你做的是需要长期记忆的场景Window只能算基座不能算终局。2.3 Summary模式让长对话不“失忆”Summary模式也叫摘要压缩模式是处理长对话的经典思路。它的做法是当对话历史超过一定长度时启动一个压缩流程把较早的对话内容交给模型生成一份摘要之后只保留摘要和最近几轮完整对话。听起来很美但它有几个容易被忽视的坑。第一压缩本身需要调用一次模型消耗额外的Token和时间。如果每三轮就压缩一次成本反而可能比Full模式还高。我的实践是做“分级压缩”先设置一个阈值比如总上下文到6K Token时启动压缩后把历史归约为400-600 Token的摘要给最近对话保留充足空间。第二摘要生成的质量直接决定了后续回答的准确性。模型在总结时可能漏掉用户提过的重要限制条件比如“不要推荐含酒精的护肤品”摘要里一旦弄丢后面模型就会放飞自我。针对这一点我会在压缩prompt里加一条指令列出所有带否定表述的用户指令逐字保留。用这种细节来对抗信息丢失。第三压缩过程要尽量对用户无感。服务端在接到新消息后如果发现上下文超限先异步做摘要紧接着再用“摘要最近消息”去请求主模型不要让用户白白等一次额外调用。Summary模式适合那些对话轮次长且历史信息有持续参考价值的场景比如在线问诊、法律咨询、私人助教。这些场景的共同特点是用户可能和AI聊几周但最近几轮对话之外的背景信息不能丢。2.4 Hybrid模式成本和质量之间的折中Hybrid模式是我现在最喜欢用的也是我个人认为Context-Mode真正的精髓所在。它不固定用一种策略而是根据每次请求的具体情况动态选择。具体做法也不复杂先给会话里的每条消息打上标签判断它的类型和重要性。系统提示词永远保留用户当前的提问永远完整保留历史对话里如果包含结构化信息订单号、身份证号、需求清单就保留原文纯寒暄、超长且无关键实体的中间轮次则压缩成摘要。落到代码里就是在组装请求前算一次“当前上下文预算”。计算公式大概是可分配Token 模型窗口大小 - 系统提示词Token数 - 工具定义Token数 - 当前输入Token数拿到这个预算后再决定从摘要池和完整历史池里各取多少内容。预算充足时多保留原文预算紧张时优先保证当前问题完整历史部分全部走摘要。Hybrid模式的好处是质量稳定成本和延迟都可控。但它的难度也最大因为需要你自己定义消息的重要性打分规则。别指望模型自己判断你得通过业务规则来定。比如金融客服场景里“转账”“退款”“投诉”这些词出现过的消息权重直接标最高正常闲聊则标最低。这套规则最好沉淀成配置文件方便后续调整。3. 实操从零实现一个Context-Mode模块3.1 数据模型与存储设计理论讲再多不动手都是空的。我分享一个可以直接复用的实现思路核心语言用Python存储可以用Redis或者任意KV数据库。先设计消息的数据结构。一条消息最少要有这几个字段{ role: user, # user / assistant / system content: 我要退掉昨天的耳机, ts: 1690000000, # 消息时间戳 priority: 2, # 0低 1中 2高 msg_id: uuid-xxx, round_id: 7 # 第几轮对话 }存储上我习惯用Redis的List结构以会话ID为key按时间顺序存消息。同时维护一个独立的摘要字段单独存压缩后的历史。import redis import json r redis.Redis(hostlocalhost, port6379, db0) def append_message(session_id: str, message: dict): r.rpush(fsession:{session_id}:messages, json.dumps(message, ensure_asciiFalse)) def get_messages(session_id: str, start: int 0, end: int -1): raw_list r.lrange(fsession:{session_id}:messages, start, end) return [json.loads(item) for item in raw_list] def save_summary(session_id: str, summary: str): r.set(fsession:{session_id}:summary, summary)如果会话量非常大建议对List按天做归档避免单条List过长导致查询变慢。用Redis的Stream类型也可以但List对中小团队来说最简单排查问题也方便。3.2 核心调度逻辑上下文管理器是整个模块的中枢它的职责就一句话根据当前会话状态决定最终发给模型的消息列表。我用一个简化的类来说明class ContextManager: def __init__(self, model_window8000, system_prompt..., reserve_ratio0.3): self.model_window model_window self.reserve_ratio reserve_ratio # 预留空间比例 def build_context(self, session_id: str, current_user_message: str): messages get_messages(session_id) summary r.get(fsession:{session_id}:summary) # 计算可用预算 system_tokens estimate_tokens(self.system_prompt) current_tokens estimate_tokens(current_user_message) available self.model_window - system_tokens - current_tokens available - self.model_window * self.reserve_ratio if available 0: raise ValueError(当前消息超出上下文窗口请精简后重试) history_tokens sum(estimate_tokens(m[content]) for m in messages) # 预算充足走 Full if history_tokens available: return [{role: system, content: self.system_prompt}] messages [ {role: user, content: current_user_message} ] # 预算不足走 Hybrid high_priority [m for m in messages if m[priority] 2] low_priority [m for m in messages if m[priority] 2] high_tokens sum(estimate_tokens(m[content]) for m in high_priority) low_allowed available - high_tokens if low_allowed 0: low_used self._fit_low_priority(low_priority, low_allowed) else: low_used [] if summary: summary_block {role: system, content: f[历史摘要] {summary}} else: summary_block {role: system, content: [历史摘要] 无} return ( [{role: system, content: self.system_prompt}] [summary_block] high_priority low_used [{role: user, content: current_user_message}] ) def _fit_low_priority(self, messages, budget): result [] used 0 # 从最新的低优先级消息开始往前取保证最近信息优先 for m in reversed(messages): t estimate_tokens(m[content]) if used t budget: break result.append(m) used t return list(reversed(result))这段代码里的estimate_tokens函数生产环境请务必用模型官方Tokenizer来计算不要用len(content)那种偷懒写法。中文字符和英文字符的Token比例差距很大不精确计算会导致实际大小和预估差出几倍。3.3 接入大模型API的关键细节拼接好上下文之后调用大模型API本身也有讲究。以OpenAI兼容接口为例def chat(manager, session_id, user_message): context_messages manager.build_context(session_id, user_message) response openai.ChatCompletion.create( modelgpt-4o-mini, messagescontext_messages, temperature0.7, timeout30, ) assistant_reply response.choices[0].message.content append_message(session_id, {role: user, content: user_message, priority: 2, ts: time.time()}) append_message(session_id, {role: assistant, content: assistant_reply, priority: 1, ts: time.time()}) maybe_summarize(session_id) return assistant_reply还有一个非常容易忽略的点系统提示词本身也要参与Token预算计算。很多人只算用户消息的Token忽略系统提示词和工具定义结果就是实际请求超出窗口被API直接拒绝。另一个细节是某些模型的API会对system消息有数量限制像我前面把摘要也塞进system角色的做法在个别模型上可能报错。稳妥的兼容做法是用user角色来承载摘要块前面加一个[历史摘要]前缀这样模型能理解它的含义又不会触发角色限制。4. 参数调优与效果对比4.1 核心参数怎么定Context-Mode能不能跑好参数设定占了80%的功劳。第一个参数是Token预算分配。我把模型窗口大致按这个比例切系统提示词占10%-20%当前输入占20%-30%历史分配占40%-50%预留余量占10%-20%。如果你有工具调用的需求还得单独再留出工具定义的空间。第二个参数是滑动窗口的轮数或Token数。按我的经验普通客服场景最近10轮完整对话足以覆盖90%以上的提问需求。如果模型窗口是8K10轮对话大约占3K-4K Token加上系统提示词和当前输入刚好在安全范围内。第三个参数是摘要触发阈值。我建议设置两个阈值形成滞回区间。比如上下文总量达到6K时触发压缩压缩到3K以下才停止。不要设成“一到6K就压、一低于6K就停”否则会频繁触发压缩白白消耗Token。这种滞回设计是从位图法或者缓存淘汰策略里借来的思路能让系统状态更稳定。4.2 三种模式的效果实测与成本对比我拿一个真实场景跑过对比场景是模拟客户连续咨询30轮内容涉及订单查询、退款申请、地址修改等多类问题。模型用gpt-4o-mini上下文窗口16K。模式平均单次请求Token消耗30轮总成本估算回答完整率首字响应耗时Full3200偏高97%1.8sWindow(10轮)2100中78%1.2sSummary1900中低88%1.3sHybrid2400中95%1.4s回答完整率怎么定义我找了三个人工标注员看模型的回答是否准确引用了前文信息。结果很能说明问题Window模式虽然最便宜但回答完整率只有78%明显“偏科”。Summary模式通过摘要挽回了一部分长期记忆完整率能到88%但摘要丢失细节的问题仍然存在尤其在涉及精确数字的对话里。Hybrid模式完整率接近Full模式成本却低了不少首字响应也几乎没有明显劣化。所以我现在的默认建议是先上Window模式保证系统能跑后续再迁移到Hybrid模式。Full模式作为兜底方案只在特殊情况用。5. 常见问题排查与我的避坑心得5.1 典型问题速查表我把实际运维中碰到过的问题整理成了表格方便你直接对照现象可能原因排查方法解决方案模型报超出上下文窗口错误Token预算没算系统提示词和工具定义打印发送前的messages列表逐个统计Token在build_context里扣掉系统提示词的开销用户说“你忘了之前说的”关键信息被滑动窗口丢弃查看窗口内的消息时间跨度把高优先级消息单独保留或切到Hybrid摘要生成后回答质量下降压缩prompt没有强调保留否定句和数字对比摘要原文检查压缩逻辑在压缩prompt中强制保留“禁止”“不要”等否定表述延迟明显增加压缩流程串行阻塞观察请求耗时分布把摘要压缩改为异步预生成相同问题在不同模式下答案不一致上下文模式差异导致固定模式做A/B测试用日志记录每次请求使用的模式方便回溯5.2 我在生产环境踩过的几个坑第一个坑把摘要直接放在system消息里。当时图省事摘要和系统提示词合在一起结果某次模型升级后摘要对回答的影响权重被放大了模型开始把“历史摘要”当成“系统指令”来执行出现了一些诡异的回答。后来我把摘要和系统指令彻底分开并且把摘要放在历史消息区内这个问题才消失。第二个坑忽略并发会话的上下文隔离。最初我用一个全局变量缓存摘要结果用户A的摘要串到了用户B的对话里。这个低级错误在流量上来之后立刻暴露日志里全是驴唇不对马嘴的回复。教训是上下文必须严格按session_id做隔离任何全局共享都要不得。第三个坑压缩太频繁。我一开始设置的阈值是4K Token一触发就压缩结果一轮30分钟的对话压缩了二十次总Token消耗反而比Full模式还多。后来改成阈值6K、压缩到3K的滞回策略压缩次数大幅减少成本立刻降下来。第四个坑没有日志记录当前的Context-Mode。生产环境经常遇到用户投诉但你在事后不知道当时系统用的是哪种模式等于无法复现问题。我现在把模式名、Token明细、是否触发压缩这些字段全部写入日志排查效率高了一个量级。最后一个心得Context-Mode不是一次性设计完就固定不变的方案它需要根据业务数据持续调优。我建议每两周看一次日志里的模式分布、Token消耗和用户投诉率找到那些频繁走摘要但用户仍然满意的场景再针对性调整优先级规则。这段调优过程没有捷径只能靠对业务的理解和对数据的敏感度慢慢磨。