直接写。

说实话，我第一次接触到“context-mode”这个词，是在调一个多轮对话应用被逼得没办法的时候。那会儿模型聊着聊着就把前面的信息忘得一干二净，用户上一句刚说完自己姓甚名谁，下一句模型就开始胡编身份，气得我一度以为模型“降智”了。后来反复翻日志才发现，问题根本不在模型身上，而是我压根没管过上下文。所谓 context-mode，说人话就是给模型管理“短期记忆”的一套策略和模式：什么时候保留历史、什么时候裁剪历史、什么时候把旧信息压缩成摘要、什么时候从外部存储里把关键信息捞回来，这些都需要一个明确的模式来约束。这篇文章就是围绕“context-mode”这个概念展开的，我会把它的本质、主流实现路径、选型思路、核心参数、落地方式和踩坑实录一次讲清楚，适合正在做聊天机器人、Agent、RAG 应用，或者被长上下文搞到头疼的开发者参考。

1. 先搞明白：我们到底在管理什么“上下文”

1.1 上下文窗口的真实局限

先说背景。大语言模型本身是有输入长度上限的，也就是常说的上下文窗口。窗口越大，模型能“看到”的内容越多，但代价也越高：一是 token 费用随长度线性上涨，二是响应延迟明显增加，三是一个很容易被忽视的问题——上下文太长时，模型对中间段落的注意力会明显下降，反而更关注开头和结尾。国外有研究者把这种现象称作“中间丢失”，你塞给它一万五千字的背景材料，它很可能只记住第一段和最后一段，中间全部当背景板。

我打个比方你就明白了。上下文窗口就像一个你面前的小托盘，用户不断往上面放新菜，可托盘就这么大，旧菜不放下去新菜就摆不上来。如果你不管，最直接的结果就是托盘堆到放不下，要不就是模型直接报错，要不就是它把中间的菜全碰掉，只留下几片叶子。所以说，把上下文看成“无限追记”是不现实的，它需要的是主动管理，而不是被动堆积。

1.2 context-mode 到底是什么模式

context-mode 并不是某一个开源框架的专有名词，而是一类上下文管理策略的统称。它的核心思想是：把“历史对话内容”从天然的纯文本序列，变成一组可控的数据对象，按照预先定义的规则决定每轮请求时，哪些内容进入模型上下文、以什么形式进入、位置放在哪里。

举一个最直观的例子。假设用户和模型聊了三十分钟，产生了五十轮对话。你当然可以把这五十轮全部拼进请求里发给模型，这是最原始的“全量模式”。但更合理的做法是：前二十轮已经聊完了的主题，抽成一段两百字的摘要；中间十轮涉及用户偏好，单独存成结构化条目；最后二十轮保持原文。这样拼出来的上下文比原始文本短得多，但关键信息一点没丢。这套“怎么拆、怎么存、怎么拼”的规则，就是 context-mode 的实质。

1.3 为什么要“模式化”而不是“写死逻辑”

你可能会说，上下文管理直接写一段代码不就行了，为什么要刻意把它抽象成“模式”？

答案在于可复用性和可切换性。不同的业务场景对上下文的需求完全不同：客服机器人希望快速回忆用户历史工单，代码助手希望记住当前项目文件结构和最近改动的函数，角色扮演应用希望长期维持人物设定和关系记忆。如果你把这些逻辑全写在一个类的 if-else 里，换场景几乎等于重写。而把它抽象成几种模式——滑动窗口模式、摘要记忆模式、混合检索模式——你只需要切换策略对象，就能适应不同任务，这就是它叫“mode”而不是“module”的原因。

从工程实践来看，我强烈建议你把 context 的管理逻辑独立出来，不要散落在业务代码里。给系统留一个上下文管理器，专门负责读、写、裁剪、压缩、检索上下文，这样后续调优时你只需要碰这一个模块，不会牵一发动全身。

2. 主流 context-mode 实现路径：滑动、压缩、检索

2.1 滑动窗口模式：最朴素也最稳妥

滑动窗口是所有上下文管理模式里最基础、最容易实现的一种。它的逻辑非常简单：只保留最近 N 轮对话，更早的一律丢。比如设置窗口大小为二十轮，那么每来一轮新对话，系统就丢弃最早的一轮，始终保持最近二十轮在场。

这个模式的优点显而易见：实现成本极低，只需要一个双向队列，每轮对话后 push 一条、超出长度就 pop 一条；token 消耗完全可控；响应延迟稳定。它的缺点也很直接：早期聊过但后面还会用到的信息，一旦滑出窗口就彻底消失。比如用户在第 3 轮告诉你“我住在上海”，在第 40 轮问“你猜我在哪个城市”，模型这时候已经什么都不记得了。

所以滑动窗口模式适合什么场景？适合那些信息时效性强、轮次之间关联度低的对话，比如天气查询、临时性的问题解答、工具调用过程中的多步交互。如果你只是做一个“能连续聊天但不依赖长期记忆”的助手，滑动窗口就是性价比最高的起点。

2.2 摘要记忆模式：用“压缩”换“历史”

摘要记忆模式解决的是滑动窗口“忘得太快”的问题。它的思路是：当对话积累到一定程度时，不是简单丢弃早期内容，而是调用模型把早期内容总结成一段摘要，然后在后续请求中，用“摘要 + 最近若干轮原文”的组合来取代“全部原文”。

我习惯把摘要记忆分成两层：短期层保留最近几轮原始对话，长期层存放历史摘要。当短期层的 token 数超过预设阈值，就触发一次摘要动作——把当前短期层内容合并到长期摘要里，然后清空短期层，继续接收新对话。这样模型每次看到的都是“旧事概要 + 新鲜事原文”，既控制长度，又不至于把历史全盘抹掉。

这里有一个特别需要注意的细节：摘要本身也会越积越长。当你的应用持续运行了几百轮之后，长期摘要可能已经长到几千 token，这时候必须对摘要做二次压缩，比如把旧摘要归纳成更上层的概要，或者只保留跟当前任务相关的那部分摘要。这也是为什么摘要记忆模式不能只做一层，必须设计多级摘要机制。

2.3 混合检索模式：记忆不一定要全带上

前面两种模式都有一个共同前提：所有历史都必须“在场”。滑动窗口把历史压缩到最近 N 轮，摘要模式把历史压缩成摘要，但本质上信息仍然是以连续文本的形式参与生成的。混合检索模式则彻底改变了这个思路——历史信息不再常驻上下文，而是被写入外部存储，等需要时再检索回来。

具体做法是：每一轮对话结束后，把这一轮的内容做向量化（embedding），连同原文一起存进向量数据库，同时也可以抽取结构化信息（实体、偏好、意图）存进普通数据库。当用户发起新问题，系统先对问题做向量化，然后去向量库执行相似度检索，取回最相关的若干条历史片段，和当前问题拼接后一起交给模型。

这个模式的优势是上下文永远不会被无关历史撑爆。有一次我做一个企业知识库问答系统，用户的历史对话可能跨几十个主题，如果用滑动窗口，聊到后面早就把开头关于合同审批流程的讨论忘了；用检索模式就完全不受影响，用户随时问回之前聊过的内容，系统都能从向量库里把相关片段捞回来。代价是需要额外维护一套存储和检索链路，选型和调优的复杂度明显更高。

三种模式我整理过一张对比表，方便你按需选型：

3. 怎么选型：先看场景，再定策略

3.1 三类典型任务的模式选型思路

很多同学一上来就问我：我到底该用哪种模式？我的回答通常是：先别急着选模式，先回答三个问题。

第一，这个对话的“有效记忆半衰期”是多长？用户提到一个信息之后，多久可能会再次用到？比如一次性问答，半衰期可能只有几十秒，用滑动窗口就够了；但如果用户是在分多轮追问项目方案，早期讨论的背景信息随时会被引用，就必须用摘要甚至检索。

第二，历史中能被未来复用的信息占比大概多少？如果你的对话基本是线性推进的，每轮都会用到上一轮的结论，那检索模式反而发挥不了作用，因为找不到零散的“关键片段”；反之，如果对话内容覆盖多个独立主题，用户可能随时跳回旧话题，检索模式就非常合适。

第三，你能接受的工程复杂度上限是多少？滑动窗口可能半小时就能接上；摘要记忆需要一个可靠的摘要触发与存储机制；混合检索则意味着要搭向量数据库、写 embedding 管道、维护召回质量。很多项目失败就是因为在复杂度上盲目上探，最后维护成本把业务拖垮。

基于这三个问题，我的经验判断是：客服和 FAQ 类系统优先考虑混合检索；角色扮演和长周期任务型 Agent 优先考虑摘要记忆；简单的多轮对话助手直接从滑动窗口起步，等出现“忘了前文”的问题再升级。

3.2 关键参数怎么定：窗口、阈值、切换条件

无论选择哪种模式，最后都会落到几个具体参数上，这些参数设得好不好，直接决定体验。

窗口长度：滑动窗口模式下，N 到底取多少？我的经验是不要只按“轮数”算，要按 token 算。比如设定上下文上限 4000 token，平均每轮 200 token，那么窗口就是最近 20 轮。如果你们选用的模型支持 8k 甚至更大窗口，也不要贪多，建议先跑出真实对话数据的平均 token 数再倒推窗口轮数。

摘要触发阈值：摘要模式下，短期层积累到多少 token 触发一次摘要？我常用的初始值是 2000 token 或最近 8 轮对话，两者取先到者。触发太频繁会让每次请求的延迟变大，触发太晚则短期层过长，压缩效果打折。

检索召回量：混合检索模式下，topK 取多少？这个参数我习惯控制在 3 到 6 条之间。取太少容易漏关键信息，取太多则会把无关噪音塞进上下文，反而干扰模型。配合相似度阈值使用，比如最低相似度设为 0.35（按余弦距离），低于这个值宁可不召回。

模式切换条件：成熟的系统往往不是单一模式走到底，而是根据上下文长度动态切换。比如上下文 token 数低于 3000 时走全量模式；超过 3000 但低于 6000 时走滑动窗口；超过 6000 时启用摘要压缩。这里的切换点没有标准答案，需要结合模型表现和计费成本实测调整。

4. 实操：从零搭一个可用的 context-mode 管理器

4.1 最小实现：带系统提示词保护的滑动窗口

纸上谈兵没意思，直接上一个可用的最小实现。我先展示一个滑动窗口模式的上下文管理器，它有一个关键设计：系统提示词永远不会被滑出窗口。

import json from collections import deque class SlidingWindowContext: def __init__(self, max_tokens=4000, system_prompt=""): self.max_tokens = max_tokens self.system_prompt = {"role": "system", "content": system_prompt} self.messages = deque() def _estimate_tokens(self, text): # 按中英文混合场景粗略估算：约1.2字符/字面token # 生产环境建议改用模型的 tokenizer return int(len(text) * 1.2) def _total_tokens(self): total = self._estimate_tokens(self.system_prompt["content"]) for msg in self.messages: total += self._estimate_tokens(msg["content"]) return total def add_message(self, role, content): self.messages.append({"role": role, "content": content}) # 滑窗裁剪：从最老的消息开始移除 while self._total_tokens() > self.max_tokens: self.messages.popleft() def build_request(self): return [self.system_prompt] + list(self.messages) # 使用示例 ctx = SlidingWindowContext( max_tokens=4000, system_prompt="你是一个贴心的线上客服助手。" ) ctx.add_message("user", "我想了解一下退款政策") ctx.add_message("assistant", "当然可以，退款政策是……") req_messages = ctx.build_request()

这段代码整体的核心就是 add_message 里的 while 循环：每加一条新消息，就检查总 token 是否超限，超了就丢最老的。之所以在 build_request 里把系统提示词放在消息列表最前面，是为了让模型接收时依然保持“先系统指令、后历史对话”的标准结构。一个需要特别提醒的坑是：如果你直接用len(messages)只按轮数裁剪，遇到超长单轮消息时依旧会爆量，所以一定要按 token 来算，而不是按条数。

4.2 升级：给它加一层摘要记忆

接下来在滑动窗口的基础上叠加摘要记忆层。这里我用一个小型模型来做摘要，避免每次摘要都走大模型导致延迟过高；在实际项目中，这一步的具体实现会因为模型 API 不同有差异，但逻辑是通用的：超过阈值就触发摘要生成函数，然后把摘要作为一条特殊消息放回上下文。

class SummaryMemoryContext: def __init__(self, max_tokens=6000, summary_threshold=2000): self.max_tokens = max_tokens self.summary_threshold = summary_threshold self.summary = "" # 长期摘要 self.recent_messages = deque() # 短期原文 self.system_prompt = {"role": "system", "content": "你是一个可靠的对话助手。"} def _trigger_summary(self): # 如果短期内容超过阈值，就把短期原文发给摘要模型 # 这里用占位函数表示，实际项目替换为具体的模型调用 history_text = "\n".join( f"{m['role']}: {m['content']}" for m in self.recent_messages ) # 合并旧摘要和本轮短期内容 combined = self.summary + "\n" + history_text self.summary = self._summarize(combined) self.recent_messages.clear() def add_message(self, role, content): self.recent_messages.append({"role": role, "content": content}) typing_tokens = sum(len(m["content"]) for m in self.recent_messages) if typing_tokens > self.summary_threshold: self._trigger_summary() def build_request(self): messages = [self.system_prompt] if self.summary: messages.append({ "role": "system", "content": f"[历史摘要] {self.summary}" }) messages.extend(self.recent_messages) return messages

这里有个容易踩坑的地方：摘要信息用什么角色放回去。我建议不要用普通的 user 或者 assistant 角色，而是单独用一条 system 消息，写成“[历史摘要] ...”，这样模型能够明确区分“这是压缩后的背景资料”和“这是当前对话内容”，减少混淆。还有一个小技巧，摘要触发时不要把短期层清空得太干净，我通常保留最后两到三轮原文，因为它们很可能正在参与当前话题的讨论，贸然清掉会让下一轮模型突然“失忆”。

4.3 效果验证：怎么判断 context-mode 真的有效

很多同学实现了上下文管理器之后，不知道怎么评估效果。我分享一个简单有效的测试方法：设计一组“跨轮次信息引用”的测试对话。

比如先在对话早期刻意埋入一个不相关但明确的事实，像“我的工号是 2024-007”，中间隔上几十轮闲聊，最后再若无其事地问一句“你记得我的工号吗”。如果模型答对了，说明上下文管理器至少在这个维度上是有效的。反之，如果答不上来，就说明信息在写入或检索环节丢失了。

更严谨的方法是记录三项指标：信息召回率（跨轮事实被正确回答的比例）、上下文平均 token 数（直接对应费用和延迟）、回复质量人工评分（让几个人盲测前后对比）。我最常看到的情况是：优化后上下文 token 明显下降，费用省了一大截，但信息召回率也同步下滑，这往往是因为裁剪策略过于激进。记住一个铁律：上下文管理的本质是在“成本”和“信息完整性”之间找平衡，任何只优化其中一项的方案都是不可持续的。

5. 常见问题与排查技巧实录

5.1 历史越聊越忘：摘要信息在“稀释”

一个非常典型的问题是：随着摘要越积越长，模型对摘要末尾内容的注意力越来越弱，明明摘要里写了用户是自由职业者，问了三次用户职业，三次都露出茫然脸。排查到最后发现，摘要里确实有这条信息，但被淹没在了一大段旧摘要中间。

解决办法有两种，你可以任选其一。第一种是“分段摘要”：把长期摘要按照主题拆成几个小段，每段用一句概括性标签打头，比如“[工作]-自由职业，主要写设计文案”，构建请求时只选择跟当前问题相关的那一段拼进去。第二种是“倒置位置”：把最近的摘要放在靠前的位置，让模型的注意力优先级更高，旧摘要往后排。我实测下来，第一种方法的效果更持久，因为它同时解决了长度和定位两个问题。

5.2 摘要失真：压缩过程改了原意

摘要模型在压缩长文本时，很容易出现一个危险的问题：表面上总结得很流畅，但把细节给“圆”没了，甚至自行脑补出不存在的结论。你说用户说过“不喜欢太辣”，摘要里可能变成了“用户饮食偏好清淡”——方向上是接近的，但这个等价关系一旦被当作事实输入给主模型，后续推荐的菜品就会跑偏。

核对摘要是否失真，我建议采用一致性校验：摘要生成后，不直接让它进入上下文，而是让摘要模型再做一个动作——根据摘要回答几个预设的细节问题，把答案和原文里的事实做比对。如果对不上，说明摘要失真，需要退回原文重新压缩或者直接保留原文。这套流程听着麻烦，但在关键业务场景里是值得的。

5.3 检索召回质量差：向量相似度不总是可靠

混合检索模式最让人头疼的问题就是召回结果“看似相关实则无关”。用户问“订单怎么取消”，检索回来的历史片段可能是用户在半年前抱怨“这家店取消订单很麻烦”，语义上相关，但对解决当前问题毫无帮助。

我的排查思路分三步。第一步，先看 embedding 是否领域适配，通用 embedding 在专业术语面前表现往往不理想，需要尝试领域微调过的模型。第二步，加上重排（rerank）层，先向量召回 20 条，再用精排模型选出最相关的 5 条，这一步骤对质量的提升通常非常明显。第三步，为关键业务类型手动维护关键词索引，跟向量检索做混合召回，用传统的 BM25 兜底。我见过不少项目就是在召回侧加了 BM25 之后，答案准确率从六成直接跳到八成以上。

5.4 上下文管理器自身的 bug 比模型更难发现

这个坑我栽得最深。模型回复错了，你能从回复内容里反推；但上下文管理器拼错了内容，模型已经基于错误输入给出了看似合理的回复，排查难度直接翻倍。比如我在一个项目里发现，用户的一句话被重复拼了三次进上下文，模型开始“复读机式”地回答相同内容，我一直以为是模型抽风，查了半天才发现是消息去重逻辑写错了。

所以强烈建议给上下文管理器增加完整的访问日志：每一次 build_request 后，记录当前系统里摘要、近期消息、检索片段分别占多少 token、各来自哪里。类似给对话系统配一个“黑匣子”，业务反馈回复不对时，先看这个日志，能省掉一半的排查时间。

6. 容易被忽略但非常重要的工程细节

6.1 系统提示词的保命位置

很多滑动窗口实现会无差别裁剪所有消息，包括最开头的系统提示词。一旦系统提示词里的角色设定、输出格式要求被挤掉，模型的行为会发生不可预知的漂移，而且你还不容易觉察——它不会报错，只会用一种“奇怪但合理”的方式回复。

我的建议是把系统提示词拆成两层：一层是“无论什么情况都必须保留”的核心指令，放在请求的最前面；另一层是“任务补充说明”，允许被裁剪或压缩。在滑动窗口的裁剪逻辑里，永远从中间开始裁，两头不动，这样即使上下文再长，模型的角色定位也不会丢。

6.2 按 token 计费的隐藏成本

很多人把上下文管理当成纯功能优化，没意识到它其实是成本优化的第一道闸门。同样运行一小时的对话服务，全量模式下每轮请求的 token 会持续增长，到后面可能一次请求就吃掉几万 token；而开了摘要记忆模式之后，每轮请求的 token 被压在阈值附近，费用可能直接降一个数量级。

要特别小心的是摘要模型自身的成本。每次做摘要都是一次额外的模型调用，如果频率设置得太激进，摘要费用可能会超过省下的费用。建议是：用一个更小、更便宜的模型专门承担摘要任务，只要摘要质量可以接受，就别让主模型去干这个活。我在项目中通常会单独记录“主链路 token”和“摘要链路 token”，两条曲线拿到仪表盘上看，超了才知道问题在哪。

6.3 上下文的跨请求一致性

在多轮对话系统里，用户不会连续地只跟你的后端交互，中间可能有其他逻辑在修改消息记录。如果上下文管理器被多个调用方共享，就一定要做好并发控制。我见过一个翻车案例：一个 Web 应用开了并发请求后，上下文里的消息队列出现乱序，模型开始按错误顺序“理解”对话，回答质量急剧下降。

一个实用的做法是：给每一轮对话维护一个递增的 sequence 序号，build_request 之前先按序号重排消息列表。这样即使某些环节乱序写入，最终交给模型的还是有序内容。这算是一个很小的防御性编程习惯，但能避免很多隐性故障。

6.4 动态模式切换是最终形态

坦率地讲，单一模式跑到底很难在所有场景都表现好。我在线上系统里实际验证下来，组合策略是最稳定的：以滑动窗口为基础，保证响应速度；同时维护一层摘要记忆，在上下文接近上限时启用；在特定意图触发时，才去调用检索层找回更久远的关键信息。三种模式并行，由路由逻辑根据上下文长度和用户意图动态切换。

这个组合并不需要非常复杂的代码，本质上就是几个 if-else 分支加上状态标记。但它的价值在于：让上下文管理器从“一套固定的算法”进化成“一套灵活的机制”，这在我看来才是 context-mode 最值得投入的状态。

最后再分享一个我个人养成的习惯：每次给一个新的上下文管理模式写代码，别急着把代码和业务强耦合，先做一个独立的模块，用模拟对话数据反复压测几轮，观察它会怎么处理“信息埋点”“超长文本”“重复内容”这三种边界情况。踩过的坑多了就会发现，上下文管理从来不是锦上添花的事，而是一旦出了问题，整个对话应用的体验都会跟着崩盘。希望这篇基于 context-mode 的拆解能让你少走几条弯路。