做 AI 应用的时间一长大概率都会撞上同一个尴尬场景用户聊了十几轮突然提到第一轮交代过的背景模型却开始失忆反问起来。这真不是模型变笨了而是应用层没有真正把 context-mode上下文模式做实。这个模式听着玄乎说白了就是给 AI 装上选择性记忆——既要它在连续对话里记住关键信息又不能让上下文无限膨胀把窗口撑爆。我这两年在好几个项目里反复折腾这套东西踩过不少坑也总结出了一套能直接落地的工程方案。这篇文章就把架构设计、代码实现、问题排查完整过一遍想给团队引入 context-mode 的可以直接照着抄。1. 为什么说 Context Mode 是 AI 应用的记忆中枢1.1 上下文窗口不是越大越好很多团队选模型时盯着参数表看觉得 128K、200K token 的窗口已经绰绰有余。真上线了才发现窗口光是装得下远远不够。首先是成本问题每次请求都会把全部上下文发给模型输入 token 一多账单直接起飞。其次是延迟首字返回时间会随着上下文长度明显变长用户那边就是转了半分钟没反应。更隐蔽的是模型对超长上下文的注意力会退化你塞了 80K 的日志进去模型反而抓不住最后几轮对话里的关键指令。这就像让一个人同时读十份合同他能读完但你要他准确说出第三份合同的第三条条款就得翻半天。context-mode 要解决的本质上就是资源调度问题在有限的上下文预算内把最重要的信息放到模型面前。不是所有历史消息都值得让模型读一遍很多对话过了几轮之后细节就变得无关紧要了保留反而是一种噪音。真正有价值的往往只是几类信息用户的核心意图、已经确认的事实、尚未完成的任务、以及最近几轮的即时语境。1.2 用户体验和成本之间的博弈没有 context-mode 的应用通常只有两个极端状态。一个极端是无状态设计每次请求都只带当前用户输入和固定 system prompt模型永远记不住五分钟前的事用户需要反复重复自己的需求体验极其割裂。另一个极端是盲目全量把所有历史消息一股脑塞进去短期看是记住了成本和延迟也同步失控了。这两个极端我都见过真实项目踩进去过。无状态的方案适合那种一次性问答比如文档问答里用户每次都是独立问题但放到客服、写作助手、编程助手这种强交互场景用户天然默认 AI应该记得我们之前聊了什么一旦忘了就会被认为产品很蠢。盲目全量的方案在 Demo 阶段很爽演示时整个会话都顺畅但一上生产、并发一起来账单和超时告警会逼着你马上重构。context-mode 就是在两端之间划出的那条中间路线既保留会话的连续感又通过机制主动管理记忆的存储和释放。它的本质不是让模型更聪明而是让应用更懂取舍。1.3 从无状态接口到有状态应用的跳跃做传统后端的人对状态管理其实不陌生Session、Redis、数据库事务都是解决状态的手段。但 AI 应用的状态管理有个完全不同的特点它的状态不是结构化数据而是自然语言。你可以把用户 ID 存在 MySQL 里但你不能要求模型每次回答前都去查一次数据库把用户意图读出来。语言本身就是模型的状态载体。所以 context-mode 的核心逻辑变成了一条流水线接收原始对话识别哪些信息值得保留怎么保留原文、摘要、还是结构化槽位下次请求时用什么样的顺序把记忆重新组装出来最后塞给模型。这条流水线就是 AI 应用的记忆中枢后面的所有架构设计、代码实现都是围绕这条流水线展开的。想清楚这一层再去看各种 Context Management 框架思路就通透了。2. Context Mode 的整体架构设计2.1 先拆模块记忆不只是缓存我见过不少团队把 context-mode 简单理解成Redis 里存一份聊天记录这其实只完成了存储环节。一个能上生产的上下文模式至少要拆成五个模块会话存储层、上下文组装器、预算控制器、压缩策略器、检索增强器。每个模块都有明确的职责边界互相之间只通过接口通信这样后续替换组件比如从 Redis 换到向量库才不会牵连一片。会话存储层管的是原始消息的持久化它得支持按会话 ID 存取消息列表也得上消息编辑和删除接口因为用户经常会撤回或修改说法。上下文组装器是核心枢纽负责从存储层捞数据按既定策略决定哪段用原文、哪段用摘要、哪段走检索最终拼出一次请求的 prompt。预算控制器是个会计所有进 prompt 的内容都要经过它的 token 计量超标就打回重来。压缩策略器是记忆的橡皮擦当会话累积到一定程度就把旧消息压成摘要或者抽取成结构化的事实。检索增强器负责从更久远的记忆里捞回被压缩掉的内容通常基于向量召回。五个模块协作才能实现既有短期记忆、又有长期记忆的完整上下文模式。下面这张表可以直观看到每个模块的职责和常见选型模块核心职责常见实现选型会话存储层持久化原始消息支持增删改查Redis、PostgreSQL、MongoDB上下文组装器按策略拼接 prompt 片段自定义组装逻辑可做成 Pipeline预算控制器计量 token控制窗口占用tiktoken、模型官方 Tokenizer压缩策略器生成摘要、抽取关键事实大模型摘要、规则抽取、分层摘要检索增强器从长期记忆召回相关片段Embedding 向量库pgvector、Milvus2.2 三种核心模式怎么选context-mode 在实践中会派生出很多变体但底层跑不出三种模式短窗口全量、滚动摘要、检索增强。短窗口全量最简单就是只保留最近 N 轮对话原文超过 N 轮的直接丢弃适合对话轮次少、上下文短的应用比如单轮工具调用。滚动摘要则是在会话超过阈值后让模型把旧消息总结成一段摘要每次请求都带上这份摘要加最近几轮原文。检索增强更进一步把历史消息先向量化存进向量库请求时通过语义相似度捞回相关片段再拼进上下文。选型没有银弹得看业务场景。客服机器人这种用户问题重复度高、但每次会话独立的滚动摘要就够了代码助手这种用户改了半小时代码每个改动都有上下文依赖的短窗口全量加关键文件全文更靠谱企业知识管家这种用户随时会问三天前聊过的某个细节的就必须上检索增强。我自己的习惯是优先组合使用比如滚动摘要保底、检索增强补细节这比押注某一种模式稳妥得多。2.3 一个容易忽略的决策组装顺序prompt 拼装不是简单把记忆倒进去就完事顺序直接影响模型的理解效果。上下文窗口里有个很出名的Lost in the Middle现象模型对开头和结尾的内容敏感对中间部分容易忽略。所以组装时要刻意做位置管理。我的标准顺序是这样的system prompt全局规则放最前面让模型先构建行为基线然后是检索出来的长期记忆片段这部分是辅助信息放前面比放中间好再是历史摘要用于补充背景最后才是最近几轮的原文对话它们要贴着用户当前问题确保模型对最新意图有最直接的感知。检索结果和摘要之间空一行分隔符能明显减少模型把不同信息源混淆的概率。这个顺序我反复测过效果比把历史全部堆在开头好不少。3. 核心实现上下文管理器实操3.1 数据结构设计先定好记忆单元动手写代码前先设计数据模型。消息不能只存谁说了什么还需要状态标记否则后续压缩、检索、组装都无从下手。我在项目里定义了一套消息结构每条消息至少包含这几个字段消息 ID、会话 ID、角色user/assistant/system、内容、时间戳、状态raw/compressed/retrieved、元数据可扩展存 token 数、话题标签等。元数据看起来是加分项实际是必备项压缩和检索都依赖它做筛选。下面是一个最小可用的数据结构示例# 消息模型的最小定义 dataclass class ChatMessage: message_id: str # 全局唯一 ID session_id: str # 会话 ID role: str # user / assistant / system content: str # 文本内容 created_at: datetime # 创建时间 state: str raw # raw / compressed / retrieved token_count: int 0 # 预计算的 token 数 metadata: dict field(default_factorydict) # 扩展字段 # 会话聚合根管理整个对话状态 dataclass class Conversation: session_id: str system_prompt: str messages: list[ChatMessage] summary: str # 滚动摘要压缩策略写入 summary_token: int 0 facts: list[dict] field(default_factorylist) # 抽取出的关键事实这个结构看着简单但解决了两个关键问题一是 state 字段让上下文组装器能区分原始消息和压缩产物组装时按需取用二是 summary 放在会话对象上而不是每条消息上因为它描述的是整个会话的演化过程。token_count 是写入时就计算好的避免组装时逐条现算省下不少延迟。3.2 Token 估算与预算分配预算控制是整个 context-mode 的命脉预算算不准后面全白搭。我强烈建议用模型官方的 tokenizer 做精确估算而不是按字符数拍脑袋。以 OpenAI 系模型为例tiktoken 库可以按模型类型拿到准确的 token 数其他家的模型也都有对应的 tokenizer务必用官方实现因为不同 tokenizer 的分词结果差距很大估算偏差会导致截断或浪费。预算分配我一般按比例切而不是给每一段定死绝对数值。默认的分配策略是 system prompt 占 10%近期对话原文占 55%滚动摘要占 20%检索结果占 10%留 5% 的安全余量。这个比例可以根据模型窗口总量换算成绝对 token 数比如窗口是 32K那 system 就是约 3.2K近期对话约 17.6K。安全余量非常重要因为模型回答本身也要占窗口超了会直接报错预留 5% 到 10% 是经验值。计算过程可以封装成一个 BudgetCalculator组装前先预估本次请求的总量如果超出预算就触发压缩而不是组装到一半才发现爆了。这个预检动作在线上的价值很大能拦截大部分上游正常、下游报错的诡异问题。我在代码里一般把预算校验放在组装器入口任何拼装都先过这道卡口。3.3 压缩策略从全量记忆到结构化记忆压缩是整个环节里最依赖模型能力的一步也是最容易出质量事故的一步。常见的压缩形式有三种原文截断、摘要生成、事实抽取。原文截断最无脑超过条数直接丢最老的消息适合没有强依赖的闲聊场景。摘要生成让模型把旧对话总结成几百字的摘要能保留大部分背景信息但摘要生成本身有成本和延迟。事实抽取是把对话里的关键实体、偏好、任务状态抽成结构化字段比如用户偏好 简洁回复任务 订购机票未完成这种最稳定后续组装时可以当成伪 system prompt 用。我的做法是三层配合而不是只选一种。新消息先全量保留当会话轮数超过阈值比如 20 轮时把前 10 轮压缩成摘要同时每轮都可能做轻量的事实抽取把用户交代过的偏好、约束、待办提取出来。这样组装时既有摘要提供背景也有事实列表提供确定性信息比单一摘要的抗遗忘能力强很多。压缩的触发条件建议用预算占比来控制比如当近期原文 token 数超过预算的 60% 就触发而不是死等窗口爆掉。下面是一个简单的压缩触发和摘要生成实现import tiktoken class ContextManager: def __init__(self, modelgpt-4, max_context_tokens32000): self.tokenizer tiktoken.encoding_for_model(model) self.max_context_tokens max_context_tokens def estimate_tokens(self, content: str) - int: return len(self.tokenizer.encode(content)) def compress_if_needed(self, conv: Conversation, max_dialogue_tokens: int): dialogue_tokens sum(m.token_count for m in conv.messages if m.state raw) # 超过预算 60% 即触发压缩带一点提前量 if dialogue_tokens max_dialogue_tokens * 0.6: return False # 压缩旧消息这里会调用模型生成摘要为便于说明只给出伪代码示意 conv.summary self._generate_summary(conv.messages[:-10]) # 被压缩的消息标记状态不再进入上下文组装 for msg in conv.messages[:-10]: msg.state compressed conv.summary_token self.estimate_tokens(conv.summary) return True有个细节必须提醒_generate_summary 是同步调用大模型的会引入几百毫秒到一两秒的额外延迟绝不能让用户在这一轮对话里干等。我的做法是压缩异步化在检测到需要压缩时先把摘要生成任务丢进后台队列当前请求继续用压缩前的内容回复等下一轮请求到来时摘要已经生成好了直接用。这套思路跟读缓存和写缓存的异步刷新是一个道理。3.4 检索增强让 AI 找到被压缩掉的旧记忆压缩必然带来信息损失摘要压得再精细用户突然问起我上周提过的那个需求细节时摘要里大概率没有。这时就得靠检索增强把原始消息捞回来。检索增强的整体思路是把所有原始消息切块后做 embedding存入向量库用户提问时先对当前问题做 query 改写再用向量相似度召回最相关的历史片段把这些片段当作临时记忆拼进上下文。切块策略直接影响召回效果。我的建议是按对话轮次切块而不是按字符数硬切。每一轮 user 和 assistant 的对话作为一个完整语义单元embedding 后存储因为一轮对话本身就包含了完整的前因后果硬按字符切会把语义拦腰截断。块的长度控制在模型 embedding 的推荐范围内比如 512 token 以内太长向量会被稀释太短语义不完整。召回数量上top-k 我一般取 5 到 10 条具体看上下文预算宁缺毋滥塞太多无关片段反而会增加噪音。query 改写这一步很多人会跳过但实际效果差异很大。用户说那个方案怎么样了时直接拿这句话去检索那个方案是模糊指代命中率很低。改写例程可以让模型把当前问题补全成带上下文信息的独立表述比如结合之前讨论的登录优化那个方案怎么样了再去检索命中率立刻上一个台阶。改写本身也消耗一次模型调用可以做轻量化用一个较小的模型或者事先预设好的模板来解决。3.5 上下文组装所有记忆的临门一脚组装器是最后把所有记忆拼到一起的地方也是最容易出低级 bug 的地方。我在组装器里维护了一个严格的顺序列表每次请求都按固定顺序拼接并通过预算控制器做总量校验。组装逻辑大致如下先追加 system prompt 和抽取出的关键事实清单这两者是全局约束再追加检索召回的历史片段然后追加滚动摘要最后追加最近 N 轮原文消息紧跟用户当前输入。每段之间加一个明确的分隔标记比如history、summary、current让模型能清晰区分信息源。def assemble_prompt(self, conv: Conversation, current_query: str, retrieved_chunks: list[str] | None None) - str: parts [] # 1. 系统规则与关键事实 system_block conv.system_prompt if conv.facts: system_block \n\n[Key Facts]\n \n.join( f- {f[content]} for f in conv.facts) parts.append(system_block) # 2. 检索到的历史片段 if retrieved_chunks: parts.append([Retrieved History]\n \n\n.join(retrieved_chunks)) # 3. 滚动摘要 if conv.summary: parts.append(f[Conversation Summary]\n{conv.summary}) # 4. 最近几轮原文紧随当前问题 recent_raw [m.content for m in conv.messages[-6:] if m.state raw] parts.append([Recent Messages]\n \n.join(recent_raw)) parts.append(f[User Current]\n{current_query}) return \n\n---\n\n.join(parts)这段代码刻意用了简单的列表拼接没有引入重的框架是因为组装逻辑本身不复杂但业务上经常要调整顺序或者加字段保持轻量反而更容易改。真正要在工程上做扎实的是中间那些 if 判断哪些记忆在什么条件下该加入什么条件下不该加入。比如新会话没有历史摘要时summary 块就得跳过不加空标记检索结果为空时也不能硬塞一个空块占位。这些边界处理决定了组装出来的 prompt 在极端情况下是否还能正常工作。4. 常见问题与排查技巧实录4.1 上下文割裂模型忘事的第一现场症状很典型用户上一轮说我叫小明帮我记录一下下一轮问我叫什么名字模型答不上来。很多人第一反应是模型不行但排查后会发现是 context-mode 在组装时把记录名字那轮对话丢掉了。我在自己项目里就踩过这个坑原因是压缩策略按轮数硬切总是只保留最近 10 轮用户一提早于 10 轮的关键信息就彻底失忆。排查方法很简单把组装后的完整 prompt 打日志打出来肉眼检查关键信息在不在里面。修复方式有两种一是做关键事实抽取把用户名字偏好约束条件这类结构化信息单独拎出来放进 facts 列表组装时固定放在 system 区域这样无论多少轮以前都不会丢。二是在压缩时做硬保留把含有高价值信息比如包含用户明确指令、数字细节、邮箱电话等的消息设成不可压缩状态。两种方式不冲突可以同时用实际效果是模型的长期记忆会明显变稳。4.2 Token 预算超限明明算过了还爆明明预算控制器算得好好的线上还是会出现maximum context length exceeded的报错。这种问题九成出在模型回答的长度上。很多场景的 prompt 本身就接近预算上界模型回答又占了 1K 到 2K token总输入加输出就超了。我之前只算输入侧预算忽略输出侧上线第一周就被这个坑了个措手不及。解决办法是给输出侧留够空间。先把 max_tokens 参数显式设好然后预算控制时把输入预算 总窗口数 - max_tokens - 安全余量如果安全余量取 5%那输入侧实际可用比例就不到 95% 了。更严谨的做法是把 max_tokens 也纳入预算控制器组装前做的预检直接检查当前输入 预估输出是否在限内超了就提前触发压缩或裁剪检索结果。这样能把报错率压到接近零毕竟模型请求一旦报错对用户体验的伤害比多花一点 token 的代价大得多。4.3 压缩失真摘要把关键信息消化掉了滚动摘要用久了容易在某个节点把重要信息压没了。比如用户之前反复强调回复要口语化、不要用敬语摘要模型生成时觉得这是次要信息直接省略后续所有回复风格都跑偏。这种问题最难排查因为摘要模型是黑盒你不知道哪句话被丢了。我的排查思路是给摘要加要素自检清单生成摘要时在 prompt 里要求模型按固定结构输出必须覆盖用户明确提出的偏好、所有未完成任务、重要的实体名词、已确认的决策和变更点。不只是让它总结这段对话而是给一个模板让它往模板里填。另外摘要生成时可以同时让模型输出一行信息完整度评分低于某个阈值就报警至少能让问题在第一时间暴露出来而不是等用户投诉了才发现。这里还有个土办法很有效定期把摘要和原始对话放一起抽样比对人工看一眼就能发现摘要是不是开始偷懒了。4.4 延迟陡增记忆环节成了性能瓶颈加了 context-mode 之后接口延迟不降反升的情况也常有。主要嫌疑集中在三处一是压缩策略里同步调用大模型生成摘要每轮请求都多了一次模型往返二是检索增强走的向量库查询串行执行没有和模型调用并行三是 token 估算阶段如果每条消息都现算一遍长会话的场景光 tokenize 就能吃掉几十毫秒累计起来也可观。对症下药的方法压缩尽量拆到异步任务里用户当前的请求不走压缩那条链路向量检索和模型调用之间如果业务允许可以在拿到用户 query 后并行发起检索结果回来后拼进 prompt 再调模型token 数写入消息时就算好缓存变更时增量更新避免每次都全量重算。这些优化不会影响功能正确性纯粹是工程上的性能磨刀但对 P99 延迟的改善非常明显。我在一个客服机器人项目上做完这三步接口平均延迟从 2.4 秒降到了 1.1 秒效果立竿见影。下面把几类高频问题整理成一张速查表方便定位时对照症状常见根因排查切入点解决建议模型忘了早前对话关键信息被压缩/裁剪查看组装日志里的完整 prompt引入事实抽取硬保留高价值消息请求报上下文超限忽视输出 token 占用检查预算控制器是否包含 max_tokens输入预算 窗口 - 输出 - 余量回复风格突然变味摘要丢失了用户偏好检查摘要内容并比对原始消息用摘要模板强制覆盖偏好、任务、实体接口延迟明显升高压缩/检索串行同步调用打点看各环节耗时压缩异步化检索与模型调用并行检索结果文不对题query 指代不清或切块不完整查看召回片段与 query 改写结果加 query 改写按对话轮次切块5. 从能用到好用监控体系怎么搭上下文模式上线后光靠功能正常运转还不够。我这边的经验是一定要有可观测性否则内存管理的问题会像慢性病一样折磨你。我在系统里埋了几个关键指标第一个是上下文预算使用率能看出系统整体是不是经常逼近上限第二个是压缩触发次数如果压缩过于频繁说明会话长度设计不合理或者应该更早启动检索分流第三个是摘要生成的成功率和平均耗时这直接关系接口延迟。日志层面每次组装完成的完整 prompt 务必要落盘方便排查一切模型怎么答成这样的疑难杂症。可以在日志里加上 team 标识类似 request_id把一次请求的原始输入、检索结果、摘要、最终 prompt、模型输出串成一条链路排查问题时一次拉全不用到处拼证据。这个习惯帮我省了无数个半夜排查的夜晚。有条件的话可以加一层自动评测在测试集上定时对比不同压缩策略和检索参数的问答准确率让优化有数据支撑而不是每次靠感觉调参。5.1 先小流量试点再全量上下文模式是深度影响模型回复质量的一层不能拍脑袋全量上线。我建议先在内部或者小范围白名单用户里跑一版观察摘要质量、延迟、报错率这几个核心指标跑几天再逐步放开。这类改动最怕的是线上出了问题你还不知道是组装策略还是模型本身的锅小流量试点能让你在可控范围内把问题都暴露出来再集中修掉。我自己每次改压缩策略或者检索参数都是先在一部分会话上做 A/B对比用户满意度或任务成功率确认正向收益才全量推。5.2 别把 context-mode 做成一把梭最后想提醒一句上下文模式不是万能药它只解决在有限窗口里高效利用记忆的问题。如果你的业务本质上是单轮问答完全不需要引入这套复杂度老老实实把 system prompt 写好就够了如果你的业务动辄需要几十万字的长文档分析那问题重点在文档切片和检索而不是对话记忆管理。看清场景边界再决定投入多少才是做技术选型的正确姿势。这个判断比任何框架和代码都重要。我在实际项目里把 context-mode 落地过好几轮从最早的手写拼接到后来用框架再到最后返璞归真自己维护核心逻辑最深的体会是这套东西真正的难点不在某一个模块怎么写而在模块之间的衔接是否顺滑——存储层状态改没改对预算器和组装器有没有一致压缩和检索会不会互相覆盖。把这些衔接打磨顺了AI 应用的记忆体验才会有质的提升。如果你正准备动手建议先把我上面讲的五个模块的职责边界理清楚再一行代码一行代码去填比急着找现成框架要靠谱得多。