在 ReAct（Reasoning and Action）模式中，模型通过“思考-行动-观察”的循环来解决问题。然而，由于 LLM 的随机性或工具调用的不确定性，代理（Agent）容易陷入逻辑死循环（如重复相同的 Thought）或无效重试（反复调用失败的工具）。

为了构建健壮的 ReAct 系统，通常需要从硬性约束、状态感知和反馈修正三个维度来处理。

1. 防止死循环的核心策略

死循环通常发生在模型认为当前的 Action 是唯一解，但 Observation 却不断返回错误或相同结果时。

• 最大迭代次数限制 (Max Iterations):
  这是最基础的“断路器”。设定一个硬性阈值（如 $N=5$ 或 $10$），一旦超过该次数，系统强制停止并返回错误或当前最接近的答案。
• 重复检测 (Repetition Detection):
  记录历史的 Thought 和 Action。如果当前的 Action 及其参数与前几次完全一致，说明模型陷入了原地踏步。此时应干预 Prompt，提示模型“你已经尝试过此操作并得到了相同结果，请尝试其他策略”。
• 多样性惩罚或温度调节:
  如果检测到连续两次相同的输出，可以临时提高 LLM 的 Temperature 采样参数，强制引入随机性以跳出局部最优陷阱。
• Early Exit (早停机制):
  当模型连续多次生成的 Observation 没有任何信息增益时（例如搜索引擎反复返回相同摘要），判定为无法通过当前途径解决，触发早停。

2. 重试机制的处理逻辑

重试不应是简单的重新执行，而应该是带上下文的修正。

• 解析错误重试 (Parser Retry):
  当 LLM 输出的格式不符合预期（如 JSON 格式损坏）时，将错误信息（Error Traceback）反馈给模型，让其重新生成符合格式的内容，而不是盲目重试。
• 工具调用回退 (Tool Backoff):
  如果某个工具频繁报错（如 API 超时或权限问题），重试逻辑应包含“降级方案”：
  1. 第一次失败： 原样重试。
  2. 第二次失败： 修改参数重试。
  3. 第三次失败： 切换工具或提示用户干预。
• 反思提示 (Self-Reflection):
  在重试的 Prompt 中加入一个 Reflection 步骤。要求模型先回答：“为什么之前的尝试失败了？我接下来的调整是什么？”这能有效引导模型改变解题思路。

3. 关键标志位 (Flags)

在实现 ReAct 框架（如 LangChain 或自定义 Engine）时，以下标志位是判断状态和控制流转的关键：

4. 最佳实践建议

1. System Prompt 约束： 在系统提示词中明确规定：“如果你发现陷入了循环，请立即停止并向用户说明原因。”
2. 人工介入点 (Human-in-the-loop)： 对于高价值任务，当重试次数达到阈值（如 3 次）时，不直接报错，而是挂起任务并请求人工输入提示，帮助 Agent 绕过障碍。
3. 结构化输出： 尽量使用结构化工具（如 OpenAI 的 Function Calling 或 JSON Mode），这能从根源上大幅减少由于解析失败导致的重试。

在实际开发中，防止死循环不仅仅是为了节省资源，更是为了保证代理在复杂长链推理中的确定性。

在设计 ReAct 代理时，你通常更倾向于使用硬性的迭代次数限制，还是通过逻辑判断来动态调整 Agent 的行为？