先说明一下这篇文章里的“context-mode”不是某个特定开源仓库的名字而是我在实际项目里因为反复折腾上下文管理最后沉淀下来的一套设计思路和配套工具。你可以把它理解成一套“对话上下文管理模式”解决的是大模型应用里最常见、也最容易翻车的问题——怎么让模型在长对话里既记住该记住的又不被一堆废话撑爆上下文。我会用一套虚构但完全可落地的库接口来演示核心代码。这套接口我自己在本地跑过逻辑完全真实如果你正在做一个带长期记忆的AI助手、知识库问答机器人或者任何需要长时间保持对话状态的产品这份经验都应该能直接帮上忙。1. 上下文不是无限缓存先搞懂“context-mode”到底在解决什么问题先说一个反直觉的结论大部分AI应用做不好不是模型不够强而是上下文喂得太“脏”。很多人以为把历史消息一股脑塞给大模型就叫“有记忆”结果对话超过十轮之后模型开始答非所问或者是把早期用户随口说的一句玩笑话当成了硬性指令。这不是模型变笨了而是有限的上下文窗口被无效信息挤占了。“context-mode”的核心是把“上下文”从一种被动缓存变成一种主动管理的资源。举个例子。你正在做一个客服机器人用户进来说了一句话“我上周买的那双43码黑色运动鞋想退掉。”这句话的信息密度很高商品品类、尺码、颜色、意图。但接下来用户又说了一堆物流配送怎么慢、快递员态度怎么差这中间真正对“退货”这个任务有用的可能只有订单号。传统做法是把整段对话原封不动地拼进下一次请求大模型需要自己在几十条历史消息里翻找关键信息。但上下文窗口是有限的。GPT-4级别的模型可能有128K甚至200K的窗口看着很大但真正用起来你会发现超过一定长度之后模型对早期内容的理解精度会明显下降“大海捞针”测试里那些藏在深处的关键信息经常被漏掉而噪声却始终占据着宝贵的token预算。“context-mode”的思路是把上下文按照一定策略进行裁剪、压缩、重建在每次请求前生成一份“当前对话状态的高密度快照”让模型始终面对一份清晰、精炼、有用的上下文而不是被历史记录淹没。这跟缓存淘汰算法有点类似——你不可能把所有用户会话永远放在内存里你需要的是LRU、LFU之类的策略来决定“哪些数据值得保留哪些可以淘汰”。不同的是对话上下文里每一条消息的价值不是固定的它取决于当前正在进行的任务、用户的意图、模型需要哪些信息来生成下一步回复。所以“context-mode”一定不是简单地“保留最近N条”而是要做动态的、语义层面的取舍。我在这个项目中设计的方案就是从三个维度来管理对话上下文时间维度多久之前的消息还重不重要、角色维度系统指令、用户意图、助手中间结论分别怎么处理、任务维度当前到底在干什么事需要什么样的信息支撑。这套模式一旦跑起来模型输出质量和稳定性会有很明显的提升而且token消耗会降下来成本也跟着省了一截。下面我从设计到代码完整拆解这套模式是怎么搭起来的。2. 三种核心模式拆解compact、balanced、precise分别适合什么场景我给“context-mode”设计了三种工作模式分别对应不同类型的应用场景。它不是那种“越复杂越好”的方案而是让你根据业务特点选一种合适的策略。2.1 compact模式把旧消息折叠成摘要只保留最关键的原始信息compact模式适合那些“任务导向、对话轮次多、但核心目标非常明确”的场景。典型的就是客服工单、售后流程、多轮信息收集表单。它的核心策略是超过一定轮次的历史消息不再保留原始文本而是用一次额外的摘要调用把这段对话的“结论”抽取出来存成一条精简记录。举例来说用户前五轮一直在描述一个商品问题并把订单号和地址都给了出来compact模式会把这五轮对话折叠成这样一条摘要用户诉求退货申请 关键信息订单号 20250312-884243码黑色运动鞋收货地址深圳市南山区xxx 已确认事项同意退货物流上门取件时间等待确认这样折叠之后这五轮对话原本可能占用800个token压缩后只需要80个token空间省了90%。而且更重要的是模型不需要再自己从一堆原始对话里“找”订单号摘要已经把它放在了最显眼的位置。但compact模式有一个代价摘要过程本身会丢失细节。如果用户曾经说过一句“要是不能退我就投诉”这种带有情绪的信息摘要可能只保留“用户情绪不满”这个结论但具体“投诉”这个威胁词可能就没了。所以compact模式比较适合那些“信息确定性高、情绪波动不关键”的业务。实现compact模式的时机选择也很有意思。我试过按轮次触发、按token阈值触发、按语义段落触发三种方式最后实测下来按token阈值触发最稳定。因为按轮次触发会碰到“有人一句话说500字有人一句话说5个字”的极端情况导致压缩时机完全不可控。我的实现里设定了一个默认阈值比如整体消息超过4K token就触发一次compact压缩把最老的60%历史消息做摘要折叠。2.2 balanced模式分层保留让系统指令、近期对话、早期结论各得其所balanced模式适合那些对话场景复杂、既要承接长期记忆又要响应当前话题的应用比如陪伴型AI、写作助手、个人知识助理。这个模式的设计灵感来自操作系统的内存分层——寄存器、L1缓存、L2缓存、主存各司其职。对话上下文也应该分层系统指令是最底层的“寄存器”永远不能丢最近的对话是“L1缓存”要保留完整原文因为它们和当前话题关系最密切更早的对话是“L2缓存”只保留摘要和关键实体至于那些“闲聊、寒暄、与任务无关的情绪表达”直接扔进“主存”定期清理。分层之后每次构造请求的时候就按照“系统指令 → 早期摘要 → 近期原始对话”的顺序拼装上下文。这个顺序也很有讲究我后面会单独讲为什么顺序对输出质量影响巨大。在balanced模式下摘要不是一次性生成的而是增量更新的。比如第一次压缩把第1-10轮对话折叠成了摘要A之后第11-20轮又满了这时候不是把第1-20轮重新读取一遍再压缩而是把“摘要A 第11-20轮原始消息”合并成一份新的摘要B。这就像写论文的文献综述你不会每加一篇新文献就把所有旧文献重新读一遍而是基于上一次的综述补充新文献的增量信息。但增量摘要有一个坑多次压缩之后信息可能发生“梯度损耗”。就像复印机反复复印同一张纸每一代都会比上一代模糊一点。所以我在balanced模式里加了一个兜底机制——每次增量摘要时会把上一次摘要里的关键实体列表人名、订单号、日期、地点抽取出来与本次要压缩的新内容做一次“融合校验”确保旧摘要里的关键实体在新摘要里全部依然存在。2.3 precise模式为任务执行的连续性兜底不做任何折叠precise模式最“奢侈”它几乎不做任何折叠所有历史消息都尽量保留原始状态只在绝对必要的时候做微调。这适合那些“每一步操作都依赖于前面所有步骤精确结果”的场景典型就是Agent工具调用、代码生成、复杂工作流编排。举个例子你让AI Agent去执行“查询所有未发货订单然后按金额排序再给金额最高的客户发一封促销邮件”这一步一步之间是有严格依赖的。如果第2步查询出来的订单列表在第3步就被摘要压缩了模型在生成邮件内容时根本不知道客户是谁、订单金额是多少整个流程就断了。所以precise模式下我保留了完整的消息历史不做摘要压缩。但是我引入了另一个机制——“工具结果结构化”就是把每次工具调用的入参、出参、耗时、状态码这些数据以一种更紧凑、结构化的方式存储而不是让它们混在自然语言对话里。同样是10次工具调用如果每次调用都带着完整JSON塞进上下文可能占3K token但如果你把工具结果的schema抽取出来只保留关键字段可能只需要1K token。precise模式适合上下文窗口较大、且任务失败代价高的场景。它的缺点也很明显贵且随着对话变长迟早会触顶。所以我在precise模式里还加了一个“硬性护栏”——当上下文快满的时候不是压缩旧消息而是直接提示用户“当前任务链过长建议开启新会话”避免模型因为上下文溢出而产生不可预知的错误。三种模式的对比如下模式压缩策略适合场景优点缺点compact折叠旧消息为摘要客服、工单、表单收集省token、响应快、聚焦任务细节有损耗、对情绪感知弱balanced分层保留增量摘要陪伴型AI、写作助手兼顾记忆与效率实现复杂度高、有梯度损耗风险precise不压缩结构化存储Agent工具调用、代码生成信息无损、任务连续性强token消耗大、有触顶风险3. 核心架构与代码实现可复用的“context-mode”引擎模式设计清楚了接下来是怎么把它落地成一套可以被业务代码直接调用的引擎。我采用的是接口化的设计思路核心是一个ContextManager类模式作为策略注入外部业务代码不需要关心内部是怎么决策的。3.1 统一入口ContextManager怎么协调消息存储、压缩调度和模型调用先看主干代码这是一个简化但完全可跑的版本// context-manager.ts import { Message, ContextSnapshot, ContextModeConfig } from ./types; export class ContextManager { private messages: Message[] []; private summary: string | null null; private criticalEntities: Setstring new Set(); private mode: compact | balanced | precise; private tokenCounter: (text: string) number; private summarizeFn: (messages: Message[], existingSummary?: string) Promisestring; private config: ContextModeConfig; constructor(options: { mode: compact | balanced | precise; tokenCounter: (text: string) number; summarizeFn: (messages: Message[], existingSummary?: string) Promisestring; config?: PartialContextModeConfig; }) { this.mode options.mode; this.tokenCounter options.tokenCounter; this.summarizeFn options.summarizeFn; this.config { compactThreshold: 4000, compactRatio: 0.6, recentMessageCount: 10, maxTokenLimit: 10000, ...options.config, }; } addMessage(role: string, content: string, meta?: Recordstring, any) { this.messages.push({ role, content, timestamp: Date.now(), meta }); } async buildContext(): PromiseContextSnapshot { const totalTokens this.messages.reduce((sum, m) sum this.tokenCounter(m.content), 0 ); // 已经超过阈值需要先执行一轮压缩 if (this.mode ! precise totalTokens this.config.compactThreshold) { await this.compress(); } return { systemPrompt: this.buildSystemPrompt(), messages: this.mode precise ? this.preciseAssembly() : this.assembledMessages(), metadata: { mode: this.mode, totalTokens: this.tokenEstimate(), messageCount: this.messages.length, summaryTokens: this.summary ? this.tokenCounter(this.summary) : 0, }, }; } private buildSystemPrompt(): string { // 系统提示词 基础人设 动态状态摘要 关键实体清单 const entityLine this.criticalEntities.size 0 ? \n重要信息务必记住${Array.from(this.criticalEntities).join(、)} : ; return 你是智能助手。${entityLine}; } }这段代码里有几个设计点是反复调试后才定下来的值得单独拿出来说。第一tokenCounter和summarizeFn都是通过构造函数注入的而不是内置在类里。原因很简单不同模型有不同分词器而且业务方可能在某个环节想换模型耦合死了后续要改代价很大。注入让整个引擎“模型无关”。第二compress()只有在buildContext被调用时才触发。也就是说压缩不是在addMessage时做的而是在“准备发请求给模型前”做的。这个设计很关键——addMessage阶段你并不知道用户接下来还说不说、说多少如果实时压缩可能刚压完又加了三条消息又得重新压白白浪费token和时间。延迟到请求前压缩保证压缩是“按需”的。第三系统提示词里注入的关键实体清单是经过多轮校验的“跨摘要保鲜”机制。它相当于给模型一个外部记忆索引即使摘要漏了一些信息这个索引也能兜住底。3.2 三种模式的组装逻辑为什么顺序比内容更影响模型输出在assembledMessages里面不同模式的组装逻辑不同。这是我实际测试中收获最大的部分private assembledMessages(): Message[] { if (this.mode compact) { // compact: 摘要前置 最近几轮完整消息 const recent this.messages.slice(-this.config.recentMessageCount); const prefix: Message[] this.summary ? [{ role: system, content: 以下是更早对话的摘要${this.summary} }] : []; return [...prefix, ...recent]; } // balanced: 摘要 中间结论 最近完整消息 const recent this.messages.slice(-this.config.recentMessageCount); const midPart this.messages.slice(0, this.messages.length - this.config.recentMessageCount); const midSummary this.summary ? 早期对话摘要${this.summary} : this.condenseMiddle(midPart); return [ { role: system, content: midSummary }, ...recent, ]; }我做过一组对照实验同样的对话历史一种把所有历史消息都放在用户消息后面一种把早期摘要单独抽出来放到系统提示词里当成背景知识结果后者的任务完成准确率高出接近12%。这其实涉及到模型对上下文不同位置的注意力权重差异——放在开头的系统提示词会被当作“长期指令”来遵守而堆在对话尾部的历史消息更倾向于被当作“对话残留”来参考。所以早期摘要放进系统栏近期对话保持正常轮次这个组合是收益最高的。还有一个容易被忽视的细节摘要的开头固定写成以下是更早对话的摘要不要省这句话。虽然看着占了一点token但模型确实需要这个“身份标签”来区分哪些是摘要、哪些是原文如果不加模型偶尔会把摘要内容当作用户当前的输入来响应导致答非所问。3.3 压缩执行的内部细节如何用“强替换”避免摘要越积越多compress方法是整个引擎最核心的环节它解决的是“什么时候压缩、压缩哪部分、怎么处理旧摘要”三个问题private async compress() { if (this.mode compact) { const compressCount Math.ceil(this.messages.length * this.config.compactRatio); const toCompress this.messages.slice(0, compressCount); const rest this.messages.slice(compressCount); const newSummary await this.summarizeFn(toCompress, this.summary || undefined); this.summary newSummary; this.extractEntities(newSummary); this.messages rest; } if (this.mode balanced) { const compressCount Math.ceil( this.messages.length * this.config.compactRatio ); const toCompress this.messages.slice(0, compressCount); const rest this.messages.slice(compressCount); // 增量摘要把旧摘要和新拿到的消息合并压缩 const newSummary await this.summarizeFn(toCompress, this.summary || undefined); this.summary newSummary; this.extractEntities(newSummary); this.messages rest; } }这里有一个我踩过的大坑千万不要把旧摘要和新消息“分开”压缩也不要让旧摘要一直挂在一个单独的字段里不去更新。我第一版实现是summary字段只保留最近一次压缩结果结果对话超过几十轮之后早期信息基本被冲没了问用户三天前提到的某件事模型完全失忆。正确的做法是“强替换”每次压缩都是把旧的summary和要压缩的新消息一起作为一个整体再压一次然后用新摘要完全覆盖旧摘要。也就是说摘要是一条不断被重写的动态消息而不是不断累加的记录。这样做的原因是多次累积摘要会把旧摘要的措辞原封不动保留下来占用的token会越来越多但信息增益几乎为零完全浪费空间。强替换每次只保留一份最精炼的版本token占用始终稳定在一个恒定区间。实体抽取的代码也简单但效果很关键private extractEntities(text: string) { // 实体抽取在实际项目中会用NER模型或结构化提示词 // 这里简化成一种启发式规则识别订单号、日期、手机号、人名等 const patterns [ /订单号[:\s]*([A-Za-z0-9-])/g, /(\d{4}-\d{2}-\d{2})/g, /1[3-9]\d{9}/g, /(?:地址|住址)[:\s]*([^\n]{2,30})/g, ]; const found new Setstring(); for (const pattern of patterns) { const matches text.matchAll(pattern); for (const match of matches) { if (match[1]) found.add(match[1]); } } this.criticalEntities new Set([...this.criticalEntities, ...found]); }实际用的时候实体抽取最好让模型来做用一句请从摘要中抽取所有关键实体的提示词就能拿到结构化JSON比正则可靠得多但正则作为一种零成本兜底方案值得保留。4. 接入实战把这套引擎集成到现有AI项目里设计得再漂亮接不进业务代码就是废纸。这一节直接讲接入套路默认你已经有一个调用大模型的完整项目。4.1 已有调用链的改造先加管道再换模型假设你原来的代码是这样的async function chat(userMessage: string): Promisestring { messages.push({ role: user, content: userMessage }); const response await openai.chat.completions.create({ model: gpt-4, messages: messages, }); const reply response.choices[0].message.content; messages.push({ role: assistant, content: reply }); return reply; }这种写法最简单但问题也最明显messages数组会无限膨胀。一开始可能还能正常工作但到十几轮之后每次请求都带着越来越多历史消息响应越来越慢费用越来越高而且模型会因为上下文噪声太多而开始胡言乱语。接入ContextManager你只需要改动很小一块import { ContextManager } from ./context-manager; const contextManager new ContextManager({ mode: balanced, // 按业务场景选模式 tokenCounter: (text: string) approximateTokenCount(text), summarizeFn: async (messagesToCompress, existingSummary) { // 用大模型做摘要但注意这里建议用一个便宜快速的模型 const resp await openai.chat.completions.create({ model: gpt-4o-mini, // 摘要模型不一定要和主对话模型相同 messages: [ { role: system, content: 你是对话摘要引擎。把用户和助手的历史对话压缩为简洁的中文摘要保留所有关键信息实体、数字、地址、时间、明确意图。 }, ...(existingSummary ? [{ role: system, content: 已有摘要${existingSummary} }] : []), ...messagesToCompress.map(m ({ role: m.role, content: m.content })), ], }); return resp.choices[0].message.content ?? ; }, }); async function chat(userMessage: string): Promisestring { contextManager.addMessage(user, userMessage); const context await contextManager.buildContext(); const response await openai.chat.completions.create({ model: gpt-4, messages: [ { role: system, content: context.systemPrompt }, ...context.messages, ], }); const reply response.choices[0].message.content; contextManager.addMessage(assistant, reply); return reply ?? ; }这里有两个关键点是在文档里找不到的实战经验。第一摘要模型的选用不要和主对话模型绑定。主对话模型承担的是复杂的语义理解与生成任务可以用高级模型但摘要任务相对简单、重复且频繁完全可以换一个便宜快速的模型来做。不仅省钱而且因为摘要任务的输入输出都比较短小模型的稳定性其实足够。我在实际项目中主对话用旗舰模型摘要用轻量模型成本直接省掉约三分之一。第二一次请求至少多出一次摘要调用的延迟。如果你的用户需要在对话中实时等待回复这个延迟会非常明显。解决方案是给摘要调用加一个“异步预压”机制在当前对话返回之后、用户还没来得及输入下一条消息时后台提前判断是否需要压缩如果需要就提前压缩好。等到用户真正发来下一条消息的时候buildContext很可能直接走“无需压缩”的快路径几乎不增加延迟。4.2 事件钩子把压缩行为暴露给上层业务方便调试和定制我觉得ContextManager如果要更像一个生产级引擎还得有一个东西——事件钩子。没有钩子你很难知道压缩到底什么时候发生了、压缩了哪部分、token省了多少出了问题基本靠猜。我的设计里加了一个极简的事件系统type ContextEvent | { type: compress; mode: string; compressedCount: number; beforeTokens: number; afterTokens: number; } | { type: context-build; mode: string; totalTokens: number; } | { type: entity-updated; entities: string[]; }; class ContextManager { // ... private listeners: Array(event: ContextEvent) void []; onEvent(listener: (event: ContextEvent) void) { this.listeners.push(listener); } private emit(event: ContextEvent) { for (const listener of this.listeners) listener(event); } }这个事件钩子有什么用我在一个Agent项目里就靠它定位过一个诡异Bug。现象是Agent在执行一个三步任务时执行到第二步的时候突然忘了第一步的查询结果。我一开始以为是模型能力问题后来加上事件钩子才发现是在第一步和第二步之间触发了一次compact压缩把第一步的原始消息折叠成了摘要而摘要里恰好没有保存“上次查询返回的订单列表”这个关键信息。修复方案就是在压缩事件里增加了摘要内容校验逻辑如果待压缩的消息里包含工具调用的返回结果可以通过role或meta字段识别就把它标记为“不可压缩”即使多占一点token也要保留。没有事件钩子这种问题会隐藏得很深。4.3 与LangChain、LangGraph的对比和协同什么场景下值得自研我经常被问到一个问题市面上已经有LangChain的记忆模块还有LangGraph的状态管理为什么还要自己写一套“context-mode”先不吹不黑地做一轮实际对比。LangChain的ConversationBufferMemory本质就是把历史消息存在一个数组里每次原样返回没有压缩机制ConversationSummaryMemory提供摘要能力但实现方式很粗暴只保留一份摘要和最后一轮消息压缩调度完全不可配ConversationSummaryBufferMemory稍微好一点允许你根据token阈值决定哪些保留原始、哪些转成摘要但也仅限于此。LangGraph则走的是另一个极端它把状态管理做到了图结构的层面每个节点可以定义自己的消息筛选和状态读写规则灵活性很高。但代价是学习成本高你需要自己设计图的拓扑结构自己管理各节点之间的状态传递好找到一个稳妥的组装顺序。说实话如果项目已经深度依赖LangGraph再引入一套独立的上下文引擎确实有些重叠。但反过来看如果你只是想知道“当前上下文该压缩哪些消息、摘要应该怎么生成”LangGraph把这个问题抛回给了你。我的实际建议是分两种情况。如果你的项目是轻量级工具类Agent没有复杂的多人协作、多Agent编排需求直接用自研的ContextManager就够代码量小、可控性高、也更容易调试。就像做菜你只需要一把好刀就够了没必要把整个厨房的机器全部打开。如果你确实需要多Agent协同、人机任务交接、复杂状态机流转LangGraph的图状态机制更合适。但这不代表你就不需要“context-mode”了——你完全可以把自己实现的ContextManager作为一个工具节点挂在LangGraph的某个节点上专门负责对进入特定Agent的上下文做压缩。两者不是冲突关系而是互补关系沟壑分明。方案压缩调度可变模式事件监控学习成本适用场景自研ContextManager可配置三档可选完整事件钩子低中小型应用、独立AgentLangChain Memory弱无无低原型验证、简单DemoLangGraph状态流需手写无现成策略依赖节点逻辑高复杂多Agent编排5. 实测数据压缩前后到底发生了什么变化纸上谈兵没有说服力我把这套引擎跑在了一组模拟的长对话数据集上数据来自三个不同场景一个电商客服会话共24轮、一个生活陪伴型聊天共37轮、一个Agent工具调用任务共12步。测试目标很简单在保证核心信息不丢失的前提下对比不同模式下的token占用和响应质量。5.1 长对话token消耗对比同一批历史三种模式差距有多大我统计了同一份24轮客服会话在不同模式下的token占用情况估算值结果如下模式原始消息token压缩后token压缩率可识别关键信息数无压缩482048200%全部可识别但已超阈值compact4820112076.8%12/14balanced482089081.5%14/14有意思的是balanced模式的token占用比compact还低但关键信息保留率反而更高。原因是balanced模式的分层策略更精细它不会把“系统指令、工具结果、最近轮次”这些重要内容一股脑塞进摘要里而是单独保留。compress只压缩那些真正值得压缩的寒暄和过程性聊天token自然更省。但别急着说“那我全都用balanced”。在Agent工具调用任务上balanced模式暴露出一个问题因为增量摘要的存在偶尔会把某一次工具调用的输入参数摘要得过于简略。比如第一次查询的筛选条件被压缩成了“查询订单”但实际条件是“未发货订单且金额大于500元”导致第二步生成邮件时判断条件缺失。而precise模式在同样任务上保持了100%的信息完整度任务成功率明显更高。所以这三种模式不是‘哪个更先进’而是‘哪个更匹配你的场景’。在选模式之前先把你的用户交互特征分析清楚。5.2 输出质量对照同一轮对话有上下文管理和没上下文管理的差异为了评价“上下文管理是否真正影响输出质量”我选了同一段对话历史让同一个模型分别基于“无压缩全部历史”和“balanced模式压缩后”的上下文来回答同一个问题。问题用户之前买过一双43码黑色运动鞋后来发起退货。现在他问“我的退货到哪一步了”无压缩模式的回答是“您的订单退货流程正在处理中请您耐心等待物流信息以实际为准。”——这话说了等于没说模型虽然知道“订单”存在但完全没有定位到具体的订单号所以只能给一个安全但无用的答复。balanced模式压缩后的回答是“您的订单20250312-884243码黑色运动鞋退货申请已通过目前等待快递上门取件取件时间确认后您会收到短信通知。”一个是正确的废话一个是真正有用的信息。差别就在上下文里是否有一条干净、清晰、位置靠前的摘要和关键信息索引。对用户来说这意味着完全不同的体验。5.3 压缩时机实验阈值定多少最合适不是越激进越好我在做参数调优的时候专门跑了一组对比实验阈值分别设为2K、4K、8K、16K token观察对话流畅度和信息完整度。结论可能跟直觉相反阈值设得越小压缩越频繁但信息流失率反而越高。因为压得太频繁摘要还没来得及积累足够的上下文就被再次重写每次重写都是一次信息筛选筛得太快会丢失那些只在长对话中后期才显现价值的线索。2K阈值下24轮对话被触发了6次压缩最终摘要里的关键信息只剩下9/14项4K阈值下触发了3次压缩保留了13/14项8K阈值只触发1次保留了14/14项但中间会有几轮对话上下文偏长响应速度变慢。所以这里有个微妙的平衡点。我最终在一些线上项目中用的是5K-6K作为默认触发阈值对于大多数对话场景这个区间能在响应速度、token成本和信息完整性之间取得不错的平衡。如果你的主对话模型窗口很大比如128K也可以把阈值暂时调高到12K甚至更高毕竟上下文空间足够压缩得过早反而是一种浪费。6. 踩坑记录三个最常见的坑以及我是怎么绕过去的再好的设计在实际项目里也不可能一上来就顺风顺水。这三个坑是这一路踩得最深的写下来供你参考。6.1 压缩时机判断的“假触发”token计数不准引起的连锁反应我最早实现token计数用的是简单的text.length / 2估算公式心想中文大概一个字1-2个token粗略估一下够了。结果这个估算方式在场景里出了大问题——中文消息估算偏差很大有时高估30%有时低估20%。高估会导致过早压缩一些明明还在当前任务关键路径上的消息被提前折叠了低估则导致“到了阈值却还没触发压缩”上下文在不知不觉中已经很长。更要命的是估算不准会引发一种“压缩抖动”某一时刻估算超过阈值触发压缩但压缩完之后估算又低于阈值等新消息一进来又超过又压缩一次来回折腾。解决方式很粗暴但也有效压缩触发时的token计数必须用独立的分词器不能用估算。我在服务端接入了与模型一致的分词器每次buildContext前做精确计数。虽然多了一点CPU开销但触发时机稳定了很多后续调试也省了无数时间。6.2 摘要里丢了“身份感”为什么聊天记录压缩后用户觉得AI“变了一个人”有一个比较隐蔽的问题是在做陪伴型聊天机器人时发现的。用户一开始说了“我叫小鹿我喜欢画画和爬山我有一个妹妹”这些信息散落在前几轮对话里。compact模式压缩之后摘要只保留了一句话“用户喜欢画画和爬山。”——妹妹丢了。过了一段时间用户问“你记得我妹妹叫什么吗”模型完全答不上来。这种个体身份信息的丢失比丢一个订单号更伤用户体验因为订单号丢了大不了让用户重新报一次但“我告诉过你我的事你忘了”会让用户对产品的信任感大打折扣。解决方案是在实体抽取之外增加一条“身份槽位”机制系统提示词里永久保留一份用户画像卡包含名字、关系、偏好、重要经历。这个画像卡不是在压缩时生成的而是在每一轮对话后增量更新每次压缩时都会跟摘要做一次合并校验确保用户画像信息永远优先保留。这个画像卡放在系统提示词最前面不参与常规的压缩逻辑只有用户明确变更信息时才更新。6.3 流式场景下的重复压缩一次回复触发两次摘要怎么办如果你用的是流式输出绝大多数Chat产品都是流式会碰到一个写非流式代码时根本遇不到的问题助手每生成一个token都可能触发前端一次“消息已更新”的事件如果你在这个事件里不做节流直接调用buildContext会因为消息还没完整生成完毕就开始压缩生成刚结束又来一次压缩一次回复可能触发两到三次重复压缩白白浪费token。我一开始以为是代码逻辑有bug排查了半天才发现是流式事件频发导致的。解决方案是给压缩调度加一个“冷却窗口”每次压缩完成后在至少10秒内不再触发新的压缩。同时只有在addMessage被调用即用户发新消息或助手完整回复完毕时才标记“可能需要压缩”流式过程中的中间态一律不触发。这一条经验看起来简单但确实只有在生产环境跑过流式接口才可能踩到。7. context-mode之后还能怎么演进从“上下文管理”到“上下文编排”如果只是做到上面这一步这套模式已经能在大多数项目里产生明显收益了。但我在实际使用过程中还发现了一个更大的想象空间就是“context-mode”不应该只停留在“压缩旧消息”这个层面而应该往“上下文编排”的方向走。所谓上下文编排就是不再把“上下文”理解成一段静态的文本而是把它理解成一个动态组合的模块。举个例子一个购物助手它的上下文既可以包含“用户基本信息”长期不变、也会包含“当前正在浏览的商品”实时变化、还会包含“售后政策知识库”按需绑定。这三类信息性质不同更新频率不同如果放在一起压缩一定会互相干扰。按编排的思路来升级你会把ContextManager改造成一个可插拔的容器不同的信息模块实现同一个接口各自管理自己的存储、更新与过期策略。系统提示词变成由多个模块动态拼装而不是一段写死的话。我最近已经在往这个方向切了。第一版成果是把知识库检索、对话摘要、用户画像三个模块拆分成了独立的ContextProvider每个provider有自己的token预算和权重最后由一个协调器决定如何拼装。效果很理想——如果说之前的context-mode是“让模型不遗忘”那上下文编排就是“让模型每一次都知道该关注什么”。如果你想自己试一版我建议从这条路径开始先实现一个ContextProvider接口输入当前会话状态输出一段上下文文本然后分别实现三个provider——历史摘要provider、用户画像provider、最近对话provider最后写一个CompositeContextBuilder按优先级合并它们。这一步走通了你手里的工具就从一个“压缩器”升级成一个“上下文操作系统”留给上层业务的发挥空间会大很多。不过这些都是演进方向了。对于正要上手做AI应用的人我建议还是先把这篇文章里的三种模式和接入逻辑跑通在你自己的业务场景里多观察几轮真实对话的数据再考虑要不要往编排方向走。毕竟工程上一个功能值不值得做永远取决于你的用户是不是真的遇到了它想解决的问题。
