最开始让我对 context-mode 这个说法产生警觉的是一次线上事故。当时我维护的智能客服机器人上线第一个月还正常第二个月开始频繁出现答非所问用户明明刚才已经填好了所在城市和售后单号下一句问那大概什么时候能修好它居然反问请问您所在的地区是。后台日志一拉发现问题出在上下文管理上会话超过 20 轮后模型收到的历史消息已经接近上下文窗口上限系统做了暴力截断只保留了末尾 4 条消息。更麻烦的是每轮回答必须携带的固定角色设定、工具定义和外部知识片段也在截断中被丢了。模型倒是没崩它只是像一个刚入职就被人删了工位资料的实习生嘴上说好的没问题实际上什么都不记得。这之后我花了一整周把 context-mode 从概念到工程实践重新梳理了一遍。坦率讲这是每一个做 LLM 应用落地的人都绕不开的坎模型本身的对话能力大家都差不多真正决定产品体验上限的往往是谁能把上下文这三个字管得更好。围绕这个话题这篇文章我会把 context-mode 的核心原理、常见模式的选型逻辑、上下文窗口溢出的应对策略以及我在实际项目里踩过的坑和最终落地的方案一次性讲清楚。无论你是刚开始接 API 做 Demo还是已经在生产环境里被用户质量问题折磨到怀疑人生这篇内容应该都能帮上忙。1. 先别急着写代码搞清楚 context-mode 到底在解决什么问题很多教程一上来就教你如何设置上下文轮数如何用滑动窗口但如果你不清楚这一切到底在解决什么问题你调参的时候基本就是瞎猫碰死耗子。所以我先花点篇幅把上下文的本质这件事讲透。1.1 模型并没有你想的那么能记我见过太多人把大模型理解成塞给它多少信息它都能记住然后慢慢回忆出来。真实情况完全不是这样。Transformer 架构的模型核心机制是自注意力。它每一次生成 token你可以把 token 粗略理解成一小块文字都要对着输入序列里所有的 token 去重新计算一遍注意力权重。这意味着模型在生成时看得到的信息取决于你这次请求给它的完整输入是什么。它不是一个人没有大脑皮层的记忆功能它只有一双眼睛你给它看多少它就基于多少来作答。打个比方你跟一个同事合作项目这个同事每次行动前只允许翻看你递给他的那几张便签纸。上一轮你告诉他的信息如果没有写进这一轮的便签纸里他这一轮就是不知道的——哪怕这些信息是五分钟前你自己亲口说的。所以上下文模式这个词本质上是在描述一个问题每次请求你打算把过去哪些信息重新塞给模型看是一次都不给让它每次作答都当初次见面还是给最近几轮的对话还是给全部历史对话外加知识库检索内容1.2 context-mode 不是一个开关而是一套策略如果你去翻各大模型平台的文档很多地方确实会提供一个叫 context 或 session 相关的参数看起来像一个开关。但工程上context-mode 真正指的是一套输入组装策略它由三个核心部分组成历史对话的选取范围保留最近 N 轮还是全部保留还是按时间衰减系统提示与固定上下文角色设定、指令、工具说明、知识库片段这些永远在场的信息如何安置怎么防止它们被挤出窗口。溢出后的降级策略窗口满了怎么办截断掉最早的消息还是把前面的内容总结成摘要继续喂给模型你只有把这三件事全部设计清楚才算是真的理解了 context-mode。只设置一个max_turns20那只是「截断」谈不上模式设计。1.3 为什么这个问题在落地阶段会被无限放大如果你只是自己在 Playground 里聊聊天context-mode 感觉不到多重要。但一旦进入生产环境用户数量上来了场景复杂了问题就全冒出来了用户的对话轮数不可控。有的用户有耐心聊 100 轮有的用户三句话就要答案。你按 20 轮截断对某些人是够的对另一些人就是灾难。上下文价格不便宜。OpenAI 之类的按 token 计费每多保留一轮历史请求成本就上升一截。100 轮对话的完整历史可能比你当前这条问题的 token 还贵好几倍。响应延迟与窗口长度强相关。窗口内容越多生成前等待的时间就越长。长上下文虽然能力变强了但响应变慢会让用户觉得产品卡了。正是以上这些现实压力逼着每一个负责人正视 context-mode 的设计。它不是加分项而是必答题。2. 三种主流的 context-mode它们各自的脾气、优点和致命伤工程上落到具体实现context-mode 最常见的就是下面这三种。我把实现逻辑、优缺点和适合场景全部列出来你对照自己项目情况基本直接能选型。2.1 独立模式每次请求都是初次见面这种模式最简单每次发给模型的内容只有当前这一句问题不携带任何历史消息。大多数模型的 API 默认就很接近这种模式比如某些 Completion 类接口。优点是逻辑简单到了极致token 消耗最小排查问题最方便。每次请求都是独立的不存在对话漂移也不会因为前面聊歪了把后面带偏。缺点也致命模型是全忘状态。它不知道用户刚才填了哪些信息不知道用户叫什么名字甚至连上一句自己刚说过的结论也忘光了。一旦产品需要多轮信息收集或者用户会追问细节这种模式直接白给。这个模式只适合两类场景一是一次性问答比如快速翻译、改写、代码解释用户不会追问二是对上下文合规有严格要求的场景比如某些金融、医疗场景强制要求每轮请求数据最小化。2.2 会话模式最常用但也最容易半桶水这是绝大多数聊天轮机器人采用的模式。具体做法是在每次请求时把系统提示放在开头后面依次拼接用户和助手的最近 N 轮对话拼满一个输入窗口。真实实现中碰到的问题比想象的多第一轮数和 token 数是两个概念。用户一句哈哈哈只有几个 token但用户贴一段代码可能一千多 token。如果只按轮数截断遇到贴代码的用户直接把上下文窗口塞爆。所以生产环境我几乎不用轮数做单位全部换算成 token 数去控制。第二从头到尾平铺历史消息并不科学。历史消息中很多是好的谢谢嗯嗯这类信息量极低的填充语它们白白占用窗口空间。你在设计会话模式时需要考虑一个历史消息压缩层不重要的寒暄可以直接去掉重要的信息用户填写的关键字段、最终结论必须保留。第三多角色消息的顺序和标签不能搞错。很多模型的接口对消息角色有严格要求——system、user、assistant 必须按照真实对话顺序出现一旦顺序错乱比如连续两条 user模型立刻变傻。这件事情在测试单个请求时很难发现只有跑真实对话才会暴露。会话模式适合绝大多数常见场景AI 客服、教育辅导、写作助手、私人助理几乎所有需要记得上一句的产品起点。小步快跑没问题但你要清楚它只是一个够用但不完美的起步方案。2.3 全量摘要模式长会话的最终答案当你的产品真的需要支持超长会话50 轮以上或者需要把大量外部知识塞进上下文时光靠保留最近 N 轮已经不够了。我的做法是两层结构第一层每个对话维护一份滚动摘要。当对话超过一定阈值比如 20 轮系统会调用一次模型把当前的历史对话浓缩成一段 200-300 字的摘要存到对话状态的 summary 字段里。之后的每次请求基础上下文由「系统提示 滚动摘要 最近 10 轮完整对话」构成。第二层如果涉及知识库检索嵌入内容也分两类需要持久保留的核心知识比如用户身份、订单号、服务偏好单独存字段每次请求放在摘要区之后临时检索的片段比如用户在某轮问过的某个产品详情只在当轮加入过期就丢弃。这种模式融合了记忆和当前任务两个维度虽然工程成本最高但对体验提升也是最明显的。用户会觉得这个 AI记得几十分钟前说过的话信任感完全不一样。这三种模式不是一个比另一个高级的关系它们是在上下文保留成本与对话连贯性之间做权衡的三个档位。我见过有人一上来就上全量摘要模式结果服务端每个会话都要维护一个摘要任务延迟和成本居高不下用户体验反而不如简单模式。选型逻辑我展开说一下。模式实现成本token 消耗多轮连贯性最适合的场景最不适合的场景独立模式极低最少无一次性问答、合规严格场景多轮信息收集、连续追问会话模式中等中等中常见客服、助手、写作超长会话、跨话题漂移全量摘要高较高但可控强深度陪伴、长文档分析、复杂任务短会话、高并发高吞吐场景选型口诀就一句话你的产品用户是多聊几句 5 分钟就完事还是一聊聊半小时前者会话模式够用后者必须上摘要和状态管理。一上来就想要完美体验成本和效果往往两头都不讨好。3. 上下文窗口溢出这堵墙炸过才知道疼刚才一直在说上下文窗口那到底这个窗口是怎么被打满的为什么一定要去管它这一节我讲得细一点因为这是所有 context-mode 设计里最核心的约束条件。3.1 每个 token 都在花钱、花时间先算一笔账。你发一个请求输入里面的每个 token 都要参与注意力计算。假设你的输入是 10000 个 token这个 10000 不只是它本身的长度注意力矩阵计算量还有额外的开销实际耗时和显存压力都不是线性增长的。这是为什么很多人发现上下文塞得越多响应越慢的核心原因。然后计费国内外的模型 API输入 token 都是要收钱的。一个用户一天聊几十轮如果每轮都保留大量历史几十个用户并发日成本轻松破千。这不是夸张我见过好几个团队模型能力没问题纯粹是上下文管理太粗糙把项目烧死了。所以我们设计师在设计 context-mode 的时候脑子里要有一根弦每一个保留在上下文里的 token都等于真金白银和响应时延。能不放就不放能少放就少放。3.2 截断策略别只会掐头窗口快要溢出时最简单的策略是从最早的消息开始往掉丢这叫 FIFO 截断。代码写起来很简单就是维护一个数组超了就 shift。但 FIFO 有两个明显问题第一上下文断崖。用户在第 1 轮报了订单号然后聊了 30 轮别的第 31 轮突然问那我的订单还要多久这时候第 1 轮的订单号早被截掉了模型一脸茫然。这种临时想起很久以前的事在真实用户行为里非常常见。第二摘要丢失。如果你的系统维护了滚动摘要但摘要放在上下文开头FIFO 截断只会丢尾部摘要倒是能保住。但如果你用的是最朴素的整个历史平铺方案没有摘要层一截断之前的有效信息就全断在那里了。所以要升级方案关键信息持久化用户报名号、选中的选项、填写的表单字段对话中一旦出现立刻抽出来存到会话元数据里每次请求重新注入系统提示区。这部分信息永远优先保留。摘要兜底每 10-20 轮做一次摘要把重要的、用户明确决定过的信息摘出来防止被挤掉窗口。最近内容无损保留最近 5-10 轮完整保留因为用户在当下最可能在追问刚说完的事。三条配合起来才能做到既能处理新话题又不丢老信息。不要迷信某一种截断策略好的 context-mode 是组合拳。3.3 摘要生成本身的成本和时机摘要生成是要额外花一次模型调用的所以不能每轮都做。我的经验值是每 15-20 轮或累计上下文超过窗口 70% 时做一次具体数字你自己调。更要注意的是摘要可能引入信息失真。模型总结时可能漏掉用户明确表达的细节。所以摘要后你可以把原对话归档为用户翻旧账场景留一份后手。遇到用户问我刚才不是说过……可以去归档里检索原文再补进上下文。3.4 上下文缓存的工程细节现在很多平台都提供上下文缓存比如 Anthropic 的 prompt cachingOpenAI 后来的自动缓存这玩意儿可以让重复前缀内容打折计费响应也更快。但缓存不是白来的它有前提你输入的前缀必须逐字节一致才能命中缓存。所以设计上下文时变量部分如用户当前消息、实时检索结果一定要放在动态区固定部分系统提示、摘要、历史记录放在静态区。如果你把固定信息打散穿插在动态信息之间缓存命中率直接归零成本翻好几倍。这一点我觉得很多文章都没强调到但它是我在实际优化中节省成本的最大头。缓存命中时 token 成本可以降一大截命中不了就只能全额买单。4. 一个真实项目的 context-mode 落地方案从需求到代码理论讲完上实操。这是我去年做过的一个企业智能客服项目的真实简化版我会把需求分拆、模式选型、核心代码结构、调优过程全部带出来你可以直接参考着改。4.1 需求分拆先问自己三个问题开工前我先把需求落到三个问题上答案决定了选型用户会连续聊多少次我们统计过企业客服场景用户平均会话轮数为 12 轮但长尾用户会到 80 轮以上。所以必须支持长会话但前 90% 场景是短会话。信息收集强不强客服场景必须收集用户身份、产品型号、故障描述、期望时间。这些关键信息一旦丢失用户会非常烦躁。外部知识要不要产品手册、售后政策需要实时检索一段上下文需要放入知识片段。三个问题的答案指向同一个方向不能只靠单一会话模式需要会话模式 关键信息持久化 摘要压缩的组合方案。4.2 核心实现一个 ContextManager 类我建议所有做这类项目的同学把上下文管理抽象成一个独立的模块别把拼接逻辑散落在业务代码里。下面是这个模块的 Python 骨架核心思路是把系统固定上下文关键信息元数据滚动摘要最近对话窗口临时检索片段五种数据源按规则拼装成最终请求。class ContextManager: def __init__(self, system_prompt: str, max_context_tokens: int 4000): self.system_prompt system_prompt # 固定系统提示 self.metadata {} # 关键信息字段订单号、姓名、偏好 self.summary # 滚动摘要 self.recent_messages [] # 最近 N 轮完整对话 self.max_context_tokens max_context_tokens def extract_key_info(self, user_msg: str, assistant_msg: str): # 用正则或小模型从对话中提取关键字段 # 例如订单号r订单号[:]\s*([A-Za-z0-9]) # 提取后写入 self.metadata以便后续每轮注入 pass def maybe_update_summary(self): # 当 len(self.recent_messages) 20 或 token 超阈值时 # 调用模型把 old_messages old_summary 压缩成新 summary pass def build_messages(self, current_query: str, retrieved_chunks: list None): messages [{role: system, content: self.system_prompt}] # 1. 关键信息区一旦有提取结果用一段可见文本注入 if self.metadata: metadata_text \n.join(f{k}: {v} for k, v in self.metadata.items()) messages.append({ role: system, content: f[持久化关键信息]\n{metadata_text} }) # 2. 摘要区 if self.summary: messages.append({ role: system, content: f[此前对话摘要]\n{self.summary} }) # 3. 临时检索片段 for chunk in (retrieved_chunks or []): messages.append({ role: system, content: f[相关文档片段]\n{chunk} }) # 4. 最近对话窗口无损保留 messages.extend(self.recent_messages) messages.append({role: user, content: current_query}) return messages这段代码是我项目里的一个很简化的版本实际生产环境你还要加索引、缓存、监控、持久化存储但骨架就是这一套。有几个点我特别说明一下关键信息为什么要单独注入而不是放在历史消息里因为用户随口说的一串单号如果只存在某轮历史消息里一截断就没了。单独抽出来放系统区它的优先级最高永远不会被截断。检索片段为什么要放 system很多平台的 API 里system 消息可以有多个你完全可以用多条 system 消息来携带外部知识这样语义清晰后续做前缀缓存也好做。不要把所有东西全塞到一条消息里。4.3 轮次管理的链路细节方案落到工程细节时还有几个很关键的链路要打通对话存储每一轮对话结束把 user/assistant 消息和新增的关键字段存储到一个会话存储里Redis 或者数据库都行。存储的内容要包含时间戳这样后端能按时间顺序重建会话。截断触发每次拼完 messages写一个 token 预估函数预估输入长度。如果超过阈值比如窗口最大 8000 token 时给请求预留 2000 输出 token输入最多 6000依次触发降级先丢弃最久远的寒暄类消息用规则判断现在是否距离上次关键信息很久再触发摘要生成把旧对话压缩进 summary最后如果还不够直接丢掉最旧的普通消息。摘要触发时机在刚完成第 20 轮或者上下文超过窗口 70% 时触发生成全新摘要后把最近消息列表里的旧部分清空只保留最近 10 轮。4.4 模式切换与降级给用户体验兜底实际运行中一定会出现极端情况用户连着发了几个超长文本比如贴了一整篇代码上下文瞬间被打满。这时候你不可能做到完美保留所有最近消息只能做一个降级注意降级时绝不能为了让内容放得下把用户这一个问题本身截断了。我的规则非常明确——用户当前提问永远无损保留需要裁剪的只可能是历史消息和固定知识。任何时候宁可丢背景知识也不能丢用户当前诉求。我在那个项目里特意加了一个降级状态标记当连续多轮发生截断时返回给前端一个状态字段前端可以提示用户您的问题较长我已经把之前的信息做了压缩如有需要可以重新描述关键信息。这个提示极大减少了用户在长文本场景下对 AI失忆的困惑。5. 调试 context-mode 时踩过的那些坑每一个都值得记住方案设计再完美落地过程还是会遇到一堆怪问题。我把自己踩过的坑按发生频率排个序下面这几个是重灾区基本每个人都会栽在其中一个上面。5.1 角色消息重复叠加导致的上下文污染我最开始做 context-mode 时为了让模型记住用户已填写的信息每次请求都会重新把「用户已提供的信息」写成一长段塞到系统提示里。结果跑了几天发现一个诡异问题如果用户修改了某个字段比如先把城市填成北京后来又改成上海模型有时会同时说根据您所在的北京……哦不对是上海看起来非常精神分裂。排查后才发现旧值还留在历史消息里新值又在系统提示里两处信息冲突了。大模型的注意力机制没法自动判断哪个更新只能同时参考。解决办法是对可变信息做了更新后一定要把历史消息里的旧值同步替换或明确标记以下信息已过期。或者干脆在上下文压缩时把采集过的信息字段统一从历史消息中移除只保留系统区的权威值。现在我在设计 ContextManager 的时候对关键信息字段都不再从历史里原样保留全部抽成元数据避免多副本冲突。5.2 时间信息被截断导致的幻觉式回答有一次一个用户凌晨 1 点问客服你们几点上班模型回答我们营业时间是早 9 点到晚 6 点。看起来没问题吧但用户其实想知道的是现在人工客服是否在线而系统上下文里只放了知识库里的营业时间片段没有注入当前的实时时间。模型不是故意的它只是真的不知道现在是凌晨。这个问题的根源是context-mode 里没有把当前时间当作上下文的一部分。我后来在系统提示里固定加了一行当前日期与时间为 2025-01-15 01:12:33周四模型的表现立刻好了不少。任何涉及营业状态、时效判断的场景时间戳都是上下文的隐藏关键字段很多人漏了它。5.3 多轮工具调用中的上下文丢失现在很多产品都会给模型挂工具查天气、查订单、查物流。工具调用本身是有上下文状态的第一轮模型输出一个工具调用请求第二轮接收工具结果再继续生成。如果你没有把工具调用的过程和结果保存进上下文而是在历史消息里粗暴地把 tool 消息丢弃了模型就会在工具返回结果这一步断片。我的经验是工具调用的中间结果不但要保留还要给它们一个摘要化的容身之处。如果一个工具返回值很长比如一份十几条订单列表你还要再压缩回一个关键结论比如共 3 条未完成订单最早的超时单号 XXX。否则每次轮询工具记录都会把上下文撑爆。5.4 缓存命中率上不去成本不降反升我在前面说过上下文缓存能省钱但现实是很多团队实现了半天一看命中率不到 10%白忙一场。最常见的原因有两个一是把时间戳放在静态区。有人想实现当前时间的更新把时间戳直接拼在系统提示的前缀里导致每次前缀都不一样缓存全废。正确做法是把时间戳放在动态区比如系统提示最后部分或者只在必要时才更新。二是动态检索片段位置不固定。如果检索片段放在 system 区但每次检索命中的文本长度不一样历史消息的起点就一直在变缓存还是废。要命的是检索片段本身就是动态的所以系统设计时要把所有检索到的内容放在所有固定内容之后、历史消息之前保证固定的前缀部分连贯不变形。只要固定前缀足够稳定缓存命中率就能从 10% 拉到 60% 以上。5.5 日志里必须能看到每次请求真正看到了什么最后一条经验我放在所有坑之后讲因为它可能是最救命的调试 context-mode 时你必须有上帝视角的日志。我开发时总会为每次请求打一行日志包含以下字段session_id, request_timestamp, input_tokens, output_tokens, history_count, summary_len, metadata_keys, cache_hit_flag, truncated_count_desc这样用户说AI 怎么不知道 XXX时我一眼就能定位是历史被截断了、还是摘要压缩失误、还是关键信息没抽取出来。如果没有这种日志出问题你真是一个小时都不一定能查出来。我甚至建议给每条进入上下文的消息打一个生命周期标签比如来自历史第 3 轮来自摘要来自检索片段——知道信息的来源你就能快速判断到底哪一环在丢失信息。context-mode 本质上是个数据管道问题管道的每一环都需要被观测。6. 最后再分享两个关于 context-mode 的实战小技巧聊到这儿核心的东西基本说完了。我把两个我觉得特别值得拿出来再说一遍的细节放在最后它们不算大理论但确实让我的项目体验好了不少。第一个是为上下文管理预设一个信息衰减优先级。不是所有历史消息平等用户明确表达的偏好我不吃辣优先级最高用户给出的临时状态我今天下午三点到店取货次之无关寒暄好的谢谢最低。你在做截断或者压缩时按这个优先级决定谁可以被丢弃谁必须留下。这个优先级表要明确写在代码里而不是靠模型自己判断——模型判断不可控。第二个是把 context-mode 的治理当成一个持续打磨的过程每个版本的对话记录都沉淀下来定期复盘哪些轮次被截断了哪些信息丢失被用户追问了摘要压缩有没有引起误解。我就是在第一次复盘时发现 70% 的记忆丢失场景不是窗口溢出而是关键信息没有从对话里被抽取出来——于是把重点放在了信息抽取的准确性上而不是单纯调大窗口。这个转向让用户问题率降了将近一半。最后说一句实在话context-mode 这个事看似是怎么把历史消息塞进模型里这样的小问题实际上它决定了一个 AI 产品是聊两句就让人崩溃的玩具还是能真正办事的工具。花一周把它想清楚比后面用户抱怨三个月再返工划算太多了。