本地部署AI Agent老是被工具调用卡住，大家怎么解决上下文爆炸的？

我也遇到过一模一样的情况，7B做多步工具调用基本就是三四个来回后开始发癫。我后来直接把工具返回结果做了个结构化摘要，只保留关键字段，比如搜索就存标题加前200字，代码执行就存输出前500字符，然后强制让模型基于摘要输出，不把完整结果塞进去。

另外可以试试给每个工具调用单独开一个子对话窗口，最后只把结论传回主线程，这样主上下文就一直是干净的历史。不过说实话，如果任务链真得很长，7B的推理衰减还是明显，我换到14B的Qwen之后明显稳了一个档次，但显存压力也上来了，看你要不要折中。

7B做多步agent确实容易崩，我试过把工具结果先做一轮关键词提取再塞进上下文，比直接截断稳一些。另外把历史对话按轮次做衰减权重，太早的对话只保留动作和结果摘要，效果比让模型自己总结靠谱。你用的是单次完整对话还是分块存储？有时候切分策略比压缩算法更关键。

我这边用13B模型也有类似问题，后来改成每次工具调用后强制把原始返回清洗成结构化JSON，再让模型只基于结构化数据决策，上下文能少一半。但代码执行这类动态结果还是容易超，毕竟输出长度不可控。

7B做多步工具调用确实容易崩，我之前用4bit量化跑也这样。后来试了个笨办法，每轮只保留最近一次工具结果+原始query，把中间过程全丢给一个单独的summary buffer存着，效果比让LLM自己总结稳定点。你用的LangChain里有memory模块，但得自己控制写入时机，别啥都往对话里塞。另外搜索和代码执行的结果最好先结构化提取关键信息再拼回上下文，直接塞原始返回必炸。要是任务再复杂点，感觉真得上13B以上，或者试试拿7B做单步规划，多步流程用脚本硬编码控制流。

说实话我也踩过一模一样的坑，Qwen2.5-7B在长上下文下注意力衰减特别明显，尤其工具返回的JSON或者代码块一多，模型基本就“失忆”了。我自己试下来最有效的办法是给工具结果做“结构化摘要”，不是让LLM总结，而是用正则或者模板把关键字段提取出来，比如搜索就只留标题和前三行正文，代码执行就只保留输出尾部几百字符，效果比让它自己总结稳定得多。另外你可以试试把历史对话按轮次做滑动窗口，但别只按长度截，优先保留包含工具调用参数的轮次，那些往往是最关键的决策点。还有一个偏门但有用的技巧，给每轮工具结果前加一个明确的“当前任务状态”标签，比如“已获取资料，下一步需要编写脚本”，这样模型不容易跑偏。至于换大模型，我觉得7B做三步以上的工具链确实勉强，13B或带长上下文训练的量化版会好不少，但如果你硬件有限，先把摘要和窗口策略调好，很多问题能缓解一半。

7B做多步agent确实容易崩，我试过把工具结果先做个摘要再塞回上下文，比直接截断好点，但摘要本身也会丢细节。后来干脆改成每轮只保留最近一次工具输出的关键字段，历史对话全丢给一个单独的向量库做检索，效果勉强能撑到五六轮。不过说实话，本地跑7B想稳定多步调用，不如直接上14B量化版，省心太多。你用的LangChain自带memory组件试过没？有时候问题不在长度，是它把旧工具结果和新指令搞混了。

试试给工具结果单独建个滑动窗口，只保留最近一轮的完整输出，历史让它自动过期。

7B搞多步确实容易飘，我后来换8B的Qwen才稳了点，要不你先把工具调用拆成两条独立链路？

我最近也踩过这个坑，7B模型在长上下文下确实容易崩。试过把工具返回结果先做个摘要再塞回去，比直接截断好点，但摘要质量又依赖模型本身。后来干脆把历史对话按轮次加权，只保留最近两轮和跟当前任务相关的关键词，效果凑合。不过感觉这种硬规则还是治标不治本，工具结果本来就是结构化数据，让模型读一遍再总结，不如直接抽关键字段存成变量，需要时再拼进去。你试过把工具调用拆成独立子任务吗？每步只喂最小上下文，最后再汇总，可能比一直拖着整个历史跑更稳。

说实话7B做多轮工具调用确实容易崩，我试过在工具返回前先让模型生成一个“摘要+关键字段”的结构化缓存，比直接截断好用很多。另外你可以试试把工具结果单独存到一个固定长度的滑动窗口里，只把最近两轮完整保留，更早的用向量检索抽相关片段。这玩意儿本质上是记忆管理问题，跟模型大小关系没那么绝对，但7B对长上下文的注意力确实弱，实在不行就上RAG把历史“外置”掉。

说实话你这情况我太熟了，7B做多步工具调用基本就是卡在第三四轮这个坎上。我之前试过类似方案，最后发现上下文爆炸不光是长度问题，更多是模型对早期工具输出和当前目标之间的关联性丢失了，截断反而会加速它“失忆”。后来我换了个思路，不压缩历史，而是给每轮工具结果加一个“结构化摘要”的强制节点，让模型在调用下一步前必须用一两句话总结出关键信息，再把原始输出丢进一个单独的检索池里，需要时按相关性调出来。这个法子比让LLM自由总结稳定不少，代价是多一次推理开销，但至少不会疯。另外你那LangChain的Memory组件建议别直接用默认的ConversationBufferMemory，换成ConversationSummaryMemory加一个时间窗口，只保留最近两轮完整对话+更早的摘要，效果会好很多。至于7B行不行，我个人觉得单步工具调用它能扛住，多步确实勉强，Qwen2.5-7B在指令跟随上还行，但那种“把A结果融入B再推导C”的递归推理，它很容易把中间步骤的格式搞乱，你要是能上14B或者量化后的32B，差距是质变级别的。不过要是硬件有限，也可以试试把工具调用拆成更小的子agent，每个只干一件事，用外部队列管理状态，别让主模型扛所有历史。

说实话我之前用7B模型跑agent也撞过这堵墙，第三轮工具调用开始幻觉几乎是必然的，不是你的prompt问题。我后来试了个土办法，就是把工具返回结果强制压缩成结构化摘要，比如只保留关键数字、文件名和结论，而不是原始全文，这样上下文能省一半。但更核心的问题是，7B模型对“工具结果应该改变自身行为”这件事理解很弱，你截断了它反而更容易忽略。我建议你试试把历史对话按“意图-动作-结果”三段式重写，每轮只保留最近两次的工具调用，配合一个单独的短期记忆buffer，超过阈值就触发一次摘要，但摘要要带着原始时间戳和动作标签，不然模型分不清谁先谁后。另外LangChain自带的ConversationSummaryBufferMemory其实不好用，它总结得太抽象，我换成直接往prompt里塞“上一轮工具返回了X，你还没用它做Y”这种显式提醒，效果立竿见影。不过说真的，如果你预算允许，换8B或14B的Qwen，哪怕量化后，多步推理的稳定性会明显上台阶，7B真不是干这活的料。

说实话7B做多步agent确实有点勉强，我之前用8B模型跑类似的流程，第三轮工具调用后输出质量就明显下降，不是忽略结果就是开始编造内容。后来我试了个笨办法，把每轮工具返回的结果先做个摘要再塞回上下文，用个小一点的模型比如3B专门负责压缩，主模型只保留摘要和当前任务相关的那部分历史，效果比直接截断好一些，但也没质变。我觉得关键问题在于工具结果的格式太占token，比如搜索返回的长文本，其实真正有用的就那几句话，你可以试试用关键词抽取或者正则把核心信息先捞出来，再让主模型处理。还有个思路是给历史对话加个滑动窗口，但窗口外的信息一旦丢失就很难恢复，所以得设计好什么时候该总结、什么时候该硬截断。我自己后来换成了14B模型，虽然速度慢了点，但稳定性提升非常明显，至少不会在第三四轮就崩。你如果不想换模型，建议先排查是不是工具调用本身的问题，比如prompt里对工具返回的描述不够清晰，有时候模型不是被长上下文搞晕，而是根本分不清哪段是工具结果哪段是对话历史。

说实话你这情况我太熟了，之前我用7B模型跑类似流程的时候，第三轮开始模型就跟喝了假酒一样，连工具返回的JSON都读不进去。后来我干脆不用LangChain那套记忆，改成自己维护一个固定长度的环形缓冲区，只保留最近两轮的工具结果和最终结论，中间那些细节全丢，效果反而稳了不少。另外你试过把工具返回的内容先做一步抽取吗，比如搜索就只存标题和前三行摘要，代码执行就只存报错信息和输出尾部，这样能省下大量token。但说实话，7B模型对长上下文的注意力衰减确实是个物理瓶颈，我后来换成了Qwen2.5-14B的量化版，同样策略下能多撑两三轮。你要是就想在7B上凑合，试试给每个工具调用前加一句“根据以上信息”之类的显式指引，有时候能拉回注意力。还有个歪招，把历史对话分段压缩成伪代码风格的关键词列表，模型反而更买账，你可以试试看。

说实话你说的这个问题我太有同感了，7B模型做多步agent确实容易在第三四轮开始“失忆”，我甚至怀疑不是上下文爆炸，而是模型注意力在长文本里自己就涣散了。我试过把工具结果先做个摘要再塞回去，比如用个小的embedding模型算相似度，只保留跟当前任务最相关的几段，效果比让LLM自己总结稳定不少。不过有个坑是摘要本身也会占token，而且如果工具返回的是代码或结构化数据，硬压缩反而容易丢语法。我现在比较偏向给每个工具结果加个“保质期”，比如搜索内容用完后直接删掉，只留一个结论性的一行记录，代码执行结果则只保存最后的输出状态，这样能撑到五六轮。但说真的，如果你任务链经常超过五步，我建议要么上14B或更大的量化模型，要么干脆把流程拆成两个独立的agent，一个负责收集信息，一个负责执行，中间用文件或数据库传递状态，这样比硬塞在同一个上下文里靠谱得多。你试过用memory bank那种结构吗——就是固定分配一段“长期记忆”给关键信息，其他全丢——我感觉这个思路对7B特别友好，但实现起来有点折腾。

7B做多步工具调用确实容易崩，我试过在LangChain里给每轮工具结果加个摘要节点，只保留关键数字和结论，能多撑两轮但牺牲了细节。后来换成把历史对话按窗口切块，每块独立压缩成embedding存向量库，需要时再检索相关片段拼回去，比让模型自己总结稳定不少。不过说实话，如果任务链条超过五步，7B的指令跟随能力就是硬瓶颈，换14B或量化后的32B提升更明显。你用的是全量微调还是LoRA？说不定模型本身对工具调用的格式没学扎实。

试试只把工具返回的关键字段塞进上下文，历史对话用向量库做检索，7B确实撑不住全量。

我用的是双缓冲，工具结果单独存，模型只读摘要，感觉比截断靠谱。

7B做多步工具调用确实容易崩，我试过在中间步骤用向量库存工具返回的关键摘要，只把最新一轮完整对话塞给模型，效果比单纯截断好点。另外LangChain的ConversationTokenBufferMemory可以设个阈值，把最老的对话自动压成几个关键词，但得调好参数，不然关键指令会被吞。你那个让LLM自己总结的思路其实可行，就是得加个强制格式化的prompt，比如让它只输出“工具结果+下一步计划”，别让它自由发挥。

7B做多步工具调用确实容易崩，我试过在中间步骤直接把工具返回结果用一句话摘要替换掉，能撑到第五六轮。但摘要质量看模型心情，后来干脆给每个工具输出加了个“关键信息提取”的强制prompt，效果比让LLM自己总结历史稳定。你那个忽略工具结果的情况，也可能是LangChain的memory把工具返回值格式搞混了，检查下是不是把observation和thought拼一起传了。

说实话你这个情况我太懂了，7B做多步工具调用基本就是极限操作，上下文一长注意力一散，模型直接开始瞎编。我自己试过用Qwen2.5-7B跑类似的流程，后来发现问题的核心不是压缩策略，而是你喂给模型的内容结构太“平”了，它分不清哪些是工具返回的原数据、哪些是它自己该记住的决策链。我现在的做法是给每一轮工具调用结果单独做一层“信息蒸馏”，比如让模型输出一个固定格式的JSON，只保留关键数字、路径、结论，其他原始输出直接丢，这样上下文里全是精炼过的“记忆碎片”。另外你提到让LLM自己总结历史不稳定，那是因为总结本身也消耗token，而且7B在这种任务上总结能力本来就不行，不如用个更小的embedding模型或者简单的关键词去重逻辑，把历史按“意图-动作-结果”三元组存起来，每次只拉最近两轮加上当前请求。至于上不上大模型，我觉得如果预算允许，直接试试Qwen2.5-14B或者32B，量化后其实显存压力没想象中大，7B的推理深度做多步规划确实太勉强，那种“忽略工具返回结果”的情况大概率是模型根本没学会从长文本里提取关键信息，跟压缩策略关系不大。

说实话你这个情况太典型了，7B模型做多步工具调用就是会栽在上下文上，不是你的prompt写得不好，是模型本身的注意力窗口就那么点，塞进去一堆工具返回的JSON和代码片段之后，原始指令和中间推理早就被稀释得没影了。我之前试过用Qwen2.5-7B跑类似流程，也是第三轮开始发疯，后来干脆把工具结果做了硬性截断，比如搜索只保留前500字符，代码执行只保留输出尾部，然后强制在每轮工具调用前加一条“基于以上事实，请用一句话总结当前状态”的指令，效果会稳一些，但代价是复杂任务经常漏细节。你那个让LLM自己总结历史的思路方向对，但别让它自由发挥，得给定一个固定的总结模板，比如“已完成：xxx；待办：xxx；当前关键数据：xxx”，这样模型输出更可控。另外我试过用embedding做相似度召回历史，只把跟当前问题最相关的几轮对话塞回去，比全量塞进去强很多，不过要额外维护一个向量库，有点重。说实话，如果任务链条超过四步，7B基本就是极限了，要么把任务拆成多个独立agent用小模型分别处理，要么直接上14B或更大的量化模型，本地显存不够的话可以考虑用API兜底，别硬扛。

试试把工具结果先向量化检索再拼进prompt，7B模型真扛不住全量历史，省下的token留给关键步骤会稳很多。