企业官网建设流程全解析

算起来，ReAct这个词从提出到现在已经不算新了，但直到今天，它依然是我给大模型应用做架构设计时最先考虑的思路。原因很简单：它足够简单，却又把大模型从"会想"推到了"会做"的位置上。这个范式真正解决的，是纯语言模型只能"纸上谈兵"的问题——模型能写出一段滴水不漏的方案，却没法查一眼实时天气，也没法替你发一封邮件。很多刚接触智能体（Agent）概念的朋友，一上来就去看复杂的规划算法、记忆机制，结果被绕得云里雾里。其实把ReAct吃透，就等于拿到了打开智能体大门的钥匙。

这篇文章我会从一个实际动手者的角度，把ReAct范式的核心机制、为什么它能成立、以及我自己在代码层面落地时的完整过程和踩坑记录一次讲清楚。无论你是刚入门大模型应用开发，还是已经在做AI Agent相关的项目，这篇内容都值得收藏备用。

1. 为什么大模型需要一双"手"：ReAct要解决的真实痛点

1.1 纯语言模型的瓶颈：推理不等于行动

想要理解ReAct（Reasoning + Acting），得先看大模型在没有"手"的时候是什么状态。我们平时用模型写文案、做总结、生成代码，本质上是让它在一个封闭的语言空间里做概率预测。这个过程可以很强，但它天然缺两个东西：

第一是实时信息。模型的知识有截止日期，你问它今天某座城市的天气，它只能靠训练数据里的统计规律去猜。第二是外部操作能力。模型无法真的去查询数据库、调用计算器、操作某个软件，它只能告诉你"应该怎么做"，但没法亲自动手。

我用一个很直白的类比：纯语言模型像一个没出过门的理论派顾问，你知道很多道理，但你拿不到现场数据，也没法亲自去调整机器。遇到需要动手的活儿，只能干瞪眼。这种"能说不能做"的局限，在很多真实业务场景里是致命的。比如让模型做数据分析，它可能把统计口径讲得头头是道，但真要让它跑个脚本拉数据，它做不到。

1.2 CoT的启发与局限

思维链（Chain-of-Thought，CoT）的出现解决了一部分问题。它通过让模型在给出答案前先输出中间推理步骤，显著提升复杂任务的准确率。这个思路的启示在于：把"思考过程"显式化，模型的表现会有质的提升。

但CoT有个明显短板：它的推理全程在"脑内"完成，没有外部反馈。模型可以沿着一个错误方向越想越深，最后一本正经地给出错误结论。就好比你让一个顾问闭着眼睛推演市场走势，推演得再细腻，方向错了就是错了。推理链条再长，也没有纠错的锚点。

所以单纯把推理"说出来"不够，还需要让推理能够指导行动，并且让行动的结果反过来修正推理。

1.3 ReAct用一句话解题：想一步，做一步，看结果，再想下一步

ReAct范式的核心逻辑，用一句话就能概括：让模型交替进行推理（Reasoning）和行动（Acting），在推理的指导下调用外部工具，再把工具返回的结果作为新信息融入下一轮推理，如此循环直到任务完成。

这个"推理-行动-观察-再推理"的闭环，就是ReAct的全部秘密。它本质上给大模型装上了一双可以触摸真实世界的"手"，同时保留了一个可以不断纠错的"大脑"。

我在实际开发里对这套逻辑感触很深。遇到需要事实核查、数学计算或多步骤调研的任务，ReAct几乎是碾压纯Prompt的存在。比如让模型算一笔复利，它直接写答案可能错得离谱，但如果让它先写出计算公式，调用计算器工具算出中间结果，再基于结果继续推理，每一步都有据可查，正确率拉高一大截。

2. ReAct的核心机制拆解：Thought、Action、Observation三元组如何循环

2.1 三元组的各自职责

ReAct的每一轮循环里，模型输出的内容被严格切分成三个字段：Thought（推理）、Action（行动）、Observation（观察）。这三个词是整个范式的骨架。

Thought是模型的思考过程，它解释"我为什么要这么做"。比如模型可能会想："用户问的是今天天气，我需要先获取所在城市的实时天气数据，因此我要调用天气查询工具。"

Action则是具体的行动指令，告诉系统该调用哪个工具、传入什么参数。比如"调用get_weather，参数是北京"。

Observation是工具执行后返回的结果，它被作为真实信息反馈给模型。注意，Observation不是模型自己生成的，而是系统从外部工具获取后拼接进上下文的。这个区别极其关键，后面讲问题排查时我会展开说。

从信息论的角度看，Thought负责提出假设，Action负责验证假设，Observation负责带回验证结果。三者缺一不可，少了Thought，模型变成盲目调工具的机器人；少了Observation，模型又回到闭门造车的老路。

2.2 为什么非要搞一个"死板"的格式

你可能觉得，让模型输出带固定字段的文本很别扭。但这份"死板"恰恰是ReAct能工程化落地的前提。原因有三点：

第一，可解析性。程序需要稳定地从模型输出里提取行动指令。如果模型自由发挥，五花八门的格式会让解析代码变成一场灾难。死板的格式让正则表达式或JSON解析变得极其可靠。

第二，可观测性。Thought字段记录了模型每一步的决策依据，这对调试很有价值。模型为什么做了错误选择？回溯Thought字段就能看清它的推理链路。

第三，上下文管理便捷。每一轮循环的"Thought/Action/Observation"都作为一个完整单元追加到对话历史里，模型既能理解之前的操作，又能基于最新的Observation调整下一步，不会出现上下文错乱。

你可以把这套格式想象成手术室里的器械盘——每把钳子、每把剪刀都有固定位置。主刀医生不需要思考"钳子在哪"，只需要伸手就能拿到。格式的确定性，换来的是系统的稳定和高效。

2.3 工具注册表：让模型知道"自己有什么手"

模型必须提前知道有哪些工具可用、每个工具是干什么的、参数怎么填。这就是工具注册表（Tool Registry）的作用。

我在实际项目里通常给每个工具准备四样东西：工具名称、功能描述、参数说明、一个使用示例。比如一个时间查询工具，它的描述可能是"获取指定城市的当前时间，参数为城市中文名"。示例则展示完整的调用方式，帮助模型理解该在什么场景下使用。

工具描述的质量直接影响模型调用的准确度。描述太模糊，模型会在不需要的时候乱调；描述太啰嗦，模型反而抓不住重点。我的经验是，描述控制在两三句话以内，把"何时用、参数填什么"说清楚就够了。

3. 从零手写一个ReAct智能体：代码级的完整实操

3.1 先说整体架构：LLM + 工具集 + 循环调度器

动手写代码之前，先把架构想明白。一个最简的ReAct系统由三个部分组成：大模型接口、工具集、循环调度器。

大模型接口负责接收Prompt并返回模型输出，工具集负责注册和实际执行外部操作，循环调度器则是整个系统的心脏——它负责拼接Prompt、解析模型输出、调用工具、把Observation拼回上下文，然后判断是继续循环还是终止。

我选用Python来演示，因为它的生态最适合快速原型开发。下面这段代码，是一个不依赖任何重型框架的ReAct最小实现。你如果已经装了Python环境，并且有一个可调用的大模型API接口，就能直接跑起来。

3.2 定义工具集：以时间和计算器为例

我先定义两个工具。一个用来获取当前时间，一个用来做数学计算。选这两个工具是有讲究的：时间查询覆盖了"实时信息获取"这个ReAct典型场景，计算器则覆盖了"外部工具辅助推理"这个场景。

import json from datetime import datetime def get_current_time(city: str = "本地") -> str: """获取当前时间。参数city仅用于兼容，实际返回本机时间。""" now = datetime.now() return f"{city}的当前时间是{now.strftime('%Y-%m-%d %H:%M:%S')}" def calculator(expression: str) -> str: """执行四则运算，返回计算结果。""" # 注意: eval有安全隐患, 生产环境请用ast.literal_eval或受限表达式解析器 return str(eval(expression)) TOOL_REGISTRY = { "get_current_time": { "description": "获取当前本地时间，无参数或参数为城市名。", "function": get_current_time, }, "calculator": { "description": "计算数学表达式，传入如 '(3+5)*2' 这样的字符串。", "function": calculator, }, }

这个工具注册表的结构很简单：一个字典，键是工具名，值包含描述信息和可调用函数。实际项目里我会在这个基础上再增加参数schema的校验，但最简版本里，只要描述足够清晰，模型基本能正确传参。

3.3 编写Prompt模板：把规矩写进系统提示词

接下来是核心中的核心——Prompt模板。ReAct能不能跑对，一半的功力都在Prompt里。模板的关键是把Thought、Action、Observation的格式规范、工具的用法、终止条件全讲清楚。

Prompt模板里需要几家内容：

SYSTEM_PROMPT = """你是一个严谨的AI助手，可以通过调用工具来解决用户的问题。 你有以下工具可用（严格按此格式调用）： {tool_descriptions} 请严格遵循以下循环格式思考与行动： Thought: 你当前的思考过程。 Action: 要调用的工具名（只能从上述工具中选择）。 Action Input: 传给工具的参数，必须是合法的JSON字符串。 Observation: 工具返回的结果（由系统提供，你不能自行编造）。 ...(可重复多次 Thought/Action/Observation)... 当你认为信息足够时，输出： Thought: 我现在可以回答用户的问题了。 Final Answer: 给用户的最终回答。 注意事项： 1. 每一步都必须先输出Thought，再决定是否调用Action。 2. 如果不需要调用工具，直接输出Thought和Final Answer即可。 3. 工具的结果必须以Observation形式反馈给你，你需要基于Observation继续推理。 """ tool_descriptions = "\n".join( f"- {name}: {info['description']}" for name, info in TOOL_REGISTRY.items() )

这段Prompt的措辞我踩过好几版的坑。第一版写得太宽松，模型经常不按格式来；第二版又写得太复杂，模型理解起来反而吃力。最终版本的关键是"明确Action只能从工具中选择"这句话，它能大幅降低模型胡编工具名的概率。

3.4 核心循环逻辑：解析、执行、拼回、再推理

循环调度器是整个系统里逻辑最重的部分。它的流程可以拆成四步：

import re def run_react(user_query: str, llm_func, max_iterations: int = 5): messages = [ {"role": "system", "content": SYSTEM_PROMPT.format(tool_descriptions=tool_descriptions)}, {"role": "user", "content": user_query}, ] for step in range(max_iterations): # 第一步: 调用大模型 response = llm_func(messages) messages.append({"role": "assistant", "content": response}) # 第二步: 判断是否终止 if "Final Answer:" in response: return response.split("Final Answer:")[-1].strip() # 第三步: 解析Action和Action Input action_match = re.search(r"Action: (.*?)\n", response) action_input_match = re.search(r"Action Input: (.*?)\n", response) if action_match and action_input_match: action_name = action_match.group(1).strip() action_input_str = action_input_match.group(1).strip() if action_name not in TOOL_REGISTRY: observation = f"错误: 未知工具'{action_name}'，请从工具列表中选择。" else: # 第四步: 执行工具并构造Observation try: if action_input_str: param = json.loads(action_input_str) result = TOOL_REGISTRY[action_name]["function"](**param) else: result = TOOL_REGISTRY[action_name]["function"]() observation = str(result) except Exception as e: observation = f"工具执行出错: {e}" messages.append({"role": "user", "content": f"Observation: {observation}"}) else: # 模型既没给Final Answer，也没给出完整的Action指令，需要引导 messages.append({"role": "user", "content": "请按约定格式输出完整的Action和Action Input，或直接给出Final Answer。"}) return "已达到最大迭代次数，未能得出最终答案。"

这段代码的循环逻辑很清晰。模型每次输出后，系统先检查有没有Final Answer，有就结束；没有就尝试解析Action指令，调用对应工具，把执行结果包装成Observation追加回对话，然后让模型基于Observation继续推理。

3.5 实际运行演示：一个混合任务走一遍全流程

现在用一个任务来实际跑一遍，看看这套循环如何工作。假设用户提问："现在是北京时间几点？然后帮我算一下此刻时间戳除以 7 的余数。"

这里有个相对复杂的推理过程：模型并不知道此刻的时间戳，它必须先调用工具获取时间，再调用计算器做除法。如果没有ReAct循环，模型只能瞎编一个答案。现在看看它如何一步步完成：

第一轮，模型输出：

Thought: 用户需要先知道当前时间，我可以调用get_current_time获取。 Action: get_current_time Action Input: {"city": "北京"}

系统调用工具，返回Observation：北京的当前时间是2025-01-15 14:30:22。

第二轮，模型看到Observation后继续思考：

Thought: 当前时刻是2025年1月15日14:30:22。我需要先把这个时间转换为时间戳，然后计算除以7的余数。我可以调用calculator工具。 Action: calculator Action Input: {"expression": "1736922622 % 7"}

系统执行计算，返回Observation：2。

第三轮，模型拿到计算结果是2，信心满满地输出：

Thought: 我已经得到时间戳除以7的余数为2。 Final Answer: 此刻北京时间的UNIX时间戳除以7的余数是2。

这个过程最大的特点是：每一步都有依据，模型没有凭空捏造任何数据。时间从哪来、余数怎么算的，全部可以通过回溯Thought和Action看到。

3.6 关键参数配置与经验值

跑通基础循环后，有几个参数值得单独调：

max_iterations（最大迭代轮数）我一般设5到8。设太小，复杂任务还没推理完就被截断；设太大，模型可能在某个错误方向上来回打转，浪费大量token还拿不到答案。如果发现模型经常在最后一轮才给出Final Answer，适当调大上限。

temperature（温度）我倾向设低一些，0.2到0.5之间。这个任务需要工具调用能力强，太大的随机性会让模型输出格式不稳定。这里跟写文案不一样——创意任务可以高温，但工具调用的任务，稳定性优先。

另一个容易被忽略的是Observation的截断。如果工具返回的内容非常长（比如查询了一整张数据库表），直接拼接进上下文会消耗大量token，还可能让模型迷失重点。我的做法是对超过一定长度的Observation做摘要或截断，只保留前若干字符和关键统计信息。

4. 高频翻车场景实录：ReAct落地最常见的5个坑

4.1 模型自己伪造Observation

这是ReAct系统最隐蔽、也最可怕的坑。模型在生成过程中，有时会脑补一个工具结果写进来，比如明明没有调用任何工具，却输出了"Observation: 北京的天气是晴天，温度25度"。如果不做约束，模型会把幻觉信息当作真实结果继续推理，整个系统就变成了带幻觉的百科全书。

我处理这个问题的方式是双管齐下。第一，在Prompt里明确写死"Observation: 由系统提供，你不能自行编造"。第二，在代码层面做防护——解析模型输出时直接丢弃其中可能冒充Observation的部分，只从工具执行的真实结果中构造Observation。也就是说，Observation永远以系统消息的身份注入，而不是从模型输出里读取。

4.2 模型绕来绕去就是不调用工具

有时候模型面对一个明显需要工具的场景，却一直在Thought里打转，始终不输出Action。出现这个问题的原因通常是Prompt里没有强调工具的必要性，或者模型不知道哪个工具能解决当前问题。

我的对策是让Prompt里增加一句"如果某个信息你不确定或没有实时数据，请务必调用工具获取，不要自行编造"。另外，工具描述的措辞也很关键——如果你的工具名字是内部代号（比如某个服务的缩写），模型很难猜到它该在什么时候用。用贴近自然语言的名字和描述，会大大提升调用的准确率。

4.3 工具参数解析失败：模型传了个寂寞

我遇到过很多次模型输出Action Input是乱写的JSON，或者参数名跟工具定义对不上。比如计算器工具定义参数名为expression，模型却传了个calc。这种问题的根源，一是Prompt里没有给出参数示例，二是工具说明不够明确。

改进方法是工具描述里带上参数示例。比如我上面的计算器就写了"传入如'(3+5)*2'这样的字符串"，这一句话能让模型少犯一半的错误。代码侧再兜底一层：参数解析失败时返回一个固定的Observation，比如"工具执行出错: 参数无法解析，请检查参数名和格式"，这样模型就知道该怎么修正。

4.4 循环到最大轮数还是收不了尾

这种情况我称之为"鬼打墙"：模型一会儿调工具A，一会儿调工具B，来回折腾，就是不给Final Answer。原因通常是任务本身过于开放，或者模型在某个中间结果上犯了迷糊，需要反复确认。

除了调大max_iterations外，我更推荐在Prompt里加一句："如果你已经获取了足够信息，请立即输出Final Answer，不要重复调用工具。"这句话不复杂，但可以明显减少模型的无效循环。如果还是不行，就检查是不是任务目标定义得不够清晰，导致模型不知道"什么时候算完成"。

4.5 性能与成本失控：每一轮循环都在烧钱

ReAct循环的本质是反复调用大模型，每一轮都产生费用和延迟。一个3轮的循环，成本就是单次调用的三倍还多。在项目初期，我常常在月底看账单时肉疼。

缓解思路有几个：一是尽量精简工具描述和中间Observation的token长度；二是对于简单的、一步能完成的任务，可以在Prompt里约定"不需要工具时直接给出Final Answer"，避免模型为了严谨而强行调工具；三是尽量用小模型完成高频率的简单任务，把流量集中在真正复杂的场景再让大模型上场。这一点在后面进阶部分细讲。

5. 让ReAct更好用的进阶配置与调优心得

5.1 给模型几个"示范动作"：Few-shot示例的魔力

最基础的ReAct实现用的是零样本（Zero-shot）Prompt，模型完全靠系统提示词来理解任务。但如果你在Prompt末尾加上一两个具体的任务示范——展示完整的Thought/Action/Observation链路——模型的表现会立刻上一个台阶。

我试着给系统Prompt加了一个"用户问明天天气"的完整示例，模型后续调起工具的格式规范率几乎到了百分之百。这里的原理其实很简单：大模型擅长模仿模式，给一个高质量示范相当于告诉它"这就是标准答案的样子"，比你说一百句"请按格式输出"都管用。

5.2 让智能体能"记住"关键信息：简单的记忆机制

很多任务是有状态的，比如用户先问"帮我查一下A产品的价格"，接着又问"那B产品呢"，这里的"那"指代的是前面提到的比价语境。如果没有记忆机制，模型每次都是全新开始，会丢掉前面对话里的关键信息。

最简单的做法是把历史对话的摘要保存下来，在每一轮循环开始前拼进Prompt。或者干脆保留完整的历史消息序列，让模型在上下文里自己找线索。对于ReAct系统来说，把每次Observation之后的推理结论压缩成一个短摘要，是性价比很高的记忆方案。

5.3 轻重搭配：多模型协同调度

在ReAct的每个循环里，不是所有环节都需要最强的大模型。比如判断"当前是否需要调用工具"这种粗粒度的动作，用一个轻量模型就够了；真正需要深度推理和生成最终答复的时候，再动用旗舰级模型。

这个思路落地起来并不复杂：循环调度器里加一个路由逻辑，根据当前阶段选择不同模型。我在做某个内部工具时，把频繁的"工具结果理解"环节切到轻量模型，成本直接降了一半以上，而用户体验几乎无损。当然，这里的取舍要结合实际业务判断，如果任务本身就极其复杂，就不要为了省钱牺牲质量。

5.4 安全与权限：哪些工具不能随便让模型碰

ReAct给了模型行动的能力，也意味着给了它造成破坏的能力。我在项目里对工具做了分级：只读类工具（查询天气、搜索资料）可以放心让模型随便调；写操作类工具（发邮件、改数据库）必须加一层人工确认。

这个人工确认可以是一个简单的回调函数，在执行写操作前暂停循环，把待执行的指令发给管理员审批。审批通过才继续执行，不通过则把拒绝结果作为Observation返回给模型。这层保护在真实业务里不可或缺，千万别因为追求自动化而省掉这个步骤。

5.5 从工具调用到反思机制：ReAct的下一个台阶

ReAct跑顺之后，我建议你尝试在这个闭环上加一层"反思"（Reflection）。思路是：在模型给出Final Answer之前，让它先审视自己以前几步的推理和行动，找出可能的错误或遗漏，然后决定是否需要补充行动。

这个"ReAct + Reflection"的组合，能显著提升多步任务的完成质量。原理也不复杂：模型在连续输出的过程中容易沿着惯性走偏，反思步骤相当于强制让它停下来抽离一下，重新审视整个路径的合理性。对过程复杂的任务（比如制定一份可执行的调研计划），这个增量收益尤其明显。

写在最后的个人体会

在把这些代码和方案跑到稳定之后，我对ReAct的理解反而回归简单了：它本质上模拟了人解决问题的本能——遇到不确定的事就动手查一下，查到的结果用来修正下一步判断。大模型的推理能力被工具扩展之后，才真正有机会成为能闭环工作的智能体。我个人在实际操作中的体会是，ReAct最适合的场景是"任务边界清晰、需要反复获取外部信息、且中间过程可被观察"的任务；而如果任务本身就是纯文本创作，或者信息完全依赖模型内部知识，硬套ReAct反而会拖慢速度、增加成本。

最后再分享一个小技巧：如果你在实验中发现模型频繁犯同一个错误，不要急着改代码，先把你给它的完整Prompt从头到尾读一遍。十次里有八次，问题出在工具描述不清或者格式要求含混上。把这部分打磨清楚，比调任何参数都见效快。ReAct的门槛其实不高，迈过这一步之后，后面的大厦能建多高，就看你在实践里怎么组合和打磨了。