RAG里Agent调用多个工具时，上下文老是丢，怎么解决？

遇到过，这问题太典型了，AgentExecutor默认的memory只管对话历史，根本不管工具中间结果的拼接。你那个“查完销售额再查客户”的链条，本质是两步推理依赖，但LangChain默认把每次工具调用当成独立step，上下文只保留最后一条消息，前置结果自然就丢了。

我试过几个土办法，最靠谱的是自己维护一个临时变量池，比如在tool函数里把关键输出塞进一个全局dict，或者用一个自定义的CallbackHandler在每步结束后把结果强制注入到prompt模板里。还有个偷懒的招：把两个查询合并成一个tool，让Agent自己用SQL先查汇总再联表查客户，虽然丑但省事。

另外你检查下是不是用了ConversationBufferMemory，这玩意儿只管用户和AI的对话，工具内部的intermediate_steps根本没存进去。可以试试改用ConversationSummaryMemory，配合return_intermediate_steps=True，效果会好一些，但token消耗会变大。

还有个坑，有些模型对工具结果里的长文本特别容易“选择性遗忘”，特别是OpenAI的gpt-4-turbo，建议对工具返回做结构化压缩，比如只保留核心数值和名单，别把完整查询结果全塞回去。你现在用的什么模型？如果换Claude或者本地模型，行为可能完全不一样。

巧了，我上周刚踩完这个坑。你这个问题八成不是Memory的锅，而是AgentExecutor在中间步骤里对observation的处理方式导致的——它默认只把最终输出拼进下一轮prompt，中间工具返回的原始结果可能被截断或者压根没传进下一轮。我后来是直接把AgentExecutor换成LangGraph，把每个工具的输出显式存到state里，再手动控制下一步该读哪些字段，问题当场就没了。你要是暂时不想换框架，也可以试试在工具函数内部把返回结果顺便写进一个全局dict，然后在下个工具调用前强制把dict内容拼到prompt末尾，但这样确实比较hack。另外注意下工具返回的文本长度，如果超过模型上下文窗口，被静默丢弃也是常事，最好在工具里就做摘要。你用的是哪个模型？有些模型对多轮工具调用的指令遵循能力就是弱一些，换GPT-4或者Claude 3.5可能也会有改善。

我之前也踩过这个坑，LangChain的AgentExecutor在工具间传递上下文时确实有点“健忘”，主要是它默认只把当前这一步的observation塞给下一步，之前的结果如果没有显式塞回prompt，自然就丢了。你试过用ConversationBufferMemory，但那个更适合多轮对话，对工具调用的中间状态帮助不大，因为Agent的execution plan和memory是两套逻辑。我觉得最直接的办法是自己在agent的tools里维护一个全局的临时存储，比如用contextvars或者简单的dict，每个工具执行前把需要的历史结果作为参数传进去，然后返回时把关键信息追加到当前输入里。另一个思路是别依赖Agent自动拼接，改成手动控制流程：先调用第一个工具，拿到结果后，把结果格式化成一个临时“备忘”文本，再拼到第二次调用的user query里，相当于你把上下文硬编码进去。还有个小技巧，检查一下是不是用了ReAct的prompt模板，有时候输出解析器会把中间步骤截断，导致思考里虽然有但实际传给工具的参数没带上，可以在tool的description里明确要求“必须引用之前查询到的具体数值”。我后来干脆用LangGraph的StateGraph重写了流程，每个节点显式声明要读哪些state字段，再也没丢过，虽然代码量多了点，但比在AgentExecutor里折腾省心。你要是懒得重构，可以先试试把Memory换成Zep或者自写一个回调，在tool_start时把上次结果注入当前消息。

我之前也踩过这个坑，LangChain的AgentExecutor默认只把工具返回值塞进中间步骤，如果没开return_intermediate_steps或者没手动拼进下一轮prompt，第二次调用确实看不到前面的结果。你可以试试把每次工具输出显式追加到一个running summary里，再喂给下一轮。或者干脆换个思路，用LangGraph那种带状态的图结构，每个节点自己管理上下文，比硬怼Memory靠谱多了。

这个问题我踩过坑，大概率不是Memory的问题，而是AgentExecutor在多轮工具调用时中间结果没被正确塞回prompt。LangChain默认的scratchpad只保留有限的中间步骤，工具返回的内容如果太长或者被截断，下一轮LLM就看不到完整信息了。我之前也以为是Memory没配好，折腾半天换成ConversationBufferMemory都没用，后来发现根因在工具输出的处理上。建议你先把verbose打开，把每轮实际发给LLM的完整prompt打出来看，一眼就能定位是哪一步丢了。另外可以试试把第一个工具的返回结果显式写进state或者用return_direct之外的方式存到一个临时dict里，让第二个工具调用前手动拼进system或者human message，比依赖框架自动传递靠谱。如果用的是新版LangGraph会好很多，它本身就有state机制管理跨工具的数据流，比AgentExecutor那种黑盒拼接透明多了。

这个问题我踩过类似的坑，确实挺烦人的。LangChain的AgentExecutor在多轮工具调用时，中间结果默认不会自动带进下一轮的工具输入里，它只在最终生成回答时把scratchpad拼进去，所以你第二次调工具时看不到第一次的返回值很正常。Memory解决的是跨会话的对话历史，跟工具调用链里的中间态是两码事，别指望它。我当时的做法是自己维护一个running state，每次工具返回后手动塞进一个dict或者list里，再把它作为下一轮工具的部分输入传进去，或者直接在prompt模板里预留一个中间结果占位。另外可以看看LangGraph，它对这种多步状态流转的支持比AgentExecutor清楚很多，每个节点之间状态是显式传递的，不容易丢。如果非要用AgentExecutor，也可以试试把return_intermediate_steps打开，然后自己解析steps再回填。你这个场景其实挺典型的，先查数再查关系，本质上是需要把前一个工具的output当作后一个工具的context，靠框架自动串基本不靠谱，还是得自己管状态。

我一般把中间结果塞进一个临时变量再拼到prompt里，比靠Memory靠谱。

我是在工具回调里手动把上一步结果塞进prompt的，LangChain自带的memory对多工具场景确实不太灵。

你试试把工具返回结果手动塞进对话历史里，别光靠AgentExecutor自动拼，我踩过这坑。

我之前也踩过这个坑，LangChain的AgentExecutor默认每轮工具调用是独立的，中间结果不会自动塞回下一轮的prompt里。你可以试试用return_intermediate_steps=True把中间步骤拿出来，自己拼到下一轮的输入里。另外Memory那块要注意，它主要存的是对话历史，工具返回的原始结果不一定能进去。我现在是手动维护一个scratchpad变量，每次工具调用完就append进去，效果比单纯靠Memory稳很多。

我之前也踩过这个坑，跟你说个关键点：AgentExecutor每次tool调用其实是个独立的observation，默认只在单轮scratchpad里传递，跨工具的时候如果中间有LLM重新生成prompt，前面的结果很容易被截断或者没塞进去。你试的Memory大概率是对话级的，管不到工具调用链内部的中间结果。我的做法是在tool返回时手动把结果写进一个state dict，然后在后续tool的输入里显式引用，比如客户查询工具的参数里带上"已知销售额"字段。另外LangChain的return_intermediate_steps=True一定要开，不然你根本看不到丢在哪一步。还有个坑是有些模型对长context的中间部分注意力很弱，工具结果堆太多反而稀释了，可以考虑每步做个摘要再传。如果场景固定，其实用LangGraph自己画状态机比AgentExecutor可控得多，每个节点该带什么上下文一目了然。

有没有更详细的教程推荐？

学到了，感谢分享！

有没有更详细的教程推荐？

我之前也踩过这个坑，LangChain的AgentExecutor默认每次工具调用完只把最后一条observation塞回去，前面几轮的结果很容易被截断或覆盖。你可以试试在prompt里显式要求模型把关键中间结果记下来，或者自己包一层工具回调，把每次返回的摘要追加到一个scratchpad里再传回去。另外检查下max_iterations和early_stopping配置，有时候不是上下文丢了，是循环被提前掐了。