1. 从“指令-响应”到“思考-行动”的范式跃迁如果你在过去一年里尝试过构建或使用智能体大概率经历过这样的场景你给一个基于大语言模型的智能体下达一个指令比如“帮我查一下今天北京的天气然后告诉我是否需要带伞”它可能会直接回复你“我无法直接访问实时天气数据”。这个回答本身没错但它暴露了一个核心问题——这个智能体只会“说”不会“做”。它缺乏将复杂目标拆解为可执行步骤并调用外部工具去完成这些步骤的能力。这正是传统大语言模型应用在迈向“智能体”道路上遇到的第一堵墙。而ReActReasoning Acting架构的出现就是为了推倒这堵墙。它不是一个具体的产品而是一种思想框架一种让大语言模型从“静态的知识应答机”转变为“动态的任务执行者”的方法论。我第一次在论文中读到ReAct时有种豁然开朗的感觉。它精准地捕捉到了智能体最核心的两个动作思考Reasoning和行动Acting。思考是模型对当前状况、历史信息和最终目标进行内部推理规划下一步该做什么行动则是根据思考的结果去调用一个具体的工具比如搜索引擎、计算器、API接口或执行一个具体的操作比如在数据库中写入一条记录。为什么这种“先想后做”的循环如此重要因为现实世界的任务极少能通过一次性的问答完成。它们往往是多步骤、有条件分支、且需要根据中间结果动态调整的。ReAct通过将任务分解为一系列“思考-行动-观察”的循环为智能体赋予了处理这类复杂任务的基本能力骨架。这不仅仅是给模型加了个“工具调用”的按钮而是从根本上改变了智能体与环境和任务交互的范式。接下来我们就深入这个骨架的内部看看它是如何运作以及在实际构建中我们又会遇到哪些意料之中和意料之外的挑战。2. ReAct的核心循环不只是“调用工具”那么简单很多人初次接触ReAct会简单地把它理解为“让大模型学会使用工具”。这个理解没错但过于表面容易让人忽略其设计精妙之处和真正的工程难点。ReAct的核心是一个严格的、结构化的交互循环这个循环的每一步都充满了设计考量。2.1 循环的标准化结构Thought, Act, Observation一个标准的ReAct循环步骤其输出必须遵循一个严格的格式。这通常通过精心设计的提示词Prompt来约束模型输出。一个典型的循环看起来是这样的Thought思考: 这是模型内部推理的“外化”。模型需要分析当前的任务目标、已有的历史信息包括之前的思考和观察结果然后决定下一步应该做什么。关键点在于思考必须导向一个具体的、可执行的行动。例如“用户想了解北京的天气。我目前没有任何天气数据。我需要调用一个天气查询API来获取信息。我应该使用‘search_weather’这个工具参数是城市‘北京’。”Act行动: 基于上述思考模型生成一个格式化的动作指令。这个指令不是自然语言而是一个结构化的调用通常包括工具名称和输入参数。例如Act: search_weather(“北京”)。这个格式化的输出会被系统解析并触发对应的工具函数执行。Observation观察: 工具执行后返回的结果。这个结果被作为“观察”反馈给模型成为下一轮思考的新输入。例如Observation: 北京2023年10月27日晴气温5-18°C降水概率10%东北风2级。这个Thought - Act - Observation的三段式结构构成了智能体与环境交互的一个原子单元。任务被分解为多个这样的单元串联执行直到模型在“Thought”中认为任务已经完成并最终输出给用户答案。2.2 思考的价值超越简单的工具选择“Thought”环节是ReAct区别于简单工具调用链的关键。它不仅仅是选择工具更承担着多项核心职能任务分解与规划面对“查天气并判断是否带伞”的任务模型需要在第一个Thought中就想好“这是一个两阶段任务1. 获取天气数据2. 分析降水概率并给出建议。” 这为后续的行动序列提供了蓝图。信息整合与状态管理模型需要记住历史上的所有Observation。例如在完成天气查询后下一个Thought可能是“Observation显示降水概率为10%。这是一个很低的概率通常不需要带伞。但用户可能对‘需要带伞’有个人标准我可以直接给出客观建议也可以反问用户的标准。” 这里模型整合了天气数据并生成了新的推理。错误处理与重试逻辑当工具调用失败时例如API返回错误或超时Thought环节需要能识别错误并规划替代方案。例如“Act调用‘search_weather’失败返回‘网络错误’。我可以等待1秒后重试一次或者如果用户允许我可以提供一个基于历史天气的估算。”终止条件判断模型必须能判断任务何时完成。最终的Thought可能是“我已经获取了天气信息并基于降水概率给出了不带伞的建议。所有用户问题都已解答任务完成。” 随后模型会输出最终答案而不是发起另一个Act。在实际编码中我们通常用系统提示词System Prompt来“教”模型如何进行这种格式化的思考。一段经典的ReAct提示词开头可能是这样的你是一个善于思考并采取行动解决问题的助手。你必须遵循以下格式 Thought: 你在这里分析当前情况决定下一步做什么 Act: 你在这里发出行动指令格式必须是 工具名(参数) Observation: 行动的结果会在这里提供给你 任务开始 用户问题{用户输入}通过反复在上下文中提供Thought-Act-Observation的示例模型会逐渐学会这种推理模式。然而让模型稳定地输出严格格式化的内容是工程实践中的第一个挑战。3. 工程落地将理论循环转化为可靠系统把ReAct论文里的漂亮流程图变成线上可稳定运行的服务中间隔着无数个需要填平的坑。这里我结合自己搭建智能体平台的经验分享几个最关键的工程化考量点。3.1 工具Tool的抽象与注册工具是Act环节的最终执行者。一个健壮的工具系统需要良好的抽象。通常我们会定义一个统一的工具接口class Tool: name: str # 工具唯一标识如 “search_weather” description: str # 工具功能的自然语言描述用于帮助模型理解何时使用它 parameters_schema: dict # 参数JSON Schema定义输入格式 function: callable # 实际执行的函数 def run(self, **kwargs): # 执行逻辑返回字符串形式的Observation pass关键设计点描述Description至关重要模型的Thought环节依赖工具的description来判断“我该不该用这个工具”。描述必须清晰、无歧义并包含典型用例。例如“search_weather”的描述应该是“查询指定城市当前或未来一段时间的天气情况包括温度、天气状况、降水概率、风速等。输入参数city城市名字符串”而不是简单的“查天气”。参数标准化使用JSON Schema定义参数可以在调用前进行校验避免模型因参数格式错误导致工具执行失败。同时Schema本身也可以作为提示词的一部分帮助模型生成正确的参数。错误封装工具执行可能因各种原因失败网络、权限、资源不存在。run函数必须妥善处理异常并返回一个对模型友好的错误信息作为Observation例如“Observation: 调用天气API失败原因网络连接超时。请检查网络或稍后重试。” 这比直接抛出一个Python异常堆栈更有助于模型进行后续推理。工具注册中心系统需要维护一个全局的工具注册表。在初始化智能体时将可用的工具列表包括其name和description注入到系统提示词中让模型知道“你手头有哪些牌可以打”。3.2 提示词工程引导与约束的平衡让大语言模型乖乖地、稳定地输出Thought:和Act:这样的固定格式是提示词工程的核心任务。这不仅仅是写一段指令那么简单。基础模板你的系统提示词需要包含角色定义、格式指令、可用工具列表和少量示例Few-shot Examples。你是一个任务解决助手。请通过思考Thought和行动Act来解决问题。 你必须严格按照以下格式响应 Thought: 分析当前任务和已有信息决定下一步 Act: 调用工具格式为 工具名(参数)参数需为JSON格式 ...此模式循环... 当任务解决或无法继续时在Thought中说明并给出最终答案。 你可以使用的工具有 - search_weather: 查询城市天气。参数{city: 城市名} - calculator: 执行数学计算。参数{expression: 数学表达式如 (105)*2} - search_web: 使用搜索引擎查询信息。参数{query: 搜索关键词} 示例1 用户今天上海温度多少 Thought: 用户想知道上海的温度我需要查询天气信息。 Act: search_weather({city: 上海}) Observation: 上海晴气温15-22°C。 Thought: 我已获得上海的气温信息可以回答用户。 最终答案上海今天气温在15到22摄氏度之间天气晴朗。 可以再提供1-2个更复杂的多步示例高级技巧与坑点格式漂移Format Drift这是最常见的问题。模型在几轮循环后可能会开始输出“我想我应该...”而不是“Thought:”。或者在Act环节输出自然语言。对策除了在开头强调还可以在每一轮将模型的上一个输出和新的Observation喂给它时都重新附上格式提醒。或者在解析模型输出时采用更鲁棒的正则表达式或解析器容忍一定程度的格式偏差。上下文长度爆炸ReAct的每一步都会增加对话历史Thought, Act, Observation。一个复杂任务可能进行几十轮循环迅速耗尽模型的上下文窗口。对策实现“摘要”或“压缩”机制。定期例如每5轮对之前的交互历史进行总结用一个精简的“先前状态摘要”替换掉冗长的原始历史再继续循环。工具选择困惑当两个工具描述相似时模型可能选错。对策优化工具描述使其职责单一、区分度大。或者在Thought环节要求模型给出选择该工具的理由这有时能“逼”模型进行更审慎的推理。3.3 执行引擎状态、循环与超时控制有了工具和提示词还需要一个驱动整个循环的“发动机”即执行引擎Orchestrator。它的伪代码逻辑如下class ReActAgent: def run(self, user_query: str, tools: List[Tool], max_turns: int 20): # 初始化对话历史包含系统提示词和用户问题 messages [system_prompt, user_msg] for turn in range(max_turns): # 1. 调用LLM获取响应 llm_response call_llm(messages) # 2. 解析响应提取 Thought 和 Act thought, act_str parse_llm_response(llm_response) # 如果解析出最终答案则返回 if is_final_answer(thought, act_str): return extract_answer(thought) # 3. 执行 Act tool_name, params parse_act(act_str) tool find_tool(tool_name, tools) observation tool.run(**params) # 4. 更新对话历史添加本次循环的 Thought, Act, Observation messages.append(fThought: {thought}) messages.append(fAct: {act_str}) messages.append(fObservation: {observation}) # 循环超过最大轮数强制终止 return 任务处理超时可能过于复杂。关键控制逻辑最大轮次max_turns必须设置防止智能体陷入死循环比如不停地搜索同一个问题。解析器Parser的鲁棒性parse_llm_response函数需要能处理模型输出的各种小偏差比如多余的空格、换行、偶尔的标点缺失。最终答案判断is_final_answer逻辑需要仔细设计。通常如果模型在Thought中表达了任务已完成如“现在我有足够信息回答用户”并且没有输出有效的Act指令就可以判定为最终答案。错误处理工具执行失败时Observation是错误信息。引擎需要允许模型在下一轮Thought中处理这个错误而不是直接终止任务。4. 超越基础循环ReAct的进阶模式与挑战基本的ReAct循环能解决很多问题但当任务变得极其复杂或模糊时我们会发现它的局限性。这时就需要引入更高级的模式。4.1 规划Planning的引入先谋全局再动局部对于需要多个步骤的长任务让模型走一步看一步贪婪式搜索效率低下且容易迷失。一个改进方案是引入规划阶段。即在进入Thought-Act循环之前先让模型制定一个高层计划。用户我想策划一个从北京出发预算5000元的三日周末旅行。传统ReAct可能直接思考“用户要旅行策划我需要先搜索北京周边目的地”然后开始行动容易陷入细节丢失全局预算和天数约束。加入规划后的流程规划阶段提示模型先输出一个概要计划。规划1. 确定目的地候选考虑时间、预算。2. 查询交通方式与费用。3. 查询目的地住宿与餐饮均价。4. 制定每日行程草案。5. 核算总预算并调整。执行阶段然后模型带着这个计划进入标准的ReAct循环。每一轮Thought都可以参考当前步骤在总计划中的位置使得行动更有目的性。这相当于让智能体具备了“顶层设计”的能力。在实践中可以通过在系统提示词中增加“请先制定一个分步计划”的指令来实现。4.2 反思Reflection机制从错误中学习即使有规划智能体也可能犯错比如工具返回了不相关或错误的信息。反思机制让智能体能够评估自身行动和结果的有效性并在必要时调整策略。在每一轮或每几轮循环后可以插入一个“反思”步骤提示词“请回顾你刚刚获取的Observation它是否直接、完整地回答了当前Thought中的问题如果否问题出在哪里是工具选错参数不对还是需要换一种问法”模型输出反思“Observation返回的是上海的总体介绍但我需要的是具体的三日游攻略。我使用的‘search_web’工具参数‘query’可能太宽泛了应该更具体比如‘上海三日游攻略 预算5000’。”基于反思调整这个反思结果可以作为下一轮Thought的重要输入指导模型采取更正后的行动例如用更精确的查询重新搜索。反思机制显著提升了智能体的纠错和自适应能力使其更像一个“吃一堑长一智”的智能体而非机械循环的程序。4.3 面临的固有挑战即便采用了进阶模式ReAct架构仍面临一些根深蒂固的挑战推理成本高昂每一步都需要调用一次大模型生成Thought对于复杂任务token消耗巨大响应延迟高成本也成倍增加。对模型推理能力依赖极强整个架构的基石是模型的“思考”质量。如果模型逻辑混乱、规划能力差整个智能体就会表现糟糕。这本质上是将所有复杂性都压在了提示词工程和模型本身的能力上。长程依赖与状态管理虽然Thought环节理论上能整合历史但模型在实际中很容易遗忘或混淆很早之前的关键信息尤其是在上下文窗口受限时。工具学习的灵活性每当新增一个工具都需要更新提示词中的工具列表和描述并可能需要提供新的示例系统扩展不够灵活。5. 实战心得构建生产级ReAct智能体的注意事项在真正将ReAct智能体部署到生产环境服务真实用户后我积累了一些在论文和教程里很少提及的经验。第一日志与可观测性Observability是你的生命线。你必须记录下每一轮完整的Thought-Act-Observation三元组。当用户反馈“这个智能体答非所问”时你需要能完整回溯它的“心路历程”看看它是在哪一步思考跑偏了还是工具返回了垃圾信息。没有详细的日志调试一个多步推理的智能体如同盲人摸象。第二给工具调用加上“护栏”Guardrails。不是所有工具都能被无条件调用。例如一个“发送邮件”的工具必须在Thought中明确识别出用户有发送邮件的意图并且参数中包含了收件人和内容后才能执行。你需要实现一套轻量的规则引擎或预校验逻辑在parse_act之后、tool.run之前对高危操作进行二次确认或直接拦截。安全永远是第一位的。第三准备好处理模型的“固执”与“发散”。有时模型会卡在一个无效的思路上循环尝试比如反复用不同关键词搜索同一个无解的问题。除了设置max_turns更聪明的做法是引入“异常检测”。例如如果连续三轮的Observation都包含“未找到结果”可以主动介入在下一轮提示词开头加上一句“注意之前多次搜索未果请考虑调整搜索策略或确认问题本身是否有误。”引导模型跳出死循环。第四用户感知与体验设计。如果你把智能体内部漫长的“思考-行动”循环原封不动地展示给用户用户会看到大量“Thought: ... Act: ...”的中间过程体验很差。对于前端展示你需要设计一个“静默执行”模式只向用户展示最终的答案和关键的中期结果如“正在查询天气...”“正在计算预算...”。智能体的“内心戏”只留在后台日志里。最后也是最重要的从简单任务开始定义清晰的边界。不要试图用一个ReAct智能体解决所有问题。首先为它定义明确、有限的任务领域比如“旅行信息查询与规划”或“内部知识库问答”并提供领域内精准、可靠的工具集。一个在特定领域内表现卓越的智能体远胜于一个在所有领域都表现平庸的“通才”。ReAct是一个强大的框架但它不是银弹。理解其原理承认其局限并在工程实践中用各种技巧去弥补和增强才是用好它的正确方式。 ReAct架构解析：大语言模型如何通过思考与行动循环构建智能体
1. 从“指令-响应”到“思考-行动”的范式跃迁如果你在过去一年里尝试过构建或使用智能体大概率经历过这样的场景你给一个基于大语言模型的智能体下达一个指令比如“帮我查一下今天北京的天气然后告诉我是否需要带伞”它可能会直接回复你“我无法直接访问实时天气数据”。这个回答本身没错但它暴露了一个核心问题——这个智能体只会“说”不会“做”。它缺乏将复杂目标拆解为可执行步骤并调用外部工具去完成这些步骤的能力。这正是传统大语言模型应用在迈向“智能体”道路上遇到的第一堵墙。而ReActReasoning Acting架构的出现就是为了推倒这堵墙。它不是一个具体的产品而是一种思想框架一种让大语言模型从“静态的知识应答机”转变为“动态的任务执行者”的方法论。我第一次在论文中读到ReAct时有种豁然开朗的感觉。它精准地捕捉到了智能体最核心的两个动作思考Reasoning和行动Acting。思考是模型对当前状况、历史信息和最终目标进行内部推理规划下一步该做什么行动则是根据思考的结果去调用一个具体的工具比如搜索引擎、计算器、API接口或执行一个具体的操作比如在数据库中写入一条记录。为什么这种“先想后做”的循环如此重要因为现实世界的任务极少能通过一次性的问答完成。它们往往是多步骤、有条件分支、且需要根据中间结果动态调整的。ReAct通过将任务分解为一系列“思考-行动-观察”的循环为智能体赋予了处理这类复杂任务的基本能力骨架。这不仅仅是给模型加了个“工具调用”的按钮而是从根本上改变了智能体与环境和任务交互的范式。接下来我们就深入这个骨架的内部看看它是如何运作以及在实际构建中我们又会遇到哪些意料之中和意料之外的挑战。2. ReAct的核心循环不只是“调用工具”那么简单很多人初次接触ReAct会简单地把它理解为“让大模型学会使用工具”。这个理解没错但过于表面容易让人忽略其设计精妙之处和真正的工程难点。ReAct的核心是一个严格的、结构化的交互循环这个循环的每一步都充满了设计考量。2.1 循环的标准化结构Thought, Act, Observation一个标准的ReAct循环步骤其输出必须遵循一个严格的格式。这通常通过精心设计的提示词Prompt来约束模型输出。一个典型的循环看起来是这样的Thought思考: 这是模型内部推理的“外化”。模型需要分析当前的任务目标、已有的历史信息包括之前的思考和观察结果然后决定下一步应该做什么。关键点在于思考必须导向一个具体的、可执行的行动。例如“用户想了解北京的天气。我目前没有任何天气数据。我需要调用一个天气查询API来获取信息。我应该使用‘search_weather’这个工具参数是城市‘北京’。”Act行动: 基于上述思考模型生成一个格式化的动作指令。这个指令不是自然语言而是一个结构化的调用通常包括工具名称和输入参数。例如Act: search_weather(“北京”)。这个格式化的输出会被系统解析并触发对应的工具函数执行。Observation观察: 工具执行后返回的结果。这个结果被作为“观察”反馈给模型成为下一轮思考的新输入。例如Observation: 北京2023年10月27日晴气温5-18°C降水概率10%东北风2级。这个Thought - Act - Observation的三段式结构构成了智能体与环境交互的一个原子单元。任务被分解为多个这样的单元串联执行直到模型在“Thought”中认为任务已经完成并最终输出给用户答案。2.2 思考的价值超越简单的工具选择“Thought”环节是ReAct区别于简单工具调用链的关键。它不仅仅是选择工具更承担着多项核心职能任务分解与规划面对“查天气并判断是否带伞”的任务模型需要在第一个Thought中就想好“这是一个两阶段任务1. 获取天气数据2. 分析降水概率并给出建议。” 这为后续的行动序列提供了蓝图。信息整合与状态管理模型需要记住历史上的所有Observation。例如在完成天气查询后下一个Thought可能是“Observation显示降水概率为10%。这是一个很低的概率通常不需要带伞。但用户可能对‘需要带伞’有个人标准我可以直接给出客观建议也可以反问用户的标准。” 这里模型整合了天气数据并生成了新的推理。错误处理与重试逻辑当工具调用失败时例如API返回错误或超时Thought环节需要能识别错误并规划替代方案。例如“Act调用‘search_weather’失败返回‘网络错误’。我可以等待1秒后重试一次或者如果用户允许我可以提供一个基于历史天气的估算。”终止条件判断模型必须能判断任务何时完成。最终的Thought可能是“我已经获取了天气信息并基于降水概率给出了不带伞的建议。所有用户问题都已解答任务完成。” 随后模型会输出最终答案而不是发起另一个Act。在实际编码中我们通常用系统提示词System Prompt来“教”模型如何进行这种格式化的思考。一段经典的ReAct提示词开头可能是这样的你是一个善于思考并采取行动解决问题的助手。你必须遵循以下格式 Thought: 你在这里分析当前情况决定下一步做什么 Act: 你在这里发出行动指令格式必须是 工具名(参数) Observation: 行动的结果会在这里提供给你 任务开始 用户问题{用户输入}通过反复在上下文中提供Thought-Act-Observation的示例模型会逐渐学会这种推理模式。然而让模型稳定地输出严格格式化的内容是工程实践中的第一个挑战。3. 工程落地将理论循环转化为可靠系统把ReAct论文里的漂亮流程图变成线上可稳定运行的服务中间隔着无数个需要填平的坑。这里我结合自己搭建智能体平台的经验分享几个最关键的工程化考量点。3.1 工具Tool的抽象与注册工具是Act环节的最终执行者。一个健壮的工具系统需要良好的抽象。通常我们会定义一个统一的工具接口class Tool: name: str # 工具唯一标识如 “search_weather” description: str # 工具功能的自然语言描述用于帮助模型理解何时使用它 parameters_schema: dict # 参数JSON Schema定义输入格式 function: callable # 实际执行的函数 def run(self, **kwargs): # 执行逻辑返回字符串形式的Observation pass关键设计点描述Description至关重要模型的Thought环节依赖工具的description来判断“我该不该用这个工具”。描述必须清晰、无歧义并包含典型用例。例如“search_weather”的描述应该是“查询指定城市当前或未来一段时间的天气情况包括温度、天气状况、降水概率、风速等。输入参数city城市名字符串”而不是简单的“查天气”。参数标准化使用JSON Schema定义参数可以在调用前进行校验避免模型因参数格式错误导致工具执行失败。同时Schema本身也可以作为提示词的一部分帮助模型生成正确的参数。错误封装工具执行可能因各种原因失败网络、权限、资源不存在。run函数必须妥善处理异常并返回一个对模型友好的错误信息作为Observation例如“Observation: 调用天气API失败原因网络连接超时。请检查网络或稍后重试。” 这比直接抛出一个Python异常堆栈更有助于模型进行后续推理。工具注册中心系统需要维护一个全局的工具注册表。在初始化智能体时将可用的工具列表包括其name和description注入到系统提示词中让模型知道“你手头有哪些牌可以打”。3.2 提示词工程引导与约束的平衡让大语言模型乖乖地、稳定地输出Thought:和Act:这样的固定格式是提示词工程的核心任务。这不仅仅是写一段指令那么简单。基础模板你的系统提示词需要包含角色定义、格式指令、可用工具列表和少量示例Few-shot Examples。你是一个任务解决助手。请通过思考Thought和行动Act来解决问题。 你必须严格按照以下格式响应 Thought: 分析当前任务和已有信息决定下一步 Act: 调用工具格式为 工具名(参数)参数需为JSON格式 ...此模式循环... 当任务解决或无法继续时在Thought中说明并给出最终答案。 你可以使用的工具有 - search_weather: 查询城市天气。参数{city: 城市名} - calculator: 执行数学计算。参数{expression: 数学表达式如 (105)*2} - search_web: 使用搜索引擎查询信息。参数{query: 搜索关键词} 示例1 用户今天上海温度多少 Thought: 用户想知道上海的温度我需要查询天气信息。 Act: search_weather({city: 上海}) Observation: 上海晴气温15-22°C。 Thought: 我已获得上海的气温信息可以回答用户。 最终答案上海今天气温在15到22摄氏度之间天气晴朗。 可以再提供1-2个更复杂的多步示例高级技巧与坑点格式漂移Format Drift这是最常见的问题。模型在几轮循环后可能会开始输出“我想我应该...”而不是“Thought:”。或者在Act环节输出自然语言。对策除了在开头强调还可以在每一轮将模型的上一个输出和新的Observation喂给它时都重新附上格式提醒。或者在解析模型输出时采用更鲁棒的正则表达式或解析器容忍一定程度的格式偏差。上下文长度爆炸ReAct的每一步都会增加对话历史Thought, Act, Observation。一个复杂任务可能进行几十轮循环迅速耗尽模型的上下文窗口。对策实现“摘要”或“压缩”机制。定期例如每5轮对之前的交互历史进行总结用一个精简的“先前状态摘要”替换掉冗长的原始历史再继续循环。工具选择困惑当两个工具描述相似时模型可能选错。对策优化工具描述使其职责单一、区分度大。或者在Thought环节要求模型给出选择该工具的理由这有时能“逼”模型进行更审慎的推理。3.3 执行引擎状态、循环与超时控制有了工具和提示词还需要一个驱动整个循环的“发动机”即执行引擎Orchestrator。它的伪代码逻辑如下class ReActAgent: def run(self, user_query: str, tools: List[Tool], max_turns: int 20): # 初始化对话历史包含系统提示词和用户问题 messages [system_prompt, user_msg] for turn in range(max_turns): # 1. 调用LLM获取响应 llm_response call_llm(messages) # 2. 解析响应提取 Thought 和 Act thought, act_str parse_llm_response(llm_response) # 如果解析出最终答案则返回 if is_final_answer(thought, act_str): return extract_answer(thought) # 3. 执行 Act tool_name, params parse_act(act_str) tool find_tool(tool_name, tools) observation tool.run(**params) # 4. 更新对话历史添加本次循环的 Thought, Act, Observation messages.append(fThought: {thought}) messages.append(fAct: {act_str}) messages.append(fObservation: {observation}) # 循环超过最大轮数强制终止 return 任务处理超时可能过于复杂。关键控制逻辑最大轮次max_turns必须设置防止智能体陷入死循环比如不停地搜索同一个问题。解析器Parser的鲁棒性parse_llm_response函数需要能处理模型输出的各种小偏差比如多余的空格、换行、偶尔的标点缺失。最终答案判断is_final_answer逻辑需要仔细设计。通常如果模型在Thought中表达了任务已完成如“现在我有足够信息回答用户”并且没有输出有效的Act指令就可以判定为最终答案。错误处理工具执行失败时Observation是错误信息。引擎需要允许模型在下一轮Thought中处理这个错误而不是直接终止任务。4. 超越基础循环ReAct的进阶模式与挑战基本的ReAct循环能解决很多问题但当任务变得极其复杂或模糊时我们会发现它的局限性。这时就需要引入更高级的模式。4.1 规划Planning的引入先谋全局再动局部对于需要多个步骤的长任务让模型走一步看一步贪婪式搜索效率低下且容易迷失。一个改进方案是引入规划阶段。即在进入Thought-Act循环之前先让模型制定一个高层计划。用户我想策划一个从北京出发预算5000元的三日周末旅行。传统ReAct可能直接思考“用户要旅行策划我需要先搜索北京周边目的地”然后开始行动容易陷入细节丢失全局预算和天数约束。加入规划后的流程规划阶段提示模型先输出一个概要计划。规划1. 确定目的地候选考虑时间、预算。2. 查询交通方式与费用。3. 查询目的地住宿与餐饮均价。4. 制定每日行程草案。5. 核算总预算并调整。执行阶段然后模型带着这个计划进入标准的ReAct循环。每一轮Thought都可以参考当前步骤在总计划中的位置使得行动更有目的性。这相当于让智能体具备了“顶层设计”的能力。在实践中可以通过在系统提示词中增加“请先制定一个分步计划”的指令来实现。4.2 反思Reflection机制从错误中学习即使有规划智能体也可能犯错比如工具返回了不相关或错误的信息。反思机制让智能体能够评估自身行动和结果的有效性并在必要时调整策略。在每一轮或每几轮循环后可以插入一个“反思”步骤提示词“请回顾你刚刚获取的Observation它是否直接、完整地回答了当前Thought中的问题如果否问题出在哪里是工具选错参数不对还是需要换一种问法”模型输出反思“Observation返回的是上海的总体介绍但我需要的是具体的三日游攻略。我使用的‘search_web’工具参数‘query’可能太宽泛了应该更具体比如‘上海三日游攻略 预算5000’。”基于反思调整这个反思结果可以作为下一轮Thought的重要输入指导模型采取更正后的行动例如用更精确的查询重新搜索。反思机制显著提升了智能体的纠错和自适应能力使其更像一个“吃一堑长一智”的智能体而非机械循环的程序。4.3 面临的固有挑战即便采用了进阶模式ReAct架构仍面临一些根深蒂固的挑战推理成本高昂每一步都需要调用一次大模型生成Thought对于复杂任务token消耗巨大响应延迟高成本也成倍增加。对模型推理能力依赖极强整个架构的基石是模型的“思考”质量。如果模型逻辑混乱、规划能力差整个智能体就会表现糟糕。这本质上是将所有复杂性都压在了提示词工程和模型本身的能力上。长程依赖与状态管理虽然Thought环节理论上能整合历史但模型在实际中很容易遗忘或混淆很早之前的关键信息尤其是在上下文窗口受限时。工具学习的灵活性每当新增一个工具都需要更新提示词中的工具列表和描述并可能需要提供新的示例系统扩展不够灵活。5. 实战心得构建生产级ReAct智能体的注意事项在真正将ReAct智能体部署到生产环境服务真实用户后我积累了一些在论文和教程里很少提及的经验。第一日志与可观测性Observability是你的生命线。你必须记录下每一轮完整的Thought-Act-Observation三元组。当用户反馈“这个智能体答非所问”时你需要能完整回溯它的“心路历程”看看它是在哪一步思考跑偏了还是工具返回了垃圾信息。没有详细的日志调试一个多步推理的智能体如同盲人摸象。第二给工具调用加上“护栏”Guardrails。不是所有工具都能被无条件调用。例如一个“发送邮件”的工具必须在Thought中明确识别出用户有发送邮件的意图并且参数中包含了收件人和内容后才能执行。你需要实现一套轻量的规则引擎或预校验逻辑在parse_act之后、tool.run之前对高危操作进行二次确认或直接拦截。安全永远是第一位的。第三准备好处理模型的“固执”与“发散”。有时模型会卡在一个无效的思路上循环尝试比如反复用不同关键词搜索同一个无解的问题。除了设置max_turns更聪明的做法是引入“异常检测”。例如如果连续三轮的Observation都包含“未找到结果”可以主动介入在下一轮提示词开头加上一句“注意之前多次搜索未果请考虑调整搜索策略或确认问题本身是否有误。”引导模型跳出死循环。第四用户感知与体验设计。如果你把智能体内部漫长的“思考-行动”循环原封不动地展示给用户用户会看到大量“Thought: ... Act: ...”的中间过程体验很差。对于前端展示你需要设计一个“静默执行”模式只向用户展示最终的答案和关键的中期结果如“正在查询天气...”“正在计算预算...”。智能体的“内心戏”只留在后台日志里。最后也是最重要的从简单任务开始定义清晰的边界。不要试图用一个ReAct智能体解决所有问题。首先为它定义明确、有限的任务领域比如“旅行信息查询与规划”或“内部知识库问答”并提供领域内精准、可靠的工具集。一个在特定领域内表现卓越的智能体远胜于一个在所有领域都表现平庸的“通才”。ReAct是一个强大的框架但它不是银弹。理解其原理承认其局限并在工程实践中用各种技巧去弥补和增强才是用好它的正确方式。