用LangChain搭Agent，工具调用时上下文总丢，大佬们怎么解决的？

这问题太典型了，AgentExecutor默认确实不会把工具输出塞回memory，你加chat_history只管了对话轮次，管不到工具内部状态。我之前也卡这，后来是直接在tool的return里手动拼接结果，再作为observation传回给LLM重新组织语言，才勉强能用。不过说实话，LangChain这块设计挺反直觉的，建议你直接看下AgentExecutor的源码里_call方法，工具输出其实会被覆盖，不保留历史。你试试在每次工具调用后，把输出手动append到prompt的system消息里，别依赖memory组件，这个方案最稳。

这问题太典型了，我刚入坑LangChain那会儿也被坑过。AgentExecutor默认确实不会把工具输出自动塞进下一轮对话的上下文，它只保留当前step的observation，所以你加memory存的是用户和AI的对话历史，但工具返回结果不在里头。我后来是自己在工具函数里把返回结果主动append到memory的chat_memory里，或者用LangChain的ConversationBufferMemory配合一个自定义的callback，在tool_end事件里把输出写进去。还有个更省事的办法是把工具返回的结构设计成包含“summary + raw data”的格式，然后在prompt里强制要求Agent每轮先检查memory里是否有相关记录再决定要不要调工具。不过说实话，这么折腾几次后我反而觉得不如直接用CrewAI或者自己写个简单的状态机，LangChain的抽象层太厚，调试起来真要命。你试试在AgentExecutor的verbose=True模式下跑一遍，看看中间到底有没有把工具输出传给LLM，大概率是prompt里没明确告诉它“你可以引用之前工具调用的结果”。

我之前也踩过这坑，试试把工具结果手动塞进prompt的system里，别只靠chat_history。

这问题我当初也踩过坑，AgentExecutor默认确实不会把工具输出自动塞回对话上下文，你得自己在tool的return里把结果拼进observation，或者用langchain的AgentFinisher手动处理。我之前是重写了Agent的plan逻辑，把每次工具调用后的关键结果提取出来存到memory的buffer里，再配合prompt里强调“优先用已有信息回答”才解决。你可以试试用ConversationBufferWindowMemory加个k值，同时把工具返回的大结构截断成摘要再存，不然token一长照样丢。

这个问题我踩坑踩了快两周才搞明白，LangChain的AgentExecutor确实默认不把工具输出塞进chat_history，它只保留最终的observation，而且很多memory实现只记录用户和AI的对话，不会自动把中间工具结果拼进去。我当时是直接在prompt里手动把工具返回的关键字段提取出来，然后拼成一段“已知信息”塞回system prompt里，比如每次工具调用后都更新一个全局变量存结果，下一轮对话开头强制注入。你试试重写一下memory的save_context，把agent的intermediate_steps也写进去，或者干脆不用AgentExecutor，自己写个循环用langchain的create_react_agent，每一步都手动维护上下文。还有个小坑，如果你用了带function call的模型，tools的返回最好格式化成一两句摘要，别直接堆原始JSON，不然token一长注意力就散了。我后来是写了个自定义回调，每次工具结束后把输出精简成“工具X返回了Y”这种固定格式追加到messages里，目前跑多轮基本不丢了。你也检查下是不是memory的max_token_limit设小了，有时候不是没存而是被截断了。

这问题我当初也踩过，LangChain的AgentExecutor确实不会自动把工具输出塞进chat_history，它只保留最终的response。你加memory的方向没错，但得把工具结果显式写进prompt的上下文里，比如在自定义的agent里手动把observation拼到中间步骤里。我之前用ConversationBufferMemory配合agent的scratchpad，把每次工具调用的输入输出都append进去，效果就好多了。不过更省事的办法是直接用langchain的create_react_agent，把memory接到它的prompt模板里，工具结果会作为Observation保留。你试过把tool的return_direct设成True吗？那样能强制把结果直接返回给用户，不走推理循环，但多轮复用还是得靠memory。另外，如果用的是新版的langgraph，那AgentState里的messages才是关键，得确保工具输出被保存成ToolMessage，而不是只放在中间变量里。你贴下你的agent配置代码，我看看是不是哪里漏了。

这问题太典型了，我当初也被坑过一轮。AgentExecutor默认确实不会把工具输出塞进chat_history，它只保留给LLM看的中间步骤，但那个是临时的，多轮一过就没了。你加了memory但没指定把tool result也写进去，等于白加。我现在的做法是自定义个回调，在tool执行完把结果强制append到memory的messages里，格式跟assistant回复一样，这样下一轮LLM才能看到。另外你那个“刚才那个订单”的场景，光靠memory还不够，最好在prompt里明确让Agent先查历史再决定调不调工具，不然它可能觉得重新查更“安全”。代码的话别用AgentExecutor了，直接上LangGraph，自己控制节点状态流转，工具输出存到state里，比黑盒好用太多。还有个细节，工具返回的字符串最好带个结构化前缀，比如“订单状态查询结果：”，这样LLM更容易区分新旧信息。

我之前也踩过这个坑，核心问题不是memory没加，而是AgentExecutor默认确实不把工具输出写回给LLM的上下文，只保留最终回复。你可以试试在tool的return_direct=True，或者手动把工具结果拼进新的HumanMessage里，再传给agent。另外检查一下你的prompt里有没有明确要求“基于历史工具结果回答”，有时候模型偷懒就直接重查了。我后来干脆自己写了个循环，把每次工具输出都存进一个list塞回prompt，效果比调内置memory稳多了。

这问题太典型了，我刚踩完同一个坑。AgentExecutor确实默认不把工具输出塞回memory，它只保留最终回复，所以你得手动在tool的返回值里把关键信息拼进一个“观察”字段，或者干脆用langchain的ConversationBufferWindowMemory，然后把工具结果也当作一条消息加进去，比如return {"result": data, "extra": "订单状态：已发货"}。我之前试过把工具输出直接放到SystemMessage里，但那样对话一长就爆token，后来改成把结果存到全局dict，每次tool调用前先查缓存，命中就直接返回，省得重复查库。你那个“刚才订单状态”的问题，本质是Agent没把“查询动作”和“结果”关联成一条记忆，建议你在tool函数里把查询参数和结果一起格式化成字符串，再用add_message塞进chat_history，这样多轮里它能顺着历史推断。另外检查下你的prompt里有没有明确告诉Agent“优先使用已有信息”，不然它总会倾向重新调用工具。最后提一句，LangChain 0.2之后有个create_history_aware_retriever，但对工具调用场景帮助不大，还是手动管理memory更靠谱。

这个问题我踩过好几次坑，核心不在memory，而在AgentExecutor的迭代机制。默认情况下，每次工具返回确实会被写进中间步骤（intermediate_steps），但如果你用的是conversational agent，prompt模板里往往只把chat_history传给了对话轮次，没把intermediate_steps塞进当前输入里——所以模型压根看不到上一轮的工具结果。我后来是直接改了agent的prompt，把intermediate_steps显式拼进messages里，比如在system prompt里加一句“这是你最近一次工具调用的原始输出：{tool_output}”，这样模型才能基于真实数据回答。另外，如果你只是想在多轮里复用查询结果，不如自己写个简单的缓存装饰器，按用户ID+意图哈希存返回值，比硬调AgentExecutor的memory靠谱得多。还有个小技巧，把工具函数的return直接格式化成一个带时间戳的JSON字符串，塞回给agent时它更容易“记住”这是新鲜数据而不是幻觉。你可以试下用langchain的create_agent_executor配合verbose=True看下实际传给LLM的完整消息列表，问题基本一眼就暴露了。

这问题我当初也踩过坑，LangChain的AgentExecutor默认确实不会把工具输出自动塞回对话上下文，它只保留给LLM的那轮思考记录。你光加memory和chat_history不够，得显式把工具返回结果拼到下一次的prompt里，或者用langchain的ConversationBufferMemory配合return_messages=True，再把工具输出作为user消息推进去。我之前试过在工具函数里自己维护一个全局dict存最近结果，然后在agent的prompt模板里加一句“如果用户问的是刚才的数据，直接引用{last_tool_output}”，虽然土但管用。另外你检查下是不是用了多个工具，AgentExecutor在多工具切换时容易把中间结果丢掉，可以试试用create_react_agent或者自定义AgentExecutor的callbacks，在工具结束回调里强制把output写入memory。还有个思路是改用langgraph，它对状态管理更精细，工具输出能作为节点间的显式状态传递，就不会丢了。你那个“重新查一遍”的问题，大概率是prompt里没给Agent明确指令说“优先复用已有结果”，试试在system prompt里加一条“如果历史中已有相同查询的结果，直接引用，不要重复调用工具”。

这问题太典型了，AgentExecutor默认确实不会把工具输出塞回prompt，你得自己处理。试试在tool的func里把返回值格式化一下，然后手动拼到chat_history里，或者直接换用LangGraph，用StateGraph显式传递消息状态，比AgentExecutor可控得多。

我之前也踩过这坑，后来干脆在每次工具调用后，把结果存进一个全局dict，然后在prompt里加一个“上次工具结果”的变量，每次对话前动态注入。代码的话，核心就是别依赖默认memory，自己维护上下文列表。

另外，你检查下是不是tool的description写得太模糊，Agent可能以为要重新查才能拿到最新状态，有时候把description写成“查询订单状态，若已有结果可直接复用”能减少误判。

我之前也踩过这个坑，AgentExecutor默认确实不会把工具输出自动塞回上下文，得自己在中间步骤里手动处理。我后来是重写了_take_next_step，把工具返回结果格式化后追加到scratchpad里，这样后续LLM就能看到了。另外你提到memory，但注意memory管的是历史对话，跟工具中间结果不是一回事，得分开弄。建议直接看看LangChain的AgentExecutor源码里_call的逻辑，比调prompt更靠谱，我之前就是卡在它只保留最后一次观察上。

这个问题我之前也踩过坑，AgentExecutor默认确实只保留最后一轮的工具输出，多轮记忆得自己拼进prompt里。我的做法是写个自定义的memory类，把每次工具返回的摘要存进一个list，然后在构造prompt时用format把这些历史结果拼到system message里，比直接塞chat_history可控。另外你试试把工具描述写清楚点，比如“查询订单状态，返回json”，让Agent更明确该不该复用旧数据，比硬调缓存逻辑省心。

工具输出不保留是LangChain老毛病了，不是prompt的锅。我一般会在工具函数里自己维护一个全局dict，按会话id存结果，然后在agent的observation里加个标志位，让LLM判断“这个数据是否已存在”，而不是靠memory硬塞。你也可以试试把AgentExecutor换成langgraph，那个状态管理清晰很多，工具输出能显式传给下一步。

你这问题我也遇到过，后来发现是chat_history只存了对话没存工具结果。我现在的解法是：在工具里直接return一个带时间戳的字符串，然后自定义一个callback把工具输出追加到memory的buffer里，再让prompt里明确写“如果之前查过订单状态，直接引用上次结果”。代码就不贴了，思路就是别依赖默认机制，自己接管上下文拼接。

说实话，LangChain的AgentExecutor对工具结果的缓存确实弱，我

这个问题我最近也踩过坑，LangChain的AgentExecutor确实默认不会把工具输出塞回对话上下文，它只保留在单次执行的内部状态里。你加memory和chat_history只是存了用户和AI的对话，工具返回结果如果不主动追加到prompt里，模型当然“失忆”了。我试过比较靠谱的做法是，在自定义的tool里，把返回值同时append到memory的chat_history里，或者干脆用一个全局dict缓存key-value，然后在agent的system prompt里强制要求“优先从缓存读取已知信息”。不过更省事的方案是直接用langchain的create_react_agent配合messages_to_dict，把每一步的tool输出都以ToolMessage的形式显式push进去。你可以检查下是不是用了旧版AgentExecutor，新版langchain已经推荐用langgraph了，它的StateGraph能让你自己控制消息流，工具结果想留多久留多久。另外prompt里最好写清楚“当用户提及‘刚才’或‘之前’时，必须引用已获取的数据，禁止重复调用”，否则模型偷懒就重新查。代码片段我没法贴全，但核心就是拿到AgentAction后，手动把Observation追加到messages列表，再传给下一轮。你试试把tool的return_direct设成False，然后自己接管格式化逻辑，应该就好使了。

这问题太典型了，AgentExecutor默认确实不会把tool output塞回对话上下文，只保留在中间步骤里。我后来是直接在prompt里显式加了个“以下是已知信息”的段落，每次把历史工具结果格式化塞进去，才稳住的。另外你可以试试把memory换成ConversationSummaryBufferMemory，它对长上下文的压缩比单纯chat_history靠谱。不过还是建议先打印一下agent的完整输入，看看工具返回到底有没有进prompt，有时候是自定义工具里return_direct参数没设对。

这问题我踩过坑，光塞chat_history不够，得把工具输出显式拼回messages里喂给模型，或者直接用create_react_agent试试。

这问题我上周刚踩过坑，AgentExecutor默认确实不会把工具输出自动塞进后续prompt，你得自己在tool的return_direct或者callback里手动处理一下。我当时是把工具结果格式化后追加到chat_history里，再传给下次迭代，代码大概就是在agent的observation里拼上“上次查询结果：xxx”。另外你试试把memory的return_messages设成True，用MessagesPlaceholder接住，比直接塞字符串稳很多。

工具输出本来就该你自己拼进messages里，AgentExecutor只传最后一步的observation，试试把中间结果手动append到chat_history再传给下一次。

这问题我踩过不少坑，核心其实不在prompt，而是LangChain的AgentExecutor默认只把最后的观察结果（Observation）留在短期记忆里，上一轮的工具输出在下一轮就被剪掉了。你试的memory和chat_history只管用户和AI的对话，管不到工具调用的中间状态，所以Agent觉得“手里没数据”自然就重查了。我后来是直接在工具函数里把返回值写进一个全局dict或者Redis，key绑上会话ID，然后在prompt里明确告诉Agent“查订单状态前先看下缓存键xxxx”，这样比硬塞上下文靠谱得多。如果你想保留完整链路，可以重写AgentExecutor的_achain_iter，把每步的action和observation都append到messages里再传回LLM，但那样token消耗会爆炸，不太建议。还有个取巧办法，就是让工具自己返回一个带记忆的标识，比如查完数据库直接把结果格式化成“订单号xxx状态是xxx（查询时间xxx）”，然后让Agent把这句话原样复述给用户，相当于把数据“烙”进对话里，下轮就能从chat_history里翻到。你试试这个思路，比折腾memory参数直观。