从“边想边干”到“先规划再执行”，再到“自我检查修正”的工程落地指南

很多人第一次接触 Agent 范式时，会把 ReAct、Plan-and-Execute、Reflection 当成三个并列方案，然后纠结到底哪个更先进。这个理解很容易跑偏。

更准确的是：ReAct 和 Plan-and-Execute 解决的是“任务怎么推进”；Reflection 解决的是“结果怎么变好”。前两者是主流程，后者是质量增强层。

所以选型不是三选一，而是看任务复杂度、流程确定性、输出质量要求、延迟和成本，再决定是单用一种，还是组合使用。

简单探索用 ReAct，复杂长流程用 Plan-and-Execute，高质量交付再加 Reflection。

一、ReAct：边想边干，走一步看一步

ReAct 的核心是把推理和行动交织在一起：先想一下当前应该做什么，再调用工具或执行动作，然后根据观察结果继续想下一步。

它非常像一个经验丰富的外卖骑手：不是出发前把每个红绿灯都规划死，而是边走边看，遇到封路就换路线，发现商家没出餐就等待或联系用户。

ReAct 的优点很明显：实现简单，灵活，过程透明，调试时能看到每一步为什么调用工具。它适合流程不固定、需要实时探索的任务，比如信息检索、客服助手、简单数据查询、日常工具型 Agent。

但短板也很明显：任务越长，历史上下文越重；每一步都只看当前局部，容易走偏；如果工具结果不稳定，还可能陷入重复调用。

ReAct 最小代码骨架可以写成这样：

def run_react_agent(task, tools, max_steps=8):

history = []

for step in range(max_steps):

decision = llm_decide_next_action(

task=task,

history=history,

tools=tools,

)

if decision.action == "finish":

return decision.answer

observation = execute_tool(

name=decision.tool_name,

arguments=decision.tool_args,

)

history.append({

"thought": decision.thought,

"action": decision.action,

"observation": observation,

})

return "任务未在最大步数内完成，需要降级或转人工。"

这段代码的关键不是循环本身，而是三个护栏：max_steps 防止死循环，tools 必须白名单，observation 最好结构化保存，方便回放和排查。

二、Plan-and-Execute：先规划，再分步执行

Plan-and-Execute 是为了解决 ReAct 长任务容易跑偏的问题。它先用 Planner 把目标拆成完整计划，再交给 Executor 按步骤执行，最后汇总结果。

它像项目经理做项目：先拆需求、排计划、定里程碑，再让不同同学分别执行。这样好处是全局目标更清楚，执行链路更可控。

工程上最实用的一点是：规划和执行可以用不同模型。规划阶段需要强推理，可以用大模型；执行阶段任务已经很具体，可以用便宜的小模型或规则工具。这样不一定减少 token 数，但能明显降低实际花费。

Plan-and-Execute 的典型代码骨架如下：

def run_plan_execute_agent(task, tools):

plan = planner_llm.create_plan(task, tools)

context = {}

for step in plan.steps:

result = executor.run(

instruction=step.instruction,

tools=tools,

context=context,

)

context[step.id] = result

if should_replan(task, plan, step, result):

plan = planner_llm.replan(

task=task,

finished=context,

remaining=plan.remaining_after(step.id),

)

return writer_llm.summarize(task, context)

这套结构适合长流程、多步骤、目标明确的任务，比如行业调研、竞品分析、代码生成、项目开发、复杂报表分析。

它的代价是实现更复杂，计划如果一开始拆错，后面会跟着错。所以生产环境通常会加动态 Replan：每完成关键步骤后，判断剩余计划是否还合理。

三、Reflection：不是独立流程，而是质量增强 Buff

Reflection 的定位一定要说清楚：它不是第三种完整流程，而是加在 ReAct 或 Plan-and-Execute 外面的检查层。

它做的事很像写完文章后的自查：有没有事实错误？逻辑有没有断？格式是否满足要求？关键边界条件有没有漏？如果不合格，就把问题交给模型重新改。

最小实现可以是一个包装器：

def with_reflection(task, draft_agent, max_rounds=2):

draft = draft_agent.run(task)

for _ in range(max_rounds):

review = critic_llm.check(

task=task,

answer=draft,

criteria=["事实准确", "逻辑完整", "格式满足", "风险提示"],

)

if review.passed:

return draft

draft = reviser_llm.rewrite(

task=task,

old_answer=draft,

issues=review.issues,

)

return draft

Reflection 适合高要求场景，比如生成生产代码、严肃技术报告、投研分析、法律材料、对外发布内容。它能提升质量，但会增加调用次数、延迟和 token 消耗，所以必须设置最大反思轮次。

四、三种范式的核心区别

对比三者，不能只看“谁更强”，要看它们解决的问题层次。ReAct 解决单步灵活性；Plan-and-Execute 解决长任务全局规划；Reflection 解决输出质量。

五、进阶：动态 Replan 与 Reflexion

动态 Replan 解决的是 Plan-and-Execute 的僵硬问题。计划不是一成不变的，每执行完关键步骤，都可以让 Planner 判断剩余计划是否还适合当前情况。

Reflexion 则比普通 Reflection 更进一步：它不仅改答案，还会把失败原因写入记忆。下次遇到类似任务时，模型先读取这些经验，再做决策。它像工程师的“错题本”。

二者不要混淆：Replan 是改“接下来怎么做”；Reflexion 是记住“上次为什么错”。一个管当前任务，一个管跨任务经验。

六、成本视角：Token 消耗不是小问题

Agent 不只是效果问题，也是成本问题。一个 5 步任务，如果每一步都把完整历史带回模型，ReAct 的输入上下文会越来越长；而 Plan-and-Execute 可以让执行步骤只拿当前指令和必要结果摘要。

这也是为什么很多生产系统会先用 ReAct 快速验证，再根据日志把长任务迁移成 Plan-and-Execute。不是因为 ReAct 不好，而是长任务下它的上下文和成本增长更明显。

Reflection 也不是越多越好。建议只在关键节点加，比如最终报告交付前、代码提交前、工具动作高风险前。

七、选型指南：从问题出发，不要为了炫技堆架构

实际选型可以按 4 个问题判断：任务是否很长？流程是否不确定？输出是否不能错？执行过程中是否经常遇到意外？

经验口诀：

任务短、探索性强：用 ReAct。

任务长、步骤多、目标清晰：用 Plan-and-Execute。

输出要求高、不能错：在前两者基础上加 Reflection。

环境变化大、计划容易过时：加动态 Replan。

同类任务反复做、能从失败中学习：引入 Reflexion 记忆。

八、生产环境最常见的组合架构

真正落地时，很少是纯 ReAct 或纯 Plan-and-Execute。更常见的是混合：Plan 负责全局拆解，ReAct 负责单步执行，Reflection 负责质量验收。

比如“自动生成一份竞品分析报告”：先用 Planner 拆出资料收集、维度提炼、对比分析、风险结论；每一步内部用 ReAct 调搜索、数据库、文档检索等工具；最终报告用 Reflection 做事实核查、逻辑检查和格式检查。

这套组合能兼顾全局稳定性、局部灵活性和最终质量。缺点是复杂度上升，所以必须有工程护栏。

九、总结

ReAct 是 Agent 的基础动作循环，适合快速启动和灵活探索。

Plan-and-Execute 是复杂任务的稳定器，把大目标拆成清晰步骤，避免越走越偏。

Reflection 是质量增强器，不负责推进任务，而是负责发现问题、修正问题。

动态 Replan 是对 Plan-and-Execute 的补强，Reflexion 是对 Reflection 的长期记忆升级。

所以真正的工程答案不是“哪个最好”，而是“先用最简单的方案跑通，再根据复杂度、成本、质量逐层加能力”。