一、先说一个最基本的问题：Agent 为什么需要"推理"？
LLM 本身就能回答问题，为什么还要给它加推理框架？
因为 LLM 只会"说"，不会"做"。当用户说"帮我创建一个明天截止的任务"，LLM 可以生成一段漂亮的文字描述应该怎么做，但它没有手去操作数据库。Tool（或者叫 Skill）就是给 LLM 装上了手脚——它可以调用接口、查询数据、执行操作。
但问题来了：LLM 什么时候该用哪只手？先用左手还是右手？用完之后下一步该干嘛？
这就是推理框架要解决的问题。它本质上是一套"决策流程"，告诉 LLM 如何思考、何时行动、怎么判断任务完成了没有。
ReAct 和 Plan-and-Execute 就是两套不同的决策流程。
二、ReAct：边想边做的演员
ReAct 的全称是 Reasoning + Acting，来自 2022 年 Google 和普林斯顿大学联合发表的论文（Yao et al., 2022）。
它的核心思想用一句话概括：让 LLM 交替进行"思考"和"行动"，每做一步就停下来想想，然后决定下一步。
工作流程
ReAct 的运行方式像一个循环：
text
思考 → 行动 → 观察 → 思考 → 行动 → 观察 → ... → 完成
拿一个具体的场景来说，用户问："张三这周有多少个未完成的任务？"
- 思考：用户要查张三的任务，我需要先知道张三的用户 ID。
- 行动：调用用户查询工具，搜索"张三"。
- 观察：返回了 user_id = 12345。
- 思考：好，现在我有了 ID，需要查他本周的未完成任务。
- 行动：调用任务查询工具，参数是 user_id=12345, status=未完成，时间=本周。
- 观察：返回了 8 个任务。
- 思考：信息够了，可以回答了。
- 输出："张三这周有 8 个未完成的任务。"
整个过程就像一个人在自言自语——"我现在知道了什么？还缺什么？下一步该做什么？"——每一步都是临时决定的。
为什么 ReAct 能流行起来
ReAct 的优雅之处在于简单。它不需要任何复杂的架构设计，只需要在 Prompt 里告诉 LLM 三件事：
- 你可以思考（Thought）
- 你可以使用这些工具（Action）
- 工具会给你返回结果（Observation）
LLM 天然就会按照这个模式运行。这也是为什么几乎所有 Agent 框架的入门示例都是 ReAct——它的概念直觉、实现简单、容易理解。
而且 ReAct 的适应性很强。如果某一步工具调用失败了，LLM 可以立即反应："这个工具报错了，让我换一种方式试试。"这种灵活性是其他架构不容易做到的。
ReAct 的致命缺陷
但当我真正在项目中使用 ReAct 时，问题开始暴露。
第一个问题：它没有全局视野。
ReAct 是"走一步看一步"的。它优化的是"下一步做什么最好"，而不是"整个任务怎么做最优"。这就像一个人在迷宫里，每到一个路口只看眼前的三条路选一条，从不翻看地图。
当任务简单时（比如"查一下张三的任务"），这没有问题——两三步就完事了，不需要地图。但当任务复杂时（比如"生成本周的团队工作总结"），ReAct 可能走出一条非常曲折的路径：先查了任务列表，然后突然想起还要查项目进度，查完项目进度又忘了还要统计延期情况，最后生成的总结遗漏了关键信息。
第二个问题：上下文污染。
ReAct 的每一步"思考"都需要把之前所有的历史（包括思考过程、工具调用、返回结果）全部发送给 LLM。执行 5 步之后，上下文里充斥着各种中间数据、报错信息、调试噪声。LLM 的注意力被这些无关信息稀释，推理质量明显下降。
这在业界有个形象的说法叫"上下文越长，模型越笨"。我在实际测试中观察到，同一个 LLM 在 3 步以内的任务上表现优秀，但超过 6 步后，它开始"忘记"最初的目标，或者在几个相似的状态之间反复跳转。
第三个问题：成本失控。
每一步"思考"都是一次完整的 LLM 调用，而且每次调用都要携带越来越长的历史上下文。一个 10 步的任务，到第 10 步时，prompt_tokens 可能已经是第 1 步的 5 倍以上。更要命的是，这些 token 大部分花在了"让 LLM 重新理解之前发生了什么"上——这是纯粹的浪费。
