ReAct架构解析：大语言模型如何通过思考与行动循环构建智能体

1. 从“指令-响应”到“思考-行动”的范式跃迁

如果你在过去一年里尝试过构建或使用智能体，大概率经历过这样的场景：你给一个基于大语言模型的智能体下达一个指令，比如“帮我查一下今天北京的天气，然后告诉我是否需要带伞”，它可能会直接回复你“我无法直接访问实时天气数据”。这个回答本身没错，但它暴露了一个核心问题——这个智能体只会“说”，不会“做”。它缺乏将复杂目标拆解为可执行步骤，并调用外部工具去完成这些步骤的能力。这正是传统大语言模型应用在迈向“智能体”道路上遇到的第一堵墙。

而ReAct（Reasoning + 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区别于简单工具调用链的关键。它不仅仅是选择工具，更承担着多项核心职能：

  1. 任务分解与规划：面对“查天气并判断是否带伞”的任务，模型需要在第一个Thought中就想好：“这是一个两阶段任务：1. 获取天气数据；2. 分析降水概率并给出建议。” 这为后续的行动序列提供了蓝图。
  2. 信息整合与状态管理：模型需要记住历史上的所有Observation。例如，在完成天气查询后，下一个Thought可能是：“Observation显示降水概率为10%。这是一个很低的概率，通常不需要带伞。但用户可能对‘需要带伞’有个人标准，我可以直接给出客观建议，也可以反问用户的标准。” 这里，模型整合了天气数据，并生成了新的推理。
  3. 错误处理与重试逻辑：当工具调用失败时（例如，API返回错误或超时），Thought环节需要能识别错误，并规划替代方案。例如：“Act调用‘search_weather’失败，返回‘网络错误’。我可以等待1秒后重试一次，或者如果用户允许，我可以提供一个基于历史天气的估算。”
  4. 终止条件判断：模型必须能判断任务何时完成。最终的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": "数学表达式，如 (10+5)*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(f"Thought: {thought}") messages.append(f"Act: {act_str}") messages.append(f"Observation: {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. 规划阶段：提示模型先输出一个概要计划。
    • 规划：1. 确定目的地候选（考虑时间、预算）。2. 查询交通方式与费用。3. 查询目的地住宿与餐饮均价。4. 制定每日行程草案。5. 核算总预算并调整。
  2. 执行阶段：然后，模型带着这个计划进入标准的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是一个强大的框架，但它不是银弹。理解其原理，承认其局限，并在工程实践中用各种技巧去弥补和增强，才是用好它的正确方式。