1. 先搞清楚 context-mode 到底解决什么问题第一次看到 context-mode 这个词时你可能觉得它只是某个框架里的新参数。但当我真正把它用进一个对话式需求分析工具后才意识到它是一整套关于如何管理大模型上下文资源的策略集合。说白了就是解决一件事对话历史越滚越长上下文窗口就那么大你该怎么取舍、怎么保留、怎么压缩。1.1 暴力堆上下文的困境很多人刚开始做聊天机器人时直接把所有历史消息拼进 prompt 发给模型。短对话没问题一旦聊了二三十轮上下文窗口就被塞满了。然后出现三种典型的副作用模型开始忘事把 10 轮前的关键指令给丢了token 费用暴涨大量无价值的内容在反复计算响应延迟变高用户明显能感觉到卡。我自己踩过这个坑。之前做一个项目需求分析助手用户连续追问了一个小时系统因为上下文溢出直接报错。那次之后我才意识到靠堆 token 解决不了问题必须给上下文的管理引入一个模式概念——这就是我理解的 context-mode 的初衷。需要注意的是context-mode 并不是单一技术而是一组上下文管理策略的统称。它决定了什么时候保留完整历史、什么时候做摘要压缩、什么时候只留最近几轮、什么时候去检索历史片段。核心目的非常朴素在有限的上下文窗口里放进对当前任务最有价值的信息。1.2 context-mode 的三层含义我在实际使用中倾向于把 context-mode 拆成三个维度来理解。第一层是窗口策略。也就是最近多少轮对话会被保留。比如 window12 表示只保留最近 12 轮。这个维度解决的是放不下的问题。第二层是压缩策略。当历史超过窗口阈值时是把更早的内容直接丢掉还是用摘要把它浓缩成一个短段落。这个维度解决的是不能丢的问题。第三层是检索策略。更复杂的系统会把历史切块存进向量库用户提出新问题时先按相关性召回几段历史再拼接进 prompt。这个维度解决的是用得准的问题。三个维度通常要组合使用。比如我常用的搭配是窗口保留最近 8 轮完整对话 超过窗口的部分每 4 轮做一次摘要快照 如果用户明确提到上次说过的那个方案再从摘要快照里找回相关段落。这就是一个非常实用的 context-mode 配置。理解了这三层你也就明白它为什么重要——本质上它是在把大模型的上下文窗口当作一个资源池做规划管理跟操作系统做内存管理的思路一模一样。1.3 哪些场景最需要它不是所有项目都必须上 context-mode。我做了一个简单的判断标准你可以在规划阶段自查你的产品是否存在多轮连续对话且单次会话会超过 10 轮用户是否会依赖早前说过的话来做后续决策你是否因为 token 成本或上下文溢出而限制过对话长度你是否曾收到过你忘记了我刚说的内容这类反馈如果中了任意两条那 context-mode 就是你迟早要面对的问题。尤其是智能客服、项目协作助手、长文分析、代码辅助等场景上下文管理的质量几乎直接决定了产品口碑。做得好用户会觉得系统懂我做不好用户会觉得机器人健忘。2. 方案选型与工作原理2.1 四种典型实现方式市面上常见的上下文管理模式大体可以归为四类。我整理了一张对比表方便直接抄模式名称核心思路适用场景优点缺点全量模式full所有历史全部拼进 prompt单轮或短对话信息无损token 损耗大、窗口上限低滑动窗口window只保留最近 N 轮持续性闲聊、辅助编程实现简单、响应快旧信息全丢摘要模式summary超过阈值后压缩为摘要长对话、文档分析保留核心信息、节省 token摘要可能丢细节检索模式retrieval历史切块入库按需召回知识库问答、个性化助手精确召回、容量大延迟高、需要额外组件这四种不是非此即彼的关系。实际上我在线上系统里用得最多的是混合模式也就是 window summary再加一档 retrieval 作为可选开关。这里多说一句不要迷信检索模式。检索模式看起来高端但它有两个硬伤。一是需要单独维护向量库增加部署复杂度二是相似度召回有随机性经常漏掉重要上下文。如果项目刚起步先把滑动窗口和摘要做好性价比最高。2.2 为什么我选滑动窗口 摘要快照我在对话式需求分析工具里测试过四种模式的组合效果最后稳定采用的是滑动窗口为主、摘要快照为辅。原因有几个。第一滑动窗口的 token 开销是可控的。窗口长度固定后prompt 长度基本稳定不会出现聊得越久越贵的情况。第二摘要快照能在几乎不增加 token 的情况下保留早期重要信息比如用户的核心诉求、关键决策、审批结论。第三这种组合不需要额外组件纯靠 prompt 拼接就能实现部署非常轻。原理上也很直观。每轮对话结束后系统会检查当前消息数量是否达到触发条件。如果达到就调用一次摘要模型把窗口外的那部分历史压缩成一段 100-200 字的摘要替换掉原始消息。这样 prompt 结构变成三块meta 区系统指令 用户设定 当前任务摘要区早期历史的浓缩描述窗口区最近 N 轮完整对话模型既能看到宏观脉络又能看到最近发生的细节这比单一策略稳定得多。2.3 检索模式的适用边界当然检索模式也不是没有价值。我把它留给两类场景一类是知识库问答用户的问题通常相互独立靠向量召回比靠完整对话历史更高效另一类是超大上下文的个性化助手比如用户和系统连续交流了几十次中途提到过大量具体事实用摘要难以覆盖只能靠检索把相关碎片找回来。但在实现检索模式时建议做好两个准备。第一你的文本切块策略要过关切太大了召回噪声高切太小了语义容易碎通常 200-400 字一块比较合适。第二检索结果要附带时间戳和相关度得分拼进 prompt 时还要给模型说明以下片段来自历史记录可能包含过时信息否则模型很容易把旧信息当成当前事实。2.4 模式切换的前置条件用一个 mode 字段来定义当前上下文管理策略目的是让程序在运行期能灵活切换。但切换不能随意做我在代码里必须保证几个前置条件。条件一每轮请求都要能区分持久信息和临时信息。持久信息包括用户设定的偏好、系统约束、任务目标这些不受窗口影响临时信息指某一轮的具体提问和回答窗口滚动时可以丢弃。如果这两类信息混在一个列表里任何模式切换都会出问题。条件二摘要生成必须保证格式一致。每次压缩都要求输出固定结构比如用户最开始提出要做一个...中间明确了...最后决定...。这样后续拼接时模型才能稳定读取不会因为格式漂移而漏判。条件三切换模式时旧模式的上下文要能安全转换。举个具体例子从 full 切到 window 时不能直接把超出的几轮删掉——而是应该先把它们压缩成摘要快照再丢弃原始内容。这一步如果不写严谨用户会明显感觉到系统突然失忆。3. 动手实现一个 context-mode 对话系统下面这部分我把实际用过的代码骨架整理出来。你可以改几个变量名就接入自己的项目。我采用最通用的 LLM 调用方式不绑定某个特定厂商的 SDK。3.1 整体结构与数据结构设计核心是一个叫 ContextManager 的类它维护一个消息列表和一个摘要列表。为简洁起见我这里用 dataclass 定义from dataclasses import dataclass, field from typing import Any, Dict, List dataclass class ContextSnapshot: 摘要快照保存早期历史的核心信息 content: str source_count: int created_at: int extra: Dict[str, Any] field(default_factorydict) dataclass class ContextState: 上下文的完整状态 mode: str meta: Dict[str, Any] recent_messages: List[Dict] snapshots: List[ContextSnapshot] retrieval_index: Any None这个结构很清爽。meta 永远不参与窗口滚动recent_messages 是真正会发生截断的部分snapshots 存放早期历史的摘要。每次拼接 prompt 时顺序是 meta → snapshots → recent_messages。我建议把 mode 也写进 ContextState这样每次请求都能看到当前系统是用什么策略组织上下文的排障时一眼就能定位问题。另外给每条消息加 timestamp 字段也很重要摘要生成和窗口截断都要依赖它判断先后顺序。3.2 核心流程的四个方法ContextManager 里有四个核心方法追加消息、判断是否需要压缩、执行摘要压缩、拼接最终 prompt。追加消息实际上就是往 recent_messages 里 push 一条记录然后调用_maybe_compact()检查是否需要触发压缩class ContextManager: def __init__(self, mode: str window, window_size: int 12, summary_trigger: int 8, summary_max_tokens: int 200): self.state ContextState(modemode) self.window_size window_size self.summary_trigger summary_trigger self.summary_max_tokens summary_max_tokens self._message_counter 0 def add_message(self, role: str, content: str): self.state.recent_messages.append({ role: role, content: content, timestamp: self._message_counter }) self._message_counter 1 self._maybe_compact() def _maybe_compact(self): if len(self.state.recent_messages) self.window_size: return snapshot self._summarize_old_messages() self.state.snapshots.append(snapshot) self.state.recent_messages self.state.recent_messages[-self.summary_trigger:]这里有一个值得注意的细节window_size和summary_trigger是两个不同参数。window_size是上限summary_trigger是压缩后保留的最近消息条数。比如 window_size12summary_trigger8意思是当消息达到 12 条时触发压缩把旧内容变成摘要窗口保留最近 8 条。这样既能防止频繁压缩又能保证最近信息充足。3.3 压缩与拼接的实现细节执行压缩时我把即将被丢弃的旧消息和已有摘要一起交给模型让它输出新摘要。注意一定要把旧摘要带上否则摘要会丢掉更早期的信息def _summarize_old_messages(self) - ContextSnapshot: old_messages self.state.recent_messages[:-self.summary_trigger] summary_prompt ( 你负责维护对话的长期记忆。请阅读历史对话和已有摘要 输出一份简洁摘要包含用户的核心目标、已确定的关键决策、 尚未解决的问题。保留具体名称、数字、结论。不要超过{}字。\n\n 已有摘要\n{}\n\n 新历史\n{} ).format( self.summary_max_tokens, self._format_snapshots(self.state.snapshots), self._format_messages(old_messages) ) summary_text call_llm([ {role: user, content: summary_prompt} ]) return ContextSnapshot( contentsummary_text, source_countlen(old_messages), created_atself._message_counter )调用call_llm的地方我用的和主链路是同一个模型。如果对成本敏感可以把摘要模型换成更小的型号。实测下来摘要质量差异不大但成本能降一半以上。最终拼装 prompt 的代码如下把三段式结构落实到位def build_prompt(self, user_query: str) - List[Dict]: messages [] if self.state.meta.get(system_prompt): messages.append({role: system, content: self.state.meta[system_prompt]}) if self.state.snapshots: snapshot_text self._format_snapshots(self.state.snapshots) messages.append({ role: system, content: 以下是这段对话更早期的背景摘要\n snapshot_text }) messages.extend(self.state.recent_messages) messages.append({role: user, content: user_query}) return messages这样 build 出来的 messages传给大模型就是一条结构清晰、信息分层的 prompt。模型先读 meta 区建立全局约束再读摘要区获得早期脉络最后读窗口区了解最新进展思考质量会明显提升。3.4 关键参数怎么定参数设置没有万能配方但我多次实测后总结了一套比较靠谱的初始值上下文窗口总长window_size轮summary_trigger轮summary_max_tokens字8k6415016k10620032k1610300128k4024600为什么这么定核心逻辑是给摘要区和 meta 区预留空间。比如 8k 窗口平均每轮对话约 800 token保留 6 轮就是 4800 token剩下 3200 token 给摘要和系统指令。如果单轮内容经常超过 1500 token就得把 window_size 调小到 4 或 5。参数调整有一个笨但有效的办法累计观察 50 轮请求的 token 分布把 meta 区、摘要区、窗口区的占比控制在 1:2:3 左右。超过这个比例就该触发压缩了。记得把摘要本身的长度也算进去很多人容易忽略这一点导致 prompt 超限。3.5 模式切换的完整时序示例模式切换不应该是一个瞬时的粗暴操作而应该是分步的安全迁移。我以从 full 模式切到 summary 模式为例给出一个可参考的时序调用 freeze 接口停止接收新消息锁住当前 ContextState把当前 recent_messages 中超出目标窗口的部分生成一份摘要快照将摘要快照写入 snapshots 列表截断 recent_messages只保留目标窗口内的消息更新 state.mode 为 summary解冻继续接收新消息。def switch_mode(self, new_mode: str): if new_mode self.state.mode: return if new_mode in (summary, window): if len(self.state.recent_messages) self.window_size: snapshot self._summarize_old_messages() self.state.snapshots.append(snapshot) self.state.recent_messages self.state.recent_messages[-self.summary_trigger:] self.state.mode new_mode这个方法的巧妙之处在于不管从哪个模式切换过来它都先把旧信息转成摘要确保用户的历史记忆不丢失。我在实际使用中发现这个简单的设计极大地避免了切换模式后系统像变了个人的体验问题。4. 实战中的坑上下文污染与模式切换陷阱实现 context-mode 不难难的是让它在真实场景里不翻车。这一节聊几个我在部署过程中踩过的坑希望对你有帮助。4.1 最典型的问题速查表现象可能原因解决建议用户说我刚才不是说过吗窗口滚动丢掉了关键决策把关键决策写入 meta 区不参与滑动窗口淘汰摘要里出现错误事实压缩模型把猜测写进了摘要摘要指令里加不确定的信息不要写频繁触发压缩导致响应慢summary_trigger 设置太小增大 trigger让更多消息累积后再压缩切换模式后用户失忆旧模式完整历史没有先做摘要切换前强制执行一次摘要快照模型遵循旧指令不理会新目标meta 区的目标任务被窗口覆盖每次请求都把当前目标放在 prompt 最近位置token 统计和预想差很大摘要 prompt 里拼接了过多旧摘要只保留最近一个摘要或对摘要做二级压缩这些坑我几乎全部踩过。最让人崩溃的是第二个摘要里出现错误事实。有一次系统在摘要里写用户决定采用 PostgreSQL实际上用户说的是暂时不考虑 PostgreSQL。原因是压缩时旧消息里既有讨论又有否定模型在压缩时把否定条件给省了。后来我在摘要指令里明确要求必须保留否定性结论和约束条件问题基本消失。4.2 排查思路先看 token 分布再看内容遇到 context-mode 相关问题我的排查顺序是固定的。先打印当前请求的完整 prompt 结构统计每个区域的 token 占比。如果摘要区占比过高说明压缩频率太低如果窗口区占比过高说明 window_size 太大如果 meta 区占比过高可能是系统指令塞了太多无用规则。内容层面的排查我习惯做一个小工具同时记录每次压缩前的原始消息和压缩后的摘要把它们输出到日志文件。这样一旦用户反馈你忘了什么我可以立刻 diff 出是哪一次压缩丢的信息。另外一个实用技巧在窗口区里混入一个当前任务状态占位符每轮由模型自己更新。比如【当前进度】已完成需求分析待确认预算范围。这样即使窗口滚动模型也能从状态占位符里迅速恢复上下文而不是依赖阅读全文。这是我在实践中验证过非常有效的做法。4.3 用评测集守住摘要质量摘要质量是 context-mode 的生命线。只靠肉眼检查根本不现实所以我后来专门建立了一个摘要评测集里面有 50 组容易产生事实偏移的对话。每组都有标准答案比如必须保留的关键决策必须保留的否定条件允许省略的寒暄内容。每次调整摘要指令或更换摘要模型我都会跑一遍这个评测集记录三个指标关键决策保留率标准答案中的决策是否都出现在摘要中事实错误率摘要中是否出现了与原始对话矛盾的内容信息密度摘要文本中有效信息占比是否合理。跑完评测集再上线上环境能挡掉大部分隐性回归。这个小步骤的成本并不高但对稳定性收益极大。你在接自己的项目时建议从第一天就留出时间做这件事。5. 我的调参经验与最终心得5.1 按场景推荐的一组配置上文那些参数是通用初值。真到具体项目我通常会做一轮针对性的微调。这里分享三个典型场景。智能客服/闲聊机器人。这类场景轮次极多但单轮信息量小。我建议用 window 模式window_size 可以放到 20-30 轮不启用摘要。因为闲聊的历史价值密度低摘要反而会多花 token还可能引入噪声。需求分析与项目管理助手。这种场景单轮信息量大且历史中的决策必须保留。我建议用 window summarywindow_size 控制在 8-12summary_trigger 控制在 4-6。摘要区必须显式记录已确认和待讨论两类信息这样后续轮次模型才知道什么能直接用、什么还需要追问。知识库问答助手。场景特点是历史相对独立主要靠检索。我建议用 retrieval 模式窗口只需要保留最近 2-3 轮把主要精力放在高质量切块和向量召回上。context-mode 在这里的目标不是记住全部而是准确定位。5.2 实测下来最值钱的三条经验第一条经验context-mode 的设计应该服务于用户体验而不是服务于技术指标。在优化 token 成本和控制延迟时不要牺牲掉用户明确需要的信息。有一次我把摘要间隔调得太激进token 省了 30%但用户满意度掉了 12%。后面调回来成本回到原来的 80%满意度也恢复了。这个平衡点需要拿数据说话不能拍脑袋。第二条经验要把摘要生成当成一等公民对待。很多人把摘要压缩当作一个简单的 prompt 拼接但它其实是整个 context-mode 里质量风险最高的环节。值得为它单独设计指令、单独做评测。摘要指令做得越具体模型就越不会自由发挥。比如我要求必须保留具体名称、数字、结论比笼统地说请总结一下稳定得多。第三条经验日志和可观测性一定要从第一天就加上。context-mode 的价值在于让系统有选择地记忆而记忆出错时用户很难定位。所以至少要记录三项数据每次拼接后的 token 分布、每次摘要的前后对比、每次模式切换的触发原因。有了这些日志用户说你记错了的时候你能在五分钟内给出明确答复而不是一脸懵。5.3 后续还能怎么扩展context-mode 这套思路并不局限在对话场景。我现在尝试把它扩展到两个方向。第一个方向是多智能体协作。每个智能体都有自己的上下文窗口同一个任务跨多个智能体流转时需要定义清晰的 context-mode 来传递任务目标和已完成进度而不是把整个对话历史打包带走。这样既能节省 token也能避免无关信息干扰下游智能体。第二个方向是流式日志分析。把系统运行时的关键事件切片成窗口超过阈值就生成摘要快照用于快速定位异常。这个思路本质上和 context-mode 一致保留最有价值的上下文舍弃无关的噪声。边界场景中它能帮你从海量日志里快速还原故障现场。我还给每个请求带上 context-mode 的标识在请求头里加一个自定义字段x-context-mode: windowsummary日志和监控都按这个维度聚合。后期做 A/B 测试非常方便也能随时切换策略验证效果。这个小习惯帮我省了很多排障时间。实际上到现在我还在持续调整 context-mode 的参数。每个项目的知识密度、交互风格、用户耐心都不一样不存在一套配置通吃所有场景。我个人的体会是先搭好可插拔的架构让模式可以随时切换再用真实用户数据去调参。只有把上下文管理当成一项持续演进的工程而不是一锤子买卖你的对话系统才能真正变得聪明起来。上面这套代码和参数是我在自己项目里反复打磨出来的希望能帮你少走几段弯路。
context-mode大模型上下文管理：滑动窗口与摘要快照实战解析
1. 先搞清楚 context-mode 到底解决什么问题第一次看到 context-mode 这个词时你可能觉得它只是某个框架里的新参数。但当我真正把它用进一个对话式需求分析工具后才意识到它是一整套关于如何管理大模型上下文资源的策略集合。说白了就是解决一件事对话历史越滚越长上下文窗口就那么大你该怎么取舍、怎么保留、怎么压缩。1.1 暴力堆上下文的困境很多人刚开始做聊天机器人时直接把所有历史消息拼进 prompt 发给模型。短对话没问题一旦聊了二三十轮上下文窗口就被塞满了。然后出现三种典型的副作用模型开始忘事把 10 轮前的关键指令给丢了token 费用暴涨大量无价值的内容在反复计算响应延迟变高用户明显能感觉到卡。我自己踩过这个坑。之前做一个项目需求分析助手用户连续追问了一个小时系统因为上下文溢出直接报错。那次之后我才意识到靠堆 token 解决不了问题必须给上下文的管理引入一个模式概念——这就是我理解的 context-mode 的初衷。需要注意的是context-mode 并不是单一技术而是一组上下文管理策略的统称。它决定了什么时候保留完整历史、什么时候做摘要压缩、什么时候只留最近几轮、什么时候去检索历史片段。核心目的非常朴素在有限的上下文窗口里放进对当前任务最有价值的信息。1.2 context-mode 的三层含义我在实际使用中倾向于把 context-mode 拆成三个维度来理解。第一层是窗口策略。也就是最近多少轮对话会被保留。比如 window12 表示只保留最近 12 轮。这个维度解决的是放不下的问题。第二层是压缩策略。当历史超过窗口阈值时是把更早的内容直接丢掉还是用摘要把它浓缩成一个短段落。这个维度解决的是不能丢的问题。第三层是检索策略。更复杂的系统会把历史切块存进向量库用户提出新问题时先按相关性召回几段历史再拼接进 prompt。这个维度解决的是用得准的问题。三个维度通常要组合使用。比如我常用的搭配是窗口保留最近 8 轮完整对话 超过窗口的部分每 4 轮做一次摘要快照 如果用户明确提到上次说过的那个方案再从摘要快照里找回相关段落。这就是一个非常实用的 context-mode 配置。理解了这三层你也就明白它为什么重要——本质上它是在把大模型的上下文窗口当作一个资源池做规划管理跟操作系统做内存管理的思路一模一样。1.3 哪些场景最需要它不是所有项目都必须上 context-mode。我做了一个简单的判断标准你可以在规划阶段自查你的产品是否存在多轮连续对话且单次会话会超过 10 轮用户是否会依赖早前说过的话来做后续决策你是否因为 token 成本或上下文溢出而限制过对话长度你是否曾收到过你忘记了我刚说的内容这类反馈如果中了任意两条那 context-mode 就是你迟早要面对的问题。尤其是智能客服、项目协作助手、长文分析、代码辅助等场景上下文管理的质量几乎直接决定了产品口碑。做得好用户会觉得系统懂我做不好用户会觉得机器人健忘。2. 方案选型与工作原理2.1 四种典型实现方式市面上常见的上下文管理模式大体可以归为四类。我整理了一张对比表方便直接抄模式名称核心思路适用场景优点缺点全量模式full所有历史全部拼进 prompt单轮或短对话信息无损token 损耗大、窗口上限低滑动窗口window只保留最近 N 轮持续性闲聊、辅助编程实现简单、响应快旧信息全丢摘要模式summary超过阈值后压缩为摘要长对话、文档分析保留核心信息、节省 token摘要可能丢细节检索模式retrieval历史切块入库按需召回知识库问答、个性化助手精确召回、容量大延迟高、需要额外组件这四种不是非此即彼的关系。实际上我在线上系统里用得最多的是混合模式也就是 window summary再加一档 retrieval 作为可选开关。这里多说一句不要迷信检索模式。检索模式看起来高端但它有两个硬伤。一是需要单独维护向量库增加部署复杂度二是相似度召回有随机性经常漏掉重要上下文。如果项目刚起步先把滑动窗口和摘要做好性价比最高。2.2 为什么我选滑动窗口 摘要快照我在对话式需求分析工具里测试过四种模式的组合效果最后稳定采用的是滑动窗口为主、摘要快照为辅。原因有几个。第一滑动窗口的 token 开销是可控的。窗口长度固定后prompt 长度基本稳定不会出现聊得越久越贵的情况。第二摘要快照能在几乎不增加 token 的情况下保留早期重要信息比如用户的核心诉求、关键决策、审批结论。第三这种组合不需要额外组件纯靠 prompt 拼接就能实现部署非常轻。原理上也很直观。每轮对话结束后系统会检查当前消息数量是否达到触发条件。如果达到就调用一次摘要模型把窗口外的那部分历史压缩成一段 100-200 字的摘要替换掉原始消息。这样 prompt 结构变成三块meta 区系统指令 用户设定 当前任务摘要区早期历史的浓缩描述窗口区最近 N 轮完整对话模型既能看到宏观脉络又能看到最近发生的细节这比单一策略稳定得多。2.3 检索模式的适用边界当然检索模式也不是没有价值。我把它留给两类场景一类是知识库问答用户的问题通常相互独立靠向量召回比靠完整对话历史更高效另一类是超大上下文的个性化助手比如用户和系统连续交流了几十次中途提到过大量具体事实用摘要难以覆盖只能靠检索把相关碎片找回来。但在实现检索模式时建议做好两个准备。第一你的文本切块策略要过关切太大了召回噪声高切太小了语义容易碎通常 200-400 字一块比较合适。第二检索结果要附带时间戳和相关度得分拼进 prompt 时还要给模型说明以下片段来自历史记录可能包含过时信息否则模型很容易把旧信息当成当前事实。2.4 模式切换的前置条件用一个 mode 字段来定义当前上下文管理策略目的是让程序在运行期能灵活切换。但切换不能随意做我在代码里必须保证几个前置条件。条件一每轮请求都要能区分持久信息和临时信息。持久信息包括用户设定的偏好、系统约束、任务目标这些不受窗口影响临时信息指某一轮的具体提问和回答窗口滚动时可以丢弃。如果这两类信息混在一个列表里任何模式切换都会出问题。条件二摘要生成必须保证格式一致。每次压缩都要求输出固定结构比如用户最开始提出要做一个...中间明确了...最后决定...。这样后续拼接时模型才能稳定读取不会因为格式漂移而漏判。条件三切换模式时旧模式的上下文要能安全转换。举个具体例子从 full 切到 window 时不能直接把超出的几轮删掉——而是应该先把它们压缩成摘要快照再丢弃原始内容。这一步如果不写严谨用户会明显感觉到系统突然失忆。3. 动手实现一个 context-mode 对话系统下面这部分我把实际用过的代码骨架整理出来。你可以改几个变量名就接入自己的项目。我采用最通用的 LLM 调用方式不绑定某个特定厂商的 SDK。3.1 整体结构与数据结构设计核心是一个叫 ContextManager 的类它维护一个消息列表和一个摘要列表。为简洁起见我这里用 dataclass 定义from dataclasses import dataclass, field from typing import Any, Dict, List dataclass class ContextSnapshot: 摘要快照保存早期历史的核心信息 content: str source_count: int created_at: int extra: Dict[str, Any] field(default_factorydict) dataclass class ContextState: 上下文的完整状态 mode: str meta: Dict[str, Any] recent_messages: List[Dict] snapshots: List[ContextSnapshot] retrieval_index: Any None这个结构很清爽。meta 永远不参与窗口滚动recent_messages 是真正会发生截断的部分snapshots 存放早期历史的摘要。每次拼接 prompt 时顺序是 meta → snapshots → recent_messages。我建议把 mode 也写进 ContextState这样每次请求都能看到当前系统是用什么策略组织上下文的排障时一眼就能定位问题。另外给每条消息加 timestamp 字段也很重要摘要生成和窗口截断都要依赖它判断先后顺序。3.2 核心流程的四个方法ContextManager 里有四个核心方法追加消息、判断是否需要压缩、执行摘要压缩、拼接最终 prompt。追加消息实际上就是往 recent_messages 里 push 一条记录然后调用_maybe_compact()检查是否需要触发压缩class ContextManager: def __init__(self, mode: str window, window_size: int 12, summary_trigger: int 8, summary_max_tokens: int 200): self.state ContextState(modemode) self.window_size window_size self.summary_trigger summary_trigger self.summary_max_tokens summary_max_tokens self._message_counter 0 def add_message(self, role: str, content: str): self.state.recent_messages.append({ role: role, content: content, timestamp: self._message_counter }) self._message_counter 1 self._maybe_compact() def _maybe_compact(self): if len(self.state.recent_messages) self.window_size: return snapshot self._summarize_old_messages() self.state.snapshots.append(snapshot) self.state.recent_messages self.state.recent_messages[-self.summary_trigger:]这里有一个值得注意的细节window_size和summary_trigger是两个不同参数。window_size是上限summary_trigger是压缩后保留的最近消息条数。比如 window_size12summary_trigger8意思是当消息达到 12 条时触发压缩把旧内容变成摘要窗口保留最近 8 条。这样既能防止频繁压缩又能保证最近信息充足。3.3 压缩与拼接的实现细节执行压缩时我把即将被丢弃的旧消息和已有摘要一起交给模型让它输出新摘要。注意一定要把旧摘要带上否则摘要会丢掉更早期的信息def _summarize_old_messages(self) - ContextSnapshot: old_messages self.state.recent_messages[:-self.summary_trigger] summary_prompt ( 你负责维护对话的长期记忆。请阅读历史对话和已有摘要 输出一份简洁摘要包含用户的核心目标、已确定的关键决策、 尚未解决的问题。保留具体名称、数字、结论。不要超过{}字。\n\n 已有摘要\n{}\n\n 新历史\n{} ).format( self.summary_max_tokens, self._format_snapshots(self.state.snapshots), self._format_messages(old_messages) ) summary_text call_llm([ {role: user, content: summary_prompt} ]) return ContextSnapshot( contentsummary_text, source_countlen(old_messages), created_atself._message_counter )调用call_llm的地方我用的和主链路是同一个模型。如果对成本敏感可以把摘要模型换成更小的型号。实测下来摘要质量差异不大但成本能降一半以上。最终拼装 prompt 的代码如下把三段式结构落实到位def build_prompt(self, user_query: str) - List[Dict]: messages [] if self.state.meta.get(system_prompt): messages.append({role: system, content: self.state.meta[system_prompt]}) if self.state.snapshots: snapshot_text self._format_snapshots(self.state.snapshots) messages.append({ role: system, content: 以下是这段对话更早期的背景摘要\n snapshot_text }) messages.extend(self.state.recent_messages) messages.append({role: user, content: user_query}) return messages这样 build 出来的 messages传给大模型就是一条结构清晰、信息分层的 prompt。模型先读 meta 区建立全局约束再读摘要区获得早期脉络最后读窗口区了解最新进展思考质量会明显提升。3.4 关键参数怎么定参数设置没有万能配方但我多次实测后总结了一套比较靠谱的初始值上下文窗口总长window_size轮summary_trigger轮summary_max_tokens字8k6415016k10620032k1610300128k4024600为什么这么定核心逻辑是给摘要区和 meta 区预留空间。比如 8k 窗口平均每轮对话约 800 token保留 6 轮就是 4800 token剩下 3200 token 给摘要和系统指令。如果单轮内容经常超过 1500 token就得把 window_size 调小到 4 或 5。参数调整有一个笨但有效的办法累计观察 50 轮请求的 token 分布把 meta 区、摘要区、窗口区的占比控制在 1:2:3 左右。超过这个比例就该触发压缩了。记得把摘要本身的长度也算进去很多人容易忽略这一点导致 prompt 超限。3.5 模式切换的完整时序示例模式切换不应该是一个瞬时的粗暴操作而应该是分步的安全迁移。我以从 full 模式切到 summary 模式为例给出一个可参考的时序调用 freeze 接口停止接收新消息锁住当前 ContextState把当前 recent_messages 中超出目标窗口的部分生成一份摘要快照将摘要快照写入 snapshots 列表截断 recent_messages只保留目标窗口内的消息更新 state.mode 为 summary解冻继续接收新消息。def switch_mode(self, new_mode: str): if new_mode self.state.mode: return if new_mode in (summary, window): if len(self.state.recent_messages) self.window_size: snapshot self._summarize_old_messages() self.state.snapshots.append(snapshot) self.state.recent_messages self.state.recent_messages[-self.summary_trigger:] self.state.mode new_mode这个方法的巧妙之处在于不管从哪个模式切换过来它都先把旧信息转成摘要确保用户的历史记忆不丢失。我在实际使用中发现这个简单的设计极大地避免了切换模式后系统像变了个人的体验问题。4. 实战中的坑上下文污染与模式切换陷阱实现 context-mode 不难难的是让它在真实场景里不翻车。这一节聊几个我在部署过程中踩过的坑希望对你有帮助。4.1 最典型的问题速查表现象可能原因解决建议用户说我刚才不是说过吗窗口滚动丢掉了关键决策把关键决策写入 meta 区不参与滑动窗口淘汰摘要里出现错误事实压缩模型把猜测写进了摘要摘要指令里加不确定的信息不要写频繁触发压缩导致响应慢summary_trigger 设置太小增大 trigger让更多消息累积后再压缩切换模式后用户失忆旧模式完整历史没有先做摘要切换前强制执行一次摘要快照模型遵循旧指令不理会新目标meta 区的目标任务被窗口覆盖每次请求都把当前目标放在 prompt 最近位置token 统计和预想差很大摘要 prompt 里拼接了过多旧摘要只保留最近一个摘要或对摘要做二级压缩这些坑我几乎全部踩过。最让人崩溃的是第二个摘要里出现错误事实。有一次系统在摘要里写用户决定采用 PostgreSQL实际上用户说的是暂时不考虑 PostgreSQL。原因是压缩时旧消息里既有讨论又有否定模型在压缩时把否定条件给省了。后来我在摘要指令里明确要求必须保留否定性结论和约束条件问题基本消失。4.2 排查思路先看 token 分布再看内容遇到 context-mode 相关问题我的排查顺序是固定的。先打印当前请求的完整 prompt 结构统计每个区域的 token 占比。如果摘要区占比过高说明压缩频率太低如果窗口区占比过高说明 window_size 太大如果 meta 区占比过高可能是系统指令塞了太多无用规则。内容层面的排查我习惯做一个小工具同时记录每次压缩前的原始消息和压缩后的摘要把它们输出到日志文件。这样一旦用户反馈你忘了什么我可以立刻 diff 出是哪一次压缩丢的信息。另外一个实用技巧在窗口区里混入一个当前任务状态占位符每轮由模型自己更新。比如【当前进度】已完成需求分析待确认预算范围。这样即使窗口滚动模型也能从状态占位符里迅速恢复上下文而不是依赖阅读全文。这是我在实践中验证过非常有效的做法。4.3 用评测集守住摘要质量摘要质量是 context-mode 的生命线。只靠肉眼检查根本不现实所以我后来专门建立了一个摘要评测集里面有 50 组容易产生事实偏移的对话。每组都有标准答案比如必须保留的关键决策必须保留的否定条件允许省略的寒暄内容。每次调整摘要指令或更换摘要模型我都会跑一遍这个评测集记录三个指标关键决策保留率标准答案中的决策是否都出现在摘要中事实错误率摘要中是否出现了与原始对话矛盾的内容信息密度摘要文本中有效信息占比是否合理。跑完评测集再上线上环境能挡掉大部分隐性回归。这个小步骤的成本并不高但对稳定性收益极大。你在接自己的项目时建议从第一天就留出时间做这件事。5. 我的调参经验与最终心得5.1 按场景推荐的一组配置上文那些参数是通用初值。真到具体项目我通常会做一轮针对性的微调。这里分享三个典型场景。智能客服/闲聊机器人。这类场景轮次极多但单轮信息量小。我建议用 window 模式window_size 可以放到 20-30 轮不启用摘要。因为闲聊的历史价值密度低摘要反而会多花 token还可能引入噪声。需求分析与项目管理助手。这种场景单轮信息量大且历史中的决策必须保留。我建议用 window summarywindow_size 控制在 8-12summary_trigger 控制在 4-6。摘要区必须显式记录已确认和待讨论两类信息这样后续轮次模型才知道什么能直接用、什么还需要追问。知识库问答助手。场景特点是历史相对独立主要靠检索。我建议用 retrieval 模式窗口只需要保留最近 2-3 轮把主要精力放在高质量切块和向量召回上。context-mode 在这里的目标不是记住全部而是准确定位。5.2 实测下来最值钱的三条经验第一条经验context-mode 的设计应该服务于用户体验而不是服务于技术指标。在优化 token 成本和控制延迟时不要牺牲掉用户明确需要的信息。有一次我把摘要间隔调得太激进token 省了 30%但用户满意度掉了 12%。后面调回来成本回到原来的 80%满意度也恢复了。这个平衡点需要拿数据说话不能拍脑袋。第二条经验要把摘要生成当成一等公民对待。很多人把摘要压缩当作一个简单的 prompt 拼接但它其实是整个 context-mode 里质量风险最高的环节。值得为它单独设计指令、单独做评测。摘要指令做得越具体模型就越不会自由发挥。比如我要求必须保留具体名称、数字、结论比笼统地说请总结一下稳定得多。第三条经验日志和可观测性一定要从第一天就加上。context-mode 的价值在于让系统有选择地记忆而记忆出错时用户很难定位。所以至少要记录三项数据每次拼接后的 token 分布、每次摘要的前后对比、每次模式切换的触发原因。有了这些日志用户说你记错了的时候你能在五分钟内给出明确答复而不是一脸懵。5.3 后续还能怎么扩展context-mode 这套思路并不局限在对话场景。我现在尝试把它扩展到两个方向。第一个方向是多智能体协作。每个智能体都有自己的上下文窗口同一个任务跨多个智能体流转时需要定义清晰的 context-mode 来传递任务目标和已完成进度而不是把整个对话历史打包带走。这样既能节省 token也能避免无关信息干扰下游智能体。第二个方向是流式日志分析。把系统运行时的关键事件切片成窗口超过阈值就生成摘要快照用于快速定位异常。这个思路本质上和 context-mode 一致保留最有价值的上下文舍弃无关的噪声。边界场景中它能帮你从海量日志里快速还原故障现场。我还给每个请求带上 context-mode 的标识在请求头里加一个自定义字段x-context-mode: windowsummary日志和监控都按这个维度聚合。后期做 A/B 测试非常方便也能随时切换策略验证效果。这个小习惯帮我省了很多排障时间。实际上到现在我还在持续调整 context-mode 的参数。每个项目的知识密度、交互风格、用户耐心都不一样不存在一套配置通吃所有场景。我个人的体会是先搭好可插拔的架构让模式可以随时切换再用真实用户数据去调参。只有把上下文管理当成一项持续演进的工程而不是一锤子买卖你的对话系统才能真正变得聪明起来。上面这套代码和参数是我在自己项目里反复打磨出来的希望能帮你少走几段弯路。