1. 先搞明白ReAct 为什么能想一步走一步我第一次给客户演示 AI Agent 时对方问了一句特别扎心的话你这 Agent 跟 ChatGPT 有什么区别不都是聊天吗当时我做的 Demo 确实就是个聊天框模型再聪明它也只会说不会做。后来我把 ReAct 模式接进去同一个 Demo 立刻就不一样了用户说帮我查一下杭州明天天气顺便看看有没有合适的航班Agent 会自己先拆解问题然后调天气 API、查航班接口拿到结果再继续推理最后把结论汇总成一段完整答复。整个过程不是一次生成答案而是一轮一轮地想一步、做一步、看一步。先提醒一句这里的 ReAct 是 Reasoning Acting 的缩写跟前端圈那个 React.js 完全不是一回事别搞混。ReAct 最早是 2022 年底由 Princeton 和 Google 的研究者在论文ReAct: Synergizing Reasoning and Acting in Language Models里提出的。它要解决的根本问题很简单大语言模型本身只擅长想不擅长做。模型没有途径去查数据库、调接口、操作文件而现实世界的任务恰恰需要这些外部动作。ReAct 的做法是让模型在推理过程中主动声明我现在需要做什么动作然后由外部系统真正执行这个动作把结果再喂回给模型让它继续推理。如果你是刚接触 AI Agent 的开发者ReAct 是你绕不开的第一个执行范式。它同时也是现在大量 Agent 框架LangChain、LangGraph、AutoGPT 等底层默认采用的核心模式。它不依赖特定 SDK也不是某个框架的专利本质上就是一套思考-行动-观察交替进行的循环结构用任何模型、任何编程语言都能实现。1.1 从只会聊到能干活差的不是模型而是循环做个思想实验。你让一个对话模型完成这个任务告诉我北京和上海今天的实时温差是多少。模型如果没见过实时天气数据它只能靠训练时的记忆瞎编因为它根本没有途径获取今天的天气。传统的 prompt engineering 解决不了这个问题因为瓶颈不在提示词而在获取外部信息这个动作本身。ReAct 的思路是把获取天气这个动作显式地交给模型去决策。模型可以输出一个结构化指令比如调用get_weather(city北京)然后外部代码真正去请求天气 API把返回结果作为观察Observation再交给模型。模型看到北京气温 25 度、上海 28 度就能自然算出温差 3 度。注意这里的计算温差是模型推理能力的一部分但拿到两个城市的实时温度这个前提是靠行动循环补上的。所以 ReAct 解决的问题可以概括成一句话让模型借助外部工具把推理和行动交替串联起来最终收敛到一个可验证的答案。它给 LLM 补上了可操作性这层能力。模型不再只是回答问题而是能调度工具、能感知结果、能根据结果调整下一步。这也是为什么同样一个模型套上 ReAct 循环之后能从一个聊天机器人变成真正下地干活的智能体。1.2 推理和行动交替发生的底层逻辑ReAct 的底层逻辑可以画成一个循环模型根据当前已知信息推理出下一步该做什么Thought然后声明一个具体动作Action外部系统执行动作后返回观察结果Observation模型再基于新的 Observation 重复这个过程直到它认为信息足够、可以直接输出最终答案为止。这个循环听起来简单但它对应着人类解决复杂问题的基本方式。你接到帮我规划周末出行这个任务时不会一次性把整套方案背出来而是先想出行得知道天气吧然后去查天气行动看到下雨再想那得带伞再看看室内备选方案推理接着查博物馆开放时间……每一步的想都建立在上一步做的结果之上。ReAct 就是把这个过程显式地建模成模型可以执行的循环。这里有个关键区别ReAct 不是让模型一次性输出完整思考过程所有动作而是要求它每轮只输出当前这一步的推理和动作执行完拿到结果后再继续。这种逐步推进设计有实际的工程意义——它让每一步都建立在真实、最新的观察结果上而不是模型凭空的预测。在我实测过的多步工具调用任务里ReAct 的准确率明显高于让模型一次性规划完再执行的做法主要原因就是它每一步都有外部结果兜底。2. 拆开 ReAct 的核心循环Thought / Action / Observation 三段式把 ReAct 循环的每一轮拆开看其实就是三个角色在接力模型负责 Thought 和 Action外部系统负责执行并产生 Observation然后 Observation 又成为下一轮模型输入的上下文。2.1 一次循环里的三个关键角色在 ReAct 的 Prompt 中通常会要求模型按固定格式输出三段内容Thought思考模型解释它为什么决定这么做这一步的推理过程。Action行动模型声明要调用的工具名称和参数比如search(query北京到上海机票)。Observation观察外部系统在模型输出 Action 后执行得到的结果会作为下一轮输入的一部分再喂回给模型。这里要特别强调Thought 和 Action 是模型生成的Observation 不是模型生成的而是外部工具返回的真实结果。很多初学者第一次看 ReAct 执行日志时会把 Observation 当成模型的输出实际上它来自工具层。把这个角色搞混调试 Agent 时会走很多弯路。一次完整的循环大概长这样模型输出 - Thought: 用户需要查询北京的天气我需要先调用天气接口。 Action: get_weather(city北京) 外部系统执行 - get_weather 返回 {temperature: 25, condition: 晴} 拼接下一轮 - Observation: 北京今天 25 度晴天模型看到 Observation 后再决定是继续行动比如还需要查上海天气还是直接回答用户。这就是想一步做一步的最小闭环。整个 Agent 就是把这个循环重复若干次直到收敛。2.2 一个可以直接抄的 Prompt 模板ReAct 的实现不依赖任何框架核心是两件事Prompt 设计 输出解析。我贴一个最简版本的 system prompt 模板可以直接拿去改你是一个能够调用外部工具的智能助手。请严格按照以下格式输出 Thought: 你对当前任务的分析和你决定采取行动的原因。 Action: 你要调用的工具格式为 工具名(参数1值1, 参数2值2)。 当且仅当需要调用工具时输出 Action Observation: 这是工具返回的结果你需要基于它继续推理。 Observation 不需要你生成它由系统提供 当你已经获得足够信息不再需要调用工具时请输出 Thought: 我已获得足够信息。 Answer: 你对用户问题的最终回答。这是最经典的 ReAct 格式。实际使用时我强烈建议在 Prompt 里附上完整的工具清单和每个工具的详细说明参数类型、返回值含义、使用示例因为模型对有哪些工具、参数怎么填的全部感知都来自这里。在我的项目里工具说明写得好不好直接决定了模型调用工具的准确率能差出两到三成。别嫌 Prompt 长这里多花的心思一定会在效果上赚回来。3. 完整走一遍真实执行链路让 Agent 查机票并给出建议光看模板不够直观。我拿一个自己在项目里反复跑过的场景——查机票价格并给建议——把完整链路走一遍。假设 Agent 有两个工具search_flights(origin, destination, date)和search_hotels(city, check_in, check_out)。3.1 第一轮模型生成 Thought 和 Action用户提问帮我看看下周五从北京到上海的机票顺便看看有没有便宜的酒店。模型收到问题后第一轮输出可能是Thought: 用户需要北京到上海的机票和上海酒店信息。我需要先查询机票。 Action: search_flights(origin北京, destination上海, date2026-05-15)这里有个非常容易被忽略的细节用户说的下周五是个相对时间模型需要自己推算具体日期。如果模型不知道当前日期它在这一步就会卡住或者编造日期。所以实际工程中通常要把当前日期作为系统信息注入到 Prompt 里让模型知道今天是什么日子。我最早做 Agent 时没注意这个结果模型一本正经地查了一个过去日期的航班返回无结果——排查了半天才发现是日期推算的问题。外部系统你的代码解析出 Action 后调用真实的航班查询接口返回结果Observation: 北京-上海 下周五共有 3 个航班 国航 CA1501 08:00-10:15 950元 东航 MU5108 10:30-12:40 780元 吉祥 HO1252 19:00-21:10 680元3.2 中间轮工具返回 Observation模型继续推理模型拿到 Observation继续生成下一轮Thought: 有三趟航班可选价格从 680 到 950 元。 用户还问了便宜的酒店我需要继续查询上海酒店。 Action: search_hotels(city上海, check_in2026-05-15, check_out2026-05-16)外部系统再次执行返回Observation: 上海人民广场附近经济型酒店如家 350元/晚、汉庭 320元/晚。 静安寺附近亚朵 650元/晚。注意看模型每一轮的 Thought 都依赖上一轮的 Observation。如果没有这个循环模型在第一轮就一次性输出我估计机票几百块、酒店五六百那全是编的。ReAct 的强项恰恰在于每一步结论都有工具结果作支撑这也是它能用来做真实业务决策的根本原因。3.3 终止轮没有 Action只有 Final Answer模型看到酒店信息后觉得自己掌握的信息足够回答用户问题了于是输出Thought: 我已有航班和酒店信息可以给出建议。 Answer: 从北京到上海下周五有三趟航班最便宜的是吉祥 HO1252680元 但起飞时间是晚上 19:00。如果希望白天到达东航 MU5108 是 780 元。 酒店方面汉庭 320 元/晚性价比最高。到这里一轮任务就完整收敛了。这个例子看着简单但任务复杂度上去之后——比如需要对比多个渠道、需要根据中间结果动态改变查询条件、需要在多个结果之间做权衡——ReAct 逐步推理的优势会非常明显。我见过不少团队花大力气把 Agent 的思考写死在代码里结果每次需求一变就要改代码而 ReAct 的灵活性恰恰省掉了这部分维护成本。4. ReAct 的边界它和 Chain、Plan-and-Execute 到底差在哪ReAct 不是唯一的 Agent 执行模式。实际工程里我经常被问到什么时候用 ReAct什么时候用 Chain什么时候用 Plan-and-Execute这三个模式我都在生产环境跑过给你梳理一下它们的本质区别和取舍逻辑。4.1 三类模式的运行方式对比Chain链式调用最简单把任务拆成固定几个步骤按顺序执行每步输入来自上一步输出。比如先总结用户评论再翻译成英文再提取要点就是一个固定链。它的特点是步骤是预设的、不可变的模型没有决定下一步做什么的自由度。优点是可预测、好调试缺点是任务一变化就失效。ReAct 的特点是模型每轮自主决定下一步动作没有预设步骤数循环直到模型认为可以回答为止。它比 Chain 灵活得多但也带来了不可预测性——你不知道它会调用多少次工具也不知道它会不会跑偏、会不会陷入死循环。Plan-and-Execute规划后执行是两段式模型先一次性制定完整计划Plan然后按计划逐步执行。比如先规划第一步查机票、第二步查酒店、第三步比较价格然后一步步执行。它和 ReAct 最大的区别在于ReAct 是边想边做Plan-and-Execute 是先想后做。用表格对比更直观模式决策方式灵活度适用场景主要风险Chain预设固定步骤低流程稳定、不允许跳步的任务步骤一变就失效ReAct每轮自主决策高多步工具调用、结果影响后续决策可能循环过多或跑偏Plan-and-Execute先整体规划再逐步执行中任务结构清晰、步骤间相互独立计划可能与实际情况脱节4.2 什么时候别用 ReActReAct 虽然灵活但某些场景下它真不是最优解。比如你做的 Agent 必须严格遵循动作序列先鉴权、再查库、再脱敏、再返回这种时候固定 Chain 更可靠因为你根本不想让模型自由发挥去跳过鉴权步骤——那会直接变成安全事故。另外当任务是一锤子买卖、不需要外部工具时比如纯文本改写、翻译ReAct 的循环完全是多余的直接单次生成更快、更省 token。我见过不少团队把 ReAct 用在所有场景上结果延迟高企、成本翻倍其实很多简单任务用普通 prompt 就能搞定。还有一种情况是先规划更合适当任务步骤非常多、且单次工具调用成本很高比如外部 API 收费、耗时很久Plan-and-Execute 可以先让模型制定一份完整计划执行时每一步都可以审视计划是否仍然合理必要时候再重新规划。它跟 ReAct 没有绝对的优劣之分核心是看你更看重灵活性还是可控性。我的经验是步骤少于 5 步、环境变化快的任务用 ReAct步骤多、执行成本高、需要稳定流程的任务用 Plan-and-Execute 或者 Chain。5. 工程落地时的四个关键决策点理论讲完说点工程落地一定会碰到的问题。我在好几个项目里从零实现过 ReAct 循环下面这几个决策点几乎每个项目都会碰到而且踩坑成本都不低。5.1 工具怎么定义模型才不容易出错工具定义直接决定模型能不能正确调用。我建议每个工具的说明至少包含五件事工具名称简短、语义明确比如get_weather别用do_thing_1这种。参数说明每个参数的名称、类型、取值范围、是否必填。返回值说明返回的 JSON 结构或文本格式模型需要知道结果长什么样才能正确解析。使用示例至少一个完整的调用例子模型会模仿示例的格式。使用场景提示什么时候该用这个工具、什么时候不该用。实测下来工具说明里给示例的效果远好于只给字段说明。大模型的 few-shot 能力很强你给它一两个正确调用示例它就会照着例子输出格式。工具数量超过五六个以后我建议把工具说明按业务域分组或者给每个工具加一句当用户提到 XXX 时使用本工具的场景提示能明显减少模型选错工具的概率。5.2 最大循环轮数设置多少合适ReAct 循环如果没有限制模型可能陷入无限循环——不停调用工具、不停看观察结果、就是不出最终答案。所以工程上必须设置最大轮数max_iterations。我的经验值是常规任务设 5 到 8 轮复杂任务放宽到 10 到 15 轮超过 15 轮还收敛不了基本可以判定是 Prompt 或工具定义有问题不是轮数不够。轮数触顶之后的处理方式也很有讲究。最简单的做法是强制要求模型基于已有观察输出 Answer更好的做法是给模型一个兜底提示你已用完所有尝试次数请基于已有信息尽可能回答如果信息不足以回答请明确告诉用户缺什么。这个兜底逻辑能显著降低 Agent 最后硬编一个答案的幻觉率。我见过很多 Agent 在轮数耗尽后为了完成任务开始瞎编数据加一句话提示就能规避大半。5.3 上下文窗口不够了怎么办ReAct 的每次循环都会把 Thought、Action、Observation 追加到历史里多轮之后 Prompt 会变得非常长。上下文窗口有限Observation 太详细时比如搜索接口返回 100 条结果几轮下来窗口就炸了。我的做法是两级策略。第一级在把 Observation 喂给模型前先做裁剪只保留关键字段、限制返回条数、超长内容截断。第二级对历史对话做摘要压缩把早期轮次的 Thought/Observation 压缩成一行摘要只保留最近几轮的完整内容。这个早期摘要 最近完整的组合策略在我实际项目里支撑过 20 轮以上的复杂任务上下文窗口始终没爆过。记住一个原则模型只需要看到做决策所需的最小信息集而不是所有原始数据。5.4 解析模型输出时格式不稳定的处理ReAct 依赖结构化输出Thought/Action/Observation但模型输出格式天然不稳定。你要求它输出Action: search(北京)它可能给你加一段解释或者把 Action 写进 JSON 里或者用 Markdown 代码块包起来。解析失败是 ReAct 实现中最常见的 bug 来源没有之一。我的经验是三层防护。第一层在 Prompt 里明确要求只输出规定格式不要输出任何解释性文字并同时给正例和反例。第二层用正则做宽松匹配比如从整段输出里提取Action:标记之后的内容修剪掉多余字符。第三层解析失败时不要直接报错而是把你的输出格式不符合要求请重新按格式输出作为 Observation 喂回给模型给它一次纠错机会。这个格式纠错循环在我的实测里能把解析成功率从 80% 拉到 95% 以上是所有调优手段里性价比最高的一个。6. 实测中踩过的坑和调优心得最后分享几个我在真实项目里踩过、且有代表性的大坑。这些基本都是文档里不会写的东西属于不自己跑一遍根本不知道的经验。6.1 模型幻觉式调用工具模型有时会在信息不足时硬编一个工具调用比如虚构一个不存在的 ID、或者把查询参数乱填。我遇到最典型的一次模型在 Action 里调用了一个根本不存在的工具名称完全是根据我工具清单里的描述编出来的。排查下来发现是因为那个工具说明写得太模糊模型误以为还存在另一个变体工具。解决方法是加一道工具校验层外部系统解析出 Action 后先检查工具名是否在白名单里、参数类型是否合法不合规就返回一个固定 Observation工具不存在可用工具为XXX让模型自己纠正。千万不要让不合规的调用直接抛异常崩掉整个循环那样整个 Agent 会话就废了。这个校验层成本很低但对稳定性的提升非常明显。6.2 Observation 内容过载工具返回大段 JSON 时如果把原始 JSON 直接作为 Observation 喂给模型既浪费 token又会干扰模型推理——模型在里头翻半天找不到关键信息还容易找错重点。我的做法是在工具层做一次结果摘要把原始返回 JSON 转成一句话或结构化要点只保留模型做决策所需的信息。比如查询结果有 50 条就取前 5 条并注明共 50 条结果。模型不需要看全部原始数据它只需要拿到能支撑下一步决策的最小信息集。养成这个习惯之后整个 Agent 的稳定性和 token 成本都会有肉眼可见的改善。6.3 冷启动、超时与并发场景的建议如果你打算把 ReAct Agent 做成线上服务有几个容易被忽略的工程点。一是冷启动首次请求时模型要加载系统 Prompt 和工具清单如果多轮循环串行执行延迟会很高。建议把工具清单和系统 Prompt 缓存起来或者用支持 prompt caching 的模型服务首轮响应能快不少。二是并发控制ReAct 循环通常会调用外部 API多路并发时要对下游接口做限流。我遇到过不止一次 Agent 本身没挂、下游 API 先被打爆的情况。三是超时设置每轮循环都要有独立的超时控制避免某个工具调用卡死导致整个 Agent 会话长时间挂起。最后说一点模型选型的体会。ReAct 模式对模型的推理能力要求不低小参数模型经常出现 Action 格式错误、Thought 逻辑跳脱的问题。如果你受限于部署条件只能用较小的模型建议把任务拆得更细或者改用 Plan-and-Execute 模式减少循环深度。如果项目预算允许用推理能力强的模型跑 ReAct整体体验会好一个档次——尤其是复杂任务模型一弱整个循环就变成在错误边缘反复试探调试成本反而更高。