学习目标读完本章后你将掌握理解传统LLM在动态交互场景下的根本局限性掌握ReAct模式的核心思想与思考-行动-观察循环机制深入理解ReAct与Chain-of-Thought的本质区别与各自适用场景掌握Function Calling的技术原理与工具定义规范能够设计实现多工具协作的ReAct Agent系统了解ReAct模式的优势、局限及与其他Agent范式的对比一、从静态生成到动态交互1.1 传统LLM的局限性知识截止与行动缺失传统的大语言模型LLM本质上是一个静态文本生成器。它的运作模式可以抽象为Outputf(Input,θ) \text{Output} f(\text{Input}, \theta)Outputf(Input,θ)其中θ\thetaθ是模型在预训练阶段学习的参数。这意味着知识受限于训练数据模型只知道截至训练截止日期的信息无法获取实时信息无法查询天气、股票、新闻等动态数据不能执行实际操作不能订票、发邮件、控制智能家居这种局限性在现实中带来诸多问题。当用户询问今天北京的天气如何时模型只能基于训练数据中的历史天气模式进行猜测而非给出准确的实时信息。当用户希望帮我订一张去上海的机票时模型甚至无法启动订票流程因为缺少与外部系统交互的能力。更深层的问题在于幻觉Hallucination。当模型处理涉及精确数值计算、长尾事实或专业领域知识的查询时它可能自信满满地编造看似合理但实际错误的内容。例如大数乘法、近期新闻事件、特定股票的当前价格——这些问题都在传统LLM的能力边界之外。1.2 工具调用给LLM装上双手为了突破上述局限研究者提出了**工具调用Tool Calling / Function Calling**机制。这一思想的核心洞察是LLM的强项是理解和推理弱项是精确计算和实时感知。我们应该让它专注于自己擅长的部分同时将行动能力委托给专业的外部工具。工具调用的工作流程如下┌─────────────────────────────────────────────────────────┐ │ 工具调用流程 │ ├─────────────────────────────────────────────────────────┤ │ │ │ 1. 理解意图 ──→ LLM分析用户query识别需要执行的动作 │ │ ↓ │ │ 2. 选择工具 ──→ LLM从可用工具中选择最适合的一个 │ │ ↓ │ │ 3. 参数生成 ──→ LLM构造工具调用的参数JSON格式 │ │ ↓ │ │ 4. 执行工具 ──→ 系统/开发者执行具体函数 │ │ ↓ │ │ 5. 结果整合 ──→ LLM将工具返回结果融入最终回答 │ │ │ └─────────────────────────────────────────────────────────┘这个流程的关键在于解耦。LLM不需要知道天气API的具体调用方式只需要知道有一个叫get_weather的工具可以获取天气信息。工具的实现细节对LLLM是透明的这使得系统具有很好的扩展性——添加新工具只需定义接口无需修改LLM本身。二、ReAct的核心原理2.1 推理与行动的融合ReAct的诞生ReActReasoning Acting是由Google Research和普林斯顿大学于2022年联合提出的框架其论文标题为《ReAct: Synergizing Reasoning and Acting in Language Models》。这一工作的核心贡献在于首次系统性地提出将LLM的**推理Reasoning与行动Acting**交织在一起形成一种边想边做的交互范式。在ReAct之前主流的Agent研究主要沿两条路线展开纯推理路线Chain-of-Thought让模型展示思考过程但不执行任何外部操作纯行动路线Action Models让模型直接生成动作但缺乏显式的推理链ReAct的创新之处在于第三条路将推理和行动视为互补而非替代的关系。推理可以帮助决定下一步做什么而行动可以提供新的信息来支撑后续推理。2.2 ReAct vs Chain-of-Thought本质区别为了更好地理解ReAct的价值我们通过一个具体例子对比ReAct与CoT的差异问题谁是2024年巴黎奥运会的金牌总数第一名Chain-of-Thought的回答思考我需要知道各国在2024年奥运会获得的金牌数。 根据我的训练数据我对体育赛事有一些了解... 美国在历届奥运会表现都很强... 中国也是体育强国... 我猜测可能是美国或中国... 回答可能是美国基于历史表现的推测问题在于模型基于过时的训练数据回答了一个有时效性的问题其答案很可能是不准确的。ReAct的回答思考这是一个关于2024年奥运会的事实性问题 我需要查询最新的权威数据才能准确回答。 行动调用搜索API查询2024年巴黎奥运会金牌榜 观察搜索结果显示中国队获得91枚金牌位居第一 思考现在我有了准确的实时数据可以给出答案了 回答中国以91枚金牌位居2024年巴黎奥运会金牌榜第一名关键区别在于ReAct通过行动打破了知识截止的限制而CoT只能基于内部知识进行推理。用数学语言描述假设问题的真答案为y∗y^*y∗模型对答案的置信度为pppCoTyCoTarg⁡max⁡y P(y∣x,reasoning_chain)y_{CoT} \arg\max_y\ P(y | x, \text{reasoning\_chain})yCoT​argmaxy​P(y∣x,reasoning_chain)其中xxx是问题置信度ppp依赖于训练数据的覆盖程度ReActyReActh(f1(x),f2(f1(x)),...,fn(fn−1(x)))y_{ReAct} h(f_1(x), f_2(f_1(x)), ..., f_n(f_{n-1}(x)))yReAct​h(f1​(x),f2​(f1​(x)),...,fn​(fn−1​(x)))其中fif_ifi​是工具调用nnn是迭代次数直到置信度达到阈值2.3 思维链格式设计为什么这样设计ReAct采用特定的Thought-Action-Observation循环格式这个格式的设计蕴含着深刻的工程考量Question:今天北京天气如何需要带伞吗Thought:我需要先查询北京的天气信息才能回答这个问题Action:get_weatherAction Input:{city:北京}Observation:{temperature:25°C,weather:晴,humidity:40%}Thought:根据天气信息北京今天是晴天不下雨不需要带伞Final Answer:今天北京晴气温25°C湿度40%不需要带伞。格式设计的意图组成部分设计意图为什么重要Thought让LLM显式表达推理过程使思考过程可追溯、可调试Action明确指定要执行的工具避免LLM直接尝试行动导致混乱Action Input结构化的参数传递确保工具调用的正确性Observation外部世界的真实反馈为后续推理提供事实基础Final Answer明确的答案输出与中间步骤分离确保输出格式一致这个格式本质上是一种结构化的人机协作协议。它让LLM的思考和行动都变得透明可控而不是让LLM在黑盒状态下自由发挥。2.4 Prompt模板解析ReAct的灵魂ReAct的Prompt模板是整个框架的灵魂。一个典型的ReAct Prompt包含以下组成部分Answer the following question as best you can. You have access to the following tools: {tools} ← 插入可用工具的描述 Use the following format: Question: the input question you must answer Thought: you should always think about what to do Action: the action to take, should be one of [{tool_names}] Action Input: the input to the action Observation: the result of the action ... (this Thought/Action/Action Input/Observation can repeat N times) Thought: I now know the final answer Final Answer: your final answer to the original input question模板设计的工程考量显式约束通过大写格式关键词Thought, Action, Observation强化LLM对格式的遵循工具白名单限制LLM只能调用提供的工具防止其幻觉调用不存在的工具循环暗示通过…can repeat N times暗示多步推理是预期行为终止条件明确要求Final Answer作为循环终止信号三、工具调用的技术细节3.1 Function Calling的工作原理LLM如何决定调用工具现代LLM如GPT-4、Claude、Gemini原生支持Function Calling这一能力是如何实现的呢从技术角度看Function Calling本质上是结构化输出能力的扩展。传统上LLM输出自由文本而Function Calling要求LLM输出符合特定JSON Schema的结构化数据。┌────────────────────────────────────────────────────────────────┐ │ Function Calling 执行流程 │ ├────────────────────────────────────────────────────────────────┤ │ │ │ 用户输入北京天气怎么样 │ │ ↓ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ LLM推理过程思考是否需要工具 选择工具 生成参数 │ │ │ └─────────────────────────────────────────────────────────┘ │ │ ↓ │ │ 结构化输出 │ │ { │ │ tool_calls: [{ │ │ name: get_weather, │ │ arguments: {city: 北京} │ │ }] │ │ } │ │ ↓ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ 系统执行工具get_weather(city北京) │ │ │ │ → {temperature: 25, weather: 晴, humidity: 40} │ │ │ └─────────────────────────────────────────────────────────┘ │ │ ↓ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ LLM整合工具结果生成自然语言回答 │ │ │ └─────────────────────────────────────────────────────────┘ │ │ ↓ │ │ 最终回答今天北京晴朗气温25°C湿度40%非常适合出行。 │ │ │ └────────────────────────────────────────────────────────────────┘为什么LLM能够理解何时该调用工具答案是上下文学习In-Context Learning。当我们在Prompt中提供工具的描述描述工具能做什么调用格式的示例当前用户的问题LLM能够通过Few-shot Learning的方式从示例中学习问题-工具选择-参数构造的映射规律。这就是为什么ReAct Prompt中的格式说明如此重要——它本质上是在给LLM提供调用工具的示例。3.2 工具定义规范如何让LLM正确理解工具工具定义是Function Calling系统中最关键的设计决策之一。一个良好的工具定义应该包含{name:get_weather,description:获取指定城市的实时天气信息包括温度、天气状况和湿度,parameters:{type:object,properties:{city:{type:string,description:城市名称需要包含省份或国家以避免歧义如北京、上海市、Tokyo},unit:{type:string,enum:[celsius,fahrenheit],description:温度单位默认celsius摄氏度}},required:[city]}}工具定义各字段的作用字段作用设计建议name工具的唯一标识符使用清晰的动词短语如get_weather、search_newsdescription告诉LLM工具能做什么这是LLM选择工具的主要依据应该详细且无歧义parameters定义输入参数使用JSON Schema格式便于LLM理解和验证required标记必填参数减少LLM生成错误参数的概率描述description的设计原则功能导向描述做什么而非怎么做参数关联说明参数的具体含义和取值范围边界条件描述可能的异常情况使用示例帮助LLM理解正确的调用方式3.3 多工具协作机制如何组织多个工具当系统中有多个工具时LLM需要能够理解工具之间的关系哪些工具可以独立使用哪些需要按顺序选择最合适的工具根据用户意图选择最相关的工具规划调用顺序对于复杂任务确定工具调用的先后依赖# 多工具场景示例用户询问投资分析tools[{name:search_stock,description:搜索股票信息根据股票名称或代码查找股票symbol,},{name:get_stock_price,description:获取股票当前价格和涨跌幅,},{name:get_financial_metrics,description:获取股票的财务指标如PE、市值、股息率等,},{name:calculator,description:执行数学计算支持加减乘除和百分比的计算,}]# LLM的思考链# 1. 用户想了解苹果股票的投资信息# 2. 需要先通过search_stock找到苹果的股票代码(AAPL)# 3. 然后并行调用get_stock_price和get_financial_metrics# 4. 最后用calculator计算收益率等指标多工具协作的设计模式并行调用当工具之间无依赖时可以并行执行以提高效率顺序依赖当前一个工具的输出是后一个工具的输入时必须顺序执行结果聚合多个工具的结果需要整合后一起返回给LLM四、ReAct实战开发4.1 核心循环实现ReAct的骨架ReAct Agent的核心是一个循环结构不断重复思考-行动-观察直到获得满意答案# ReAct核心循环的伪代码defreact_loop(question,tools,max_iterations10):messages[{role:user,content:question}]foriinrange(max_iterations):# Step 1: LLM决定下一步行动responsellm.generate(messagesformat_tools(tools))ifresponse.is_final_answer():returnresponse.answer()# Step 2: 执行工具tool_nameresponse.extract_tool_name()tool_argsresponse.extract_arguments()resultexecute_tool(tool_name,tool_args)# Step 3: 将结果加入上下文messages.append(tool_result_message(result))return达到最大迭代次数循环终止条件的设计考量LLM明确输出Final Answer达到最大迭代次数防止无限循环工具执行出错需要优雅降级4.2 工具执行与结果处理工具执行是将ReAct设计落地的关键环节# 工具执行器的设计模式classToolExecutor:def__init__(self):self.tools{}defregister(self,name,func):self.tools[name]funcdefexecute(self,name,args):ifnamenotinself.tools:return{error:fTool {name} not found}try:returnself.tools[name](**args)exceptExceptionase:return{error:str(e)}工具执行的设计原则错误隔离单个工具的错误不应该导致整个系统崩溃结果标准化所有工具返回统一格式便于LLM处理日志记录记录每次工具调用便于调试和审计五、ReAct的优势与局限5.1 核心优势优势说明为什么重要实时信息获取可调用API获取最新数据解决了LLM知识过时的问题可验证性每步推理可追溯、可检查便于调试和错误定位可纠错性中间步骤错误可被发现修正提高了系统的可靠性强扩展性可接入任意外部工具工具生态丰富可塑性强5.2 潜在局限局限说明应对策略延迟增加工具调用需要时间异步执行、并行调用Token消耗多步循环增加上下文长度结果压缩、选择性调用错误传播早期错误可能影响最终结果添加验证步骤循环风险可能陷入无限循环设置最大迭代次数5.3 最佳实践防止无限循环设置max_iterations限制添加停止关键词检测实现循环检测相同的Thought重复出现优化Token消耗使用结果摘要而非完整返回实现工具调用的缓存合理设计工具的返回值大小六、ReAct vs 其他Agent范式不同的Agent范式代表了不同的推理-行动权衡策略范式核心思想推理方式行动方式适用场景ReAct推理与行动交织显式Thought工具调用需要外部知识的问答CoT纯推理显式思考链无数学推理、逻辑分析Plan-and-Execute先规划后执行分层规划顺序执行复杂多步骤任务Reflexion自我反思经验回顾纠错行动需要自我改进的任务如何选择ReAct当你需要结合LLM的推理能力和外部信息时首选CoT当你只需要LLM展示推理过程不需要外部行动时Plan-and-Execute当任务可以明确分解为多个子步骤时Reflexion当系统需要从错误中学习、持续改进时小结ReAct模式代表了AI Agent领域的重大突破——它首次系统性地将LLM的推理能力与工具行动能力融合在一起。核心要点回顾问题的本质传统LLM是静态生成器无法获取实时信息或执行实际操作ReAct的解法通过思考-行动-观察循环将推理与行动交织与CoT的区别ReAct通过工具调用获取外部信息CoT只能基于内部知识技术实现Function Calling是现代LLM原生支持的工具调用机制工程考量循环控制、错误处理、Token优化是生产级实现的关键ReAct不仅是一种技术实现更是一种人机协作范式的设计哲学——让AI专注于自己擅长的推理工作将精确执行交给专业的工具系统。习题概念理解解释题为什么ReAct模式能够解决传统LLM知识过时的问题请从信息获取的角度进行分析。对比题分析ReAct与Plan-and-Execute两种范式的适用场景差异。如果要构建一个旅行规划助手你更倾向于选择哪种范式为什么设计题为一个智能客服助手设计工具集。需要考虑哪些类型的工具工具之间可能存在什么依赖关系实践应用实现题设计一个ReAct Agent的Prompt模板使其能够处理多跳推理问题如特斯拉CEO的出生地在哪。优化题分析以下场景中可能导致ReAct循环效率低下的原因并提出优化方案用户询问一个可以通过单次工具调用解决的问题工具返回了大量数据需要LLM进行筛选调试题假设你的ReAct Agent陷入了无限循环请设计一个调试流程来定位问题。参考文献Yao S, Zhao J, Yu D, et al. ReAct: Synergizing Reasoning and Acting in Language Models[J]. arXiv preprint arXiv:2210.03629, 2022.Wei J, Wang X, Schuurmans D, et al. Chain-of-thought prompting elicits reasoning in large language models[J]. Advances in Neural Information Processing Systems, 2022.Schick T, Dwivedi-Yu J, Dessì R, et al. Toolformer: Language models can teach themselves to use tools[J]. arXiv preprint arXiv:2302.04761, 2023.OpenAI. Function calling and other API updates[EB/OL]. https://openai.com/blog/function-calling-and-other-api-updates, 2023.Qin E, Chen Y, Liu J, et al. Tool Learning with Foundation Models[J]. arXiv preprint arXiv:2304.08354, 2023.