没有终止条件，就算不上产品

一句话总结

没有结束条件的智能体不是产品。 而结束条件应由人来定义，不应交给模型决定。

为什么需要它——递归上限是安全网，不是设计

LangGraph 提供 recursion_limit。一旦超过这个次数，就会抛出异常。倚赖它来停止流程，会同时带来两个结果：用户看到错误，而此前消耗的费用仍会照常计费。

上限是捕获缺陷的安全网，不是停止流程的方法。真正的停止方式必须存在于图本身之中。

三种停止条件

实际项目中通常组合使用以下三种条件。

条件	何时触发	缺少它会怎样
成功	已得到想要的结果	即使已有答案仍继续运行
次数上限	已尝试 N 次	永远重复尝试
放弃路径	已到达上限	以异常结束，或开始编造答案

第三种最容易遗漏。只设置上限却没有定义后续去向，到达上限时就会无路可走并抛出异常。放弃本身也是一条路径。

def after_lookup(state):
    if state.get("answer"):
        return END                      # 성공
    if state.get("tries", 0) < MAX_TRIES:
        return "lookup"                 # 다시
    return "fallback"                   # 포기 — 이 줄이 자주 빠진다

不知道时不要编造

放弃路径的作用不只是停止，更重要的是坦率地说不知道。

检索空手而归，却仍把任务交给模型并要求“给出答案”，模型就会生成一个答案。这是产生幻觉最常见的路径；根因不在模型，而在于图把空结果原封不动地传了下去。

在实际项目中

当有人报告令牌成本达到预期的数倍时，需要检查的位置很明确：循环经过的路径及其上限。 如果日志没有记录路径，连这一点都无法确认，最后只能重新构建整个流程。上限与记录必须同时存在。