1. 为什么“能聊很多轮的机器人”反而会越聊越笨——context-mode要解决的真实问题接入大模型API做聊天机器人第一个月往往是最兴奋的。搭个前端、调个接口、角色扮演一下就能做出一个像模像样的对话助手。但等用户真正用起来问题就来了用户跟机器人聊了二十分钟前面的信息它一条都记不住。你说“我刚刚不是说了我家猫叫咪咪吗”它一脸茫然地反问“咪咪是谁”。我当时第一反应是“模型记忆力不行”于是把所有历史消息一股脑塞进下一次请求里。结果呢上下文一长费用肉眼可见地涨回答质量反而断崖式下跌。明明第一轮时逻辑清晰的模型聊到三十轮之后开始答非所问、重复啰嗦甚至把用户早先说过的话当成自己说的。这个问题本质不在模型而在“context-mode”——上下文模式或者更准确地说你在调用API时如何组织、裁剪、传递对话历史。Context-mode就是处理这个问题的一整套方案请求里到底带什么内容、带多少轮、按什么策略保留关键信息、丢弃冗余内容。它直接决定了模型“每次看到的世界”长什么样。你可以把每一次API请求都理解成“模型睁眼的一瞬间”它没有你想象中的人脑记忆它只有你喂给它的那串文字。所以context-mode设计的本质就是决定“这一瞬间模型应该看到什么”。这篇文章我想把context-mode从原理到落地讲透包括token到底怎么算、三种主流上下文策略各自适合什么场景、以及我实际开发中踩过的那些坑。如果你是刚开始做基于LLM API的应用开发或者正被“多轮对话越来越笨”困扰这篇应该能帮你省掉不少调试时间。1.1 上下文窗口的物理限制与“伪记忆”先明确一个基础概念上下文窗口context window。每个模型都有最大上下文限制比如某些模型支持128K token一些老模型只有4K、8K、16K。这个数字意味着一次请求里所有能放进来的文本包括系统提示、历史对话、用户最新消息、模型已经生成的回复加起来不能超过这个量。很多人把“大上下文”理解成“无限的记忆”这是最大的误解。哪怕你有一个128K的窗口模型也没有“检索”能力——它不会主动去128K里翻找“我五十分钟前提到过的那个地址”。它只是把这128K文本当作一个连续的文字流基于前面的内容预测下一个token。窗口越大越靠前的信息在注意力机制中占比越弱模型对早期内容的“记忆”其实很模糊。这就是为什么你把全部历史都塞进去模型反而越聊越笨。拿一个非常生活化的例子打比方你让一个人读一份两百页的报告然后立刻回答细节他大概率只能记住最近几十页的内容。大模型也一样——它能“看到”全部但注意力资源有限早期信息会被稀释。context-mode的价值就是替模型筛选只给它真正重要的那几页。1.2 Context Mode的核心作用控制“模型看到什么”既然模型本质上只有“每次睁眼看到的内容”而没有记忆context-mode就承担了两个关键任务一是把需要模型记住的关键信息显式地放进上下文二是把已经不需要的旧内容从上下文中移除省出宝贵的token空间给新内容。举个例子你做一个客服机器人。用户先咨询了退款政策然后聊了十分钟物流问题最后又问退款进度。这时候模型真正需要的是用户的退款单号、订单状态、客服规则而不是中途关于物流的那十分钟闲聊记录。一个好的context-mode策略会在用户聊到退款进度时把“物流话题”压缩成一行摘要甚至直接丢弃但把退款单号原封不动保留。模型看到的内容从“一整段冗长聊天记录”变成了“一个清晰的当前问题概览”回答质量当然会提升。所以不要在context-mode上偷懒。它是你花费最多时间调优、也最能直接决定产品体验的模块。后面的几个章节我会逐步拆解它是怎么工作的以及怎么把它做到位。2. 拆解context-mode的核心机制messages结构、角色分工与token定价要真正理解context-mode就不能停在“把历史消息都带上”这种粗浅的用法上。API的请求格式本身就是上下文模式的骨架。你把结构理解了后面的策略才有根。2.1 一次API调用的完整“输入配方”大多数主流LLM API都以一个messages数组作为输入。数组里每一项是一个消息对象通常包含role和content两个字段。role有几种固定取值system、user、assistant部分API还有tool或function角色。我举一个最标准的例子messages [ {role: system, content: 你是一个电商客服助手回答要简洁不要编造订单信息。}, {role: user, content: 你好我上周买的耳机想退货。}, {role: assistant, content: 你好请提供订单号我帮您查询退货政策。}, {role: user, content: 订单号是20240911-8899但是我已经拆封了还能退吗} ]这次请求模型能“看到”的全部信息就是这四条消息。模型不会记得“你上周买过耳机”之外的东西因为除此之外你什么都没给它。而如果你希望它记住用户更早之前说过的话就必须把那些历史消息以同样的格式加进数组。这就是context-mode最底层的机制你对上下文的控制本质上就是对messages数组的控制。你往里面加什么、删什么、压缩什么决定了模型每一次回复的输入基础。2.2 角色分工为什么重要刚开始调API的人最容易犯的一个错误是把所有历史对话不加区分地交给模型或者甚至把用户说过的所有话都混在一条消息里。这两种做法都会让模型“角色错乱”。system角色是模型的行为框架相当于公司规章制度。它影响最大但也最容易被长对话中的大量历史淹没——如果上下文里有几十轮聊天模型到后面会慢慢“忘记”system里的指令因为它在文字流中占的比例太小了。所以很多做生产级对话系统的人不只是把system放在最前面还会在关键节点重复注入一次。这不是系统提示词写的问题而是上下文长度稀释了它的权重。user和assistant角色则负责维持对话的秩序。模型知道assistant角色发出去的内容是“自己说的”这会直接影响后续回复的口吻和立场。如果你把assistant的历史回复误删了模型下一次再收到用户追问时就不知道自己之前给出了什么承诺很容易前后矛盾。我见过一个实际案例用户问售后政策assistant之前承诺“可以免费换新”但工程上把那条assistant消息裁剪掉了下一次请求模型一本正经说“我们从不提供免费换新”。这属于context-mode裁剪策略设计失误导致的用户体验事故。还有一个细节是部分API要求严格的角色轮换顺序user、assistant交替出现不能连用两个user或两个assistant。当你做摘要压缩或系统注入时特别容易打破这个顺序需要主动用assistant角色填充过渡消息。后面写代码的时候我会给示范。2.3 Token不是字数计价背后的数学Token才是上下文真正的计量单位。一个token不是一个字而是一个“原子片段”。英文中一个单词通常拆成一到两个token中文里一个汉字大约对应1到2个token。不同模型用不同分词器同一个词在不同模型里的token数量都可能不一样。我这里有组实测参考值一段约2000个汉字的对话文本在常见模型下大概会消耗2800到3500个token一段1000字的英文文档大概是450到550个token。看到差距了吗中文的token效率其实不高同样的信息量需要更多token。而token直接等于钱。大多数API按输入token和输出token分别计价输入token便宜一些输出token更贵。如果你的历史消息不做裁剪一场30轮的深度对话可能每次请求都要消耗几十K的输入token。一天一万次请求成本能到很高的两位数甚至三位数以美元计。这也是context-mode在工程上必须存在的最直接理由——不管理上下文你的账单就先失控了。还有个容易被忽略的subtlety系统消息也占token。很多人做context-mode时才意识到自己那条又长又详细的system prompt本来就在吃预算。如果你同时维护一个2000字的system和一个完整的聊天记录可能随便一聊就到上下文上限了。所以把system prompt写精炼不只是“提示词技巧”它本身就是context-mode的一部分。3. 三种最常见的context-mode策略对比与取舍原理懂了下一步是选择具体的上下文管理策略。目前业界主流的方案可以归纳为三大类滑动窗口、滚动摘要、向量检索召回。它们不是互斥的成熟系统往往叠加使用但你必须先理解各自的适用边界。3.1 滑动窗口简单粗暴但有效滑动窗口的思路非常直白只保留最近N轮对话更早的一律丢弃。N可以按轮数算比如“只保留最近10轮”也可以按token数算比如“只要总token超过6000就从头开始删”。这个方案的优点是实现成本极低逻辑完全可控几乎不会出错特别适合早期版本或上下文需求简单的工具型产品比如单轮问答工具、客服FAQ查询。缺点是粗暴——它不区分信息的重要程度早先聊过但重要的信息比如用户的订单号、用户对某件事的明确偏好会跟着被丢进垃圾桶。我给一个判断标准如果你的产品里用户会在明确引用几分钟前的信息“我之前说过的那个XX”滑动窗口大概率不够用。但如果你的产品是“用户问一句、模型答一句、结束了”滑动窗口就是最优解不用为了追求复杂而复杂。3.2 滚动摘要压缩出“记忆主干”滚动摘要rolling summary在滑动窗口基础上做了一层升级把被裁剪掉的旧内容用一次额外的模型调用总结成几句话塞进system消息里然后只保留最近几轮完整对话。这样模型既能“想起来”早先的事又不至于让token失控。实际执行流程大致是维护两条消息一条是“历史摘要”一条是“最近对话列表”。当最近对话超过预设阈值比如5000 token触发摘要更新。把当前摘要和最早的那几轮对话发给模型要求它“压缩生成新摘要”摘要覆盖旧摘要和这些早期对话。新摘要写回“历史摘要”位置被压缩掉的早期对话从列表移除。我就用这种方式做过一个咨询类聊天机器人效果非常明显长对话的保持能力上来了每次请求的token消耗被压在一个平稳水平不会再线性膨胀。代价是每触发一次摘要压缩就多消耗一次模型调用增加了一点延迟和费用。所以摘要触发阈值要调不能太频繁比如等到旧对话积累到一定量才压缩一次。摘要的策略还有一个变体按对话片段保留关键实体而不是笼统摘要。比如用户提过的订单号、地址、偏好用JSON提炼出来保存在摘要字段里{ user_profile: { order_id: 20240911-8899, return_status: pending }, context_summary: 用户咨询退款问题订单已拆封正在等待售后审批。 }这种方式让模型在回答需要精确信息的场景时更稳定尤其适合客服、电商助手类应用。笼统摘要的问题是靠模型自己决定重点但模型“觉得重要”的不一定是业务上真正重要的显式结构化的实体信息能把这个不确定性降到最低。3.3 向量召回让长上下文变成可检索数据库第三种策略适合超长会话或知识库问答场景把所有历史消息做向量化处理存进向量数据库。每次新的提问到来时先做一次语义检索挑出与当前问题最相关的几条历史消息再拼进messages数组。这样无论对话历史多长传给模型的都只有“被检索出来的精华”。这个方案的上限很高能支持跨几十个不同话题的复杂会话模型也不会因为总历史太大而变笨。但工程复杂度也明显上升你要维护一个向量库、要处理embedding调用的成本、要调检索的相似度阈值。而且向量检索本身也不是完美——语义相似不等于信息关键比如用户问“我那个订单退款到哪一步了”语义上跟“退款进度”高度相关却可能漏掉用户一开头提到的“我是黑卡会员享受优先处理”这条完全不相似的但对于当前答复很重要的线索。所以在实际系统中我更倾向于把向量召回和规则提取组合向量解决“找话题相关段”规则和实体提取解决“找结构化事实”。需要索引的不过是一万条聊天记录里真正有业务价值的那些实体字段用结构化信息来兜底。三种策略放一起对比策略实现成本上下文保持能力token消耗趋势适合场景滑动窗口低低稳定但会丢信息短会话工具型产品滚动摘要中中高稳定且信息保持好客服、咨询类机器人向量召回高高与检索量挂钩超长会话、知识库问答4. 手写一个基于context-mode的对话服务完整代码与参数细节光讲原理必然空洞我直接把一个可运行的对话服务完整写给你看。这个服务使用Python依赖openai库但核心逻辑你换成任何其他大模型SDK都成立。它实现了“滑动窗口滚动摘要”的混合模式并在注释里解释每个关键参数为什么这么定。4.1 基础版维护messages并自动裁剪先看最基础的滑动窗口实现。核心是维护一个messages数组并在追加新消息前检查总token数import tiktoken class ContextManager: def __init__(self, max_tokens6000, max_messages20): self.max_tokens max_tokens self.max_messages max_messages self.encoder tiktoken.encoding_for_model(gpt-4) self.messages [] def count_tokens(self, messages): # 计算单个消息列表的总token数注意不同模型的计价方式略有差异 return sum(len(self.encoder.encode(msg[content])) for msg in messages) def append(self, role, content): self.messages.append({role: role, content: content}) # 裁剪策略优先裁最早的user/assistant消息保留system消息 while self.count_tokens(self.messages) self.max_tokens: for i, msg in enumerate(self.messages): if msg[role] ! system: self.messages.pop(i) break def get_messages(self): return self.messages看到关键参数了吗max_tokens6000是因为我把输出token预算按1000估计加上一个系统提示词确保总上下文不超过7K远离模型窗口上限。留出buffer非常重要因为你的代码是估算API内部对消息还有一些额外的格式占位token只算content会低估实际消耗。4.2 进阶版token预算分配与摘要降级策略实际生产环境不能用这种单纯裁剪。我把滚动摘要集成进来做一个完整的会话状态类import json import tiktoken class SessionMemory: def __init__(self, system_prompt, summary_threshold4500, max_context7000): self.system_prompt system_prompt self.summary self.recent_messages [] # 最近对话保留完整形式 self.summary_threshold summary_threshold self.max_context max_context self.encoder tiktoken.encoding_for_model(gpt-4) def construct_messages(self): messages [ {role: system, content: self.system_prompt} ] if self.summary: messages.append({ role: system, content: f以下是此前对话的摘要请将它作为事实依据{self.summary} }) messages.extend(self.recent_messages) return messages def append_exchange(self, user_msg, assistant_msg): self.recent_messages.append({role: user, content: user_msg}) self.recent_messages.append({role: assistant, content: assistant_msg}) self._maybe_compress() def _maybe_compress(self): tokens self._count_tokens(self.recent_messages) if tokens self.summary_threshold: return # 把最早的一半消息压缩进摘要实际项目中触发次数要按业务调优 compress_count max(len(self.recent_messages) // 2, 2) oldest self.recent_messages[:compress_count] self.recent_messages self.recent_messages[compress_count:] self.summary self._summarize(oldest, self.summary) def _summarize(self, messages, old_summary): prompt ( 把对话历史压缩为简洁摘要。如果已有摘要请在原有基础上合并更新 保留用户的订单号、地址、偏好等关键事实。不要臆造信息。 ) payload [ {role: system, content: prompt}, {role: user, content: f已有摘要{old_summary}\n新对话{json.dumps(messages, ensure_asciiFalse)}} ] # 这里调用你的模型接口返回压缩后的summary文本 response call_llm(payload) return response def _count_tokens(self, messages): return sum(len(self.encoder.encode(msg[content])) for msg in messages)这个结构的核心亮点是摘要和最近对话被分开了。摘要进system完整历史留在recent两者互不干扰。压缩的触发频率也不是按轮数而是按token数这样无论用户发长消息还是短消息逻辑都自动均衡。summary_threshold4500的意思是我希望完整对话最多只占4.5K token再加上摘要和system总上下文保持在7K以内留足安全余量。4.3 必须注意的count_tokens精度问题tiktoken的用法比表面看上去麻烦。不同模型的tokenizer不一样比如gpt-4、gpt-3.5-turbo、以及gpt-4-turbo系列用的编码器版本是不同的。最保险的做法是def get_encoder(model_name): try: return tiktoken.encoding_for_model(model_name) except KeyError: return tiktoken.get_encoding(cl100k_base)encoding_for_model查不到新模型时会抛KeyError要回退到基础编码。另外tiktoken只对消息的content字段计算API内部还会为每条消息额外加几个token比如角色标识、消息分隔符。如果你严格贴近上限可能算出来是6999但API实际消耗是7020直接被拒或者被截断。所以我个人习惯是程序内部计算值永远比API限制低10%~15%多出来的buffer没人会怪你。另一个精度问题是当对话里出现函数调用、图片输入、工具结果时context-mode的token计算会更复杂。这些内容不以纯字符串形式存在你的计数逻辑要单独处理。否则裁剪逻辑会在异常输入上算错导致突然一次调用爆上下文。我建议从一开始就把“非文本输入”的数量和内容单独记录而不是强行拼进content文本里。5. 实测数据与踩坑记录上下文过长时模型到底会发生什么这一章我整理了自己做长会话调优时的一手观测包括报错类型、回答质量的量化对比和几个容易被忽视的生产事故。这些数据都是快照性质模型更新后数值会变化但趋势和教训是可复用的。5.1 上下文超过窗口时的报错类型先看最常见的失败模式。当你把超出上下文窗口的输入发给API通常会得到类似这样的错误InvalidRequestError: This models maximum context length is 8192 tokens. However, you requested 9741 tokens (9057 in the input, 684 in the output).或者更简化的Please reduce the length of the messages or completion.很多人以为API会帮你做“智能截断”其实不会。它只是粗暴地拒绝请求你的用户当场看到一条错误信息。生产环境里必须避免用户触发这个错误方法就是保证自己维护的消息列表永远不会到达模型上限——这是context-mode存在的底线理由。我曾经犯过一个低级错误只统计了历史消息的token但忘了把用户新输入的长度也算进去。用户发了一篇粘贴的几千字长文直接撑爆上下文。所有上下文管理逻辑都不该在请求发出前临时计算而是在每次append时实时计算并且预留输出token空间。5.2 同一会话在上下文裁剪前后的回答质量对比我做过一个很直观的测试同一个咨询会话多轮聊天记录分别用三种方式请求模型回答 1完整上下文40轮约16K tokens 2滑动窗口最近10轮 3滚动摘要最近5轮全文。三个答案的质量差异非常明显。完整上下文那个虽然模型“看过”所有内容但它在回答“用户最初提到的预算要求”时竟然错了因为它对早期细节已经是模糊状态而且前文信息之间的注意力互相干扰。最近10轮窗口方案丢了早早提到的一个重要前提而滚动摘要方案三个问题都答对了token成本只用了大概2的60%。这个实验让我确认了一个结论“上下文越多模型越聪明”是错觉。模型在长上下文上的“注意力稀释”导致纯粹堆历史并不能提升早前信息的记忆率。真正可靠的做法是把早期事实显式提炼到摘要里而不是指望去翻历史。5.3 实际开发中最容易忽略的system prompt膨胀做context-mode的时候很多人只盯着历史对话长度忘了system prompt本身也在膨胀。比如一开始你写了一份客服规范后来产品要求加商品信息、加优惠规则、加工单指引一条条往system里塞一个月后system prompt变成了三千字。我发现这个问题的契机是一次线上故障一个只聊了3轮的短会话输入token竟然已经8K。排查后发现查这些token全在system prompt里。当时才意识到长system prompt有两个副作用一是它的token开销在每一次请求里都是固定的用户提问越短这个固定开销占比就越尴尬二是它占据了模型上下文中的注意力比例挤占了对话内容的占比。为此我有一套“system分层”的做法把固定的规范如何回话、禁止事项放最顶层把动态知识当前商品、当前活动放第二层把历史摘要放第三层最后才是对话记录。动态知识可以按需刷新比如用户问退款时才注入退款政策详情。用这个分层法典型请求的输入token能从8K降到3K效果立竿见影。6. 长期会话的下一步会话窗口设计之外的工程配套context-mode不只是内存里的一组messages数组生产环境还牵扯到会话持久化、多用户隔离、成本监控。很多项目在单个会话里调好一到多用户并发就崩多数崩在“上下文串台”。6.1 会话状态保存与恢复用户并不会一次性聊完40轮。服务重启、断网、刷新页面都会中断会话。所以每轮交互结束后你要把当前消息列表和摘要状态序列化存起来。用Redis做KV存储是比较常见的方案key是session_idvalue是JSON序列化后的状态。def save_session(session_id, memory: SessionMemory): payload { summary: memory.summary, recent_messages: memory.recent_messages, updated_at: timestamp() } redis.set(fsession:{session_id}, json.dumps(payload, ensure_asciiFalse), ex3600 * 24)这里有个经验过期时间要按业务设计。客服场景保留一天足够有些场景需要30天。过期时间越长存储成本越高而其中大量的早期信息根本不会再被访问。所以我更推荐“Redis只存最近N天活跃会话”长尾会话在下次访问时走向量库检索重建而不是全量恢复。6.2 多用户场景下的上下文隔离很多人写demo时用一个全局messages变量自己测没问题一上线就出大事A用户的问题和B用户的聊天记录混在一起模型给出的回答里甚至带出了别人的姓名和订单号。这在context-mode里是个严肃的工程红线。每个请求必须从session_id解析出独立的会话状态绝不能做成共享可变状态。我的做法是在接口入口处就建立session_id和SessionMemory的一一映射每个用户操作自己的内存对象互不干扰。同时给session_id加前缀区分业务场景比如order_bot:u123:s456这样排查问题时可以快速定位来源。并发场景还有一个暗坑同一个用户的多个并发请求可能导致消息列表被重复追加。比如用户连点两次“发送”两个请求同时读取同一个消息列表各自带上不同的新消息然后各自更新存储互相覆盖。所以需要给会话操作加一把锁或者采用“乐观锁版本号”的更新策略。我用Redis的SET key value NX做简单锁即可锁过期时间设3秒确保同一用户的请求串行更新。6.3 成本监控与优化最后context-mode调优的终极目标之一是控成本。我维护一个简单的日志表记录每次请求的输入token、输出token、session_id和触发时间。每周跑一次统计能看到整体token消耗的分布特征。如果发现某些会话的输入token长期偏高说明摘要压缩阈值设置得太大或太保守要调整。另一个成本优化技巧是把用户的“长期事实”单独存储而不需要重放对话历史来获取。比如用户改了收货地址直接在存储里更新地址字段下次构建messages时只带地址结果不带用户修改地址的那两三轮对话。这样历史对话可以更快被裁剪token消耗进一步下降。从我个人的经验看一个被认真设计的context-mode能让每千次请求的输入token消耗下降40%到60%同时回答质量的稳定性反而上升。这不是夸张——信息的“信噪比”提高了模型当然听话了。上下文管理从来不是“为了省钱的妥协”它本身就是质量的一部分。如果你正准备给应用接入大模型API我建议你从第一行代码起就把context-mode当成一等公民来设计先定token预算、再定裁剪策略、最后写业务逻辑。等上线后再回头补你会发现自己得重构大半接口。这几个参数踩过的坑都能在前几个项目暴露出来早设计早省心。