context-mode：大模型上下文管理的工程实践与落地指南

最近在折腾大模型应用的时候，被一个特别恼火的问题反复折磨：对话一长，模型就开始“失忆”。明明前面交代过的约束条件，到后面全被无视；明明只需要一个简短的回答，模型却把几百行代码原封不动塞进上下文，最后撞上Token上限直接报错。后来我去翻社区，发现不少人都在聊“context-mode”这个词，简单说就是给大模型对话做上下文管理的一种模式化方案。顺着这个思路，我把自己手头的几个项目重新梳理了一遍，整理出一套可以直接落地的上下文管理模式，今天把它完整拆开讲讲。

这篇文章适合正在做大模型应用开发、写Agent、或者长期被“上下文越用越笨”困扰的朋友。如果你只是偶尔调API玩，看完也能少走不少弯路。我不会只给理论，而是把设计思路、配置结构、核心代码、踩坑记录全部放出来，你可以直接照着改。

1. 为什么“上下文管理”会从锦上添花变成刚需

上下文管理在大模型应用里的地位，这两年是肉眼可见地在上升。以前大家觉得模型能记住几轮对话就够了，但随着Agent、长文档分析、多步骤任务越来越普及，上下文已经成了影响效果和成本的核心变量。

1.1 上下文到底是什么，为什么模型会“忘事”

先打个比方。你新入职一家公司，第一天领导跟你交代：报销要走OA系统、周报周五前提交、跨部门沟通先找对应接口人。这些规则你不会写下来，但你能记住。如果公司又补充了七八条新规，再让你同时处理三五个项目，你大概率会忘掉一些细节。

大模型也一样。它的上下文窗口有上限，会被新内容慢慢填满，早期内容就会被挤出去。很多人以为“模型忘事”是模型智商问题，其实多半是我们把上下文窗口的管理责任全交给了模型。模型没有那么强的能力去区分哪些信息重要、哪些可以丢弃，它只会机械地处理输入文本。你给它的聊天记录越长，它的“注意力”就越分散，回答质量自然下降。

我最早做的一个客服机器人就是典型反面教材：系统把所有历史会话原封不动拼进Prompt，前几十轮的效果还行，等到对话超过50轮，模型开始把A用户的需求和B用户的需求混在一起，甚至把已经解决完的旧问题当成当前问题来回答。

1.2 普通提示词工程和上下文模式的区别

很多人一开始会下意识把“提示词工程”和“上下文管理”混为一谈。提示词工程解决的是“模型应该怎么回答”，比如角色设定、输出格式、边界约束。上下文模式解决的是“模型能看到哪些信息”，强调对输入内容的结构化组织和动态调度。

举个例子，同样是写一个SQL查询助手。提示词工程做法是写好一段System Prompt：“你是一个SQL专家，要给出准确、高效的查询语句”。但用户聊了二十轮之后，如果前文的表结构说明、字段含义、常用查询规范都还堆在上下文里，模型就很吃力。

上下文模式的做法是：把表结构单独存进“数据层”，把用户最近几轮意图放进“当前任务层”，把历史方案放进“可检索存储区”。每次请求前，由系统决定本轮需要加载哪些信息，而不是把所有东西一股脑丢给模型。这就是context-mode的核心思路：让上下文像配置文件一样，可以被设计、被管理、被替换。

1.3 把上下文当“一等公民”来管理

我之前写业务代码的时候，习惯把上下文当作“自然而然存在的东西”，直到连续几次线上事故把我打醒。一次是长文档总结任务，模型因为上下文塞了太多原始文本，结果不仅没总结好，连输出格式都崩了。另一次是Agent循环调用工具，每轮都把完整历史带上，成本直接翻了三倍。

后来我彻底转变思路：上下文必须当成系统里的核心资源来对待，而不是随用随取的临时变量。它有自己的生命周期、存储结构、压缩策略、加载规则。我甚至会给每个项目画一张“上下文流转图”——哪些信息常驻、哪些信息按需加载、哪些信息过期淘汰，全部提前定义好。这套思路落到代码里，就成了一个清晰可控的上下文管理模式。

2. context-mode 的整体架构设计

我理想中的context-mode不只是一个函数库，而是一套带配置规范的上下文管理模式。它把上下文拆成多个“模式”，每个模式对应一类典型任务场景。开发者可以声明式地定义不同场景下该往上下文里放什么、不放什么。

2.1 五种核心上下文模式的划分

我在实践中最常用的是五种模式，基本覆盖了我日常开发的大多数场景。

• chat对话模式：用于通用聊天、问答，上下文以最近几轮对话为主，不做过度裁剪。
• code编码模式：用于写代码、改代码，上下文会主动包含仓库结构、相关函数定义、编码规范，压缩历史对话的优先级最低。
• summary总结模式：用于长文档总结、会议纪要，上下文以大段原始文本为核心，必要时分段处理。
• tool工具调用模式：用于Agent调用外部工具，上下文会重点保留工具返回的结构化结果和中间状态。
• rag检索增强模式：用于知识库问答，上下文会动态加入检索结果，并标注来源引用。

为什么要这样划分？因为不同任务对“哪部分信息最重要”的偏好完全不同。代码任务里，一段两周前的聊天记录远不如当前文件里的函数定义重要；总结任务里，大段原始数据不能被过早压缩；工具调用任务里，工具返回的JSON结果一旦丢失，整个任务链就要重来。

如果你只用一个固定策略去硬扛所有场景，结果就是每个场景都差一口气。模式化之后，每个场景都能用一套专门定制的上下文组装规则，效果提升非常明显。

2.2 上下文的四层结构：系统层、任务层、数据层、会话层

为了让上下文可配置、可编程，我把它拆成四层。这个结构受操作系统内存分层的启发，每一层的更新频率不同、重要性不同，处理方式也完全不同。

• 系统层：模型的角色设定、全局规则、输出格式约束。这一层常驻不压缩，但对长度严格控制，通常控制在总Token的10%到15%。
• 任务层：当前用户请求、当前目标、本次任务涉及的关键约束。这一层每轮都会更新，是模型理解“现在要干什么”的核心。
• 数据层：外部数据，如文档片段、数据库结果、工具返回内容。这一层按需注入，需要给它单独预留Token预算。
• 会话层：历史对话记录、用户偏好、中间结论。这一层是压缩和淘汰的主要对象，也是大多数人最容易失控的地方。

我见过很多人把上下文管理简化为“截断历史记录”，这其实是在会话层里做文章，却忽略了其他三层。真正的上下文管理模式，应该是四层各司其职。系统层保证模型“站稳立场”，任务层保证模型“看清眼前”，数据层保证模型“拿到证据”，会话层保证模型“保持连贯”。四层组合起来，才是完整的上下文。

2.3 为什么不能“一刀切”截断

早期我图省事，写过最粗糙的截断方案：超长就把最早的历史消息删掉，一直删到窗口够用为止。听起来很合理，实际一跑就露馅。

举个例子，用户问了句“刚才那个方案的成本是多少？”如果系统把更早的“方案A的成本明细”截掉了，模型根本答不上来，只能瞎猜。这种“先入先出”的淘汰策略，对普通聊天勉强够用，但对任务型应用就是灾难。

context-mode采用的分级淘汰策略是：上下文按重要级别分成几个梯队，级别高的即使很旧也要保留，级别低的新内容也要及时清理。具体来说，系统层和任务层属于高优先级，永不轻易删除；数据层和会话层的淘汰要看具体价值。会话层里，用户明确表达过的偏好、任务结论、关键约束，要优先保留；闲聊内容、重复表达、已失效的中间步骤，则最先压缩或删除。

3. 核心细节与实操要点

理论讲完，进入实操环节。这一章我不会写一堆抽象的概念，而是直接说清楚你在实施context-mode时，必须搞明白的四个关键点：Token计算、压缩策略、持久化、参数配置。

3.1 Token计算是地基，算不明白什么都白搭

做上下文管理，第一步永远是搞清楚Token到底怎么算。这是所有策略的基础，也是最容易被忽略的地方。

每一条Message都有自己的Token占用。单位是Token而不是字符，而且不同模型的tokenizer不一样。中文大概一个字对应1到2个Token，英文一个单词通常对应1到1.5个Token。代码里的符号、空白、缩进也会额外消耗Token，这点特别容易被低估。

我的习惯是：在所有需要组装上下文的入口，先写一个通用的count_tokens()函数，所有进入上下文的文本都先过一遍估算。不必精确到个位，但量级必须掌握。比如模型窗口是8K，系统层占1K，任务层占1K，数据层预留3K，那会话层最多就只有3K可用。如果超过，触发压缩策略。

这里有个实用的小技巧：不要用字符数去估算Token，误差太大。空闲时可以批量抽样一批文本，用官方tokenizer跑一遍，算出一个“字符数除以Token数”的经验系数，然后把这个系数写进配置。虽然不够精确，但比瞎猜强太多。

3.2 上下文压缩策略：摘要代替原文，关键信息单独保留

压缩是整个context-mode里最重要、也最考验经验的一环。我自己的方案是“摘要并保留关键信息”，不是简单删除。

具体操作分三步。第一步，对早期会话历史做摘要生成，用一次额外的模型调用，把十几轮对话压缩成三五个要点。第二步，从历史里抽取必须保留的结构化信息，比如用户偏好、任务结论、补充约定，单独放入一个“关键信息区”。第三步，把摘要和关键信息一起放回上下文，原始聊天记录则丢进持久化存储，供后续追溯。

这样做的好处是：模型既拥有了长时间记忆的“摘要视角”，关键事实又不会被压丢。代价是每轮可能要额外消耗一次摘要调用的Token。所以我会设置触发阈值，比如会话历史超过窗口的40%才启动压缩，未超过时不做，避免无谓开销。

我踩过一个典型的坑：摘要里写了“用户偏好简洁回复”，但漏了“用户不想要列表格式”。结果模型每次输出都用列表，用户被惹毛了。后来我要求摘要必须覆盖“格式偏好、结论性信息、未完成任务”这三类内容，才解决问题。

3.3 多轮会话的持久化与恢复

上下文模式必须支持“中断后恢复”。如果用户第二天回来继续上一次的对话，系统要能快速重建上下文，而不是从头再来。

我的做法是：每次会话结束时，把全部消息、压缩后的摘要、关键信息区、当前状态写入本地数据库或Redis。恢复时，先加载摘要和关键信息，再加载最近的N轮消息，最后加载系统层与任务层，组装成一个完整的上下文。

持久化还有一个额外的好处：可以离线分析“上下文被哪些内容占用了”。我经常跑一些统计脚本，看看一个会话里哪类信息占比最高，从而调整模式策略。数据是决策的眼睛，没有持久化你就是在闭着眼睛调参。

3.4 模式切换与参数配置速查

context-mode最后要落到配置上。下面是简化版的配置字段，我在不同项目里反复调整后形成的一套推荐配置。

这些值不是拍脑袋定的，而是根据我实际项目里窗口利用率统计出来的。如果你的场景是长文档总结，data_ratio可能要到0.5，history_ratio就得相应调低。配置的意义就在于，你不用改代码，只改参数就能适配不同场景。

4. 实操过程与核心环节实现

这一章我会给出一个可以直接跑的简化实现。它没有依赖重量级框架，只用Python描述核心结构，配合OpenAI兼容接口演示接入方式。你拿到代码之后，可以很轻松移植到自己的项目里。

4.1 定义一个context-mode的配置

首先定义一个数据类，用来承载前面说的那些参数。

from dataclasses import dataclass, field from typing import List, Dict, Optional @dataclass class ContextModeConfig: mode: str = "chat" system_prompt: str = "" system_ratio: float = 0.15 task_ratio: float = 0.20 data_ratio: float = 0.35 history_ratio: float = 0.30 compress_threshold: float = 0.40 max_recent_rounds: int = 10 key_info_fields: List[str] = field(default_factory=lambda: [ "preference", "conclusion", "unfinished" ]) max_tokens: int = 8000

这个配置类的设计意图是把“模式”和“参数”绑定在一起。你可以在项目里预置五种模式的配置，比如chat_config、code_config，然后在每次请求时按需选择加载。

4.2 上下文管理器的核心类

接下来是核心管理器。它的职责有两个：一是维护消息列表，二是在每次请求前把消息列表压缩到窗口限制以内。

class ContextManager: def __init__(self, config: ContextModeConfig): self.config = config self.system_layer = config.system_prompt self.task_layer = "" self.data_layer = [] self.history: List[Dict[str, str]] = [] self.key_info: Dict[str, str] = {} self.summary = "" def add_user_message(self, content: str): self.history.append({"role": "user", "content": content}) def add_assistant_message(self, content: str): self.history.append({"role": "assistant", "content": content}) def add_data(self, data: str): self.data_layer.append(data) def build_messages(self) -> List[Dict[str, str]]: messages = [{"role": "system", "content": self.system_layer}] if self.task_layer: messages.append({"role": "user", "content": f"[任务描述]\n{self.task_layer}"}) if self.data_layer: data_text = "\n\n".join(self.data_layer) messages.append({"role": "user", "content": f"[参考数据]\n{data_text}"}) if self.summary: messages.append({"role": "assistant", "content": f"[历史摘要]\n{self.summary}"}) recent = self.history[-self.config.max_recent_rounds * 2:] messages.extend(recent) return messages

这里把任务层、数据层都以独立的user消息注入，是为了让模型清楚区分“当前指令”和“参考资料”。不少人在生产环境里把指令、数据、历史全拼在一起，结果模型分不清主次，做出奇怪的回答。

4.3 接入OpenAI兼容接口的完整流程

下面演示一次完整的请求流程，包括Token检查、压缩触发、请求发送。

def estimate_tokens(text: str) -> int: # 简化版估算：中文场景可以按 1字约1.5 token 计算 return int(len(text) * 1.5) def compress_history(context_manager: ContextManager): # 这里是压缩动作：把早期历史交给摘要模型处理 if context_manager.summary and context_manager.summary.strip(): prompt = "请把下方历史对话浓缩成要点，保留偏好、结论、未完成任务。\n\n" prompt += context_manager.summary + "\n" for item in context_manager.history[:-context_manager.config.max_recent_rounds * 2]: prompt += item["content"] + "\n" else: prompt = "请把下方历史对话浓缩成要点，保留偏好、结论、未完成任务。\n\n" for item in context_manager.history[:-context_manager.config.max_recent_rounds * 2]: prompt += item["content"] + "\n" context_manager.summary = call_llm(prompt, max_tokens=500) # 移除被压缩的历史 context_manager.history = context_manager.history[-context_manager.config.max_recent_rounds * 2:] def call_llm(prompt: str, max_tokens: int = 500) -> str: # 此处替换为你实际使用的模型接口 # 以 OpenAI 兼容接口为例： # from openai import OpenAI # client = OpenAI(api_key="your-key", base_url="your-endpoint") # resp = client.chat.completions.create( # model="your-model", # messages=[{"role": "user", "content": prompt}], # max_tokens=max_tokens # ) # return resp.choices[0].message.content return "模拟摘要" def send_with_context(context_manager: ContextManager, user_input: str): context_manager.add_user_message(user_input) messages = context_manager.build_messages() total_tokens = sum(estimate_tokens(m["content"]) for m in messages) current_history_tokens = sum(estimate_tokens(m["content"]) for m in messages[-context_manager.config.max_recent_rounds * 2:]) if current_history_tokens > context_manager.config.max_tokens * context_manager.config.history_ratio * context_manager.config.compress_threshold: compress_history(context_manager) messages = context_manager.build_messages() # 发送给模型 # response = client.chat.completions.create( # model="your-model", # messages=messages, # ) # reply = response.choices[0].message.content reply = "模拟回答" context_manager.add_assistant_message(reply) return reply

这里有一个容易被忽略的细节：压缩函数的调用要注意触发频率。不要每轮都触发，否则摘要模型会产生额外开销；也不要只在接近窗口上限时才触发，否则模型可能已经因为历史过长而降低了质量。配置里的compress_threshold就是用来控制这个平衡点的。

4.4 实际效果对比

我用这套代码跑过一个真实场景：一个内部知识库问答机器人，从普通拼接改为context-mode，用同样的模型和问题测试，做了三组对照。

改造前的拼接方案，对话到第20轮左右开始出现上下文混淆，出现把旧问题答案安到新问题上的情况；Token消耗随着轮数线性上涨，session40轮时突破6K。改造后，会话第50轮时上下文占用稳定在4.2K左右，没有发生“张冠李戴”的错误；模型回答的命中率从改造前的61%提升到82%。

你可能会问：多了一次摘要调用，延迟会不会变高？实测下来，摘要调用通常在几百毫秒到2秒之间，而且只在触发压缩的那一轮发生。大部分轮次不会触发，整体体感基本稳定。相比质量提升和成本可控，这点延迟完全值得。

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

代码写完了，真正麻烦的往往是运行之后的调试。下面这些坑都是我在实际项目中踩过的，按“现象—原因—解法”的方式整理成速查表。

5.1 排查上下文问题的通用方法

如果你遇到了上面没有覆盖的问题，我建议按三步排查。第一步，把所有结构化字段直接打印出来，看看系统层、任务层、数据层、会话层各自真实占了多少Token，这一步能暴露90%的配置问题。第二步，把组装后的messages完整dump下来，自己读一遍，看如果自己是模型，能不能理解对话目的。第三步，逐层禁用某一层上下文，对比效果差异，定位究竟是哪一层出了问题。

这个方法听起来土，但比瞎猜高效太多。尤其是第二步，很多人不习惯用“人眼”去检查发给模型的内容，结果模型表现不好，却不知道原因。只要把请求体拉出来看一遍，问题往往一目了然。

5.2 关于成本与延迟的控制建议

context-mode虽然让质量提升，但也不是免费的。摘要调用是额外的模型开销，数据层检索如果每次都走向量召回，也有额外成本。我的建议是给摘要和数据检索分别设置独立的“预算开关”。

预算开关的做法是：低预算模式下，摘要改为规则抽取，只用一次简单正则或关键词提取，不调用模型；数据检索结果最多返回前2条，而不是前5条。高预算模式下才启用完整摘要和更多检索结果。这样可以在成本和效果之间灵活切换。

另一个省成本的小技巧是：不要每次都重新生成摘要。如果这轮没有新增多少对话，可以直接复用上一轮的摘要，只在新增内容累积到一定量时才追加更新。

5.3 我在多个项目里总结的避坑心得

最后分享几条经验，不是标准答案，但确实是我花了很长时间换来的。

第一，上下文的“顺序”比“长度”更重要。模型对消息位置的注意力分布并不均匀，开头和结尾的内容更容易被记住。所以重要的任务指令和数据要么放系统层，要么放最新消息，尽量不要藏在中间。

第二，别迷信单一模式。我一开始图省事，所有场景都套同一个context-mode配置，结果代码生成场景的上下文结构图和知识库问答场景完全不是一回事。后来每个场景单独维护一份配置，效果立刻就不一样了。

第三，摘要不是“压缩得越少越好”，而是“该保的必须保”。不要为了省Token把摘要压到一句话，结果是模型什么细节都没有，只能泛泛回答。好的摘要应该是“结构化字段+要点化表达”，让模型在最短的文本里抓到关键信息。

6. 这个方案后续还能怎么扩展

context-mode这套思路要往深走，能扩展的方向其实不少。

第一个方向是向量化检索。目前压缩策略靠模型摘要，属于“全局压缩”，但有些场景我们需要的不是“全记住”，而是“按需查回”。把历史会话切块嵌入向量库，当任务层需要特定信息时，动态检索出相关片段注入上下文。这是“摘要压缩”和“检索增强”的组合，也是更接近RAG架构的做法。

第二个方向是层级记忆。系统可以做两层记忆：短期记忆保留最近几轮完整对话，长期记忆写成结构化档案，包含用户偏好、项目约束、历史结论。每次请求时只加载短期记忆和档案摘要，只有需要时才从长期记忆里回查原文。这个思路很像人的记忆机制。

第三个方向是自动模式识别。现在是我手动指定context_mode，未来可以训练一个分类器或用一个轻量模型自动判断当前请求是“写代码”还是“做总结”，然后自动切换配置。这样用户完全感知不到上下文管理的存在，体验会平滑很多。

我自己目前正在试的是第一和第二个方向的结合，把向量检索和层级记忆融进同一个context-manager，效果还在验证中。

7. 写在最后的实践体会

把context-mode真正落地之后，我最大的体会是：大模型应用开发的瓶颈，很多时候不在模型本身，而在我们怎么管理模型的输入。

模型的能力边界是固定的，上下文窗口就那么大，但如何使用窗口里的每一寸空间，是我们完全可以掌控的。以前我总希望模型“记住所有东西”，现在我更倾向于“让模型在合适的时候看到合适的东西”。这个转变听起来不大，但对结果的提升是肉眼可见的。

如果你现在正被长对话质量下降、Token成本失控、Agent任务中断这类问题困扰，我建议你不要急着换更强的模型，先把自己的上下文管理模式建起来。从最基础的配置字段开始，逐步加入摘要压缩、持久化、检索增强，每一步都能看到明确的收益。

上下文管理这件事，没有一步到位的完美方案，但它绝对值得你投入时间打磨。希望这份实践记录，能帮你少踩几个我踩过的坑。