ReAct 循环：Agent 的心跳

上一篇讲了 Agent 和聊天机器人的区别，核心是"会不会自己决定下一步、并且真的去做"。这一篇往下拆一层：这个"自己决定下一步"的能力，具体是怎么运转的？

答案没有想象中复杂。几乎所有 Agent 系统的底层，都在跑同一个简单循环，叫 ReAct（Reasoning + Acting，推理 + 行动）。

（配图占位 ①，见文末配图清单）

先看一个反例：单轮问答

你问 AI"今天北京天气怎么样"，它调用一次天气 API，把结果念给你听，结束。这个过程只发生了一次"行动"（调用工具），没有循环。

这不是 ReAct，这是我在上一篇里说的"工具增强型聊天机器人"——调用工具，拿到结果，直接生成回复，完事。

ReAct 到底在循环什么

ReAct 的循环有三个动作，不断重复：

观察（Observe）——看看当前状态是什么：任务完成了吗？上一步行动的结果是什么？有没有出错？

思考（Reason）——基于观察到的情况，判断接下来该干什么：这个结果够不够？需不需要换个方法？任务是不是已经做完了？

行动（Act）——把思考的结论变成实际动作：调用一个工具、写一段代码、读一个文件、或者干脆判断"任务完成，可以结束了"。

然后回到"观察"，看这次行动带来了什么新状态，再思考，再行动，一直循环，直到任务真的完成，或者判断这条路走不通需要换策略。

这个"观察→思考→行动→再观察"的闭环，就是 Agent 的心跳。心跳停了（循环终止），任务要么完成了，要么卡住了。

（配图占位 ②，见文末配图清单）

举一个具体例子

假设让一个 Agent 帮你修一个跑不过的测试。它大概会这样循环：

观察：跑一下测试，看到报错信息（比如"预期返回 200，实际返回 500"）
思考：500 通常是服务端报错，得去看日志或者堆栈信息
行动：读日志文件
观察：日志里看到一个 NullPointerException，指向某个具体文件的某一行
思考：这一行大概率是某个变量没初始化就被使用了
行动：打开那个文件，读代码上下文
观察：确实看到一个变量在某个分支下没有赋初值
思考：加一个默认值应该能解决
行动：修改代码，重新跑测试
观察：测试通过了
思考：任务完成，可以结束

11 步里，"观察"出现了 5 次，"思考"出现了 5 次，"行动"出现了 4 次——这就是 ReAct 循环真实运转起来的样子。每一次行动之后都要重新观察，而不是"预先规划好所有步骤，然后一口气全部执行"。

这一点很关键：ReAct 不是"先想好完整计划再执行"，而是"边做边看边调整"。这也是为什么 Agent 能处理"计划之外"的情况——比如日志里显示的报错和预期完全不一样，它可以在下一轮"思考"里临时改变方向，而不会死守着一份写死的计划硬冲。

为什么这个循环听起来很简单，做好却很难

ReAct 这个概念本身，讲清楚可能只需要三分钟。但真正决定一个 Agent 好不好用的，从来不是"有没有这个循环"，而是循环里每一步做得扎不扎实：

观察做得不好：拿到的信息不完整、不准确，比如日志被截断了、报错信息看串了，后面的思考就建立在错误的地基上
思考做得不好：明明观察到了关键信息，却没意识到它的重要性，或者被无关信息干扰了判断
行动做得不好：想清楚了该干什么，但执行的时候手滑了（比如改错了文件、传错了参数）

这也是我在上一篇结尾提到的"上下文管理"问题的根源——循环跑得越久，"观察"到的历史信息就越多，如果不做处理，后面的"思考"会被淹没在噪音里，判断力反而会下降。这是下一篇要展开的内容。

回到我自己的项目：为什么这里没有 ReAct 循环

上一篇说过，这个博客的 AI 分身不是 Agent。现在能说得更精确一点：它压根没有 ReAct 循环——没有"观察→思考→行动→再观察"这个闭环，它是单次生成：接收你的问题，检索相关文章内容，生成一段回复，回复里可能带一个"推荐文章："的标记，前端解析出来渲染成卡片。仅此而已，不会再回头"观察"这次生成的效果好不好，也不会基于观察结果决定"要不要换个说法再试一次"。

这不是缺陷。一个只需要"回答问题、顺便推荐一篇相关文章"的场景，根本不需要 ReAct 这种为了应对"计划之外的情况"而存在的机制——因为这里几乎不存在"计划之外"，检索完文章、生成回复，就是全部的任务。给一个不需要循环的场景硬套上循环，只会让系统变慢、变复杂，却拿不到任何实际好处。

判断要不要上 ReAct 循环，可以用一个简单的问题自测：这个任务在执行过程中，会不会出现"必须先看到上一步的结果，才能决定下一步怎么走"的情况？如果答案是否定的——任务从一开始就能被完整规划出来，中途不会有意外——那可能根本不需要 Agent，普通的单次生成或者固定 Workflow 就够了。

ReAct 循环转起来之后，很快会撞上一个新问题：循环跑得越久，"观察"积累的历史就越多，模型的判断力反而会下降。这就是上下文管理要解决的问题——下一篇讲清楚 Agent 为什么会"失忆"，以及常见的应对方式。

配图清单（生成完发给我，我会替换掉正文里的占位标记）

① 位置：开头，"先看一个反例"之前

建议：一张简单示意图，突出"这是一个循环，不是一次性动作"

简约手绘风格插画，暖色调，类似之前"分岔路口"那张封面的画风。
画面是一个循环箭头，三个节点分别标注（可以用简单图标代替文字）：
一个眼睛图标（观察）→ 一个大脑/灯泡图标（思考）→ 一个手/齿轮图标（行动）→
箭头绕回到眼睛图标，形成闭环。整体干净，不要太多细节，突出"循环"这个核心意象。

② 位置："举一个具体例子"之前，也就是三个动作定义讲完之后

建议：可以做成一张更细节化的流程图，或者做成 GIF 展示循环真的在"转"

如果做静态图：横向流程图，三个圆角矩形框，分别写"观察 Observe"、
"思考 Reason"、"行动 Act"，中间用箭头连接，最后一个箭头从"行动"
弯回到"观察"，形成一个环形箭头（不是直线）。配色用蓝紫渐变，
风格简洁现代，类似技术博客常见的信息图（infographic）风格，不要卡通化。

如果做 GIF（更能体现"循环"这个动态感）：
同样三个节点的循环图，但让高亮色块沿着箭头方向持续流动，
每次流过一个节点就短暂停留放大一下，营造"一步步执行"的节奏感，
循环播放，2-3 秒一圈，配色同上（蓝紫渐变，简洁现代风格）。

两张图（或一图一 GIF）风格不用完全一致，但尽量都保持简洁、不花哨，跟你之前"分岔路口"那张封面的克制感一致就行。