用LangChain搭的Agent跑完就崩，是上下文管理姿势不对吗？

5轮就乱套大概率不是BufferWindow没设好，而是你每轮把retriever召回的文档也塞进history里了，这样token膨胀得飞快，模型注意力全被旧文档带跑。我之前也踩过这个坑，后来把检索结果和对话历史彻底分开存，history只保留纯对话文本，召回内容每轮重新拼，效果好很多。另外GPT-4o-mini对长上下文的中间部分本来就容易丢信息，你可以在prompt里显式要求它先复述当前问题再回答，能压住一部分答非所问。记忆裁剪我建议先别急着上LangGraph，手写一个按token数截断的逻辑就够用了，把最近两三轮的完整对话留着，更早的做摘要压缩成一句话塞回去。真要跑到20轮以上还稳，checkpoint机制确实更靠谱，但它解决的是状态持久化，不解决注意力分散，两者不是一回事。你可以先拿LangSmith把每轮的prompt打出来看看，八成能一眼看出问题出在哪。

我踩过一模一样的坑，后来发现光调Memory窗口大小没用，检索回来的文档块才是罪魁祸首，几轮下来塞进去的chunk把上下文撑爆了。我的做法是每轮只保留最近两轮原文，更早的让模型自己压缩成一句摘要再存，比无脑截断稳很多。LangGraph的checkpoint适合多步工具调用场景，单纯问答Agent有点杀鸡用牛刀了，先试试摘要压缩加检索结果去重，20轮基本能扛住。

5轮就崩大概率是history全塞system里了，试试用LangGraph的checkpoint加摘要压缩，20轮稳得很。

五轮就崩大概率不是memory的锅，而是你每轮都把全量history塞进system prompt，token一长模型就开始抓不住重点。我一般用window加summary的组合，近期几轮保留原文，更早的压缩成一段摘要，比单纯裁剪稳很多。LangGraph的checkpoint更适合做跨会话持久化，单纯跑20轮对话其实没必要上，先把prompt结构和检索结果的位置理顺更实际。

试试把历史摘要和检索结果分开塞，别全堆system里，LangGraph的checkpoint挺稳的。

我之前也遇到过类似问题，后来换了方案。

这个思路不错，收藏了。

写得挺好，建议补充一些性能数据。

五轮就崩基本可以锁定是history膨胀把prompt挤爆了，BufferWindowMemory的k值设太大跟没裁一样。我现在的做法是history只保留最近两三轮原文，更早的让模型压缩成一句话摘要挂到system里，再配个token计数超阈值就强制触发裁剪。另外检索那块也得看看，多轮之后query被历史污染，召回的东西越来越偏，答非所问往往是这个原因不是记忆本身。想稳跑20轮的话可以试试LangGraph的checkpoint，状态和消息分开管，比手写裁剪省心不少。

5轮就崩不太像是单纯memory窗口没设好的问题，BufferWindowMemory默认k=5，理论上不至于这么快乱套——更可能是每轮把retrieved chunks也一起塞进history了，token一多模型就开始丢前面的指令，尤其是system prompt被挤到后面去。我之前踩过这个坑，后来改成history里只存user和assistant的纯对话文本，检索到的文档每轮单独拼在最新一条消息前面，不写回memory，5轮到20轮的稳定性差别很明显。另外答非所问也可能是retriever本身在多轮改写query时没跟上，追问里的指代没被resolve，查出来的东西就不对了，建议先打个日志看看每轮实际送进LLM的完整prompt长啥样，大概率一眼就能看出问题。记忆裁剪我手写过一版，就是超token就丢最老的轮次、但保留第一条system约束和最近两条，够用但维护起来烦。现在更推荐LangGraph的checkpoint，配合trim_messages做裁剪，20轮基本无压力，还能顺便做持久化恢复。长期记忆那块不用急着上，先把短期窗口和检索query改写这两块理顺，效果提升比换框架大得多。

我之前也踩过这个坑，5轮就崩大概率不是memory参数的问题，而是你把整段history塞进system prompt之后，模型注意力被稀释了，越往后越容易忽略检索到的文档内容。ConversationBufferWindowMemory只按条数截断，不看语义，裁掉的往往是有用的上下文，留下的可能是寒暄。我后来改成只保留最近两轮原文，更早的用一个小模型压缩成一句摘要，效果稳定不少。另外你那个retriever每次拼prompt时最好把文档块放在history前面，让模型先看到证据再读对话，答非所问会少很多。LangGraph的checkpoint机制确实好用，但它解决的是状态持久化，不负责记忆裁剪逻辑，别指望换个框架就自动稳。20轮不崩的关键我觉得是给每轮加个token预算，超了就触发摘要，别等爆了再补救。

5轮就崩大概率不是模型问题是history塞太满了，BufferWindowMemory默认按条数截断，但每轮要是带retriever的chunk，token很快就炸了。我之前也踩过这坑，后来改成按token预算裁剪history，再加一层对retrieved chunks的去重和压缩，效果立竿见影。20轮稳定跑的话确实推荐上LangGraph的checkpoint，短期窗口加长期摘要分开管，比手写裁剪省心多了。

试试把history结构化成role-based messages而不是拼进system prompt，5轮就崩大概率是拼接位置把system挤后面了。我这边跑20轮的做法是window memory设k=4加摘要压缩老对话，LangGraph的checkpoint更适合多节点状态管理，单链问答用不上。另外retriever每次返回的chunk记得去重，重复输出有时是检索层的问题不是记忆层。