1. 为什么我放弃了“无脑塞上下文”的做法
先交代一下背景。我最近大半年都在做 LLM 应用开发，每天打交道最多的不是模型本身，而是上下文。早期写对话机器人，我的实现方式很直接：把用户发的每一条消息、我回的每一条消息，全部追加到一个 messages 数组里，然后一股脑丢给模型。Demo 阶段确实爽，代码简单，效果也能看。但一旦进入真实业务场景，这套“无脑塞上下文”的做法立刻失控。
失控的典型表现有三种。第一种是对话稍微长一点，token 直接爆炸。用户问个十几轮，再夹带几条长文档，随便一算就是一万多 token，调用成本肉眼可见地涨。第二种是模型开始“记性错乱”，前面的信息记住一些、忘掉一些，优先级全乱了，用户问“我刚才说的那件事怎么办”，模型开始一本正经地编。第三种是调试极其痛苦，你根本没法确认模型到底基于哪一段历史给出了回答，出了问题都不知道该砍哪一行。
后来我在一次内部技术分享里听到同事提了一句“context-mode”，意思是把上下文管理做成一种显式的模式，而不是被动地累积。这句话点醒了我。我回去把代码重构了一遍，把上下文从一个无脑增长的列表，改成了有结构、有策略、有生命周期的“模式化”管理。跑了一段时间之后，对话稳定性上去了，成本降了大约三分之一，最关键的是出了幺蛾子我能快速定位问题了——这才是聊下去的动力。
这篇文章就把我落地 context-mode 的完整思路、代码实现、踩坑记录都摊开讲。适合正在做聊天机器人、AI 客服、智能体（Agent）、或者任何需要长对话记忆的 LLM 应用开发者。不管你是刚接触这个概念，还是已经被上下文问题折磨了一阵子，下面这些内容都能直接用。
2. 核心概念与设计拆解
2.1 什么是 context-mode：把“记什么”和“怎么记”分开
简单说，context-mode 是一种上下文管理策略，它的核心思想是：不再把对话历史当成一条连续的、不可分割的串，而是把它拆成若干“段”，每一段承担不同的职责，由一套显式规则来决定——当前这轮请求里，哪些段要带、哪些段可以丢、哪些段需要先压缩。
打个比方。传统的上下文管理方式，就像你进会议室的时候，把前面每一场会议的原始录音都搬进去，全放出来。而 context-mode 的做法是：先整理出一份“会议纪要”（核心事实），再抽出几张跟本次议题直接相关的“原始发言记录”（关键引用），至于无关紧要的闲谈，直接留在档案室不带了。
这套思路看起来简单，但落地之后你会发现，它解决的不只是 token 超限的问题，更关键的是让模型的注意力集中在当前真正需要的信息上。模型的注意力是有限的，你硬塞给它 10 万字的聊天记录，它不可能真正“记住”每一个细节，它只会被最近的、位置靠前的、或表述清晰的内容带跑。context-mode 的目标，就是通过管理层面的主动筛选，帮模型排除噪音。
2.2 上下文的三层结构：原始层、提炼层、控制层
我在实际工程里把上下文拆成了三个层面，这样每一层都有清晰的责任边界，后续的增删改查都方便。
第一层叫原始层（Raw Layer），存的是完整的对话历史，包括用户原话、我的回复、工具调用结果、抓取到的网页内容等等。这一层只负责“存”，不负责“用”，它存在的意义是作为一个数据源，随时可以回溯原始信息。真实场景里，原始数据我一般落在 Redis 或者数据库中，不会常驻内存，只有在需要重新提炼时才读出来。
第二层叫提炼层（Distilled Layer），这是 context-mode 的核心。在这一层里，原始对话会被提炼成三种类型的摘要：长期摘要（比如用户的核心目标、关键背景资料）、短期摘要（最近几轮的要点）、当前意图（正在进行的任务的当前状态）。这三者组合成一份结构化的“当前上下文快照”，每次调用模型时，主要就是把这一层的内容带进去。
第三层叫控制层（Control Layer），它不参与具体的对话内容，而是负责元信息的管理：比如当前上下文还在哪个阶段、上一次提炼是什么时候、还有多少 token 预算、哪些内容被标记为“高优先级不能丢”、哪些被标记为“低优先级可压缩”。控制层是整个 context-mode 的指挥中枢，策略规则的执行都在这层完成。
2.3 为什么选择显式模式而非隐式拼接
可能你会问：市面上不是有很多自动上下文压缩的工具吗？我理解，确实有一类方案是通过 embedding 相似度自动检索相关历史片段拼进去，这属于“隐式拼接”。但我在实践中发现，隐式拼接有两个绕不开的坑。
坑之一是检索质量不稳定。embedding 检索擅长找语义相似的片段，但对话上下文里的关联不只是语义相似，更多是逻辑因果和引用关系。比如用户在第 5 轮提到“明天下午三点”，到了第 20 轮说“把那个时间改到四点”，这里的两条信息语义上完全不相似，但逻辑上强相关。靠相似度检索，大概率找不回第 5 轮那条信息，于是模型就懵了。
坑之二是不可解释性。隐式拼接跑出来的结果，你很难解释为什么这一轮把某条历史带进去了，那一条没带。出了问题只能干瞪眼。而 context-mode 的显式规则——哪些信息进入长期摘要、哪些进入短期摘要、优先级怎么标——每一步都明明白白写在代码里，是可审计、可调试的。对我来说，这种可控性价值远大于那一点自动化的便利。
3. 实操：从零落地一个 context-mode
3.1 定义上下文数据结构
动手第一步，是定义一套清晰的上下文数据结构。我用的语言是 Python，但思路完全通用。核心是三个数据类，分别对应上文的提炼层、原始层和控制层。
from dataclasses import dataclass, field from typing import List, Optional @dataclass class DistilledContext: """提炼层：真正会随请求发给模型的上下文快照""" long_term_summary: str = "" # 长期摘要：用户目标、背景、关键约定 short_term_summary: str = "" # 短期摘要：最近几轮的核心进展 current_facts: List[str] = field(default_factory=list) # 当前关键事实 pending_tasks: List[str] = field(default_factory=list) # 待办/未完成事项 @dataclass class ContextMessage: """原始层：单条对话记录的完整信息""" role: str # user / assistant / tool content: str timestamp: int # 时间戳，用于排序和过期判断 importance: int = 1 # 重要性标记：0丢弃，1普通，2关键 metadata: dict = field(default_factory=dict) @dataclass class ContextControl: """控制层：元信息与预算管理""" session_id: str token_budget: int = 8000 # 本轮请求允许的上下文预算 estimated_tokens: int = 0 last_distill_time: int = 0 # 上次提炼时间 high_priority_keys: List[str] = field(default_factory=list)这里我强调三个设计要点。
第一个是 importance 字段。它不是摆设，而是控制层做丢内容判断的重要依据。我在代码里给所有进入上下文的消息打重要性标记：闲聊打 0，业务关键信息打 2，普通对话打 1。标记来源分两类：一类是规则（比如命中“订单号”“日期”“金额”这些关键词就自动标记），另一类是模型自判（每隔几轮让模型把重要信息标出来）。这套标记体系在后续的压缩决策里起了大作用。
第二个是 pending_tasks 字段。实际做下来发现，让模型记住“还有哪些事没做完”，比记住“都聊了什么”更有价值。比如用户说“帮我写一篇文章，另外顺便查一下明天的天气”，模型如果只记住聊过这个话题，没有记住还有查天气这个待办，很容易写了一半就把天气忘了。pending_tasks 单独列出来，每次请求都明确告诉模型“别忘了几件事还没做”。
第三个是 timestamp 字段。原始层的数据会有过期策略，比如超过 48 小时的对话内容，默认不进入任何摘要。时间戳就是为了支持这种“让旧信息自然淡出”的机制。
3.2 实现上下文压缩与分片策略
数据结构定好了，接着是核心算法层面：怎么决定什么该留、什么该去。我实现了一套简单的两阶段压缩策略：就地压缩和回溯再压缩。
就地压缩发生在每轮对话结束后。当检测到预估 token 超过预算阈值的 70% 时，触发一次压缩操作。压缩的操作是把当前上下文里的普通消息（importance=1）交给模型，让它提炼成短摘要，替换掉原始消息。具体实现我封装成一个函数：
import tiktoken def estimate_tokens(messages: list) -> int: """用 tiktoken 估算 token 数，优先用 cl100k_base 编码""" enc = tiktoken.get_encoding("cl100k_base") total = 0 for m in messages: if isinstance(m, dict): total += len(enc.encode(f"{m.get('role', '')}: {m.get('content', '')}")) else: total += len(enc.encode(m)) return total def compact_context(raw_messages: List[ContextMessage], distill: DistilledContext, model) -> DistilledContext: """就地压缩：把普通消息提炼进摘要，关键消息保留原文""" # 收集普通消息 normal_msgs = [m for m in raw_messages if m.importance == 1] key_msgs = [m for m in raw_messages if m.importance == 2] if not normal_msgs: return distill # 把普通消息交给模型做摘要 prompt = "请将以下对话记录压缩为要点摘要，保留事实、决定、用户偏好，丢弃寒暄：" content = "\n".join(f"{m.role}: {m.content}" for m in normal_msgs) resp = model.complete(prompt + "\n" + content) # 更新提炼层：并入短期摘要 distill.short_term_summary = resp return distill这段代码的思路是：普通消息一次性压缩成摘要，而重要消息（importance=2）保持原文不压缩。为什么重要消息要保留原文？因为摘要本质上是有损压缩，牵涉到订单金额、合同条款、时间节点这类信息，一个字的偏差可能就会造成业务事故。重要消息宁可多占 token，也不能让模型在压缩过程中“自由发挥”丢掉细节。
回溯再压缩是另一套机制，触发条件更严苛。当上下文里的关键消息（importance=2）也开始超限时，我会把之前已经压缩过的短期摘要再交给模型，和长期摘要做一次合并。这相当于把“周报”合并成“月报”，粒度进一步变粗。这一步的信息损失是最大的，所以我在工程上加了保护：合并之前会先备份旧摘要到原始层，万一后面发现问题，可以回滚恢复。
分片策略则是应对长文本的。如果用户一次性拖进来一篇几万字的文档参与对话，我不建议直接塞进提炼层，而是先做切片，每片 2000 字左右，然后对每片做独立的摘要，再把所有片摘要合成一个总摘要。这一步既能控制 token，又能避免长文档超过模型本身的上下文窗口。
3.3 接入对话回调的关键代码
数据结构与压缩算法都有了，接下来需要把它们接入到实际的对话流程里。我主导这部分代码时，遵循了一个核心原则：对话主流程只面向 DistilledContext，不接触原始层。所有原始层的数据获取、提炼、压缩，都通过回调函数在后台完成。
代码逻辑如下：
class ContextManager: def __init__(self, session_id: str, model, budget: int = 8000): self.control = ContextControl(session_id=session_id, token_budget=budget) self.distill = DistilledContext() self.raw_messages: List[ContextMessage] = [] self.model = model def add_message(self, role: str, content: str, importance: int = 1): """新消息进入原始层，并触发预算检查""" self.raw_messages.append( ContextMessage(role=role, content=content, timestamp=time.time(), importance=importance) ) # 预估当前 token，触发就地压缩阈值检查 current_budget = self._estimate_all() if current_budget > self.control.token_budget * 0.7: self._compact() def build_request_messages(self) -> list: """构造发送给模型的消息列表：系统提示 + 提炼层 + 短期关键详情""" messages = [ {"role": "system", "content": f"【上下文模式】\n" f"长期摘要：{self.distill.long_term_summary}\n" f"短期摘要：{self.distill.short_term_summary}\n" f"当前关键事实：{self.distill.current_facts}\n" f"待办任务：{self.distill.pending_tasks}"} ] # 只把重要性为 2 的近期关键消息原文带进请求 recent_key_msgs = [ m for m in self.raw_messages if m.importance == 2 and time.time() - m.timestamp < 3600 ] for m in recent_key_msgs[-6:]: # 最多带最近6条关键原文 messages.append({"role": m.role, "content": m.content}) # 把最近一轮用户消息加进来 if self.raw_messages: last_msg = self.raw_messages[-1] messages.append({"role": last_msg.role, "content": last_msg.content}) return messages def _compact(self): """就地压缩：普通消息提炼进摘要，删除原始普通消息，保留关键消息""" normal_msgs = [m for m in self.raw_messages if m.importance == 1] key_msgs = [m for m in self.raw_messages if m.importance == 2] if not normal_msgs: return prompt = ("以下对话记录需要压缩为要点摘要。" "请保留用户的核心诉求、已确认的事实、做出的决定，" "丢弃寒暄、重复表达和无意义的内容：\n\n") content = "\n".join(f"{m.role}: {m.content}" for m in normal_msgs) resp = self.model.complete(prompt + content) self.distill.short_term_summary = f"{self.distill.short_term_summary}\n{resp}" # 普通消息从原始层移除，避免重复累积 self.raw_messages = key_msgs这里有几个细节我劝你务必注意。
第一，系统提示里的“上下文模式”块是给模型看的。我把它当作一份“上下文说明书”塞在最前面，明确告诉模型：长期摘要是什么、短期摘要是什么、待办有哪些。实测下来，这比把所有历史散落在多轮 user 消息里要清晰得多，模型的遵循度也有明显提升。
第二，最近关键消息只带 6 条。别看这个数字简单，它是我测试了很多轮的结论。带太多关键消息会挤占预算，带太少又容易丢失必要的细节。6 条基本覆盖了“一小时内最多 6 个关键事项被讨论”的常规场景，超过 6 条说明对话已经严重发散，更合理的做法是让用户重新发起一个新会话。
第三，压缩后立刻删除原始普通消息。这一步是很多人会忽略的：你做了摘要，但如果不删原始消息，总量根本没有减少，调用成本照样涨。删除操作也就是把 raw_messages 重设为只有关键消息。如果你担心误删，可以把普通消息转存到数据库再删，但至少内存里要清理干净。
3.4 让模型帮你标注重要性的半自动方案
上面提到 importance 字段，我在项目里最初是纯人工规则标注的。后来发现，纯规则太死板，例如“帮我查一下天气”这种临时请求，重要性其实不高，但它不含任何关键词，规则压根识别不出来。后来我在每三轮对话结束后，加了一次模型自判：
def auto_annotate_importance(raw_messages: List[ContextMessage], model) -> None: """让模型从近期对话中找出重要性为2的消息""" recent = raw_messages[-10:] content = "\n".join(f"{m.role}: {m.content}" for m in recent) prompt = ( "从以下对话中提取出与用户业务目标直接相关的关键消息，" "以JSON数组输出每条的原文序号（从1开始），例如[1,5]。" "没有则输出[]。\n\n" + content ) resp = model.complete(prompt) try: idx_list = json.loads(resp) for idx in idx_list: if 1 <= idx <= len(recent): recent[idx - 1].importance = 2 except json.JSONDecodeError: # 解析失败时保持原状，不阻断主流程 pass这段代码有几个点需要注意：只对最近 10 条做标注，不扫描全量历史，因为扫描全量的成本不划算，意义也不大；解析失败时静默跳过，不能因为标注环节出错导致主流程崩溃；模型自判的准确性不是 100%，所以只做“拔高”（从 1 提到 2），不做“降低”（从 2 降回 1），宁可多留一些关键信息，也不能误删真正的重点。这样混合了规则+模型自判之后，重要性标记的召回率明显提升了，而且大多数场景下模型判断得挺准。
4. 常见问题与排查技巧实录
4.1 首轮对话就超 token，问题出在哪
有一种很典型的报错现象：用户只发了一句话，结果请求发出去直接超限。排查到最后发现，问题不在对话历史，而在于系统提示词里塞了一份巨长的“产品说明”，那份说明本身就有 7000 多 token，再加一点上下文就爆了。
这类问题的排查思路是：超限时先分桶测试，分别估算系统提示词、提炼层、关键消息、最近消息各自的 token 数，谁占大头先砍谁。我在代码里加了一个简单的 debug 日志函数：
def log_token_usage(control: ContextControl, distill: DistilledContext, key_msgs: list): usage = { "system_prompt": estimate_tokens([_system_prompt()]), "long_term_summary": estimate_tokens([distill.long_term_summary]), "short_term_summary": estimate_tokens([distill.short_term_summary]), "key_msgs": estimate_tokens(key_msgs), } print(f"[token usage] total={sum(usage.values())}, detail={usage}")实测下来，最常背锅的是长期摘要。很多开发者做长期摘要时没有做长度上限，让模型自由发挥，结果每一轮压缩都往里面追加内容，越滚越长。我的习惯是给长期摘要设一条硬性长度上限，比如 800 字以内，超出就必须再次压缩，把它当成一个“有界”的数据结构来管理。
4.2 上下文丢失：用户说“我刚才明明告诉过你”
这是 context-mode 最敏感的一类问题。用户前脚说了关键信息，后脚你压缩的时候把它误当成普通消息，直接丢掉了。等你再问用户“麻烦再说一遍您的地址”，体验就很糟糕了。
这种问题的根源在于重要性标注不够准。我排查时常用的办法是回放：把原始层里所有消息按时间打印出来，检查有没有重要消息被错误标记为 importance=1。回放几次就能发现，容易漏掉的是那些“信息密度高但表述朴素”的内容。比如用户说“对了，我明天出差，晚上的会就取消了”，这句话里包含了两个关键事实（出差、取消会议），但字面表达非常日常，规则命中不了，模型自判偶尔也会漏。
我的改进方案是：提升模型自判的触发频率——从每三轮一次改成每两轮一次，同时把 prompt 里明确加上“注意识别用户的口语化表述，例如‘对了’‘顺便’‘另外’开头的句子往往是补充重要信息”。这一改，漏标率下降了不少。另一个兜底方案是设置“最近 N 轮消息默认进入关键列表”。比如，最近两轮的 user 消息不管 importance 标多少，build_request_messages 时都原样带入。毕竟离现在最近的对话一般是上下文里最相关的内容，牺牲一点预算换稳定性是值得的。
4.3 多会话隔离：别把 A 用户的话带到 B 用户的会话里
一开始我在单会话场景下自测，一切正常。一旦部署到线上，发现不同类型的用户会话开始互相“串味”。问题出在 session_id 的处理上：我没有显式区分每个会话的上下文存储，导致所有用户的原始消息都堆在了同一个列表里。
修复方式是：每个 session_id 独立创建 ContextManager 实例，并且用 Redis 以 session_id 为 key 做持久化。每次请求进来时，先从 Redis 加载对应实例，对话结束后把实例状态序列化存回去。这里有一个性能细节要注意：不能把整个 ContextManager 对象用 pickle 存，因为里面带有 model 实例，不可序列化。我后来只持久化三个核心字段：DistilledContext、原始消息列表、控制层的预算与时间戳，model 每次从配置中心重建。
多会话隔离还有一个隐蔽的坑，就是时间戳冲突。两个会话如果共用同一个时区处理逻辑，在跨天的时候可能会出现时间混乱，导致“最近1小时内的关键消息”判断失效。我的习惯是统一用 Unix 时间戳，所有比较都用时间戳而不是字符串时间，这样跨天、跨时区都不会出问题。
4.4 压缩引起模型“失忆”：摘要到底该怎么写
我得坦白说一个残酷的现状：摘要是有损的，压缩一定会丢信息。很多开发者包括我自己早期都犯过一个错误，就是把摘要当作一种“浓缩所有信息”的魔法，以为摘要写得足够好，模型就能记住一切。实际上，摘要的信息密度是有上限的，超过这个上限，摘要里全都是“正确的废话”。
比如我早期让模型压缩历史，它给出的摘要长这样：“用户与助手就项目安排进行了讨论，确认了一些事项，并就后续步骤达成了初步意见。”——这种摘要就是典型的废话，信息量为零。后来我把压缩的 prompt 改成了强约束问题形式：
“请以下列问题为框架，只回答能直接填进框架的内容： 1. 用户的核心目标是什么？ 2. 目前已确认的事实有哪些？（逐条列，必须包含具体数值、日期、名称） 3. 用户明确表达过哪些偏好/要求？ 4. 还有哪件事没有完成？ 其余内容一律不要写。回答不超过200字。”改成这个模板之后，摘要质量好了很多。核心逻辑是把“尽量多写”改成“只回答关键问题”，让模型的注意力落在业务需要的信息维度上。这个教训也说明了一个道理：context-mode 的成败，往往不在于框架多精巧，而在于摘要的提示词写得多具体。
5. 关于 context-mode 的延伸联想与实际选择
做完这套方案之后，我回头审视了整个架构，发现 context-mode 的价值其实不止于“省 token”。它改变的是整个对话系统的组织方式。以前我是在跟模型对话，现在我是在跟“一份经过整理的项目档案”对话，每次交流都是在这个档案基础上做增量修改。档案里有事实、有待办、有摘要，而模型扮演的角色更像一个根据档案工作的助理，而不是一个什么都得靠现问现记的临时工。
这种思路其实可以延伸到很多地方。比如我在做 Agent 规划时，也采用了类似的模式：把 Agent 长期目标、当前步骤、已完成步骤、下一步计划，拆成结构化的上下文块，而不是让 Agent 自己漫无边际地推理。再比如做文档问答时，把检索到的文档块按“核心结论”“证据细节”“补充背景”分层，再决定哪些进 prompt、哪些留在外部。这套“分层、提炼、有损接受”的哲学是通用的。
不过我还是要说一句大实话：context-mode 不是银弹，它解决的是“上下文需要管理”的问题，但它不能替你解决“上下文根本没有”的问题。如果业务本身需要模型记住大量精确的细节，那更合理的方案是接入外部记忆——比如向量数据库做长期检索、或者专门的记忆服务，而不是指望摘要能包打天下。在我目前的服务里，context-mode 承担的是“短期对话的工作记忆”，长期知识则交给了外部检索，两者配合才达到比较理想的体验，而不是互相替代。
如果你现在也被上下文问题困扰着，我的建议是：不要等到线上爆炸了才动手，早点把上下文的“管理意识”建立起来。哪怕第一版很粗糙，只做了“近 20 轮完整保留、更早的压缩成摘要”这一件事，也能立刻看到效果。做完了这第一步，后面再逐步引入重要性标注、结构化提炼、预算控制这些进阶手段，就是顺水推舟的事了。
