客服对话越聊越长，LangChain 可以留下近况、压缩较早上下文

客服助手聊了很多轮，用户刚补充一个新条件，模型却要带着之前每次查工具、改说法的长记录继续回答。对话越长，发送的上下文也越重。LangChain 的 SummarizationMiddleware，允许应用把较早信息总结成文本，同时保留最近几轮原始消息。

它值得看的地方，是把两个问题分开：什么时候应该总结，哪些近期内容仍要完整留下。开发者可以按业务选择，而不必等到模型报上下文过长，再临时丢掉历史。

保留近况，给旧对话换一种形态

官方中间件文档中，SummarizationMiddleware 接在 create_agent 上。它观察历史长度，到条件时总结较早内容，之后的模型请求继续使用摘要和保留的近期消息。

以客服产品为教学情境：较早轮次已经确定设备型号与问题背景，最近几轮则在核对新出现的报错。你可能希望前者成为简洁摘要，后者保留用户原话与刚返回的工具结果。真正需要设计的是“哪些信息会影响下一次判断”，而不是摘要字数越短越好。

官方把触发条件放在 trigger，把保留范围放在 keep。trigger 可以按 token、消息数量或上下文比例设置；keep 则指定保留多少近期消息或相应上下文范围。这两项各管一件事：启动总结的时机，与总结之后留下的近况。

中间件允许指定用于总结的模型，并提供 summary_prompt 自定义提示，其中包含待总结 messages 的位置。对具体产品，可以要求保留已确认事实、尚未解决的问题，以及用户最后提出的限制。

这些是教学性的设计方向，不意味着只要写进提示就能保证一项都不丢。业务上不可遗漏的订单状态、授权结果或已完成动作，应保存在程序的状态层；摘要适合给模型补语境，不适合充当唯一账本。

文档里的示例阈值也只是配置演示。不同任务的工具输出长度、用户消息密度与模型上下文都不同，不能把某个固定 token 数当成通用最优值。可以先查看真实会话在哪些位置开始变长，再决定触发与保留策略。

官方明确，这是一种面向文本的压缩，不会自动缩小图片、音频或视频。近期消息保留下来的多模态块仍是原始负载；较早多模态消息被总结时，留下的是文字摘要。

因此，截图很多的支持场景，不能指望一个摘要中间件同时解决所有传输与上下文问题。应用可以把媒体存到文件或对象存储，通过引用管理，同时保留真正需要模型看到的材料。

LangChain 仓库采用 MIT 许可，框架与 LangGraph、LangSmith 等产品层次有区别，模型服务也需另外配置。对于长期多轮对话，我会把这项能力当成一个可修改的上下文环节：旧材料怎样归纳，新材料保留多少，关键业务事实又在哪里独立保存。把这几项分清，长对话才更容易继续维护。