场景LLM 能回答问题但无法完成多步任务——ReAct 给 LLM 装上了思考→行动→验证的试错循环路径一个答不出的问题 → 最简实现 → 每轮 Token 账单 → 决策框架 → 一句话锚点上篇我们提到 ReAct 是 Agent 最核心的执行模式——看一眼三元组图就懂了。但一张图能告诉你的事太少了它不告诉你每轮消耗多少 Token、不告诉你什么情况下会死循环、不告诉你生产实现和教程实现差了多远。这篇我们把工具箱掀开12 行核心代码背后的隐藏成本、逐轮的 Token 增长曲线、以及一个决策框架——什么场景该用 ReAct什么场景不该。如果你上篇理解了ReAct 是 Thought→Action→Observation这篇帮你理解ReAct 内部到底怎么运转以及什么时候该用它。一个 LLM 答不出的问题ReAct 不是 2025 年的新算法——它是人类解决问题最自然的方式想一下试一下看看结果再想。如果你观察过自己怎么解决一个复杂问题你已经理解了 ReAct 的核心。区别只在于你把想和试放在大脑里ReAct 把试的结果显式写进下一轮的输入。看一个具体问题帮我查明天上海天气如果下雨就定一个早上 8 点的闹钟。对普通 LLM 来说这是一个不可能完成的任务——不是因为它难而是因为它需要多步、需要外部信息、需要条件判断。传统 LLM 的调用模式是一次请求一次回答没有查完了再决定的机制。左半传统模式——LLM 根据训练数据猜测答案。如果训练数据截止于某天、或者天气 API 不在训练集里它只能编一个。右半ReAct 模式——LLM 先推理我需要查天气然后调用工具获取真实数据再基于真实数据做决策。问题的本质传统 LLM 调用是一次性的User Input → LLM → Response。所有推理都发生在一次前向传播中。对于需要外部信息、多步推理、条件分支的任务这种模式注定失败。ReAct 把一次调用拆成了多次每次只做三件事推理当前状态、决定下一步行动、观察行动结果。每次行动的结果都成为下一次推理的上下文——这才是 ReAct 的核心机制。ReAct 的驱动力为什么需要 ReAct因为 LLM 有一个根本局限它无法验证自己的输出。传统编程中你写a b编译器告诉你结果对不对。LLM 写一段文字没有编译器——它自己不知道是对是错。ReAct 引入了一个外部验证器工具调用的结果。LLM 说查一下天气API 返回的数据就是验证——如果返回了温度说明查成功了如果返回了错误说明参数不对。三元组Thought → Action → ObservationReAct 的每一轮输出包含三部分Thought当前状态分析、Action具体要执行的操作、Observation工具返回的结果。下一轮的 Thought 基于上一轮的 Observation 做修正——形成闭环。这三个词之间的关系不是串行的是互相驱动的Thought 决定 ActionAction 产生 ObservationObservation 修正下一轮的 Thought。上篇用一张图展示了这个循环这篇我们用代码和逐轮拆解来看它到底怎么转。最简 ReAct12 行代码抛开理论ReAct 的核心就是一个循环这 12 行背后表面上看是一个 while 循环但有三个隐藏成本Token 消耗逐轮增长。Token 是 LLM 处理文本的最小单位类似编程语言的字符——英文一个词约 1-2 个 Token中文一个字约 1-2 个 Token。每一轮的 Thought、Action、Observation 都追加到消息列表。第 1 轮可能 500 Token第 5 轮可能 3000 Token基于 GPT-4 典型对话场景估算具体消耗取决于模型上下文窗口和工具返回数据量。如果任务需要 10 轮Token 消耗不是线性增长是逐轮加速增长——因为每轮的输入包含前面全部输出。工具执行有延迟和失败率。tools.execute(reply.action)这行代码隐藏了整个外部调用的复杂度。API 可能超时、可能返回错误、可能返回了数据但格式不对。ReAct 需要处理这些——最简实现没有生产实现必须有重试和超时。最终答案的判断标准不明确。reply.type final是 LLM 自己决定的。LLM 可能过早宣布完成幻觉也可能永远不宣布完成死循环。生产系统中需要额外的判断逻辑是否达到了目标是否超过了预算教程 vs 生产3 个差距上面这个版本是每个 ReAct 教程都会展示的玩具实现。把它部署到生产环境你至少还要加 3 样东西差距 1容错。玩具实现假设tools.execute永远成功。生产中每个 API 都可能超时或报错。真实的 ReAct 实现需要重试策略、超时阈值、降级方案——比如工具返回 500 错误时LLM 应该重试还是换工具差距 2Token 预算。玩具实现假设无限上下文。生产中你必须给每轮对话设置 Token 预算上限。LLM 选了 128K 上下文窗口的模型不等于你应该用完 128K。合理的做法设定每轮最大 Token 数超限就截断或归档。差距 3可观测性。玩具实现无日志。生产系统必须记录每一步的 Thought、Action、Observation、Token 消耗和执行时间。否则当你发现 Agent 花了 1 万 Token 只做了两个 API 调用时你根本不知道哪里出了问题。传统方案的差异对比传统的 if-else 状态机维度传统状态机ReAct状态定义开发者手动编码LLM 动态推理转移逻辑硬编码条件分支LLM 生成下一步错误处理预定义异常路径观察结果后自适应扩展成本新增状态需改代码新增工具即可ReAct 不是用 LLM 替代代码——它是把决策逻辑从代码搬到模型里。传统状态机中开发者必须预判所有可能的状态和转移。ReAct 中LLM 根据当前上下文动态决定下一步开发者只需要提供工具。下次遇到 ReAct 这个概念先理解这个核心机制——ReAct 不是循环是 LLM 的调试器。每次行动都是断点每次观察都是 print()。传统编程中调试的流程是设断点 → 运行 → 检查变量 → 调整代码 → 重新运行。ReAct 中输出 Thought像设断点前的推理 → 执行 Action像运行到断点 → 拿到 Observation像打印变量 → 修正下一步像调整代码。循环只是形式调试才是本质。逐轮拆解当 LLM 学会边做边看回到开头的例子——“查明天上海天气如果下雨就定闹钟”。让我们逐轮跟踪 ReAct 的执行过程。第 1 轮LLM 根据已知知识推理输入上下文只有用户问题。LLM 需要先理解任务判断需要什么信息。LLM 的输出Thought: 用户想知道上海明天的天气还需要根据是否下雨决定是否设闹钟。我需要先查天气。天气 API 需要城市名称和日期。Action:get_weather(city: 上海, date: 2026-07-06)这里的关键是LLM 没有任何已知的天气信息。它只是推理出我需要先查然后发出工具调用请求。它知道自己不知道。第 2 轮Observation 修正推理工具返回了天气数据。现在 LLM 看到了真实信息进入下一轮推理。新的输入上下文 用户问题 第一轮的 Thought 工具返回的天气数据。LLM 的输出Thought: 工具返回上海明天多云25°C降雨概率 30%。30% 不算高但多云说明有降雨可能。用户说如果下雨就定闹钟。稳妥起见我应该设闹钟。Set Alarm 工具需要时间和标签。闹钟定在早上 8 点。Action:set_alarm(time: 08:00, label: 上海明天可能有雨起床注意)这一轮的 Thought 和第二轮的 Observation 紧密相关。如果没有上一轮的工具返回LLM 只能猜测天气——有了 Observation它的推理有了事实基础。第 3 轮验证完成工具返回闹钟设置成功。LLM 判断任务已完成。LLM 的输出Thought: 天气已查闹钟已设。所有子任务都完成了。给出最终回复。Final: “上海明天7月6日多云25°C降雨概率 30%。已帮你设置早上 8 点的闹钟以防下雨影响出行。”Token 账单三轮下来花了多少每一轮都在追加上下文。来看三轮下来的累计 Token 消耗基于 GPT-4 典型对话估算实际会有浮动轮次本轮输入本轮新增累计 Token第 1 轮用户问题~150~150第 2 轮第1轮全部输出 天气数据~650~800第 3 轮第2轮全部输出 闹钟结果~1200~2000三轮下来用掉了约 2000 Token。其中只有最后 ~100 Token 是输出给用户的 Final Answer前面 95% 都是中间步骤——这是 ReAct 的固有开销用大量 Token 换取准确性。这也是为什么 ReAct 不适合简单问答——你本来可以用 200 Token 换一个直接回答现在用了 2000 Token。换来了准确率从 70% 提升到 95% 左右代价是成本翻 10 倍。值不值取决于问题的重要性。什么时候 ReAct 会失败ReAct 不是银弹。三个常见失败场景死循环。LLM 不断重复相同的 Thought→Action→Observation每次 Observation 都一样但 LLM 认为再试一次可能不同。解决方法最大步数限制 重复检测。过早终止。LLM 在关键工具还没调用时就认为任务完成。比如只查了天气就给出任务完成而忘记了设闹钟。解决方法更详细的 System Prompt 任务完成判断标准。工具选择错误。LLM 选了参数不对的工具或者理解错了工具的功能。解决方法更好的工具描述 错误信息的重试机制。选型指南什么时候用 ReAct上篇提到了三种 Agent 模式ReAct、Plan-then-Execute、Reflection。它们不是互斥的各有适用场景。模式适用场景不适合典型成本ReAct多步推理 工具调用简单问答浪费 Token每轮 ~500 TokenPlan-then-Execute步骤明确、依赖清晰的流水线信息不确定的动态任务一次规划 ~1000 TokenReflection需要质量验证的输出场景对延迟敏感的场景翻倍 Token标准 LLM 调用单次问答、知识查询需要外部信息的任务最低一个简单判断如果任务需要查完后决定下一步用 ReAct如果任务步骤已知、每步做什么早就清楚用 Plan-then-Execute如果任务不确定答案质量是否够好加上 Reflection。ReAct 和 Plan-then-Execute 也不是二选一——成熟的 Agent 系统会把两者组合使用先规划再执行每步执行内嵌 ReAct 循环。记住一句话理解 ReAct 不需要记住论文公式。“ReAct 把调试思维装进 LLM——每次行动都是断点每次观察都是 print()”下次有人问你 ReAct 是什么先从这句话开始。然后问一个问题“一个 LLM 答不出的多步问题ReAct 怎么一步步解决”如果答案是先想需要什么信息去拿看到结果再决定下一步——你已经理解了 ReAct。