1. 从“执行”到“思考”：为什么Agent需要规划与推理

如果你最近在折腾AI Agent，大概率会遇到一个让人头疼的问题：你精心设计的Agent，在简单任务上表现尚可，但一旦任务稍微复杂、步骤一多，或者需要前后逻辑关联时，它就很容易“翻车”。比如，你让它帮你规划一个周末出游计划，它可能会先告诉你“订好酒店”，然后下一步就让你“去酒店前台办理入住”，却完全忽略了“查询交通路线”和“购买车票”这两个前置关键步骤。这种表现，本质上是因为它缺乏真正的“思考”能力，只是在执行一个被动的、线性的指令响应。

这就是“规划与推理”要解决的核心问题。在AI Agent的语境下， 规划 指的是Agent为了达成一个目标，自主地生成一系列有序的、可行的子步骤或行动序列的能力。而 推理 ，则是支撑规划得以正确进行的内在过程，包括理解当前状态、评估可选行动、预测行动后果、以及根据反馈调整策略。没有推理的规划是盲目的，没有规划的推理是散漫的。我们这一章要探讨的，就是如何为Agent注入这种“先想后做”、“边做边想”的思考能力，让它从一个简单的指令执行器，升级为一个能处理复杂问题的智能协作者。

从网络上的讨论热度来看，无论是“ReAct”、“思维树（ToT）”还是“Self-Reflection”，这些关键词都指向了同一个方向：如何让大语言模型（LLM）突破其固有的“下一个词预测”的局限性，展现出更接近人类的、有结构的思考过程。这不仅仅是学术界的前沿课题，更是每一个希望构建实用、鲁棒Agent的开发者必须面对的工程现实。接下来，我们就深入这些核心框架，看看它们是如何赋予Agent思考能力的。

2. ReAct框架：将推理与行动交织的经典范式

ReAct（Reason + Act）是一个里程碑式的框架，它为大语言模型赋能Agent提供了一种清晰、可操作的模式。其核心思想非常直观： 让模型在采取每一个行动（Act）之前，先进行一步推理（Reason） 。这个“推理-行动”的循环，构成了Agent与外部环境（如搜索引擎、数据库、工具API）交互的基本单元。

2.1 ReAct的核心循环与Prompt设计精髓

一个标准的ReAct循环通常包含以下几个步骤，这些步骤会通过精心设计的Prompt模板来引导模型输出：

1. 任务理解与目标拆解 ：模型首先需要理解用户的最终目标，并将其分解为更易管理的子目标。这一步的Prompt会强调“分析任务”和“制定计划”。
2. 思考（Think） ：针对当前子目标或状态，模型需要“自言自语”地分析现状、可用的工具、以及下一步的最佳行动是什么。这是“推理”的显性化输出。Prompt中会明确要求模型输出“Thought:”字段。
3. 行动（Act） ：基于上一步的思考，模型选择一个具体的工具并生成调用该工具所需的精确参数（如搜索查询词、API调用指令）。Prompt中对应“Action:”和“Action Input:”字段。
4. 观察（Observe） ：环境执行行动，并返回结果（可能成功，也可能失败或返回特定信息）。这个结果被反馈给模型。Prompt中对应“Observation:”字段。
5. 循环与总结 ：模型根据观察结果，更新其内部状态，并开始下一轮的“思考-行动-观察”循环，直至任务完成或无法继续。最终，模型需要输出“Final Answer:”。

一个简化的Prompt模板示例如下：

你是一个智能助手。请使用以下工具完成任务：
- 搜索工具 (search)：用于查询实时信息。输入应为搜索关键词。
- 计算器 (calculator)：用于数学计算。输入应为数学表达式。
- 结束任务 (finish)：当任务完成时使用，并给出最终答案。

任务：{用户问题}

开始！

在实际交互中，模型的输出会严格按照这个结构：

Thought: 用户想了解明天的天气来决定是否洗车。我需要先获取明天的天气预报。
Action: search
Action Input: 北京明天天气预报
Observation: 天气预报显示北京明天晴转多云，气温15-25度，无雨。
Thought: 天气很好，没有雨，适合洗车。我可以给出建议了。
Action: finish
Action Input: 明天北京天气晴朗无雨，非常适合洗车。

注意 ：设计ReAct Prompt时，最关键的是明确工具的描述、输入输出的格式，并通过Few-shot示例清晰地展示整个“Thought -> Action -> Observation”的流程。工具描述越精确，示例越典型，模型的规划能力就越强。

2.2 ReAct的实战优势与典型“翻车”场景

ReAct的优势在于其结构清晰，易于实现和调试。它将模型的“黑盒”思考过程白盒化，让我们能够看到Agent决策的“依据”，这对于排查问题至关重要。例如，当Agent行动失败时，我们可以检查它的“Thought”是否合理，是工具选择错误，还是参数构造有误。

然而，ReAct在实践中也容易遇到一些经典问题：

• 思考短路（Short-sighted Reasoning） ：模型可能只进行非常浅显的推理，就匆忙采取行动。例如，在需要多步计算的问题上，它可能不先规划计算顺序，直接调用计算器导致错误。
• 错误累积（Error Propagation） ：一旦某一步的“Observation”包含了错误信息（比如搜索到了一个过时的答案），后续的所有推理和行动都可能建立在错误的基础上，导致最终结果完全偏离。
• 在复杂规划上乏力 ：对于需要深度回溯、比较多种可能路径的复杂任务（如下棋、复杂行程规划），简单的链式ReAct循环显得力不从心，因为它本质上是一种“贪婪”的、只往前看一步的决策方式。

为了解决这些问题，更强大的规划与推理框架被提出，其中最具代表性的就是“思维树”。

3. 思维树（ToT）：让Agent拥有“多线程”思考能力

思维树（Tree of Thoughts, ToT）框架是对ReAct范式的一次重大升级。如果说ReAct是让Agent沿着一条路走到黑（或走到亮），那么ToT则是让Agent在关键决策点停下来，像下棋一样， 同时思考多种可能的下一步（生成多个“思维”），然后评估这些可能性，有选择地深入探索其中最有希望的路径 。这模仿了人类在解决复杂问题时的“发散-收敛”思维模式。

3.1 ToT的工作原理：思维生成、评估、搜索与回溯

ToT框架将问题求解过程形式化为在一棵树上的搜索过程，这棵树就是“思维树”。每个节点代表问题的一个部分解或一种思考状态，边代表从一个思维到另一个思维的演化。整个过程由以下几个核心模块协同完成：

1. 思维生成器（Thought Generator） ：给定当前状态（树节点），通过提示LLM，生成多个（k个）可能的后续“思维”。例如，在写作任务中，当前状态是文章开头，思维生成器可能产出几个不同的下一段核心论点。
2. 状态评估器（State Evaluator） ：对生成的新思维（子节点）进行快速评估，给出一个分数或评级，用于判断该路径的潜在价值。评估可以基于LLM本身（例如，询问“这个论点是否切题？”），也可以基于一个简单的启发式函数。
3. 搜索算法（Search Algorithm） ：负责协调整个探索过程。最常用的是启发式搜索（如最佳优先搜索）。算法根据状态评估器的分数，决定接下来扩展（深入思考）哪个节点。它维护一个“前沿”节点列表，总是优先探索评估分数最高的节点。
4. 回溯与路径整合 ：当一条路径被探索到终点（解决子问题或确定无解）或达到深度限制时，搜索算法会回溯到上层节点，选择其他高分路径继续探索。最终，将从根节点到某个叶节点（解决方案）的整个思维路径整合起来，形成最终答案。

3.2 实现ToT的关键：提示工程与搜索策略

实现一个ToT Agent，难点不在于编码的复杂度，而在于提示设计和策略选择。

• 思维生成提示 ：必须能引导LLM产生多样化的、合理的后续步骤。提示中需要明确要求“生成N个不同的可能方案”，并可以通过指定角度（如“从成本角度”、“从时间效率角度”）来增加多样性。

  当前问题状态：我们需要将项目预算削减20%。已分析出营销费用是最大头。
  请生成3个不同的、具体的下一步行动建议。
  

• 状态评估提示 ：需要让LLM成为一个“裁判”。评估标准必须清晰、可操作。例如，可以要求LLM从“可行性”、“潜在影响”、“实施难度”三个维度进行1-10分打分。

  请评估以下方案在“可行性”和“效果”上的表现（分别用1-10分打分）：
  方案：立即终止所有线下广告投放。
  可行性评分理由：
  效果评分理由：
  

• 搜索策略的选择 ：
  • 广度优先（BFS） ：在每一层充分探索所有可能，适合解空间不大但需要全面考虑的场景，但开销大。
  • 深度优先（DFS） ：沿着一条路快速深入，适合解空间有明确“深度”指标（如步骤数）的场景，但容易陷入局部最优。
  • 最佳优先搜索（BeFS） ：最常用。始终扩展当前评估分数最高的节点，在探索效率和解的质量之间取得较好平衡。你需要维护一个优先队列（通常基于评估分数）。

实操心得 ：在项目初期，不建议实现一个完整的、通用的ToT框架。更实用的做法是 针对特定任务类型进行定制 。例如，为一个代码调试Agent设计ToT：思维生成是“提出不同的错误假设”，状态评估是“用假设去解释日志的匹配程度”，搜索策略就是优先验证匹配度最高的假设。这种任务特定的ToT实现起来更简单，效果也更直接。

4. Self-Reflection：让Agent学会“复盘”与“自我纠正”

即使有了ReAct和ToT，Agent在执行中仍然会犯错。Self-Reflection（自我反思）机制，就是为Agent配备一个“事后复盘”和“即时校准”的能力。其核心思想是： 让Agent在行动之后，尤其是失败或收到负面反馈后，不是机械地进入下一步，而是主动分析刚才的行动哪里出了问题，并制定修正策略 。这相当于给Agent加了一个“元认知”层。

4.1 自我反思的触发与执行流程

自我反思通常不是持续进行的，而是在特定触发器被激活后启动：

1. 触发条件 ：

   • 行动失败 ：工具调用返回错误（如API错误、工具不可用）。
   • 结果无效 ：观察结果与预期严重不符（如搜索不到信息、计算结果明显荒谬）。
   • 用户反馈 ：用户明确指出“不对”、“这不是我想要的”。
   • 周期性检查 ：在长序列任务中，每完成N步后自动进行阶段性复盘。

2. 反思执行流程 ：

   • 问题诊断 ：LLM被要求分析刚刚的“Thought-Action-Observation”三元组，找出问题根源。是目标理解有误？工具选择不当？参数构造错误？还是对观察结果的解读有偏差？
   • 计划修正 ：基于诊断结果，LLM生成一个修正后的计划。这可能包括：重新定义子目标、选择不同的工具、调整行动参数、甚至回溯到更早的步骤重新开始。
   • 重试或继续 ：执行修正后的计划。

一个典型的反思Prompt如下：

刚才的行动出现了问题。
任务目标：{原始目标}
已执行的历史步骤：
- Thought: {之前的思考}
- Action: {之前的行动}
- Observation: {得到的错误或不满意的结果}
请分析导致当前结果不理想的主要原因是什么？接下来应该如何修正你的计划？请输出修正后的下一步“Thought”。

4.2 将Self-Reflection融入现有框架

自我反思不是一个独立的框架，而是一个可以增强ReAct或ToT的插件式模块。

• 增强ReAct ：在ReAct循环的“Observation”步骤后，增加一个“Reflection”判断。如果观察结果不佳，则进入反思子流程，生成新的“Thought”，而不是基于坏的观察直接继续。

  Observation: 搜索返回“未找到相关信息”。
  Reflection: 我使用的搜索关键词“XX最新型号参数”可能太模糊或信息已过时。我应该尝试更具体的关键词，或查询官方网站。
  New Thought: 我需要更换搜索策略，尝试搜索“XX品牌官网 技术支持 型号列表”。
  Action: search
  Action Input: XX品牌官网 技术支持 型号列表
  

• 增强ToT ：在ToT的搜索过程中，可以对评估分数低的路径节点进行反思，分析其为什么得分低，并将这个分析作为启发式信息，影响后续思维生成的方向，避免重复生成类似的差方案。

踩坑实录 ：引入自我反思的一个常见陷阱是“反思循环”或“过度反思”。Agent可能在一个小问题上反复反思，不断尝试微调，却无法跳出错误的思维定式，导致任务停滞。为了避免这种情况，必须设置反思的最大深度或次数限制，并在Prompt中强调“如果反思两次后问题依旧，考虑是否从根本上误解了任务目标，并尝试向用户请求澄清”。这提醒我们，Agent的“智能”是有限的，与人的协同至关重要。

5. 实战：构建一个具备规划能力的旅行策划Agent

现在，让我们综合运用以上概念，设计一个能处理复杂需求的“旅行策划Agent”。假设用户请求是：“为我规划一个为期三天、预算5000元、从上海出发的杭州休闲游，重点体验美食和自然风光。”

5.1 架构设计：采用分层规划与反思机制

对于这个多约束、多目标的任务，单一的ReAct链会非常吃力。我们采用一个 分层规划 结构，结合 ToT进行方案探索 ，并在关键节点引入 Self-Reflection 。

1. 顶层规划器（ToT驱动） ：

   • 任务 ：生成多个高层次的行程框架。
   • 思维生成 ：“第一天主打西湖古迹，第二天灵隐寺+龙井村，第三天美食街区与返程”；“第一天直接去西溪湿地，第二天环湖骑行，第三天博物馆与购物”。
   • 状态评估 ：根据“预算符合度”、“休闲指数”、“美食与风光覆盖度”进行打分。
   • 输出 ：选择一个得分最高的框架进入下一层。

2. 中层细化器（ReAct循环） ：

   • 任务 ：对选定框架的每一天进行活动细化。
   • 过程 ：以“第一天：西湖古迹”为例，启动ReAct循环。
     • Thought：需要查询西湖主要景点、开放时间、门票价格、地理位置以便串联。
     • Action：调用 search 工具。
     • Observation：获取景点列表（断桥、雷峰塔、苏堤...）及信息。
     • Thought：根据地理位置和兴趣（自然风光），选择断桥、白堤、孤山公园。估算交通时间和门票费用。发现雷峰塔门票较贵，可能超当日预算分支，需反思。
     • (触发Reflection)：当前景点组合门票接近150元，加上交通餐饮，第一天预算可能吃紧。是否需要替换一个免费景点？
     • New Thought：用“西湖音乐喷泉”（免费）替代“雷峰塔”，调整路线。
     • Action：调用 calculator 工具核算调整后的一天预算。
     • Observation：预算合理。
   • 循环 ：完成一天所有活动的规划（餐饮、交通、具体时间估算）。

3. 底层执行与校验器 ：

   • 任务 ：对细化后的活动，进行实时信息确认（如调用订票API检查门票库存、查询天气API）。
   • 过程 ：如果发现“灵隐寺下周维修关闭”，则将此“Observation”作为负面反馈，触发中层细化器的Reflection，要求其重新规划第二天的活动。

5.2 关键工具与Prompt设计要点

这个Agent需要接入多种工具：

• search_attraction : 搜索景点信息。
• search_restaurant : 搜索餐厅信息。
• calculate_budget : 计算分段预算。
• check_weather : 查询天气预报。
• check_ticket : 模拟查询门票库存与价格。

Prompt设计核心 ：每一层的Prompt都需要明确其角色和输入输出格式。例如，顶层规划器的Prompt必须强调“生成 差异化 的框架”和“基于 以下三个标准 进行评估”。中层细化器的Prompt则需要详细的Few-shot示例，展示如何从一个“活动主题”通过多次ReAct循环，分解成具体的、有时序的、有预算的行动列表。

5.3 可能遇到的挑战与调优经验

• 预算控制的动态性 ：Agent容易在前几天过度分配预算。解决方法是在每一层评估和反思中，都加入“剩余预算”作为关键上下文，并设置严格的预算预警规则（如单日超支则必须触发反思）。
• 信息冲突与过时 ：不同工具搜索的信息可能冲突。需要在 Observation 步骤后加入一个“信息核实”子步骤，例如对比多个来源，或优先采用权威来源（如官网）。
• 用户体验 ：最终生成的计划可能过于机械。可以在输出最终答案前，增加一个“润色”步骤，让LLM将冰冷的行程列表转化为一段亲切、有建议性的旅行建议文案。
• 性能与成本 ：ToT搜索会产生大量的LLM调用，成本高昂。在实际应用中，会对搜索宽度（生成的思维数）和深度进行严格限制，并优先考虑使用更便宜、更快的模型进行评估步骤。

构建这样一个Agent的过程，本质上就是将大语言模型的泛化能力，通过规划、推理、反思等模块，约束并引导到一个具体的、结构化的任务解决流程中。它不再是一个“聊天机器人”，而是一个可以信赖的、具备初步思考能力的“智能流程自动化助手”。