用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可以留着当兜底，但别让它当主力，不然正常的多步任务很容易被误杀。