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 为什么会"失忆"，以及常见的应对方式。