你让一个 Agent 帮你"查资料、整理结果，再发一封邮件"。它先搜索，读取网页，发现信息不够，又搜索一次。接着它重新读取刚才的网页，再次判断"还需要更多信息"，于是继续搜索。
几分钟后，你发现它已经执行了十几轮，花了更多 Token，却没有明显接近最终答案。
这类问题很容易被理解成"模型不够聪明"。但真正值得关注的，其实是另一个问题：Agent 什么时候应该继续尝试，什么时候必须停下来？
最大迭代次数，就是给这个问题设置的一道安全边界。它看起来只是一个数字，背后却涉及成本、任务复杂度、错误恢复和系统可靠性。
Agent不能无限循环，因为"继续思考"并不等于"继续进步"
普通聊天模型生成一次答案后就结束，而 Agent 往往是一个循环：
观察当前状态 → 判断下一步 → 调用工具 → 获取结果 → 再判断下一步。
只要目标还没有完成，它理论上就可以继续执行。
问题在于，循环次数增加，并不保证任务完成概率同步增加。
假设一个 Agent 需要在网页里寻找某个不存在的信息。第一轮搜索没找到，第二轮换关键词，第三轮扩大搜索范围，这些尝试可能都有意义。
但到了第十轮，如果它仍然只是换几个近义词继续搜索，新的执行已经很难带来新的信息。
更麻烦的是，Agent 的动作可能不是只读操作。
如果它拥有发邮件、修改数据库、创建工单、下单等工具，一次错误循环甚至可能意味着重复发送邮件、反复创建记录，或者不断修改同一份数据。
所以最大迭代次数并不是为了"限制模型发挥"，而是为了控制一个开放循环最坏情况下能造成多大损失。
可以把它理解成程序里的保险丝。
保险丝并不会让电器工作得更好，但当系统进入异常状态时，它能避免问题无限扩大。
最大迭代次数，不应该拍脑袋设一个数字
很多 Agent 框架都会提供类似 max_iterations 的参数。最简单的做法当然是随手设置成 5、10 或 20。
但更合理的问题应该是：
一个正常完成的任务，大约需要多少个有效步骤？
例如，一个非常简单的查询任务可能只有：
理解问题 → 搜索 → 读取结果 → 输出答案。
如果把每次工具调用和重新决策算作一次迭代，五六轮通常已经足够。
但如果任务变成：
读取几十份文件 → 找出相关内容 → 对比信息 → 调用代码计算 → 检查结果 → 生成报告，
那么五轮显然可能不够。
因此，可以先估算任务的"正常路径长度"。
假设一个典型任务预计需要 6 次关键动作，不要直接把最大次数也设置成 6，而应该留出一定的错误恢复空间。例如某次搜索失败、API 超时，或者 Agent 需要重新规划一次。
一种实用思路是：
最大迭代次数 = 正常任务步骤 + 合理的重试空间 + 少量异常缓冲。
真正需要关注的不是"行业标准是多少"，而是你的任务完成路径究竟有多长。
更成熟的系统甚至不必所有任务共享一个上限。简单问答可以设置较小预算，研究型任务拥有更大的预算，高风险写操作则应该拥有更严格的限制。
设置太小，Agent会死在离终点只差一步的地方
最大迭代次数设置得很小，看起来更安全，也更省钱，但它会制造另一类问题：任务被过早终止。
假设 Agent 的工作是：
读取销售数据 → 发现格式异常 → 清洗数据 → 重新计算 → 生成图表 → 写总结。
如果最大迭代次数只有 4，它可能刚把数据整理干净，系统就告诉它：
"达到最大迭代次数，停止执行。"
此时 Agent 并不是不会完成任务，而是执行预算用完了。
这种问题在需要探索的任务里尤其明显。
现实任务并不会永远按照最短路径执行。网页可能打不开，文件格式可能异常，第一次搜索可能没有结果，代码可能运行失败一次。
如果系统完全不给 Agent 留纠错空间，那么稍微出现一点意外，任务就会失败。
因此，判断上限是否太小，可以观察一个非常实用的信号：
大量任务是不是经常在最大迭代次数附近被强制结束？
如果 Agent 经常运行到 8/8、10/10 才失败，这往往意味着预算不足，或者任务本身需要拆分。
反过来，如果绝大多数任务三四轮就完成，而系统给了 50 轮，上限可能又过于宽松。
设置太大，真正增加的是"错误可以持续多久"
有人可能会想：既然设置太小会中途停止，那干脆设成 100。
这样确实降低了正常任务被提前截断的概率，却引入了另一个问题：Agent 一旦走错方向，会拥有非常充足的时间继续错下去。
最常见的情况就是重复调用工具。
例如：
搜索 A → 没找到 → 搜索 B → 回到搜索 A → 再搜索 B。
如果上限是 10，这个错误最多持续十轮。如果上限是 100，它可能消耗大量 Token 和 API 调用之后才停止。
而且迭代越多，上下文通常也会越来越长。
Agent 需要携带之前的观察结果、工具返回值和执行记录。信息不断累积后，模型可能更难识别哪些信息仍然重要，甚至开始被旧错误影响。
所以一个很重要的判断是：
最大迭代次数不是能力参数，更像风险预算。
你允许 50 次迭代，就相当于告诉系统：即使 Agent 没有明显取得进展，我最多也愿意承担 50 轮执行的成本和风险。
这个数字自然不应该无限大。
真正危险的不是迭代次数多，而是"没有进展"
只限制最大迭代次数，其实还是一种比较粗糙的保护方式。
更值得检测的是：Agent 有没有产生新的进展。
假设一个 Agent 连续三次调用：
search("AI Agent memory")
参数完全一样，返回结果也基本一样。
此时根本没必要等到第 20 次迭代才停止。系统在第三次就可以判断：它已经进入循环。
工程上可以给每一次动作生成一个简单的"动作指纹"，记录：
工具名称 + 关键参数 + 返回结果摘要。
如果短时间内出现相同指纹，就触发重复检测。
但还有一种循环更隐蔽：
搜索"Agent memory"
搜索"AI Agent memory"
搜索"memory for AI agents"
搜索"how agents use memory"
表面上参数不同，实际做的是同一件事。
因此，除了检测"动作是否相同"，还可以判断状态是否发生变化。
每轮执行后问几个问题：
获得新信息了吗？
任务剩余步骤减少了吗？
某个子目标完成了吗？
当前结果与上一轮相比有什么变化？
如果连续几轮答案都是"没有"，就应该触发重新规划，而不是继续执行原计划。
遇到重复执行，别只会把最大次数调小
发现 Agent 陷入循环后，直接把最大迭代次数从 20 改成 5，只是让它更快失败，并没有解决循环产生的原因。
更有效的处理通常分几层。
先做重复动作检测。同一个工具、相同参数连续调用，直接阻止。
再加入"无进展计数器"。例如连续三轮没有产生新信息，就要求 Agent停止原计划，重新分析任务。
重新规划仍然失败时，可以切换策略。搜索没有结果，就尝试其他数据源；代码连续报错，就要求解释错误原因，而不是原样重跑。
还可以设置单工具限制。比如一次任务最多搜索 8 次、最多发送一次邮件、最多创建一个工单。这样即使整体 Agent 还有迭代预算，高风险动作也无法无限执行。
最后才是全局最大迭代次数。
一个更稳健的 Agent，通常不是只有一道"最多运行 20 次"的墙，而是同时存在：
重复动作保护、无进展检测、工具调用预算、错误重试限制，以及最终的最大迭代上限。
这些机制组合起来，才能真正控制循环。
最大迭代次数，是停止机制的最后一道防线
设计 Agent 时，很容易把注意力放在"怎样让它完成更多事情"上。但一个能够调用工具、修改外部世界的系统，还必须回答另一个同样重要的问题：什么时候应该承认这条路线走不通。
最大迭代次数可以从任务的正常步骤开始估算，再为合理重试留下空间，并根据真实运行日志持续调整。
但不要把全部希望寄托在这个数字上。
如果 Agent 连续执行很多轮却没有产生新信息，真正应该解决的是"进展判断"和"循环检测"。
一个好的 Agent，不只是知道下一步该做什么。
它还应该知道：什么时候继续尝试已经没有意义。