
ReAct 不是一个框架配资乐股票配资网址,不是一个库,不是一个产品。它是一种让 Agent 能真正"干活"的运作机制——推理告诉 Agent 下一步做什么,行动去触发外部系统,观察把结果拿回来修正判断,三步循环往复,直到任务完成。
一、为什么需要 ReAct一句话回答:单纯让模型"想"会产生幻觉,单纯让模型"做"会失去方向,只有推理和行动交替推进、互相校正,Agent 才能在复杂任务里保持准确。
2022 年底,Google Research 与普林斯顿大学的研究者联合发表了论文《ReAct: Synergizing Reasoning and Acting in Language Models》,提出了一个看起来朴素但影响深远的问题:让语言模型单纯生成推理链(Chain-of-Thought),和单纯执行动作,哪个效果更好?
实验结论是:都不够好。
纯推理链让模型在自己的"内心独白"里打转,无法获取外部信息,遇到需要实时数据的任务就会开始编造。纯动作执行缺乏对任务目标的整体把握,容易陷在局部步骤里,忘了自己最终要做什么。
ReAct 的核心思路是:推理和行动必须交替进行,且互相通知。每一步推理为下一个动作提供方向,每次动作执行后的结果反馈回推理过程,修正接下来的判断。这个闭环,就是"推理-行动-观察"循环的来源。
二、循环的三个节点节点一:Thought(推理)
Agent 在这一步不调用任何工具,只是输出一段内部独白,用自然语言描述当前的判断:任务目标是什么,已有哪些信息,还缺什么,下一步该做什么以及为什么这样做。
这段推理默认对用户不可见,但它是后续动作合理性的来源。跳过这一步直接行动,工具调用就变成了盲目触发。
节点二:Action(行动)
基于推理结论,Agent 选定一个工具并生成调用参数。这一步输出的是结构化内容,不是自由文本:
Action: search_contract_databaseAction Input: {"status": "overdue", "date_range": "2024Q3"}工具调用发出后,执行权转交给外部系统——数据库、HTTP 接口、文件系统,或者企业内部的业务平台。模型本身在这个阶段暂停生成,等待结果回传。
节点三:Observation(观察)
外部系统返回执行结果,以文本形式注入 Agent 的上下文:
Observation: Found 3 overdue contracts. Contract IDs: CTR-8821, CTR-8834, CTR-8901.Total overdue amount: ¥486,000. Responsible AEs: 张伟 (2), 陈浩 (1).Agent 读取这条观察结果,进入下一轮 Thought,决定是否继续调用工具,还是判断任务已经完成,输出最终结论。
循环就这样一轮一轮推进,直到触发终止条件。
三、完整循环的执行过程用合同管理这个场景,把 ReAct Loop 的节奏完整走一遍:
[Iteration 1]THOUGHT: 先查出所有逾期合同,了解数量、金额和负责人分布。ACTION: search_contracts(status="overdue")OBSERVATION: {"contracts": [{"id":"CTR-8821","ae":"张伟","amount":180000},{"id":"CTR-8834","ae":"张伟","amount":230000},{"id":"CTR-8901","ae":"陈浩","amount":76000}], "total": 3}[Iteration 2]THOUGHT: 共 3 份逾期合同,合计 ¥486,000。张伟负责 2 份,陈浩 1 份。先通知张伟。ACTION: send_notification(ae_name="张伟",contract_ids=["CTR-8821","CTR-8834"],message="您负责的 2 份合同(共 ¥41 万)已逾期,请尽快跟进")OBSERVATION: {"status": "sent", "recipient": "张伟"}[Iteration 3]THOUGHT: 张伟通知完成,继续通知陈浩。ACTION: send_notification(ae_name="陈浩",contract_ids=["CTR-8901"],message="您负责的合同 CTR-8901(¥76,000)已逾期,请尽快跟进")OBSERVATION: {"status": "sent", "recipient": "陈浩"}[Iteration 4]THOUGHT: 通知全部发出,生成汇总报告。ACTION: generate_report(data={...}, report_type="overdue_summary")OBSERVATION: {"report_id":"RPT-20241105-001","download_url":"https://rainsuite.internal/reports/RPT-20241105-001.xlsx"}[Iteration 5]THOUGHT: 所有子任务完成,输出摘要。DONE: 本次处理共涉及 3 份逾期合同(总计 ¥486,000)。已分别向张伟(2 份)和陈浩(1 份)发送催款通知。汇总报告已生成:https://rainsuite.internal/reports/RPT-20241105-001.xlsx5 轮迭代,人工处理需要 15-20 分钟的任务压缩到秒级完成。效率的来源不是模型有多聪明,而是推理与执行的交替结构让每一步都有依据、有反馈、有纠偏空间。
四、ReAct 的真实局限任何值得认真用的技术,都值得提前了解它的边界。
上下文配额是有限资源。 每轮 Observation 都会消耗 token,复杂任务的执行历史很快会把上下文撑满。应对方式是引入历史摘要压缩,或者将需要长期保留的信息迁移到外部向量数据库。
工具数量多了,模型的选择准确率会下降。 当可用工具超过 20 个,模型选错工具或生成格式错误的调用参数的概率会明显上升。解决思路是在工具的 Schema 描述上下功夫,或者在模型选工具之前先用一个路由层缩小候选范围。
有工具调用不代表没有幻觉。 模型可能在 Thought 阶段推理出错,导致工具调用本身成功,但整个任务方向是偏的。评估 Agent 质量时,工具调用成功率只是过程指标,任务目标是否真正达成才是结果指标。
并行工具调用需要额外处理。 上面示例里通知张伟和通知陈浩是串行执行的,实际上完全可以并发。OpenAI 和 Anthropic 的主流模型已支持单次响应返回多个工具调用请求,但执行层需要相应改造为并发处理,代码复杂度会上升一个台阶。
五、小结ReAct Loop 的本质,是让推理和行动成为彼此的上下文,而不是两个独立步骤的简单拼接。
这个机制给了 Agent 一种"边做边想、根据反馈调整"的工作方式,让它在面对多步骤、不确定性高的任务时不容易跑偏。它不完美,但目前是工程上可解释性最好、落地最稳定的 Agent 实现路径。
评估一个 Agent 平台是否真正支持 ReAct,而不只是"接了工具调用的 API",可以问四个问题:能不能查看每步的推理过程;工具调用失败时有没有自动重试机制;是否支持人工介入节点的设置;多 Agent 协作时,子 Agent 的执行结果能否正确传递给上层编排。
这四个问题问完,基本就能判断面对的是一个真 Agent 平台,还是一个包了皮的聊天机器人。
上一篇:[AI Agent 与普通 AI 助手的区别是什么?]配资乐股票配资网址
富华优配提示:文章来自网络,不代表本站观点。