ReAct、Plan-Execute、Reflexion——Agent 怎么"思考-行动"

你有没有想过 Agent 在"干活"的时候，脑子里到底在转什么？

大多数人第一次看到 Agent 的时候会有个直觉错误：以为它是"收到指令→想清楚→一次性输出答案"，就像一个超级聊天机器人。但真实的 Agent 根本不是这样工作的。它不是一次性给答案，它在"想-做-看"的循环里逼近目标。

问题来了：怎么"想"？怎么"做"？循环长什么样？

这里没有一个固定答案——多年来研究者和工程师摸索出了几种主流的"思考-行动范式"，每种有自己的节奏和适合场景。这一节我们把三种最常见的范式拆开讲清楚：ReAct、Plan-Execute、Reflexion——不是给你背定义，是让你看懂它们各自的内部齿轮怎么转，以及你碰到一个真实任务时该抓哪个。

---

为什么需要"思考-行动范式"

在聊具体范式之前，先理解为什么这件事值得专门讲。

把 Agent 和 Chatbot 的本质区别先摆出来（AI Agent 是什么 里讲了这个）：Chatbot 是"一问一答"，Agent 是"自主循环"。但"自主循环"本身是个很模糊的说法——循环里到底在做什么？什么时候停？出了错怎么处理？

这就是范式要解决的问题。范式规定了：

• 思考的结构：每步要想什么、想多深、想多远
• 行动的时机：什么时候触发工具调用、什么时候先想好再动
• 反馈的用法：工具执行结果怎么进入下一轮决策

不同任务对这三点的要求差异很大，这就是为什么有多种范式共存。

---

ReAct：想一步，做一步，看结果，再想

机制

ReAct 是"Reason + Act"的缩写，论文名字直接告诉你核心思路：交替推理（Reason）和行动（Act）。

每一轮循环长这样：

[Thought] 我现在掌握的信息是 X，我认为下一步应该做 Y，因为 Z
[Action]  调用工具 Y，参数是 ...
[Observation] 工具返回了结果 R
[Thought] 根据 R，我发现 ..., 下一步应该 ...
[Action]  ...
（重复，直到任务完成）

关键点是：每次 Thought 只基于当前已知信息推理下一个单步行动，不试图规划整条路。做完一步，把结果看完，才决定下一步。

伪代码示意：

messages = [{"role": "user", "content": task}]
while True:
    response = llm.call(messages, tools=available_tools)
    if response.stop_reason == "end_turn":
        return response.text          # 任务完成，退出
    if response.stop_reason == "tool_use":
        result = execute_tool(response.tool_call)
        messages.append(response)     # 把 Thought+Action 存进历史
        messages.append(tool_result)  # 把 Observation 存进历史
        # 循环回去，让模型看结果再想下一步

这就是 Claude Agent SDK 里最小可跑 Agent 的骨架。每一轮 messages 越来越长，模型能看到完整历史，每步都在"当前信息基础上"做决定。

适合什么任务

• 信息不确定、结果要一步步验证：比如查资料写报告，不知道搜到什么才停
• 短到中等步骤：3-8 步以内
• 任务路径依赖实际结果：你不知道第三步要做什么，因为取决于第二步的查询结果

优缺点

优点：

• 实现简单，一个 while 循环搞定
• 对意外情况自适应强——结果出乎意料时能即时调整路线
• 透明度高，每步 Thought 都记录在案，可追溯

缺点：

• 步骤多时上下文暴涨，成本和延迟线性增加
• 没有全局规划，可能走弯路（每步局部最优不等于全局最优）
• 复杂长任务容易"走着走着偏了"

---

Plan-Execute：先想清楚，再分头干

机制

Plan-Execute 的核心思路是把"规划"和"执行"分开，不让它们混在同一个循环里互相干扰。

分两阶段：

第一阶段：Plan（规划）

输入任务 → 模型生成完整执行计划
计划 = [步骤1, 步骤2, 步骤3, ..., 步骤N]

第二阶段：Execute（执行）

for 步骤 in 计划:
    结果 = 执行该步骤（可能调工具、可能调子Agent）
    存入结果集
最终综合所有结果 → 输出答案

伪代码示意：

# 阶段一：规划
plan = llm.call(f"为以下任务制定执行步骤：{task}")
steps = parse_steps(plan)   # ["搜索X", "整理Y", "分析Z", "生成报告"]

# 阶段二：逐步执行
results = []
for step in steps:
    result = execute_step(step, context=results)
    results.append(result)

# 最终综合
final = llm.call(f"综合以下结果，完成任务：{results}")

有些实现会在执行过程中加"重规划"——如果某步结果偏差太大，触发局部重新规划。但核心逻辑是：先想好全局，再分步落实。

适合什么任务

• 任务结构相对固定：能提前知道大致需要哪几类工作
• 长链任务（10步以上）：提前规划比走一步看一步更不容易偏
• 需要并行执行：各步骤之间依赖关系清晰，可以同时跑多个子任务
• 大型代码工程、研究报告、多数据源汇总：结构已知，执行要系统

优缺点

优点：

• 全局视野，不容易走弯路
• 步骤解耦，可以并行化提速
• 规划阶段可以人工介入检查，再放行执行

缺点：

• 规划依赖"任务结构可预知"，遇到高度不确定任务时计划容易失效
• 执行中途遇到意外，要么硬撑计划（产生错误），要么触发代价高昂的重规划
• 规划质量高度依赖模型对任务的理解，有时生成的步骤颗粒度不对

---

Reflexion：做完了，反省一下，改了再来

机制

Reflexion 的核心是给 Agent 加一个"自我反思"环节：不只是执行，执行完了要评估自己做得好不好，从失败中提炼改进点，然后带着这个反思重试。

循环结构：

[执行一次尝试] → 
[自我评估：成功了吗？哪里出了问题？] → 
[如果不满意：生成反思 + 改进思路] → 
[带着反思再试一次] → 
[重复，直到满足质量标准或达到最大尝试次数]

伪代码示意：

reflections = []
for attempt in range(max_attempts):
    # 执行（可以是 ReAct 循环，也可以是简单生成）
    output = react_loop(task, context=reflections)
    
    # 自我评估
    score, feedback = evaluator.assess(task, output)
    if score >= threshold:
        return output   # 满意，退出
    
    # 生成反思
    reflection = llm.call(
        f"任务：{task}\n我的输出：{output}\n问题：{feedback}\n"
        f"下次应该怎么改进？"
    )
    reflections.append(reflection)
    # 带着历次反思继续下一轮尝试

关键是 reflections 这个列表——它不是单次任务的历史，而是跨越多次尝试的经验积累。每次失败都沉淀成一条"我上次在哪踩坑了"的记忆，下一轮能看到。

适合什么任务

• 有明确质量评估标准：必须能判断"做得好不好"，否则反思无从入手
• 代码生成/调试：跑一下，报错了，反思错在哪，改了再跑
• 需要精度迭代的写作：有评分标准，允许多轮改稿
• 竞赛题、数学推理：有确定正确答案，反思很好用

优缺点

优点：

• 从失败中学习，而不是重头再来——每次尝试不浪费
• 对需要高精度输出的任务效果显著
• 可以捕获"系统性偏差"：不只是当次错误，而是识别出一类错误模式

缺点：

• 需要可靠的评估器（evaluator）——这个不好做
• 多轮尝试成本高（每轮都是一次完整执行）
• 如果反思生成质量差（比如模型把原因归结错了），下轮会越跑越偏

---

三种范式处理同一任务：对比

用一个具体任务来感受三者差异：

任务： "帮我调研竞品 A、B、C 的定价策略，整理成一份对比报告，给出我们的定价建议。"

---

ReAct 的处理路径：

[Thought] 先搜竞品 A 的定价信息
[Action]  web_search("竞品A 定价 2024")
[Observation] 搜到几条信息：A 是订阅制，基础版 $29/月，专业版 $99/月

[Thought] 有了 A 的数据，接下来搜 B
[Action]  web_search("竞品B pricing")
[Observation] B 是按用量收费，$0.01/次调用

[Thought] B 和 A 模式差异大，有趣。再搜 C
[Action]  web_search("竞品C 价格")
[Observation] C 免费开源，靠企业服务收费

[Thought] 三家数据都有了，现在可以整理对比并给建议了
[Action]  (直接生成报告)

特点：每步基于上一步结果，路径自然弯曲——如果搜 B 的时候意外发现有新竞品 D，可以即兴追一下。

---

Plan-Execute 的处理路径：

[Plan阶段]
步骤1: 搜索竞品A定价策略
步骤2: 搜索竞品B定价策略
步骤3: 搜索竞品C定价策略
步骤4: 整理三者对比表格
步骤5: 分析定价模型差异
步骤6: 生成定价建议

[Execute阶段]
→ 步骤1、2、3 并行执行（三个搜索工具同时调）
→ 汇总结果，执行步骤4
→ 执行步骤5、6

特点：可以并行搜三家，效率更高；但如果搜索返回的信息不够，没有"即兴追踪"的空间——计划是定好的。

---

Reflexion 的处理路径（假设结合 ReAct 做第一轮）：

[第一轮尝试] 生成报告v1
[自我评估]   "定价建议太笼统，没有考虑我们的成本结构；B竞品数据不够新"
[反思]       "下次搜索要加时间过滤，定价建议要基于具体假设"
[第二轮尝试] 带着反思，重新搜索 B，重新生成建议（加入成本假设）
[自我评估]   "更扎实了，建议有了数字依据"
→ 输出报告v2

特点：输出质量更高，但要多跑几轮——如果一次报告就够用，Reflexion 的代价显得不值。

---

什么任务用哪种范式

直接给结论，可以用做日常判断的参考：

任务特征	推荐范式	原因
信息不确定，步骤数少（<8步）	ReAct	灵活、简单、自适应
任务结构清晰，步骤多（>10步），可并行	Plan-Execute	全局规划、可并行化
有明确质量标准，允许多轮迭代	Reflexion	从失败中精进
写代码/调试，需要跑通为止	Reflexion	有确定验证标准（跑通=成功）
实时信息查询，结果决定路径	ReAct	每步依赖上步结果
长篇研究报告，多数据源汇总	Plan-Execute	结构已知，各部分相对独立
需要高精度输出（分析报告、评审）	ReAct + Reflexion 混用	先跑通，再反思提质

两个关键问题帮你判断：

1. "任务路径要到执行中才知道吗？" → 是的 → ReAct 优先
2. "有没有办法评估输出好不好？" → 有 → 考虑 Reflexion

---

真实 Agent 常常混用

上面的三种范式在论文和教程里通常是分开介绍的，但生产环境里的 Agent 几乎不会只用一种。

几种常见的混用组合：

ReAct + Reflexion： 先用 ReAct 跑一遍，用 Reflexion 的自我评估层判断质量，不满意就改进重跑。适合需要高质量输出但又无法提前规划路径的任务。

Plan-Execute + ReAct： 用 Plan-Execute 做整体骨架，每个执行步骤内部用 ReAct 处理细节的不确定性。"大纲我规划，每章怎么写你自己想"——外层结构化，内层灵活。

Plan-Execute + Reflexion： 执行完一版计划，整体反思计划有没有偏差，下次重新规划。适合周期性任务。

关键判断依据是：你的任务在哪个层面上有不确定性？

• 步骤层面不确定 → 那层用 ReAct
• 全局结构确定 → 外层用 Plan-Execute
• 输出质量需要迭代 → 加 Reflexion

如果你接触过 LangGraph 或类似框架，你会发现它们的核心就是让你自由组合这些循环结构——理解了这三种范式，框架选型时你就有了判断骨架。子代理和多 Agent 编排 也是建立在这个基础之上的。

---

增量视角：思考-行动范式不只是 Agent 设计，也是 prompt 设计

这三种范式还有一个容易被忽视的用法：在 prompt 层面模拟范式，不一定要写完整 Agent。

比如，你写一个 prompt 让模型先生成"执行计划"再逐步完成，本质上是 Plan-Execute 的思想；让模型"先做一版，自我批评，再输出最终版"，是 Reflexion 的思想；让模型"边想边写、每步注明依据"，是 ReAct 的思想。

从 prompt 到 Agent，是同一套思维的不同实现层级——先理解机制，再决定在哪一层实现它。

---

常见问题

Q：我刚开始做 Agent，应该从哪个范式入手？

ReAct。理由：实现最简单（一个 while 循环），覆盖大多数任务，调试也最直接——每步 Thought 都是明文记录，出了问题哪步出的一眼就看到。最小可跑 Agent 那节的代码就是标准 ReAct 骨架。先跑通 ReAct，再按需考虑是否需要升级到其他范式。

Q：Plan-Execute 里"规划"这步很关键，模型做不好规划怎么办？

两个方向：一是提升规划 prompt 的质量，明确要求步骤数、每步粒度、依赖关系；二是让人工介入规划审核再放行执行——这恰恰是 Plan-Execute 相对 ReAct 的优势之一，执行前的计划是可读可修改的。如果任务足够标准化，也可以用固定模板限定规划结构。

Q：Reflexion 的"自我评估"如果模型评错了，反思会越走越偏，怎么防？

几种手段：①让评估者和执行者用不同的 prompt 甚至不同模型，降低自我欺骗风险；②对于有客观验证标准的任务（比如代码能否跑通、答案是否正确），用程序化评估替代模型自评；③设定最大重试次数，防止无限循环；④保留所有尝试历史，人工复查时可以追溯每次反思写了什么。Reflexion 最好配"有标准的任务"，模糊任务自我评估容易变成随机游走。

Q：这三种范式之外还有别的吗？

有。比如 Tree of Thoughts（让模型同时探索多条推理路径，取最优）、MCTS 风格的树搜索等。但这些在工程实践中相对少见，复杂度也高很多。三种主流范式覆盖了 80%+ 的实际场景，先把这三种用熟，遇到特殊需求再扩展。

Q：Agent 的四要素 和这里的范式是什么关系？

四要素（模型/工具/记忆/评估）是 Agent 的"零件"，范式是"零件的组装方式"。同样的四个零件，用 ReAct 组装和用 Plan-Execute 组装出来的行为模式完全不同。理解四要素是理解"有什么"，理解范式是理解"怎么用"。

---

小结

• ReAct：想一步做一步，最常用，灵活，适合路径未知的短到中等任务
• Plan-Execute：先规划再执行，适合结构清晰的长链任务，可并行
• Reflexion：做完反思改进再试，适合有质量标准、允许迭代的任务
• 三者不互斥，真实 Agent 常混用，判断标准是"哪层有不确定性"
• 入门先从 ReAct 开始，它是其他一切的基础

如果想看范式怎么落进实际代码，翻 用 Claude Agent SDK 写出第一个能跑的 Agent——那节里的 while 循环就是 ReAct 的最简实现。对 Agent 的完整知识体系感兴趣，可以去 AI Agent 学习路径 从全局看清节点顺序。

👉 看看 AI 数字员工落地指南，或了解 数字员工搭建实战课。需要为企业落地方案，欢迎找我们聊 企业服务。