做了几年大模型应用我发现很多团队在把模型从“能用”推向“好用”的时候卡住的往往不是模型本身而是上下文。去年我开始在内部工具链里正式引入“context-mode”这个概念——一种专门管理模型输入上下文的运行模式。说白了它就是一套约定哪些信息必须塞给模型、哪些信息可以压缩、哪些历史该被丢弃、哪些知识需要随时待命。如果你正在做 AI 助手、Agent 或者任何带“记忆”的对话系统这篇文章就是写给你的。我会从原理讲到代码再讲到我在生产环境里踩过的坑。1. 先说清楚context-mode 到底在解决什么问题1.1 上下文爆炸系统里最常见的隐性成本很多人第一次意识到上下文是个问题是在线上跑了一个带知识库的问答机器人之后。刚开始效果很好知识库里几千个文本块随便检索回答精准。但用着用着会长久高频出现一种诡异现象同一个问题昨天答得好好的今天突然答错了。查日志发现没有改过任何代码知识库内容没变模型版本没换。原因几乎都是上下文爆炸。每次对话系统把用户问题、检索到的知识块、对话历史、系统提示词一股脑拼进请求。检索模块为了“保险”经常把 Top-10、Top-20 的知识块都塞进去。这些块互相重叠。对话历史越滚越长。几次交互之后可能一个只有 200 字核心逻辑的问题请求体里已经堆了好几万字的上下文。模型不是被你骗了它是真的被噪声淹没了。就像一个本来就有点分心的优等生你让他在一堆废话里找一个关键信息他也会犯低级错误。context-mode 要解决的第一个问题就是这个如何让模型始终看到“最该看到的”而不是“能塞下的全部”。1.2 “全量送进去”的成本提醒不看钱也要看延迟。简单算一笔账。假设你用的是 32K 上下文窗口的模型一次请求塞了 20K token 的上下文。模型每生成一个 token都要把所有输入 token 重新计算一遍注意力。上下文越长生成速度越慢而且是近似平方级的影响。一个原本 1 秒能答完的问题上下文翻倍之后可能要 3 到 4 秒。如果团队比较在意边际成本每千 token 的输入价格乘以每天的请求量一个月下来也是不小的一笔支出。而 context-mode 的核心思想很朴素模型的输入质量由“有效信息密度”决定而不是“信息总量”。把密度做上去成本自然降下来。1.3 context-mode 是什么先下个准确定义我用最直白的话定义一下 context-mode它是一套在调用模型之前对上下文做筛选、结构化、压缩、排序的运行模式。设计目标是让模型每一次推理都站在最相关、最精炼、信息密度最高的上下文基础上。它不是某个 SDK 里的一个开关也不是某家厂商的专属功能。它是一套方法论。可以落到代码里做成一个 Python 类也可以落到工程规范里变成团队对 prompt 和历史的处理约定。我后面会给出一个可以跑的参考实现。1.4 适合谁如果你属于下面几类人这文章值得看完在做客服机器人、AI 助手、行业问答系统的开发者在做 AI 编程助手、需要把项目代码和对话历史喂给模型的开发者在做 Agent、想让多个工具调用的结果能“被记住”的开发者以及任何希望省点 token、别把模型输送给搞脏的人。2. context-mode 的内部机制它凭什么叫“模式”2.1 分层的上下文结构我在设计自己的 context-mode 时第一件事就是把原来乱七八糟的 prompt 字符串重新拆成了四个独立层级系统层 System模型的人设、输出格式、行为边界。一般固定不变。规则层 Rules当前任务专用的规则。比如“只许用中文回答”“遇到法律问题要声明不构成建议”。知识层 Knowledge从外部检索到的知识块比如文档片段、数据库内容、搜索结果。历史层 History多轮对话中的历史消息或者 Agent 的工具调用记录。这四个层级在最终请求里拼接顺序基本是 System Rules Knowledge History User Input。为什么要搞得这么麻烦直接一个字符串拼起来不行吗行但后期维护必是灾难。分层最大的好处是每一层可以独立策略化。系统层永远是权重最高的不参与裁剪规则层只在特定任务时注入知识层要走检索和去重历史层要滚动和压缩。这几个层级的优先级关系我可以用一个比喻系统层是公司的规章制度规则层是本次任务的作战手册知识层是桌上的参考资料历史层是刚开过的会议记录。开会记录可以丢参考资料可以精简但规章制度不能说改就改。2.2 动态窗口滑动历史层的主流策略历史层的处理是 context-mode 里最常见的话题。很多团队一开始的方案是“只保留最近 N 轮”。简单但有明显问题如果关键信息在第 1 轮提到第 10 轮要用只保留最近 5 轮就直接把关键信息丢了。我在实际项目中用的是一套滑动窗口的改良版把对话历史切成若干段每段包含一个完整的用户输入和助手输出。用一个可配置的窗口大小比如 10 轮限制保留的轮数。从最后一段开始向前取直到达到窗口上限。多取的部分不直接删除而是送进一个“摘要缓冲池”——后面会细讲。这个滑动窗口的价值不只是控制长度更重要的是给系统一个“遗忘范围”。范围内的细节完整保留范围外的细节只留摘要。这样既不会让上下文无限膨胀也不会让模型彻底失忆。2.3 摘要压缩与记忆锚点上下文实在太长对话轮数太多的时候就必须做压缩。我在 context-mode 里实现了一个两层摘要机制当窗口溢出把最早溢出的那几轮对话先提取关键信息生成一段短摘要。摘要也设上限。比如摘要积累到一定长度就把最旧的摘要再次压缩成“长期记忆摘要”。长期记忆摘要就是记忆锚点。它包含了用户的核心身份特征、已经完成的任务结论、尚未解决的遗留问题。这样即使是初次接手一个老对话模型也能基于锚点快速理解来龙去脉。做摘要的时机不要选择在请求前临时做而是应该在每次生成完回复后异步执行。这样用户下一次提问时摘要已经是现成的不需要额外等待。2.4 知识层的选取策略知识层是整个 context-mode 中变量最大的部分因为知识来源不固定。我的实践是三步走检索召回把用户问题向量化在知识库中召回 Top-K 候选块。相关性重排用一个更精准的 cross-encoder 或者 LLM 对候选块打分剔除低分块。去重与裁剪把多个块中重复的高频文案去掉再把超长的块截断到允许长度。关于 Top-K 的选择常规不是一个固定的 10而是动态的。我问一句“你好”跟问一句“服务器连接超时怎么排查”需要的知识量完全不同。所以检索数量最好根据问题的字符数和信息量做简单估算同时最后通过重排只保留前 3 到 5 个高价值块。3. 自己动手实现一个轻量级 context-mode3.1 设计目标与基础数据结构我打算给出的这个实现不依赖任何重型框架只用一个 Python 类足以支撑中小型项目的上下文管理。先定义数据接口from dataclasses import dataclass from typing import List, Optional dataclass class ContextBlock: 上下文的最小单元 role: str # system / rules / knowledge / history content: str priority: int 100 # 数值越大越优先保留 metadata: dict None这个类看着不起眼它定义清楚了上下文每一段都是可追溯的。后来我在生产环境调试“这个回复为什么是错的”时靠的就是每个块上的 metadata。没有这个字段出了问题就只能人肉翻代码。然后定义“上下文包”dataclass class ContextPackage: blocks: List[ContextBlock] token_limit: inttoken_limit 是这次请求允许的上下文预算。所有后续的裁剪、压缩动作都围绕这个预算来。3.2 组装器核心流程的实现组装上下文是整个 context-mode 的心脏。流程我拆成五步class ContextModeAssembler: def __init__(self, token_limit: int, history_window: int 10): self.token_limit token_limit self.history_window history_window def assemble( self, user_input: str, system_prompt: str, rules: List[str], knowledge_blocks: List[ContextBlock], history: List[ContextBlock], ) - List[ContextBlock]: blocks [] # 第一步系统层永远排在最前且完整保留 blocks.append(ContextBlock(system, system_prompt, priority1000)) # 第二步规则层按需注入 for rule in rules: blocks.append(ContextBlock(rules, rule, priority800)) # 第三步知识层按相关度排序之后统一裁剪 knowledge_sorted sorted( knowledge_blocks, keylambda b: b.priority * -1 ) blocks.extend(knowledge_sorted) # 第四步历史层按滑动窗口截断保留最近N轮 recent_history history[-self.history_window:] blocks.extend(recent_history) # 第五步用户问题永远放最后确保注意力落在上面 blocks.append(ContextBlock(user, user_input, priority1001)) return self._fit_to_limit(blocks)这个组装的顺序已经包含了我在 2.1 节讲的分层理念。系统层和用户输入我给的优先级最高。为什么要这样因为系统层决定模型的“人格”用户输入决定本次目标这两个是绝对不能被裁掉的。知识层放中间因为模型在阅读历史之前先看到参考资料会更合理。这有一点像是考试先看题目相关的资料再看之前做过的笔记最后落笔写答案。3.3 token 估算与裁剪落盘_token_limit 预算的分配是 context-mode 最值得琢磨的部分。我建议用比例分配系统层 规则层不超过总预算的 15%知识层不超过 50%历史层不超过 30%用户输入预留 5%。这个分配比例在实践中表现很稳尤其是知识强相关的任务。如果你的场景是闲聊助手历史层的比例可以提到 40%知识层降下来。token 估算我用一个非常朴素的近似算法def estimate_tokens(text: str) - int: # 中英文混排场景下的近似估算 # 英文按 4 字符估算 1 token中文按 1 字估算 1 token # 现实中建议直接用 tokenizer 或 tiktoken import re chinese_chars len(re.findall(r[\u4e00-\u9fff], text)) other_chars len(text) - chinese_chars return int(chinese_chars other_chars / 4)真正落到生产环境还是建议用模型自家 tokenizer 做精确计数。我用近似算法的原因只是为了在检索阶段快速判断“这段知识太长了要不要先截断”避免每次都跑重计算。裁剪逻辑如下def _fit_to_limit(self, blocks: List[ContextBlock]) - List[ContextBlock]: used sum(estimate_tokens(b.content) for b in blocks) if used self.token_limit: return blocks # 先裁剪知识层通过截断超长块来降低占用 for i, block in enumerate(blocks): if block.role knowledge and estimate_tokens(block.content) 300: content block.content[:300] # 注意这里简化了截断真实场景应该断在语义完整的段落 # 不要硬切在句子中间。 blocks[i] ContextBlock( block.role, content, block.priority, block.metadata ) # 再裁剪历史层 while len(blocks) 0: used sum(estimate_tokens(b.content) for b in blocks) if used self.token_limit: break # 找历史层优先级最低的那一块 history_blocks [ (i, b) for i, b in enumerate(blocks) if b.role history ] if not history_blocks: break # 默认丢最旧的一条 target_idx min( [i for i, _ in history_blocks], keylambda x: blocks[x].metadata.get(order, 0) ) blocks.pop(target_idx) return blocks这个裁剪逻辑相当粗糙但是可用。它的大体方向是先压缩知识块再丢历史轮次每一步都检查预算约束。优先压知识块是因为知识层经常有冗余而历史丢一轮通常对最终语义影响可接受。裁剪的逻辑顺序很有讲究。我建议所有团队统一为截断知识块 缩减历史轮数 压缩摘要。这个顺序是经过多次对比得出来的。3.4 带自动摘要与压缩的完整循环想让 context-mode 真正好用光有滑动窗口还不够。我做了个完整循环class ContextModeManager: def __init__(self, assembler: ContextModeAssembler): self.assembler assembler self.history: List[ContextBlock] [] self.summary def send_and_learn(self, user_input: str, response: str): # 每次交互结束后更新内部状态 self.history.append( ContextBlock(user, user_input, priority1001) ) self.history.append( ContextBlock(assistant, response, priority800) ) # 触发摘要压缩 if self._need_compression(): self._compress_history() def _need_compression(self) - bool: total sum(estimate_tokens(b.content) for b in self.history) return total self.assembler.token_limit * 0.7 # 70% 阈值 def _compress_history(self): pool_size len(self.history) - self.assembler.history_window if pool_size 0: return # 把最早超出的部分做一个简单摘要 overflow self.history[:pool_size] overflow_text \n.join( f{b.role}: {b.content} for b in overflow ) # 这里理想情况下应该调用 LLM 生成摘要 # 我为了演示先用截断占位 new_summary self._summarize(overflow_text) self.summary new_summary self.history self.history[pool_size:] def _summarize(self, text: str) - str: # 实际项目中这里调用 LLM: # prompt 请把下面的对话压缩成100字内的摘要保留关键事实 # 演示阶段直接截断 return text[:200]这套循环让我第一次真正摆脱了“上下文越长效果越差”的魔咒。4. 在真实场景中调试 context-mode4.1 越聊越笨上下文被噪声占满后的典型表现第一个典型的坑是模型在长对话后“变笨”。症状比较典型前几轮正确后面开始忽略用户问题中的关键条件甚至开始自问自答。我排到一个客服机器人项目的案例。一开始怀疑是模型缓存问题实际查看日志后发现问题出在历史层。每次客服回答都会带一串固定的“请问还有其他可以帮您吗”等套话。这类套话积累多了历史层的信息熵变得极低模型一读到大量高重复内容就开始跑偏。后来我在历史层写入前做了模式过滤将问候语、结束语等“无信息量”的轮次直接剔除效果立竿见影。心得是历史层不是每句话都值得保留只保留“包含事实、约束、承诺、问题”的轮次。这是调整 context-mode 精度时最先该优化的点。4.2 答非所问知识层检索噪声的排查第二个高频问题模型回答的内容跟问题毫无关系。大部分是知识层出了问题。在 context-mode 里知识层的检索结果并不是越多越好。我曾经把 Top-K 从 5 调到 10结果准确率反而下降。原因是多召回了若干低相关的文本块这些块带有相似的字词但包含相反的信息。模型在上下文里同时看到矛盾信息就会反复横跳。解决办法是在重排阶段必须设定“相关性阈值”。低于阈值的块宁可不送也不能送。同时检测重复或者互相矛盾的块保留最高优先级的那一个其余的丢弃。这一步非常关键不到位的 context-mode 等于什么都没做。4.3 问题排查速查表分享一份我在内部团队使用的排查表遇到问题先对照现象可能原因优先检查内容并进行调整长对话后回答开始跑偏历史层保留了太多低信息量轮次检查历史轮次的过滤规则和 token 占比知识回答错误知识层 Top-K 过大或阈值过低检查重排得分观察是否混入矛盾知识块回答忘记用户说过的条件摘要压缩时丢了关键约束条件检查压缩 prompt 是否明确要求保留约束回复越来越短或敷衍系统层提示词被裁剪压缩检查系统层的 priority 是否被覆盖表格这东西用起来真能救命。团队里每个人排障思路完全一致效率高很多。4.4 压缩摘要的质量校准摘要质量是长对话的命门。我自己踩过的最深的一个坑是生成摘要时没有强调保留“用户明确表达的限制条件”。例如用户说“我预算不超过 1000 元”摘要却只保留“他想买耳机预算适中”这样模型就会推荐超过 1000 元的产品。解决方案是在生成摘要的 prompt 里加一行请把所有数字、价格限制、时间限制、否定性条件完整保留在摘要中不得省略。这行字的成本很低但效果极高。凡是涉及金额、时间、状态的限制一律原样保留。5. 关于 context-mode 的设计心得与扩展方向5.1 先定边界再写代码context-mode 看起来是纯技术的东西但设计起来极度依赖产品边界。做之前必须明确三个问题这个系统是知识密集型还是对话密集型的上下文里的信息是否有严格的时效性错误容忍度怎么样是容忍“丢老信息”还是容忍“答错关键点”这三个问题直接决定裁剪顺序。如果是知识密集型知识层就不能轻易截断该做的是更精准的检索。如果是对话密集型历史层要尽量多留轮次哪怕知识层薄一点。这没有统一答案是设计方案。5.2 从单次会话记忆到跨会话长期记忆context-mode 的下一个扩展方向是跨会话记忆。现在很多系统只在单次会话里管上下文用户第二天再打开就全忘了。我已经在一个项目中把 context-mode 升级成支持用户画像的版本每次会话结束后从对话中抽取用户的偏好、目标、习惯写入用户画像表。下次会话开始时将画像中的关键信息作为规则层或知识层的一部分注入上下文。这有点像把“摘要压缩”的粒度从“对话轮次”提升到“用户维度”。效果非常显著尤其是 B2B 类的销售助手和客服系统。5.3 给新手的三条建议如果你准备在自己的项目里引入 context-mode我基于几次从零到一的经验给你三条建议第一先上日志再做优化。context-mode 任何环节做调整前先把每层上下文保存到可检索的日志里。否则你根本不知道模型看到的是什么。第二优先级字段是一切裁剪逻辑的基础。不要省。第三从最小的“历史滑动窗口”开始跑通后再逐步加入摘要最后加入知识层重排。一次全部上出了问题都不知道该看哪一层。5.4 最后分享一个小技巧我在生产项目里给 context-mode 加了个很实用的细节在组装最终请求之前把“用户输入”和“最相关的历史对话”再做一次相关性检查。如果发现用户当前问题与某段历史的相似度极高才把这段完整留在历史层否则只留摘要。这么做可以让预算集中在真正需要的地方。context-mode 这个名词看起来简单但它背后的工程思路在 AI 应用从原型走向产品的过程中是决定体验的一道分水岭。希望这篇文章能帮你少走点弯路。