什么是最大步数限制？防止无限循环

一个智能体如果陷在「调用、失败、再调用、再失败」的循环里出不来，会一直消耗资源直到有人发现。最大步数限制就是防止这种无限循环的断路器：给 Agent 的执行轮次设一个硬上限，到数即停，无论任务完没完成。

上限是怎么兜底的

执行循环每走一步计一次数，计数到达上限，系统就强制中止循环并输出当前进展。这个上限和任务难度无关，纯粹是安全阀——正常任务可能十步内跑完，上限设到三十，是为了给重试和纠偏留余量；异常任务则会在三十步处被拦下，不至于空转一夜。

DeepSeek 执行复杂推理任务时步骤偏多，扣子在编排长流程时也普遍建议设置步数上限，道理相同：模型不知道自己陷入了循环，只有外部的计数器知道。

上限触发时的行为也值得了解：好的实现会先尝试保存现场——把已完成的中间产物落盘、把当前进展写成摘要，再中止循环；差的实现直接一刀切，前面跑的全白费。选平台时可以专门问一句「步数用尽后会输出什么」，答案的质量基本能判断这个平台对长任务的认真程度。另一个细节是计数的口径：有的按模型轮次计，有的按工具调用计，一个含重试的流程在两种口径下能差出一倍，配置前务必看清。多数平台允许在任务中途查看剩余步数，长流程的进度感也来自这里。

生活类比：游戏里的体力条

把步数上限想成游戏体力条：每做一个动作扣一格，耗尽就休息。体力条的作用不是限制你玩，是防止无意识地刷个通宵。上限的存在，逼着每次执行都精打细算。

体力条的比方盖不住一点：游戏体力花完会恢复，Agent 步数用尽则任务直接终止，产出是半成品。所以上限触发后系统通常要输出一份中途报告——做到第几步、卡在哪里、下一步建议——这些信息比任务本身更值钱。精打细算的另一面是取舍：步数快用完时，模型会倾向走更直接但质量略低的路径，这是预算意识的自然表现，不必视为缺陷。

上限设多少比较稳

没有统一答案，但有几条经验：

• 先跑几次正常任务，记录实际步数，上限取均值的两到三倍。
• 步数总是偏多，说明任务拆分有问题，优先改规划，再考虑放大上限。
• 外部调用要花钱的流程，上限宁小勿大，出问题宁可人介入。
• 重试次数也要设上限，否则一次调用反复重试同样能吃掉大量步数。

自查清单：

• 你的 Agent 有没有显式的步数上限？还是靠运气不循环？
• 触发上限后的输出，能不能让人一眼看出卡点？
• 上限值多久没复查过了？任务变了，上限也该跟着变。

三条里有一条答不上来，就该回去补配置了。

每一步返回的内容如何解读，见观察结果；正常情况下何时收手，见终止条件；多轮之间的信息留存，可读记忆分层；流程化执行与自由发挥的区别，见工作流编排；由时间或事件自动启动的任务，则在触发器里展开。

把它想成护栏就好：护栏不是为了限制行走，而是为了让走得慢的人也敢上路。

关于最大步数限制再多问三句

• 触发上限算失败吗？：不算天然失败。它是保护机制生效，重点看触发后的输出有没有说清进展与卡点，供人决定重跑还是改方案。
• 上限设在模型侧还是平台侧？：多数在平台侧，与模型无关。同一个模型换平台，上限逻辑可能不同，迁移前要重新确认。
• 并行跑多个任务，上限怎么算？：通常按单个任务计。如果平台按总量计，多个任务会互相挤占额度，配置时要看清计数口径。