context-mode 上下文处理模式：从概念到落地的工程实践指南

1. 从“context-mode”这个词说起：它到底指什么

第一次看到“context-mode”这个标题，很多人会愣一下——它不像“XX管理系统”“XX爬虫框架”那样一眼能看出用途。我最初接触这个词是在做对话系统上下文管理的时候，当时团队里有人提出“给会话加一个 context-mode 开关”，我才意识到，这其实是一个描述“上下文处理策略”的抽象概念，而不是某个具体的库或工具。

简单来说，context-mode 指的是一个系统在处理“上下文”时采用的模式或策略。这里的“上下文”可以是一段对话的历史消息、一次请求携带的环境参数、一个函数执行时的作用域链，也可以是一个 AI 应用在生成回复前需要参考的全部背景信息。而“mode”则意味着：面对同样的上下文，系统可以选择不同的处理方式——全量保留、滑动窗口截断、摘要压缩、按优先级筛选、分层缓存等等。

它解决的问题非常实际：上下文不是越多越好，也不是越少越好，而是要在“信息完整性”和“资源消耗”之间找到平衡点。比如一个客服机器人，如果把用户过去三个月的所有对话都塞给模型，token 成本会爆炸，响应也会变慢；但如果只保留最后一句话，机器人又会丢失用户之前说过的订单号、产品型号等关键信息。context-mode 就是用来定义“到底保留哪些、丢弃哪些、怎么组织”的那套规则。

这篇文章适合三类人看：一是正在做对话系统、Agent 应用、RAG 管道的开发者，你们一定被上下文长度折磨过；二是做后端服务、需要管理请求级上下文（比如链路追踪、多租户隔离）的工程师；三是对 AI 应用架构感兴趣、想理解“为什么同样的大模型，不同产品体验差那么多”的技术爱好者。我会从概念拆解讲到落地实现，把我在实际项目里踩过的坑和总结出的模式都摊开来说。

需要先说明一点：context-mode 目前没有一个官方标准，不同团队对它的定义有差异。我下面讲的是基于常见工程实践归纳出来的一套理解框架，你可以把它当作设计参考，而不是照搬的规范。

2. 上下文为什么需要“模式”：三种典型困境

2.1 困境一：窗口有限，但信息无限增长

大模型的上下文窗口是有硬上限的。早期是 4K token，后来到 32K、128K，现在有些模型号称支持百万级。但窗口变大不等于可以无脑塞。我做过一个实测：把一个 8 万 token 的对话历史直接喂给模型，响应延迟从 1.2 秒涨到了 7 秒以上，成本翻了十几倍，而回答质量并没有线性提升——因为大量历史信息是冗余的，反而稀释了关键内容的注意力权重。

这就引出一个核心矛盾：业务上希望“记住一切”，工程上必须“有所取舍”。context-mode 的第一个作用，就是定义取舍规则。常见的策略包括滑动窗口（只保留最近 N 轮）、摘要压缩（把旧对话总结成一段话）、关键信息抽取（只保留实体、意图、槽位）、分层保留（近期全量 + 远期摘要）等。每种策略对应一种 mode，适用场景不同。

2.2 困境二：不同任务对上下文的敏感度差异巨大

同一个系统里，不同请求对上下文的需求可能完全相反。我拿一个实际项目举例：那是一个法律咨询助手，用户会先描述案情，然后连续追问细节。对于“帮我总结一下刚才说的案情”这类请求，需要完整的历史；但对于“劳动合同法第几条规定了试用期”这种事实性问题，历史上下文几乎没用，反而可能干扰模型。

如果系统只有一种上下文处理方式，就会出现两难：全量保留则事实性问题变慢变贵，激进截断则总结类请求丢信息。context-mode 的价值就在于让“上下文策略”变成可切换的配置，根据请求类型、用户等级、会话阶段动态选择。这就像开车时的驾驶模式——市区用经济模式，高速用运动模式，没有一种模式通吃所有路况。

2.3 困境三：上下文里混着“噪声”和“信号”

原始上下文往往很脏。用户可能发了一堆“嗯”“好的”“稍等”，中间夹杂着真正重要的需求描述；系统日志里混着无关的调试信息；多轮工具调用产生的中间结果大部分是一次性的。如果不加处理直接使用，模型会被噪声带偏。

我遇到过最典型的情况：用户在和机器人聊了二十轮之后，突然问“那这个多少钱”。如果上下文里最近几轮都在聊别的产品，模型很可能答错价格。这时候需要的 context-mode 是**“按相关性重排 + 时间衰减”**——不是简单取最近几条，而是根据当前 query 去检索历史中语义相关的片段，再结合时间新鲜度加权。这已经接近 RAG 的思路了，但作用域是会话内部而非外部知识库。

3. 拆解 context-mode 的核心维度：一张设计决策表

要设计一套 context-mode 机制，我习惯从四个维度去思考。下面这张表是我在多个项目里反复用到的决策框架，你可以对照自己的场景填一遍，基本就能确定需要哪些 mode。

3.1 保留策略：从“全量”到“检索式”的连续谱

全量保留是最简单的 mode，适合会话轮次少（比如 5 轮以内）、上下文总量可控的场景。它的优点是零信息损失，缺点是成本随轮次线性增长。我一般把它作为默认 mode，但设置一个 token 阈值，超过就自动降级。

滑动窗口是保留最近 N 轮或 N 个 token。这里有个容易踩的坑：按轮次截断和按 token 截断效果差别很大。用户一轮可能只发“好的”两个字，也可能发一大段案情描述。按轮次截断会导致 token 数剧烈波动，按 token 截断更稳定，但可能把一轮对话从中间切断。我的做法是按 token 截断，但保证不切断单条消息，从最旧的消息开始整条丢弃。

摘要压缩是把旧上下文用模型总结成一段话。这里的关键是摘要的粒度和更新频率。我试过每 5 轮做一次摘要，结果发现摘要本身也要消耗 token 和时间，而且多次摘要会累积误差。后来改成“当上下文超过阈值时，把最旧的一半消息摘要成一段”，效果更稳。摘要 mode 适合长会话，但要注意摘要可能丢失细节，所以关键实体（订单号、金额、日期）最好单独抽取保留。

检索式是进阶方案：把历史消息向量化存入临时索引，每次请求时用当前 query 检索 top-k 相关片段。这个 mode 最省 token，但引入了检索延迟和召回率问题。我在一个知识密集型客服项目里用过，配合“最近 3 轮全量 + 检索 top-5 历史片段”的混合策略，效果比纯滑动窗口好很多。

3.2 组织方式：顺序会影响模型注意力

同样一组上下文，排列顺序不同，模型的表现可能差很多。我做过对比实验：把关键信息放在上下文开头、中间、结尾三个位置，模型对结尾位置的召回率最高，开头次之，中间最差——这就是所谓的“lost in the middle”现象。

所以我的经验是：把最重要的信息放在上下文的末尾（靠近用户当前 query），次要信息放开头，最不重要的放中间。如果是多类型信息（系统指令、历史对话、检索结果、当前问题），用明确的分隔符或结构化标签分区，比如用 XML 标签包裹不同区块，模型对结构的敏感度比纯文本高。

3.3 压缩手段：摘要和抽取要配合使用

摘要擅长保留“语义走向”，比如“用户之前咨询过退货政策，表示对运费不满”。抽取擅长保留“精确事实”，比如订单号ORD-2024-8871、金额¥299。两者不是替代关系，而是互补。我的做法是：摘要用于对话脉络，抽取用于关键实体，两者拼在一起作为压缩后的上下文。

这里有个实操细节：抽取实体时不要只抽一次就完事，因为实体可能在后文被修正。比如用户先说“我要退 A 商品”，后来说“算了改成 B 商品”。如果只保留第一次抽取的 A，就会出错。所以抽取逻辑要支持覆盖更新，以最后一次出现的值为准。

3.4 切换触发：什么时候该换 mode

手动指定 mode 最可控，但用户体验差。自动切换需要触发条件，常见的有：

• 轮次阈值：超过 10 轮切换到摘要 mode
• token 阈值：上下文超过模型窗口的 60% 时触发压缩
• 意图识别：检测到“总结”“回顾”类意图时切回全量，检测到事实性问题时切到精简 mode
• 成本预算：按用户等级或请求优先级动态调整

我倾向于组合触发：token 阈值作为兜底（防止超限），意图识别作为优化（提升体验）。纯靠意图识别风险大，因为意图分类本身可能出错，一旦把需要全量的请求误判为精简，用户会明显感到“机器人失忆了”。

4. 落地实现：一个可运行的 context-mode 管理器

光讲概念不够，我把自己项目里用的一套简化实现拆出来讲。这套代码用 Python 写，核心是一个ContextManager类，支持多种 mode 切换。你可以直接拿去改。

4.1 数据结构设计：消息、会话、模式配置

先定义基础结构。每条消息包含角色、内容、时间戳、token 数、以及一个可选的pinned标记（用于标记不可丢弃的关键消息）。

from dataclasses import dataclass, field from typing import List, Optional import time @dataclass class Message: role: str # user / assistant / system / tool content: str timestamp: float = field(default_factory=time.time) tokens: int = 0 pinned: bool = False # 关键消息，压缩时优先保留 @dataclass class ContextConfig: mode: str = "sliding" # full / sliding / summary / retrieval / hybrid max_tokens: int = 4000 # 上下文 token 上限 window_size: int = 10 # 滑动窗口保留轮次 summary_threshold: int = 3000 # 触发摘要的 token 阈值 retrieval_top_k: int = 5 # 检索式保留片段数

这里pinned字段很关键。我在实际项目里发现，有些消息绝对不能丢，比如用户明确说“记住我的订单号是 XXX”，或者系统注入的租户配置。给这些消息打上 pinned 标记，任何压缩策略都要优先保留它们。

4.2 滑动窗口 mode 的实现与边界处理

滑动窗口看似简单，但边界处理有讲究。我的实现逻辑是：从最新消息往前累加 token，直到接近上限，然后整条保留，不切断消息。

def sliding_window(messages: List[Message], max_tokens: int) -> List[Message]: selected = [] total = 0 # 先保留所有 pinned 消息 for msg in messages: if msg.pinned: selected.append(msg) total += msg.tokens # 从最新往前加非 pinned 消息 for msg in reversed(messages): if msg.pinned: continue if total + msg.tokens > max_tokens: break selected.append(msg) total += msg.tokens # 恢复时间正序 selected.sort(key=lambda m: m.timestamp) return selected

注意这里有个细节：pinned 消息可能很多，如果 pinned 本身就超限了怎么办？我的做法是pinned 优先，超限时对 pinned 内部再做一次摘要，而不是直接丢弃。因为 pinned 之所以被标记，就是因为它重要，直接丢会出大问题。

4.3 摘要 mode：什么时候摘要、摘要什么、怎么拼接

摘要 mode 的触发时机我前面提过，是 token 超过阈值。但摘要本身也有讲究。我的实现是：把最旧的一半非 pinned 消息交给模型摘要，摘要结果作为一条 system 消息插入上下文开头。

def summarize_old_messages(messages: List[Message], llm_client) -> str: # 取最旧的一半非 pinned 消息 non_pinned = [m for m in messages if not m.pinned] half = len(non_pinned) // 2 to_summarize = non_pinned[:half] if not to_summarize: return "" text = "\n".join(f"{m.role}: {m.content}" for m in to_summarize) prompt = f"请用简洁的中文总结以下对话的关键信息，保留实体、数字和结论：\n{text}" return llm_client.generate(prompt)

这里有个坑：摘要 prompt 必须明确要求保留实体和数字，否则模型会写成“用户咨询了退货相关问题”这种没用的概括。我试过不加这句，结果摘要里订单号全丢了，后面用户问“我那个订单怎么样了”，机器人完全接不上。

拼接时，摘要消息放在最前面，然后是 pinned 消息，最后是最近的全量消息。这样模型先看到背景摘要，再看到关键事实，最后看到当前对话，层次清晰。

4.4 检索式 mode：会话内向量检索的轻量方案

检索式 mode 适合超长会话。完整方案需要向量数据库，但会话内检索其实可以用轻量方案：用 TF-IDF 或 BM25 做关键词检索，不一定要上 embedding。因为会话内消息通常有大量词汇重叠（用户会重复提到同一产品名、订单号），关键词检索的召回率已经够用，而且零额外成本。

from rank_bm25 import BM25Okapi def retrieval_mode(messages: List[Message], query: str, top_k: int) -> List[Message]: corpus = [m.content for m in messages] tokenized = [doc.split() for doc in corpus] bm25 = BM25Okapi(tokenized) scores = bm25.get_scores(query.split()) # 取 top_k，同时保证最近 3 轮一定在 top_indices = sorted(range(len(scores)), key=lambda i: scores[i], reverse=True)[:top_k] recent = list(range(max(0, len(messages)-3), len(messages))) final_indices = sorted(set(top_indices) | set(recent)) return [messages[i] for i in final_indices]

这个方案我在一个日均 5 万次请求的项目里跑过，检索延迟在 10ms 以内，比 embedding 方案快一个数量级。当然，如果会话里语义相似但用词不同的情况多，还是得上 embedding。选型要看具体数据分布。

4.5 混合 mode：我的默认推荐配置

纯任何一种 mode 都有短板，我最终在生产环境用的是混合 mode：最近 3 轮全量 + pinned 消息 + 检索 top-5 历史片段 + 超长时追加摘要。这个组合覆盖了“近期精确”“关键事实”“相关历史”“远期脉络”四个层次。

配置上，我把max_tokens设为模型窗口的 50%，留一半给模型输出和系统指令。这个比例是我多次压测后定的：超过 60% 时延迟明显上升，低于 40% 时信息不够用。当然不同模型不一样，你需要自己测。

5. 踩坑记录：那些让我加班到凌晨的上下文问题

5.1 坑一：摘要的“滚雪球”误差

早期我做摘要 mode 时，是每次超限就把全部历史摘要一次，然后新消息继续追加，下次超限再把“旧摘要+新消息”一起摘要。结果跑了十几轮之后，摘要变得面目全非——最初的订单号、金额全没了，只剩“用户咨询了售后问题”这种废话。

根因：摘要是不可逆的有损压缩，多次摘要会累积误差，就像反复复印同一张纸，越印越模糊。

修复方案：改成“分层摘要”——原始消息保留在存储层不删，摘要只用于构建上下文。每次摘要时，从原始消息重新生成，而不是在旧摘要上再摘要。这样虽然多存了数据，但摘要质量稳定。存储成本远低于模型调用成本，这笔账要算清楚。

5.2 坑二：pinned 消息的“僵尸化”

有次用户反馈机器人“记不住事”。排查发现，用户早期说过的订单号被标记为 pinned，一直保留在上下文里。但后来用户改了订单，新订单号没有被标记 pinned，结果旧订单号一直占着位置，新订单号反而被滑动窗口挤掉了。

根因：pinned 标记是静态的，没有随信息更新而失效。

修复方案：引入“实体版本”概念。同一类实体（如订单号）只保留最新版本，旧版本自动取消 pinned。实现上可以用一个简单的实体槽位表，每次抽取到新值就覆盖旧值，并更新对应消息的 pinned 状态。

5.3 坑三：多租户场景下的上下文串扰

在一个 SaaS 项目里，多个租户共用同一套服务。有次出现严重 bug：A 租户的用户看到了 B 租户的上下文片段。排查发现是缓存 key 设计有问题，只用了 session_id 做 key，而 session_id 在不同租户间可能重复。

根因：上下文隔离维度不足。

修复方案：缓存 key 必须包含租户 ID + 用户 ID + 会话 ID 三级。而且上下文管理器初始化时就要绑定租户，不能等到写入时才检查。这个坑让我意识到，context-mode 不只是“保留多少”的问题，更是“隔离谁和谁”的问题。多租户场景下，隔离优先级高于一切压缩策略。

5.4 坑四：工具调用结果的“一次性污染”

Agent 应用里，工具调用会产生大量中间结果，比如搜索返回的十条网页摘要、数据库查询的原始行。这些结果对当前轮有用，但下一轮基本是噪声。我早期没处理，导致上下文迅速膨胀，而且模型经常被上一轮的搜索结果带偏。

修复方案：给工具结果设置TTL（生存轮数），默认只保留 1 轮，除非被显式引用。实现上给消息加一个expire_after字段，构建上下文时过滤掉已过期的工具消息。这个改动让平均上下文 token 数下降了 40%，响应质量反而提升。

6. 效果验证：怎么知道你的 context-mode 选对了

6.1 三个必须监控的指标

选 mode 不能凭感觉，要有数据。我一般盯三个指标：

• 上下文 token 均值与 P95：均值看成本，P95 看极端情况。如果 P95 远超窗口，说明压缩策略没兜住。
• 关键信息召回率：构造一批测试用例，每个用例有一个“必须被模型看到”的关键信息（订单号、日期、金额），检查最终上下文里是否包含。这个指标直接反映压缩是否过度。
• 端到端响应延迟：上下文处理本身有开销（摘要、检索），要单独计时，不能混在模型推理里。

6.2 一个简单的 A/B 测试框架

我通常用离线回放做 A/B：把历史真实会话拿出来，用不同 mode 重新构建上下文，让模型生成回复，然后人工或自动评估质量。评估维度包括事实准确性、上下文连贯性、指令遵循度。跑几百条就能看出明显差异。

这里有个经验：不要只看平均分，要看方差。有些 mode 平均分不差，但方差大，意味着不稳定，线上会出各种诡异问题。我宁愿选平均分略低但方差小的 mode。

6.3 线上灰度与回滚策略

新 mode 上线一定要灰度。我的做法是按用户 ID 哈希分流，先放 5% 流量，观察一周。回滚开关要能秒级生效，而且回滚后要能恢复到旧 mode 的上下文状态——这就要求上下文存储层和 mode 逻辑解耦，mode 只是“视图”，底层消息始终完整保存。

7. 不同场景下的 mode 选型建议

7.1 客服机器人：混合 mode + 强 pinned

客服场景的特点是会话中等长度（10-30 轮），关键实体多（订单、产品、金额），且用户经常回溯。我推荐混合 mode，pinned 策略要激进——所有实体抽取结果都标记 pinned，并做版本管理。摘要用于对话脉络，检索用于历史回溯。

7.2 代码助手：滑动窗口 + 文件上下文分区

代码助手的上下文分两部分：对话历史和当前文件内容。文件内容通常很大但结构清晰，适合用分区方式组织——把函数签名、相关代码块、报错信息分区放置。对话历史用滑动窗口即可，因为代码问题通常聚焦在当前几轮。这里有个技巧：把光标位置附近的代码放在上下文末尾，模型对末尾注意力最强。

7.3 长文档问答：检索式为主，全量为辅

长文档问答的上下文主要是文档片段，不是对话历史。这时候 context-mode 的重点是片段检索和重排。我的做法是：先用向量检索召回 top-20，再用 cross-encoder 重排取 top-5，最后按文档顺序排列（保持逻辑连贯）。对话历史只保留最近 2 轮，因为文档问答通常是独立问题。

7.4 多 Agent 协作：结构化上下文 + 角色隔离

多 Agent 场景下，每个 Agent 只需要看到与自己角色相关的上下文。比如规划 Agent 需要看全局目标，执行 Agent 只需要看当前子任务。这时候 context-mode 的核心是按角色过滤 + 结构化传递。我一般用 JSON 结构定义上下文，每个字段标注可见角色，构建时按角色裁剪。

8. 我个人的几条实操心得

第一，上下文处理逻辑要和业务逻辑解耦。我见过太多项目把压缩逻辑写死在业务代码里，改一个策略要动十几个文件。正确的做法是抽象出 ContextManager，业务层只负责往里面塞消息，取的时候指定 mode。

第二，永远保留原始消息。压缩后的上下文是给模型看的，但存储层要留全量。排查问题时，原始消息是唯一真相。我吃过亏——有次线上出问题，结果发现压缩后的上下文把关键信息丢了，但原始消息也没存，根本没法复现。

第三，token 计数不要用估算。不同模型的 tokenizer 不一样，估算误差可能到 20%。我早期用字符数除以 4 估算，结果中文场景严重低估，导致频繁超限。后来统一用对应模型的 tokenizer 精确计数，虽然慢一点，但稳定。

第四，给上下文加“新鲜度权重”。同样相关的两条历史消息，一条是 5 分钟前的，一条是 3 天前的，显然前者更重要。我在检索式 mode 里加了时间衰减因子，score = 相关性 × exp(-Δt / τ)，τ 取 1 小时左右。这个改动让“最近提过但语义匹配度略低”的信息更容易被召回。

第五，定期 review 上下文内容。我每个月会抽样看一批线上真实上下文，经常发现意外情况：比如某个工具返回了超长 JSON、某个用户发了大量重复内容、某个系统消息被反复注入。这些问题不看原始数据是发现不了的。Review 之后针对性加过滤规则，比盲目调参有效得多。

context-mode 这个东西，说到底是在资源约束下做信息取舍的工程艺术。没有银弹，只有对场景的深刻理解和对数据的持续观察。我上面给的配置和代码都是起点，真正适合你业务的 mode，得自己跑数据、看指标、迭代出来。