最近在做一个叫 context-mode 的项目名字本身是从工程里到处可见的“上下文切换”借来的但真正落地的时候才发现它要解决的是AI应用里最难缠的一类问题怎么让模型在多轮对话里既不“断片”又不会被一波波无关信息带偏。很多刚接触AI应用开发的朋友会把 context 想成“把聊天记录一股脑丢给模型”可真做起来就会发现prompt 越长不代表效果越好反而会引入噪音、拖慢响应、抬高成本。context-mode 想做的就是把这套东西工程化把上下文当成一个有策略、有生命周期、有预算管理的资源来设计。这篇文章我会从 context-mode 的典型场景讲起拆开它的架构组成再给出一套可以直接照着写的落地实现最后把我踩过的坑和排查思路整理成速查表。适合正在做聊天机器人、Agent、智能客服、RAG 问答这类应用的开发者也适合产品经理和技术负责人用来评估“上下文策略”在设计阶段该怎么做。你不需要有很深的大模型基础只要写过 Python、对 API 调用有点感觉就能跟着走一遍。1. context-mode 到底在解决什么问题1.1 同一个术语三种完全不同的场景“上下文模式”这个词在不同领域里的含义差别很大。做前端或者图形开发的朋友听到 context-mode第一反应可能是 canvas 的 2D/3D 绘图上下文或者是 OpenGL 里的 context 切换。做编辑器的人会想到 vscode 的 context 变量和 when 条件。而我这里要聊的是 LLM 应用工程里的 context-mode它决定哪些信息能进入模型视野、以什么顺序进入、保留多久、超出预算时怎么压缩。为什么要把这个区分说清楚因为很多团队在开会讨论“我们要不要上 context-mode”的时候经常发现大家想的根本不是一回事。我建议先把范围框定在 AI 应用里context-mode 是“模型输入侧的信息编排策略”它由消息记录、检索结果、系统指令、工具返回、摘要压缩五类素材共同决定。1.2 没有策略的上下文问题很快就会暴露我见过很多早期项目第一版都很简单把 messages 数组不断 append最多因为怕太长截断一下。在小规模 demo 里没问题一旦用户连续聊上几十轮甚至跨天回来继续聊问题就接二连三出现。第一种是“定位漂移”。用户一开始说“我想查上个月的电费”聊了几轮天气、聊了股市、聊了餐厅推荐然后突然又说“那笔钱什么时候到账”模型可能已经忘了“那笔钱”指的是电费退款。原因很简单后面的闲聊把关键约束挤出了窗口。第二种是“Token 爆炸”。没有预算管理一个 session 聊久了每次请求的 token 成本线性上涨。到了月底看账单会发现真正有价值的会话没多少钱全花在重复搬运历史消息上了。第三种是“首轮指令被覆盖”。系统提示词里的规则是固定的但模型对指令的服从度会随着上下文长度衰减尤其是当中间夹了几十条用户消息时新消息的影响力会盖过早期的 system 约束模型开始“不听话”。第四种最隐蔽上下文污染。比如我们把 RAG 检索到的文档片段塞进消息里但这些片段和当前意图无关模型就会被带偏回答一些“看起来很有道理但根本不是用户想问”的东西。所以 context-mode 不是一个炫技名词它是把上下文从“自然堆积”变成“主动管理”。下面我会从架构上拆开看一个合格的 context-mode 到底有哪几块积木。2. context-mode 的架构拆解2.1 会话层消息不是“堆进去”的而是“编排”出来的很多人在设计 context 的时候直接用一个数组存消息最后拼成 prompt 就完事。我建议把“会话存储”和“上下文构建”这两个概念分开。会话存储解决的是“信息怎么记”每一条消息要有独立 ID、角色、时间戳、来源类型用户、模型、工具回调、检索引用、系统事件、还有它的“重要度标记”。这样后续无论是裁剪、摘要还是检索都能按元数据做精细操作而不是只按顺序硬切。上下文构建解决的是“这次请求给它看什么”它不是把存储里的消息全取出来而是根据当前用户输入临时组装出一个“视角”。这个视角里可能有原始消息片段、可能有历史摘要、可能有检索到的知识块还可能有一条被改写过的问题比如把指代词还原成完整实体。举个例子用户说“那笔钱呢”系统先做代词消解改成“用户询问电费退款何时到账”再把改写后的这句话送去检索和匹配历史。这个改写结果不会存回数据库它只是本次上下文构建过程的中间产物。分层的好处是存储层保持干净策略层可以不断调优而不会污染原始数据。2.2 策略层三种主流上下文管理形态在我接触过的项目里上下文管理策略基本可以归为三类滑动窗口、摘要压缩、混合检索。大部分成熟系统用的都是它们的组合。滑动窗口最直接保留最近的 N 轮对话超出范围的直接丢弃。优点是实现简单、token 开销可控缺点是“信息只认新不认旧”用户前期提过的偏好和约束窗口一滑就没了。摘要压缩的核心是“用少量 token 代表大量历史”。系统定期把旧的对话内容拿给模型让它归纳成结构化摘要比如“用户是北京用户、偏好夜间下单、上周投诉过配送延迟”。摘要本身可以进一步做滚动摘要避免摘要越来越长。这个方案能解决长期记忆但摘要过程会丢细节对需要精确引用的场景不友好。混合检索的思路是不预先决定保留什么而是在每次请求时根据当前 query 去检索历史消息和知识库取回最相关的片段。这是 RAG 系统的常见做法也是最灵活的一种。缺点是依赖检索质量如果召回不准反而会引入噪音。我实际推荐的是三者的组合窗口层管“最近这几轮”摘要层管“稍早但重要的部分”检索层管“很久以前但相关的信息”。它们之间的优先级关系要根据业务来定。下表是我常用的参数模板层级策略典型容量适合内容风险即时层滑动窗口最近 10~20 轮当前任务、指代关系旧约束丢失摘要层滚动摘要每 10 轮产一条用户画像、长期偏好细节被压缩检索层向量/关键词召回top-k 3~6 条跨天历史、知识文档召回不精准这里每一个数字都不是拍脑袋定的后面第 3 部分我会讲怎么结合 token 预算去做推算。2.3 持久化层上下文要有生命周期还要有隔离很多团队一开始把上下文存在内存里进程一重启全部丢失。我建议至少要有一层外部存储哪怕是 SQLite 起步也行。每个 session 可以有不同状态活跃、待定、已归档。归档后不再参与常规构建只有当检索层命中时才会被临时唤醒。另一个容易踩的坑是“上下文串线”。如果你的服务是并发处理多个用户的一定不能把不同 session 的消息混在一个数组里。我见过一个项目因为没有给消息加 session_id 前缀结果两个用户的对话交叉出现在 prompt 里模型直接“精分”。隔离这件事要做在存储层而不是构建层。也就是说读写上下文之前的第一道校验就是 session 归属。3. 实操从零搭一个 context-mode 上下文管理器3.1 定义基础数据结构我会给你一套可以直接改的 Python 实现代码本身不依赖特定框架只用到标准库和可选的向量库接口方便你接进 FastAPI、Django 或者任意脚本里。先定义消息结构from dataclasses import dataclass, field from typing import Optional from enum import Enum import time class MsgType(str, Enum): USER user ASSISTANT assistant SYSTEM system TOOL tool SUMMARY summary # 压缩后的历史摘要单独作为一种消息类型 class MsgSource(str, Enum): LIVE live # 实时对话 RETRIEVED retrieved # 检索得到的旧消息 GENERATED generated # 系统生成的摘要 dataclass class Message: session_id: str role: str content: str msg_id: str msg_type: MsgType MsgType.USER source: MsgSource MsgSource.LIVE created_at: float field(default_factorytime.time) metadata: dict field(default_factorydict)我故意把 msg_type 和 role 分开原因是它们能对应不同的裁剪策略。比如 role 是 system 的消息未必一直保留而 msg_type 为 summary 的消息在滑动窗口里的优先级可以高于某些低价值的 user 消息。3.2 核心构建器一次完整的上下文装配接下来是核心的 ContextBuilder 类它要做三件事按预算裁剪、组装检索片段、生成最终 messages 数组。class ContextBuilder: def __init__( self, max_context_tokens: int 6000, live_window_rounds: int 10, summarize_every: int 10, ): self.max_context_tokens max_context_tokens self.live_window_rounds live_window_rounds self.summarize_every summarize_every def estimate_tokens(self, text: str) - int: # 中文场景下粗略估算一个汉字约 1~1.5 token这里取 1.3 估算 # 英文按空格分词估算。更精确请用 tiktoken 或对应模型的 tokenizer。 return int(len(text) * 1.3) 10 def build_messages(self, session_id: str, storage, retrieverNone) - list[dict]: # 1. 取出最近的 live_window_rounds 轮原始消息 recent storage.get_recent_rounds(session_id, self.live_window_rounds) # 2. 尝试读取最近的摘要 summary storage.get_latest_summary(session_id) # 3. 如果摘要为空且历史足够长则异步触发一次摘要生成 if summary is None and storage.get_total_round_count(session_id) self.summarize_every: summary self._generate_summary(storage.get_early_messages(session_id)) storage.save_summary(session_id, summary) # 4. 把摘要放进 system 前面的“记忆区” messages: list[dict] [] if summary: messages.append({ role: system, content: f[历史摘要] {summary}, }) # 5. 实时窗口消息直接追加 for msg in recent: messages.append({ role: msg.role, content: msg.content, }) # 6. 如果传入了检索器额外补充知识片段 if retriever and messages: query recent[-1].content if recent else hits retriever.retrieve(session_id, query, top_k3) for hit in hits: messages.append({ role: system, content: f[相关参考] {hit.content}, }) # 7. token 预算检查 total sum(self.estimate_tokens(m[content]) for m in messages) if total self.max_context_tokens: messages self._trim_to_budget(messages, self.max_context_tokens) return messages这段代码里值得注意的点在第 5 步为什么摘要放在所有实时消息之前因为模型对开头的部分注意力更高摘要代表的是“你应该长期记住的背景”放在前面可以让它更稳定地参与后续推理。而相关参考放在最后是让它作为“即时输入”与用户最近的问题相邻减少被长历史稀释的概率。3.3 裁剪与预算计算怎么做_token 预算_是 context-mode 中最容易让人迷糊的地方。你需要记住一个公式最终 prompt 预算 模型最大上下文 - 输出预留 - 系统指令固定开销比如你用的是 8K 上下文的模型设置最大输出 1024 token系统指令固定 200 token那么真正留给历史对话和检索片段的总预算就是8000 - 1024 - 200 6776 token我建议在这个数字上再打一个 0.8 的安全系数留出响应波动和 tokenizer 误差的空间实际配置 5400 上下比较稳。然后把这些预算拆成三个池子摘要区20%、实时窗口60%、检索参考20%。划分越明确越不容易出现“某次检索结果把历史全挤掉了”的问题。裁剪器 _trim_to_budget 的实现逻辑要慎重不能简单从头部一刀切。我常用的做法是优先去掉来源为 retrieved 且得分较低的片段再去掉最早的 live 消息最后才考虑压缩摘要。因为摘要已经是高度浓缩的再去掉它反而会让模型丢失基本盘。def _trim_to_budget(self, messages: list[dict], budget: int) - list[dict]: # 记录开销便于调试 costs [(i, self.estimate_tokens(m[content])) for i, m in enumerate(messages)] total sum(c for _, c in costs) while total budget and len(messages) 1: # 找到第一个可以裁剪的索引优先删 retrieved其次删 early live drop_idx None for i, m in enumerate(messages): if 相关参考 in m[content]: drop_idx i break if drop_idx is None: # 找到最早的 user 消息裁剪保留第一条 system for i, m in enumerate(messages): if m[role] user and i 0: drop_idx i break if drop_idx is None: break total - costs[drop_idx][1] messages.pop(drop_idx) costs.pop(drop_idx) return messages需要说明的是裁剪操作不应该修改存储层里的原始数据它只是“本次请求视图”的缩小镜。原始消息还在库里下次请求可能又会被检索层召回。这就是为什么我前面反复强调“构建视图”和“存储层”要分家。3.4 摘要生成与滚动更新摘要生成是 context-mode 中最依赖大模型判断力的环节。简单做法是把早期 N 轮消息一次性发给摘要模型让它输出结构化 JSON包含 user_profile、confirmed_facts、unresolved_questions、policies_mentioned 四个字段。这比让它自由发挥生成一段话要好用得多因为 JSON 能被稳定的解析和追加。滚动摘要的意思是如果已经存在一份摘要需要把旧摘要和新一批历史消息一起发给模型让模型输出一份“合并后的新摘要”而不是重新从原始终端生成。这样摘要长度基本恒定不会随着会话变长而无限膨胀。我在实际操作中会要求摘要模型最后必须输出一个 attributes 字典例如{ user_profile: {region: 北京, preferred_time: 夜间}, confirmed_facts: [用户账户余额不足欠费 58 元, 用户使用家庭共享套餐], unresolved_questions: [用户询问退款到账时间], policies_mentioned: [退款规则以支付渠道为准] }这个 JSON 可以直接存在数据库的 JSON 字段里后续检索时也能按 key 去匹配。比一大段自然语言摘要更可控。4. 上线前必须做的四类验证4.1 上下文污染测试给模型“下套”所谓的污染测试是故意在历史消息里塞一些与当前话题无关甚至相反的信息看模型会不会被带偏。比如之前的会话一直在聊“电费”检索层错误地召回了另一条“宽带费”文档那么正确的 context-mode 应该让模型回答“我这里没有宽带费数据”而不是顺着文档编造。我的测试方法是准备 20 组“事实对”每组包含正确事实、干扰事实、诱导问题。逐个跑完之后统计“被干扰带偏率”。理想状态下这个数字应该低于 10%如果超过 20%说明你的检索权重或摘要内容优先级有问题。4.2 遗忘与优先级测试看关键约束能不能活下来在长会话里用户最先提到的约束往往最重要。比如第一轮说“我只要省内的套餐”第五十轮问“帮我推荐一个”模型如果忘了“省内”这个限制推荐了全国套餐那就是不可接受的。测试步骤是先构造跨 30 轮的会话把关键约束放在第 2 轮然后让模型完成一个需要依赖该约束的任务。分别用不加 context-mode、普通窗口裁剪、混合检索三套方案跑记录约束保留率。我实测下来不加策略的版本约束保留率只有 20%~40%加了检索层后能到 90% 以上。4.3 长会话压力测试token 和时延的双重考验你还要关注性能。context-mode 不是只调一次模型摘要要调、检索要调、最终回答还要调。在最坏情况下一次用户请求可能触发 3~4 次模型调用延迟会明显上升。我建议做 70 轮的压测记录 P50、P95 延迟和 token 消耗。如果 P95 超过 3 秒就要考虑把摘要生成改成异步任务不要在用户请求的关键路径上同步等待检索层则要加缓存同一个 session 的同一个 query 在一小时内直接命中缓存。4.4 并发隔离测试别让 session 串味这个测试比所有人想象的都重要。开 50 个会话每个会话的消息里带上专属暗号比如“我的验证码是 12345请记住”。让这些会话并发跑几十轮最后逐个问模型“验证码是多少”。如果任何一个 session 的模型回答里出现了别的 session 的验证码说明你的隔离有问题。除了存储冗余另一个容易被忽略的隔离点是缓存。我见过有人把检索结果按 query 做全局缓存结果 A 用户问了“我附近有什么火锅”B 用户也问同样的问题B 拿到了 A 的历史信息。缓存 key 里必须包含 session_id这是 context-mode 里的黄金法则。5. 常见问题与排查技巧实录5.1 模型突然“失忆”先查裁剪器而不是模型如果你的模型没变、prompt 模板没变但隔了一段时间后它开始“忘记”早期内容第一嫌疑就是上下文被裁剪了。打开日志把每一次 build_messages 产生的 messages 内容和 token 数都打印出来对照看关键约束是在第几步被丢掉的。很多时候你会发现不是模型变笨了而是你的滑动窗口太小。我建议把构建上下文时的裁剪决策记录下来至少记录“丢弃了哪条消息、为什么丢弃、剩余预算多少”。这样问题复现时你能快速定位是预算不足还是优先级配置不对。5.2 频繁触发超限说明预算记账和实际消耗对不上很多模型 API 在接近 max context 时会报错即使你自己估算没超。原因常常是估算函数不准。中文、英文、代码的 token 密度差异很大一个粗略的 len(text) * 1.3 在英文场景可能偏差 40%。排查方式很简单在开发环境里用官方 tokenizer 对真实 messages 做统计和你的估算函数做对比算出误差系数然后往估算函数里加一个补偿系数。如果你用的 OpenAI 系模型直接调 tiktoken其他模型也有对应的 tokenizer 或 API 返回的 usage 字段记得把它存下来做校准。5.3 摘要内容出现“伪事实”摘要模型也会一本正经地编造。明明历史里没说过“用户已退款”摘要里却写了“退款已完成”那后续所有回答都会基于这个错误事实危害极大。我的应对策略是“摘要必带溯源”每一条摘要事实都附上一段原文引用或者消息 ID至少要让最终展示层能在用户追问时定位到出处。至于那些无法溯源的内容统一标记为 uncertain不让它直接进决策链路。你可以在摘要生成的 prompt 里加一句“如果你不确定请明确标注”。5.4 检索层召回太杂扰动反而大于帮助混合检索不是万能的有时候检索回来 3 条周围话题的内容把好好的对话节奏全打乱了。我后来在检索结果接入前加了一个“相关性阈值过滤”先用一个小的分类模型或规则判断检索片段与当前 query 的主题相似度低于阈值的直接丢掉。宁可少给参考也不要给错参考。5.5 并发高时的性能瓶颈如果你发现 context-mode 成了接口瓶颈多半不是上下文构建的问题而是摘要模型调用太频繁。我个人建议摘要生成走异步队列并且只在“会话空闲超过 5 分钟”或“新增消息达到 N 条”两种条件下触发而不是每次请求都重建摘要。6. 小结与下一步建议单纯从函数数量看context-mode 的代码量不大但它横跨了存储、策略、检索、模型调度四层。我在这套方案里最想强调的一点是它不是一个固定的库而是一套你可以不断调优的策略框架。接下来你可以做的事很明确。第一把滑动窗口、摘要、检索三个模块的参数独立配置方便做 A/B 测试。第二给每一次上下文构建加上可观测的中间产物也就是把“为什么这条消息被包含/排除”记录下来帮你快速定位问题。第三把这套模式和你的业务指标挂钩比如客服场景里的“一次解决率”、写作场景里的“引用准确率”用指标来判断策略调优到底是变好了还是变坏了。我自己的体会是context-mode 不该在项目上线后才补最好是产品原型阶段就引入。哪怕最开始只是简单的滑动窗口也比“无脑全塞”强十倍。上线之后再根据真实对话数据把摘要和检索一层层叠加上去风险要小得多。