context-mode：决定大模型应用质量与成本的分水岭

最近好几个社群都在聊“context-mode”，有人以为是某个新框架的配置项，有人拿它在调大模型 API，还有人干脆把它当成“上下文窗口”的简称。这个词确实被用滥了，但它背后指向的东西非常具体：应用在跟大模型打交道时，如何处理、传递、回收对话上下文的那套策略。我前后在好几个项目里跟它打过交道，踩过不少坑，今天就把我对 context-mode 的理解和实操经验完整整理出来。这篇文章适合正在做 AI 应用接入、智能体开发、RAG 改造的开发者，也适合想搞清楚“为什么模型老记不住话”的产品经理——看完你会知道问题多半不在模型，而在你的上下文管理模式。

1. context-mode 到底是个什么东西

1.1 先从一次 bug 说起

之前我做一个客服问答机器人，初版逻辑非常简单：把用户每一次提问拼上历史消息，一股脑丢给大模型。上线当天效果还行，第二天就开始抽风——用户问“刚才那个退货运费是多少”，机器人一脸茫然地反问“哪个运费”。我一开始怀疑是模型不行，后来把请求日志打出来才发现，单轮对话里塞了 12 轮历史消息，加上系统提示词，一次请求的 token 快要破万，模型确实能把所有字都“看”完，但回答质量肉眼可见地下降。

这不是个例。很多开发者在接入大模型时，默认以为“上下文窗口越大越好”，于是把所有能塞的东西全塞进去。结果就是：输入越长，单次响应越慢，费用越高，而且模型反而抓不住重点。context-mode 要解决的就是这类问题——它不是某一个具体的 API 参数，而是一整套关于“上下文如何被组织、压缩、缓存、遗忘”的方案。

1.2 接待员模型：上下文模式的本质

我后来跟朋友聊这个问题，发现一个特别好的类比：把大模型想象成一个极其聪明但记忆力有限的接待员。你给他一张纸条，上面写着所有客户的完整聊天记录，他确实能在里面找到信息，但找得很慢，还经常被无关信息干扰；如果你递给他的是整理过的要点摘要，他处理起来又快又准。

不同 context-mode 之间的差异，本质上就是你递给接待员“纸条”的整理方式不同。现在主流做法有这么几类：

• 完整历史模式：把多轮对话原封不动全带上，适合短会话、高准确性要求场景，但成本和时延都很高。
• 滑动窗口模式：只保留最近 N 轮对话，模拟人的短期记忆，实现简单，早期 chatbot 最喜欢用。
• 摘要压缩模式：把早期对话压缩成一小段摘要，再拼上近期完整对话，兼顾记忆长度和 token 成本。
• 检索增强模式：不依赖对话历史，而是从知识库中检索相关内容拼进上下文，适合知识问答类应用。
• 缓存复用模式：系统提示词、历史公共部分做 KV 缓存，重复请求不再重复计费，适合高频调用场景。

你看，这五个模式解决的是不同层次的问题。实际项目中很多人把它们混着用，结果上下文一团糟。我在后面第 3 章会详细讲怎么组合，这里先记住一个核心原则：上下文不是越多越好，而是越“相关”越好。

2. 为什么上下文模式决定了大模型应用的天花板

2.1 长文本不是万能药

有一段时间流行一个说法：模型上下文窗口到 128K、200K 了，RAG 是不是没必要做了？反正把文档全丢进去就行。我见过真有人这么干，把一本产品手册 8 万字直接塞进提示词，让模型归纳。结果呢？生成速度慢得崩溃，费用高得离谱，最后总结出来的要点还不如原来只塞前三章准确。

这个现象背后有个被很多人忽略的事实：大模型对上下文中间部分的注意力天然弱于开头和结尾，业界管这叫“lost in the middle”。哪怕窗口有 200K，塞进去 150K 的无关内容，关键信息埋没在中间，模型照样抓瞎。所以长上下文只是给了你更大的“房间”，不代表你应该把整个仓库都搬进去。

真正决定应用质量的是：你选择让哪些信息进入这个房间，以及它们以什么顺序排列。这就是 context-mode 存在的意义。

2.2 成本、速度、效果的三重账

接大模型应用的人没有不算账的。我们拿一个日均 10 万次调用的小应用举例：

具体数字按各家模型定价会有差异，但趋势很明确：同样的业务量，上下文管理模式选得好，成本能差出一个量级。我见过有团队为了省事用“完整历史模式”硬扛流量，结果账单翻了三倍，第二天就紧急改版。另外很多人没注意时延——用户可不管你是不是塞了 2 万字才回答，3 秒以上基本就会流失。

2.3 上下文工程：新的必修课

去年大家还在卷提示词工程（prompt engineering），今年风向已经变成“上下文工程”（context engineering）。因为提示词写的再花哨，如果送进模型的上下文本身是乱的，提示词根本无力回天。

上下文工程做的事情，就是设计一套规则：哪些信息必须带、哪些可以丢、哪些需要压缩、哪些要检索、哪些要缓存。它比提示词工程更底层，也更吃架构功底。一个完整 context-mode 方案，通常包含四个环节：组织（organization）、压缩（compression）、检索（retrieval）、缓存（caching）。这四个环节的先后顺序、搭配比例，决定了一个 AI 应用的质量下限和成本上限。

我在多个团队看到同一个现象：提示词写了一版又一版，效果始终不稳定，最后排查下来是上下文管理模块的问题。所以如果你当前正被“模型回答不稳定”折磨，我建议先把 80% 的精力放到上下文这层来。

3. 实操：把你的应用切成 context-mode

3.1 先分清三种上下文模式

动手之前，先给上下文分个类。不是所有信息都该用同一种方式处理，我习惯把上下文分成三层：

• 系统层：模型的人格设定、回答规则、输出格式约束。这部分几乎不变，最适合做缓存。
• 会话层：当前对话产生的历史消息，包括用户问题和助手回复。这部分要按轮次做取舍。
• 数据层：外部知识、用户资料、业务数据。这部分体量最大，不能全塞，必须检索或压缩。

这三层对应不同的 context-mode 策略：系统层走“缓存复用”，会话层走“滑动窗口+摘要”，数据层走“检索增强”。我在项目里是这么拆的，后面每一步配置都会围绕这个分层展开。

3.2 最小可用实现：随手就能跑的代码

下面我用一个实际项目中的 Python 代码示例，展示一个混合 context-mode 的最小实现。这个代码解决的就是开头那个客服机器人的问题：既能记住上下文，又不至于把历史全塞进去。

from typing import List, Dict import json class ContextManager: """一个极简的上下文管理模式实现""" def __init__(self, max_turns: int = 6, max_context_len: int = 4000): self.max_turns = max_turns # 滑动窗口：最多保留6轮完整对话 self.max_context_len = max_context_len # 上下文总长度上限（token估算） self.history: List[Dict] = [] self.summary: str = "" # 摘要压缩：早期对话的压缩结果 def add_message(self, role: str, content: str) -> None: """新增一轮消息""" self.history.append({"role": role, "content": content}) def _summarize_old_history(self) -> str: """把超窗对话做摘要压缩（示例直接用截断，生产环境应调用LLM做压缩）""" if len(self.history) > self.max_turns: old_parts = self.history[:-self.max_turns] old_text = "\n".join([f"{m['role']}: {m['content']}" for m in old_parts]) # 这里的压缩逻辑可以换成真正的 LLM 摘要调用 self.summary = old_text[:800] + "...(已压缩)" # 丢弃已压缩的旧消息 self.history = self.history[-self.max_turns:] def build_context(self, system_prompt: str, knowledge: str = "") -> List[Dict]: """组装最终发送给模型的上下文""" messages = [] # 第1层：系统层（可走缓存） if system_prompt: messages.append({"role": "system", "content": system_prompt}) # 第2层：摘要层（早期对话的压缩记忆） if self.summary: messages.append({ "role": "system", "content": f"以下是更早对话的摘要，请把它当作已发生的背景：{self.summary}" }) # 第3层：数据层（检索增强，由外部传入相关片段） if knowledge: messages.append({ "role": "system", "content": f"以下是参考资料，优先依据它们回答：{knowledge}" }) # 第4层：会话层（滑动窗口，只带最近几轮） messages.extend(self.history) return messages # 使用示例 cm = ContextManager(max_turns=6) cm.add_message("user", "我想退货，怎么操作？") cm.add_message("assistant", "您可直接在订单页面申请退货。") cm.add_message("user", "运费谁承担呢？") messages = cm.build_context( system_prompt="你是某电商平台的客服助手，回答要简洁。", knowledge="退货运费规则：七天无理由退货运费由买家承担；因质量问题则卖家承担。" ) print(json.dumps(messages, ensure_ascii=False, indent=2))

这段代码能跑，但只是骨架。核心思路是：消息进入时先按窗口截留，超出窗口的旧消息在后台做压缩，请求时再把系统层、摘要层、数据层、会话层四块拼起来。你会发现分类后的上下文非常清晰，模型收到的信息没有冗余，自然回答得准。

实际接入大模型 SDK 时，只需把messages传给chat.completions.create(messages=messages, ...)即可。很多框架本身不帮你做上下文管理，只负责传输，所以这个处理层得自己写。

3.3 进阶：缓存与压缩并用

当请求量上来以后，你会发现每次请求都在重复传输同一个 system prompt 和知识库片段，这部分 token 是纯浪费。现在的模型供应商基本都支持 KV 缓存，只要你传入的公共前缀完全一致，系统会命中缓存，价格和延迟都会下降。

实操上的关键点是：把不变的系统层内容放在 messages 最前面，然后才是变化的会话层。因为缓存的命中条件是“前缀一致”，一旦前面有任何一个字符发生变动，整个前缀缓存全部失效。

另一个进阶技巧是摘要压缩的触发时机。不要每轮都压，那样既慢又贵。我一般设置一个“记忆水位线”：当历史消息超过 N 轮或超过某个 token 量时才触发一次压缩任务，压缩结果替换掉旧消息。就像人脑一样，不是每时每刻都在回忆，而是到一定时间节点才做一次梳理。

再补充一点：如果你的应用需要处理多用户，每个用户会话的摘要最好单独存储，不要混在一个全局变量里。上面代码是单会话演示，生产环境要把history和summary按user_id/session_id做持久化，否则用户 A 的历史会串到用户 B 的上下文里，后果很严重。

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

4.1 模型“忘了”刚才说的话

这是所有人遇到的第一个问题。排查思路不要太着急调模型，先按顺序检查三处：

第一，确认请求里真的带上了历史消息。我见过很多“忘事”案例，最后发现是前端每次只发当前输入，历史根本没传给后端。

第二，检查窗口裁剪逻辑。如果你用的是滑动窗口，看看窗口长度是否过小。我建议单条会话至少保留 4 到 8 轮，少于 4 轮模型很难建立连续感。

第三，看摘要压缩是否出错。摘要模式最大的坑是压缩后信息失真，比如用户之前说过“我家在南方，冬天没暖气”，摘要压成了“南方用户”，后面回答时就丢失了关键信息。压缩任务本身最好用摘要能力强的模型来做，不要用截断代替。

4.2 上下文越堆越贵

成本失控多半是“完整历史模式”跑太久。我之前接手过一个项目，单用户对话 20 轮之后，一次请求光历史就有 8000 多 token，乘以日活用户数，账单直接起飞。

治本的方法是分层：历史消息不能一视同仁。早期对话压缩成摘要，中期对话保留最近 10 轮，当前轮次完整保留。如果你用的是带 KV 缓存的接口，还要确保 system prompt 和摘要部分绝对前置，保证缓存可以命中。另外，上下文不是只能等对话结束才清理，用户切换到新话题时也可以主动重置，避免把上一个话题的陈年旧账全背在身上。

4.3 检索结果反而帮倒忙

RAG 检索出来的片段本来就该是“助攻”，但如果你把一堆低相关片段全塞进上下文，模型反而会被带偏。我做过一个测试：同一个问题，只给 2 个高相关片段时回答准确率 87%；给了 2 个高相关加 6 个低相关片段后，准确率掉到 71%。无关信息的干扰是实打实的。

所以检索增强不是“检索了就得全放进去”，一定要加一个相关度阈值。低于阈值宁可返回“资料库暂无相关信息”，也别硬塞。另外一个实用技巧是检索结果里标明来源位置（如“《使用手册》第三章”），模型回答时天然会引用更准确。

我把这些排查思路整理成一张速查表，方便你对照：

5. 跳出 AI：context-mode 在其他领域的表现

5.1 命令行世界里的 context

很多开发者每天都在用 context-mode，只是没意识到。比如kubectl的 context 切换、git 的 current branch、云服务的 profile 配置——这些本质上都是“上下文管理”：系统只根据当前选中的 context 来决定执行目标，而不是每次把所有集群、所有环境全部加载一遍。

这个思路跟 AI 应用里的 context-mode 如出一辙：通过收缩当前可见范围，降低信息负担，提升决策速度。你切换 kubectl context 时，其实就是告诉系统“我现在只关心这个集群”，和人类“我只关心最近这几轮对话”是同一个逻辑。

5.2 编辑器里的上下文感知

现代代码编辑器里的“上下文模式”也在做类似的事：IDE 根据光标所在文件、语言类型、最近打开过的标签页，动态决定代码补全和诊断要参考哪些内容。它不是把你整个工作区的几十万行代码全塞给分析引擎，而是精准提取当前相关的几个模块。

这也解释了为什么好的 AI 编程助手在超大仓库里仍然表现不错，差一点的助手在文件一多就宕机——背后就是上下文管理的差距。你把什么喂给模型，决定了模型还你什么结果，这句话放到任何领域都成立。

我个人的体会是：做过 AI 应用之后再回头看这些传统工具，会发现通用的规律——凡是涉及“有限资源下的信息决策”，都需要 context-mode 的思路。做 AI 应用时，别急着堆功能，先把系统层、会话层、数据层的边界画清楚，再决定每一层用什么模式。这个准备工作花不了半天，但能帮你避开后面数周的成本爆炸和效果翻车。