用LangChain搭Agent做多步推理，为什么总卡在工具调用上？

我之前也遇到过一模一样的情况，后来发现多半是tool description里没把“输出格式”和“适用条件”写清楚，模型一拿到搜索结果就当成最终答案了。你可以试试在每次工具返回后强制加一个“思考下一步”的prompt节点，或者把max_iteration调低点，让它被迫收敛。另外，如果反复调同一个工具，可以检查下是不是ReAct模板里的“Observation”字段没吃进历史消息，导致它忘了自己已经查过。我现在习惯把工具调用结果先缓存成变量，再让Agent基于变量做判断，会稳很多。

我之前也遇到过一模一样的情况，搜索完直接输出原文多半是ReAct模板里对“最终回答”的触发条件写得太宽了，模型觉得拿到结果就能收工。建议你在prompt里明确加一条“必须完成所有工具调用后才能总结”，或者把每一步的思考过程强制要求输出。另外tool description别光写功能，最好带上输入输出示例，像“输入城市名，返回天气数据”，这样模型判断要不要继续调用的概率会准很多。死循环那个问题，可以给agent加个最大迭代次数的硬限制，然后在工具返回里加个“是否已解决”的字段，让模型自己判断要不要跳出，比单纯靠调参稳。你用的哪个模型？我感觉GPT-4对这类指令的遵从度比3.5好不少，换模型有时候比调prompt更省事。

这问题我太熟了，刚用LangChain那会儿几乎天天被tool call卡死。你那个“搜索完就直接输出原文”的毛病，八成是ReAct模板里对observation的格式约束太弱，模型把工具返回当成了最终答案。我后来是把prompt里“你必须基于工具结果进行下一步思考”这句话加粗加长，还塞了个few-shot示例，专门演示“拿到搜索结果后要再调用Python计算”的完整链路，效果立竿见影。

至于死循环，我怀疑是tool description里没写清楚“什么时候不该用这个工具”，比如搜索API的描述只说了“查资料”，模型就会在分析阶段也去搜一遍数据。建议给每个工具加个“当用户问题需要数值计算时，不要调用搜索”这种负向提示，能挡掉不少无效调用。另外可以试试在Agent里加个最大迭代次数，超了就强制让模型总结当前结果，至少不会无限转圈。

还有个坑你可能没注意到，就是工具返回的数据格式。如果搜索结果是那种超长网页摘要，模型注意力会被稀释，根本找不到后续推理的触发点。我一般会在工具内部做个预处理，只返回前500个字符加关键字段，让模型一眼扫到重点，后续走Python逻辑就顺多了。调参方面，temperature降到0.1以下也挺有用的，减少模型“自由发挥”不按模板走的情况。你先按这几个方向试试，应该能稳不少。

这坑我太熟了，刚入坑时几乎每个agent都卡在工具调用上。你那个“返回结果后不继续走”的问题，大概率不是ReAct模板写错，而是LangChain默认的agent执行逻辑里，对中间步骤的终止条件判断太粗暴——只要output里带了疑似最终答案的关键词就直接停，压根不管你的工具结果里有没有“搜索到但需进一步分析”这种暗示。我后来干脆不用它内置的AgentExecutor，自己写了个while循环控制，每轮拿到工具返回值后手动检查是否满足“需要调用下一个工具”的条件，才稳下来。另外tool description确实关键，别写“搜索一下”，要写清楚“当用户问题包含具体实体且需要实时信息时，调用此工具，返回结果含摘要和链接”，否则模型经常把它当万金油。死循环那个，我建议你在prompt里加一句“如果上一个工具结果已包含足够信息，必须直接给出结论而非再次调用相同工具”，同时把max_iterations调小到4，配合print日志看每步的thought和action，能定位到是模型在瞎绕还是tool反馈格式有问题。还有一个隐蔽点：如果你用的是OpenAI函数调用模式，别把多个工具塞进一个function里，拆成独立的函数描述，模型选择会更准。你可以试试把工具返回的结果先截断到前500字符，有时候是结果太长把后续指令挤出了上下文。