用LangChain搭Agent，工具调用多了就崩，是我代码姿势不对吗？

遇到这种多工具链式调用，大概率是LangChain对中间格式解析太死板，建议试试直接自己写循环调函数，反而稳得多。

我最近也踩过这坑，感觉是工具结果一多上下文就串味了，后来换成给每个工具加清晰的分隔符和状态标记才好点。

说实话，你这个现象太正常了，我换过好几个框架都这样，本质是工具返回格式稍微不干净就带偏agent。

建议先把每个工具的output解析成严格json再喂给模型，比调max_iterations管用多了。

遇到过一模一样的情况，尤其是工具返回结果一长或者字段一复杂，那个格式解析就特别容易崩。我后来排查发现，LangChain的AgentExecutor在处理中间步骤时，对工具输出的结构假设其实挺脆弱的，尤其是当openai的function calling返回内容里带了些额外字符，或者模型自己脑补了不该有的字段时，整个循环就卡死了。

我自己试下来，比较有效的土办法是把工具返回的内容强制精简，比如只返回关键状态码和一句话摘要，别让模型去理解大段JSON。另外，prompt里明确告诉它“如果上一步成功，直接调用下一个工具，不要复述结果”，这样能减少模型在“思考”里反复纠结的概率。

不过说实话，这类多工具链式调用，根子上就是模型在长上下文中保持格式稳定的能力不够。如果你追求更可控的流程，可以试试不依赖Agent自动决策，而是自己写一个状态机，每一步用单独的LLM调用去决定下一步调哪个工具，这样虽然代码多点，但每一步都能做校验和重试，稳定性会好很多。

另外，现在比较新的框架像LlamaIndex的Agent或者CrewAI，在处理工具切换时用了更严格的schema约束，你可以对比下它们的实现思路，说不定能给你些启发。最后想问下，你那个“卡在思考里”的时候，日志里最后一次工具返回是什么内容？我怀疑是某个特定格式的响应触发了它的死循环。

我之前也踩过这坑，LangChain的AgentExecutor在多工具场景下确实容易乱，尤其工具描述写得模糊时，模型会反复纠结调哪个。你可以试试把每个工具的description写得更死板一点，明确啥时候用、返回啥格式，能减少不少无效循环。另外max_iterations只是兜底，真正管用的还是把中间步骤的observation压缩一下，不然上下文一长模型就开始飘。如果还不行，换LangGraph自己搭状态机，可控性比黑盒Executor强太多。

我之前也踩过这个坑，后来发现多半是工具返回结果太长把上下文撑爆了，模型就开始胡言乱语。你可以试试在每个工具返回后做一层摘要压缩，别把原始JSON直接塞回去。另外LangChain的AgentExecutor确实有点黑盒，换成LangGraph自己画状态机后可控多了，卡死的情况基本没再出现。

我之前也踩过这个坑，后来发现多半是工具描述写得太模糊，模型分不清该调哪个，来回绕就把自己绕死了。你可以试试把每个工具的入参和返回结构写死一点，再在prompt里明确要求它一次只决定一个动作。另外LangGraph做状态机式的流程会比裸AgentExecutor稳不少，至少每步干啥是可控的。

这个问题我踩过类似的坑，连续调用多个工具的时候确实容易出问题。LangChain的AgentExecutor在处理多轮工具调用时，中间结果会不断拼接进上下文，token一多模型就容易跑偏，尤其是返回格式稍微不匹配解析器就直接炸了。我后来把每个工具的返回做了严格的结构化裁剪，只保留必要字段，情况好了不少。另外prompt里最好明确告诉模型每次只能调一个工具，拿到结果再决定下一步，别让它一口气规划太多。max_iterations确实只是兜底，不是解决方案，真正要控的是上下文膨胀和工具返回的干净程度。如果还搞不定，可以看看LangGraph，它把状态和流程拆得更清楚，多工具场景下比裸AgentExecutor稳很多。