与其先给系统贴上 ReAct、ReWOO 或 Plan-and-Execute 的标签，不如逐段回答一个更可操作的问题：这一步执行完之后，是否需要让模型观察结果并重新决策？
需要观察，系统更能适应未知结果，但调用次数和上下文成本更高；不需要观察，步骤可以批量或并行执行，但计划错误可能到后期才暴露。
模式名称描述的是观察频率
常见规划方式可以放到同一条连续谱上：
| 方式 | 何时重新决策 | 主要取舍 |
|---|---|---|
| ReAct | 每一步之后 | 适应性强，模型调用多 |
| Plan-and-Execute | 先规划多步，失败时重规划 | 计划可审查，错误发现较晚 |
| ReWOO | 规划器先生成依赖蓝图，收集证据后统一求解 | 中间结果不反复进入模型，依赖计划稳定 |
| Reflexion | 一轮产出后增加独立反思 | 多一次评审成本 |
| Tree-of-Thoughts | 在多个候选节点之间反复比较 | 搜索能力强，分支成本高 |
这些方式不是互斥架构。一个系统可以整体按 ReAct 推进，同时在单轮内并行执行几个互不依赖的工具；也可以先执行稳定步骤，遇到未知结果后再回到模型。
是否返回模型取决于结果的不确定性
如果下一步依赖工具结果，例如搜索后决定读取哪个文件，就必须观察后再决策。若步骤及依赖能够提前确定，例如并行读取三份固定报告，则中间返回模型没有带来新的决策价值。
因此我会检查三个条件：
- 工具结果是否会改变后续步骤；
- 计划能否在执行前做结构校验；
- 计划失败后重新执行的代价是否可接受。
一次性规划并不天然更正确。它只是用“较低的规划错误概率”换取更少模型调用。ReAct 也会判断错误，但通常能在下一次观察时较早修正。
先用可适应路径，再用数据优化
ReAct 是更稳妥的默认方式，因为未知结果会及时反馈。只有评估数据表明某类任务的步骤稳定、计划失败率足够低时，才值得把一段改成批量执行或 ReWOO 式的规划与求解分离。
计划执行前还可以做低成本结构校验：工具是否存在、依赖引用是否完整、占位符是否能够被前序步骤填充。执行中任一步失败，则回到模型重规划，而不是继续消耗在已经失效的后续步骤上。
自我反思也不应等同于可靠评审。执行任务的同一上下文可能已经接受自己的错误假设，重要产出更适合由独立上下文检查。Tree-of-Thoughts 则适合确实需要比较多个候选的任务，不应作为普通流程的默认开销。
我的选择：按局部决策组织混合流程
我不会要求整个 Agent 只属于一种规划模式，而是在流程中标记哪些节点必须观察、哪些节点可以批量、哪些失败会触发重规划。
这会让控制流比单一循环更复杂，但能够把成本优化放在有数据支持的局部。若任务短、环境未知或工具结果高度不稳定，保持逐步观察最合适；只有稳定任务的模型往返成为主要成本时，才减少观察频率。
下一篇讨论如何看清这些分支：一次 Agent 运行为什么应该记录成一棵因果树。
依据说明
ReWOO 的规划器、执行器、求解器结构来自论文 arXiv:2305.18323。论文报告的效率与准确率提升属于作者实验结果，本文未将其视为所有任务上的通用收益。“是否返回模型”是本文对多种模式的工程归纳，不是统一行业定义。