Agent 不只是LLM Tools。LLM 怎么想问题、怎么决定下一步做什么有不同的模式。本篇介绍三种主流模式ReAct边想边做、Plan-and-Execute先想再做、Reflection想完自查。理解它们的区别才能在不同场景下选对模式。一、ReActReasoning Acting边走边算拿到一个信息后推理再调工具再推理循环直到信息足够。Thought推理→ Action执行工具→ Observation观察结果→ 再推理 → … → Final Answer例子用户问今天天气适合徒步吗Thought我需要知道今天的天气情况来判断是否适合徒步Action调用天气查询工具传入城市名Observation返回温度 28°C湿度 60%下午有阵雨Thought下午有阵雨需要知道徒步路线是否有避雨点。还需要查昨天的天气做对比Action调用地图工具查徒步路线设施Observation路线沿途有 3 个避雨亭Thought信息足够可以回答——建议上午出发带雨具Final Answer给出具体建议这个例子展示了 ReAct 的核心特征每一步都在想→做→看→想之间循环直到信息足够才给出最终回答。优点简单直观实现容易适合对话式交互缺点可能死循环Thought→Action 反复停不下来、消耗更多 token、没有全局视角每一步只考虑当前信息适合日常问答、单步工具调用、信息不完整的场景论文Yao et al., 2022, ICLR 2023《ReAct: Synergizing Reasoning and Acting in Language Models》ReAct 循环的工程实现在 Agent Runtime 中ReAct 循环是一个连贯的七阶段流程意图识别判断用户的真实需求是什么理解 Context结合当前上下文和记忆理解完整场景路由Routing决定用哪个 Skill 或 ToolSkill 加载按需加载对应 Skill 指令工具执行执行 Tool等待结果结果观察评估工具返回结果判断结束/继续信息足够 → 生成最终答案不够 → 回到第一步这个七阶段循环是 Agent Runtime 的核心引擎。每次从 7 回到 1都是一次Thought→Action→Observation的完整迭代。ReAct 的死循环问题ReAct 最常被诟病的问题是死循环。Agent 反复想→做→看但永远得不到足够的信息得出结论。工程上常用的应对手段最大迭代次数限制设定硬上限如 10 次超出后强制输出当前结果时间超时机制超过设定时间如 30 秒后中断信息增益检测如果最新 Observation 没有带来新的有效信息提前终止重复动作检测如果 Agent 连续调用同一个工具且参数相同打断循环二、Plan-and-Execute先规划再执行先制定完整计划再逐步执行。vs ReActReAct 是边想边做每步重新推理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 reviewReflection 的变体包括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团队执行ReActQA 验收Reflection。组合模式的优势在于各取所长Plan 提供全局视角ReAct 提供灵活性Reflection 提供质量保障。缺陷也很明显复杂度和 Token 消耗都更高。模式选择指南任务特点推荐模式说明简单、单步ReAct不需要全局规划复杂多步Plan-and-Execute先规划节省 token高准确性Reflection审阅机制兜底大型通用组合模式三种整合使用选择的核心原则不要为不需要的能力买单。简单问答用 ReAct 就够了加 Reflection 反而增加延迟和成本。只有当你明确遇到质量不够的问题时才叠加更复杂的模式。
