1. 长会话为什么会“断片”以及摘要中间件到底在解决什么做过对话类应用的人大概率都遇到过这种场景用户跟你的 AI 助手聊了四五十轮前面明确说过“我预算八千、主要拍娃、不要单反”结果聊到后面推荐相机时它又开始给你推两万的全画幅或者干脆反问“请问您的预算是多少”。用户当场就炸了觉得这 AI 是不是失忆了。这不是模型笨这是上下文窗口和Token 预算的物理限制在作祟。大模型的上下文窗口是有限的早期模型 4K、8K现在主流也就 128K、200K看着挺大但你要知道Token 消耗是平方级增长的——每一轮对话都要把之前所有历史重新塞进去。聊到第 50 轮光历史记录可能就吃掉几万 Token成本飙升不说一旦超出窗口最早的内容就被直接截断丢弃于是“断片”就发生了。摘要中间件SummarizationMiddleware就是干这个的它不让你无脑地把全部历史塞给模型而是在对话变长时自动把早期的对话内容压缩成一段摘要用摘要替代原始历史从而在保留关键信息的前提下把 Token 用量压下来。LangChain 生态里这个组件是长会话场景的标配配合 LangGraph 做状态管理能实现“聊一百轮也不失忆、成本还可控”的效果。这篇文章适合三类人看一是正在用 LangChain 搭对话应用、被长会话 Token 问题折磨的开发者二是想搞明白摘要中间件内部机制、准备自己魔改的进阶玩家三是做工业智能体、客服机器人这类需要长期记忆场景的工程同学。我会从设计思路讲到实操代码再把我踩过的坑和参数调优经验都摊开说。2. 摘要中间件的整体设计思路与方案选型2.1 为什么是“摘要”而不是“截断”或“全量保留”处理长会话历史业内常见就三条路我做个对比你就明白为什么摘要中间件是更优解。方案做法优点致命问题全量保留每轮把完整历史塞进去信息零丢失Token 爆炸超窗即崩成本极高滑动窗口截断只保留最近 N 轮实现简单成本低早期关键信息永久丢失必然断片摘要压缩早期历史压成摘要近期保留原文信息保留与成本平衡实现稍复杂摘要质量依赖模型滑动窗口截断是最容易踩的坑。我见过不少项目图省事直接messages[-10:]结果用户第一轮说的核心需求全没了。摘要中间件的思路是近期对话保留原文保证细节和语气早期对话压缩成摘要保证关键事实不丢。这就像人开会你记不住每个人说的每句话但你会记住“上次会议定了 A 方案、预算 50 万、下周三交付”这种要点。2.2 触发时机什么时候该做摘要摘要不是每轮都做那样反而浪费。核心是设一个Token 阈值。常见做法是当历史消息的总 Token 数超过模型上下文窗口的某个比例比如 60%~70%时触发摘要。留出的那 30%~40% 是给当前对话、系统提示词和模型输出用的。这里有个参数计算的实际例子。假设你用某模型上下文窗口 128K Token你设置触发阈值 0.6那就是 76.8K Token 时触发摘要。摘要后目标压到多少一般压到触发阈值的 30%~50%也就是 23K~38K Token 左右。这样一次摘要能撑很多轮不会频繁触发。注意阈值别设太高。我试过设 0.9结果摘要还没做完加上系统提示词和输出预留直接超窗报错。0.6 到 0.7 是比较稳的区间。2.3 摘要保留多少、丢弃多少keep 与 summarize 的边界摘要中间件通常有两个关键参数keep保留最近多少条消息原文和触发阈值。keep设太小近期上下文细节丢失模型回答会变得笼统设太大摘要省下的 Token 又不够。我的经验值是keep保留最近 6~10 轮对话约 12~20 条消息。这个量级能覆盖大多数“指代消解”需求——用户说“就刚才那个”“换成第二个”模型能从前几轮找到指代对象。再往前的交给摘要。2.4 和 LangGraph 的配合状态怎么管单用 LangChain 的ConversationSummaryBufferMemory也能做但生产环境我更推荐LangGraph SummarizationMiddleware的组合。原因是 LangGraph 把对话状态显式建模成 State摘要逻辑作为图中的一个节点或中间件钩子可控性更强也方便做 human-in-the-loop、持久化、多轮分支。LangChain 和 LangGraph 的区别这里顺带说一句LangChain 偏“链式调用”适合线性流程LangGraph 偏“状态图”适合有循环、分支、需要长期维护状态的 Agent 场景。长会话摘要天然是状态管理问题所以 LangGraph 更合适。面试里也常问这个区别答“LangGraph 是 LangChain 之上做有状态编排的框架”基本就对了。3. 核心细节解析与实操要点3.1 摘要提示词怎么写才不丢关键信息摘要质量直接决定长会话会不会断片。很多人随便写个“请总结以上对话”结果摘要出来全是“用户询问了产品信息助手进行了回答”这种废话关键的数字、偏好、约束全没了。好的摘要提示词要结构化明确要求保留哪几类信息。我常用的模板是这样的SUMMARY_PROMPT 请将以下对话历史压缩成结构化摘要务必保留 1. 用户明确提出的硬性约束预算、时间、数量、禁忌 2. 用户表达过的偏好和倾向 3. 已经达成的结论或决定 4. 尚未解决的问题 5. 关键实体名称产品名、人名、地点 不要保留寒暄、重复确认、助手的长篇解释。 对话历史 {history} 结构化摘要这个模板的关键在于明确“保留什么”和“丢弃什么”。模型做摘要时如果没有明确指令倾向于保留“看起来重要”的礼貌性内容反而丢掉数字。我实测下来加上“硬性约束”“关键实体”这些词后摘要里数字和名称的保留率明显提升。3.2 Token 计数别用字符数估算Token 和字符数不是一回事。中文大概 1 个汉字 ≈ 1~2 个 Token英文 1 个单词 ≈ 1.3 个 Token代码和特殊符号更飘。用len(text)估算 Token 是新手最容易犯的错会导致阈值判断严重失准。正确做法是用对应模型的 tokenizer。LangChain 里可以用tiktokenOpenAI 系或模型自带的 tokenizer。如果你用的是国产模型很多也提供了 tokenizer 接口。实在没有用transformers的AutoTokenizer加载对应模型的分词器。import tiktoken def count_tokens(text: str, model: str gpt-4) - int: enc tiktoken.encoding_for_model(model) return len(enc.encode(text))提示如果你的应用混用多个模型Token 计数要按“最贵的那个”或“窗口最小的那个”来算否则切换模型时会翻车。3.3 摘要的“递归压缩”问题聊得特别久的时候摘要本身也会变长。比如聊了 200 轮第一次摘要 500 Token第二次把“旧摘要新对话”再摘要可能变成 800 Token越滚越大。这就是递归压缩膨胀。解决办法有两个一是摘要时对旧摘要也做压缩明确要求“在保留关键信息的前提下尽量精简目标 X Token 以内”二是设置摘要的硬上限超过就强制二次压缩。我在工业智能体项目里就遇到过这个一个客服机器人聊了三天摘要滚到 3000 Token最后加了个“摘要不得超过 800 Token超出则丢弃最不重要的细节”的约束才压住。3.4 摘要与原始消息的拼接顺序摘要生成后怎么和保留的近期消息拼给模型顺序很重要。正确顺序是系统提示词 → 历史摘要 → 近期原文消息 → 当前用户输入。摘要要放在近期消息之前并明确标注“以下是更早对话的摘要”让模型知道这是背景而非当前上下文。我见过有人把摘要放在最后结果模型把摘要当成了“用户刚说的话”回答完全跑偏。这个细节不注意调试半天都找不到原因。4. 实操过程与核心环节实现4.1 环境准备与依赖安装先把环境搭起来。LangChain 生态版本迭代快建议用较新的稳定版并且用虚拟环境隔离。conda create -n summary-mw python3.11 -y conda activate summary-mw pip install langchain langchain-core langgraph tiktoken如果你要用特定模型再装对应的 SDK。这里我用一个通用的 ChatModel 接口演示你替换成自己的模型即可。LangChain 安装时如果遇到依赖冲突优先保证langchain-core和langgraph版本匹配这俩是核心。4.2 定义对话状态与摘要中间件用 LangGraph 定义状态把消息列表和摘要都放进 State。from typing import Annotated, TypedDict from langgraph.graph.message import add_messages from langchain_core.messages import BaseMessage, SystemMessage class ChatState(TypedDict): messages: Annotated[list[BaseMessage], add_messages] summary: str # 累积的历史摘要add_messages是 LangGraph 提供的 reducer会自动把新消息追加到列表不用手动管理。summary字段单独存摘要和消息列表解耦方便控制。4.3 摘要触发与压缩的核心逻辑这是整个中间件的心脏。逻辑是每次准备调用模型前先算 Token超阈值就压缩。import tiktoken from langchain_core.messages import HumanMessage, AIMessage def count_tokens(text: str, model: str gpt-4) - int: enc tiktoken.encoding_for_model(model) return len(enc.encode(text)) def maybe_summarize(state: ChatState, llm, threshold: int 60000, keep_recent: int 12) - ChatState: messages state[messages] total sum(count_tokens(m.content) for m in messages) if total threshold: return state # 没超阈值不动 # 保留最近 keep_recent 条其余压缩 to_summarize messages[:-keep_recent] recent messages[-keep_recent:] history_text \n.join( f{用户 if isinstance(m, HumanMessage) else 助手}: {m.content} for m in to_summarize ) # 把旧摘要也纳入压缩范围 if state.get(summary): history_text f【已有摘要】{state[summary]}\n\n【新增对话】\n{history_text} prompt SUMMARY_PROMPT.format(historyhistory_text) new_summary llm.invoke([HumanMessage(contentprompt)]).content return {messages: recent, summary: new_summary}这段代码有几个关键点。第一to_summarize是除最近keep_recent条之外的所有消息包括之前已经摘要过的部分——通过把旧摘要拼进history_text实现递归压缩。第二返回时messages只留近期原文摘要单独存这样下次触发时不会重复压缩已经压过的内容。第三阈值 60000 是针对 128K 窗口的保守值你可以按自己模型调整。4.4 接入 LangGraph 主流程把摘要逻辑挂到图里在调用模型前执行。from langgraph.graph import StateGraph, END def build_graph(llm): graph StateGraph(ChatState) def summarize_node(state): return maybe_summarize(state, llm) def chat_node(state): # 拼接系统提示 摘要 近期消息 sys SystemMessage(content你是一个有长期记忆的助手。) context [] if state.get(summary): context.append(SystemMessage( contentf以下是更早对话的摘要\n{state[summary]} )) context.extend(state[messages]) resp llm.invoke([sys] context) return {messages: [resp]} graph.add_node(summarize, summarize_node) graph.add_node(chat, chat_node) graph.set_entry_point(summarize) graph.add_edge(summarize, chat) graph.add_edge(chat, END) return graph.compile()流程是每轮先过summarize节点判断要不要压缩再进chat节点生成回复。chat_node里拼接顺序严格遵循“系统提示 → 摘要 → 近期消息”这是前面强调过的关键细节。4.5 参数调优的实测记录我在一个客服场景里做过对比测试模型窗口 128K用户平均单轮输入 80 Token助手回复 200 Token。测试结果配置触发阈值keep_recent平均每轮 Token断片率无摘要--随轮数线性增长50 轮后超窗高激进压缩400006约 8000中近期细节丢平衡配置6000012约 15000低保守压缩8000020约 25000极低但成本高最后选了平衡配置。激进压缩虽然省钱但keep_recent6时用户说“第二个方案”模型经常找不到指代断片率反而上升。keep_recent12是个甜点值。5. 常见问题与排查技巧实录5.1 摘要后模型“失忆”了关键数字这是最高频的问题。原因通常是摘要提示词没强调保留数字或者摘要模型本身能力弱。排查步骤先把生成的摘要打印出来看如果摘要里就没数字那是提示词问题如果摘要里有但模型回答时没用那是拼接顺序或系统提示的问题。解决办法提示词里明确“所有数字必须原样保留”并且摘要用能力较强的模型做别用最便宜的那个。摘要是一次性成本值得用好模型。5.2 Token 计数和实际消耗对不上常见原因是用了错误的 tokenizer或者没算系统提示词和工具调用的 Token。排查时把每次请求的完整 payload 打出来逐段算。另外注意有些模型的计费 Token 和上下文 Token 口径不同以官方文档为准。5.3 摘要递归膨胀导致越压越大前面提过解决办法是给摘要设硬上限。在提示词里加“摘要总长度不得超过 800 Token”并在代码里做二次校验超了就再压一次。我一般会写个enforce_summary_limit函数兜底。5.4 多轮工具调用时摘要把工具结果也压没了Agent 场景里工具返回的结果比如查到的订单号、API 返回的 JSON如果被摘要压掉后续就没法用了。解决办法是对工具消息单独处理要么不压缩工具消息要么在摘要里明确保留“工具调用结论”。我在工业智能体项目里的做法是给工具结果打标记摘要时优先保留带标记的内容。5.5 常见问题速查表现象可能原因排查方向解决关键数字丢失摘要提示词未强调打印摘要内容提示词加“数字原样保留”指代消解失败keep_recent 太小检查保留条数调到 10~12摘要越滚越大递归膨胀看摘要 Token 趋势设摘要硬上限Token 超窗报错阈值设太高核对窗口与阈值阈值降到 0.6回答跑偏拼接顺序错检查消息顺序摘要放近期消息前工具结果丢失工具消息被压检查摘要是否含工具结论工具消息单独保留5.6 几个我踩过的坑第一个坑是摘要和消息列表双写。早期我把摘要也塞回 messages 列表结果下次压缩时摘要被当成普通消息又压一遍信息层层衰减。后来改成摘要单独字段存储才解决。第二个坑是异步场景下的竞态。高并发时多个请求同时触发摘要可能对同一段历史重复压缩。解决办法是加锁或把摘要做成独立的后台任务不阻塞主对话流。第三个坑是摘要语言漂移。用户用中文聊摘要模型有时输出英文摘要导致后续模型回答语言混乱。提示词里明确“用与对话相同的语言输出摘要”能解决。6. 进阶玩法让摘要中间件更聪明6.1 分层摘要短期、中期、长期记忆单一摘要不够用的时候可以做分层。近期对话保留原文短期中期对话压成详细摘要中期更早的压成一句话要点长期。这类似人脑的记忆分层实现上就是维护多个摘要字段按时间窗口滚动压缩。LangGraph 的状态图天然适合做这种分层每个层级一个节点。6.2 摘要 向量检索需要时再召回摘要会丢细节但有些细节后面可能突然要用。进阶做法是把被压缩的原始对话存进向量库摘要里保留“索引提示”当用户提到相关话题时用检索把原始细节召回。这就是 RAG 思路用在对话记忆上。基于 LangChain 的 RAG 流程做这个很顺Chroma 或类似向量库都行。6.3 摘要质量评估怎么知道压得好不好生产环境要有监控。我一般记录三个指标摘要压缩比压缩后 Token / 压缩前 Token、关键实体保留率摘要里是否含原始对话的关键名词和数字、断片率用户纠正“我之前说过”的频率。断片率是最直接的业务指标一旦上升就说明摘要策略要调。6.4 和 human-in-the-loop 结合有些关键决策不该被摘要模糊掉。用 LangGraph 做 human-in-the-loop 时可以在摘要节点后加个人工确认环节让运营人员审核摘要是否保留了关键信息。这在工业智能体、医疗咨询这类高要求场景很有必要。7. 一些参数选择的经验值汇总最后把我这些年攒下来的参数经验值整理一下你可以直接拿去当起点再按自己场景微调。参数推荐值说明触发阈值比例0.6~0.7占模型窗口比例keep_recent10~12 条约 5~6 轮对话摘要目标长度触发阈值的 30%~50%压缩后大小摘要硬上限800~1500 Token防递归膨胀摘要模型中等能力以上别用最便宜的摘要语言跟随对话语言提示词明确这套配置我在几个项目里跑下来长会话断片率能压到很低Token 成本相比全量保留能省 60% 以上。当然具体数字因场景而异关键是理解每个参数背后的权衡而不是照抄。摘要中间件这东西说穿了就是“用一次性的摘要成本换长期的上下文稳定”。它不复杂但细节多尤其是提示词、拼接顺序、递归压缩这几个点不注意就会踩坑。我个人的体会是先把基础版跑通再根据实际断片情况针对性调参比一上来就搞分层、搞向量召回要务实得多。等你把单层摘要玩明白了再往上叠进阶玩法心里才有底。