1. 从“指令执行”到“自主思考”为什么我们需要ReAct模式如果你已经尝试过一些基础的AI Agent框架比如LangChain的简单链式调用你可能会发现一个明显的瓶颈模型就像一个“听话但死板”的执行者。你给它一个任务比如“查询北京的天气”它会直接调用你预设的天气API工具然后返回结果。这很好但仅限于简单、明确的任务。一旦任务变得复杂、模糊或者需要多步骤推理这种“指令-执行”的单向模式就立刻捉襟见肘了。举个例子你给Agent一个任务“帮我分析一下公司上个季度销售额下滑的主要原因可能是什么并给出三条改进建议。” 一个简单的工具调用型Agent可能会直接去调用“销售数据分析”工具然后返回一堆数字图表。但它不会去思考“我需要先获取销售数据然后对比历史数据再结合市场报告和客户反馈交叉验证后才能得出结论。” 它更不会在遇到数据缺失时主动去搜索行业报告或者在发现某个产品线异常时去查询该产品的用户评价。它缺乏“思考”和“调整”的能力。这就是ReAct模式要解决的核心问题。ReAct即Reasoning Acting翻译过来是“推理-行动”。它不是一个具体的工具或API而是一种让AI Agent工作的范式或架构。其核心思想是模仿人类解决问题的方式先动脑思考Reasoning再动手行动Acting然后观察结果Observation并根据观察结果进行下一轮的思考如此循环直到任务完成或无法继续。这个循环之所以强大是因为它将大语言模型LLM的推理能力与外部工具的执行能力结合在了一起。LLM不再仅仅是生成文本或调用工具它成为了一个“大脑”负责规划、决策、反思。而外部工具如搜索引擎、数据库、代码解释器、API则是它的“手脚”负责获取信息、执行操作。这种“思考-行动-观察”的闭环使得Agent能够处理那些需要多步骤、有条件分支、动态调整策略的复杂任务。在我实际构建营销分析、竞品调研、自动化报告生成等复杂Agent的过程中从简单的工具链切换到ReAct模式效果提升是立竿见影的。Agent从一个“脚本执行器”变成了一个“初级分析师”它会自己决定先查什么、后查什么发现矛盾信息时会尝试从其他渠道验证最终给出的结论也更有逻辑性和说服力。接下来我们就深入这个循环的内部看看它具体是如何运作的。2. ReAct循环的解剖思考、行动、观察的三步舞曲ReAct模式的核心就是一个循环Thought - Action - Observation。理解每一个环节的输入、输出和设计要点是构建有效Agent的关键。我们可以把这个循环想象成解决一个侦探案件思考是分析线索、形成假设行动是去调查取证观察是拿到证据。2.1 Thought思考Agent的“内心独白”这是循环的起点也是LLM作为“大脑”发挥核心作用的环节。Thought的目标是基于当前的任务目标、已有的历史信息包括之前的思考、行动和观察决定下一步应该做什么。Thought的输出内容有严格的格式要求这通常通过提示词工程Prompt Engineering来约束。一个典型的Thought输出格式是Thought: 我现在需要解决[任务描述]。目前我已经知道[历史观察信息]。为了推进任务我下一步应该[具体的推理过程]因此我将采取[下一步行动]。关键设计要点引导深度推理提示词必须鼓励模型进行逐步推理而不是跳跃式结论。例如不能只说“去搜索”而要说“因为我们需要了解X的背景信息而搜索引擎是获取公开信息最有效的工具所以下一步是使用搜索工具查询X”。保持上下文Thought必须显式地引用之前的Observation证明它“消化”了上一步的结果。例如“根据上一步搜索到的2023年市场报告显示该品类增长放缓因此我怀疑是市场大环境问题。为了验证我需要查看我们公司具体产品的销售数据。”决定行动边界Thought的结尾必须明确指向一个具体的、可执行的Action并且这个Action必须在Agent可用的工具列表内。一个反面例子Thought: 用户想知道销售额下降的原因我应该去分析数据。这个思考太模糊“分析数据”不是一个可执行的行动。一个正面例子Thought: 用户想知道公司Q3销售额下降的原因。目前我没有任何数据。第一步应该是获取基础的销售数据。我可以使用‘查询数据库’工具执行SQL语句来获取Q3以及Q2的销售额、各产品线细分数据。在我的实践中Thought环节最容易出现的问题是模型“胡思乱想”即推理过程偏离正轨或陷入循环。这时就需要在提示词中加入更强的约束比如“你必须基于已知事实进行推理不要臆测未知信息”或者设定最大循环次数来避免死循环。2.2 Action行动调用工具的手Action是Thought的自然延伸是Agent与外部世界交互的方式。它的格式非常标准化Action: 工具名称 Action Input: 传递给工具的输入参数JSON格式或特定字符串例如基于上面的ThoughtAction可能是Action: query_database Action Input: {sql: SELECT product_line, SUM(amount) as sales FROM orders WHERE quarter Q3 GROUP BY product_line ORDER BY sales DESC;}关键设计要点工具描述的清晰度在给Agent初始化时你必须为每个工具提供清晰、准确的描述。例如query_database工具的描述应包括“此工具用于执行SQL查询返回数据库结果。输入应为包含‘sql’键的JSON对象。” LLM会根据这些描述来决定使用哪个工具。输入格式的标准化Action Input必须严格符合工具要求的输入格式。这通常需要在Agent框架中预先定义好工具的函数签名Function Calling。现在主流的LLM如GPT-4、Claude 3都原生支持函数调用这大大简化了Action的构建。错误处理的前瞻性在Thought阶段就应该让模型考虑到行动可能失败。例如“我将使用搜索工具但如果第一次搜索没有找到相关结果我会尝试更换关键词。”2.3 Observation观察世界的反馈Observation是环境或工具执行结果对Action的响应。它是对Thought和Action有效性的直接检验。Observation: 工具执行后返回的结果。这个结果可以是结构化的数据JSON也可以是一段文本、一个代码执行结果甚至是一个错误信息。关键设计要点结果格式化尽量让工具返回清晰、简洁的结果。过于冗长或杂乱的结果会干扰后续的Thought。例如数据库查询结果可以格式化为Markdown表格代码执行结果应包含成功/失败状态和输出。处理错误观察Observation可能包含错误如“工具调用超时”、“数据库连接失败”、“搜索无结果”。一个健壮的Agent其Thought环节必须能处理这些错误观察并制定备用计划。例如Observation: 搜索工具返回‘未找到相关结果’。接下来的Thought可能是Thought: 使用‘产品A 销量下降’作为关键词没有找到直接分析。可能这个问题比较内部。我需要换个思路尝试查询公司内部的客户投诉记录看看是否有产品相关的反馈激增。信息累积所有的Observation都会被添加到Agent的对话历史上下文中。这意味着随着循环进行上下文会越来越长。需要警惕上下文长度限制对于长任务可能需要设计摘要Summarization机制将过往的冗长观察提炼成关键信息点再喂给模型进行下一轮思考。这个Thought - Action - Observation的循环会一直进行下去直到LLM在Thought阶段生成一个特殊的结束标记比如Thought: 我已经完成了所有必要的步骤收集了足够的信息。现在我可以给出最终答案了。然后Agent会跳出循环进入最终的答案生成阶段。3. 实战构建手把手实现一个ReAct智能分析Agent理论讲得再多不如亲手实现一遍。我们以构建一个“智能业务分析助手”为例目标任务是“分析某电商品牌‘星辰科技’过去一个月在社交媒体上口碑变化的主要原因。”我们将使用LangChain框架因其生态成熟文档丰富和OpenAI的GPT-4模型来构建。选择GPT-4是因为它在复杂推理和遵循指令方面表现更稳定。你也可以用Claude 3或开源的DeepSeek等模型但提示词可能需要微调。3.1 环境准备与工具定义首先安装必要库并设置环境变量。pip install langchain langchain-openai langchain-communityimport os from langchain_openai import ChatOpenAI from langchain.agents import AgentExecutor, create_react_agent from langchain.tools import Tool from langchain.prompts import PromptTemplate # 假设我们有几个自定义的工具函数 from my_tools import search_web, query_social_media_api, analyze_sentiment # 1. 初始化LLM llm ChatOpenAI( modelgpt-4-turbo, temperature0, # 对于需要严谨推理的Agent温度设为0以保证稳定性 api_keyos.getenv(OPENAI_API_KEY) ) # 2. 定义工具 # 工具1网络搜索模拟 def web_search(query: str) - str: 执行一次网络搜索返回摘要结果。用于获取品牌新闻、行业报告等公开信息。 # 这里可以集成Serper API、Google Search API等真实服务 # 为演示我们返回模拟数据 mock_results { 星辰科技 近期 口碑: 近日科技媒体‘TechView’报道‘星辰科技’最新发布的Z3耳机因电池续航标注问题引发争议多名评测博主指出实际续航远低于宣传值。, 星辰科技 社交媒体 投诉: 在‘消费者之声’论坛上近两周关于‘星辰科技耳机’的投诉帖数量环比增加150%主要聚焦续航和充电故障。, 电子产品 口碑 影响因素: 行业分析指出产品实际性能与宣传不符是导致消费电子品牌口碑短期恶化的最主要原因占比约65%。 } return mock_results.get(query, f未找到关于‘{query}’的明确信息。) # 工具2社交媒体数据查询模拟 def fetch_social_media_posts(brand: str, days: int) - str: 获取指定品牌在过去N天内的社交媒体帖子数量模拟。 # 模拟数据返回帖子数量和情感趋势 data { (星辰科技, 30): { total_posts: 12500, negative_trend: 过去7天内负面及中性帖子占比从15%上升至40%。, top_topics: [续航虚假宣传, 充电盒故障, 客服响应慢] } } result data.get((brand, days)) if result: return f品牌‘{brand}’过去{days}天相关帖子共{result[total_posts]}条。趋势{result[negative_trend]} 主要讨论话题{, .join(result[top_topics])}. else: return 未获取到该时间段的数据。 # 工具3情感分析模拟 def sentiment_analysis(text: str) - str: 对一段文本进行情感分析返回正面、中性、负面的判断。 # 这里可以集成NLP情感分析模型如TextBlob、VADER或商用API negative_keywords [投诉, 故障, 虚假, 失望, 差评, 续航差] if any(kw in text for kw in negative_keywords): return 情感倾向负面 else: return 情感倾向中性或正面 # 将函数包装成LangChain Tool对象 tools [ Tool( nameWebSearch, funcweb_search, description当需要获取最新的公开新闻、行业报告或品牌相关的一般性信息时使用此工具。输入应为一个明确的搜索查询字符串。 ), Tool( nameSocialMediaQuery, funcfetch_social_media_posts, description当需要获取特定品牌在社交媒体上的声量、帖子数量变化趋势和热门话题时使用此工具。输入应为品牌名称字符串和天数整数的元组例如 (星辰科技, 30)。 ), Tool( nameSentimentAnalyzer, funcsentiment_analysis, description当需要对一段具体的文本内容如一条帖子、一篇报道的摘要进行情感倾向判断时使用此工具。输入应为一段文本字符串。 ) ]3.2 构建ReAct提示词与Agent这是最核心的一步。LangChain提供了create_react_agent函数它需要一个强大的提示词模板。这个模板会引导模型按照ReAct格式进行输出。# 3. 构建ReAct提示词模板 # 这是LangChain ReAct文档推荐的模板变体我们稍作调整以适应中文和我们的任务 react_prompt PromptTemplate.from_template( 你是一个专业的业务分析AI助手。请通过思考Thought、行动Action、观察Observation的循环来逐步解决用户问题。 你可以使用以下工具 {tools} 使用工具时请严格按照以下格式 Thought: 你需要思考当前情况并解释下一步行动的原因 Action: 要使用的工具名称必须是[{tool_names}]中的一个 Action Input: 工具的输入内容 在你得到工具的观察结果Observation后继续你的思考并决定下一步。 当你认为已经获得了足够的信息来最终回答用户的问题时请使用以下格式 Thought: 我已经完成了所有分析步骤。 Final Answer: [你的最终答案应清晰、有条理基于所有观察到的证据] 注意你的“Thought”部分应该展示你的推理链而不仅仅是描述行动。 开始 任务{input} 之前的历史交互如果有 {agent_scratchpad} ) # 4. 创建ReAct Agent agent create_react_agent(llm, tools, react_prompt) # 5. 创建Agent执行器 agent_executor AgentExecutor( agentagent, toolstools, verboseTrue, # 设为True可以打印出详细的思考过程调试时非常有用 handle_parsing_errorsTrue, # 处理模型输出格式错误 max_iterations10, # 防止无限循环设置最大迭代次数 early_stopping_methodgenerate # 当模型输出最终答案时停止 )3.3 运行与深度解析执行过程现在让我们运行这个Agent并仔细观察它的每一步。设置verboseTrue后控制台会打印出完整的ReAct循环日志。# 6. 执行任务 task 分析某电商品牌‘星辰科技’过去一个月在社交媒体上口碑变化的主要原因。 result agent_executor.invoke({input: task}) print(\n 最终答案 \n) print(result[output])预期的执行日志解析模拟 进入新的Agent执行链... Thought: 用户要求分析“星辰科技”过去一个月社交媒体口碑变化的原因。我首先需要了解近期是否有关于该品牌的重大事件或舆论。我应该从公开信息入手使用WebSearch工具进行搜索。 Action: WebSearch Action Input: “星辰科技 近期 口碑” Observation: 近日科技媒体‘TechView’报道‘星辰科技’最新发布的Z3耳机因电池续航标注问题引发争议多名评测博主指出实际续航远低于宣传值。 Thought: 搜索结果显示产品续航宣传问题可能是导火索。但这只是一个来源。我需要从社交媒体本身获取更直接的声量和情感数据来验证这个趋势。使用SocialMediaQuery工具获取过去30天的数据。 Action: SocialMediaQuery Action Input: (‘星辰科技’ 30) Observation: 品牌‘星辰科技’过去30天相关帖子共12500条。趋势过去7天内负面及中性帖子占比从15%上升至40%。 主要讨论话题续航虚假宣传充电盒故障客服响应慢。 Thought: 社交媒体数据证实了负面趋势的急剧上升且“续航虚假宣传”是核心话题这与网络搜索的发现一致。为了更具体地理解用户情绪我应该对搜索到的那篇报道摘要进行情感分析。 Action: SentimentAnalyzer Action Input: “近日科技媒体‘TechView’报道‘星辰科技’最新发布的Z3耳机因电池续航标注问题引发争议多名评测博主指出实际续航远低于宣传值。” Observation: 情感倾向负面 Thought: 报道的情感是负面的。现在我需要探究更深层的原因。续航标注问题是个具体产品问题但为什么会导致大范围口碑下滑这可能涉及行业共性问题或消费者预期管理。我可以用WebSearch搜索更一般的行业分析。 Action: WebSearch Action Input: “电子产品 口碑 影响因素” Observation: 行业分析指出产品实际性能与宣传不符是导致消费电子品牌口碑短期恶化的最主要原因占比约65%。 Thought: 行业分析支持了我的判断。现在我已经收集了多方证据1) 媒体报道的具体产品问题续航争议2) 社交媒体数据证实负面情绪飙升且话题聚焦3) 行业规律指出“宣传不符”是主因。这些信息足以形成一个有根据的分析。我可以给出最终答案了。 Final Answer: 根据多源信息分析“星辰科技”过去一个月社交媒体口碑恶化的主要原因如下 1. **直接导火索**其新品Z3耳机被科技媒体和评测博主曝光存在“电池续航实际表现远低于官方宣传”的问题引发了最初的争议。 2. **现象验证**社交媒体监测数据显示近一周内品牌相关负面及中性帖子占比从15%激增至40%讨论焦点高度集中于“续航虚假宣传”、“充电盒故障”等相关问题证实了负面舆论的扩散。 3. **根本原因**行业普遍规律表明“产品实际性能与宣传不符”是消费电子品牌口碑短期恶化的首要因素占比约65%。本次事件正是这一规律的典型体现。宣传与实际的落差直接导致了消费者信任受损并在社交媒体上迅速发酵。 综上所述本次口碑变化并非单一事件而是由具体产品问题触发并因触及“宣传失真”这一消费者敏感点在社交媒体时代被快速放大所导致的。通过这个详细的执行过程你可以清晰地看到Agent的“思考-行动-观察”循环第一轮思考需要背景信息 - 行动搜索- 观察发现续航争议。第二轮基于观察思考需要验证 - 行动查社交媒体数据- 观察确认负面趋势。第三轮思考需要具体情感佐证 - 行动情感分析- 观察负面。第四轮思考需要理论支撑 - 行动搜索行业规律- 观察找到依据。最终综合所有观察进行最终推理并输出答案。这个Agent展现出了自主的任务分解、信息验证和逻辑串联能力远胜于简单的工具调用。4. 超越基础ReAct模式的高级技巧与实战避坑指南当你成功跑通第一个ReAct Agent后兴奋之余很快就会遇到各种实际问题。下面分享一些从实战中总结的高级技巧和常见“坑位”。4.1 设计“聪明”的工具描述工具的描述description直接决定了LLM是否会以及如何正确使用它。一个糟糕的描述会导致模型误用工具。差描述“一个搜索工具。”好描述“当需要获取最新的公开新闻、行业报告、事实性信息或未知领域的概览时使用此工具。输入应为明确、具体的关键词查询字符串。对于已知的、内部的具体数据如已知订单号查询物流不应使用此工具。”好描述明确了使用场景、输入格式和使用边界。这能极大减少Agent的“胡思乱想”提高行动的有效性。4.2 处理复杂观察与上下文管理随着循环进行上下文会积累大量的Observation。GPT-4的上下文长度虽然长128K但并非无限且更长的上下文会增加成本和延迟有时甚至会降低模型对关键信息的注意力。解决方案摘要Summarization在每轮或每几轮循环后可以添加一个“摘要工具”或让LLM自己生成当前状态的摘要。例如在Observation之后增加一个步骤“请用一句话总结当前最关键的新发现。”然后将摘要而非原始冗长文本放入后续上下文。选择性记忆设计机制让Agent只记住关键事实和结论丢弃中间过程细节。这可以通过在提示词中强调来实现例如“在你的思考中请提炼并记住关键数据如‘负面帖子占比40%’无需复述整个观察文本。”分段执行对于超长任务可以将其拆分为多个子任务每个子任务用一个独立的Agent执行链处理最后再汇总。4.3 应对模型“死循环”与“偏航”这是ReAct模式最常见的两个故障模式。死循环Agent反复执行相同的或无效的Thought-Action-Observation无法推进。例如反复搜索同一个关键词。对策设置最大迭代次数如上面的max_iterations10这是最后的安全网。在提示词中加入反思指令例如“如果你的连续两次行动未能获得新的有效信息请重新评估你的策略尝试完全不同的方法。”丰富工具集提供更多样化的工具如分析工具、计算工具、不同的数据源查询工具给模型更多选择。偏航Agent的推理逐渐偏离核心任务。例如在分析“星辰科技”口碑时突然开始深入调研电池技术原理。对策强化系统提示词在提示词开头反复强调核心任务和目标。例如“你的核心任务是分析口碑变化的原因请始终围绕‘品牌’、‘社交媒体’、‘口碑’、‘原因’这些关键点展开不要深入与技术细节无关的领域。”在Thought阶段进行校验可以设计一个简单的校验机制比如让另一个轻量级模型或规则判断当前Thought是否与任务高度相关如果不相关则强制中断或引导回正轨。4.4 调试像侦探一样阅读思维链当Agent表现不如预期时verboseTrue输出的思维链Chain of Thought是你最好的调试工具。不要只看最终答案要一步步看Thought是否合理它的推理逻辑有没有漏洞是否基于了正确的ObservationAction选择是否正确它是否选对了工具输入参数是否合理Observation是否被正确理解下一轮Thought是否引用了上一轮Observation的关键信息通过分析思维链你可以精准定位问题是提示词描述不清是工具返回结果格式太乱导致模型无法理解还是模型本身的推理能力在某个环节不足然后针对性地优化。4.5 成本与延迟优化ReAct模式意味着多次调用LLM每次Thought都是一次调用和可能的外部工具调用API费用、数据库查询开销。成本使用gpt-4-turbo等高性能模型成本不低。对于复杂任务一次运行可能进行5-10轮循环相当于进行5-10次对话交互。优化建议对于推理能力要求不高的环节可以考虑使用更便宜的模型如gpt-3.5-turbo来承担部分工作或者设计更高效的提示词减少循环次数。延迟每次循环都涉及网络IO调用LLM API和工具API整体延迟是各步骤的累加。优化建议对于可以并行调用的工具如同时查询两个不依赖彼此结果的数据源可以探索异步或并行的Agent架构如LangGraph的并发节点。同时确保工具API本身响应迅速。从我实际运营多个生产级Agent的经验来看ReAct模式是构建复杂、可靠AI应用不可或缺的一环。它把LLM从“鹦鹉学舌”的文本生成器提升为了具备初步规划和解决问题能力的“智能体”。虽然它在开发和调试上比简单链式调用更复杂但为了处理现实世界中那些模糊、多变的复杂任务这份投入是绝对值得的。开始动手实现你的第一个ReAct Agent吧从一个小而具体的任务开始仔细观察它的“思考”过程你会对AI能力的边界有全新的认识。