---

第一部分：引言与基础 (Introduction & Foundation)

---

1. 引人注目的标题 (Compelling Title)

主标题： 从 ReAct 到 Plan-and-Solve：Agent 推理模式的效率对比与选型指南
副标题： 拆解推理策略、构建Benchmark系统、量化分析性能差，帮你的AI Agent选对「大脑回路」

---

2. 摘要/引言 (Abstract / Introduction)

想象一下：你正在开发一个AI编程助手Agent，它需要根据用户的一句模糊需求（“帮我写一个能统计Python文件所有类和函数的脚本”），完成思考、查文档、写代码、调错误、测试结果这一系列动作。如果Agent的「大脑回路」是瞎猫碰死耗子式的随机调用工具，那它可能要试几十次才写出能用的代码；如果是纯大模型推理（CoT，Chain of Thought），它会把步骤想清楚，但一涉及真实工具调用（比如ast库的语法检查）就容易“纸上谈兵”出错；如果是经典的ReAct（Reasoning + Acting），它会想一步、做一步、再反思，虽然稳但慢得让人挠头；而如果是Plan-and-Solve（PaS）或更高级的PaS+Prompting，它会不会先搭好「完整的任务蓝图」再一步步「精准施工」，既稳又快？

这就是本文要解决的核心问题： 在LLM驱动的通用任务Agent中，不同的推理模式（Reasoning Paradigms） 对任务完成率、推理效率（时间/步数/Token消耗）、错误率 等关键指标的影响到底有多大？我们应该如何根据任务类型、资源限制、精度要求为Agent选型？

本文的核心方案与成果：

1. 概念体系重构与深度解析：不仅仅是罗列“CoT、ReAct、PaS”这几个名词，而是从「推理阶段的划分」「工具调用的触发时机」「信息的整合方式」「决策的粒度大小」这四个维度，建立一个通用的Agent推理模式分类框架；
2. 可复现的Benchmark系统构建：使用LangChain作为Agent编排框架，Gradio作为可视化界面，Python+SQLite作为数据存储，构建一套支持多任务类型（代码生成、数学问题、Web搜索问答、多跳知识推理）、多LLM模型（GPT-3.5-Turbo-16k、GPT-4o-mini、Claude 3 Haiku）、多推理模式（纯CoT、CoT+Reflection、ReAct、PaS、PaS+Reflection）、可自定义参数（温度、工具限制、思考次数）的自动化测试与可视化分析系统；
3. 量化分析与结论提炼：基于超过2000次的自动化测试，对比不同推理模式在不同任务、不同模型下的表现差异，给出有数据支撑的选型建议；
4. 落地实践与优化方向：分享在真实项目中应用这些推理模式的经验，以及如何通过Prompt工程、工具链优化、子任务拆分等手段进一步提升效率。

本文的组织结构：我们将从基础概念讲起，先帮你建立对Agent推理模式的清晰认知；然后带你一步步搭建Benchmark系统；接着进行深入的量化对比分析；最后给出选型指南、落地实践和未来展望。

---

3. 目标读者与前置知识 (Target Audience & Prerequisites)

目标读者：

• 有一定Python编程基础（能编写简单的脚本、使用第三方库）的开发者；
• 对大语言模型（LLM）基础概念（比如Token、上下文窗口、Prompt Engineering、温度参数）有初步了解；
• 对LLM驱动的Agent（比如AutoGPT、LangChain Agent、CrewAI）有好奇心，或者正在开发/维护相关项目；
• 希望通过量化分析而非主观感觉为自己的Agent选择合适的推理策略。

前置知识（必备）：

1. Python 3.8+ 编程；
2. 了解LLM的基本工作原理（至少知道什么是“生成式预训练”和“推理”）；
3. 熟悉Git/GitHub的基本操作（用于克隆本文的代码仓库）；
4. 拥有一个或多个LLM API Key（OpenAI GPT系列、Anthropic Claude系列均可，本文主要使用OpenAI）。

前置知识（加分，但不强制）：

1. 了解Prompt Engineering的基本技巧（比如Few-Shot Prompting、Zero-Shot CoT）；
2. 用过LangChain（至少知道LangChain的Agent、Tools、LLM Chain这几个核心组件）；
3. 了解数据库的基本操作（本文使用SQLite存储测试数据）；
4. 了解数据可视化的基本概念（本文使用Matplotlib、Seaborn、Plotly绘制图表）。

---

4. 文章目录 (Table of Contents)

由于本文内容非常丰富，我们先列出详细的目录，方便你快速导航到感兴趣的部分：

---

第一部分：引言与基础 (Introduction & Foundation)

1. 引人注目的标题
2. 摘要/引言
3. 目标读者与前置知识
4. 文章目录

---

第二部分：核心概念与理论基础 (Core Concepts & Theoretical Foundation)

5. 问题背景与动机
   5.1 LLM Agent的崛起与“推理效率焦虑”
   5.2 现有Agent推理模式的局限性与误区
   5.3 为什么我们需要一套量化的、可复现的推理模式对比体系？
6. LLM Agent的核心组成与推理流程抽象
   6.1 LLM Agent的“通用四元组模型”
   6.2 推理流程的“端到端抽象”：从“输入需求”到“输出结果”
7. 本文提出的Agent推理模式分类框架
   7.1 分类维度一：推理阶段的划分（单阶段/两阶段/多阶段）
   7.2 分类维度二：工具调用的触发时机（纯推理/按需触发/强制触发）
   7.3 分类维度三：信息的整合方式（局部整合/全局整合/混合整合）
   7.4 分类维度四：决策的粒度大小（原子级决策/子任务级决策/混合粒度决策）
8. 主流推理模式的深度解析与数学建模
   8.1 纯思考（Zero-Shot/One-Shot/Few-Shot CoT）：无工具依赖的单阶段推理
   8.1.1 核心概念
   8.1.2 问题背景
   8.1.3 问题解决
   8.1.4 边界与外延
   8.1.5 数学模型
   8.1.6 算法流程图（Mermaid）
   8.1.7 伪代码/简化实现
   8.2 反思型思考（CoT+Reflection）：两阶段纯推理
   8.2.1 核心概念
   8.2.2 问题背景
   8.2.3 问题解决
   8.2.4 边界与外延
   8.2.5 数学模型
   8.2.6 算法流程图（Mermaid）
   8.2.7 伪代码/简化实现
   8.3 经典ReAct（Reasoning + Acting）：单阶段混合粒度推理
   8.3.1 核心概念
   8.3.2 问题背景
   8.3.3 问题解决
   8.3.4 边界与外延
   8.3.5 概念结构与核心要素组成
   8.3.6 数学模型
   8.3.7 算法流程图（Mermaid）
   8.3.8 伪代码/简化实现
   8.4 Plan-and-Solve（PaS）：两阶段子任务级推理
   8.4.1 核心概念
   8.4.2 问题背景
   8.4.3 问题解决
   8.4.4 边界与外延
   8.4.5 概念结构与核心要素组成
   8.4.6 数学模型
   8.4.7 算法流程图（Mermaid）
   8.4.8 伪代码/简化实现
   8.5 Plan-and-Solve+Reflection（PaS+Reflection）：三阶段混合粒度推理
   8.5.1 核心概念
   8.5.2 问题背景
   8.5.3 问题解决
   8.5.4 边界与外延
   8.5.5 数学模型
   8.5.6 算法流程图（Mermaid）
   8.5.7 伪代码/简化实现
9. 主流推理模式的核心属性维度对比与ER实体关系图
   9.1 核心属性维度对比（Markdown表格）
   9.2 ER实体关系图（Mermaid）
   9.3 交互关系图（Mermaid）

---

第三部分：Benchmark系统的环境准备与分步实现 (Benchmark Environment Setup & Step-by-Step Implementation)

10. Benchmark系统的设计目标与整体架构
    10.1 设计目标
    10.2 技术选型理由
    10.3 整体架构图（Mermaid）
11. 环境准备
    11.1 硬件要求
    11.2 软件要求
    11.3 依赖库安装与版本控制
    11.4 API Key的配置与安全管理
    11.5 项目结构初始化
12. 测试数据集的构建与选择
    12.1 测试任务类型的选择原则
    12.2 公开数据集的筛选与适配
    12.3 自定义测试数据集的构建
    12.4 测试数据的格式定义
13. 核心组件的分步实现
    13.1 通用LLM封装组件（支持多模型切换）
    13.2 通用工具封装组件（代码执行、Web搜索、知识检索、数学计算）
    13.3 主流推理模式的LangChain实现
    13.3.1 纯CoT Agent
    13.3.2 CoT+Reflection Agent
    13.3.3 ReAct Agent
    13.3.4 Plan-and-Solve Agent
    13.3.5 Plan-and-Solve+Reflection Agent
    13.4 测试执行引擎（支持批量测试、单步测试、自定义参数测试）
    13.5 数据存储与分析组件（SQLite存储、数据清洗、统计分析）
    13.6 可视化交互界面（Gradio实现，支持参数配置、任务选择、结果展示、图表分析）
14. 关键代码解析与深度剖析
    14.1 通用LLM封装组件的异常处理与重试机制
    14.2 Plan-and-Solve Agent的“子任务动态调整”逻辑
    14.3 测试执行引擎的“并发控制”与“资源限制”
    14.4 数据可视化组件的“性能优化”与“图表多样性”

---

第四部分：验证与量化对比分析 (Verification & Quantitative Comparison Analysis)

15. 结果展示与验证
    15.1 系统功能验证
    15.2 测试数据的预处理与质量检查
    15.3 单次测试的结果示例
    15.4 批量测试的初始结果展示
16. 量化指标的定义与计算方法
    16.1 核心指标（任务完成率、推理时间、总步数、总Token消耗、每步Token消耗、成功率/时间比、成功率/Token比）
    16.2 辅助指标（错误率类型分布、工具调用次数分布、子任务拆分准确率、反思修正率）
    16.3 指标的归一化与综合评分方法
17. 不同推理模式在不同维度下的量化对比分析
    17.1 任务类型维度的对比分析（代码生成、数学问题、Web搜索问答、多跳知识推理）
    17.2 LLM模型维度的对比分析（GPT-3.5-Turbo-16k、GPT-4o-mini、Claude 3 Haiku）
    17.3 温度参数维度的对比分析（0.0、0.3、0.7、1.0）
    17.4 任务复杂度维度的对比分析（低复杂度、中复杂度、高复杂度）
    17.5 综合评分维度的对比分析
18. 关键发现与结论提炼
    18.1 纯推理模式（CoT、CoT+Reflection）的适用场景
    18.2 混合推理模式（ReAct、PaS、PaS+Reflection）的适用场景
    18.3 任务复杂度与推理模式的匹配关系
    18.4 LLM模型能力与推理模式的匹配关系
    18.5 资源限制（时间、Token）与推理模式的匹配关系

---

第五部分：落地实践与优化方向 (Real-World Application & Optimization Directions)

19. 落地实践：如何在真实项目中应用这些推理模式
    19.1 实践案例一：AI编程助手Agent的推理模式选型
    19.2 实践案例二：企业级知识问答Agent的推理模式优化
    19.3 实践案例三：多Agent协作系统中的推理模式分配
20. 最佳实践Tips
    20.1 Prompt工程的最佳实践
    20.2 工具链优化的最佳实践
    20.3 子任务拆分的最佳实践
    20.4 异常处理与重试机制的最佳实践
21. 常见问题与解决方案 (FAQ / Troubleshooting)
    21.1 通用问题
    21.2 Benchmark系统相关问题
    21.3 推理模式实现相关问题
22. 行业发展与未来趋势
    22.1 Agent推理模式的演变发展历史（Markdown表格）
    22.2 最新的推理模式研究进展（Self-Improving Agents、Tree of Thoughts、Graph of Thoughts）
    22.3 未来的推理模式发展方向
    22.4 对Agent开发者的建议

---

第六部分：总结与附录 (Conclusion & Appendix)

23. 总结
24. 参考资料
25. 附录
    25.1 完整的GitHub代码仓库链接
    25.2 完整的测试数据集链接
    25.3 完整的配置文件示例
    25.4 额外的量化分析图表
    25.5 更多的推理模式实现（Tree of Thoughts、Graph of Thoughts简化版）

---

第二部分：核心概念与理论基础 (Core Concepts & Theoretical Foundation)

---

5. 问题背景与动机

5.1 LLM Agent的崛起与“推理效率焦虑”

在过去的两年里，大语言模型（LLM）驱动的自主Agent无疑是人工智能领域最热门的话题之一。从最早爆火的AutoGPT、BabyAGI，到后来出现的CrewAI、LangChain Agent、Microsoft AutoGen，再到现在结合了多模态能力的GPT-4o Agent、Claude 3 Opus Agent，LLM Agent已经从“实验室玩具”逐渐走向了“工业级应用”——它们可以帮用户写代码、查资料、订机票、管理日程、生成报告、甚至完成复杂的科学研究辅助任务。

然而，随着LLM Agent应用场景的不断拓展，一个非常现实且棘手的问题逐渐浮出水面：推理效率太低了！

这里的“推理效率”不仅仅指“完成一个任务需要多长时间”，还包括“完成一个任务需要消耗多少LLM Token（这直接关系到成本）”、“完成一个任务需要调用多少次工具（这直接关系到系统的稳定性和延迟）”、“完成一个任务的准确率有多高（这直接关系到用户体验）”。

举几个真实的例子：

1. AutoGPT在写一个简单的Python爬虫脚本时：可能会先思考“我需要用什么库？requests？BeautifulSoup？Selenium？”，然后调用一次“搜索Python爬虫最佳实践”的工具，接着又思考“我应该用BeautifulSoup，因为它更轻量”，然后又调用一次“搜索BeautifulSoup的官方文档”的工具，接着又思考“我需要先获取网页的HTML内容，然后解析它，然后提取我需要的信息”，然后又试着写一段代码，接着调用一次“代码执行工具”发现报错，然后又反思“哦，我忘记导入requests库了”，然后又修改代码，再执行一次……整个过程可能需要10-20分钟，消耗几千甚至上万Token，而且如果LLM在某一步犯了错误（比如提取了错误的HTML标签），整个过程可能会陷入死循环，最后直接失败。
2. 一个企业级的多跳知识问答Agent在回答“2023年华为Mate 60 Pro的销量与苹果iPhone 15 Pro Max的销量相比，哪个更高？高多少？”这个问题时：如果用纯ReAct模式，它可能会先调用一次“搜索华为Mate 60 Pro 2023年销量”的工具，得到一个结果，然后调用一次“搜索苹果iPhone 15 Pro Max 2023年销量”的工具，得到另一个结果，然后再调用一次“数学计算工具”计算差值，最后给出答案——这个过程虽然稳，但可能需要3-5次工具调用，消耗几千Token，而且如果两次搜索的结果来源不同（比如一个是IDC的数据，一个是Counterpoint的数据），LLM可能还需要再调用一次工具来验证数据的准确性，整个过程的效率会更低。
3. 一个学生用AI数学助手Agent做一道高中数学竞赛题时：如果用纯CoT模式，LLM可能会把步骤想清楚，但如果涉及到一些特殊的数学公式或者定理，LLM可能会记错（比如记错了三角函数的和差化积公式），导致整个答案错误；如果用CoT+Reflection模式，LLM可能会先给出一个答案，然后再反思自己的步骤有没有问题，但是如果Reflection的Prompt写得不好，LLM可能还是发现不了错误；如果用ReAct模式，LLM可能会调用一次“数学公式查询工具”来验证公式，然后再继续思考，虽然准确率提高了，但效率也降低了。

正是因为这些真实的痛点，Agent推理模式的效率对比与选型已经成为了每一个Agent开发者都必须面对的问题。

---

5.2 现有Agent推理模式的局限性与误区

目前，虽然已经有很多关于LLM Agent推理模式的研究（比如Google的ReAct论文、Microsoft的Plan-and-Solve论文、Meta的Tree of Thoughts论文），也有很多开源的Agent框架（比如LangChain、CrewAI、AutoGen）支持不同的推理模式，但是现有的研究和框架都存在一些局限性和误区：

现有研究的局限性

1. 测试数据集单一：很多研究只在某一个特定的测试数据集上验证自己的推理模式（比如ReAct论文主要在HotpotQA、WebShop、ALFWorld这三个数据集上验证），而没有在多个不同类型的测试数据集上进行对比，导致结论的普适性不强。
2. 量化指标不全面：很多研究只关注“任务完成率”这一个指标，而忽略了“推理时间”、“Token消耗”、“工具调用次数”等同样重要的指标，导致结论的实用性不强。
3. LLM模型选择单一：很多研究只使用某一个特定的LLM模型（比如ReAct论文使用GPT-3.5-Turbo，Plan-and-Solve论文使用GPT-4），而没有在多个不同能力、不同价格的LLM模型上进行对比，导致结论的参考价值有限。
4. 没有可复现的Benchmark系统：很多研究虽然公布了自己的测试结果，但没有公布完整的测试代码和测试数据集，导致其他研究者或开发者很难复现他们的结果，也很难在此基础上进行进一步的研究。

现有开源框架的局限性

1. 推理模式的实现不够灵活：很多开源框架（比如LangChain的早期版本）只支持固定的几种推理模式，而不支持开发者自定义推理模式的参数（比如ReAct的思考次数、PaS的子任务拆分粒度）。
2. 推理模式的性能优化不够：很多开源框架的推理模式实现没有考虑到性能优化（比如没有对Prompt进行压缩、没有对工具调用进行批量处理、没有对LLM的输出进行缓存），导致实际使用时的效率很低。
3. 缺乏量化分析与可视化功能：很多开源框架只支持Agent的执行，而不支持对Agent的执行过程和结果进行量化分析与可视化，导致开发者很难了解自己的Agent在哪些方面表现好，在哪些方面表现不好，也很难进行针对性的优化。

现有Agent开发者的常见误区

1. 盲目追求“最先进”的推理模式：很多Agent开发者一看到有新的推理模式论文发表（比如Tree of Thoughts、Graph of Thoughts），就立刻在自己的项目中使用，而没有考虑到自己的任务类型、资源限制、精度要求是否适合这种推理模式——事实上，很多时候，经典的ReAct或PaS模式已经足够满足需求，而且效率更高、成本更低。
2. 认为“推理模式越复杂越好”：很多Agent开发者认为，推理模式的阶段越多（比如三阶段、四阶段）、决策的粒度越细（比如原子级决策）、反思的次数越多（比如三次、四次），Agent的表现就会越好——但事实并非如此，复杂的推理模式不仅会增加推理时间和Token消耗，还可能会因为LLM在某一阶段犯了错误而导致整个任务失败（比如PaS模式的子任务拆分阶段如果犯了错误，后面的执行阶段即使做得再好也没用）。
3. 忽略了Prompt工程的重要性：很多Agent开发者认为，只要选对了推理模式，Agent的表现就会好——但事实并非如此，Prompt工程是LLM Agent开发中最重要的环节之一，一个好的Prompt可以让即使是最简单的CoT模式的表现也超过一个差的Prompt的最复杂的推理模式的表现。

---

5.3 为什么我们需要一套量化的、可复现的推理模式对比体系？

正是因为现有研究、开源框架和开发者都存在这些局限性和误区，所以我们迫切需要一套量化的、可复现的Agent推理模式对比体系，这套体系应该具备以下几个特点：

1. 多维度的测试：支持在多个不同类型的测试任务、多个不同能力的LLM模型、多个不同的参数（比如温度、工具限制、思考次数）下进行测试；
2. 全面的量化指标：不仅关注“任务完成率”，还关注“推理时间”、“Token消耗”、“工具调用次数”、“错误率类型分布”等同样重要的指标；
3. 可复现的结果：公布完整的测试代码、测试数据集、配置文件，让其他研究者或开发者可以轻松复现测试结果；
4. 可视化的分析：提供可视化的交互界面，让开发者可以直观地看到不同推理模式在不同维度下的表现差异；
5. 可扩展的架构：支持开发者轻松添加新的测试任务、新的LLM模型、新的推理模式，以便在此基础上进行进一步的研究。

本文的核心目标之一，就是构建这样一套对比体系，并基于这套体系进行深入的量化对比分析，为Agent开发者提供有数据支撑的选型建议。

---

6. LLM Agent的核心组成与推理流程抽象

在深入讲解不同的推理模式之前，我们需要先建立一个对LLM Agent的通用认知，包括它的核心组成和推理流程的抽象。

---

6.1 LLM Agent的“通用四元组模型”

虽然不同的LLM Agent在功能和实现上可能千差万别，但它们的核心组成是基本相同的——我们可以用一个通用四元组模型来表示：

$$\text{Agent}=⟨\text{LLM Core},\text{Tools},\text{Memory},\text{Reasoning Engine}⟩$$

下面我们逐一解释这四个核心组成部分：

1. LLM Core（大语言模型核心）

LLM Core是Agent的“大脑”，它负责接收输入信息、进行思考、生成决策、输出结果。LLM Core的能力（比如理解能力、推理能力、生成能力、知识储备）直接决定了Agent的上限。

常见的LLM Core包括：

• OpenAI GPT系列（GPT-3.5-Turbo、GPT-4o-mini、GPT-4o、GPT-4 Turbo）；
• Anthropic Claude系列（Claude 3 Haiku、Claude 3 Sonnet、Claude 3 Opus）；
• Google Gemini系列（Gemini 1.5 Flash、Gemini 1.5 Pro）；
• Meta Llama系列（Llama 3 8B/70B、Llama 3.1 8B/70B/405B）；
• 国内的开源/闭源LLM（比如通义千问、文心一言、智谱GLM、DeepSeek）。

2. Tools（工具集）

Tools是Agent的“手脚”，它负责执行LLM Core生成的决策，与外部环境进行交互。因为LLM Core本身存在一些局限性（比如知识截止日期、无法访问实时信息、无法执行代码、无法处理多模态数据），所以Tools对于Agent来说是至关重要的——没有Tools，Agent就只能是一个“纸上谈兵”的纯聊天机器人。

常见的Tools包括：

• 信息检索类：Web搜索（比如Google Search、Bing Search、Tavily Search）、知识库检索（比如基于Chroma、Pinecone、Weaviate的向量检索）、数据库查询（比如SQL查询、NoSQL查询）；
• 操作执行类：代码执行（比如Python REPL、Jupyter Notebook）、文件操作（比如读取文件、写入文件、删除文件）、API调用（比如调用天气预报API、调用机票预订API）；
• 辅助计算类：数学计算（比如Wolfram Alpha、Python math库）、单位转换、日期计算；
• 多模态处理类：图像识别（比如GPT-4o Vision、Claude 3 Vision）、图像生成（比如DALL-E 3、Midjourney）、语音识别（比如Whisper）、语音合成（比如TTS）。

3. Memory（记忆系统）

Memory是Agent的“记忆”，它负责存储Agent的历史信息（比如用户的历史对话、之前的思考过程、工具调用的结果），以便LLM Core可以根据历史信息进行更好的决策。因为LLM Core的上下文窗口是有限的（比如GPT-3.5-Turbo-16k的上下文窗口是16k Token，GPT-4o的上下文窗口是128k Token），所以Memory对于处理长任务、多轮对话的Agent来说是至关重要的。

Memory可以分为以下几种类型：

• Short-Term Memory（短期记忆）：也叫“上下文记忆”，它存储的是Agent最近的几次对话或执行过程，通常直接存储在LLM Core的上下文窗口中；
• Long-Term Memory（长期记忆）：它存储的是Agent的所有历史信息，通常存储在外部数据库（比如向量数据库、关系型数据库）中，当LLM Core需要时，通过检索的方式提取相关信息；
• Working Memory（工作记忆）：也叫“任务记忆”，它存储的是Agent当前正在执行的任务的相关信息（比如任务目标、当前的进度、子任务列表），通常存储在内存中。

4. Reasoning Engine（推理引擎）

Reasoning Engine是Agent的“神经中枢”，它负责编排LLM Core、Tools、Memory这三个核心组成部分的工作流程——也就是我们本文要重点讨论的推理模式。Reasoning Engine决定了Agent“如何思考”、“何时调用工具”、“如何整合信息”、“如何调整策略”。

不同的Reasoning Engine对应不同的推理模式，比如：

• 纯CoT模式的Reasoning Engine只调用LLM Core，不调用Tools；
• ReAct模式的Reasoning Engine会交替调用LLM Core和Tools；
• PaS模式的Reasoning Engine会先调用LLM Core生成子任务列表，然后再依次调用LLM Core和Tools执行每个子任务。

---

6.2 推理流程的“端到端抽象”：从“输入需求”到“输出结果”

为了方便后续对不同推理模式的对比分析，我们可以将Agent的端到端推理流程抽象为以下几个步骤：

下面我们逐一解释这些抽象步骤：

1. 输入需求（Input）

输入需求是Agent推理的起点，它可以是用户的一句自然语言指令（比如“帮我写一个能统计Python文件所有类和函数的脚本”），也可以是一个结构化的任务描述（比如JSON格式的任务目标、约束条件、输出格式）。

2. 推理模式决策（Reasoning Decision）

在一些高级的Agent系统中，会有一个“推理模式决策器”，它会根据输入需求的类型（比如纯文本问答、代码生成、多跳知识推理）、复杂度（比如低复杂度、中复杂度、高复杂度）、资源限制（比如时间限制、Token限制）自动选择合适的推理模式。不过，在大多数普通的Agent系统中，推理模式是预先固定的。

3. 纯思考阶段（Pure Reasoning）

在纯思考阶段，Agent只调用LLM Core，不调用任何Tools——LLM Core会根据输入需求和Memory中的历史信息，直接进行思考并生成结果。纯思考阶段的典型代表是Zero-Shot CoT、Few-Shot CoT。

4. 思考-执行循环（Reasoning-Acting Loop）

在思考-执行循环阶段，Agent会交替调用LLM Core和Tools：

1. 首先，LLM Core根据输入需求、Memory中的历史信息、之前的工具调用结果进行思考，生成下一步的决策（比如“调用Web搜索工具搜索‘BeautifulSoup官方文档’”）；
2. 然后，Agent根据LLM Core生成的决策调用相应的Tools；
3. 接着，Tools将执行结果返回给Agent；
4. 最后，Agent将执行结果存储到Memory中，并回到第一步，直到LLM Core认为任务已经完成，或者达到了最大的循环次数。

思考-执行循环阶段的典型代表是经典的ReAct模式。

5. 规划阶段（Planning）

在规划阶段，Agent会先调用LLM Core，根据输入需求和Memory中的历史信息，生成一个完整的子任务列表（也叫“任务蓝图”），每个子任务都有明确的目标、输入、输出、可能用到的Tools。规划阶段的典型代表是Plan-and-Solve模式。

6. 子任务执行阶段（Subtask Execution）

在子任务执行阶段，Agent会依次执行规划阶段生成的每个子任务——对于每个子任务，Agent可以使用纯思考模式，也可以使用思考-执行循环模式。

7. 反思/调整阶段（Reflection/Adjustment）

在反思/调整阶段，Agent会调用LLM Core，根据子任务执行阶段的结果，反思自己的规划是否合理、子任务的执行是否正确、是否需要调整子任务列表、是否需要重新执行某些子任务。反思/调整阶段的典型代表是CoT+Reflection、PaS+Reflection模式。

8. 结果验证与输出（Result Verification & Output）

在结果验证与输出阶段，Agent会调用LLM Core（或者专门的验证工具），验证最终的结果是否满足输入需求的要求——如果满足，就将结果以指定的格式输出；如果不满足，就回到反思/调整阶段，或者直接输出一个错误信息。

9. 输出结果（Output）

输出结果是Agent推理的终点，它可以是一句自然语言回答，也可以是一个结构化的结果（比如JSON格式的答案、生成的代码文件、统计图表）。

---

7. 本文提出的Agent推理模式分类框架

在现有的研究中，Agent推理模式的分类通常比较混乱——有的研究按“是否使用工具”分类，有的研究按“推理阶段的数量”分类，有的研究按“决策的粒度”分类。为了方便后续的对比分析，我们提出了一个基于四个维度的通用Agent推理模式分类框架：

---

7.1 分类维度一：推理阶段的划分（单阶段/两阶段/多阶段）

这个维度指的是Agent的推理流程被划分为几个相对独立的阶段：

• 单阶段推理（Single-Stage Reasoning）：Agent的推理流程只有一个阶段——要么是纯思考阶段（比如Zero-Shot CoT），要么是思考-执行循环阶段（比如经典的ReAct）；
• 两阶段推理（Two-Stage Reasoning）：Agent的推理流程被划分为两个相对独立的阶段——通常是“规划阶段+子任务执行阶段”（比如Plan-and-Solve），或者是“纯思考阶段+反思阶段”（比如CoT+Reflection）；
• 多阶段推理（Multi-Stage Reasoning）：Agent的推理流程被划分为三个或三个以上相对独立的阶段——通常是“规划阶段+子任务执行阶段+反思阶段”（比如PaS+Reflection），或者是“多轮规划阶段+多轮子任务执行阶段+多轮反思阶段”（比如Self-Improving Agents）。

---

7.2 分类维度二：工具调用的触发时机（纯推理/按需触发/强制触发）

这个维度指的是Agent何时调用Tools：

• 纯推理（No Tools）：Agent完全不调用任何Tools，只依赖LLM Core自身的能力进行推理；
• 按需触发（On-Demand Triggering）：Agent只有在LLM Core认为“需要使用Tools才能完成当前任务”时，才会调用Tools——比如LLM Core需要访问实时信息、需要执行代码、需要查询自己不知道的知识时；
• 强制触发（Mandatory Triggering）：Agent在推理流程的某些固定阶段必须调用Tools——比如在规划阶段必须调用“任务分解工具”，在结果验证阶段必须调用“结果验证工具”。

---

7.3 分类维度三：信息的整合方式（局部整合/全局整合/混合整合）

这个维度指的是Agent如何整合Memory中的历史信息和工具调用的结果：

• 局部整合（Local Integration）：LLM Core在进行决策时，只考虑最近的几次对话或工具调用结果——比如经典的ReAct模式，LLM Core在每一步思考时，只考虑上一步的工具调用结果；
• 全局整合（Global Integration）：LLM Core在进行决策时，会考虑所有的历史信息和工具调用结果——不过，由于LLM Core的上下文窗口是有限的，所以全局整合通常需要配合“信息检索”技术（比如从Long-Term Memory中检索相关信息）；
• 混合整合（Hybrid Integration）：LLM Core在进行决策时，会同时考虑最近的几次对话或工具调用结果（局部信息）和通过检索得到的相关历史信息（全局信息）——这是目前大多数高级Agent系统采用的信息整合方式。

---

7.4 分类维度四：决策的粒度大小（原子级决策/子任务级决策/混合粒度决策）

这个维度指的是LLM Core每次生成的决策的粒度大小：

• 原子级决策（Atomic-Sized Decision）：LLM Core每次生成的决策是不可再分的最小动作——比如“调用Web搜索工具搜索‘华为Mate 60 Pro 2023年销量’”、“读取当前目录下的‘test.py’文件”；
• 子任务级决策（Subtask-Sized Decision）：LLM Core每次生成的决策是一个相对独立的子任务——比如“收集华为Mate 60 Pro 2023年的销量数据”、“统计‘test.py’文件中的所有类和函数”；
• 混合粒度决策（Hybrid-Sized Decision）：LLM Core在推理流程的不同阶段会生成不同粒度的决策——比如在规划阶段生成子任务级决策，在子任务执行阶段生成原子级决策。

---

8. 主流推理模式的深度解析与数学建模

在本节中，我们将基于上一节提出的分类框架，对目前最主流的五种推理模式进行深度解析，包括它们的核心概念、问题背景、问题解决、边界与外延、概念结构与核心要素组成（如果有的话）、数学模型、算法流程图（Mermaid）、伪代码/简化实现。

---

8.1 纯思考（Zero-Shot/One-Shot/Few-Shot CoT）：无工具依赖的单阶段推理

8.1.1 核心概念

纯思考模式（也叫“Chain of Thought模式”，简称CoT模式）是最简单、最基础的LLM推理模式——它不依赖任何Tools，只通过Prompt Engineering的方式，引导LLM Core“一步步地思考问题”，最后生成结果。

CoT模式可以分为以下几种类型：

1. Zero-Shot CoT（零样本思维链）：只需要在Prompt的最后加上一句简单的引导语（比如“让我们一步步地思考这个问题”、“Please think step by step”），不需要提供任何示例；
2. One-Shot CoT（单样本思维链）：在Prompt中提供一个完整的“问题-思考过程-答案”示例，然后引导LLM Core按照这个示例的格式进行思考；
3. Few-Shot CoT（少样本思维链）：在Prompt中提供多个（通常是3-5个）完整的“问题-思考过程-答案”示例，然后引导LLM Core按照这些示例的格式进行思考。

8.1.2 问题背景

在CoT模式出现之前，LLM在处理复杂的推理任务（比如数学问题、逻辑推理问题、多跳知识推理问题）时的表现非常差——即使是当时最先进的GPT-3模型（175B参数），在处理数学应用题时的准确率也只有不到20%。

为什么会出现这种情况呢？原来，LLM的工作原理是“自回归生成”——它每次只生成一个Token，然后将这个Token添加到上下文窗口中，再生成下一个Token，直到生成结束符（比如<|endoftext|>）。如果没有引导语，LLM在处理复杂的推理任务时，往往会“直接跳到答案”，而忽略了中间的思考过程，这样就很容易犯错误。

8.1.3 问题解决

CoT模式的核心思想非常简单：通过引导LLM Core“一步步地思考问题”，将复杂的推理任务分解成多个简单的子任务，让LLM Core逐个解决这些子任务，最后将子任务的结果整合起来，得到最终的答案。

2022年，Google Brain的研究人员在论文《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》中首次提出了CoT模式，并通过大量的实验证明了CoT模式的有效性——在GPT-3（175B参数）模型上，使用Few-Shot CoT模式处理数学应用题时的准确率可以从不到20%提高到超过50%，在处理逻辑推理问题时的准确率可以从不到30%提高到超过70%。

8.1.4 边界与外延

边界（适用场景的限制）

纯CoT模式虽然简单有效，但它也有一些非常明显的边界：

1. 不能访问实时信息：LLM Core的知识有截止日期（比如GPT-3.5-Turbo的知识截止日期是2023年10月，GPT-4o的知识截止日期是2024年5月），所以纯CoT模式无法回答涉及实时信息的问题（比如“今天的天气怎么样？”、“2024年巴黎奥运会中国代表团获得了多少枚金牌？”）；
2. 无法执行代码或操作外部环境：纯CoT模式无法执行代码（比如无法写一个Python脚本并运行它）、无法操作外部文件（比如无法读取或写入文件）、无法调用外部API（比如无法预订机票或酒店）；
3. 知识储备有限：虽然LLM Core的知识储备非常丰富，但它也不是“万能的”——对于一些非常专业、非常冷门的知识，LLM Core可能不知道或者会记错；
4. 不适合处理超长任务：由于LLM Core的上下文窗口是有限的，所以纯CoT模式不适合处理需要大量上下文信息的超长任务（比如写一本完整的书、分析一个大型的代码库）。

外延（可以扩展的方向）

纯CoT模式的外延非常丰富，很多后来的推理模式都是在纯CoT模式的基础上扩展而来的：

1. CoT+Reflection：在纯CoT模式的基础上，增加了一个“反思阶段”，引导LLM Core反思自己的思考过程和答案是否正确；
2. Self-Consistency CoT：在纯CoT模式的基础上，让LLM Core生成多个不同的思考过程和答案，然后通过“投票”的方式选择最一致的答案；
3. Tree of Thoughts（ToT）：在纯CoT模式的基础上，让LLM Core生成一个“思考树”，每个节点是一个可能的思考步骤，然后通过“搜索”的方式找到最优的思考路径；
4. ReAct：在纯CoT模式的基础上，增加了“工具调用”的能力，让LLM Core可以“想一步、做一步、再反思”。

8.1.5 数学模型

为了方便后续的量化对比分析，我们可以用数学模型来描述纯CoT模式的推理过程。

首先，我们定义一些符号：

• $I$：输入需求（Input）；
• $P_{\text{CoT}}$：CoT模式的Prompt（包括引导语和/或示例）；
• $M$：LLM Core；
• $T$：LLM Core的温度参数（Temperature）；
• $C$：LLM Core的上下文窗口大小（Context Window Size）；
• $S=[s_1,s_2,...,s_n]$：LLM Core生成的思考过程（Chain of Thought），其中$s_i$是第$i$个思考步骤；
• $O$：最终的输出结果（Output）；
• $K_{\text{input}}$：输入需求$I$和Prompt$P_{\text{CoT}}$的总Token数；
• $K_{\text{thought}}$：思考过程$S$的总Token数；
• $K_{\text{output}}$：输出结果