ReAct、Plan-Execute、Reflexion三种单Agent架构实战对比与选型指

同一个LLM，用不同架构跑同一个任务，步数、Token消耗和最终质量可能完全不同。Agent架构模式是设计阶段的第一决策，而不是后期调优项。本文围绕三种经典单Agent架构——ReAct、Plan-Execute、Reflexion——从执行流程、代码思路、成本与错误恢复四个维度做实战对比，并给出选型决策矩阵。

说明：本文基于公开论文（如ReAct、Reflexion等）与社区实战资料整理，不宣称引用官方一手文档。文中代码为示意性实现，模型名、SDK版本号均为占位示例，实际使用时请以官方最新文档为准。

一、三种模式的本质区别

ReAct的核心特征是“交替”：Thought（思考）→ Action（行动）→ Observation（观察）→ Thought，每一步行动的结果直接影响下一步思考。它是最灵活的模式。

Plan-Execute的核心特征是“分离”：先制定完整计划，再按计划执行。规划与执行解耦，是最追求效率的模式。

Reflexion的核心特征是“迭代”：执行后反思，反思后改进，形成上升螺旋。它是最质量导向的模式。

一个直观例子：面对“查询三个数据库、对比数据、生成报告”的任务，ReAct约6步、Token中等、中途可调整；Plan-Execute约5步、Token较低、但计划出错时纠正成本高；Reflexion约8步、Token最高、但质量最好。

二、ReAct：推理与行动交替

ReAct由Yao等人于2022年提出，核心是让模型在思考和行动之间交替，观察结果作为下一步思考的输入。

实现要点：System Prompt中定义Thought/Action/Observation格式与可用工具；循环调用模型，若返回tool_calls则执行工具并把结果以tool角色回填；若输出“Final Answer:”则提取返回；用max_steps防止无限循环。

for step in range(max_steps):
    response = client.chat.completions.create(
        model="", messages=messages,
        tools=TOOLS, temperature=0.1)
    msg = response.choices[0].message
    messages.append(msg)
    if "Final Answer:" in (msg.content or ""):
        return msg.content.split("Final Answer:")[-1].strip()
    if msg.tool_calls:
        for tc in msg.tool_calls:
            result = execute_tool(tc.function.name,
                                  json.loads(tc.function.arguments))
            messages.append({"role": "tool",
                             "tool_call_id": tc.id, "content": result})
    else:
        return msg.content

优点：灵活、可中途纠错、逻辑清晰易调试，适合步骤不确定的探索性任务。缺点：多次LLM调用导致Token偏高、串行执行延迟高、可能反复调用同一工具陷入循环、对步骤明确的任务是浪费。

三、Plan-Execute：先谋后动

Plan-Execute把行为分成两个阶段：Plan阶段用强模型生成结构化计划（JSON格式的steps列表，每步含action、params、description），Execute阶段按步骤执行。

关键工程取舍：Plan阶段用强模型保证计划质量，Execute阶段用弱模型执行具体步骤，兼顾质量与成本。计划可审核，人类可在执行前干预。

plan = json.loads(plan_response.choices[0].message.content)
collected_info = []
for step in plan["steps"]:
    if step["action"] == "search":
        result = search_web(**step["params"])
        collected_info.append({"step": step["id"], "result": result})
    elif step["action"] == "summarize":
        summary = client.chat.completions.create(
            model="",
            messages=[{"role": "system", "content": EXECUTE_PROMPT.format(
                step_description=step["description"],
                collected_info=json.dumps(collected_info, ensure_ascii=False))},
                {"role": "user", "content": user_question}],
            temperature=0.1)
        return summary.choices[0].message.content

优点：Token效率高、执行快、步骤可并行、计划可审核、执行阶段可用弱模型降本。缺点：计划出错纠正成本高、不适合探索性任务、环境变化时计划可能过时、需要两套Prompt增加设计复杂度。进阶方向是动态重规划：执行中检测到偏差时触发重新规划，而不是硬走完错误计划。

四、Reflexion：反思驱动改进

Reflexion在ReAct基础上增加自我评估环节：执行完成后评估结果质量，发现遗漏则重新执行相关步骤并更新输出。它适合质量要求极高、允许多次迭代的场景，代价是Token消耗最高、延迟最长。

实现要点：在ReAct循环外再包一层评估循环；评估Prompt要求模型输出“是否满足要求”与“缺失点”；若未满足，把缺失点作为新指令重新进入执行循环；设置最大反思轮数防止不收敛。

五、选型决策矩阵

决策树思路：先问步骤是否可预先确定——否，选ReAct；是，再问质量要求是否极高——是，选Reflexion；否，选Plan-Execute。

六、混合模式：Plan + ReAct

三种模式并非互斥。常见混合方式是外层用Plan-Execute做任务分解，内层每个步骤用ReAct执行——既保留计划的全局效率，又保留单步的灵活调整能力。代价是架构复杂度上升，需要处理两层循环的终止条件与状态传递。

七、适用边界与风险提示

ReAct的风险是循环调用同一工具，必须设置max_steps并监控重复Action。Plan-Execute的风险是计划过时，需要重规划触发条件。Reflexion的风险是迭代不收敛，需要设置最大反思轮数。

版本说明：本文代码为示意性实现，模型名与SDK版本号均为占位示例，实际使用时请以官方最新文档为准。三种架构模式属于Agent工程化的经典设计模式，原理长期有效。

选型一句话建议：步骤不确定用ReAct，步骤明确用Plan-Execute，质量优先用Reflexion，复杂任务用Plan+ReAct混合。