第一部分：Agent推理模式谱系

如果我们将Agent的各种推理方式展开来看，会发现它们几乎构成了一条完整的光谱：一端是纯粹的“思考”，另一端是纯粹的“行动”，而中间地带则是“边想边干”的混合形态。

先看纯推理的那一类——只进行思考而不采取行动，专门用于解决数学题、逻辑谜题这类需要深度脑力运算的问题，全程不与外部环境发生任何交互。

链式推理（CoT）是最具代表性的方法：模型在给出最终答案之前，会先写出一串中间推理步骤。这就好比考试时，老师要求你完整写出解题过程，每一步都清晰可查。

思维树（ToT）则更进一步——它不满足于一条路走到底，而是在每个决策点尝试探索多个可能的“思维分支”，判断哪个方向更有前景，甚至能果断回溯重新开始。这与下棋时的多步推演如出一辙，你不仅要考虑自己下一步怎么走，还要预判对手的可能应对。

思维图（GoT）把树状结构进一步打散成网状，不同推理链之间可以合并、交叉甚至循环，从而形成一个更复杂的推理网络。

再来看看行动驱动的那一端。这类模式的核心是将推理隐藏在行动与反馈的交互过程之中。

ReAct 是这里面最具代表性的——推理和行动交错协同，也是本文要重点剖析的内容。后续还有反思模式（Reflexion），让Agent在执行完一系列操作后进行“复盘”，总结经验教训以优化后续行为，算是对ReAct的有效补充。而计划与执行模式则主张先绘制好蓝图，再按部就班去落实，好比写代码之前先画出架构图。

第二部分：详解 ReAct 模式

ReAct 这个名称本身就是 “Reasoning + Acting” 的融合，它的理念听起来简单，但实战效果极为强大：让大语言模型同步生成“推理轨迹”和“具体行动”，两者互相支撑、环环相扣。

一个标准的ReAct循环遵循以下流程：

思考：Agent收到用户问题后，先在脑中过一遍：“我需要先查找2023年F1冠军是谁。”
行动：基于这个判断，它决定调用“搜索”工具，并输出一个具体的API调用指令。
观察：环境返回搜索结果，例如“马克斯·维斯塔潘”。
再思考：Agent看到结果后继续推理：“现在知道冠军是维斯塔潘了，接下来要找到他的出生地。”它也可能在这个环节自我纠偏：“刚才搜索的信息还不够完整，得换一个更精确的关键词。”
再行动：发起第二次搜索，查询词改为“马克斯·维斯塔潘 出生地”。
再观察：得到反馈“比利时 哈瑟尔特”。
最终回答：经过几轮循环后，Agent整理信息给出答案：“2023年F1冠军是维斯塔潘，出生于比利时哈瑟尔特。”

ReAct的三个关键特性值得特别关注：

动态修正。它打破了传统“先规划再执行”的僵硬模式，允许Agent在观察到行动结果后即时调整下一步计划。搜索没找到有效信息？换个关键词。发现前后矛盾？启动验证机制。

可解释性。人的肉眼可以直接追踪Agent的每一次“思考”和“观察”，整个过程透明可调试，不像黑盒那样让人心里没底。

融合内外部知识。模型内部的参数化知识（“我知道需要搜索”）和外部的工具知识（搜索引擎返回的真实结果）被打通，有效缓解了模型“一本正经胡说八道”的幻觉问题。

第三部分：ReAct vs. CoT vs. ToT 核心区别

用三个直观比喻来区分它们：

CoT 像一位闭卷考试的学生，在脑中一步步演算，直接写出过程和答案。

ToT 像一位棋手，在脑海里推演接下来N种走法和对手的应对，评估每种选择的胜率，选择最优策略。整个过程仍然是脑内活动。

ReAct 则像一位拿着手机的科学侦探——他思考“凶手可能用的氰化物”，然后立刻行动：“查一下化学手册，氰化物的中毒症状是什么？”在看到症状描述（观察）后，他继续推理：“这与目击者的描述不符，得换个方向，查查其他毒物……”他通过不断与外部世界互动，最终拼凑出真相。

总结一下，ReAct能够在Agent构建中占据核心地位，根本原因在于它解决了纯推理模式最大的局限性：无法利用外部工具和真实世界信息来校准知识、执行操作。在实际高级Agent系统中，这些模式往往会组合使用。比如在ReAct的单个“思考环节”里调用ToT来解决某个子问题，形成“ReAct + ToT”的混合策略，兼顾了外部交互与内部复杂推理。

面试回答

关于Agent的推理模式，目前主流的主要有三条路线：

第一类是纯推理型，比如思维链CoT、思维树ToT，这类模式的共同特点是只在模型内部做文字推理，不与外界交互；第二类是行动型，ReAct是典型代表，它把推理和行动打通；第三类更高级一些，像自我反思Reflexion、规划与执行Plan-and-Solve等。

重点展开一下ReAct，其核心理念就是让模型一边思考一边行动，同时观察结果再继续思考。

举一个很直观的例子：用ReAct模式让Agent查询“今天北京的天气并决定是否带伞”，它会这样运作：

Thought（思考）：我需要先查天气。
Action（行动）：调用天气API查询北京实时数据。
Observation（观察）：接口返回“大雨”。
Thought（思考）：要下雨，得带伞。
Action（行动）：输出“建议带伞”。

这种模式最大的优势在于打破模型的“知识幻觉”——实时信息不知道没关系，Agent会通过工具主动获取，真正做到接地气。

对比CoT、ToT和ReAct，三者的本质区别非常清晰：

先说CoT（思维链）。它是一条线走到底，模型在内部“自言自语”，把复杂问题拆解成一步步逻辑推导。缺点在于静态、不可纠错——第一步算错了，后面的推导全部白费，而且拿不到外部真实信息。

再说ToT（思维树）。可以看作是CoT的升级版，不再是单线逻辑，而是像树一样分叉蔓延。模型在每一步都尝试多种可能性，走不通就回溯换条路。适用于需要大量探索的数学题、策略游戏。但代价是计算量爆炸，成本不菲。

最后回到ReAct。它的轨迹更像一个循环——思考、行动、观察、再思考。不是纯内部推理，而是与外部环境强交互。核心区别在于：CoT只会“想”，ReAct既会“想”也会“做”。在需要查数据库、上网搜索、操作软件的任务场景里，ReAct的表现远超CoT和ToT。

简单总结：CoT适合逻辑推导，ToT适合复杂探索，ReAct适合需要调用工具的真实任务环境。

实际开发中，通常不会只用单一模式。比较常见的做法是让Agent先用CoT做快速规划，然后在需要查信息的具体步骤上切换成ReAct模式调用工具，这其实就是更高级的 Plan-and-Solve 或 LLM Compiler 的思路。

追问：ReAct 有什么缺点？

ReAct也有坑。因为要多次调用LLM和工具，延迟比较高；而且模型在“思考-行动”之间来回切换时，容易陷入死循环，比如反复查询同一个东西。生产环境里一般都要加最大循环次数限制，或者用格式约束来保证流程收敛。