大模型上下文管理模式(context-mode)实战：从原理到代码实现

context-mode 这个词，乍一看像是某个编辑器插件里的开关选项。我第一次见到它，是在一个对话式 AI 项目的技术方案评审里，当时没太当回事，后来被上下文溢出、角色混乱、答非所问这些问题反复摩擦，才真正理解这个词背后的分量。说白了，context-mode 解决的是一个特别朴素但又特别要命的问题：系统在每一次做判断的时候，到底该看到哪些信息，屏蔽哪些信息，这些信息用什么样的结构喂进去。这篇文章我会从大模型应用开发这个最常见的切入角度，把这个词涉及的原理、关键技术、可落地的代码实现和踩过的坑一起讲透，适合正在做智能问答、Agent、Copilot 类产品的开发者，也适合想搞清楚上下文管理机制的技术人。

1. 先搞明白：context-mode 到底在解决什么问题

1.1 三个层面里的"上下文模式"

如果你在搜索引擎里搜 "context-mode"，会发现这个词在不同领域有完全不同的解释。在编程语言层面，它可能指一个贯穿方法调用的 Context 对象，用来传递用户身份、事务信息或请求参数；在交互设计层面，它可能指应用根据用户所处页面、权限、时间段动态切换操作入口的能力；而在大模型应用层面，它指的是发送给模型的 token 组合——对话历史、检索到的知识片段、工具返回的结果，全部塞进同一个窗口，模型基于这堆信息生成回答。

我最初以为这几个概念只是同名巧合，后来发现它们背后有同一个核心逻辑：让系统知道"我是谁、现在在哪、下一步该怎么办"。Context 对象是程序员手动维护这个答案，交互设计是程序自动推导这个答案，而大模型应用是把这个问题丢给模型自己去理解。当你的业务足够复杂，这三个层面会同时出现，并且互相影响。我在一个项目中就遇到过这种组合场景：前端页面根据用户角色切换操作模式，后端接口用 Context 传递调用链信息，而最上层的 AI 助手又要根据用户当前的意图选择不同的 Prompt 策略。任何一个环节的上下文给错了，整个链条都会出问题。

1.2 为什么不能简单粗暴地"全塞进去"

很多团队一开始的做法是：把所有内容一股脑拼进 Prompt，反正模型上下文窗口够大。这种思路在 demo 阶段确实能跑通，但一旦真实用户连续聊了五十轮，问题就全冒出来了。模型开始重复早期说过的话，把用户第一轮提到的错误信息当成事实引用，甚至忘记系统给它设定的身份。你以为是模型变笨了，其实是你把太多无关信息堆到了它面前，导致它对关键指令的感知被稀释。

上下文的价值不是"越多越好"，而是"刚刚好"。这就像给一个分析师开会前递材料：你如果把他过去五年看过的所有报告全放桌上，他大概率抓不住今天要决策的重点；你如果只给一份摘要加上相关的三份附件，他反而能快速给出高质量判断。context-mode 要解决的，就是如何动态准备这份"会议材料"。一个设计得当的上下文模式管理器，需要回答三个问题：这段历史值不值得保留、用什么形态保留、在什么时机注入当前 Prompt。

1.3 信息边界才是核心

设计 context-mode，本质上是在给模型的判断划定一个信息边界。边界太宽，噪音淹没信号；边界太窄，关键信息丢失。我见过一个客服机器人的案例：用户先问"退货流程是什么"，接着又追问"运费谁出"。如果上下文模式是全量拼接式，模型很可能把退货政策里的运费规则和当前会话混在一起，回答得模棱两可。但如果模式设计成按意图分类存储，系统会先识别出当前意图是"退款运费咨询"，再只把相关规则碎片和订单信息注入上下文，回答不仅准确，还能自然带出用户订单里的真实商品信息。

这就是信息边界的作用：它不是简单地对上下文做裁剪，而是对上下文做语义层面的重组。后面我会具体讲怎么实现这种重组。

2. 上下文管理里绕不开的关键技术点

2.1 窗口上限与注意力稀释

先聊一个很多人都会误解的点：模型上下文窗口从几千 token 涨到百万 token 级别，是不是意味着以后不用做上下文裁剪了？我的答案是：别高兴太早。窗口变大解决的是"能不能塞下"的问题，没有解决"塞下去之后模型能不能用好"的问题。当序列变得很长时，注意力机制会出现一种被称作注意力稀释的现象——模型会把有限的注意力权重分散到非常多的 token 上，那些真正关键、却藏在长文本中段的指令，反而拿不到足够的权重。

我在实测一个长文档问答项目时发现：把相关片段从 8k 上下文挪到 30k 上下文里，回答的准确率不升反降。原因很简单，额外的 20k token 都是用户为了测试效果粘贴的无关资料，它们把关键信息的信噪比拉低了。所以，不管模型窗口有多大，上下文都需要做筛选和聚合。这个原则在 context-mode 的设计中始终有效。

2.2 三种经典的上下文压缩策略

窗口再大也有用完的时候，更别提实际部署时推理成本跟 token 数直接挂钩。上下文压缩大致有三条路线：

• 截断式（Drop）：只保留最近 N 轮对话。实现最简单，但会丢失早期信息，用户如果中途改口，模型可能察觉不到。
• 摘要式（Summarize）：把早期对话压缩成一段摘要。比如"用户已经确认了收货地址是杭州西湖区，正在询问发票抬头"。这种方案能保留长期语义，但代价是摘要的过程本身要消耗 token 和时间。
• 结构化存储（Structured Memory）：把对话中的关键信息抽成字段，比如用户名、订单号、商品规格、当前意向。这种方式信息密度最高，但需要定义清晰的信息抽取规则，通用性稍差。

真实项目里很少只用一种策略。我在设计一个购物助手的上下文模式时，采用的是"结构化为骨架、摘要为中间层、近期对话为细节"的三层结构：第一层存用户画像和订单状态字段，第二层存每一轮会话的主题摘要，第三层才放最近五轮的完整对话。这样的好处是，模型在任何时候都能从骨架层拿到稳定信息，从中间层拿到历史脉络，从细节层拿到最新的用户表达。

2.3 检索增强：让外部知识动态进入上下文

上下文不只来源于对话历史，很大一部分来自外部知识库。这就是 RAG（检索增强生成）的用武之地。context-mode 和 RAG 的关系经常被搞混：RAG 解决的是"哪些外部文档该进上下文"，context-mode 解决的是"这些文档以什么形态和顺序排列，以及和对话历史如何融合"。

举个实际的例子。同一个法律咨询产品里，用户问"辞职需要提前几天通知单位"。如果检索系统只做关键词匹配，很可能把"违法解除劳动合同"的条款也一并检索出来。一个好的上下文模式设计，会结合用户的意图分类结果，只选取和"员工主动辞职"相关的条款，然后把这些条款放在一个独立的提示区块里，和对话历史分开，前面再加上一句"以下为相关法律规定，请基于这些条款结合用户情况回答"。这个区块划分和引用说明，就是 context-mode 在 RAG 之上的额外价值。

3. 实操：从零实现一个简单的上下文模式管理器

3.1 需求与模式选型

与其空谈理论，不如直接上一个可以抄作业的实现。我下面要写的这个上下文模式管理器，是我在几个项目里沉淀出来的简化版，核心目标是：在一个有限的 token 预算内，尽可能保留最有价值的上下文信息。

先定义需求：

• 支持多轮对话历史的维护，token 预算可配置。
• 支持三种模式：chat 模式（最近对话全量保留）、summary 模式（早期对话压缩成摘要）、field 模式（关键信息抽成结构化字段）。
• 模式之间可以自动切换，切换时上下文状态不丢失。

我用 Python 写，模型接口用 OpenAI 风格的 Chat API 做示例，但整体思路不绑定任何特定厂商。

3.2 核心类设计与关键参数

先定义上下文模式的基础数据结构：

from dataclasses import dataclass, field from typing import Dict, List, Optional @dataclass class Message: role: str # "user" 或 "assistant" content: str # 消息正文 timestamp: float = field(default_factory=__import__("time").time) @dataclass class ContextState: user_profile: Dict[str, str] = field(default_factory=dict) # 结构化字段层 summary: str = "" # 摘要层 recent_messages: List[Message] = field(default_factory=list) # 近期对话层 class ContextModeManager: def __init__(self, max_tokens: int = 8000, recent_rounds: int = 5): self.max_tokens = max_tokens self.recent_rounds = recent_rounds self.state = ContextState() self.mode = "chat" def add_message(self, role: str, content: str) -> None: self.state.recent_messages.append(Message(role=role, content=content)) self._maybe_compact() def _estimate_tokens(self, text: str) -> int: # 粗略估算：中文约 1.5 字符/token，英文约 3.5 字符/token # 更精确的做法是使用模型的 tokenizer，这里为示例做简化 return int(len(text) / 1.5 + 1) def build_context(self) -> List[Dict[str, str]]: context_parts = [] if self.state.user_profile: profile_text = "用户信息：" + "；".join( f"{k}={v}" for k, v in self.state.user_profile.items() ) context_parts.append({"role": "system", "content": profile_text}) if self.state.summary: context_parts.append({"role": "system", "content": f"历史摘要：{self.state.summary}"}) # 只取近 recent_rounds 轮的对话 recent = self.state.recent_messages[-self.recent_rounds * 2:] context_parts.extend( {"role": m.role, "content": m.content} for m in recent ) return context_parts

代码的核心思路是分层：system 层放稳定信息，对话层放动态信息。build_context()输出的结构直接传给大模型，顺序上有讲究——稳定的信息放前面，动态的放后面，模型会更容易把 system 层的指令当作长期约束。

3.3 token 预算自动压缩

_maybe_compact()是整个管理器的关键，它负责在上下文超出预算时自动降级模式。我的实现逻辑是：

def _maybe_compact(self) -> None: current_usage = self._estimate_tokens( json.dumps(m.content for m in self.state.recent_messages, ensure_ascii=False) ) if current_usage <= self.max_tokens * 0.7: return if self.mode == "chat": self._summary_recent_history() self.mode = "summary" elif self.mode == "summary": self._update_user_profile() self.mode = "field" # 如果压缩到最后仍然超限，就只保留最近一轮 if self._estimate_tokens( json.dumps(m.content for m in self.state.recent_messages, ensure_ascii=False) ) > self.max_tokens: self.state.recent_messages = self.state.recent_messages[-2:]

这段逻辑看起来简单，但有几个点我在实际项目中反复调整过：

• 压缩阈值不能定得太高。如果等 token 快用满了才压缩，一次大段的摘要生成会短暂占用双倍上下文，很容易打爆预算。我习惯在 70% 的占用率时就触发下一级压缩。
• 压缩是有损的，所以要控制压缩频率。频繁触发 chat→summary→field 的切换，会让上下文状态一直不稳定。解决方式是在两次压缩之间加一个最小间隔，比如至少相隔三轮对话。

3.4 摘要与字段提取的实现

摘要和字段提取需要调用模型。为了让这段代码不依赖具体的模型厂商，我封装了一个_call_llm()方法，实际使用的时候可以替换成任何 SDK：

def _summary_recent_history(self) -> None: content = "请把以下对话压缩成不超过100字的中文摘要，保留关键事实和用户意图：\n" + "\n".join(f"{m.role}: {m.content}" for m in self.state.recent_messages[:-2]) response = self._call_llm(content) self.state.summary = response.strip() def _update_user_profile(self) -> None: content = "从以下对话中抽取用户画像信息，例如姓名、城市、偏好、当前目标。只输出JSON格式，不要无关内容：\n" + "\n".join(f"{m.role}: {m.content}" for m in self.state.recent_messages) response = self._call_llm(content) # 这里局简解析 JSON，实际要用 json.loads + 异常处理 import json data = json.loads(response.strip().strip("`")) self.state.user_profile.update(data)

这里有一个非常容易踩的坑：摘要提示词里如果直接说"请总结对话"，模型很容易输出"用户询问了退货流程，并提到了运费问题"这种高度概括、却丢失了用户订单号、地区信息这类关键字段的内容。我的改进是强制摘要包含"关键事实和用户意图"，并且把输入限制为早期对话，给最近几轮对话留出空间。抽取字段时也要明确指名要哪些字段，而不是让模型自由发挥，否则模型会给你洒一堆锦上添花的修饰词。

3.5 实测效果：一个购物助手的上下文模式切换

我把这套管理器接进一个演示用购物助手，模拟了十五轮真实对话。用户的问询轨迹大概是：咨询商品参数、确认收货地址、询问发票抬头、然后又绕回商品颜色选型。

在默认 chat 模式下，十五轮对话的体量大约 3500 token。当对话达到第十二轮时，_maybe_compact()触发第一次压缩，早期十轮对话被压成一段 90 字摘要，里面保留了"用户在杭州西湖区，办公采购，希望开增值税发票"三个关键信息。第二十轮时再次触发压缩，此时摘要层已经足够稳定，系统把字段抽取后放进了 user_profile，近期对话只保留最近四轮。整体上下文从 3500 token 降到了 1900 token，而回答质量我在人工评估里反而感觉更稳了，因为模型不再被早期重复的讨价还价过程干扰。

这个结果符合我对 context-mode 的预期：它做的不是简单的信息减负，而是把信息结构化，让模型把注意力集中在真正重要的变量上。

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

4.1 上下文溢出的处理

现象：调用模型接口时报错，提示超过最大上下文长度。

排查思路：先确认是谁在涨。在build_context()里加一行日志，输出用户画像、摘要、近期对话三部分的 token 占比，基本一眼就能看出是摘要膨胀还是近期对话失控。我遇到过最典型的情况是模型生成的回答本身越来越长，长期累积后触发了上限——这时候单纯限制用户消息是没用的，还得给 assistant 的历史回复做截断。

处理方案：优先把recent_rounds从 5 调到 3，降级速度最快；如果还不够，就把摘要的压缩比例调高。另一个实用技巧是给 assistant 历史回复单独设一个 token 上限，比如单条不超过 400 token，超了就压成"（系统已自动截断过长回复）"。

4.2 上下文污染的识别与规避

现象：模型回答出现幻觉，把不同会话的规则混在一起，或者引用了当前会话里从未出现过的人名。

这种问题通常不是模型本身能力不行，而是上下文模式设计时把不该放的信息放进去了。我犯过一个典型的错误：在实现字段抽取时，把用户画像的更新逻辑写成了全量覆盖，导致上一个用户测试时留下的"偏好：低价优先"被带到了下一个会话。后来加了会话 ID 隔离，字段抽取只在当前会话范围内生效。

排查技巧：检查注入上下文的 system 消息里有没有包含时间敏感或会话敏感的信息。如果有，就在构建上下文时加一道过滤。

4.3 模式切换时的状态同步

现象：从 summary 模式切回 chat 模式后，模型突然"失忆"，忘了用户之前确认过的信息。

原因：模式切换时，summary和user_profile没有合并进新的上下文，或者摘要生成的时候丢弃了太多关键细节。

处理方案：我在_summary_recent_history()里强制摘要输出一个固定结构：【用户已确认信息】【待解决问题】【用户情绪/语气】。这样即使模式切换，模型也能快速从摘要中恢复关键状态。还有一个很实用的小技巧：每次压缩前的原始对话不要直接删除，暂存到磁盘或 Redis，保留 24 小时。万一后续用户追问一个只有原始对话里才有细节的问题，可以临时检索回补。

4.4 不同上下文模式的取舍速查

这个速查表是我给自己团队整理时写的，实际选型时可以把它当成讨论的起点，但最终的搭配一定来自你对自己业务数据的观察。建议上线前统计一下真实对话的平均轮数和平均单轮 token，再倒推预算分配。

5. 几个我反复用到的设计原则

5.1 稳定信息优先放 system 层

有些信息是不随对话变化的，比如用户身份、业务规则、助手能力边界。这些信息应该放进 system 层，并且放在 Prompt 的最前面。很多模型对 Prompt 头部内容的注意力权重会更高，把"你是 XX 助手，你只处理 XX 业务"放在最前面，比放在对话中间效果好得多。

如果有多块相对独立的稳定信息，比如"用户画像"和"业务规则"，我建议拆成两条 system 消息，而不是塞进同一段话。实测下来，分块后模型对不同信息块的切换更干净，不太会出现"规则条和用户画像串味"的情况。

5.2 动态信息要标明来源

对于检索来的文档、工具返回的结果，我的做法是在每条内容前加一行来源标注，比如【检索来源：退货政策_3.1节】。这个小小的改动能让模型在引用时更严谨，减少信口开河。用户看到回答带出处，可信度也会提升。

5.3 把"不知道"也写进上下文

很多上下文模式只管"该放什么"，没有管"不该有什么"。但对我来说，Model 的表现很大程度上取决于它是否知道自己不知道。所以在上下文中，我会明确加一条"当上述信息不足以回答用户问题时，请直接说明需要补充的信息，不要猜测"。这一条虽然简单，却能明显降低幻觉出现率。

5.4 定期回看压缩产物

上下文压缩是一个有损过程，但很多人从不回头检查摘要和字段提取的质量。我建议每隔一段时间，抽看几条被压缩后的摘要，对照原始对话确认有没有丢掉关键信息。这个动作看起来笨，但非常有效。我就在一次抽检中发现，摘要逻辑会把用户多次提到的"周六上门安装"压缩成"用户安排了安装"，结果模型在后续回答里丢失了对时间敏感度的理解。后来我在摘要提示词里强制加入"保留所有时间、地点、数字、姓名"的约束，问题立刻解决了。

做 context-mode 的时间越长，我越觉得它不是一个技术问题，而是一个信息治理问题。你不需要把每个 token 都用到极致，但你需要清楚地知道：哪些信息是必须保留的，哪些是可以舍弃的，哪些信息值得模型花注意力，哪些信息只会干扰判断。一个好的上下文模式设计，就像给模型配备了一个懂业务的分诊台护士，帮它快速聚焦到真正要紧的问题上。如果你正在被长对话、上下文超限、模型忘记设定这类问题困扰，我建议你先别急着换更大的窗口，试着把上下文分好层、立好边界，你可能会发现，很多问题在源头就解决了。