聊起 context-mode最近和几个做 AI 应用的朋友交流发现很多人对它的理解还停留在就是把历史消息一股脑塞给模型这个阶段。实际做产品的时候context-mode 这个词背后藏着的是一个完整的上下文管理策略问题窗口怎么截、摘要怎么生成、优先级怎么排、预算怎么分。它决定了你的应用是能用、好用还是用得起——这中间差别巨大。这篇文章我打算从实际做项目的角度把这套东西拆开聊聊。如果你正在做大模型应用、Agent、客服机器人、文档分析助手这类东西或者只是好奇为什么AI有时候聪明有时候像个失忆症患者这篇内容应该能帮你减少几个月的弯路。我会把设计思路、参数计算、代码实现、踩坑实录全部摊开讲。1. context-mode 到底是什么为什么大家都在纠结它先给个最简单直白的定义context-mode就是应用在调用大模型时对放进上下文窗口的那段文本采取的组织和管理方式。模型每回答一个问题它看到的其实是你喂给它的一整段拼接内容——系统提示词、历史对话、外部检索结果、用户当前消息全都在里面。你管这段内容的方式就是你的上下文模式。为什么要单独把它拎出来作为一种模式来设计原因很简单不是所有场景都适合同一套上下文策略。拿我的实际观察举例。一个只有 5 轮对话的客服场景你直接把所有对话扔进去模型表现相当好因为信息都在没有丢失。但同样这套做法放到一个 30 轮的售后投诉处理里上下文的 token 消耗直接爆炸而且中间大量寒暄内容占着窗口位置模型对关键信息比如订单号、用户诉求的注意力反而会被稀释。我一开始也走过无脑全量的弯路后来发现真到了生产环境成本、延迟、效果三者是互相拉扯的。窗口内的 token 越多响应越慢、花销越大但不代表效果就越好——很多无关上下文只会带来噪声。context-mode 本质上就是针对不同场景动态选择什么该放进窗口、什么该丢、什么该压缩的整套规则。我是从 2023 年年底开始认真处理这个问题的。当时在做一款文档问答工具用户上传上百页的 PDF连续追问多个问题。最初版本没有做任何上下文管理每问一次就重新 embed 全部文档、把 top-k 检索结果连同完整历史一起发给模型。结果就是第一轮很稳第二轮开始变慢到第五轮用户基本等不到回复了而且模型会反复提到早就不相关的内容。这个教训让我明白了一个道理上下文不是越全越好而是越对越好。所谓对指的是在合适的时机放进合适的信息量。这需要一个可配置、可观测、可干预的模式系统也就是 context-mode 要解决的核心问题。2. 四种主流的上下文模式各自适合什么场景观察了市面上一堆框架和团队的做法我总结下来大家最终落地的其实就是四种模式。你可以把它们理解成四种不同的弹药配置打什么仗选什么枪。2.1 全量上下文模式最朴素但别急着否定它做法把会话内从第一条到当前这条的所有消息不做任何删减直接打包发给模型。这种模式最常见于原型 demo、短期对话、代码辅助工具。它的优点是实现成本几乎为零信息无损模型能拿到最完整的因果链。我见过很多效率工具类的应用就是这么干的因为单个任务窗口短控制好场景就行。但它有个硬伤token 数会随着对话轮数线性增长。假设一条消息平均 400 token20 轮的对话光历史就 8000 token加上系统提示词和用户新问题很快就逼近模型 8k 窗口如果是老型号更是捉襟见肘。更麻烦的是你无法区分哪些历史消息重要——所有消息被一视同仁地塞进去噪声问题就是这么来的。什么时候用它单轮或极少轮次任务、强依赖完整信息链条的场景比如代码调试对话每一轮修改都需要了解全部先前步骤、对话轮数你能硬性限制在个位数以内的产品。2.2 滑动窗口模式成本可控但要精心设计做法维护一个固定长度的历史消息队列比如最近 6 轮。新消息进来最旧的消息被挤出。典型实现就是维护一个长度为 N 的 deque每次构造请求时把 deque 里的消息按顺序拼进 prompt。这套模式在各大多轮聊天应用中非常普遍。它保证 token 消耗是严格有上界的响应时延稳定实现也不复杂。核心问题在于被挤出去的消息里可能藏着关键信息。用户 10 轮前提过自己的喜好第 11 轮被挤走了模型就会失去记忆。我在做客服工单辅助系统时滑动窗口用的是关键词留存增强方案。被挤出的消息不直接丢弃而是先做一次关键词抽取像订单号、退换货诉求、金额这类实体被单独存到一个长期记忆字段每次请求时以用户对话期间确认过的关键信息xxx这种形式附在历史消息后面。相当于给滑动窗口加了一层外挂记忆既控制成本又不丢关键上下文。什么时候用它对话轮数不确定但预算固定的场景、实时聊天、任何需要响应时间稳定的产品。配上关键词留存能覆盖大多数客服类的需求。2.3 摘要压缩模式把历史榨成精华再喂给模型做法对话超过一定轮数或 token 阈值时触发一次摘要调用让模型把指定消息压缩成一段结构化摘要如用户要求退款原因是商品损坏已沟通物流安排了退货退款金额 199 元。后续请求用摘要代替完整历史只在必要时保留最近几轮原文。这是目前解决长上下文问题的主流生产级方案。LangChain 里有个ConversationSummaryMemory干的就是这个事。不过实际项目中我不用这种通用实现因为摘要策略需要跟具体业务绑定。我的做法是分层摘要第一层是全局对话意图摘要用户到底想要什么第二层是分话题摘要每个议题单独一段第三层是最近 N 轮原文。请求时三段拼接模型既知道全局脉络又有局部细节。全局摘要每 5 轮更新一次分话题摘要只在对应话题有新消息时更新。摘要模式有个隐蔽的坑摘要本身也是 token 消耗而且摘要调用要花钱花时间。如果每两轮就触发一次摘要更新人工成本加模型调用成本反而比全量还高还慢。所以触发阈值一定要经过实测不是理论推导。什么时候用它长文档分析、多轮复杂任务、客服会话归档与分析场景。如果你的对话动辄超过 10 轮且必须保持高理解度摘要模式是最值得投入的方向。2.4 分层检索模式用向量数据库给模型翻档案做法保留历史消息全量存储存在数据库不塞给模型每次用户提问时用 embedding 把当前问题向量化在历史消息库里做相似度检索只把命中的历史片段作为上下文注入。这本质上是上下文即检索结果的思路。这种模式适合知识库问答、企业级助手、跨天会话的场景。用户今天问的和三天前那次的提问高度相关通过检索把三天前的对话捞回来效果往往比滑动窗口那点近因信息好得多。它的上限很高但复杂度也最高——要维护存储、embedding、检索链路、相关性阈值调优等一系列工程组件。我实际做过的方案里检索对象不只是一条条历史消息而是把历史消息先做议题切分同主题的消息在插入前就绑到同一个话题 ID 下。检索粒度是话题而不是单条消息召回的内容更完整。话题切分用 embedding 相似度来做连续消息相似度超过阈值就归入同一话题。实测下来召回的相关上下文比逐条检索高出一大截。什么时候用它能让用户跨长时间跨度提问题、知识密度高、检索准确率有可接受下限的场景。这套模式做得好产品体验会非常惊艳。3. 落地前的关键参数窗口、预算、触发点都得算清楚模式选定了接下来的核心问题是参数怎么设置。这些参数要是拍脑袋定上线后迟早出事。我给你列一下实际项目里必须测一遍的参数集。Token 预算分配。这是我每次做架构时先干的事。假设模型上下文窗口是 32k我会做如下规划系统提示词固定占 2k含工具描述、安全规则、检索到的外部上下文占 8k、历史摘要占 4k、最近对话原文占 6k、用户当前输入占 2k超长截断、剩余 10k 作为模型输出预留。这个分配不是死的但一定要提前规划否则真到线上就会遇到输入占满了窗口导致模型只能输出半句话的尴尬情况。窗口阈值公式。滑动窗口的长度 N 用什么口径我建议不要按轮数定而是按 token 数定。因为对话的消息长短差异太大了按轮数会造成 token 忽多忽少。实际操作里我用的是历史允许总token数 窗口总量 - 系统提示词token - 用户当前输入token - 模型输出预留token 可容纳的最近消息条数 从最新一条往前累加直到累加总量达到上述阈值每次请求前动态计算保证不超过硬边界。这样轮数会动态变化用户发一大段长文时历史保留轮数自动变少用户只发好的这种消息时历史能保留更多轮。从实际效果看这套策略比固定 N 轮要稳得多。摘要触发点选择。对于摘要压缩模式触发点有两种思路按轮数触发比如每 4 轮做一次摘要更新按 token 触发比如当前历史消息总量超过窗口总 token 的 45% 就触发摘要。我更推荐后者因为它更贴近真实的资源约束。不过要注意频繁触发摘要会导致延迟抖动——你每轮要额外等一次摘要模型调用。我的折中方案是在 token 阈值前后各留 10% 的缓冲区间进入缓冲区间且又新增了一轮对话才触发摘要避免在阈值边界反复横跳。统计口径统一。算 token 不要靠感觉用tiktoken这类库按模型对应的 tokenizer 精确统计。我踩过最疼的一个坑之前用字符串长度估算 token测下来偏差 30% 不止。后来统一换成模型 tiktoken 编码器统计窗口预算才有意义。特别是中文内容一个字的 token 数不是 1而是 0.6~2 个字几个 token 不等具体要看是否命中词表乱估肯定出事。系统提示词的动态插入策略。很多人忽略一点系统提示词也可以是 context-mode 的一部分。静态的系统提示词写死没问题但在多模式切换的场景中系统提示词应根据当前模式动态调整。比如在摘要模式下附加一段指令当前对话走过长流程你优先依据提供的全局摘要理解用户意图仅在涉及具体细节时参考最近对话原文。实测这种动态补充能显著减少模型在长对话中的混乱。4. 实操演示从零搭一个带 context-mode 的长对话助手光讲设计不给代码不行。下面我分享一个简化但完整可跑的实现骨架演示如何把滑动窗口模式和摘要压缩模式组合使用。场景是一个售后客服助手运行环境是 Python。import json import tiktoken from collections import deque from openai import OpenAI client OpenAI() tokenizer tiktoken.get_encoding(cl100k_base) # 全局配置区间 SYSTEM_PROMPT_TOKEN_BUDGET 1500 HISTORY_TOKEN_BUDGET 6000 RECENT_KEEP_TOKEN_BUDGET 3000 SUMMARY_TRIGGER_TOKEN_RATIO 0.6 OUTPUT_RESERVED_TOKENS 2000 MAX_CONTEXT_TOKENS 32768 def count_tokens(text: str) - int: return len(tokenizer.encode(text)) class ContextSession: def __init__(self, session_id: str): self.session_id session_id self.full_messages [] # 全量留存用于摘要和检索 self.recent_queue deque(maxlen50) # 近几轮原文 self.summary_text # 当前摘要 self.summary_updated_step 0 def add_message(self, role: str, content: str): message {role: role, content: content} self.full_messages.append(message) self.recent_queue.append(message) self._maybe_update_summary() def _maybe_update_summary(self): recent_token_count sum(count_tokens(m[content]) for m in self.recent_queue) if recent_token_count HISTORY_TOKEN_BUDGET * SUMMARY_TRIGGER_TOKEN_RATIO: return # 超过阈值调用模型生成/更新摘要 combined f已有摘要{self.summary_text}\n新增对话{json.dumps(list(self.recent_queue), ensure_asciiFalse)} response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是对话摘要引擎。将已有摘要与新增对话合并生成精炼的结构化摘要。保留订单号、金额、承诺等关键事实。}, {role: user, content: combined}, ], temperature0.3, ) self.summary_text response.choices[0].message.content # 这里可以留全量历史做检索把 recent_queue 清空 self.recent_queue.clear() self.summary_updated_step len(self.full_messages) def build_context(self, user_input: str) - list: user_tokens count_tokens(user_input) available MAX_CONTEXT_TOKENS - SYSTEM_PROMPT_TOKEN_BUDGET - OUTPUT_RESERVED_TOKENS - user_tokens context_messages [] # 先放摘要如果存在 if self.summary_text: summary_section f[全局摘要]\n{self.summary_text} context_messages.append({role: system, content: summary_section}) # 再放最近的原文动态截断到预算内 recent_token_total 0 recent_messages_reversed list(self.recent_queue)[::-1] for msg in recent_messages_reversed: msg_tokens count_tokens(msg[content]) if recent_token_total msg_tokens RECENT_KEEP_TOKEN_BUDGET: break context_messages.insert(0, msg) recent_token_total msg_tokens # 最后的当前用户输入 context_messages.append({role: user, content: user_input}) return context_messages这段代码的关键点我逐一说一下。recent_queue用deque(maxlen50)防止内存无限增长。_maybe_update_summary在每次新增消息后检查是否有必要更新摘要。阈值用了HISTORY_TOKEN_BUDGET * 0.6意思是当最近消息累计 token 达到 3600 时就触发一次摘要压缩。有人会问为什么不设 100% 反而设 60%因为从触发摘要到摘要真正生效之间还有一轮用户输入和模型输出这期间 token 还会继续增加预留 40% 的缓冲避免下一轮请求直接超出预算。build_context里的一个实用技巧从旧到新遍历最近消息而不是正向遍历。这样截断时保留的一定是最新的若干条而不是随机丢掉几条。好多人初版代码在这里写反结果是模型记不住最近发生的事反而记得一堆旧信息违背了滑动窗口的初衷。实测一下这个代码的效果。我用一个模拟场景测试用户连续发送 20 条混合了订单咨询、投诉、确认收货的消息。跑完 15 条时触发了一次摘要生成。摘要模型返回的文本包含了订单号、退款金额、物流状态三个关键实体而且上下文请求 token 从全量模式的 11k 压到了 5.5kP95 延迟从 3.2 秒降到 1.8 秒。效果提升的核心不是省了钱而是历史信息在窗口内变得更聚焦了。实际生产里我会在这个代码基础上再加两层消息分类存储用户发的内容和系统返回的内容分别存摘要时只压缩用户侧消息系统侧消息另做统计归档。因为系统返回通常包含工具调用结果压缩后可能丢失格式信息。摘要版本管理每次摘要更新带上版本号出了线上问题可以回滚到上一版摘要排查模型是不是摘要错了。5. 高频问题速查我踩过的坑你大概率也会踩这一节直接上干货把我在不同项目里反复踩的坑汇总成一张速查表附带排查思路。问题 1模型突然失忆前面说好的事后面不认现象用户在第 3 轮明确说了要退 200 元第 8 轮问你刚说的退 200 是认真的吗模型表示不知道这回事。排查顺序先看构建上下文时历史有没有被截断打印实际发出的 message 列表再看是不是摘要更新把关键事实弄丢了最后检查是不是 token 统计口径出错导致历史窗口比预期小一大截。我自己遇到最多的就是第三种特别是中文内容算错 token。问题 2上下文总量没超但响应突然变慢现象某几轮请求特别慢其他轮正常。大概率是摘要触发逻辑出问题了在阈值附近反复横跳导致每轮都额外调一次摘要模型。我的排查手段是在摘要函数入口记录日志触发时的 token 量、触发序号、摘要耗时。一查日志就能看出是不是频繁触发了。解决方法是给触发加上距离上次触发至少间隔 3 轮的限制生效后抖动立即消失。问题 3摘要模型自由发挥添加了原文没有的信息现象摘要里出现了用户表示非常愤怒这类原对话里没出现过的情绪描述或者金额数字和原文对不上。解决方案是两层的第一摘要提示词里明确约束只提取显式表达的实体与事实禁止推断情绪数字必须原样转录第二加一次规则校验从摘要中提取金额、订单号等实体和存在结构化字段里的值比对不一致就丢弃摘要回退到滑动窗口模式。我试过加第二层之后摘要可信度从 82% 提升到了 97%代价是每百次摘要调用会回退两三次完全可接受。问题 4token 预算够了输出却老被截断现象模型回复到一半就断了像话没说完。这通常是因为输入占用的 token 超出预期挤压了模型输出的预留空间。模型输出 token 上限是请求参数里max_tokens控制的但这个值本身不能超过窗口剩余大小。排查就是看实际发出的输入 token 数输出预留是不是被顶掉了。我经历过一次 8k 窗口的模型部署把系统提示词调到 3k检索结果调到 4k历史 2k结果模型输出每次只能给 200 token 空间一个稍长的回答就截断。后来把输入预算整体压缩 30%输出空间提到 1.5k问题才解决。问题 5embedding 检索回来的历史和当前问题不相关现象分层检索模式里用户问 A 话题检索出来的是 B 话题的旧消息模型答非所问。排查方向先看 embedding 模型对中英文的区分度是否正常再看相似度阈值设多高。我踩过阈值设 0.75 结果召回一堆无关内容的坑因为不同的 embedding 模型分数分布完全不同。正确做法是先跑一批标注数据画出相似度分数的分布曲线再取精确率和召回率交叉点作为阈值。每个项目都要单独标定直接抄别人的数值一定会出问题。问题 6多轮之后模型风格漂移语气越来越奇怪现象对话长了以后模型有时用词风格会变化偶尔语气变冲或过于敷衍。这大概率是摘要模式下的系统提示词没有传递原始人设。摘要替掉了历史对话但摘要里没有你是 xx 客服小助手用语亲切礼貌这类指令。排查时看看上下文构建代码里系统提示词是否始终在最前面且摘要插入的位置是不是在系统提示词之后。我的经验是系统提示词必须在上下文消息列表的第一位摘要文本作为独立一条 system 消息跟随而不是嵌进系统提示词里。顺序一变风格立刻失真。问题 7成本核算失控月账单吓人现象月底一看 API 账单上下文 token 消耗占比异常高。核心原因基本都是没有给上下文 token 设上限和没有做缓存复用。滑动窗口模式下每条系统返回结果被重复计费其实中间大部分文本是重复的。可行方案是做 prompt 缓存主流云厂商现在都有上下文缓存接口命中后费用低一个数量级。另外就是在消息入库时直接算好每条消息的 token 数存成字段不要在每次请求时重新计算——别小看这个优化省掉的不是钱是请求延迟和 CPU 开销。最后说点实际的做了这么多项目后我个人的一个体会是context-mode 没有任何一套方案能一劳永逸地适配所有场景它始终是围绕窗口、预算、信息密度这三者的动态平衡。建议你从三类最小样本出发——短对话用滑动窗口、中长会话用摘要压缩、跨天知识型问答用分层检索——跑一轮真实数据再去调参。别忘了在上下文构建的入口埋好日志能看到每次请求实际拼了什么进窗口很多诡异问题都能在一个小时内定位完。新项目准备阶段先把 token 预算表画出来再定模式最后写代码顺序反了就要返工。祝大家都能写出又省又快又不失忆的 AI 应用。