用LangGraph写Agent总在工具调用循环里出不来，怎么设计终止条件？

我也踩过这个坑，max_iterations确实治标不治本。后来我的做法是让模型在每轮工具返回后先输出一个简短的状态判断，比如“已获得足够信息”还是“还需要查X”，把它作为路由条件而不是硬砍次数。另外同一个工具连续调用两次以上就该拦一下，把上次结果塞回prompt里让它解释为什么不够用，通常它自己就发现是重复了。纯靠LLM判断完成度也有风险，最好加个关键字段校验兜底。

我也踩过这个坑，后来发现单纯靠max_iterations确实太粗暴了。我现在比较常用的是在state里加一个工具调用历史记录，每次进节点前检查一下：同一个工具加同样的参数如果重复出现了两三次，就直接强制走结束分支，或者转成让LLM总结当前已有的信息来回答。这样比一刀切限制次数要准一些，因为真正需要多步的任务参数通常是在变的。另外我还会在工具返回里加一个字段，比如success或者confidence，当连续两次返回都是低置信度或者空结果时，就触发一个fallback提示让模型别再试了。LLM自己判断任务是否完成这招我也试过，但得配合结构化输出，不然它经常嘴上说完成了其实啥也没干。还有个偷懒的办法是给每个工具设置独立的调用预算，搜索类允许三五次，计算类一两次，比全局限制灵活。不过说到底，最稳的还是把终止逻辑写进图的条件边里，别全指望模型自觉。

我一般让LLM在每轮后输出个done标记，再配合工具结果去重，比硬限制次数灵活多了。

我一般让LLM每轮自己判断“够不够答用户了”，不够再调工具，光靠迭代次数确实容易误伤。

之前也踩过这个坑，纯靠max_iterations确实太粗暴了。我现在的做法是在state里维护一个最近几次工具调用的签名（工具名+参数hash），如果发现重复就直接强制走LLM总结分支，效果还不错。另外可以让LLM在每次工具返回后先输出一句“这个结果够不够回答问题”，不够的话再说下一步要干嘛，相当于把判断权交回去，比硬编码阈值灵活很多。

我也踩过这个坑，后来是在state里记一下每个工具最近几次的输入和返回，如果发现参数几乎没变、结果也差不多，就直接短路走结束分支。另外让LLM在每轮工具返回后先做一次“继续还是收尾”的判断，比硬卡迭代次数自然很多。max_iterations可以留着当兜底，但别让它当主力，不然正常的多步任务很容易被误杀。

我一般会在state里记录每个工具最近几次的输入和输出，如果连续两次调用参数几乎一样、返回也没啥新信息，就直接短路掉。光靠LLM判断“任务完成”不太靠谱，它有时候自己都绕晕了。max_iterations可以留着当兜底，但主力还是得看工具结果有没有实质变化。

让LLM自己判断“任务完成没”挺管用，再配个连续两次相同调用的检测兜底。

让LLM自己判断完成度更灵活，但得配个硬上限兜底，不然它也会嘴硬说没完。

我也被这问题坑过，后来发现光靠max_iterations确实治标不治本。我的做法是给工具调用加个"签名"机制，把工具名+参数hash存到state里，重复调用直接拦截，然后让LLM基于已有结果重新推理。另外会额外加个轻量判断节点，专门问模型"当前信息够不够回答原始问题"，不够才继续，这样比硬性次数限制灵活多了。

我也踩过这坑，后来让LLM每轮输出个done标记，顺便查下工具结果有没有实质变化，没变就直接掐断。

我也被这问题折磨过，后来在state里加了个tool_call_history，记录每次调用的参数和返回摘要，让LLM在决定下一步前先看一眼历史，效果还不错。另外可以给工具调用加个“重复检测”，如果连续两次参数几乎一样就直接注入一条提示让模型换策略或收尾。至于终止，我一般用LLM自评加硬上限兜底，自评问它“当前信息够不够回答”，不够就继续，够就停，比单纯数次数灵活多了。

我也遇到过这个坑，后来在state里加了工具调用历史的去重判断，如果连续两次用相同参数调同一个工具就直接中断。另外可以让LLM在每次工具返回后做个轻量判断，输出“继续/完成/放弃”三选一，比硬编码max_iterations灵活不少。不过LLM判断有时候也不靠谱，我一般还会加个硬上限兜底，双保险。

我之前也踩过这个坑，后来发现单纯靠LLM判断“任务完成”经常不靠谱，它会自我感觉良好。我现在的做法是在state里记录每个工具最近一次调用的参数和结果hash，如果连续两次完全一样就直接打断，强制走总结分支。另外给工具加个“无新信息”的返回标记也挺管用，模型看到没新东西一般就不硬试了。max_iterations当兜底就行，别当主要手段。

让LLM每轮自评“任务完成没”，再配合工具结果去重检测，基本能解决九成死循环。

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

刚入门，这个对我帮助很大。