ReAct 之外还有哪些规划方法?

30 秒回答

1. 能列举至少3种非ReAct的规划方法（如CoT、ToT、Plan-and-Execute、Reflexion等）
2. 准确描述每种方法的核心机制
3. 清晰对比与ReAct的异同（单步vs多步、是否显式规划、是否带反思等）
4. 能根据场景特点给出选型建议

回答与解析

答案要点

• 能列举至少3种非ReAct的规划方法（如CoT、ToT、Plan-and-Execute、Reflexion等）
• 准确描述每种方法的核心机制
• 清晰对比与ReAct的异同（单步vs多步、是否显式规划、是否带反思等）
• 能根据场景特点给出选型建议

主流规划方法对比

1. Chain-of-Thought (CoT)

• 核心：显式生成中间推理步骤，"Let's think step by step"
• vs ReAct：纯推理无行动，无外部工具调用；适合纯文本推理任务
• 适用：数学计算、逻辑推理、代码生成

2. Tree-of-Thoughts (ToT)

• 核心：维护多候选推理路径，主动评估+剪枝/扩展
• vs ReAct：广度优先搜索 vs 深度优先；显式探索解空间
• 适用：创意写作、数学证明、需要探索的开放问题

3. Plan-and-Execute

• 核心：先全局规划再执行，解耦"规划"与"执行"
• vs ReAct：ReAct是交错进行（think-act-observe循环），Plan-and-Execute是先完整规划
• 适用：复杂多步骤任务（如旅行规划）、需要成本预估的场景

4. Reflexion

• 核心：执行后自我反思，将失败经验写入记忆
• vs ReAct：ReAct是即时反思，Reflexion是事后总结+长期记忆
• 适用：需要持续学习的长期任务、代码生成优化

选型建议

实际常组合使用：Plan-and-Execute做高层规划 + ReAct做底层执行 + Reflexion做事后优化。

口语版讲法(约4分钟)

• 定位问题本质：规划方法与工具调用范式的取舍
• 四种方法的核心差异与边界划分
• 业务场景举例：企业IT运维中的告警处理
• 落地风险与组合使用策略
• 工程师的判断与收尾可延伸点

这道题其实是在问，当我们让模型做多步任务时，是每一步都结合工具反馈决策，还是先想清楚再动手，或者走一步看三步。我理解考察的是对不同规划范式的理解深度，以及能不能根据场景做取舍。

先说最经典的 Chain-of-Thought，它就是让模型显式写出推理步骤，但只限于文本，不调用任何外部工具。它的强项是纯推理，比如数学题或者逻辑推导。但有个明显的边界：一旦任务需要跟外部系统交互，比如查数据库或调用API，CoT就完全不行。所以它只适合封闭的推理场景。

再一个就是 Tree-of-Thoughts，它维护多条候选路径，主动评估哪些分支有希望，然后剪枝或扩展。你可以理解为广度优先搜索，而 ReAct 是深度优先。ToT 适合解空间大、需要探索多种可能性的开放问题，比如创意写作或者数学证明。但代价是计算开销大，因为每步都要生成并评估多个候选。

然后是 Plan-and-Execute，这个很直观：先做一个全局规划，分解成步骤，然后按顺序执行，执行过程中不重新规划。跟 ReAct 最大的区别是，ReAct 是思考-行动-观察循环，每一步都基于反馈调整；而 Plan-and-Execute 是一锤子买卖，规划完就不改了。所以它适合步骤明确、执行效率优先的场景，比如旅行规划，或者生成一个固定流程的文档。

最后是 Reflexion，它强调事后反思：执行完任务后，如果失败了，把失败原因写进记忆，下次遇到类似问题就能避免。而 ReAct 的反思是即时的，当前步错了当前步调整，不会沉淀为长期经验。Reflexion 适合需要持续学习的长期任务，比如代码生成优化，反复调试直到通过测试。

举个例子，假设我们做一个企业IT运维的智能助手，处理告警。如果告警是磁盘空间不足，需要查监控、分析历史、发通知，这种步骤明确的任务，我会先用 Plan-and-Execute 做高层规划，比如第一步查监控数据，第二步分析趋势，第三步发告警。但执行过程中，如果第一步查到的数据异常，比如磁盘空间突然暴涨，就需要 ReAct 的实时反馈来调整后续步骤，比如临时改为查进程列表。如果这个场景反复出现，比如每周都有磁盘告警，那就再叠一层 Reflexion，让模型记住上次失败是因为没考虑日志轮转策略，下次自动加上这个检查。

这里有个坑：很多人觉得 ReAct 万能，但其实它对工具调用的质量要求很高。如果工具返回的信息噪声大或者延迟高，ReAct 的实时反馈反而会引入错误。而且 ReAct 每一步都调LLM，成本高、延迟大。所以落地时我通常会组合使用：Plan-and-Execute 做骨架，ReAct 做局部微调，Reflexion 做离线优化。

我最近在关注一个方向：当任务依赖多个外部系统时，比如既要查数据库又要调API，ReAct 的规划能力会受限于模型的上下文窗口，这时候怎么分治？我倾向于引入 Multi-Agent 架构，每个Agent负责一个子任务，通过消息传递协作。这个方案目前还在探索，但我觉得是未来处理复杂工作流的关键。

所以整体上，我不会把任何一种方法当成银弹。我更倾向先分析任务的特性：工具调用频率、步骤确定性、是否需要长期记忆，然后组合一个最轻量的方案。

关键一句:任务依赖多个外部系统时，ReAct受限于上下文窗口，需要引入Multi-Agent分治协作。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你在做一个电商客服助手，用户问“帮我查一下订单状态”，你调了接口回复了。接着用户又问“那这个订单能改地址吗？”，你会怎么规划这两个步骤？是每次先思考再行动，还是有别的套路？

2. 问法 2 · 层层追问

   你平时写 Agent 的时候，怎么做任务规划？……那除了 ReAct 那种边想边做，还有没有别的思路？……比如能不能先把步骤列好再去执行，或者探索多种可能性？

3. 问法 3 · 直球架构

   除了 ReAct，你还了解哪些 AI 规划方法？比较一下它们的核心机制、和 ReAct 的异同，以及各自适合什么场景，比如 CoT、ToT、Plan-and-Execute 这些。