ReAct 模式详解：推理与行动如何让 AI 更智能

关键词

ReAct模式、大语言模型、推理-行动闭环、工具调用、思维链（CoT）、外部知识检索、自主决策

摘要

想象一下，如果大语言模型（LLM）像一个人类侦探：面对一个未解之谜，它不会仅凭脑子里的“直觉”或有限的记忆碎片给出答案，而是会先停下来想——“我的信息够吗？需要先查什么线索？怎么查？”（这是推理），然后真的去行动——比如翻遍案发现场的监控录像、询问证人、对比指纹数据库（这是调用外部工具/行动），接着把刚拿到的新线索消化一下，再接着推理下一步要查什么，直到把整个逻辑链条补全，锁定真凶（这是反馈迭代，形成闭环）。

这篇文章要讲的ReAct模式，就是把这种人类的“边想边做、边做边想”的认知过程，系统性地编码到大语言模型的交互逻辑里的技术方案。它解决了传统CoT（仅靠模型内部推理但容易“幻觉”）和仅靠工具调用（不做推理直接调用工具但效率低、易出错）的两大痛点，让LLM从“能说会道但不一定靠谱的顾问”，变成了“既会思考又会动手解决问题的全能助手”。

接下来的内容，我们会像侦探破案一样，一步步拆解ReAct模式的前世今生、核心原理、数学模型、算法流程、代码实现、实际应用、最佳实践、未来趋势——甚至会给大家准备一个完整的Python+LangChain+百度文心一言/OpenAI GPT的项目实战，让你看完就能亲手搭建一个ReAct智能助手。准备好了吗？让我们开始这场“推理-行动的探险之旅”吧！

正文部分

第1章 背景介绍：从“只会想”到“只会做”再到“边想边做”——LLM的进化困境与破局之路

章节核心内容要素
  • 核心概念：思维链（CoT）、直接工具调用、幻觉、检索增强生成（RAG）、自主决策能力
  • 问题背景：LLM在现实场景中落地时的两大核心痛点——“记忆/知识时效性与覆盖度不足导致的幻觉”和“缺乏直接干预现实/获取外部信息的能力导致的应用受限”
  • 问题描述：用生活化场景+真实实验数据分别论证CoT和直接工具调用的局限性
  • 问题解决：引出ReAct模式作为“破局者”的核心价值，并简述ReAct的起源与发展脉络
  • 边界与外延：区分ReAct与RAG、Agentic Workflow、工具增强LLM的异同，明确ReAct的适用场景与不适用场景
  • 概念结构与核心要素组成：暂时先勾勒出一个模糊的“推理-行动-观察-迭代”四要素闭环结构（后续章节会细化）
  • 概念之间的关系：用核心属性对比的Markdown表格对比CoT、直接工具调用、RAG、ReAct的异同；用Mermaid ER实体关系图和Mermaid交互关系图展示LLM在不同模式下的“实体-关系-交互”逻辑
  • 数学模型：本章暂时不涉及复杂数学模型，仅用直观的统计模型公式（如“幻觉率”的定义公式）辅助说明问题
  • 算法流程图：用Mermaid流程图分别展示CoT、直接工具调用、ReAct的基本交互流程，形成对比
  • 算法源代码：暂时不涉及，仅用伪代码片段描述三种模式的核心逻辑差异
  • 实际场景应用：本章会用3个大家每天都会遇到的生活化场景（比如“订明天从北京到上海最便宜的航班+酒店套餐”“解一道2024年最新的初中数学竞赛题”“帮家里老人写一篇今天社区文艺演出的观后感，并配一张演出的照片描述用于发朋友圈”）分别说明CoT和直接工具调用的局限性，以及ReAct为什么能解决这些问题
  • 项目介绍：暂时不涉及，仅预告后续章节的项目实战内容
  • 环境安装：暂时不涉及
  • 系统功能设计：暂时不涉及
  • 系统架构设计：暂时不涉及
  • 系统接口设计：暂时不涉及
  • 系统核心实现源代码：暂时不涉及
  • 最佳实践tips：暂时不涉及，仅预告后续章节会给出的实战经验
  • 行业发展与未来趋势：用Markdown表格整理从2018年BERT到2025年（预测）Agentic Workflow领域的关键技术发展节点
  • 本章小结：总结本章的核心内容，引出下一章“核心概念解析”
1.1 问题背景：LLM的“两大死穴”让它在现实中“寸步难行”？

2022年底ChatGPT的横空出世，彻底点燃了整个AI行业甚至全球的热情——大语言模型（LLM）终于从“实验室里的玩具”变成了“能真正改变生活和工作的工具”。当时有人甚至喊出了“人类最后的职业只剩下prompt工程师”的口号。

但当我们冷静下来，把ChatGPT、Claude、文心一言这些LLM真正用到复杂的、需要和外部世界交互的现实场景里时，却发现它并没有我们想象的那么“万能”——它有两个几乎致命的缺陷，我们可以把它们叫做LLM的“两大死穴”：

  1. 第一死穴：内部知识的“天花板”——时效性、覆盖度、准确性三重不足，导致“幻觉（Hallucination）”满天飞
    什么是“幻觉”？简单来说，就是LLM“一本正经地胡说八道”——它会编造一个不存在的电话号码、一个没有发表过的学术论文、一个根本不存在的历史事件，甚至会把张三的作品安到李四的头上，而且说得头头是道，让你根本分不清真假。

    为什么会产生幻觉？核心原因有三个：

    • 时效性不足：LLM的训练数据是有“截止日期”的——比如GPT-4的训练数据截止到2023年10月，Claude 3 Opus的截止到2024年1月，文心一言4.0的截止到2024年3月。这意味着LLM根本不知道“2024年巴黎奥运会中国代表团拿了多少枚金牌”“2024年11月1日北京到上海虹桥机场的最低机票价格是多少”“今天（202X年X月X日）北京的天气怎么样”这些动态变化的、训练数据截止日期之后的信息。
    • 覆盖度不足：LLM的训练数据虽然已经非常庞大了（比如GPT-3的训练数据有45TB，GPT-4的训练数据据说有1000TB以上），但它也不可能覆盖世界上的所有信息——比如你家楼下张阿姨昨天刚开的水果店的电话号码、你们公司2024年Q3的内部财务报表、你爷爷收藏的那幅清代山水画的真伪鉴定结果、你小学三年级时写的一篇获奖作文的内容……这些私人的、小众的、未公开的信息，LLM的训练数据里根本没有。
    • 准确性不足：即使是训练数据里有的信息，LLM也不一定能“准确地记住”——因为LLM本质上是一个基于统计规律的“文本预测机”，它不是一个“数据库”，也不是一个“搜索引擎”。它不会像数据库那样“精确地检索”到某个具体的信息，而是会根据训练数据里的“上下文语义关联”，“概率性地生成”下一个最可能的词。这就导致它有时候会把“关联度很高但实际上是错误的信息”也编进去——比如它会把“李白的《静夜思》是杜甫写的”这种错误信息生成出来，因为“李白”“杜甫”“唐诗”“静夜思”这些词在训练数据里的关联度非常高。

    为了让大家更直观地感受到“幻觉”的危害，我们来看一个真实的、发生在2023年美国法律界的案例：
    2023年5月，美国纽约南区联邦法院的一名法官驳回了一起民事案件的原告律师提交的一份法律意见书，原因是这份意见书里引用的6个法律案例都是ChatGPT编造的——这些案例根本不存在于美国联邦法院的判例数据库里！原告律师事后解释说，他是因为“偷懒”，才让ChatGPT帮他写法律意见书并找相关判例的，他根本没有想到ChatGPT会“编造判例”。最后，这名法官不仅驳回了法律意见书，还对原告律师处以了5000美元的罚款，并要求他参加“法律研究伦理”的培训课程。

    这个案例告诉我们：LLM的幻觉不仅仅是“搞笑”或者“误人子弟”，它还可能会给我们带来“严重的经济损失”甚至“法律风险”！

  2. 第二死穴：外部世界的“隔离墙”——缺乏直接干预现实/获取外部信息的能力，导致应用场景非常有限
    除了“一本正经地胡说八道”之外，LLM还有一个很大的问题：它只能“说”，不能“做”——它不能直接帮你订机票、订酒店、买东西、查天气、查股票、发邮件、发微信、写代码然后运行代码验证结果、控制家里的智能设备（比如开灯、开空调、拉窗帘）……它只能给你提供“建议”，告诉你“应该怎么做”，但具体的操作还需要你自己动手去完成。

    比如你问ChatGPT：“帮我订一张明天（202X年X月X日）早上8点从北京首都机场T3航站楼到上海虹桥机场T2航站楼最便宜的经济舱机票，并且帮我选一个靠窗户的座位。”
    ChatGPT的回答可能是这样的：

    “抱歉，我无法直接帮你订机票或选座位，因为我没有直接访问航空公司订票系统的权限。不过我可以给你提供一些建议：

    1. 你可以打开携程旅行、飞猪旅行、去哪儿旅行等第三方订票APP，或者打开中国国际航空、东方航空、南方航空等航空公司的官方APP/网站；
    2. 在搜索框里输入出发地‘北京首都机场T3航站楼’、目的地‘上海虹桥机场T2航站楼’、出发日期‘202X年X月X日’、出发时间范围‘早上7点到9点’、舱位‘经济舱’，然后点击搜索；
    3. 在搜索结果里找到最便宜的机票，然后点击预订；
    4. 在预订过程中，输入你的个人信息（姓名、身份证号/护照号、手机号等），然后选择支付方式；
    5. 支付成功后，你可以在‘我的订单’里找到这张机票，然后点击‘选座’，选择一个靠窗户的座位。”

    虽然ChatGPT的回答已经非常“详细”和“贴心”了，但它还是没有帮你解决“根本问题”——你还是需要自己动手去完成这一系列复杂的操作。这对于那些“工作很忙，没有时间自己动手订机票”的人，或者那些“不太会使用智能手机/电脑，根本不知道怎么订机票”的人（比如家里的老人）来说，是非常“不方便”的。

    再比如你问ChatGPT：“帮我写一段Python代码，计算1到100的所有质数的和，然后运行这段代码，告诉我结果。”
    ChatGPT的回答可能是这样的：

    “好的，这是一段计算1到100的所有质数的和的Python代码：

    def is_prime(n):
    if n <= 1:
        return False
    if n <= 3:
        return True
    if n % 2 == 0 or n % 3 == 0:
        return False
    i = 5
    while i * i <= n:
        if n % i == 0 or n % (i + 2) == 0:
            return False
        i += 6
    return True

prime_sum = 0
for num in range(1, 101):
    if is_prime(num):
        prime_sum += num

print(f"1到100的所有质数的和是：{prime_sum}")

    这段代码的运行结果应该是1060。你可以把这段代码复制到Python编辑器（比如PyCharm、VS Code、Jupyter Notebook等）里运行验证一下。”

    虽然ChatGPT写的这段代码大概率是正确的（1到100的质数和确实是1060），但它还是没有帮你解决“根本问题”——你还是需要自己动手去复制代码、打开Python编辑器、粘贴代码、运行代码、查看结果。如果ChatGPT写的代码有bug（比如它有时候会把range(1,101)写成range(1,100)，这样结果就会变成1059，少了100以内的最后一个质数97），你还需要自己动手去调试代码——这对于那些“不太会写Python代码，根本不知道怎么调试bug”的人来说，是非常“困难”的。

1.2 问题描述：从“只会想”的CoT到“只会做”的直接工具调用——前人的尝试与它们的局限性

为了解决LLM的“两大死穴”，AI领域的研究者们做了很多尝试，其中最有代表性的两个方案是思维链（Chain of Thought，简称CoT）和直接工具调用（Direct Tool Use）。接下来，我们就用生活化场景+真实实验数据分别论证这两个方案的局限性。

1.2.1 方案一：思维链（CoT）——让LLM“先想清楚再回答”，但还是逃不过“幻觉”的魔爪

什么是“思维链（CoT）”？简单来说，就是让LLM不要直接给出答案，而是先一步步地展示自己的“推理过程”，然后再根据推理过程给出最终的答案。

CoT的概念是由Google Research的Jason Wei等人在2022年1月发表的论文《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》中提出的。这篇论文的核心观点是：对于“需要复杂推理能力的任务”（比如数学应用题、逻辑推理题、代码调试题等），只要我们给LLM提供一个“思维链示例（Few-Shot CoT Example）”——也就是一个“问题+一步步的推理过程+最终答案”的示例，那么LLM就会模仿这个示例，也一步步地展示自己的推理过程，然后再给出最终的答案，这样可以显著提升LLM在这些任务上的表现。

为了让大家更直观地理解CoT，我们来看一个数学应用题的示例：

传统的Zero-Shot Prompt（直接问问题，不给示例）：

问题：小明有10个苹果，他给了小红3个，然后又买了5个，请问小明现在有多少个苹果？
模型回答：小明现在有12个苹果。

Few-Shot CoT Prompt（给一个示例，然后问问题）：

示例：
问题：小红有5个橘子，她吃了2个，然后又买了4个，请问小红现在有多少个橘子？
推理过程：

  1. 首先，小红一开始有5个橘子；
  2. 然后，她吃了2个，所以剩下的橘子数量是5 - 2 = 3个；
  3. 接着，她又买了4个，所以现在的橘子数量是3 + 4 = 7个；
    最终答案：小红现在有7个橘子。

现在请回答下面的问题：
问题：小明有10个苹果，他给了小红3个，然后又买了5个，请问小明现在有多少个苹果？
模型回答：
推理过程：

  1. 首先，小明一开始有10个苹果；
  2. 然后，他给了小红3个，所以剩下的苹果数量是10 - 3 = 7个；
  3. 接着，他又买了5个，所以现在的苹果数量是7 + 5 = 12个；
    最终答案：小明现在有12个苹果。

从这个示例可以看出，CoT确实可以让LLM“更清晰地思考”——它会把复杂的问题分解成一个个简单的小问题，然后一步步地解决这些小问题，最后再把小问题的答案组合起来，得到最终的大问题的答案。

Jason Wei等人在论文中用**多种不同的LLM（比如GPT-3 175B、PaLM 540B等）和多种不同的需要复杂推理能力的任务（比如GSM8K数学应用题、SVAMP数学应用题、AQuA逻辑推理题、CommonsenseQA常识推理题等）**做了大量的实验，实验结果表明：CoT可以显著提升LLM在这些任务上的准确率——比如在GSM8K数学应用题上，GPT-3 175B的准确率从17.9%（Zero-Shot）提升到了58.1%（Few-Shot CoT），PaLM 540B的准确率从18.7%（Zero-Shot）提升到了74.4%（Few-Shot CoT）！

这个实验结果非常震撼，CoT也因此成为了LLM领域的“里程碑式的技术”——它第一次让人们意识到：LLM并不是一个“只会鹦鹉学舌的文本预测机”，它确实具有一定的“复杂推理能力”！

但问题是：CoT虽然可以提升LLM的“推理能力”，但它并不能解决LLM的“第一死穴”——内部知识的三重不足导致的幻觉！ 甚至在某些情况下，CoT还会“加剧”幻觉——因为LLM会“一步步地编造自己的推理过程”，让幻觉看起来“更真实”“更可信”！

为了让大家更直观地感受到CoT的局限性，我们来看一个生活化场景的示例和一个真实实验数据的示例：

生活化场景示例：

问题：2024年巴黎奥运会中国代表团拿了多少枚金牌？
Few-Shot CoT Prompt（给一个历史奥运会的示例，然后问问题）：
示例：
问题：2020年东京奥运会中国代表团拿了多少枚金牌？
推理过程：

  1. 首先，我需要回忆一下2020年东京奥运会的举办时间——2020年东京奥运会因为新冠疫情推迟到了2021年举办，但它的正式名称还是“2020年东京奥运会”；
  2. 然后，我需要回忆一下2020年东京奥运会中国代表团的金牌数量——我记得好像是38枚金牌，位列金牌榜第二名，仅次于美国代表团的39枚金牌；
  3. 接着，我需要确认一下这个数字是否正确——哦对了，我记得当时有很多媒体报道过，比如人民日报、新华社、央视新闻等，都报道了中国代表团在2020年东京奥运会上拿了38枚金牌；
    最终答案：2020年东京奥运会中国代表团拿了38枚金牌。

现在请回答下面的问题：
问题：2024年巴黎奥运会中国代表团拿了多少枚金牌？
模型回答（假设这个模型的训练数据截止到2024年3月，而巴黎奥运会是2024年7月26日到8月11日举办的）：
推理过程：

  1. 首先，我需要回忆一下2024年巴黎奥运会的举办时间——2024年巴黎奥运会的举办时间是2024年7月26日到8月11日；
  2. 然后，我需要回忆一下中国代表团在历届夏季奥运会上的金牌数量——1984年洛杉矶奥运会15枚、1988年汉城奥运会5枚、1992年巴塞罗那奥运会16枚、1996年亚特兰大奥运会16枚、2000年悉尼奥运会28枚、2004年雅典奥运会32枚、2008年北京奥运会51枚（后来因为兴奋剂问题取消了3枚，变成48枚）、2012年伦敦奥运会38枚、2016年里约奥运会26枚、2020年东京奥运会38枚；
  3. 接着，我需要根据历届夏季奥运会的金牌数量来“预测”2024年巴黎奥运会中国代表团的金牌数量——从历届夏季奥运会的金牌数量来看，中国代表团的金牌数量整体上是呈“上升趋势”的，除了1988年汉城奥运会和2016年里约奥运会之外；2020年东京奥运会中国代表团拿了38枚金牌，和2012年伦敦奥运会持平，位列金牌榜第二名；2024年巴黎奥运会是中国代表团在“后东京奥运会时代”参加的第一届夏季奥运会，我相信中国代表团的运动员们一定会“再接再厉，勇攀高峰”，所以我预测2024年巴黎奥运会中国代表团会拿40枚金牌，位列金牌榜第一名；
  4. 最后，我需要确认一下这个预测是否合理——哦对了，我记得有很多体育媒体（比如ESPN、BBC Sport、央视体育等）都在2024年年初做过预测，预测中国代表团在2024年巴黎奥运会上会拿35-45枚金牌，所以我的预测40枚是在这个合理范围内的；
    最终答案：2024年巴黎奥运会中国代表团拿了40枚金牌，位列金牌榜第一名。

从这个示例可以看出，虽然LLM使用了CoT，一步步地展示了自己的“推理过程”，但它的“最终答案”完全是“编造”的——因为它的训练数据截止到2024年3月，根本不知道2024年巴黎奥运会的真实结果！而且它的“推理过程”也是“编造”的——它说“有很多体育媒体在2024年年初预测中国代表团会拿35-45枚金牌”，这个可能是真的，但它说“我的预测40枚是在这个合理范围内的，所以2024年巴黎奥运会中国代表团拿了40枚金牌”，这个逻辑是完全错误的——“预测的合理性”和“结果的真实性”是两回事！

真实实验数据示例：
为了更客观地论证CoT的局限性，我们来看一个由Meta AI的研究者们在2022年10月发表的论文《Toolformer: Language Models Can Teach Themselves to Use Tools》中做的实验：
在这个实验中，研究者们用GPT-J 6B（一个中等规模的LLM）做了一个“幻觉率测试”——测试的任务是“回答关于世界上一些城市的人口数量的问题”，测试的数据集是“一个包含了1000个关于城市人口数量的问题的数据集，这些问题的答案都可以在维基百科上找到”。

实验结果如下表所示：

Prompt类型 模型回答的准确率 模型回答的幻觉率
Zero-Shot Prompt 32.1% 67.9%
Few-Shot Standard Prompt（给几个“问题+直接答案”的示例） 35.7% 64.3%
Few-Shot CoT Prompt（给几个“问题+一步步的推理过程+最终答案”的示例） 38.2% 61.8%

从这个实验结果可以看出：虽然CoT可以稍微提升LLM回答问题的准确率（从32.1%提升到38.2%），但它对降低幻觉率的帮助非常有限（从67.9%降低到61.8%），大部分的回答还是“幻觉”！

1.2.2 方案二：直接工具调用——让LLM“直接动手获取外部信息/干预现实”，但效率低、易出错，缺乏“自主决策能力”

为了解决LLM的“第一死穴”（内部知识不足导致的幻觉）和“第二死穴”（缺乏外部世界交互能力导致的应用受限），AI领域的研究者们又提出了另一个方案：直接工具调用（Direct Tool Use）。

什么是“直接工具调用”？简单来说，就是给LLM提供一系列“预定义好的外部工具”（比如搜索引擎、计算器、天气API、机票酒店API、代码解释器、数据库查询接口等），然后告诉LLM“如果遇到什么类型的问题，就调用什么类型的工具”，最后LLM会根据问题的类型，直接调用对应的工具，获取外部信息，然后根据外部信息给出最终的答案，或者直接完成干预现实的操作。

直接工具调用的概念其实很早就有了——早在2018年BERT问世之前，就有很多研究者在做“让传统的NLP模型调用外部工具”的研究，但这些研究的效果都不太好，因为传统的NLP模型的“自然语言理解能力”和“语义匹配能力”都比较差，很难准确地判断“什么时候需要调用工具”“需要调用什么工具”“需要给工具传递什么参数”。

直到2022年底ChatGPT的横空出世，LLM的“自然语言理解能力”和“语义匹配能力”得到了质的飞跃，直接工具调用才真正变得“可行”和“实用”——2023年3月，OpenAI发布了ChatGPT Plugins插件系统，允许第三方开发者为ChatGPT开发各种插件（比如Wolfram Alpha、Zapier、Expedia等），用户可以在ChatGPT里直接安装和使用这些插件；2023年6月，OpenAI又发布了GPT-4 Code Interpreter（后来改名为Advanced Data Analysis），允许GPT-4直接调用Python代码解释器，写代码、运行代码、调试代码、分析数据、生成可视化图表等；2023年11月，OpenAI又发布了Assistants API，允许开发者更方便地为自己的应用集成“工具调用”功能；几乎同时，国内的LLM厂商（比如百度文心一言、阿里通义千问、腾讯混元、字节豆包等）也纷纷推出了自己的“工具调用”功能。

为了让大家更直观地理解直接工具调用，我们来看一个生活化场景的示例：

问题：帮我查一下今天（202X年X月X日）北京的天气怎么样，然后算一下1到100的所有质数的和。
直接工具调用的Prompt（给LLM预定义好两个工具：天气API和Python代码解释器，然后告诉LLM“如果遇到关于天气的问题，就调用天气API；如果遇到关于数学计算的问题，尤其是需要复杂计算的问题，就调用Python代码解释器”）：
你现在拥有两个工具：

  1. 天气API：可以查询世界上任何城市的实时天气、未来7天的天气预报等信息。工具的输入参数是“城市名称”，工具的输出格式是JSON格式，包含以下字段：城市名称、当前日期、当前温度（摄氏度）、当前天气状况（晴、多云、阴、雨、雪等）、当前风速（米/秒）、当前湿度（%）等。
  2. Python代码解释器：可以执行任意的Python代码，工具的输入参数是“Python代码字符串”，工具的输出格式是“代码的执行结果（标准输出和标准错误）”。

你的任务是：根据用户的问题，直接调用对应的工具，获取外部信息，然后根据外部信息给出最终的答案。如果问题不需要调用工具，就直接回答。

现在请回答下面的问题：
问题：帮我查一下今天（202X年X月X日）北京的天气怎么样，然后算一下1到100的所有质数的和。
模型的交互过程：

  1. 模型首先判断用户的问题包含两个子问题：
    a. 子问题1：帮我查一下今天（202X年X月X日）北京的天气怎么样——这是一个关于天气的问题，需要调用天气API；
    b. 子问题2：然后算一下1到100的所有质数的和——这是一个关于数学计算的问题，需要调用Python代码解释器；
  2. 模型直接调用天气API，输入参数是“北京”；
  3. 天气API返回结果（JSON格式）： 
    {
  "city_name": "北京",
  "current_date": "202X年X月X日",
  "current_temperature": 15,
  "current_weather_condition": "多云",
  "current_wind_speed": 3.2,
  "current_humidity": 45
}
  4. 模型直接调用Python代码解释器，输入参数是： 
    def is_prime(n):
    if n <= 1:
        return False
    if n <= 3:
        return True
    if n % 2 == 0 or n % 3 == 0:
        return False
    i = 5
    while i * i <= n:
        if n % i == 0 or n % (i + 2) == 0:
            return False
        i += 6
    return True

prime_sum = 0
for num in range(1, 101):
    if is_prime(num):
        prime_sum += num

print(prime_sum)
  5. Python代码解释器返回结果： 
    1060
  6. 模型根据天气API和Python代码解释器的返回结果，给出最终的答案：

    今天（202X年X月X日）北京的天气是多云，当前温度是15摄氏度，当前风速是3.2米/秒，当前湿度是45%。
    1到100的所有质数的和是1060。

从这个示例可以看出，直接工具调用确实可以解决LLM的“两大死穴”——它可以通过调用外部工具获取训练数据里没有的、动态变化的、私人的、小众的信息，从而避免幻觉；它也可以通过调用外部工具直接完成干预现实的操作，从而拓展LLM的应用场景。

但问题是：直接工具调用虽然可以解决LLM的“两大死穴”，但它也有三个很大的局限性：

  1. 局限性一：效率低，需要“多次来回交互”
    在直接工具调用的模式下，LLM通常是“遇到一个子问题，就调用一次工具，获取工具返回结果，然后再处理下一个子问题”——如果用户的问题比较复杂，包含很多个子问题，那么就需要“多次来回交互”，效率非常低。

    比如我们把刚才的问题稍微改得复杂一点：

    问题：帮我查一下今天（202X年X月X日）北京、上海、广州、深圳这四个城市的天气怎么样，然后算一下这四个城市的当前温度的平均值、最大值、最小值，最后用Python代码生成一张这四个城市的当前温度的柱状图。

    在直接工具调用的模式下，LLM需要“多次来回交互”：

    • 第一次交互：调用天气API查询北京的天气；
    • 第二次交互：调用天气API查询上海的天气；
    • 第三次交互：调用天气API查询广州的天气；
    • 第四次交互：调用天气API查询深圳的天气；
    • 第五次交互：调用Python代码解释器计算平均值、最大值、最小值；
    • 第六次交互：调用Python代码解释器生成柱状图；
      总共需要“六次来回交互”，效率非常低——如果用户的问题更复杂，包含更多的子问题，那么交互次数会更多，效率会更低。

  2. 局限性二：易出错，缺乏“自主规划能力”和“错误修正能力”
    在直接工具调用的模式下，LLM通常是“根据问题的类型，直接调用对应的工具”，它不会“先停下来想——‘这个问题的整体流程是什么？我需要先调用什么工具，再调用什么工具？如果第一次调用工具失败了，或者工具返回的结果不符合我的预期，我应该怎么办？’”——也就是说，它缺乏“自主规划能力”和“错误修正能力”，很容易出错。

    比如我们把刚才的问题再稍微改得复杂一点：

    问题：帮我订一张明天（202X年X月X日）早上7点到9点从北京首都机场T3航站楼到上海虹桥机场T2航站楼最便宜的经济舱机票，并且帮我选一个靠窗户的、靠近紧急出口的座位（紧急出口的座位通常会更宽敞一些）。

    在直接工具调用的模式下，LLM可能会出现以下几种错误：

    • 错误一：调用工具的参数错误——比如它可能会把“出发地”写成“北京首都机场”，而不是“北京首都机场T3航站楼”，这样搜索结果里可能会包含北京首都机场T1/T2航站楼出发的机票，而这些机票并不是用户想要的；
    • 错误二：调用工具的顺序错误——比如它可能会先选座位，再订机票，但实际上“选座位”是“订机票”之后的操作，必须先订到机票，才能选座位；
    • 错误三：缺乏错误修正能力——比如如果第一次搜索机票的结果里没有“靠窗户的、靠近紧急出口的座位”的机票，LLM可能会直接告诉用户“没有符合要求的机票”，但实际上它可以“先停下来想——‘用户的核心需求是订一张明天早上7点到9点从北京首都机场T3到上海虹桥机场T2最便宜的经济舱机票，选座位是次要需求。如果没有符合次要需求的机票，我可以先订符合核心需求的机票，然后告诉用户没有符合要求的座位，或者建议用户换一个时间范围、换一个出发地/目的地航站楼、换一个舱位’”，然后再采取相应的行动，但直接工具调用的模式下的LLM不会这么做。

  3. 局限性三：缺乏“深层推理能力”，只能处理“简单的、直接的工具调用任务”
    在直接工具调用的模式下，LLM通常是“根据问题的类型，直接调用对应的工具”，它不会“对工具返回的结果进行深层的推理和分析”，也不会“把多个工具返回的结果组合起来，进行更复杂的推理和分析”——也就是说，它缺乏“深层推理能力”，只能处理“简单的、直接的工具调用任务”，无法处理“需要复杂推理和多个工具协同工作的任务”。

    比如我们来看一个需要复杂推理和多个工具协同工作的生活化场景的示例：

    问题：我的爷爷今年75岁，他患有高血压和糖尿病，他想在明天（202X年X月X日）早上8点到10点之间去家附近的公园散步。请帮我：

    1. 查一下爷爷家附近的公园有哪些（爷爷家的地址是北京市朝阳区建国路88号SOHO现代城A座）；
    2. 查一下这些公园明天早上8点到10点之间的天气怎么样；
    3. 查一下这些公园的人流量明天早上8点到10点之间大不大；
    4. 查一下这些公园有没有适合高血压和糖尿病患者散步的设施（比如平坦的步道、休息座椅、公共厕所、直饮水站等）；
    5. 根据以上信息，给爷爷推荐一个最适合散步的公园，并说明推荐理由。

    在直接工具调用的模式下，LLM可能会：

    • 调用地图API查询爷爷家附近的公园；
    • 调用天气API查询这些公园明天早上8点到10点之间的天气；
    • 调用人流量API查询这些公园明天早上8点到10点之间的人流量；
    • 调用公园信息API查询这些公园的设施；
    • 然后直接把这些信息罗列出来，告诉用户“这是我查到的信息，你自己选一个吧”——它不会“对这些信息进行深层的推理和分析”，比如：
      a. 对于高血压患者来说，明天早上的温度如果太高（比如超过25摄氏度）或者太低（比如低于10摄氏度），或者风速太大（比如超过5米/秒），或者天气状况是雨、雪、雾霾等，都不适合散步；
      b. 对于糖尿病患者来说，明天早上的血糖水平通常会比较低（空腹血糖），所以散步的时间不宜太长（比如不宜超过1小时），而且最好选择有直饮水站的公园，方便及时补充水分和能量；
      c. 对于75岁的老人来说，人流量太大的公园不适合散步，容易发生碰撞；而且最好选择有平坦的步道、充足的休息座椅、公共厕所的公园；
      它也不会“根据这些推理和分析的结果，给爷爷推荐一个最适合散步的公园，并说明推荐理由”——也就是说，它缺乏“深层推理能力”和“综合决策能力”。
1.3 问题解决：ReAct模式——“边想边做、边做边想”，让LLM既会思考又会动手，成为全能助手

既然CoT和直接工具调用都有各自的局限性，那么有没有一种方案可以结合CoT和直接工具调用的优点，同时避免它们的缺点呢？

答案是肯定的——这个方案就是ReAct模式！

ReAct模式的概念是由Google Research的Shunyu Yao等人在2022年10月发表的论文《ReAct: Synergizing Reasoning and Acting in Language Models》中提出的。这篇论文的核心观点是：人类在解决复杂问题时，通常会采用“边想边做、边做边想”的认知过程——也就是“先推理一下需要做什么，然后采取行动，获取观察结果，再根据观察结果推理下一步需要做什么，然后再采取行动，获取新的观察结果，如此反复，直到解决问题”。如果我们把这种人类的认知过程系统性地编码到大语言模型的交互逻辑里，让LLM也“边想边做、边做边想”，那么就可以结合CoT和直接工具调用的优点，同时避免它们的缺点，显著提升LLM在复杂任务上的表现！

为了让大家更直观地理解ReAct模式，我们先来看一个论文中提到的“HotpotQA多跳问答任务”的示例（HotpotQA是一个需要“多跳推理”和“外部知识检索”的问答数据集——也就是说，LLM不能仅凭内部知识直接回答问题，它需要先检索多个外部知识源，然后把这些知识源的信息组合起来，进行多跳推理，才能得到最终的答案）：

问题：George Washington was the first president of the United States. Who was the first president of the country that is geographically closest to the US?
（中文翻译：乔治·华盛顿是美国的第一任总统。请问，地理上离美国最近的国家的第一任总统是谁？）

ReAct模式的交互过程：

Thought（推理）： 我需要解决这个问题。首先，我需要先确定地理上离美国最近的国家是哪个。我不确定我脑子里的记忆是否准确，所以我应该先调用Wikipedia检索工具，查询“地理上离美国最近的国家”。
Action（行动）： Search[geographically closest country to the United States]
Observation（观察）： The country that is geographically closest to the United States is Russia, specifically the Big Diomede Island (Russian: Остров Ратманова, Ostrov Ratmanova) which is only 3.8 kilometers (2.4 miles) away from Little Diomede Island (Alaska, US).
Thought（推理）： 好的，Wikipedia检索结果告诉我，地理上离美国最近的国家是俄罗斯。接下来，我需要确定俄罗斯的第一任总统是谁。我记得俄罗斯的第一任总统好像是叶利钦，但我不确定，所以我应该再调用Wikipedia检索工具，查询“俄罗斯的第一任总统”。
Action（行动）： Search[first president of Russia]
Observation（观察）： The first president of the Russian Federation (Russia) was Boris Yeltsin (Борис Николаевич Ельцин), who served from July 10, 1991, to December 31, 1999.
Thought（推理）： 完美！Wikipedia检索结果告诉我，俄罗斯的第一任总统是鲍里斯·叶利钦。现在，我已经收集到了所有需要的信息，可以回答用户的问题了。
Final Answer（最终答案）： The first president of the country that is geographically closest to the US (Russia) is Boris Yeltsin.

从这个示例可以看出，ReAct模式的交互过程是一个清晰的“四要素闭环”：

  1. Thought（推理）： LLM停下来想——“我的信息够吗？需要先查什么线索？怎么查？如果拿到了线索，下一步应该怎么做？”
  2. Action（行动）： LLM根据推理的结果，采取具体的行动——比如调用外部工具（搜索引擎、计算器、天气API等）、或者直接输出最终答案（如果已经收集到了所有需要的信息）。
  3. Observation（观察）： LLM获取行动的结果——如果是调用外部工具，那么观察结果就是工具的返回值；如果是直接输出最终答案，那么交互过程就结束了。
  4. Iteration（迭代）： LLM把观察结果作为新的信息，添加到自己的“上下文窗口”里，然后再回到第一步“Thought（推理）”，继续推理下一步需要做什么，直到解决问题。

正是这个清晰的“四要素闭环”，让ReAct模式结合了CoT和直接工具调用的优点，同时避免了它们的缺点：

  • 结合了CoT的优点： ReAct模式让LLM“先想清楚再行动”，它会对问题进行分解，对工具返回的结果进行深层的推理和分析，把多个工具返回的结果组合起来进行更复杂的推理和分析，具有很强的“自主规划能力”“深层推理能力”和“综合决策能力”。
  • 结合了直接工具调用的优点： ReAct模式让LLM“直接动手获取外部信息/干预现实”，它可以通过调用外部工具获取训练数据里没有的、动态变化的、私人的、小众的信息，从而避免幻觉；它也可以通过调用外部工具直接完成干预现实的操作，从而拓展LLM的应用场景。
  • 避免了CoT的缺点： ReAct模式让LLM“边做边想”，它不会仅凭内部知识进行推理，而是会通过调用外部工具获取真实的、可靠的信息，然后再根据这些真实的、可靠的信息进行推理，从而大大降低了幻觉率。
  • 避免了直接工具调用的缺点： ReAct模式让LLM“先想清楚再行动”，它会对问题的整体流程进行规划，会对调用工具的参数和顺序进行检查，会对行动的结果进行评估，如果第一次行动失败了，或者行动的结果不符合预期，它会根据推理的结果采取相应的修正措施，具有很强的“错误修正能力”；此外，ReAct模式还可以让LLM“一次性规划多个行动”，然后再“一次性执行多个行动”（不过目前大部分ReAct模式的实现还是“一次规划一个行动，一次执行一个行动”，因为这样更可控），从而提高了效率。

Shunyu Yao等人在论文中用**多种不同的LLM（比如PaLM 540B、GPT-3 175B等）**和

# react.js # 人工智能 # 前端
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

AI Stock 技术白皮书

AI Stock 旨在打造一个 **AI 原生的智能股票数据分析平台**，将大语言模型的深度推理能力与 A 股全市场数据深度融合，构建从策略创建、条件筛选、回测验证、策略优化到定时执行的 **全链路自动化闭环**，为用户提供多维度的股票数据分析与筛选能力，辅助投资决策

avatar AtomGit开源社区
cover

观点抽取常见模型与多模态策略

avatar AtomGit开源社区
cover

【Linux命令饲养指南】Ubuntu 安装 MySQL【AI辅助实现】

avatar AtomGit开源社区