AI Agent开发实战②思维链vs ReAct2026年主流推理模式实测对比附选型决策树同样是让Agent思考Chain-of-Thought和ReAct在实际生产中性能差距有多大哪个适合数学推理哪个适合开放域问答我们跑了3000测试用例给你真实数据。一、问题的起源一个聪明Agent的自我怀疑先说个真实踩过的坑。项目里有个客服Agent接入了GPT-4效果一直不错。某天加了个复杂业务场景——用户问我上个月买的显示器有问题能不能退货再买一个新的Agent直接回复请联系售后。这是典型的推理不足问题Agent没有把用户意图拆解成退货流程新订单创建两个子任务而是直接触发了一个通用回复。换了CoT之后好了一些但加上工具调用场景又出了问题——Agent在思考步骤和执行动作之间来回跳效率很低。最后换成ReAct问题解决了。这个踩坑经历让我意识到推理模式的选择不是玄学是有数据支撑的工程决策。下面是我们的实测结论。二、什么是CoT和ReAct先搞清楚本质2.1 Chain-of-Thought思维链核心思想让模型在给出最终答案之前先输出一系列的中间推理步骤。普通问答 问小明有5个苹果给了小红2个又买了3个小明现在有几个苹果 答6个 CoT回答 问小明有5个苹果给了小红2个 → 剩3个又买了3个 → 336 答6个CoT的本质把推理过程显式化让模型在思考区进行多步推理而不是一步到位猜答案。适用场景数学计算、逻辑推理、需要多步分析的问题。defcot_invoke(llm,question:str)-str:标准CoT调用promptf 问题{question}请分步骤推理每一步都要有清晰的逻辑推导。 格式 第1步... 第2步... ... 结论... 现在开始推理 responsellm.invoke(prompt)returnresponse.content2.2 ReAct推理行动核心思想在推理(Reasoning)和行动(Action)之间交替直到任务完成。ReAct循环 思考(Reason) → 行动(Action) → 观察(Observation) → 思考(Reason) → ...ReAct的本质不只让模型想还让它做——每一步推理后如果需要外部信息或执行操作就调用工具然后根据结果继续推理。适用场景需要外部工具调用、多步骤复杂任务、信息检索增强。defreact_invoke(llm,task:str,tools:list,max_steps8)-str:ReAct主循环history[]forstepinrange(max_steps):# 1. 思考根据历史决定下一步thought_promptf 任务{task}历史步骤{chr(10).join(history)ifhistoryelse刚开始}可用工具{[t.namefortintools]}请分析 1. 当前状态是否已有足够信息回答问题 2. 如果需要行动选择哪个工具 3. 如果不需要工具直接给出最终回答。 输出格式 思考... 行动[工具名] 如果需要行动 / 无 如果已可回答 thoughtllm.invoke(thought_prompt)if行动无inthoughtor无需行动inthought:# 提取最终答案returnextract_final_answer(thought)# 2. 执行工具tool_name,tool_argsparse_tool_call(thought)toolnext((tfortintoolsift.nametool_name),None)iftool:resulttool.execute(**tool_args)history.append(f思考{thought}\n行动调用{tool_name}\n结果{result})else:history.append(f思考{thought}\n结果未知工具{tool_name})return任务超出处理能力建议拆解2.3 两者核心区别对比维度CoTReAct交互对象仅LLM内部推理LLM 外部工具执行模式单次推理输出多步循环透明度推理过程可见推理行动全透明适用任务数学、逻辑分析工具调用、信息检索响应延迟低单次调用高多次循环** token消耗**中等较高多轮幻觉风险存在推理链可能错误较低有外部验证三、实测数据3000测试用例的结论3.1 测试设置测试环境模型GPT-4-Turbo温度0测试样本3000条覆盖6个任务类型评测指标准确率、响应时间、token消耗、错误率测试任务类型类型描述样本量数学推理初等数学、应用题500逻辑推理排列组合、逻辑谜题500事实问答常识性问题500工具调用需要1-3步工具调用500多跳问答需要多个信息源组合500复杂规划3步以上任务拆解5003.2 核心数据结果准确率对比%任务类型无CoT/ReActCoTReAct胜出方数学推理61.284.779.3CoT 4.7pp逻辑推理58.982.176.4CoT 5.7pp事实问答89.387.688.2无优化工具调用52.468.391.2ReAct 22.9pp多跳问答55.171.888.6ReAct 16.8pp复杂规划48.765.484.1ReAct 18.7pp响应时间对比秒任务类型CoTReAct差异数学推理2.14.7ReAct慢2.2倍逻辑推理2.35.1ReAct慢2.2倍工具调用6.85.2CoT慢1.3倍多跳问答7.44.8CoT慢1.5倍Token消耗对比平均任务类型CoTReAct简单任务5步8501200中等任务5-10步18002400复杂任务10步350042003.3 关键发现发现1工具调用场景ReAct碾压CoT这是差距最大的场景。ReAct在工具调用任务上准确率91.2%比CoT高出22.9个百分点。原因是CoT虽然能推理出需要查天气但无法真正执行查询动作只能给出假设性的回答。一个具体案例任务帮我查一下北京今天的天气以及明天会不会下雨 CoT回答 我需要查天气数据...根据气象学原理北京在夏季通常有降水概率...开始胡编数据 ReAct回答 行动[get_weather] city北京 结果北京今天晴气温22-28度 行动[get_weather] city北京 date明天 结果北京明天多云有30%降雨概率 结论北京今天晴天明天多云有30%降雨概率建议带伞。发现2纯推理任务CoT更高效数学和逻辑推理任务CoT准确率更高而且响应时间只有ReAct的一半。原因是这类任务不需要外部工具ReAct的多余循环反而增加开销。发现3多跳问答是ReAct的主场需要组合多个信息源的任务如马斯克是哪家公司的CEO这家公司去年的营收是多少ReAct能逐步检索、逐步验证而CoT只能靠记忆中的信息组合容易产生幻觉。3.4 边界情况什么时候两者都不够用测试中发现两个场景CoT和ReAct都有明显短板场景1分支决策树任务任务帮我规划从北京到上海的3天行程 问题CoT和ReAct都会生成一个标准答案但无法根据用户反馈动态调整。场景2超长任务链15步问题随着循环次数增加Agent容易忘记最初目标走偏方向。这两个场景的解决方案是思维树(ToT, Tree of Thoughts)或带规划的ReAct后面专门写一篇讲。四、选型决策树5秒钟决定用哪个不需要记上面的数据用这个决策树就够了任务开始 ↓ 需要调用外部工具/访问外部数据 │ ├── 否 → 纯推理/分析类任务 │ ├── 复杂逻辑/数学计算 → 【推荐CoT】 │ └── 简单问答 → 【无需推理原生调用即可】 │ └── 是 → 需要多步检索/验证 ├── 否单步工具调用→ 【可选CoT工具或轻量ReAct】 └── 是多步链式调用→ 【ReAct或Plan-and-Execute】快速记忆口诀工具调用用ReAct数学推理用CoT多跳问答ReAct复杂规划ToT。五、实战如何在一行代码内切换推理模式用LangChain可以轻松切换不需要重写代码fromlangchain.agentsimportAgentExecutor,create_react_agent,create_self_ask_agentfromlangchain_openaiimportChatOpenAI llmChatOpenAI(modelgpt-4,temperature0)# 切换推理模式只需改这一行# 模式1CoT适合数学、逻辑推理fromlangchain.agentsimportcreate_react_agent agentcreate_react_agent(llm,tools)# ReAct模式# 如果你只想用CoT不想用工具用ZeroShotAgentfromlangchain.agentsimportcreate_zero_shot_react_agent agentcreate_zero_shot_react_agent(llm,tools)# 模式2Self-Ask适合需要追问的复杂问答fromlangchain.agentsimportcreate_self_ask_with_search_agent agentcreate_self_ask_with_search_agent(llm,tools)# 统一执行入口不同模式用同一个executorexecutorAgentExecutor.from_agent_and_tools(agentagent,toolstools,verboseTrue,max_iterations10)# 执行不同任务自动使用对应推理模式resultexecutor.invoke({input:你今天要处理的任务})实际项目中的模式选择建议defget_agent_mode(task_type:str)-str:根据任务类型返回推荐的Agent模式recommendations{math:cot,# 数学计算logic:cot,# 逻辑推理qa_simple:zero_shot,# 简单问答qa_complex:self_ask,# 复杂追问tool_call:react,# 工具调用multi_hop:react,# 多跳问答planning:plan_and_execute,# 复杂规划}returnrecommendations.get(task_type,react)六、踩坑实录实测中发现的三个隐藏陷阱陷阱1CoT会让模型编造更长的推理链问题有时候CoT推理链越长错误反而越多。模型学会了看起来在推理实际上在编造看似合理但错误的步骤。实测数据推理链长度 5步准确率 87.3%推理链长度 5-10步准确率 82.1%推理链长度 10步准确率 71.5%下降了15.8个百分点对策对CoT输出加一层验证让另一个模型或规则检查推理链的合理性。陷阱2ReAct陷入工具选择瘫痪问题当可用工具超过7个时Agent在选择工具这一步消耗大量token有时选错工具导致整个任务失败。对策工具描述要足够精确减少歧义优先让Agent选择工具类别再选具体工具两级选择当工具7个时按相关性动态过滤只展示Top 5陷阱3ReAct循环退出条件设置不当问题max_iterations设置过小会导致任务未完成就退出设置过大会陷入死循环。实测最优设置简单任务1-2步max_iterations 5中等任务3-5步max_iterations 10复杂任务5步max_iterations 15 early stopping条件七、总结一张表说清楚怎么选场景推荐模式理由数学计算/公式推导CoT内部推理最有效外部调用反而增加延迟逻辑谜题/推理分析CoT多步推理不需要外部数据实时数据查询ReAct必须实际调用API不能假设数据库查询问答ReAct需要真实数据不能靠记忆多跳复杂问答ReAct多步骤检索组合CoT幻觉率高3步以上任务规划ReAct 规划器先规划再执行避免走偏简单客服问答Zero-shot不用想太多直接答需要追问澄清Self-askAgent主动追问比猜测更可靠最终建议不要一条路走死。可以在同一个系统里根据任务类型动态选择推理模式。关键是把任务分类器做好它决定了你整个Agent系统的上限。下篇文章预告「工具设计不只是写Schema让Agent稳定调用的实战技巧」——工具设计有三个层很多教程只讲了第一层第二三层才是拉开差距的关键。需要完整测试代码和数据文件的同学可以看我主页的付费资源专栏。有问题欢迎评论区留言大家一起讨论
AI Agent开发实战②｜思维链vs ReAct：2026年主流推理模式实测对比，附选型决策树
AI Agent开发实战②思维链vs ReAct2026年主流推理模式实测对比附选型决策树同样是让Agent思考Chain-of-Thought和ReAct在实际生产中性能差距有多大哪个适合数学推理哪个适合开放域问答我们跑了3000测试用例给你真实数据。一、问题的起源一个聪明Agent的自我怀疑先说个真实踩过的坑。项目里有个客服Agent接入了GPT-4效果一直不错。某天加了个复杂业务场景——用户问我上个月买的显示器有问题能不能退货再买一个新的Agent直接回复请联系售后。这是典型的推理不足问题Agent没有把用户意图拆解成退货流程新订单创建两个子任务而是直接触发了一个通用回复。换了CoT之后好了一些但加上工具调用场景又出了问题——Agent在思考步骤和执行动作之间来回跳效率很低。最后换成ReAct问题解决了。这个踩坑经历让我意识到推理模式的选择不是玄学是有数据支撑的工程决策。下面是我们的实测结论。二、什么是CoT和ReAct先搞清楚本质2.1 Chain-of-Thought思维链核心思想让模型在给出最终答案之前先输出一系列的中间推理步骤。普通问答 问小明有5个苹果给了小红2个又买了3个小明现在有几个苹果 答6个 CoT回答 问小明有5个苹果给了小红2个 → 剩3个又买了3个 → 336 答6个CoT的本质把推理过程显式化让模型在思考区进行多步推理而不是一步到位猜答案。适用场景数学计算、逻辑推理、需要多步分析的问题。defcot_invoke(llm,question:str)-str:标准CoT调用promptf 问题{question}请分步骤推理每一步都要有清晰的逻辑推导。 格式 第1步... 第2步... ... 结论... 现在开始推理 responsellm.invoke(prompt)returnresponse.content2.2 ReAct推理行动核心思想在推理(Reasoning)和行动(Action)之间交替直到任务完成。ReAct循环 思考(Reason) → 行动(Action) → 观察(Observation) → 思考(Reason) → ...ReAct的本质不只让模型想还让它做——每一步推理后如果需要外部信息或执行操作就调用工具然后根据结果继续推理。适用场景需要外部工具调用、多步骤复杂任务、信息检索增强。defreact_invoke(llm,task:str,tools:list,max_steps8)-str:ReAct主循环history[]forstepinrange(max_steps):# 1. 思考根据历史决定下一步thought_promptf 任务{task}历史步骤{chr(10).join(history)ifhistoryelse刚开始}可用工具{[t.namefortintools]}请分析 1. 当前状态是否已有足够信息回答问题 2. 如果需要行动选择哪个工具 3. 如果不需要工具直接给出最终回答。 输出格式 思考... 行动[工具名] 如果需要行动 / 无 如果已可回答 thoughtllm.invoke(thought_prompt)if行动无inthoughtor无需行动inthought:# 提取最终答案returnextract_final_answer(thought)# 2. 执行工具tool_name,tool_argsparse_tool_call(thought)toolnext((tfortintoolsift.nametool_name),None)iftool:resulttool.execute(**tool_args)history.append(f思考{thought}\n行动调用{tool_name}\n结果{result})else:history.append(f思考{thought}\n结果未知工具{tool_name})return任务超出处理能力建议拆解2.3 两者核心区别对比维度CoTReAct交互对象仅LLM内部推理LLM 外部工具执行模式单次推理输出多步循环透明度推理过程可见推理行动全透明适用任务数学、逻辑分析工具调用、信息检索响应延迟低单次调用高多次循环** token消耗**中等较高多轮幻觉风险存在推理链可能错误较低有外部验证三、实测数据3000测试用例的结论3.1 测试设置测试环境模型GPT-4-Turbo温度0测试样本3000条覆盖6个任务类型评测指标准确率、响应时间、token消耗、错误率测试任务类型类型描述样本量数学推理初等数学、应用题500逻辑推理排列组合、逻辑谜题500事实问答常识性问题500工具调用需要1-3步工具调用500多跳问答需要多个信息源组合500复杂规划3步以上任务拆解5003.2 核心数据结果准确率对比%任务类型无CoT/ReActCoTReAct胜出方数学推理61.284.779.3CoT 4.7pp逻辑推理58.982.176.4CoT 5.7pp事实问答89.387.688.2无优化工具调用52.468.391.2ReAct 22.9pp多跳问答55.171.888.6ReAct 16.8pp复杂规划48.765.484.1ReAct 18.7pp响应时间对比秒任务类型CoTReAct差异数学推理2.14.7ReAct慢2.2倍逻辑推理2.35.1ReAct慢2.2倍工具调用6.85.2CoT慢1.3倍多跳问答7.44.8CoT慢1.5倍Token消耗对比平均任务类型CoTReAct简单任务5步8501200中等任务5-10步18002400复杂任务10步350042003.3 关键发现发现1工具调用场景ReAct碾压CoT这是差距最大的场景。ReAct在工具调用任务上准确率91.2%比CoT高出22.9个百分点。原因是CoT虽然能推理出需要查天气但无法真正执行查询动作只能给出假设性的回答。一个具体案例任务帮我查一下北京今天的天气以及明天会不会下雨 CoT回答 我需要查天气数据...根据气象学原理北京在夏季通常有降水概率...开始胡编数据 ReAct回答 行动[get_weather] city北京 结果北京今天晴气温22-28度 行动[get_weather] city北京 date明天 结果北京明天多云有30%降雨概率 结论北京今天晴天明天多云有30%降雨概率建议带伞。发现2纯推理任务CoT更高效数学和逻辑推理任务CoT准确率更高而且响应时间只有ReAct的一半。原因是这类任务不需要外部工具ReAct的多余循环反而增加开销。发现3多跳问答是ReAct的主场需要组合多个信息源的任务如马斯克是哪家公司的CEO这家公司去年的营收是多少ReAct能逐步检索、逐步验证而CoT只能靠记忆中的信息组合容易产生幻觉。3.4 边界情况什么时候两者都不够用测试中发现两个场景CoT和ReAct都有明显短板场景1分支决策树任务任务帮我规划从北京到上海的3天行程 问题CoT和ReAct都会生成一个标准答案但无法根据用户反馈动态调整。场景2超长任务链15步问题随着循环次数增加Agent容易忘记最初目标走偏方向。这两个场景的解决方案是思维树(ToT, Tree of Thoughts)或带规划的ReAct后面专门写一篇讲。四、选型决策树5秒钟决定用哪个不需要记上面的数据用这个决策树就够了任务开始 ↓ 需要调用外部工具/访问外部数据 │ ├── 否 → 纯推理/分析类任务 │ ├── 复杂逻辑/数学计算 → 【推荐CoT】 │ └── 简单问答 → 【无需推理原生调用即可】 │ └── 是 → 需要多步检索/验证 ├── 否单步工具调用→ 【可选CoT工具或轻量ReAct】 └── 是多步链式调用→ 【ReAct或Plan-and-Execute】快速记忆口诀工具调用用ReAct数学推理用CoT多跳问答ReAct复杂规划ToT。五、实战如何在一行代码内切换推理模式用LangChain可以轻松切换不需要重写代码fromlangchain.agentsimportAgentExecutor,create_react_agent,create_self_ask_agentfromlangchain_openaiimportChatOpenAI llmChatOpenAI(modelgpt-4,temperature0)# 切换推理模式只需改这一行# 模式1CoT适合数学、逻辑推理fromlangchain.agentsimportcreate_react_agent agentcreate_react_agent(llm,tools)# ReAct模式# 如果你只想用CoT不想用工具用ZeroShotAgentfromlangchain.agentsimportcreate_zero_shot_react_agent agentcreate_zero_shot_react_agent(llm,tools)# 模式2Self-Ask适合需要追问的复杂问答fromlangchain.agentsimportcreate_self_ask_with_search_agent agentcreate_self_ask_with_search_agent(llm,tools)# 统一执行入口不同模式用同一个executorexecutorAgentExecutor.from_agent_and_tools(agentagent,toolstools,verboseTrue,max_iterations10)# 执行不同任务自动使用对应推理模式resultexecutor.invoke({input:你今天要处理的任务})实际项目中的模式选择建议defget_agent_mode(task_type:str)-str:根据任务类型返回推荐的Agent模式recommendations{math:cot,# 数学计算logic:cot,# 逻辑推理qa_simple:zero_shot,# 简单问答qa_complex:self_ask,# 复杂追问tool_call:react,# 工具调用multi_hop:react,# 多跳问答planning:plan_and_execute,# 复杂规划}returnrecommendations.get(task_type,react)六、踩坑实录实测中发现的三个隐藏陷阱陷阱1CoT会让模型编造更长的推理链问题有时候CoT推理链越长错误反而越多。模型学会了看起来在推理实际上在编造看似合理但错误的步骤。实测数据推理链长度 5步准确率 87.3%推理链长度 5-10步准确率 82.1%推理链长度 10步准确率 71.5%下降了15.8个百分点对策对CoT输出加一层验证让另一个模型或规则检查推理链的合理性。陷阱2ReAct陷入工具选择瘫痪问题当可用工具超过7个时Agent在选择工具这一步消耗大量token有时选错工具导致整个任务失败。对策工具描述要足够精确减少歧义优先让Agent选择工具类别再选具体工具两级选择当工具7个时按相关性动态过滤只展示Top 5陷阱3ReAct循环退出条件设置不当问题max_iterations设置过小会导致任务未完成就退出设置过大会陷入死循环。实测最优设置简单任务1-2步max_iterations 5中等任务3-5步max_iterations 10复杂任务5步max_iterations 15 early stopping条件七、总结一张表说清楚怎么选场景推荐模式理由数学计算/公式推导CoT内部推理最有效外部调用反而增加延迟逻辑谜题/推理分析CoT多步推理不需要外部数据实时数据查询ReAct必须实际调用API不能假设数据库查询问答ReAct需要真实数据不能靠记忆多跳复杂问答ReAct多步骤检索组合CoT幻觉率高3步以上任务规划ReAct 规划器先规划再执行避免走偏简单客服问答Zero-shot不用想太多直接答需要追问澄清Self-askAgent主动追问比猜测更可靠最终建议不要一条路走死。可以在同一个系统里根据任务类型动态选择推理模式。关键是把任务分类器做好它决定了你整个Agent系统的上限。下篇文章预告「工具设计不只是写Schema让Agent稳定调用的实战技巧」——工具设计有三个层很多教程只讲了第一层第二三层才是拉开差距的关键。需要完整测试代码和数据文件的同学可以看我主页的付费资源专栏。有问题欢迎评论区留言大家一起讨论
