面试题 · Prompt
搜索「大模型 Agent」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
除了ReAct范式外，您还了解哪些其他的AI规划（planning）方法或架构？请比较它们与ReAct的异同点和适用场景。
学习内容与项目面试，在同一条路上。
| 场景特点 | 推荐方案 |
|---|---|
| 工具调用频繁、需实时反馈 | ReAct |
| 解空间大、需探索多种可能 | ToT |
| 步骤明确、追求执行效率 | Plan-and-Execute |
| 长期迭代、需积累经验 | Reflexion |
实际常组合使用：Plan-and-Execute做高层规划 + ReAct做底层执行 + Reflexion做事后优化。
场景切入
假设你在做一个电商客服助手，用户问“帮我查一下订单状态”，你调了接口回复了。接着用户又问“那这个订单能改地址吗？”，你会怎么规划这两个步骤？是每次先思考再行动，还是有别的套路？
层层追问
你平时写 Agent 的时候，怎么做任务规划？……那除了 ReAct 那种边想边做，还有没有别的思路？……比如能不能先把步骤列好再去执行，或者探索多种可能性？
直球架构
除了 ReAct，你还了解哪些 AI 规划方法？比较一下它们的核心机制、和 ReAct 的异同，以及各自适合什么场景，比如 CoT、ToT、Plan-and-Execute 这些。
这道题其实是在问，当我们让模型做多步任务时，是每一步都结合工具反馈决策，还是先想清楚再动手，或者走一步看三步。我理解考察的是对不同规划范式的理解深度，以及能不能根据场景做取舍。
先说最经典的 [[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]]负责一个子任务，通过消息传递协作。这个方案目前还在探索，但我觉得是未来处理复杂工作流的关键。
所以整体上，我不会把任何一种方法当成银弹。我更倾向先分析任务的特性：工具调用频率、步骤确定性、是否需要长期记忆，然后组合一个最轻量的方案。