1. 从“执行”到“思考”为什么Agent需要规划与推理如果你最近在折腾AI Agent大概率会遇到一个让人头疼的问题你精心设计的Agent在简单任务上表现尚可但一旦任务稍微复杂、步骤一多或者需要前后逻辑关联时它就很容易“翻车”。比如你让它帮你规划一个周末出游计划它可能会先告诉你“订好酒店”然后下一步就让你“去酒店前台办理入住”却完全忽略了“查询交通路线”和“购买车票”这两个前置关键步骤。这种表现本质上是因为它缺乏真正的“思考”能力只是在执行一个被动的、线性的指令响应。这就是“规划与推理”要解决的核心问题。在AI Agent的语境下规划指的是Agent为了达成一个目标自主地生成一系列有序的、可行的子步骤或行动序列的能力。而推理则是支撑规划得以正确进行的内在过程包括理解当前状态、评估可选行动、预测行动后果、以及根据反馈调整策略。没有推理的规划是盲目的没有规划的推理是散漫的。我们这一章要探讨的就是如何为Agent注入这种“先想后做”、“边做边想”的思考能力让它从一个简单的指令执行器升级为一个能处理复杂问题的智能协作者。从网络上的讨论热度来看无论是“ReAct”、“思维树ToT”还是“Self-Reflection”这些关键词都指向了同一个方向如何让大语言模型LLM突破其固有的“下一个词预测”的局限性展现出更接近人类的、有结构的思考过程。这不仅仅是学术界的前沿课题更是每一个希望构建实用、鲁棒Agent的开发者必须面对的工程现实。接下来我们就深入这些核心框架看看它们是如何赋予Agent思考能力的。2. ReAct框架将推理与行动交织的经典范式ReActReason Act是一个里程碑式的框架它为大语言模型赋能Agent提供了一种清晰、可操作的模式。其核心思想非常直观让模型在采取每一个行动Act之前先进行一步推理Reason。这个“推理-行动”的循环构成了Agent与外部环境如搜索引擎、数据库、工具API交互的基本单元。2.1 ReAct的核心循环与Prompt设计精髓一个标准的ReAct循环通常包含以下几个步骤这些步骤会通过精心设计的Prompt模板来引导模型输出任务理解与目标拆解模型首先需要理解用户的最终目标并将其分解为更易管理的子目标。这一步的Prompt会强调“分析任务”和“制定计划”。思考Think针对当前子目标或状态模型需要“自言自语”地分析现状、可用的工具、以及下一步的最佳行动是什么。这是“推理”的显性化输出。Prompt中会明确要求模型输出“Thought:”字段。行动Act基于上一步的思考模型选择一个具体的工具并生成调用该工具所需的精确参数如搜索查询词、API调用指令。Prompt中对应“Action:”和“Action Input:”字段。观察Observe环境执行行动并返回结果可能成功也可能失败或返回特定信息。这个结果被反馈给模型。Prompt中对应“Observation:”字段。循环与总结模型根据观察结果更新其内部状态并开始下一轮的“思考-行动-观察”循环直至任务完成或无法继续。最终模型需要输出“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框架将问题求解过程形式化为在一棵树上的搜索过程这棵树就是“思维树”。每个节点代表问题的一个部分解或一种思考状态边代表从一个思维到另一个思维的演化。整个过程由以下几个核心模块协同完成思维生成器Thought Generator给定当前状态树节点通过提示LLM生成多个k个可能的后续“思维”。例如在写作任务中当前状态是文章开头思维生成器可能产出几个不同的下一段核心论点。状态评估器State Evaluator对生成的新思维子节点进行快速评估给出一个分数或评级用于判断该路径的潜在价值。评估可以基于LLM本身例如询问“这个论点是否切题”也可以基于一个简单的启发式函数。搜索算法Search Algorithm负责协调整个探索过程。最常用的是启发式搜索如最佳优先搜索。算法根据状态评估器的分数决定接下来扩展深入思考哪个节点。它维护一个“前沿”节点列表总是优先探索评估分数最高的节点。回溯与路径整合当一条路径被探索到终点解决子问题或确定无解或达到深度限制时搜索算法会回溯到上层节点选择其他高分路径继续探索。最终将从根节点到某个叶节点解决方案的整个思维路径整合起来形成最终答案。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和ToTAgent在执行中仍然会犯错。Self-Reflection自我反思机制就是为Agent配备一个“事后复盘”和“即时校准”的能力。其核心思想是让Agent在行动之后尤其是失败或收到负面反馈后不是机械地进入下一步而是主动分析刚才的行动哪里出了问题并制定修正策略。这相当于给Agent加了一个“元认知”层。4.1 自我反思的触发与执行流程自我反思通常不是持续进行的而是在特定触发器被激活后启动触发条件行动失败工具调用返回错误如API错误、工具不可用。结果无效观察结果与预期严重不符如搜索不到信息、计算结果明显荒谬。用户反馈用户明确指出“不对”、“这不是我想要的”。周期性检查在长序列任务中每完成N步后自动进行阶段性复盘。反思执行流程问题诊断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。顶层规划器ToT驱动任务生成多个高层次的行程框架。思维生成“第一天主打西湖古迹第二天灵隐寺龙井村第三天美食街区与返程”“第一天直接去西溪湿地第二天环湖骑行第三天博物馆与购物”。状态评估根据“预算符合度”、“休闲指数”、“美食与风光覆盖度”进行打分。输出选择一个得分最高的框架进入下一层。中层细化器ReAct循环任务对选定框架的每一天进行活动细化。过程以“第一天西湖古迹”为例启动ReAct循环。Thought需要查询西湖主要景点、开放时间、门票价格、地理位置以便串联。Action调用search工具。Observation获取景点列表断桥、雷峰塔、苏堤...及信息。Thought根据地理位置和兴趣自然风光选择断桥、白堤、孤山公园。估算交通时间和门票费用。发现雷峰塔门票较贵可能超当日预算分支需反思。(触发Reflection)当前景点组合门票接近150元加上交通餐饮第一天预算可能吃紧。是否需要替换一个免费景点New Thought用“西湖音乐喷泉”免费替代“雷峰塔”调整路线。Action调用calculator工具核算调整后的一天预算。Observation预算合理。循环完成一天所有活动的规划餐饮、交通、具体时间估算。底层执行与校验器任务对细化后的活动进行实时信息确认如调用订票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的过程本质上就是将大语言模型的泛化能力通过规划、推理、反思等模块约束并引导到一个具体的、结构化的任务解决流程中。它不再是一个“聊天机器人”而是一个可以信赖的、具备初步思考能力的“智能流程自动化助手”。