考察点
这道题出自阿里淘天技术岗暑期实习一面，问法很有水平：不只问「是什么」，还问「什么时候不合适」。面试官想确认你理解 ReAct 的真正价值不是「更聪明的推理」，而是推理与外部世界交互的交替结构，并且清楚这个结构引入的代价——延迟、token 消耗、对工具质量的依赖。能主动说出反面场景，说明你真在生产环境权衡过，而不是只读过论文。
参考答案
先把两者讲准
CoT（Chain-of-Thought） 是让模型把推理过程显式写出来再下结论，整个推理链完全发生在模型的「脑内」——所有中间步骤都是模型自己生成的文本，不与任何外部信息源交互。
ReAct（Reason + Act） 是把推理和行动交织成循环：Thought（分析当前状况、规划下一步）→ Action（调用工具：搜索、查库、执行代码）→ Observation（拿到工具返回的真实结果）→ 基于新信息继续 Thought，直到能给出 Final Answer。推理链里嵌入了来自外部世界的真实数据。
ReAct 的三个实质优势
第一，事实 grounding，直接压幻觉。 CoT 的推理链再漂亮，事实性内容（某 API 的参数、最新股价、内部系统的订单状态）还是靠模型参数里的记忆，记忆错了推理就是空中楼阁——而且 CoT 会让错误答案显得理直气壮，「一本正经地编」比不推理更危险。ReAct 把事实类问题外包给工具：搜索引擎、数据库、计算器，答案建立在 Observation 的真实返回上。经典论文里的对比就是：纯 CoT 在知识密集型问答上幻觉率高，ReAct 显著更低。
第二，可追溯、可干预。 ReAct 的每一步 Action/Observation 都是结构化、可记录的。线上排查时你能看到 Agent 查了哪个接口、传了什么参数、拿到了什么返回——哪一步错了清清楚楚。CoT 的中间推理是模型自言自语，错了你只能看到结果错，没法定位。生产系统里这个差异是致命的。
第三，能处理动态和多步骤任务。 「查一下这笔订单物流到哪了，如果延迟超过 48 小时就帮用户申请补偿」——这种需要拿真实状态做分支决策的任务，CoT 结构上就做不了，ReAct 的循环天然适配。
反面场景：ReAct 什么时候不合适
纯推理任务不需要工具时，ReAct 是负优化。 数学证明、逻辑推演、代码逻辑分析这类封闭域推理，没有外部信息可查，强行套 ReAct 只是徒增循环开销。而且这种任务上 CoT 的推理链反而可以更纯粹（现在推理模型的长 CoT 路线就是证明：把算力花在更长的内部推理上，比来回调工具有效）。
延迟敏感场景。 ReAct 每个循环轮次 = 一次 LLM 调用 + 一次工具执行，五轮任务可能就是十几次串行调用，延迟十秒起步。实时对话、客服首响有 SLA 的场景，要么用确定性 workflow 把流程写死，要么单轮 Function Calling 解决，ReAct 的开放式循环扛不住。
工具不可靠或成本高的场景。 ReAct 的正确性依赖工具质量：搜索引擎返回垃圾结果，Observation 就会带偏后续所有推理，而且错误会在循环里累积放大。API 按次计费或者工具本身不稳定时，循环调用放大的不仅是延迟还有成本。
任务边界不清晰时。 ReAct 循环没有内生的终止保证，模型可能陷入「查-不满意-再查」的死循环。生产上必须加最大轮数、token 预算的硬熔断——如果你连熔断机制都还没来得及建，先别上开放式 ReAct。
工程实践里的折中
实际系统很少纯用某一种。常见组合：确定性步骤用 workflow 写死，不确定的探索段用 ReAct 循环兜底；简单查询单轮 Function Calling 直接出结果，识别到复杂任务才进 ReAct 模式；推理重的任务交给长 CoT 推理模型，事实查询走检索增强。选型的判断轴就两条：任务需要多少外部事实（越多越偏 ReAct），以及延迟预算有多紧（越紧越偏 workflow/CoT）。
可能的追问
- ReAct 的循环怎么防止跑飞？ 答：最大迭代轮数 + token 预算双重硬熔断；Thought 里要求模型每轮自评是否已具备回答条件；观测历史塞不下时做压缩摘要，防止上下文爆炸导致后程退化。
- ReAct 和 Plan-and-Execute 的区别？ 答：Plan-and-Execute 先一次性生成完整计划再逐步执行，适合步骤可预知的任务，减少 LLM 调用次数；ReAct 是边做边想，每步根据 Observation 调整，适合路径不可预知但延迟和成本更高的任务。
- 工具返回错误时 ReAct 怎么容错？ 答：把错误信息原样作为 Observation 返回给模型，让它在下一轮 Thought 里修正参数重试或换工具——这恰是 ReAct 结构的优势；但要限制同类错误的重试次数，防止撞墙循环。
- 怎么评测一个 ReAct Agent？ 答：三层指标——任务成功率（端到端）、轨迹质量（工具选择/参数是否合理，可人工抽审或用 LLM-as-judge）、效率（平均轮数、token 消耗、延迟），只看成功率会掩盖「绕了八圈才蒙对」的低效轨迹。