ReAct是一种将推理与行动结合的智能体运行范式，模型在每一步先输出思考轨迹，再调用工具或执行动作，依据返回结果决定下一步。实际部署里，智能体容易在相近状态下重复发出一致的调用，形成循环死锁，既消耗算力又无法给出最终答案。
循环死锁通常表现为：智能体连续多步都执行同一个搜索或计算工具，但每次获得的结果都不能让它判断任务已完成，于是继续重复。造成这种现象的原因包括提示词未明确终止条件、工具返回格式不稳定、以及模型在不确定时倾向于模仿上一步动作。若不在架构层加以约束，死锁会一直持续到接口超时。
最大步数限制的设计与实现
最大步数限制是最直接的防护手段。系统在启动ReAct循环前，先设定一个整数阈值，例如十步或二十步。每完成一次思考加动作再加观察，计数器加一。当计数器达到阈值且未触发任务结束标志，调度器立即终止循环，避免无限执行。
具体落地时，可将步数作为参数写入Agent配置。下面给出常见设定对照：
| 任务类型 | 建议最大步数 | 说明 |
|---|---|---|
| 简单问答 | 5 | 通常一两步工具调用即可解决 |
| 多跳检索 | 12 | 需要多次查找与交叉验证 |
| 代码生成调试 | 20 | 可能反复运行与修改脚本 |
除了硬截断，还可以在临近上限时让模型收到提醒，例如在第N减一步插入提示，要求它汇总已有信息直接给出答案。这样既能控制成本，也降低用户拿到空响应的概率。
错误恢复机制的关键做法
仅有步数限制不够，因为死锁往往伴随工具异常或格式错误。错误恢复指在捕获到异常后，不直接崩塌，而是尝试修复现场。常见策略有三类：其一是重试并清洗返回内容，把不合规的JSON补齐；其二是回退到上一稳定状态，重新选择动作；其三是启用备选工具，例如主搜索接口失败时切换至缓存检索。
在实践中，可把每一步的执行包在异常处理块中。一旦抛出超时或解析错误，记录日志并递减可用恢复次数。若恢复次数未用完，就按预设分支处理；若用完仍失败，再结合最大步数限制结束流程，并向用户返回简明错误原因而非堆栈信息。
恢复与限制的协同
把最大步数限制和错误恢复放在同一控制循环里效果最好。步数限制负责全局上限，错误恢复负责局部容错。当智能体陷入重复调用，恢复逻辑可识别重复模式并主动替换动作，若替换后依旧无效，步数上限会兜底停止，防止系统挂起。
这种协同设计已在不少开源Agent框架中采用。开发者应在评测阶段故意构造畸形输入与慢速接口，观察智能体是否在限定步内优雅退出，以及错误信息是否有助于排查。只有经过这类演练，循环死锁才不会再成为线上事故源头。