摘要大语言模型LLM正在从单纯的“聊天与内容生成”演变为具备“环境感知、自主规划、工具调用与闭环执行”能力的智能体AI Agent。而决定一个 Agent 智商与执行力的核心就是其底层的推理模式Reasoning Paradigms。许多开发者在接触 Agent 时常对各种名词CoT、ToT、GoT、Plan-and-Solve、ReAct、Reflexion感到眼花缭乱也容易把 ReAct 简单等同于 LangChain 的某一行调用代码。本文将系统拆解主流 Agent 推理模式全景演进Direct ➔ CoT ➔ ToT/GoT ➔ Plan-and-Solve ➔ ReAct ➔ ReflexionReAct 核心机理剖析为什么“单纯思考”与“单纯行动”都会失败Reasoning 与 Acting 是如何实现协同增效的ReAct 的底层运行状态机Prompt 模板、停用词Stop Words、正则抽取、工具调度与上下文滚动的标准闭环工业级纯 Python 零依赖实战不依赖任何黑盒框架从零手写一个具备计算器、搜索引擎与天气查询能力的生产级 ReAct Agent 引擎常见失败模式与高阶演进死循环规避、幻觉防御、结合 Function Calling 与强化学习Agentic-RL的演进路径。一、 大模型 Agent 推理模式全景演进大语言模型本质是一个“基于概率预测下一个 Token”的概率引擎。如果我们直接向模型抛出复杂的多步骤问题Direct Prompting模型往往只能依赖浅层的隐式联想给出草率的答案容易产生严重的幻觉和逻辑混乱。为了让模型具备解决复杂多步问题的能力学术界与工业界演进出了一系列推理架构范式。┌───────────────────────────────────────────────────────────────────────────┐ │ 大模型推理模式Reasoning Paradigms演进谱系 │ └───────────────────────────────────────────────────────────────────────────┘ │ 1. 朴素模式 (Direct Prompting) Zero-Shot / Few-Shot无显式思考直接猜答案 │ 2. 线性链式 (Chain of Thought) CoT / Zero-Shot CoT单链线性推演无外部交互 │ 3. 分解执行 (Least-to-Most) Decompose ➔ Solve自顶向下将大问题拆为子问题 │ 4. 树图搜索 (ToT / GoT) Tree/Graph of Thoughts多分支探索、回溯与剪枝 │ 5. 规划求解 (Plan-and-Solve) Global Planner ➔ Executor先出全盘计划再逐项执行 │ 6. 交互协同 (ReAct) Thought ➔ Action ➔ Observation思考与行动交替闭环 │ 7. 自省迭代 (Reflexion) Actor ➔ Evaluator ➔ Self-Reflection Memory反思自愈1.1 线性推演派CoT思维链Chain of Thought由 Google 在 2022 年提出的Chain of ThoughtCoT是推理模式革命的起点。核心机制在给出最终答案之前强制模型先生成一段显式的、中间步骤的推理过程Thinking Steps。代表形态Few-Shot CoT在 Prompt 中给模型展示包含解题步骤的示例Example。Zero-Shot CoT在 Prompt 末尾加入魔法短语“Lets think step by step”让我们一步一步思考。致命局限纯内部闭环Internal-OnlyCoT 仅依赖模型预训练时保存在参数中的静态记忆无法感知当前世界的动态变化。无法接触真实世界无法查询私有数据库、无法调用 API、无法执行 Python 代码。错误累积Error Compounding如果第 1 步推导出错后续的推导将一错到底模型在纯内部思考中无法自发察觉外界事实的打脸。1.2 空间搜索派ToT思维树与 GoT思维图人类在面对下棋、撰写系统架构设计或复杂的数学证明时大脑不是沿着一条直线走到黑而是会推演多个方案、评估分支优劣、走不通时主动回溯Backtracking。【Tree of Thoughts (ToT) 搜索树拓扑】 [初始状态 / 用户问题] │ ┌──────────────────┼──────────────────┐ ▼ ▼ ▼ [思考分支 A] [思考分支 B] [思考分支 C] (评估: 0.3) (评估: 0.8) (评估: 0.1) [剪枝 ✗] │ [剪枝 ✗] ┌─────────┴─────────┐ ▼ ▼ [分支 B-1] [分支 B-2] (评估: 0.9) (评估: 0.4) │ [剪枝 ✗] ▼ [最终答案]ToTTree of Thoughts思维树将思考过程建模为树结构每个节点代表一个中间思考状态Thought State。引入生成器Proposer生成多个可能路径利用评估器Evaluator对路径打分结合广度优先搜索BFS或深度优先搜索DFS进行探索与剪枝。GoTGraph of Thoughts思维图将树形拓扑进一步扩展为有向无环图DAG支持多个思考分支的合并Merge/Aggregate与循环反馈适合复杂网络决策。局限性Token 消耗和调用延迟极其高昂通常单次任务需要几十次 LLM 调用难以用于对响应速度要求高秒级的在线业务。1.3 宏观调度派Plan-and-Solve规划与执行CoT 和 ToT 往往是“边走边想”的微观推演。而Plan-and-Solve或 Plan-and-Execute采用了软件工程中的解耦思想把全局规划Planning与具体执行Execution彻底分开。[用户输入复杂任务] │ ▼ ┌────────────────────────────────────────────────────────┐ │ 1. Planner规划者 LLM │ │ 输出全局执行计划清单: │ │ - Step 1: 搜索 2026 年最新大模型榜单 │ │ - Step 2: 提取 DeepSeek 与 GPT-4o 的 Benchmark 分数 │ │ - Step 3: 写 Python 脚本计算两者提升百分比 │ │ - Step 4: 汇总生成 Markdown 表格 │ └──────────────────────────┬─────────────────────────────┘ │ 结构化任务列表 ▼ ┌────────────────────────────────────────────────────────┐ │ 2. Executor执行者 LLM / Worker 节点 │ │ 按照步骤逐个调用工具执行 ➔ 汇总中间结果 │ └──────────────────────────┬─────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────┐ │ 3. Re-Planner重规划者可选 │ │ 若某一步执行失败动态修改后续计划 │ └────────────────────────────────────────────────────────┘优势对大局掌控好避免迷失在局部的细节中大幅减少循环调用次数。劣势计划容易偏离实际。如果第一步执行出的真实环境结果与预期大相径庭原计划可能直接报废必须频繁触发 Re-Plan。1.4 全推理模式核心对比矩阵推理模式核心理念外部工具交互回溯与纠错能力Token 消耗适合场景Direct Prompting单步直接预测否无极低简单问答、日常闲聊Chain of Thought (CoT)线性多步内部思考否弱低数学计算、逻辑题推导Tree of Thoughts (ToT)树状搜索与启发式剪枝否极强极高复杂策略博弈、算法难题Plan-and-Solve宏观规划 ➔ 串行执行是中等中等明确的长流程任务拆解ReAct思考与行动交替闭环是强基于环境反馈中等知识库问答、Web 检索、多工具协同Reflexion在 ReAct 基础上增加记忆反思是极强跨轮迭代高复杂代码 Debug、自主编程智能体二、 ReAct 是啥原理、哲学与协同增效2.1 论文溯源与诞生背景ReAct是由普林斯顿大学的 Shunyu Yao 等人与 Google Brain 团队于 2022 年底在论文《ReAct: Synergizing Reasoning and Acting in Language Models》ICLR 2023中提出的核心架构范式。它的名字是两个单词的缩写与结合Reasoning推理 / 思考大模型的内在逻辑推演、意图理解、策略规划与状态追踪。Acting行动 / 工具调用对外部环境产生影响的操作如调用搜索引擎、执行 SQL、读取文件、调用计算器。ReAct Reasoning (思考) Acting (行动)2.2 为什么纯 Reasoning 或纯 Acting 都会失败在 ReAct 提出之前大模型领域存在两派分裂的路线【纯思考派 (Reason-Only / CoT)】 [用户问题] ──► 思考步骤 1 ──► 思考步骤 2 ──► 思考步骤 3 ──► 最终输出 缺陷完全没有外部信息注入模型遇到不懂的专有名词或最新事实只能强行胡说知识幻觉。 【纯行动派 (Act-Only / Tool Calling)】 [用户问题] ──► 调用搜索 API ──► 调用网页解析 ──► 调用计算器 ──► 最终输出 缺陷缺乏高维度的思考指导模型不知道“为什么要查这个”往往生成错误的查询参数陷入盲目试错。ReAct 的协同增效Synergy哲学ReAct 将两者融合为一个紧密耦合的交互闭环┌──────────────────────────────────────────┐ │ ReAct 核心交互状态闭环 │ └────────────────────┬─────────────────────┘ │ ┌─────────────────────────────────────┴─────────────────────────────────────┐ ▼ ▼ 【Reasoning 赋能 Acting】 【Acting 纠偏 Reasoning】 思考为行动指明方向 行动结果打破思考幻觉 - “为了算出增长率我先需要通过搜索获取今年的财报数字” - 工具返回了报错“404 Not Found” - “搜索词应该设为‘2026 某公司 Q2 财报 净利润’” - 思考立刻自愈“原链接失效我需要换用备用关键词重新检索”思考引导行动Reasoning ➔ Acting思考过程帮助模型追踪当前目标、分析上一步的执行结果、并决定下一步应该调用哪一个工具、传入什么参数。行动修正思考Acting ➔ Reasoning工具执行后返回的真实观测Observation注入到模型的上下文中为模型的下一步思考提供客观依据彻底抑制了模型的参数性幻觉。2.3 ReAct 基础原子三要素Thought / Action / Observation在 ReAct 的标准执行轨迹中所有交互都被严格结构化为由三个原子单元组成的多轮循环[用户输入 User Query] Cycle 1: Thought 1: [模型生成的思考] 我需要先分析问题的核心第一步应该... Action 1: [模型生成的动作] 工具名称[工具输入参数] Observation 1: [环境返回的真实结果] (由 Python 引擎执行工具后填入) Cycle 2: Thought 2: [模型生成的思考] 根据上一步返回的信息我发现...接下来我需要... Action 2: [模型生成的动作] 工具名称[工具输入参数] Observation 2: [环境返回的真实结果] ... ... (重复上述过程) Final Cycle: Thought N: [模型生成的思考] 我已经集齐了回答该问题所需的所有证据。 Final Answer: [模型生成的最终解答] 给用户的完整业务回复。Thought思考纯文本推理不对外部世界产生副作用用于解构问题、更新上下文认知、拟定下一步意图。Action行动具体的指令输出具有标准格式如ToolName[Argument]或 JSON 格式由外部执行器拦截并执行。Observation观测外部工具的执行返回值如 API 响应文本、错误日志、网页 HTML 片段作为新的上下文强制喂回给大模型。三、 ReAct 是怎么实现的底层运行机制与状态机从工程实现角度来看ReAct 绝非魔法而是一个精密的客户端状态机Client-Side State Machine。3.1 ReAct 端到端执行流程图下图展示了一个生产级 ReAct 引擎在处理单次用户请求时的内部运行流转图[用户提问 User Query] │ ▼ ┌──────────────────────────────────────────────┐ │ 1. 组装初始 Prompt │ │ - System Instruction (角色规范) │ │ - Tools Specification (可用工具列表) │ │ - Few-Shot Examples (少样本示例) │ │ - User Query (用户问题) │ └──────────────────────┬───────────────────────┘ │ ▼ ◄──────────────────────────────┐ ┌──────────────────────────────────────────────┐ │ │ 2. 调用 LLM 推理 (设置 Stop[Observation:])│ │ └──────────────────────┬───────────────────────┘ │ │ │ ▼ │ ┌──────────────────────────────────────────────┐ │ │ 3. 正则解析 LLM 输出内容 │ │ └──────────────────────┬───────────────────────┘ │ │ │ ┌──────────────────┴──────────────────┐ │ ▼ ▼ │ 【命中 Final Answer】 【命中 Action】 │ │ │ │ ▼ ▼ │ [直接结束输出最终答案] ┌─────────────────────┐ │ │ 4. 路由分发并执行工具│ │ │ calculator(...) │ │ │ search_api(...) │ │ └──────────┬──────────┘ │ │ │ ▼ │ ┌─────────────────────┐ │ │ 5. 组装 Observation │ │ │ 并追加至 Prompt 历史├──┘ └─────────────────────┘3.2 关键实现细节 1Prompt 模板工程Prompt EngineeringReAct 的灵魂在于对大模型进行强约束的 Prompt 设计。Prompt 必须清晰地向模型解释三件事你有哪些工具可用每个工具的作用与参数格式是什么你必须遵循什么样的输出格式规范给出 1~2 个包含Thought ➔ Action ➔ Observation ➔ Final Answer的完整交互示例。标准 ReAct Prompt 模板结构你是一个具备工具调用能力的智能助手。你可以通过思考、调用工具并观察结果来解决复杂问题。 【可用工具列表】 - search(query: str): 用于在互联网上检索最新的事实、新闻与实体信息。 - calculator(expression: str): 用于执行数学计算输入必须是合法的 Python 算术表达式。 - get_weather(city: str): 查询指定城市的实时天气情况。 【交互格式规范】 为了解决问题你必须严格按照以下格式进行输出 Question: 需要解答的用户问题 Thought: 阐述你当前的思考过程以及下一步计划 Action: 工具名称必须是 [search, calculator, get_weather] 之一 Action Input: 传入工具的具体参数 Observation: 工具执行后的输出结果此部分由系统提供你严禁自己编造 ... (上述 Thought/Action/Action Input/Observation 可以重复多轮) Thought: 我已经获得了足够的信息可以给出最终结论 Final Answer: 对原始用户问题的最终详细回答 【示例】 Question: 苹果公司的现任 CEO 叫什么名字他今年多少岁了 Thought: 我需要先查出苹果现任 CEO 的名字然后再查询他的出生年份并计算年龄。 Action: search Action Input: 苹果公司 现任 CEO Observation: 苹果公司现任首席执行官是蒂姆·库克Tim Cook。 Thought: 我已经知道 CEO 是蒂姆·库克。接下来需要查询他的出生日期。 Action: search Action Input: 蒂姆·库克 出生日期 Observation: 蒂姆·库克出生于 1960 年 11 月 1 日。 Thought: 库克出生于 1960 年当前是 2026 年我需要用计算器算出他的年龄。 Action: calculator Action Input: 2026 - 1960 Observation: 66 Thought: 我已经集齐了所有答案可以生成最终回复。 Final Answer: 苹果公司的现任 CEO 是蒂姆·库克Tim Cook截至 2026 年他大约 66 岁。 现在开始回答用户的问题 Question: {USER_QUESTION}3.3 关键实现细节 2停用词Stop Words控制在 ReAct 实现中有一个极易被忽视但至关重要的机制设置 Stop Words如Stop[Observation:]。为什么必须设置 Stop Words大模型在完成预训练后具有强烈的“自我补全”倾向。当它输出了Action: search和Action Input: 北京天气之后如果不停机它会自作聪明地顺手把Observation: 今天晴朗25度也给编造出来工程解法在调用 LLM API 时传入参数stop[Observation:]。大模型一旦生成完Action Input并准备输出Observation:时底层推理引擎会强制截断输出并交出控制权。此时后端程序接管流程真正去调用外部函数并将真实的返回值追加到上下文尾部。3.4 关键实现细节 3文本正则解析 vs 原生 Function Calling在早期如 LangChain 0.0.x 时代ReAct 纯粹依赖正则表达式Regex从模型的纯文本输出中抠出Action:和Action Input:。随着技术演进目前工业界存在两种实现路径┌────────────────────────────────────────────────────────────────────────┐ │ ReAct 两种工程实现路径对比 │ ├──────────────────┬─────────────────────────────┬───────────────────────┤ │ 实现方案 │ 1. 纯文本正则匹配 (Text-ReAct)│ 2. 原生 Tool Calling │ ├──────────────────┼─────────────────────────────┼───────────────────────┤ │ 适用模型 │ 任意开源/闭源模型甚至 7B 小模型│ 需专门针对 Function SFT 的模型│ ├──────────────────┼─────────────────────────────┼───────────────────────┤ │ 解析稳定性 │ 容易因模型格式轻微走样而解析报错│ 极高JSON 强类型约束│ ├──────────────────┼─────────────────────────────┼───────────────────────┤ │ 思考可见性 │ think 或 Thought: 原生可见 │ 早期版本思考被隐藏现代模型已恢复│ ├──────────────────┼─────────────────────────────┼───────────────────────┤ │ 调试与迁移门槛 │ 极低仅靠 Prompt 驱动 │ 依赖各厂商专有 API 协议│ └──────────────────┴─────────────────────────────┴───────────────────────┘现代成熟的 Agent 架构通常采用“原生 Function Calling 协议承载 Action模型思维链CoT承载 Thought”的现代化 ReAct 范式例如 DeepSeek-R1 / OpenAI Function Calling。四、 零依赖手写工业级 ReAct Agent 实战Python为了彻底摒弃黑盒框架如 LangChain带来的抽象迷雾我们将使用原生 Python OpenAI 标准 SDK 格式从零编写一个包含完整状态机、异常重试、死循环熔断机制的生产级 ReAct Agent 引擎。4.1 架构设计与工具箱实现首先我们定义 Agent 可使用的三个真实工具简易维基搜索、安全数学计算器以及天气查询。import os import re import math import json from typing import Dict, Any, Callable from openai import OpenAI # 1. 定义真实可调用的工具库 def tool_calculator(expression: str) - str: 安全数学计算器工具 try: # 清理非法字符仅允许基础数学运算 clean_expr expression.strip() allowed_names { abs: abs, round: round, max: max, min: min, math: math, pow: pow, sqrt: math.sqrt } # 禁用内置危险函数 result eval(clean_expr, {__builtins__: None}, allowed_names) return str(result) except Exception as e: return fError: 计算表达式失败 - {type(e).__name__}: {str(e)} def tool_search(query: str) - str: 模拟外部知识检索工具可替换为真实 Google/SerpAPI/Bing mock_database { DeepSeek: DeepSeek深度求索是一家专注于通用人工智能AGI的中国开源 AI 公司推出了 DeepSeek-V3 和 DeepSeek-R1 等推理模型。, 英伟达市值: 截至 2026 年初英伟达NVIDIA市值约为 3.5 万亿美元位居全球科技公司前列。, SpaceX 星舰: SpaceX 的星舰Starship是人类历史上体积最大、推力最强的重型可重复使用运载火箭。, Python 诞生年份: Python 编程语言由 Guido van Rossum 于 1989 年底发明第一个公开发行版发布于 1991 年。 } for key, val in mock_database.items(): if key.lower() in query.lower(): return val return f未找到关于 {query} 的直接搜索结果请尝试更换关键词。 def tool_weather(city: str) - str: 查询天气工具 mock_weather { 北京: 晴朗气温 18℃北风 2 级空气质量优良。, 上海: 多云有小雨气温 22℃东风 3 级。, 深圳: 雷阵雨转阴气温 28℃湿度 85%。, 香港: 晴间多云气温 27℃微风。 } for c, w in mock_weather.items(): if c in city: return f{c}实时天气{w} return f暂无 {city} 的天气数据。 # 工具注册表映射 TOOL_REGISTRY: Dict[str, Callable[[str], str]] { search: tool_search, calculator: tool_calculator, get_weather: tool_weather }4.2 ReAct Prompt 与解析核心模块# 2. ReAct 核心系统提示词 REACT_SYSTEM_PROMPT 你是一个具备严谨推理能力与外部工具调用能力的智能体AI Agent。 你可以通过【思考】、【行动】并【观察】外部环境返回的结果来解答复杂问题。 【可用工具列表】 1. search: 检索外部事实知识、历史事件、最新新闻等。输入参数为搜索关键词字符串。 2. calculator: 执行精确的数学算术计算。输入参数必须为合法的 Python 算术表达式如 3500000000000 / 1000。 3. get_weather: 查询目标城市的天气状况。输入参数为城市名称如 北京。 【必须严格遵循的交互格式】 Question: 用户的原始输入问题 Thought: 阐述你当前的思考推演。说明你为什么需要采取下一步行动或者分析已有数据。 Action: 工具名称必须严格从 [search, calculator, get_weather] 中选择一个。 Action Input: 传递给工具的具体参数值纯字符串不要添加引号或多余括号。 Observation: 工具执行后的返回结果此部分由环境自动填入你绝不能自己生成 ... (上述 Thought/Action/Action Input/Observation 流程可以重复循环但最多不得超过 8 轮) Thought: 我已经掌握了充分的证据与数据可以得出最终结论。 Final Answer: 针对原始用户问题的完整、结构化、富有逻辑的最终解答。 【严格纪律】 1. 每次输出必须以 Thought 开头。 2. 如果需要调用工具必须严格输出 Action 和 Action Input然后立即停机等待 3. 严禁在一次回答中自导自演生成 Observation 4. 当信息充足时必须输出 Final Answer 结束任务。 4.3 核心状态机循环Agent Engine实现# 3. 生产级 ReAct 引擎封装 class ProductionReActAgent: def __init__(self, model_name: str deepseek-chat, max_steps: int 8): self.model_name model_name self.max_steps max_steps self.client OpenAI( api_keyos.getenv(OPENAI_API_KEY, your-api-key), base_urlos.getenv(OPENAI_BASE_URL, https://api.deepseek.com/v1) ) self.tools TOOL_REGISTRY def _extract_action_and_input(self, text: str) - tuple[str, str]: 使用正则稳健解析 Action 与 Action Input action_match re.search(rAction:\s*([a-zA-Z0-9_]), text) action_input_match re.search(rAction Input:\s*(.), text) action action_match.group(1).strip() if action_match else action_input action_input_match.group(1).strip() if action_input_match else return action, action_input def _extract_final_answer(self, text: str) - str: 解析 Final Answer match re.search(rFinal Answer:\s*(.), text, re.DOTALL) return match.group(1).strip() if match else def run(self, user_query: str) - str: print(f\n [开始执行 Agent 任务] ) print(f用户问题: {user_query}\n) # 初始化 Prompt 上下文 prompt_history f{REACT_SYSTEM_PROMPT}\n\nQuestion: {user_query}\n for step in range(1, self.max_steps 1): print(f----- [Cycle {step} / {self.max_steps}] -----) # 1. 调用大模型推理设置 stop 截断词防止模型自我伪造 Observation response self.client.chat.completions.create( modelself.model_name, messages[{role: user, content: prompt_history}], temperature0.1, # 降低随机性保障格式严格遵循 stop[Observation:] # 关键机制强制在 Observation 处停机 ) # 获取当前步的输出文本 generated_text response.choices[0].message.content.strip() print(f{generated_text}) # 将当前大模型的输出拼接进历史 Prompt prompt_history f{generated_text}\n # 2. 检查是否已经得出最终答案 if Final Answer: in generated_text: final_res self._extract_final_answer(generated_text) print(f\n [任务达成] ) return final_res # 3. 解析 Action 和 Action Input action, action_input self._extract_action_and_input(generated_text) if not action or not action_input: # 容错处理如果模型既没有 Final Answer 也没有有效 Action error_feedback 格式错误未能识别出合法的 Action 或 Action Input。请确保按照规范输出 Action: tool_name 和 Action Input: args。 print(fObservation: {error_feedback}) prompt_history fObservation: {error_feedback}\n continue # 4. 分发并执行真实工具 print(f\n[执行工具调用] ➔ 工具名: {action}, 参数: {action_input}) if action in self.tools: try: tool_func self.tools[action] obs_result tool_func(action_input) except Exception as e: obs_result f工具执行发生异常: {str(e)} else: obs_result f错误未找到名为 {action} 的工具。当前可用工具为: {list(self.tools.keys())} print(fObservation: {obs_result}\n) # 5. 将工具执行结果作为 Observation 回填入 Prompt 历史中 prompt_history fObservation: {obs_result}\n return 错误超出最大执行步数限制Max Iterations ReachedAgent 未能收敛得出最终结论。4.4 复杂多步任务运行与轨迹跟踪我们构造一个需要跨越检索、日期计算与多步算术的复杂问题来验证 ReAct 状态机的威力# 4. 运行验证入口 if __name__ __main__: # 实例化 Agent agent ProductionReActAgent(model_namedeepseek-chat, max_steps6) # 复杂多跳问题涉及两次搜索与一次数学计算 complex_query Python 诞生于哪一年到 2026 年它已经诞生了多少年如果一个程序员从它诞生那年开始每天写 10 行代码到现在一共写了多少行代码按每年 365 天计算 final_result agent.run(complex_query) print(f\n【最终返回用户的内容】:\n{final_result})实际控制台输出轨迹解析模拟运行过程 [开始执行 Agent 任务] 用户问题: Python 诞生于哪一年到 2026 年它已经诞生了多少年如果一个程序员从它诞生那年开始每天写 10 行代码到现在一共写了多少行代码按每年 365 天计算 ----- [Cycle 1 / 6] ----- Thought: 我需要先查出 Python 编程语言诞生的具体年份。 Action: search Action Input: Python 诞生年份 [执行工具调用] ➔ 工具名: search, 参数: Python 诞生年份 Observation: Python 编程语言由 Guido van Rossum 于 1989 年底发明第一个公开发行版发布于 1991 年。 ----- [Cycle 2 / 6] ----- Thought: Python 最初发明于 1989 年首个版本发布于 1991 年通常以公开发行年份 1991 年计算。现在是 2026 年我需要先用计算器算出诞生年数2026 - 1991。 Action: calculator Action Input: 2026 - 1991 [执行工具调用] ➔ 工具名: calculator, 参数: 2026 - 1991 Observation: 35 ----- [Cycle 3 / 6] ----- Thought: 已经算出了年数为 35 年。接下来需要计算总行数35 年 × 每年 365 天 × 每天 10 行代码。我需要调用计算器完成这个算术乘法。 Action: calculator Action Input: 35 * 365 * 10 [执行工具调用] ➔ 工具名: calculator, 参数: 35 * 365 * 10 Observation: 127750 ----- [Cycle 4 / 6] ----- Thought: 我已经获取了全部答案要素Python 公开发布于 1991 年到 2026 年已有 35 年按照每天 10 行代码计算35 年累计代码行数为 127,750 行。我可以输出最终结论了。 Final Answer: 1. **诞生年份**Python 语言由 Guido van Rossum 发明首个公开发行版本发布于 **1991 年**。 2. **诞生年数**截至 2026 年Python 已经诞生了 **35 年**2026 - 1991。 3. **累计代码行数**若从 1991 年起每天坚持编写 10 行代码35 年间按每年 365 天计共 12,775 天累计编写的代码总量为 **127,750 行**。 [任务达成] 五、 ReAct 的生产级局限、失败模式与高阶演化虽然 ReAct 在通用任务上表现出色但在复杂的工业级生产环境中原生 ReAct 会频繁遭遇以下瓶颈5.1 原生 ReAct 的四大典型失败模式┌─────────────────────────────────────────────────────────────────────────────┐ │ ReAct 典型失败模式速查表 │ ├──────────────────┬─────────────────────────────┬────────────────────────────┤ │ 失败模式 │ 具体表现 │ 根本原因 │ ├──────────────────┼─────────────────────────────┼────────────────────────────┤ │ 1. 盲目死循环 │ 反复调用同一个工具传入相同│ 模型对 Observation 缺乏深度│ │ (Infinite Loop│ 的报错参数直到耗尽步数 │ 理解无法跳出思维定势 │ ├──────────────────┼─────────────────────────────┼────────────────────────────┤ │ 2. 工具幻觉 │ 凭空捏造不存在的工具名称或│ 参数 Schema 过于隐晦模型 │ │ (Tool Hallu) │ 传入错误的数据类型 │ 指令遵循能力不足 │ ├──────────────────┼─────────────────────────────┼────────────────────────────┤ │ 3. 上下文爆炸 │ 几轮网页检索后Prompt 累积 │ 每次工具返回的 Raw Text/HTML│ │ (Context Blow)│ 突破几十 K Token导致 OOM │ 未经过滤或摘要直接塞入历史 │ ├──────────────────┼─────────────────────────────┼────────────────────────────┤ │ 4. 过早放弃 │ 仅查到一半数据就自信地输出 │ 缺乏对全局目标的校验机制 │ │ (Early Stop) │ 带有假想答案的 Final Answer │ 模型自我评估过分乐观 │ └──────────────────┴─────────────────────────────┴────────────────────────────┘5.2 高阶进阶 1ReAct Reflexion反思记忆增强为了解决 ReAct 的“盲目死循环”与“过早放弃”诺奖团队成员 Noah Shinn 等人提出了Reflexion 架构。┌─────────────────────────────────────────┐ │ Actor (标准的 ReAct 循环) │ └────────────────────┬────────────────────┘ │ 生成执行轨迹 (Trajectory) ▼ ┌─────────────────────────────────────────┐ │ Evaluator (判别与评估器) │ │ - 测试用例通过率任务目标是否真正达成?│ └────────────────────┬────────────────────┘ │ 任务失败 (Reward 0) ▼ ┌─────────────────────────────────────────┐ │ Self-Reflection (自我反思模块) │ │ “我刚才在第 2 步搜错了词导致陷入了循环” │ └────────────────────┬────────────────────┘ │ 提炼教训并存入 ▼ ┌─────────────────────────────────────────┐ │ Episodic Memory (反思经验记忆库) │ │ (在下一轮 ReAct 开始时注入 System Prompt)│ └─────────────────────────────────────────┘核心机理当 ReAct 执行失败后由一个独立的 Reflection LLM 对刚才的失败轨迹进行“复盘”生成一段自然语言教训如*“我意识到我不应该使用模糊的‘中国人口’作为关键词下次应该加上‘国家统计局 2026 最新公报’”*并将该教训写入短期情景记忆Episodic Memory。在重试时ReAct 带着历史教训重新出发成功率提升 30% 以上。5.3 高阶进阶 2ReAct 结合强化学习Agentic-RL / GRPO传统的 ReAct 依赖人工设计的 Prompt 和少样本演示Few-Shot模型对于工具调用的掌控完全依赖在预训练中习得的通识能力。在最新的技术范式中如 DeepSeek-R1、OpenAI Operator、SWE-agentReAct 正在与强化学习RL深度融合环境奖励驱动将整个Thought ➔ Action ➔ Observation的多轮轨迹置于真实沙箱Docker / 浏览器中。GRPO 策略进化模型在没有人类预设格式约束的情况下通过数万次与外部环境工具的试错强化学习自发演化出最精炼的 Thought 思考逻辑与最高效的 Action 工具调用策略。六、 总结与架构选型建议ReAct 不仅是一种提示词工程技巧更是连接大模型内部语义世界与外部数字基础设施的标准通信协议。┌─────────────────────────────────────────────────────────────────────────┐ │ Agent 架构设计选型法则 │ ├─────────────────────────────────────────────────────────────────────────┤ │ 1. 任务路径确定、步骤边界清晰 (如固定报表生成) │ │ ➔ 优先选型Plan-and-Solve (规划与执行分离) │ │ │ │ 2. 任务充满未知、严重依赖外部动态数据反馈 (如智能客服、排障诊断、代码调试)│ │ ➔ 优先选型ReAct 状态机 (思考与行动实时交替) │ │ │ │ 3. 极高容错难度、需要自主试错自愈 (如 SWE 软件工程智能体) │ │ ➔ 优先选型ReAct Reflexion 反思记忆 / Agentic-RL │ └─────────────────────────────────────────────────────────────────────────┘回顾大模型智能体的演进路线从最初单向直觉的 CoT到宏观解耦的 Plan-and-Solve再到双向闭环的 ReAct智能体正一步步逼近人类工程师解决复杂现实问题的思考模式。理解并亲手实现 ReAct 的底层状态机循环与工具交互管道是每一位 AI 应用架构师从“调用大模型 API 的初学者”蜕变为“能够构建企业级自主智能体专家”的必经之路。
Agent 推理模式有哪些
摘要大语言模型LLM正在从单纯的“聊天与内容生成”演变为具备“环境感知、自主规划、工具调用与闭环执行”能力的智能体AI Agent。而决定一个 Agent 智商与执行力的核心就是其底层的推理模式Reasoning Paradigms。许多开发者在接触 Agent 时常对各种名词CoT、ToT、GoT、Plan-and-Solve、ReAct、Reflexion感到眼花缭乱也容易把 ReAct 简单等同于 LangChain 的某一行调用代码。本文将系统拆解主流 Agent 推理模式全景演进Direct ➔ CoT ➔ ToT/GoT ➔ Plan-and-Solve ➔ ReAct ➔ ReflexionReAct 核心机理剖析为什么“单纯思考”与“单纯行动”都会失败Reasoning 与 Acting 是如何实现协同增效的ReAct 的底层运行状态机Prompt 模板、停用词Stop Words、正则抽取、工具调度与上下文滚动的标准闭环工业级纯 Python 零依赖实战不依赖任何黑盒框架从零手写一个具备计算器、搜索引擎与天气查询能力的生产级 ReAct Agent 引擎常见失败模式与高阶演进死循环规避、幻觉防御、结合 Function Calling 与强化学习Agentic-RL的演进路径。一、 大模型 Agent 推理模式全景演进大语言模型本质是一个“基于概率预测下一个 Token”的概率引擎。如果我们直接向模型抛出复杂的多步骤问题Direct Prompting模型往往只能依赖浅层的隐式联想给出草率的答案容易产生严重的幻觉和逻辑混乱。为了让模型具备解决复杂多步问题的能力学术界与工业界演进出了一系列推理架构范式。┌───────────────────────────────────────────────────────────────────────────┐ │ 大模型推理模式Reasoning Paradigms演进谱系 │ └───────────────────────────────────────────────────────────────────────────┘ │ 1. 朴素模式 (Direct Prompting) Zero-Shot / Few-Shot无显式思考直接猜答案 │ 2. 线性链式 (Chain of Thought) CoT / Zero-Shot CoT单链线性推演无外部交互 │ 3. 分解执行 (Least-to-Most) Decompose ➔ Solve自顶向下将大问题拆为子问题 │ 4. 树图搜索 (ToT / GoT) Tree/Graph of Thoughts多分支探索、回溯与剪枝 │ 5. 规划求解 (Plan-and-Solve) Global Planner ➔ Executor先出全盘计划再逐项执行 │ 6. 交互协同 (ReAct) Thought ➔ Action ➔ Observation思考与行动交替闭环 │ 7. 自省迭代 (Reflexion) Actor ➔ Evaluator ➔ Self-Reflection Memory反思自愈1.1 线性推演派CoT思维链Chain of Thought由 Google 在 2022 年提出的Chain of ThoughtCoT是推理模式革命的起点。核心机制在给出最终答案之前强制模型先生成一段显式的、中间步骤的推理过程Thinking Steps。代表形态Few-Shot CoT在 Prompt 中给模型展示包含解题步骤的示例Example。Zero-Shot CoT在 Prompt 末尾加入魔法短语“Lets think step by step”让我们一步一步思考。致命局限纯内部闭环Internal-OnlyCoT 仅依赖模型预训练时保存在参数中的静态记忆无法感知当前世界的动态变化。无法接触真实世界无法查询私有数据库、无法调用 API、无法执行 Python 代码。错误累积Error Compounding如果第 1 步推导出错后续的推导将一错到底模型在纯内部思考中无法自发察觉外界事实的打脸。1.2 空间搜索派ToT思维树与 GoT思维图人类在面对下棋、撰写系统架构设计或复杂的数学证明时大脑不是沿着一条直线走到黑而是会推演多个方案、评估分支优劣、走不通时主动回溯Backtracking。【Tree of Thoughts (ToT) 搜索树拓扑】 [初始状态 / 用户问题] │ ┌──────────────────┼──────────────────┐ ▼ ▼ ▼ [思考分支 A] [思考分支 B] [思考分支 C] (评估: 0.3) (评估: 0.8) (评估: 0.1) [剪枝 ✗] │ [剪枝 ✗] ┌─────────┴─────────┐ ▼ ▼ [分支 B-1] [分支 B-2] (评估: 0.9) (评估: 0.4) │ [剪枝 ✗] ▼ [最终答案]ToTTree of Thoughts思维树将思考过程建模为树结构每个节点代表一个中间思考状态Thought State。引入生成器Proposer生成多个可能路径利用评估器Evaluator对路径打分结合广度优先搜索BFS或深度优先搜索DFS进行探索与剪枝。GoTGraph of Thoughts思维图将树形拓扑进一步扩展为有向无环图DAG支持多个思考分支的合并Merge/Aggregate与循环反馈适合复杂网络决策。局限性Token 消耗和调用延迟极其高昂通常单次任务需要几十次 LLM 调用难以用于对响应速度要求高秒级的在线业务。1.3 宏观调度派Plan-and-Solve规划与执行CoT 和 ToT 往往是“边走边想”的微观推演。而Plan-and-Solve或 Plan-and-Execute采用了软件工程中的解耦思想把全局规划Planning与具体执行Execution彻底分开。[用户输入复杂任务] │ ▼ ┌────────────────────────────────────────────────────────┐ │ 1. Planner规划者 LLM │ │ 输出全局执行计划清单: │ │ - Step 1: 搜索 2026 年最新大模型榜单 │ │ - Step 2: 提取 DeepSeek 与 GPT-4o 的 Benchmark 分数 │ │ - Step 3: 写 Python 脚本计算两者提升百分比 │ │ - Step 4: 汇总生成 Markdown 表格 │ └──────────────────────────┬─────────────────────────────┘ │ 结构化任务列表 ▼ ┌────────────────────────────────────────────────────────┐ │ 2. Executor执行者 LLM / Worker 节点 │ │ 按照步骤逐个调用工具执行 ➔ 汇总中间结果 │ └──────────────────────────┬─────────────────────────────┘ │ ▼ ┌────────────────────────────────────────────────────────┐ │ 3. Re-Planner重规划者可选 │ │ 若某一步执行失败动态修改后续计划 │ └────────────────────────────────────────────────────────┘优势对大局掌控好避免迷失在局部的细节中大幅减少循环调用次数。劣势计划容易偏离实际。如果第一步执行出的真实环境结果与预期大相径庭原计划可能直接报废必须频繁触发 Re-Plan。1.4 全推理模式核心对比矩阵推理模式核心理念外部工具交互回溯与纠错能力Token 消耗适合场景Direct Prompting单步直接预测否无极低简单问答、日常闲聊Chain of Thought (CoT)线性多步内部思考否弱低数学计算、逻辑题推导Tree of Thoughts (ToT)树状搜索与启发式剪枝否极强极高复杂策略博弈、算法难题Plan-and-Solve宏观规划 ➔ 串行执行是中等中等明确的长流程任务拆解ReAct思考与行动交替闭环是强基于环境反馈中等知识库问答、Web 检索、多工具协同Reflexion在 ReAct 基础上增加记忆反思是极强跨轮迭代高复杂代码 Debug、自主编程智能体二、 ReAct 是啥原理、哲学与协同增效2.1 论文溯源与诞生背景ReAct是由普林斯顿大学的 Shunyu Yao 等人与 Google Brain 团队于 2022 年底在论文《ReAct: Synergizing Reasoning and Acting in Language Models》ICLR 2023中提出的核心架构范式。它的名字是两个单词的缩写与结合Reasoning推理 / 思考大模型的内在逻辑推演、意图理解、策略规划与状态追踪。Acting行动 / 工具调用对外部环境产生影响的操作如调用搜索引擎、执行 SQL、读取文件、调用计算器。ReAct Reasoning (思考) Acting (行动)2.2 为什么纯 Reasoning 或纯 Acting 都会失败在 ReAct 提出之前大模型领域存在两派分裂的路线【纯思考派 (Reason-Only / CoT)】 [用户问题] ──► 思考步骤 1 ──► 思考步骤 2 ──► 思考步骤 3 ──► 最终输出 缺陷完全没有外部信息注入模型遇到不懂的专有名词或最新事实只能强行胡说知识幻觉。 【纯行动派 (Act-Only / Tool Calling)】 [用户问题] ──► 调用搜索 API ──► 调用网页解析 ──► 调用计算器 ──► 最终输出 缺陷缺乏高维度的思考指导模型不知道“为什么要查这个”往往生成错误的查询参数陷入盲目试错。ReAct 的协同增效Synergy哲学ReAct 将两者融合为一个紧密耦合的交互闭环┌──────────────────────────────────────────┐ │ ReAct 核心交互状态闭环 │ └────────────────────┬─────────────────────┘ │ ┌─────────────────────────────────────┴─────────────────────────────────────┐ ▼ ▼ 【Reasoning 赋能 Acting】 【Acting 纠偏 Reasoning】 思考为行动指明方向 行动结果打破思考幻觉 - “为了算出增长率我先需要通过搜索获取今年的财报数字” - 工具返回了报错“404 Not Found” - “搜索词应该设为‘2026 某公司 Q2 财报 净利润’” - 思考立刻自愈“原链接失效我需要换用备用关键词重新检索”思考引导行动Reasoning ➔ Acting思考过程帮助模型追踪当前目标、分析上一步的执行结果、并决定下一步应该调用哪一个工具、传入什么参数。行动修正思考Acting ➔ Reasoning工具执行后返回的真实观测Observation注入到模型的上下文中为模型的下一步思考提供客观依据彻底抑制了模型的参数性幻觉。2.3 ReAct 基础原子三要素Thought / Action / Observation在 ReAct 的标准执行轨迹中所有交互都被严格结构化为由三个原子单元组成的多轮循环[用户输入 User Query] Cycle 1: Thought 1: [模型生成的思考] 我需要先分析问题的核心第一步应该... Action 1: [模型生成的动作] 工具名称[工具输入参数] Observation 1: [环境返回的真实结果] (由 Python 引擎执行工具后填入) Cycle 2: Thought 2: [模型生成的思考] 根据上一步返回的信息我发现...接下来我需要... Action 2: [模型生成的动作] 工具名称[工具输入参数] Observation 2: [环境返回的真实结果] ... ... (重复上述过程) Final Cycle: Thought N: [模型生成的思考] 我已经集齐了回答该问题所需的所有证据。 Final Answer: [模型生成的最终解答] 给用户的完整业务回复。Thought思考纯文本推理不对外部世界产生副作用用于解构问题、更新上下文认知、拟定下一步意图。Action行动具体的指令输出具有标准格式如ToolName[Argument]或 JSON 格式由外部执行器拦截并执行。Observation观测外部工具的执行返回值如 API 响应文本、错误日志、网页 HTML 片段作为新的上下文强制喂回给大模型。三、 ReAct 是怎么实现的底层运行机制与状态机从工程实现角度来看ReAct 绝非魔法而是一个精密的客户端状态机Client-Side State Machine。3.1 ReAct 端到端执行流程图下图展示了一个生产级 ReAct 引擎在处理单次用户请求时的内部运行流转图[用户提问 User Query] │ ▼ ┌──────────────────────────────────────────────┐ │ 1. 组装初始 Prompt │ │ - System Instruction (角色规范) │ │ - Tools Specification (可用工具列表) │ │ - Few-Shot Examples (少样本示例) │ │ - User Query (用户问题) │ └──────────────────────┬───────────────────────┘ │ ▼ ◄──────────────────────────────┐ ┌──────────────────────────────────────────────┐ │ │ 2. 调用 LLM 推理 (设置 Stop[Observation:])│ │ └──────────────────────┬───────────────────────┘ │ │ │ ▼ │ ┌──────────────────────────────────────────────┐ │ │ 3. 正则解析 LLM 输出内容 │ │ └──────────────────────┬───────────────────────┘ │ │ │ ┌──────────────────┴──────────────────┐ │ ▼ ▼ │ 【命中 Final Answer】 【命中 Action】 │ │ │ │ ▼ ▼ │ [直接结束输出最终答案] ┌─────────────────────┐ │ │ 4. 路由分发并执行工具│ │ │ calculator(...) │ │ │ search_api(...) │ │ └──────────┬──────────┘ │ │ │ ▼ │ ┌─────────────────────┐ │ │ 5. 组装 Observation │ │ │ 并追加至 Prompt 历史├──┘ └─────────────────────┘3.2 关键实现细节 1Prompt 模板工程Prompt EngineeringReAct 的灵魂在于对大模型进行强约束的 Prompt 设计。Prompt 必须清晰地向模型解释三件事你有哪些工具可用每个工具的作用与参数格式是什么你必须遵循什么样的输出格式规范给出 1~2 个包含Thought ➔ Action ➔ Observation ➔ Final Answer的完整交互示例。标准 ReAct Prompt 模板结构你是一个具备工具调用能力的智能助手。你可以通过思考、调用工具并观察结果来解决复杂问题。 【可用工具列表】 - search(query: str): 用于在互联网上检索最新的事实、新闻与实体信息。 - calculator(expression: str): 用于执行数学计算输入必须是合法的 Python 算术表达式。 - get_weather(city: str): 查询指定城市的实时天气情况。 【交互格式规范】 为了解决问题你必须严格按照以下格式进行输出 Question: 需要解答的用户问题 Thought: 阐述你当前的思考过程以及下一步计划 Action: 工具名称必须是 [search, calculator, get_weather] 之一 Action Input: 传入工具的具体参数 Observation: 工具执行后的输出结果此部分由系统提供你严禁自己编造 ... (上述 Thought/Action/Action Input/Observation 可以重复多轮) Thought: 我已经获得了足够的信息可以给出最终结论 Final Answer: 对原始用户问题的最终详细回答 【示例】 Question: 苹果公司的现任 CEO 叫什么名字他今年多少岁了 Thought: 我需要先查出苹果现任 CEO 的名字然后再查询他的出生年份并计算年龄。 Action: search Action Input: 苹果公司 现任 CEO Observation: 苹果公司现任首席执行官是蒂姆·库克Tim Cook。 Thought: 我已经知道 CEO 是蒂姆·库克。接下来需要查询他的出生日期。 Action: search Action Input: 蒂姆·库克 出生日期 Observation: 蒂姆·库克出生于 1960 年 11 月 1 日。 Thought: 库克出生于 1960 年当前是 2026 年我需要用计算器算出他的年龄。 Action: calculator Action Input: 2026 - 1960 Observation: 66 Thought: 我已经集齐了所有答案可以生成最终回复。 Final Answer: 苹果公司的现任 CEO 是蒂姆·库克Tim Cook截至 2026 年他大约 66 岁。 现在开始回答用户的问题 Question: {USER_QUESTION}3.3 关键实现细节 2停用词Stop Words控制在 ReAct 实现中有一个极易被忽视但至关重要的机制设置 Stop Words如Stop[Observation:]。为什么必须设置 Stop Words大模型在完成预训练后具有强烈的“自我补全”倾向。当它输出了Action: search和Action Input: 北京天气之后如果不停机它会自作聪明地顺手把Observation: 今天晴朗25度也给编造出来工程解法在调用 LLM API 时传入参数stop[Observation:]。大模型一旦生成完Action Input并准备输出Observation:时底层推理引擎会强制截断输出并交出控制权。此时后端程序接管流程真正去调用外部函数并将真实的返回值追加到上下文尾部。3.4 关键实现细节 3文本正则解析 vs 原生 Function Calling在早期如 LangChain 0.0.x 时代ReAct 纯粹依赖正则表达式Regex从模型的纯文本输出中抠出Action:和Action Input:。随着技术演进目前工业界存在两种实现路径┌────────────────────────────────────────────────────────────────────────┐ │ ReAct 两种工程实现路径对比 │ ├──────────────────┬─────────────────────────────┬───────────────────────┤ │ 实现方案 │ 1. 纯文本正则匹配 (Text-ReAct)│ 2. 原生 Tool Calling │ ├──────────────────┼─────────────────────────────┼───────────────────────┤ │ 适用模型 │ 任意开源/闭源模型甚至 7B 小模型│ 需专门针对 Function SFT 的模型│ ├──────────────────┼─────────────────────────────┼───────────────────────┤ │ 解析稳定性 │ 容易因模型格式轻微走样而解析报错│ 极高JSON 强类型约束│ ├──────────────────┼─────────────────────────────┼───────────────────────┤ │ 思考可见性 │ think 或 Thought: 原生可见 │ 早期版本思考被隐藏现代模型已恢复│ ├──────────────────┼─────────────────────────────┼───────────────────────┤ │ 调试与迁移门槛 │ 极低仅靠 Prompt 驱动 │ 依赖各厂商专有 API 协议│ └──────────────────┴─────────────────────────────┴───────────────────────┘现代成熟的 Agent 架构通常采用“原生 Function Calling 协议承载 Action模型思维链CoT承载 Thought”的现代化 ReAct 范式例如 DeepSeek-R1 / OpenAI Function Calling。四、 零依赖手写工业级 ReAct Agent 实战Python为了彻底摒弃黑盒框架如 LangChain带来的抽象迷雾我们将使用原生 Python OpenAI 标准 SDK 格式从零编写一个包含完整状态机、异常重试、死循环熔断机制的生产级 ReAct Agent 引擎。4.1 架构设计与工具箱实现首先我们定义 Agent 可使用的三个真实工具简易维基搜索、安全数学计算器以及天气查询。import os import re import math import json from typing import Dict, Any, Callable from openai import OpenAI # 1. 定义真实可调用的工具库 def tool_calculator(expression: str) - str: 安全数学计算器工具 try: # 清理非法字符仅允许基础数学运算 clean_expr expression.strip() allowed_names { abs: abs, round: round, max: max, min: min, math: math, pow: pow, sqrt: math.sqrt } # 禁用内置危险函数 result eval(clean_expr, {__builtins__: None}, allowed_names) return str(result) except Exception as e: return fError: 计算表达式失败 - {type(e).__name__}: {str(e)} def tool_search(query: str) - str: 模拟外部知识检索工具可替换为真实 Google/SerpAPI/Bing mock_database { DeepSeek: DeepSeek深度求索是一家专注于通用人工智能AGI的中国开源 AI 公司推出了 DeepSeek-V3 和 DeepSeek-R1 等推理模型。, 英伟达市值: 截至 2026 年初英伟达NVIDIA市值约为 3.5 万亿美元位居全球科技公司前列。, SpaceX 星舰: SpaceX 的星舰Starship是人类历史上体积最大、推力最强的重型可重复使用运载火箭。, Python 诞生年份: Python 编程语言由 Guido van Rossum 于 1989 年底发明第一个公开发行版发布于 1991 年。 } for key, val in mock_database.items(): if key.lower() in query.lower(): return val return f未找到关于 {query} 的直接搜索结果请尝试更换关键词。 def tool_weather(city: str) - str: 查询天气工具 mock_weather { 北京: 晴朗气温 18℃北风 2 级空气质量优良。, 上海: 多云有小雨气温 22℃东风 3 级。, 深圳: 雷阵雨转阴气温 28℃湿度 85%。, 香港: 晴间多云气温 27℃微风。 } for c, w in mock_weather.items(): if c in city: return f{c}实时天气{w} return f暂无 {city} 的天气数据。 # 工具注册表映射 TOOL_REGISTRY: Dict[str, Callable[[str], str]] { search: tool_search, calculator: tool_calculator, get_weather: tool_weather }4.2 ReAct Prompt 与解析核心模块# 2. ReAct 核心系统提示词 REACT_SYSTEM_PROMPT 你是一个具备严谨推理能力与外部工具调用能力的智能体AI Agent。 你可以通过【思考】、【行动】并【观察】外部环境返回的结果来解答复杂问题。 【可用工具列表】 1. search: 检索外部事实知识、历史事件、最新新闻等。输入参数为搜索关键词字符串。 2. calculator: 执行精确的数学算术计算。输入参数必须为合法的 Python 算术表达式如 3500000000000 / 1000。 3. get_weather: 查询目标城市的天气状况。输入参数为城市名称如 北京。 【必须严格遵循的交互格式】 Question: 用户的原始输入问题 Thought: 阐述你当前的思考推演。说明你为什么需要采取下一步行动或者分析已有数据。 Action: 工具名称必须严格从 [search, calculator, get_weather] 中选择一个。 Action Input: 传递给工具的具体参数值纯字符串不要添加引号或多余括号。 Observation: 工具执行后的返回结果此部分由环境自动填入你绝不能自己生成 ... (上述 Thought/Action/Action Input/Observation 流程可以重复循环但最多不得超过 8 轮) Thought: 我已经掌握了充分的证据与数据可以得出最终结论。 Final Answer: 针对原始用户问题的完整、结构化、富有逻辑的最终解答。 【严格纪律】 1. 每次输出必须以 Thought 开头。 2. 如果需要调用工具必须严格输出 Action 和 Action Input然后立即停机等待 3. 严禁在一次回答中自导自演生成 Observation 4. 当信息充足时必须输出 Final Answer 结束任务。 4.3 核心状态机循环Agent Engine实现# 3. 生产级 ReAct 引擎封装 class ProductionReActAgent: def __init__(self, model_name: str deepseek-chat, max_steps: int 8): self.model_name model_name self.max_steps max_steps self.client OpenAI( api_keyos.getenv(OPENAI_API_KEY, your-api-key), base_urlos.getenv(OPENAI_BASE_URL, https://api.deepseek.com/v1) ) self.tools TOOL_REGISTRY def _extract_action_and_input(self, text: str) - tuple[str, str]: 使用正则稳健解析 Action 与 Action Input action_match re.search(rAction:\s*([a-zA-Z0-9_]), text) action_input_match re.search(rAction Input:\s*(.), text) action action_match.group(1).strip() if action_match else action_input action_input_match.group(1).strip() if action_input_match else return action, action_input def _extract_final_answer(self, text: str) - str: 解析 Final Answer match re.search(rFinal Answer:\s*(.), text, re.DOTALL) return match.group(1).strip() if match else def run(self, user_query: str) - str: print(f\n [开始执行 Agent 任务] ) print(f用户问题: {user_query}\n) # 初始化 Prompt 上下文 prompt_history f{REACT_SYSTEM_PROMPT}\n\nQuestion: {user_query}\n for step in range(1, self.max_steps 1): print(f----- [Cycle {step} / {self.max_steps}] -----) # 1. 调用大模型推理设置 stop 截断词防止模型自我伪造 Observation response self.client.chat.completions.create( modelself.model_name, messages[{role: user, content: prompt_history}], temperature0.1, # 降低随机性保障格式严格遵循 stop[Observation:] # 关键机制强制在 Observation 处停机 ) # 获取当前步的输出文本 generated_text response.choices[0].message.content.strip() print(f{generated_text}) # 将当前大模型的输出拼接进历史 Prompt prompt_history f{generated_text}\n # 2. 检查是否已经得出最终答案 if Final Answer: in generated_text: final_res self._extract_final_answer(generated_text) print(f\n [任务达成] ) return final_res # 3. 解析 Action 和 Action Input action, action_input self._extract_action_and_input(generated_text) if not action or not action_input: # 容错处理如果模型既没有 Final Answer 也没有有效 Action error_feedback 格式错误未能识别出合法的 Action 或 Action Input。请确保按照规范输出 Action: tool_name 和 Action Input: args。 print(fObservation: {error_feedback}) prompt_history fObservation: {error_feedback}\n continue # 4. 分发并执行真实工具 print(f\n[执行工具调用] ➔ 工具名: {action}, 参数: {action_input}) if action in self.tools: try: tool_func self.tools[action] obs_result tool_func(action_input) except Exception as e: obs_result f工具执行发生异常: {str(e)} else: obs_result f错误未找到名为 {action} 的工具。当前可用工具为: {list(self.tools.keys())} print(fObservation: {obs_result}\n) # 5. 将工具执行结果作为 Observation 回填入 Prompt 历史中 prompt_history fObservation: {obs_result}\n return 错误超出最大执行步数限制Max Iterations ReachedAgent 未能收敛得出最终结论。4.4 复杂多步任务运行与轨迹跟踪我们构造一个需要跨越检索、日期计算与多步算术的复杂问题来验证 ReAct 状态机的威力# 4. 运行验证入口 if __name__ __main__: # 实例化 Agent agent ProductionReActAgent(model_namedeepseek-chat, max_steps6) # 复杂多跳问题涉及两次搜索与一次数学计算 complex_query Python 诞生于哪一年到 2026 年它已经诞生了多少年如果一个程序员从它诞生那年开始每天写 10 行代码到现在一共写了多少行代码按每年 365 天计算 final_result agent.run(complex_query) print(f\n【最终返回用户的内容】:\n{final_result})实际控制台输出轨迹解析模拟运行过程 [开始执行 Agent 任务] 用户问题: Python 诞生于哪一年到 2026 年它已经诞生了多少年如果一个程序员从它诞生那年开始每天写 10 行代码到现在一共写了多少行代码按每年 365 天计算 ----- [Cycle 1 / 6] ----- Thought: 我需要先查出 Python 编程语言诞生的具体年份。 Action: search Action Input: Python 诞生年份 [执行工具调用] ➔ 工具名: search, 参数: Python 诞生年份 Observation: Python 编程语言由 Guido van Rossum 于 1989 年底发明第一个公开发行版发布于 1991 年。 ----- [Cycle 2 / 6] ----- Thought: Python 最初发明于 1989 年首个版本发布于 1991 年通常以公开发行年份 1991 年计算。现在是 2026 年我需要先用计算器算出诞生年数2026 - 1991。 Action: calculator Action Input: 2026 - 1991 [执行工具调用] ➔ 工具名: calculator, 参数: 2026 - 1991 Observation: 35 ----- [Cycle 3 / 6] ----- Thought: 已经算出了年数为 35 年。接下来需要计算总行数35 年 × 每年 365 天 × 每天 10 行代码。我需要调用计算器完成这个算术乘法。 Action: calculator Action Input: 35 * 365 * 10 [执行工具调用] ➔ 工具名: calculator, 参数: 35 * 365 * 10 Observation: 127750 ----- [Cycle 4 / 6] ----- Thought: 我已经获取了全部答案要素Python 公开发布于 1991 年到 2026 年已有 35 年按照每天 10 行代码计算35 年累计代码行数为 127,750 行。我可以输出最终结论了。 Final Answer: 1. **诞生年份**Python 语言由 Guido van Rossum 发明首个公开发行版本发布于 **1991 年**。 2. **诞生年数**截至 2026 年Python 已经诞生了 **35 年**2026 - 1991。 3. **累计代码行数**若从 1991 年起每天坚持编写 10 行代码35 年间按每年 365 天计共 12,775 天累计编写的代码总量为 **127,750 行**。 [任务达成] 五、 ReAct 的生产级局限、失败模式与高阶演化虽然 ReAct 在通用任务上表现出色但在复杂的工业级生产环境中原生 ReAct 会频繁遭遇以下瓶颈5.1 原生 ReAct 的四大典型失败模式┌─────────────────────────────────────────────────────────────────────────────┐ │ ReAct 典型失败模式速查表 │ ├──────────────────┬─────────────────────────────┬────────────────────────────┤ │ 失败模式 │ 具体表现 │ 根本原因 │ ├──────────────────┼─────────────────────────────┼────────────────────────────┤ │ 1. 盲目死循环 │ 反复调用同一个工具传入相同│ 模型对 Observation 缺乏深度│ │ (Infinite Loop│ 的报错参数直到耗尽步数 │ 理解无法跳出思维定势 │ ├──────────────────┼─────────────────────────────┼────────────────────────────┤ │ 2. 工具幻觉 │ 凭空捏造不存在的工具名称或│ 参数 Schema 过于隐晦模型 │ │ (Tool Hallu) │ 传入错误的数据类型 │ 指令遵循能力不足 │ ├──────────────────┼─────────────────────────────┼────────────────────────────┤ │ 3. 上下文爆炸 │ 几轮网页检索后Prompt 累积 │ 每次工具返回的 Raw Text/HTML│ │ (Context Blow)│ 突破几十 K Token导致 OOM │ 未经过滤或摘要直接塞入历史 │ ├──────────────────┼─────────────────────────────┼────────────────────────────┤ │ 4. 过早放弃 │ 仅查到一半数据就自信地输出 │ 缺乏对全局目标的校验机制 │ │ (Early Stop) │ 带有假想答案的 Final Answer │ 模型自我评估过分乐观 │ └──────────────────┴─────────────────────────────┴────────────────────────────┘5.2 高阶进阶 1ReAct Reflexion反思记忆增强为了解决 ReAct 的“盲目死循环”与“过早放弃”诺奖团队成员 Noah Shinn 等人提出了Reflexion 架构。┌─────────────────────────────────────────┐ │ Actor (标准的 ReAct 循环) │ └────────────────────┬────────────────────┘ │ 生成执行轨迹 (Trajectory) ▼ ┌─────────────────────────────────────────┐ │ Evaluator (判别与评估器) │ │ - 测试用例通过率任务目标是否真正达成?│ └────────────────────┬────────────────────┘ │ 任务失败 (Reward 0) ▼ ┌─────────────────────────────────────────┐ │ Self-Reflection (自我反思模块) │ │ “我刚才在第 2 步搜错了词导致陷入了循环” │ └────────────────────┬────────────────────┘ │ 提炼教训并存入 ▼ ┌─────────────────────────────────────────┐ │ Episodic Memory (反思经验记忆库) │ │ (在下一轮 ReAct 开始时注入 System Prompt)│ └─────────────────────────────────────────┘核心机理当 ReAct 执行失败后由一个独立的 Reflection LLM 对刚才的失败轨迹进行“复盘”生成一段自然语言教训如*“我意识到我不应该使用模糊的‘中国人口’作为关键词下次应该加上‘国家统计局 2026 最新公报’”*并将该教训写入短期情景记忆Episodic Memory。在重试时ReAct 带着历史教训重新出发成功率提升 30% 以上。5.3 高阶进阶 2ReAct 结合强化学习Agentic-RL / GRPO传统的 ReAct 依赖人工设计的 Prompt 和少样本演示Few-Shot模型对于工具调用的掌控完全依赖在预训练中习得的通识能力。在最新的技术范式中如 DeepSeek-R1、OpenAI Operator、SWE-agentReAct 正在与强化学习RL深度融合环境奖励驱动将整个Thought ➔ Action ➔ Observation的多轮轨迹置于真实沙箱Docker / 浏览器中。GRPO 策略进化模型在没有人类预设格式约束的情况下通过数万次与外部环境工具的试错强化学习自发演化出最精炼的 Thought 思考逻辑与最高效的 Action 工具调用策略。六、 总结与架构选型建议ReAct 不仅是一种提示词工程技巧更是连接大模型内部语义世界与外部数字基础设施的标准通信协议。┌─────────────────────────────────────────────────────────────────────────┐ │ Agent 架构设计选型法则 │ ├─────────────────────────────────────────────────────────────────────────┤ │ 1. 任务路径确定、步骤边界清晰 (如固定报表生成) │ │ ➔ 优先选型Plan-and-Solve (规划与执行分离) │ │ │ │ 2. 任务充满未知、严重依赖外部动态数据反馈 (如智能客服、排障诊断、代码调试)│ │ ➔ 优先选型ReAct 状态机 (思考与行动实时交替) │ │ │ │ 3. 极高容错难度、需要自主试错自愈 (如 SWE 软件工程智能体) │ │ ➔ 优先选型ReAct Reflexion 反思记忆 / Agentic-RL │ └─────────────────────────────────────────────────────────────────────────┘回顾大模型智能体的演进路线从最初单向直觉的 CoT到宏观解耦的 Plan-and-Solve再到双向闭环的 ReAct智能体正一步步逼近人类工程师解决复杂现实问题的思考模式。理解并亲手实现 ReAct 的底层状态机循环与工具交互管道是每一位 AI 应用架构师从“调用大模型 API 的初学者”蜕变为“能够构建企业级自主智能体专家”的必经之路。
