ReAct 与 CoT 怎么选？

30 秒回答

1. 明确定义AI Agent与传统LLM的核心区别（自主规划、工具调用、环境交互）
2. 准确描述至少2-3种经典行为模式（ReAct、Plan-and-Solve、Toolformer等）
3. 能对比不同模式的适用场景和优缺点
4. 体现对Agent系统关键组件的理解（规划、记忆、工具、行动）

回答与解析

答案要点

• 明确定义AI Agent与传统LLM的核心区别（自主规划、工具调用、环境交互）
• 准确描述至少2-3种经典行为模式（ReAct、Plan-and-Solve、Toolformer等）
• 能对比不同模式的适用场景和优缺点
• 体现对Agent系统关键组件的理解（规划、记忆、工具、行动）

AI Agent的核心定义

AI Agent是以大模型为"大脑"的自主系统，与传统LLM的本质区别在于：它能主动规划任务、调用工具、与环境持续交互，而非仅做单次文本生成。

关键组件：规划（Planning）→ 记忆（Memory）→ 工具（Tools）→ 行动（Action）

三种经典行为模式

1. ReAct（Reasoning + Acting）

• 核心思想：推理与行动交替进行，"想一步、做一步、看反馈"
• 流程：Thought → Action → Observation → ... → 终止
• 特点：容错性强，适合动态环境；但步骤多、token消耗大
• 代表：LangChain的AgentExecutor

2. Plan-and-Solve（先规划后执行）

• 核心思想：先一次性生成完整计划，再按步骤执行
• 流程：分解任务 → 生成计划 → 顺序执行 → 汇总结果
• 特点：效率高、可解释性好；但计划僵化，遇异常需重规划
• 适用：步骤明确、环境稳定的任务（如数据分析pipeline）

3. Reflexion（自我反思型）

• 核心思想：引入"自我批评"机制，失败后反思并调整策略
• 特点：通过失败学习提升成功率；需要额外LLM调用做评估
• 适用：代码生成、数学证明等可验证任务

选型建议

口语版讲法(约4分钟)

• AI Agent本质是让LLM从被动生成变成主动规划执行
• ReAct模式像边想边做，适合动态环境但token多
• Plan-and-Solve模式像先画好图纸再施工，效率高但僵化
• Reflexion模式加入自我反思，适合代码数学等高精度任务
• 落地常混合使用，需关注工具调用稳定性、记忆管理和异常处理

这道题我觉得核心不是在问Agent的定义，而是考察你对LLM作为决策引擎的理解，怎么把大模型从一个只会接话的聊天机器人，变成一个能主动干活、调用工具、甚至自我纠错的智能体。我理解AI Agent本质就是让LLM拥有规划、记忆、工具和行动这四个组件，让它可以自主地拆解任务、执行步骤、观察反馈，而不是每次只生成一句话。

常见的Agent行为模式，我重点讲三种，因为实际落地时你会根据场景混着用。

先说ReAct，这是最直观的，推理和行动交替进行。你可以想象成一个人边想边做：先想一步，然后执行一个动作，看看发生了什么，再根据观察结果想下一步。这种模式容错性很强，环境变化了也能动态调整，但代价是token消耗大，步骤一多就容易跑偏或陷入死循环。所以它特别适合开放域问答、需要频繁调外部工具的场景，比如让Agent去查数据库、调API。但如果你用它做固定流程的任务，比如每天跑同一个报表，那每一步都要反复思考，反而浪费。

第二种是Plan-and-Solve，先规划后执行。这就像写代码前先画架构图，任务分解成清晰的步骤，然后一步一步执行。好处是效率高、解释性强，因为计划是可见的，出了问题容易定位。但缺点也很明显，计划一旦定下来就很僵化，执行中如果遇到意外，比如API返回格式变了，它不会灵活调整，只能重新规划。所以它更适合步骤明确、环境稳定的任务，比如数据处理pipeline或者定时报表生成。

第三种是Reflexion，自我反思型。这相当于给Agent加了一个批评家角色：做完一步或完成整个任务后，让模型自己评估结果对不对，如果错了就记录失败原因，下次绕开这个坑。这种模式在代码生成、数学证明这类可验证的任务上效果很好，能显著提升成功率。但代价是每次反思都要额外调用LLM，成本更高。

说到落地，其实很少只用一种模式，真正上线往往是混合使用。比如一个客服退款Agent，我会先用Plan-and-Solve做一个主流程，判断订单状态、计算退款金额、发起退款，但中间每一步都穿插ReAct的动态检查：比如调用订单API后，如果发现订单异常或用户有特殊备注，就临时切换到ReAct模式去跟用户确认。另外，遇到退款失败的情况，我会让Agent进入Reflexion模式，让它自己分析失败原因是参数错误还是权限不足，并尝试修正。

这里有个很重要的前提：Agent的可靠性高度依赖工具调用的稳定性。如果工具API不稳定，或者返回格式不统一，再好的规划也白搭。所以上线前我会特别关注工具调用的超时重试、错误码处理，以及Agent的异常恢复机制，比如连续失败多少次后应该主动上报人工。另外，记忆管理也是个大坑，长对话中Agent容易忘记前面的上下文，需要设计好短期记忆和长期记忆的切换策略。

还有一个方向我最近比较关注，就是Multi-Agent协作。当单个Agent面对复杂任务时，往往需要多个专业Agent分工，比如一个负责规划、一个负责检索、一个负责验证。但如何协调它们之间的通信和冲突，目前还没有特别成熟的方案，这也可能是未来Agent落地的关键瓶颈。

所以总的来说，我会把Agent模式看成一种工具箱，ReAct灵活但重、Plan-and-Solve轻但死板、Reflexion聪明但贵，我的工程判断是：优先用Plan-and-Solve搭骨架，用ReAct填充动态环节，用Reflexion兜底关键错误。如果环境足够稳定，甚至可以只用Plan-and-Solve加少量规则，把LLM调用降到最低。

关键一句:Multi-Agent协作是当前Agent落地的关键瓶颈，协调通信和冲突没有成熟方案

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你在做一个智能客服Agent，用户问‘帮我查订单’，它得先调用订单接口，然后根据结果可能再问用户确认。这个过程里Agent怎么决定下一步做什么？你理解Agent和普通LLM填空有什么区别？

2. 问法 2 · 层层追问

   你平时怎么用LLM做多步任务？……如果任务要调用外部工具，比如查数据库或者发请求，你怎么设计这个流程？……更具体一点，你会选哪种行为模式？ReAct和Plan-and-Solve各自适合什么场景？

3. 问法 3 · 直球架构

   请直接阐述你对AI Agent的理解，并列举至少两种经典行为模式，比如ReAct和Plan-and-Solve，对比它们的特点、优缺点和适用场景。