完整题目
除了ReAct范式外，您还了解哪些其他的AI规划（planning）方法或架构？请比较它们与ReAct的异同点和适用场景。
本文目录
答案要点
- 能列举至少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是事后总结+长期记忆
- 适用：需要持续学习的长期任务、代码生成优化
选型建议
| 场景特点 | 推荐方案 |
|---|---|
| 工具调用频繁、需实时反馈 | ReAct |
| 解空间大、需探索多种可能 | ToT |
| 步骤明确、追求执行效率 | Plan-and-Execute |
| 长期迭代、需积累经验 | Reflexion |
实际常组合使用：Plan-and-Execute做高层规划 + ReAct做底层执行 + Reflexion做事后优化。
换一种问法，检查是否真正理解
场景切入
假设你在做一个电商客服助手，用户问“帮我查一下订单状态”，你调了接口回复了。接着用户又问“那这个订单能改地址吗？”，你会怎么规划这两个步骤？是每次先思考再行动，还是有别的套路？
层层追问
你平时写 Agent 的时候，怎么做任务规划？……那除了 ReAct 那种边想边做，还有没有别的思路？……比如能不能先把步骤列好再去执行，或者探索多种可能性？
直球架构
除了 ReAct，你还了解哪些 AI 规划方法？比较一下它们的核心机制、和 ReAct 的异同，以及各自适合什么场景，比如 CoT、ToT、Plan-and-Execute 这些。
练习口述回答 · 约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]]负责一个子任务，通过消息传递协作。这个方案目前还在探索，但我觉得是未来处理复杂工作流的关键。