第5篇：三种思考模式 —— ReAct / Plan-and-Execute / Reflection

Agent 不只是"LLM + Tools"。LLM 怎么"想"问题、怎么决定下一步做什么，有不同的模式。本篇介绍三种主流模式：ReAct（边想边做）、Plan-and-Execute（先想再做）、Reflection（想完自查）。理解它们的区别，才能在不同场景下选对模式。

一、ReAct（Reasoning + Acting）

边走边算：拿到一个信息后推理，再调工具，再推理，循环直到信息足够。

Thought（推理）→ Action（执行工具）→ Observation（观察结果）→ 再推理 → … → Final Answer

例子：用户问"今天天气适合徒步吗？"

1. Thought：我需要知道今天的天气情况来判断是否适合徒步
2. Action：调用天气查询工具，传入城市名
3. Observation：返回"温度 28°C，湿度 60%，下午有阵雨"
4. Thought：下午有阵雨，需要知道徒步路线是否有避雨点。还需要查昨天的天气做对比
5. Action：调用地图工具查徒步路线设施
6. Observation：路线沿途有 3 个避雨亭
7. Thought：信息足够，可以回答——建议上午出发，带雨具
8. Final Answer：给出具体建议

这个例子展示了 ReAct 的核心特征：每一步都在"想→做→看→想"之间循环，直到信息足够才给出最终回答。

• 优点：简单直观，实现容易，适合对话式交互
• 缺点：可能死循环（Thought→Action 反复停不下来）、消耗更多 token、没有全局视角（每一步只考虑当前信息）
• 适合：日常问答、单步工具调用、信息不完整的场景

论文：Yao et al., 2022, ICLR 2023《ReAct: Synergizing Reasoning and Acting in Language Models》

ReAct 循环的工程实现

在 Agent Runtime 中，ReAct 循环是一个连贯的七阶段流程：

1. 意图识别：判断用户的真实需求是什么
2. 理解 Context：结合当前上下文和记忆理解完整场景
3. 路由（Routing）：决定用哪个 Skill 或 Tool
4. Skill 加载：按需加载对应 Skill 指令
5. 工具执行：执行 Tool，等待结果
6. 结果观察：评估工具返回结果
7. 判断结束/继续：信息足够 → 生成最终答案；不够 → 回到第一步

这个七阶段循环是 Agent Runtime 的核心引擎。每次从 7 回到 1，都是一次"Thought→Action→Observation"的完整迭代。

ReAct 的死循环问题

ReAct 最常被诟病的问题是死循环。Agent 反复"想→做→看"但永远得不到足够的信息得出结论。工程上常用的应对手段：

1. 最大迭代次数限制：设定硬上限（如 10 次），超出后强制输出当前结果
2. 时间超时机制：超过设定时间（如 30 秒）后中断
3. 信息增益检测：如果最新 Observation 没有带来新的有效信息，提前终止
4. 重复动作检测：如果 Agent 连续调用同一个工具且参数相同，打断循环

二、Plan-and-Execute（先规划再执行）

先制定完整计划，再逐步执行。

vs ReAct：ReAct 是边想边做（每步重新推理），Plan-and-Execute 是先想好再做。

Plan:[1. 搜索 React 教程 →2. 阅读前3个结果 →3. 总结核心观点 →4. 格式化输出]Execute: 按计划逐步执行，每步只需执行不需要思考

• 优点：
  • 有全局视角，不会因为局部信息影响整体判断
  • 执行效率高（大模型只在规划和重规划时被调用，执行阶段只需 Tool 调用）
  • 用户可介入修改计划（增加/修改步骤）
• 缺点：
  • 计划可能过于僵化，执行中遇到意外情况需要重新规划
  • 不适合信息高度不确定的场景
• 适合：论文写作、博客、代码开发等多步长、结构清晰的任务
• 主流框架：LangChain / LangGraph 已实现该模式

Plan-and-Execute 在 AI 编程工具中非常常见：用户提出需求 → Agent 制定修改计划 → 用户确认 → 逐步执行 → 代码应用。

三、Reflection（自我反思）

Generate → Critique → Refine 循环。

草稿 → 审阅 → 通过/不通过 → 不通过则修改 → 再审阅 →... → 通过 → 输出

Reflection 的核心是引入第二个检验环节：不是让 LLM 一次生成到位，而是先生成初稿，再让另一个 LLM（或同一个 LLM 但换一个角度）审阅，发现问题后打回修改。

• 适合：需要高准确性的任务（代码审查、专业文档、法律文书）
• 类比：写完文章后自己审稿，或者找同事 code review

Reflection 的变体包括：

• Self-Reflection：同一个 LLM 对自己生成的内容做自我批评
• Multi-LLM Reflection：不同 LLM 分别担任"写"和"审"的角色
• Tool-Assisted Reflection：通过外部工具（编译器、语法检查器）来辅助审阅

论文：SELF-RAG: LEARNING TO RETRIEVE, GENERATE, AND CRITIQUE THROUGH SELF-REFLECTION

四、组合模式

大型通用 Agent 通常三种模式整合使用：

Plan 先规划 → ReAct 逐步执行 → Reflection 验证结果

类比：项目经理先定计划（Plan），团队执行（ReAct），QA 验收（Reflection）。

组合模式的优势在于各取所长：Plan 提供全局视角，ReAct 提供灵活性，Reflection 提供质量保障。缺陷也很明显：复杂度和 Token 消耗都更高。

模式选择指南

任务特点	推荐模式	说明
简单、单步	ReAct	不需要全局规划
复杂多步	Plan-and-Execute	先规划节省 token
高准确性	+Reflection	审阅机制兜底
大型通用	组合模式	三种整合使用

选择的核心原则：不要为不需要的能力买单。简单问答用 ReAct 就够了，加 Reflection 反而增加延迟和成本。只有当你明确遇到"质量不够"的问题时，才叠加更复杂的模式。