AI Agent 的 ReAct 模式

在前面的两节中，我们分别学了 AI Agent 的大脑（思维链，负责规划）和它的手脚（工具调用，负责执行）。

但在真实的商业开发中，任务往往是非常复杂的。大模型不能一口气把计划全想完、然后闭着眼睛照着做。因为执行第一步时，外部系统的接口可能报错，返回的数据也可能不对劲。

为了让 AI Agent 能够根据现实情况动态调整自己的行为，业界提出了一套目前最标准、应用最广的 Agent 执行框架——ReAct 模式。

什么是 ReAct 模式？

所谓的 “ReAct”，指的是：Reasoning（推理） + Acting（行动）。

简单来说，ReAct 模式就是让大模型把 “思考” 和 “行动” 交织在一起。它不再是把所有计划一次想好再去干，而是——想一步，干一步，看一眼结果，再想下一步。

这就像我们照着菜谱学做一道新菜。我们不会先把整本菜谱背熟、再闷头切菜下锅，而是：

首先，看一眼第 1 步（思考）。
然后，去切洋葱（行动）。
接着，看看洋葱切得够不够碎（观察结果）。
接着，再去看菜谱的第 2 步（继续思考）。
……

AI Agent ReAct 模式通俗图解：做菜过程中的思考、行动与观察闭环逻辑

有了 ReAct 框架之后，Agent 就能用最稳妥的方式一步步推进任务，从而更好地保证结果质量。有一句话说得好：

AI Agent 时代，最重要的不是让它干活，而是管住它怎么干。

AI 圈重名乌龙

查阅 ReAct 相关资料时，小伙伴们可能会看到两个非常相似的名字：姚顺雨和姚顺宇。

两人的名字读音完全相同，也都从事前沿 AI 研究，因此经常被写错或混淆。不过，大家只需要记住一点：ReAct 论文的第一作者是姚顺雨——下雨的“雨”。

姚顺雨主要研究大模型和 AI Agent，也是“思维树（Tree of Thoughts，ToT）” 论文的作者之一。另一位姚顺宇则是从物理学转向 AI 研究的学者，曾在 Anthropic 工作，后来加入 Google DeepMind。

ReAct 模式的工作流

在 ReAct 框架里，Agent 解决任何问题，都会进入一个经典的循环。这个循环由 3 个动作组成。

1. Thought（思考）

大模型会根据当前的任务目标，或者上一步返回的数据，在大脑里进行一番逻辑推导（也就是启动思维链），然后定下这一步具体要干什么。

2. Action（行动）

想清楚要做什么之后，大模型就会输出标准的 JSON 参数，触发外部的工具调用（Function Calling），到真实世界里去执行，比如查数据库、发网络请求等。

3. Observation（观察）

外部工具执行完，会把真实的数据结果返回给大模型。大模型拿到这个结果，当作新的已知条件，再进入下一轮的 Thought（思考）。

Agent 就这样不停地重复 “思考 → 行动 → 观察” 这个循环，直到它觉得收集的信息已经够了、足以彻底解决你最开始的问题，才会给出最终答案、结束运行。

ReAct 模式核心工作流：Thought 思考、Action 行动与 Observation 观察的循环框架

其实回头一看，我们就会发现：ReAct 正好把前两节的东西缝在了一起——Thought 就是 “思维链（CoT）”，Action 就是 “工具调用（Function Calling）”，中间再加一步 “看真实结果（Observation）”，三者一循环，就拼成了一个真正会自己干活的 Agent。

ReAct 的运行过程

为了让小伙伴们更直观地理解，我们来看一个真实的业务场景：假如我们要为咱们的绿叶网开发一个自动化运维 Agent，指令是：“检查一下我们官网（https://www.lvyenet.com）的状态，如果服务器挂了，立刻给站长（我）发一封报警邮件。”

当 Agent 接收到这个指令后，它在后台的 ReAct 执行日志，大概会是这样的：

第 1 次循环

Thought（思考 1）：用户要求我检查绿叶网的服务器状态。我需要先调用网站检测工具，来获取目前的 HTTP 状态码。
Action（行动 1）：调用 check_website_status() 工具函数，传入参数：

{ 
    "url": "https://www.lvyenet.com"
}

Observation（观察 1）：工具函数返回了真实数据：

{ 
    "status": 500,
    "message": "Internal Server Error"
}

第 2 次循环

Thought（思考 2）：根据上一步的观察结果，我发现绿叶网服务器目前的返回码是 500，说明服务器确实挂了。根据用户的指令，我现在需要调用邮件发送工具，给管理员发一封报警邮件。
Action（行动 2）：调用 send_email() 工具函数，传入参数：

{ 
    "to": "admin@lvyenet.com", 
    "subject": "网站宕机报警", 
    "body": "监控到 lvyenet.com 出现 500 内部服务器错误，请立即排查！"
}

Observation（观察 2）：工具函数返回了真实数据：

{ 
    "success": true
}

第 3 次循环

Thought（思考 3）：我已经确认报警邮件发送成功。用户的要求 “检查状态” 和 “挂了发邮件” 都已经全部满足，任务可以结束了。
Final Answer（最终答案）：我已经为您检测了官网，目前服务器返回 500 错误码。我已经成功向管理员发送了报警邮件，请留意后续修复情况。

实际上，这套循环可能已经有小伙伴天天在用了：像 Claude Code、Cursor 这类 AI 编程工具，“读代码 → 改一处 → 跑一下看报错 → 接着改”，背后跑的正是 ReAct 循环！

ReAct 模式运行日志案例：自动化运维 Agent 检查官网 500 状态码，并发送报警邮件

比如我们在使用 Claude、DeepSeek 等时，如果仔细看它的思考过程，有时会看到它会发现某一步行不通的时候，就会换个法子重试，如下图所示。

AI Agent 动态纠错展示：Claude 大模型在思考过程中遇到读取报错，自动更换方法重试的 ReAct 机制

ReAct 模式的两大优势

通过上面这个具体的执行过程，我们能很清楚地看到，ReAct 框架之所以能成为业界标准，主要是因为它解决了 2 个痛点。

1. 强大的容错与纠偏能力

如果 AI Agent 没有使用 “循环观察” 的模式，而是把所有步骤一次性排死——那么只要第一步的网站检测接口超时报错，后面发邮件等步骤就会跟着全盘崩溃。

但在 ReAct 框架下，如果 Observation 1 返回的是 “接口调用超时”，Agent 就会在 Thought 2 里反思纠错：“检测接口超时了，我换一个备用接口再试一次”，程序的健壮性一下就上来了。

ReAct 模式的极强容错能力图解：接口超时报错后，动态思考调整与换接口重试

2. 大幅减少消除信息幻觉

在 ReAct 框架中，Agent 的每一次下一步决策，都必须强依赖于上一步外部工具返回的真实 Observation 结果。

它不再凭空猜测官网是 “正常” 还是 “宕机”，而是看到 500、404 这类错误码才发邮件；要是看到的是 200 状态码，就直接回复正常。这么一来，AI Agent 的执行过程就严谨可靠得多了。

ReAct 模式消除大模型信息幻觉：基于真实 200 或 500 状态码观测结果的决策树

防止 Agent 陷入 “死循环”

在真实的业务开发中，使用 ReAct 模式还必须要配置一个关键的保护参数：最大循环次数（Max Iterations）。

为什么需要这个参数呢？因为现实中的接口并不是 100% 稳定的。假设那个 send_email() 接口一直崩溃报错，Agent 可能会陷入以下死循环中：

思考:再次重试 → 行动:发邮件 → 观察:报错

如果不加限制，它会在几分钟内疯狂循环几百次，把你账户里的 Token 余额全部烧光！

所以业界标准的做法是：给 ReAct 循环设置一个上限（比如最多允许循环 5 次或 10 次）。一旦超过这个次数还没得出最终答案，程序就会强制终止并报错，从而保护你的钱包。

学到这儿，整个AI Agent 相关内容就通关了——从 Agent 概念、四大组件，到 CoT、Function Calling，再到现在的 ReAct。如果小伙伴们想要亲手把这些拼成一个真正能跑起来的 Agent，可以关注我们未来上线的——《LangChain 教程》。