最近跟几个做 AI 应用的朋友聊天，发现大家都在折腾同一个东西：context-mode。说白了就是大模型对话应用里的"上下文模式"——你往 prompt 里塞什么、保留什么、压缩什么，直接决定了产品用起来像不像一个真正"懂你"的助手。这个词看起来简单，但真落地的时候坑特别多。这篇文章我打算把一个基于 context-mode 的完整设计思路拆开讲，从核心原理讲到代码实现，再到线上踩过的坑，给正在做智能客服、知识库问答或者 AI 编程助手的同学一个可以直接参考的框架。
我先说结论：context-mode 不是一个库、不是一个框架，而是一套关于"上下文怎么组织"的策略集合。它的核心价值在于，在模型上下文窗口有限、token 成本有限、信息噪声无限的现实约束下，找到一条最优路径，让模型在每一轮对话里都拿到它真正需要的信息。下面我会从问题场景出发，逐步拆解三种主流模式，然后用 Python 手写一个最小可用实现，最后把我在线上踩过的典型坑和排查思路全部整理出来。
1. context-mode 到底是什么：先搞清楚它要解决什么问题
1.1 从一个"翻车"场景说起
我去年参与过一个电商客服机器人的项目，早期版本特别简单：每次用户提问，就把整个历史对话一股脑全塞给模型。前几轮效果还不错，用户问"我家狗粮还剩 3 公斤，能撑多久"，模型答得头头是道。
结果对话到第 12 轮的时候，用户随口问了一句"那我上次说的那个退款什么时候到账？"，模型直接懵了——它把 12 轮里所有信息都当成同等重要的内容，结果在一堆"发什么快递""猫砂能不能混用"的闲聊里，把最关键的用户 ID、订单号、退款原因全给淹没了。
这不是模型笨，是我们的上下文组织方式错了。所有信息都塞进去，等于所有信息都没被记住。这个场景让我彻底意识到，context-mode 不是一个锦上添花的功能，而是 AI 应用的底层基础设施。
1.2 context-mode 要解决的三个核心矛盾
第一个矛盾是窗口有限。主流模型的上下文窗口从 8K 到 200K 不等，看起来很够用，但真实业务场景里，一个高频用户聊 50 轮很正常，加上知识库片段、工具返回结果，几十万 token 分分钟就爆了。第二个矛盾是信息相关性不同。用户昨天说的"我喜欢蓝色外壳"可能对今天的售后问题毫无帮助，但模型不知道这一点，它只会一视同仁地处理所有历史消息。第三个矛盾是成本陡增。每多塞 1000 个 token，就多一次真实的金钱开销，高频场景下这个数字会指数级膨胀。
所以 context-mode 的本质，就是在这三个矛盾之间找平衡点：它不是"尽可能多地记住"，而是"尽可能精准地记住"。做得好，产品像真人助手；做得差，就是个一提问就胡言乱语的玩具。
1.3 哪些业务场景最需要引入 context-mode
不是所有 AI 应用都需要这套东西。单轮问答、一次性翻译、内容生成，直接塞 prompt 就行，完全没必要折腾。但下面这几类场景，不做 context-mode 基本活不下去：
- 多轮对话型产品：客服机器人、销售助手、心理陪伴类应用。用户的真实意图往往埋在多轮对话里，漏一段就全跑偏。
- Agent 类工作流：让 AI 自己决定调用哪些工具、按什么顺序执行。每一步的结果都是下一步的上下文，串不起来就卡死。
- 知识库问答：这个问题 RAG 已经很成熟了，但检索结果怎么和对话历史融合、怎么避免检索片段互相打架，依然是 context-mode 的活。
- AI 编程助手：一个项目里几十个文件，模型需要同时"记住"当前文件、相关函数、用户最近改动的意图，本质上就是多源上下文的组织问题。
如果你正在做以上任意一类产品，那这篇文章里的三种模式和一套实现代码，应该能直接帮你省掉至少两周的试错时间。
2. 三种主流的 context-mode 组织方式
2.1 滑动窗口模式：最简单的"最近优先"策略
滑动窗口是所有方案里最直觉的。核心思想是：只保留最近 N 轮对话，更早的内容直接丢进"记忆垃圾桶"。比如窗口大小设为 10 轮，那第 1 轮用户的初始需求，到第 15 轮的时候就已经被自动遗忘了。
那它为什么还能在很多场景下工作得很好？因为大部分对话都存在局部性。用户聊退款的时候，接着的三五轮大概率还是围绕退款；用户改代码的时候，最近的几次编辑就是他当前最关心的状态。滑动窗口的本质假设是"最近的就是最相关的"，这在大多数短期任务里是成立的。
实现上一定要注意按消息条数滑动还是按token 数量滑动。按消息条数简单，但一条 2000 字的长消息和一条"好的"差 200 倍权重；按 token 滑动更合理，但需要实时计算长度。我一般用 token 作为窗口计量单位，然后额外加一条硬性限制：消息条数不超过 40 条，防止单条超长消息把窗口全占满。
2.2 摘要压缩模式：对抗遗忘的高级解法
滑动窗口的问题是"遗忘"太粗暴了。用户第 3 轮说"我家的狗是只 4 岁的比格犬，对鸡肉过敏"，到第 20 轮聊到"出门五天怎么准备食物"时，这条信息早就滑出窗口了，但模型恰恰需要它来判断"不能喂含鸡肉的狗粮"。
摘要压缩模式的做法是：不等信息滑出窗口，而是在它快被丢掉之前，用模型生成一段摘要。这些摘要像"长期记忆笔记"一样，每次组装上下文时，把摘要和历史对话一起塞给模型。相当于给模型配了个随时更新备忘录的助理。
这里有个非常关键的细节：摘要不要只存事实，要把用户的偏好、状态、未完成事项单独总结出来。我见过太多人把摘要写成"用户问了快递、用户问了退款"，这等于啥也没写。好的摘要是这个画风：
用户（ID: 88231）正在咨询订单 #A203 的退款进度，该订单金额 329 元，用户已发起退款申请，目前状态为"待商家处理"。用户情绪略焦虑，在意退款到账时间。用户在对话早期提到家中宠物狗对鸡肉过敏，后续如推荐食品需避免。
这种摘要才是真正能在后续对话里"想起来"的东西。摘要压缩模式相比滑动窗口，信息保留率明显更高，但代价是需要额外调用模型生成摘要，有成本和延迟。
2.3 检索增强模式：按需捞取，不靠记忆靠索引
如果说摘要压缩是"主动记笔记"，那检索增强就是"用的时候去翻档案"。你不需要在上下文里保留所有历史，只需要把用户的历史消息、知识库文档提前切块、做成向量索引。每轮对话时，根据当前用户的问题，实时检索最相关的几个片段，拼进 prompt。
这个模式最适合知识库问答和 Agent 工具调用场景。比如用户问"帮我看看上周那份合同里违约责任怎么写的"，系统全文可能有 10 万字，但你只需要检索出"违约责任"相关的那 800 字塞给模型，剩下的全部留在索引里。
检索增强的核心在于切片策略和检索质量。切片切得太碎，单个片段缺乏上下文，模型理解不了；切得太粗，一个片段包含多个主题，检索噪声大。我的经验是：结构化文档按章节切，非结构化文档按固定长度 500~800 字切，重叠 50~100 字，效果最稳。
2.4 三种模式怎么选：一张对照表
很多初学者上来就问"到底用哪个"，其实它们不互斥，而是可以叠加的。我给你一个实操判断逻辑：
| 对比维度 | 滑动窗口 | 摘要压缩 | 检索增强 |
|---|---|---|---|
| 实现难度 | 低 | 中 | 高 |
| 信息保留能力 | 弱（只留最近） | 中（依赖摘要质量） | 强（按需捞取） |
| 实时性 | 高 | 中（摘要有延迟） | 高 |
| 成本 | 低 | 中（频繁调模型） | 中（向量库 + 检索） |
| 最适场景 | 闲聊、短任务 | 长对话、客服 | 知识库、Agent |
我的建议是分三层叠加：底层用滑动窗口保底，保证任何情况下 prompt 不会无限膨胀；中间层对窗口外的重要信息做摘要压缩；顶层对知识库类内容用检索增强。这套"三层金字塔"结构是我在多个项目里验证过的最稳组合。后面我就按这个结构来实现一个完整的 context-mode。
3. 手写一个最小可用的 context-mode 实现
3.1 设计目标与数据结构定义
在写代码之前，先明确我们要做到什么程度。我打算实现一个ContextManager类，支持滑动窗口、摘要压缩、检索增强三种策略，并且可以自由组合。它对外暴露的接口很简单：
add_message(role, content)：记录一条对话消息get_context(query)：根据当前用户问题，组装最终发给模型的上下文_maybe_summarize()：内部触发摘要压缩_retrieve(query)：内部触发检索增强
数据结构我用一个字典表示一条消息，字段包括role、content、timestamp。摘要单独记在一个列表里，每条摘要也带时间戳和对应的原始消息范围。为了演示，向量检索我用简单的余弦相似度而不是真接向量数据库，方便你拷贝就能跑。
from dataclasses import dataclass, field from typing import List, Dict import time, math @dataclass class Message: role: str # "user" 或 "assistant" content: str timestamp: float = field(default_factory=time.time) @dataclass class SummaryBlock: content: str start_time: float end_time: float3.2 滑动窗口的实现
滑动窗口的核心是"维护一个消息队列，超出预算就把最老的挤出去"。我这里用 token 估算而非字符数。中文字符和 token 的比例大概 1 比 0.7 到 1 比 1.2，不同模型有差异。为了通用性，我写一个简单的估算函数：英文字符数除以 4，中文按一个算 1.2 个 token，混排场景够用了。
def estimate_tokens(text: str) -> int: # 粗略估算 token 数，实际项目建议用模型的分词器 chinese_chars = sum(1 for c in text if '\u4e00' <= c <= '\u9fff') other_chars = len(text) - chinese_chars return int(chinese_chars * 1.2 + other_chars / 4)然后滑动窗口策略就是维护一个列表，在新增消息后检查总 token 数，超过max_tokens就从头部弹出。注意我保留了"系统级摘要"的位置——如果摘要已经存在，它不会被滑动窗口挤掉。
class ContextManager: def __init__(self, max_tokens=4000, window_messages=40): self.messages: List[Message] = [] self.summaries: List[SummaryBlock] = [] self.max_tokens = max_tokens self.window_messages = window_messages def add_message(self, role: str, content: str): msg = Message(role=role, content=content) self.messages.append(msg) self._prune_window() self._maybe_summarize() def _prune_window(self): # 双条件：token 上限 + 消息条数上限 while (len(self.messages) > self.window_messages or self._total_tokens() > self.max_tokens): if not self.messages: break self.messages.pop(0) def _total_tokens(self) -> int: summary_tokens = sum(estimate_tokens(s.content) for s in self.summaries) msg_tokens = sum(estimate_tokens(m.content) for m in self.messages) return summary_tokens + msg_tokens这里有个很容易忽略的细节：_total_tokens必须把摘要的 token 也算进去，否则你会发现日志里系统提示"上下文超限"，但自己的窗口明明设置得不大。我之前就在这个阴沟里翻过船。
3.3 摘要压缩的实现
摘要压缩的触发条件不能写死"每 N 轮执行一次"，因为对话长短差异太大。我采用一个动态判断：当前消息总 token 数超过 70% 窗口上限时，把最早的一批消息压缩成摘要。这样既不会频繁触发浪费钱，也不会等到快爆了才动手。
class ContextManager: # 接上面的类继续 def _maybe_summarize(self): if self._total_tokens() < self.max_tokens * 0.7: return # 找到最早的一半消息进行压缩 if len(self.messages) < 6: return split_idx = len(self.messages) // 2 old_msgs = self.messages[:split_idx] self.messages = self.messages[split_idx:] summary_text = self._summarize_messages(old_msgs) self.summaries.append(SummaryBlock( content=summary_text, start_time=old_msgs[0].timestamp, end_time=old_msgs[-1].timestamp )) def _summarize_messages(self, msgs: List[Message]) -> str: # 这里用 LLM 生成摘要，演示时用模板字符串代替 conversation = "\n".join(f"{m.role}: {m.content}" for m in msgs) prompt = ( "请将以下对话压缩为一份结构化摘要，必须包含：" "1) 用户的核心身份与偏好信息；" "2) 当前正在处理的未完成任务；" "3) 任何承诺、时间节点与关键事实。" "不要保留寒暄和无关内容。\n\n对话内容：\n" + conversation ) # 实际项目里：result = llm.chat(prompt) # 这里为了演示直接返回截断文本 return f"[摘要] 对话中用户提到：{conversation[:100]}..."生成摘要的提示词极其重要。如果你只是说"总结这段对话"，模型会给你输出一段废话。必须显式告诉它要提取哪几类信息，而且要强调"不要保留寒暄"。我做客服项目的时候，摘要 prompt 里还会加一条："如果用户表达过情绪（焦虑、生气、满意），请标注情绪状态"，这对后续对话的语气调整帮助特别大。
3.4 检索增强的实现
检索部分我做一个轻量版：把历史消息切成固定大小的 chunk，用 TF-IDF 向量做余弦相似度检索。真实项目里当然会用 embedding 模型，但原理是一样的——把文本变成向量，算相似度，取 Top-K。
import re, math from collections import Counter class SimpleRetriever: def __init__(self, chunk_size=200, top_k=3): self.chunks = [] self.chunk_size = chunk_size self.top_k = top_k self.tfidf_vectors = [] def index(self, text: str): # 按 chunk_size 字符切块 for i in range(0, len(text), self.chunk_size): chunk = text[i:i+self.chunk_size] self.chunks.append(chunk) self.tfidf_vectors.append(self._tfidf(chunk)) def _tokenize(self, text: str): # 简单中文分词：按字切 + 提取 2-gram，演示够用 text = re.sub(r'\s+', '', text) return [text[i:i+2] for i in range(len(text) - 1)] def _tfidf(self, text: str): tokens = self._tokenize(text) counter = Counter(tokens) total = len(tokens) return {k: v / total for k, v in counter.items()} def _cosine(self, a: Dict[str, float], b: Dict[str, float]) -> float: common = set(a.keys()) & set(b.keys()) dot = sum(a[k] * b[k] for k in common) norm_a = math.sqrt(sum(v*v for v in a.values())) norm_b = math.sqrt(sum(v*v for v in b.values())) return dot / (norm_a * norm_b) if norm_a and norm_b else 0.0 def retrieve(self, query: str, top_k=None): k = top_k or self.top_k q_vec = self._tfidf(query) scores = [(i, self._cosine(q_vec, vec)) for i, vec in enumerate(self.tfidf_vectors)] scores.sort(key=lambda x: x[1], reverse=True) return [self.chunks[i] for i, s in scores[:k] if s > 0]把这个检索器挂进 ContextManager 之后，get_context的时候先看用户的问题，决定要不要触发检索。如果问题里包含"合同""订单""之前说"这类词，说明用户需要翻旧账，就捞取相关片段拼进 prompt。
class ContextManager: def __init__(self, retriever=None): # 与前面重复的属性合并在这里 self.retriever = retriever # ... 其他属性 def get_context(self, query: str) -> str: parts = [] for s in self.summaries: parts.append(f"[长期记忆] {s.content}") for m in self.messages: parts.append(f"{m.role}: {m.content}") if self.retriever and self._need_retrieval(query): retrieved = self.retriever.retrieve(query) for r in retrieved: parts.append(f"[检索片段] {r}") return "\n".join(parts) def _need_retrieval(self, query: str) -> bool: keywords = ["之前", "刚才", "那个", "上次", "合同", "订单", "说过", "提到"] return any(k in query for k in keywords)3.5 串联完整链路：一个真实调用示例
把上面的代码拼起来，完整调用链路是这样的：
# 初始化 retriever = SimpleRetriever() retriever.index("订单 #A203 退款流程说明：用户提交申请后，商家需在 48 小时内处理。") cm = ContextManager(max_tokens=4000, retriever=retriever) # 模拟多轮对话 cm.add_message("user", "我刚买的狗粮还没发货，我想退款") cm.add_message("assistant", "请问您的订单号是多少？") cm.add_message("user", "订单号是 A203，能帮我查一下吗？") cm.add_message("assistant", "好的，我来帮您查询退款进度。") # 很晚之后用户又问 cm.add_message("user", "之前说的那个退款到账时间到底是多久？") context = cm.get_context("退款到账时间到底是多久？") print(context)输出结果里会包含长期记忆摘要、最近几轮对话、以及从知识库里检索到的"48 小时处理"片段。模型拿到这个组装好的上下文之后，才能给出"预计 2 天内到账，平台显示商家将在 48 小时内处理"这样准确且连贯的回复。
这个实现看起来简单，但它覆盖了 context-mode 的完整骨架。你可以在上面加 embedding、加 Redis 存储、加多租户隔离，方向都不会偏。
4. 线上踩坑实录：context-mode 的五个典型翻车现场
4.1 上下文污染：旧信息干扰新意图
我踩过最诡异的一个坑是：用户已经完成了退款，开始问新品推荐，但模型还在反复提退款的事。查了很久才发现，摘要模块把"退款中"的状态一直保留在长期记忆里，没有更新机制。问题不在于摘要本身，而在于摘要没有随状态变化而失效。
解决方案是在摘要块上加了一个active字段，每轮对话后用规则或小型模型判断：摘要里提到的任务是否已经闭环？比如检测到"退款"相关消息完结（用户说"收到了"，客服说"已退款"），就把对应的摘要块标记为失效，组装上下文时直接跳过。如果你不做这个机制，对话越长，过期的摘要越多，模型越糊涂。
4.2 token 预算失控：摘要自己也超了
刚开始上摘要压缩时，我犯过一个低级错误：只限制消息窗口大小，没限制摘要总量。结果用户聊到第 100 轮时，光摘要就堆了 8000 token，比消息本体还大。这就完全背离了 context-mode 的初衷。
后来我加了一条硬性规则：摘要总量超过窗口上限的 30% 时，对最早的摘要再做一层"摘要的摘要"。相当于给记忆系统加了自动归档机制——早期记忆变成高层次概述，只保留最近几轮的详细摘要。你可以理解为人的记忆也是这样，三年前的细节早就模糊成"那年我做了个项目，效果不错"这种级别了。
4.3 摘要丢失关键细节
摘要压缩最大的风险是模型漏掉细节。有一次用户在第 5 轮提到"我对花生过敏"，但摘要只写了"用户提及饮食偏好"，结果第 30 轮推荐菜单时模型推荐了含花生的菜品。回看日志，摘要模型确实收到了那条消息，但它认为"过敏"不如"用户正在安排聚餐"重要，就漏了。
我的补救策略是摘要 prompt 里增加"安全类信息优先"的硬约束，并且在摘要末尾追加一行：关键硬约束：对食物过敏、资金数额、截止时间等必须原文保留。此外，在消息被压缩之前，先用规则扫一遍是否包含这类关键词，有就直接把原句拼进摘要，不让模型自由发挥。
4.4 检索命中噪声：捞回来的内容帮倒忙
检索增强不是万能的，捞回来的片段有时候反而会把模型带偏。最典型的情况是知识库里同时存在旧版和新版两套流程文档，检索器按相似度把新版片段排在第一个，但用户问的其实是旧版场景下的历史订单。模型如果不知道版本差异，就会拿新流程解释旧订单，得出一个完全错误的结论。
针对这个问题，我给每个检索片段加了元数据头：[文档版本: v2.3 | 更新时间: 2024-06-01]。当同一个问题命中了多个版本的片段时，在 prompt 里用两句话提示模型"历史订单可能适用于旧版规则，请根据时间判断"。这个改动看起来很小，但线上准确率直接提升了十几个百分点。
4.5 并发场景下的上下文错乱
最后一个坑是工程层面的。如果同一个用户同时开着两个对话框（网页端和 App 端），或者 Agent 并行调用多个工具回写消息，上下文管理器就会遇到竞态问题——两条消息同时写入，拿到的上下文串了。
我用的是最朴素也最有效的方案：按 session_id 加锁，写入和组装上下文走同一个队列。单机用threading.Lock，多实例用 Redis 分布式锁。另外，每条消息必须带上session_id和seq序号，组装 context 时严格按seq排序。不要相信消息到达的时间戳，因为网络延迟会让时间戳乱序。
5. 根据我的实操体会，这几件事一定要做
5.1 可观测性是 context-mode 的生命线
第一个体会是：没有日志系统的 context-mode 就是黑盒。你光看模型输出变差了，根本不知道是滑动窗口挤掉了信息，还是摘要写歪了，还是检索捞错了。我在代码里给每次get_context都打了一条结构化日志：记录最终的 token 组成明细、摘要条数、检索命中了哪些片段。每次线上效果波动，第一时间翻日志定位，而不是瞎调参数。
具体来说，日志至少要包含：消息总数、摘要 token 占比、本次检索 Top-K 片段的 ID 和相似度分数、完整 prompt 长度。把这些指标每周拉一个趋势曲线，你会发现很多"玄学"问题其实都有规律，比如"每天下午 4 点后效果下降"这种，很可能是某个定时任务把知识库新文档灌进来，导致检索分布变了。
5.2 参数别拍脑袋，用回放数据来调
滑动窗口设多大、摘要触发阈值设多少、检索 Top-K 取几个，这些参数我从来不拍脑袋。我的做法是：把线上真实对话记录下来，做成回放集，然后在回放集上跑 A/B 实验。每次只调一个参数，对比"模型回答准确率"和"单轮 token 成本"这两个核心指标。
以窗口大小为例，实测下来 4000~8000 token 的窗口在大多数客服场景里性价比最高，再大收益不明显，成本却线性增长。摘要触发阈值放在 70% 是因为这时候压缩后的信息损失最小——太早触发会把还没聊透的细节压掉，太晚触发又可能压不住突发长消息。
5.3 再给一个所有场景通用的建议：永远留一条"逃生通道"
不管 context-mode 设计得多完美，总会有模型答错的时候。所以在产品层一定要加一个"澄清"机制：当模型发现自己拿到的上下文里信息不足时，允许它反问用户，而不是硬编一个答案。这个机制的实现只需要在系统提示词里加一句："如果你觉得现有信息无法回答用户问题，请直接向用户确认，不要推测。"就这么一句话，能把幻觉率肉眼可见地压下去。
context-mode 这个东西，做到后面你会发现真正难的从来不是算法，而是对业务的理解——你得知道哪些信息重要、哪些会过期、哪些需要跨对话保留。把这个想清楚了，用什么框架都是顺手的事。
