1. 从“指令执行”到“自主规划”为什么我们需要Agent Planning如果你最近在捣鼓大语言模型尤其是尝试用它来做点自动化的事情你大概率已经听过“AI Agent”这个词了。从年初开始各种Agent框架、项目和应用就像雨后春笋一样冒出来仿佛一夜之间LLM从一个“高级聊天机器人”变成了可以“自主完成任务”的智能体。但当你真正上手想把一个复杂任务比如“帮我分析一下这个季度的销售数据写份报告并给市场部提三个改进建议”丢给一个Agent时往往会发现结果不尽如人意。它可能写报告写得不错但完全忘了分析数据或者分析了一堆给出的建议却和报告内容对不上。问题出在哪核心就在于“规划”。早期的LLM应用我们称之为“指令-响应”模式。你问“今天天气怎么样”它调用天气API然后组织语言回答你。任务简单、步骤单一。但现实世界的任务尤其是商业和创造性工作往往是多步骤、有依赖、需要动态调整的。让LLM“写一份报告”是创作但让LLM“分析数据、总结洞察、生成报告、提出建议”就是一个需要规划的项目管理过程。Agent Planning就是赋予LLM这种“项目管理”和“战略思考”能力的关键技术。它要解决的是LLM在复杂任务中表现出的几个典型短板思维跳跃、忽略步骤、缺乏回溯、资源浪费。没有规划的Agent就像一个聪明但缺乏条理的助手可能一开始就直奔最复杂的部分而忘了准备基础材料。Planning就是为这个助手配备一个“任务清单”和“应急方案”确保它能一步步、稳健地走向目标。这篇文章我将结合自己近半年在多个Agent项目中的实战和踩坑经验为你彻底拆解Agent Planning的两种核心路径纯LLM范式和混合规划模式。这不是一篇堆砌论文概念的综述而是一份聚焦于“如何选、怎么用、有何坑”的实战指南。我们会先深入8种主流的纯LLM规划方法理解其思想精髓和适用场景在下一部分再探讨8种结合了符号逻辑、搜索算法等传统AI技术的混合模式看看如何取长补短。2. 纯LLM规划范式让模型自己“想清楚”纯LLM规划顾名思义就是不引入外部规划器或符号系统完全依靠LLM自身的推理能力通过设计特定的提示词Prompt、思维过程Chain of Thought或交互机制让模型自己生成并执行任务计划。这是目前最主流、门槛最低的入门方式。其核心思想是将规划能力视为LLM的一种可通过提示激发的“涌现能力”。2.1 思维链与零样本规划规划的起点一切始于Chain of Thought。2022年那篇著名的论文告诉我们只要在提示词中要求模型“一步一步地思考”它的推理能力就会显著提升。这在规划中同样适用。零样本规划是最简单的形式。你直接告诉模型“请为完成[复杂任务]制定一个分步计划。” 例如提示词可以是“你需要为我策划一个线上产品发布会。请列出你需要做的所有步骤并说明每一步的关键产出。” LLM可能会输出一个包含“市场调研、内容策划、平台选择、宣传推广、直播执行、会后复盘”等步骤的计划。实操心得零样本规划的效果极度依赖于任务描述的清晰度和模型本身的能力。对于GPT-4级别的模型在定义良好的任务上如“制定旅行计划”、“编写项目方案”它能给出结构不错的计划。但它的缺点是计划粒度不可控可能过于笼统“执行宣传推广”或陷入无关细节“第一步打开电脑”。我通常用它来做计划草稿或头脑风暴为后续更精细的规划方法提供输入。思维链增强的规划则更进一步。它不仅要求输出步骤还要求输出每一步的“理由”。例如“请为优化网站加载速度制定一个计划。对于每一步请解释为什么这一步是必要的以及它如何帮助达成最终目标。” 这迫使模型进行更深层次的因果推理产出的计划逻辑性更强也更容易被人类审查。这两种方法是所有高级规划技术的基础。它们证明了LLM具有内在的规划潜力但就像让一个新手项目经理直接制定跨国项目计划结果往往粗糙、缺乏可操作性和容错性。因此我们需要更结构化的方法。2.2 ReAct范式将“思考”与“行动”循环起来如果说CoT让模型“想”那么ReAct就是让模型“想完就做做错再想”。它是我在构建第一个实用Agent时采用的框架也是目前绝大多数Agent框架如LangChain的AgentExecutor的底层逻辑。ReAct的核心是一个循环Thought - Action - Observation。Thought模型分析当前情况任务目标、已有观察、可用工具决定下一步该做什么。Action模型根据Thought调用一个工具如搜索、计算、读写文件或执行一个操作。Observation获取Action执行后的结果工具返回、环境反馈。这个循环直到任务完成或达到终止条件。它的强大之处在于将规划Thought与执行Action实时结合允许模型根据执行反馈动态调整计划。一个典型的数据分析Agent的ReAct循环可能如下Thought 1用户想分析销售数据。我需要先获取数据。可用工具有query_database查询数据库、read_csv_file读取CSV文件。Action 1调用query_database参数为“获取本季度所有销售记录”。Observation 1数据库返回了包含10万条记录的JSON数据。Thought 2数据量很大直接分析困难。我应该先进行数据清洗和聚合计算关键指标如月度销售额、产品类别销量。可用工具python_executor执行Python代码。Action 2调用python_executor执行一段Pandas代码进行数据聚合。Observation 2代码执行成功输出一个包含聚合结果的DataFrame摘要。Thought 3现在有了聚合数据我可以开始分析趋势并可视化。需要生成图表和文字报告。可用工具generate_chart生成图表、write_markdown撰写报告。Action 3调用generate_chart生成月度销售趋势折线图。...循环继续踩坑实录ReAct听起来很美但在实践中极易陷入循环或发散。我遇到过两个经典问题1)思维漩涡模型在Thought阶段不断重复类似的思考无法推进到Action。例如反复思考“我应该分析数据但数据有点脏我是不是该先清洗可是清洗前要不要先了解数据结构”就是不执行。2)动作迷失模型执行了Action但Observation结果不理想如工具报错、返回空数据它无法有效处理这个意外要么放弃要么尝试一个完全不相关的Action。解决方案关键在于设计高质量的提示词和工具描述。在Thought提示中必须明确强调“基于当前观察决定一个最具体、最可行的下一步动作”。工具的描述要极其清晰包括输入格式、输出示例、以及可能发生的错误。此外引入最大步数限制和关键检查点是必须的防止无限循环。2.3 Tree of Thoughts像下棋一样推演多种可能当任务存在多个可能路径且每一步的选择都会影响后续发展时比如棋类游戏、复杂决策、创意写作ReAct这种“单线推进”的方式就显得力不从心了。它就像走迷宫只试一条路碰壁了才回头。Tree of Thoughts则让模型同时探索多条路径更像一个棋手在推演多种可能的走法。ToT的核心思想是将解决问题的过程建模为一棵树。树的每个节点代表一个部分解或一种思维状态从根节点初始问题开始通过LLM“生成”多个可能的下一步扩展子节点然后LLM再“评估”这些子节点的好坏选择最有希望的路径继续深入必要时进行回溯。以“用给定词语写一首诗”为例根节点词语列表[秋 风 思念]。扩展LLM生成多个可能的第一句诗如节点A“秋风起时叶纷飞”节点B“思念如风绕指柔”节点C“金秋时节硕果累”。评估LLM或另一个评估器对这三个节点打分评估其诗意、扣题程度、作为开头的潜力。搜索假设节点A得分最高。从节点A出发再次扩展生成多个可能的第二句形成新的子节点。再评估选择最优如此往复。回溯如果从节点A发展的所有路径都走不通评估分低则回溯到根节点尝试节点B或C。实战技巧ToT的实现成本比ReAct高很多因为它需要多次调用LLM生成、评估并且要维护一个树状结构。在我的项目中我通常不会对任务的每一步都进行ToT而是用于关键决策点。例如在客服Agent中当用户问题非常模糊时如“我的账户有问题”我会用ToT让Agent并行生成几种不同的澄清问法“请问是登录问题、支付问题还是信息修改问题”评估哪种问法最可能快速定位问题然后选择它进行交互。这显著提升了处理复杂咨询的效率和成功率。2.4 Graph of Thoughts处理网状关联的复杂任务有些任务不是树状的而是网状的。步骤之间不是简单的父子关系可能存在复杂的交叉引用、信息合并和循环依赖。比如撰写一篇学术论文的“相关工作”部分你需要同时阅读多篇文献提取观点比较异同然后综合成一段连贯的文字。这个过程不是线性的也不是简单的树状分支而是一个信息不断聚合、提炼的图状过程。Graph of Thoughts将思维状态表示为图中的节点将思维操作如生成、修改、总结、比较表示为连接节点的边。LLM可以在任意节点上进行操作并将结果连接到其他相关节点从而更灵活地处理信息聚合和综合推理。一个文献综述的GoT过程可能如下创建多个节点每个节点代表一篇论文的核心摘要通过LLM提取。LLM执行“比较”操作对比节点A和节点B的异同生成一个新的比较节点C。LLM执行“总结”操作将节点A、B、C的信息融合生成一个更高层次的综述节点D。引入新论文节点ELLM执行“整合”操作将节点D和E的信息合并更新节点D。最终基于这个不断演化的知识图LLM生成最终的“相关工作”文本。个人体会GoT是概念上最强大、但也最复杂的纯LLM规划范式。它非常适合于知识密集型和综合创作型任务。我曾在构建一个“竞品分析报告生成Agent”时尝试过GoT的思路。Agent会并行爬取多个竞品网站、技术文档和新闻为每个竞品创建一个信息节点然后不断执行“对比功能”、“对比价格”、“归纳优势势”等操作生成中间对比节点最后合成一份结构化的报告。它的优势在于能保持信息的关联性和可追溯性但实现上需要对图数据结构有较好的把握且LLM调用成本很高。2.5 Reflexion与Self-Refine让Agent具备“复盘”能力无论是ReAct还是ToTAgent都会犯错。一个更智能的Agent应该能从错误中学习在同一个任务或类似任务上不再犯第二次。这就是Reflexion和Self-Refine等“自我反思”范式的目标。Reflexion在标准的ReAct循环中增加了一个“反思”步骤。当Agent的行动导致失败或结果不理想时由一个评估器判断它会触发一个反思LLM被要求分析刚才失败的原因并生成一个文字形式的教训存储到短期或长期记忆中。当下一次遇到类似情境时这个教训会被作为上下文提示给LLM从而避免重蹈覆辙。例如一个编码Agent第一次尝试用requests.get()访问一个需要API密钥的端点时失败了Observation返回401错误。在Reflexion步骤LLM生成反思“访问这个API需要先在请求头中提供Authorization: Bearer token。” 这个反思被保存。下次它需要访问类似API时这段文字会出现在它的上下文中提醒它先检查认证。Self-Refine则更侧重于对输出结果的迭代优化。它不改变规划过程而是在得到一个初始输出后让LLM自己扮演“批评者”找出这个输出的问题然后基于批评意见再扮演“改进者”生成一个更好的版本。如此循环多次。例如Agent生成了一份项目计划书初稿。Self-Refine循环启动批评LLM扮演批评者提示“请从可行性、时间安排、资源分配三个方面找出这份计划书中三个最突出的问题。”改进将初稿和批评意见一起给LLM扮演改进者“请根据上述批评重写并改进这份计划书。”迭代可以重复批评-改进步骤直到满意。避坑指南自我反思听起来很“智能”但引入它需要非常小心。最大的坑是反思的质量和幻觉。LLM生成的“教训”可能是错误的、片面的如果被盲目信任并加入上下文反而会把Agent带偏。我的经验是1) 为反思设置严格的触发条件如连续失败、特定错误码不要动不动就反思。2) 对反思内容进行过滤或验证例如只采纳那些包含具体、可操作建议的反思如“需要添加请求头X”而不是“可能出了点问题”。3) 对于Self-Refine要设定最大迭代次数防止陷入对无关细节的无限优化。2.6 提示词工程规划将复杂计划“预制”到提示中对于领域特定、流程固定的任务我们其实不需要LLM动态生成计划。我们可以把最佳实践计划直接“写死”在系统提示词里。这听起来不“智能”但在生产环境中往往最稳定、最高效。这种方法的核心是设计一个极其详细、条件清晰的“元提示词”其中包含了任务分解的逻辑、步骤顺序、步骤间的依赖关系、每个步骤的具体指令和产出标准。例如一个“代码审查Agent”的系统提示词可能如下“你是一个资深代码审查助手。当你收到一段代码时请严格按照以下顺序和标准执行安全检查扫描代码中是否存在已知的安全漏洞模式如SQL注入、XSS。列出所有发现按严重程度排序。代码风格检查检查是否符合项目的编码规范如PEP 8 for Python。列出所有不符合项。性能检查识别可能的性能瓶颈如循环内的重复计算、未使用索引的数据库查询。提出优化建议。功能逻辑检查基于代码注释和函数名推断其意图检查逻辑是否正确、有无边界条件未处理。生成审查报告综合以上四步结果生成一份友好的、鼓励性的审查报告先总结优点再列出待改进点并为每个点提供修改示例。注意如果代码为空或无法解析直接输出‘无法审查’并停止后续步骤。”经验之谈这是目前工业界落地最广的“规划”方式尤其适用于客服、审核、数据ETL等场景。它的优势是完全可控、结果稳定、速度快。缺点自然是灵活性差无法处理提示词未涵盖的异常情况。我的策略是将动态规划与静态提示结合。先用一个“规划器Agent”采用ReAct或ToT来分析用户任务的类型和复杂度。如果是标准任务如“代码审查”、“周报生成”则路由到对应的、带有固定流程提示词的“执行器Agent”如果是非标任务再启用完整的动态规划流程。这样兼顾了效率和灵活性。2.7 基于LLM的规划器评估与选择面对这么多纯LLM规划范式我们该如何选择没有一个范式是万能的。下面这个表格基于我的实战经验从多个维度进行了对比可以帮助你根据任务特性进行选型。规划范式核心思想优点缺点典型适用场景零样本/CoT规划直接要求LLM输出步骤计划简单直接无需复杂框架计划粗糙粒度不一缺乏纠错快速原型、头脑风暴、简单任务分解ReAct思考-行动-观察循环动态适应执行与规划结合框架成熟易循环/发散依赖提示词和工具设计通用任务自动化、需调用外部工具的场景如数据分析、网页操作Tree of Thoughts树状搜索并行探索多条路径能权衡不同选项决策质量高计算成本高多次LLM调用实现复杂游戏、策略决策、创意生成如写作、设计Graph of Thoughts图状结构灵活聚合信息擅长处理信息融合与复杂依赖实现最复杂成本最高概念较新学术研究、综合报告撰写、复杂知识推理Reflexion/Self-Refine从错误中学习迭代优化输出具备持续改进能力结果质量更高反思可能产生幻觉增加不确定性需要长期运行、持续学习的Agent或对输出质量要求极高的场景如文案润色提示词工程规划将固定流程预置到提示词中稳定、高效、可控、成本低完全无灵活性无法处理未知情况流程固定的标准化任务如客服SOP、代码审查、数据清洗流水线选型决策流我通常遵循以下思路任务是否标准化、流程固定是 - 首选提示词工程规划。任务是否需要与外部环境/工具频繁交互是 - 首选ReAct并考虑加入Reflexion提升鲁棒性。任务是否涉及大量创造性选择或关键决策是 - 考虑Tree of Thoughts在关键节点使用。任务是否需要深度整合多源、异构信息是 - 研究Graph of Thoughts评估其必要性。只是需要一个快速计划草案- 使用零样本/CoT规划。2.8 纯LLM规划的共性局限与挑战尽管纯LLM规划取得了惊人进展但我们在欢呼其能力的同时必须清醒地认识到其固有的天花板。这些局限不是某个方法的缺陷而是源于当前LLM本身的技术特性。缺乏真正的世界模型与常识LLM的“规划”是基于统计关联的文本生成而不是基于对物理世界或社会规则的内在理解。它可能规划出一个“先造屋顶再打地基”的建筑步骤因为它在语料中见过这样的句子组合但它不理解其中的因果矛盾。这对于安全关键型应用是致命的。长程依赖与上下文遗忘即使是128K甚至更长上下文的模型在生成长篇、多步骤计划时也容易“忘记”最初的目标或中间的重要约束。规划到第20步时可能已经偏离了第1步设定的核心方向。这限制了其处理超长、复杂任务链的能力。计算成本与延迟ToT、GoT等高级范式需要多次调用LLM成本高昂延迟也大。在实时性要求高的场景如对话机器人、游戏AI这可能不适用。结果的不确定性与幻觉LLM生成的计划可能包含虚构的步骤、不可用的工具或不存在的依赖关系。你需要额外的验证层来确保计划的可行性。对提示词的高度敏感规划的质量极度依赖于提示词的设计。一个词的改动可能导致完全不同的规划路径和结果。这给开发和维护带来了很大挑战。正因为这些局限我们才需要看向另一条道路混合规划模式。通过将LLM与符号推理、搜索算法、形式化验证等传统AI技术结合我们可以构建出更可靠、更高效、更具可解释性的规划智能体。这将是下一部分我们要深入探讨的内容。我们将看到如何用LLM的创造性思维来弥补传统规划器的死板又如何用传统规划器的严谨来约束LLM的天马行空从而实现真正的优势互补。 AI Agent规划技术实战：从ReAct到ToT的8种LLM规划范式解析
1. 从“指令执行”到“自主规划”为什么我们需要Agent Planning如果你最近在捣鼓大语言模型尤其是尝试用它来做点自动化的事情你大概率已经听过“AI Agent”这个词了。从年初开始各种Agent框架、项目和应用就像雨后春笋一样冒出来仿佛一夜之间LLM从一个“高级聊天机器人”变成了可以“自主完成任务”的智能体。但当你真正上手想把一个复杂任务比如“帮我分析一下这个季度的销售数据写份报告并给市场部提三个改进建议”丢给一个Agent时往往会发现结果不尽如人意。它可能写报告写得不错但完全忘了分析数据或者分析了一堆给出的建议却和报告内容对不上。问题出在哪核心就在于“规划”。早期的LLM应用我们称之为“指令-响应”模式。你问“今天天气怎么样”它调用天气API然后组织语言回答你。任务简单、步骤单一。但现实世界的任务尤其是商业和创造性工作往往是多步骤、有依赖、需要动态调整的。让LLM“写一份报告”是创作但让LLM“分析数据、总结洞察、生成报告、提出建议”就是一个需要规划的项目管理过程。Agent Planning就是赋予LLM这种“项目管理”和“战略思考”能力的关键技术。它要解决的是LLM在复杂任务中表现出的几个典型短板思维跳跃、忽略步骤、缺乏回溯、资源浪费。没有规划的Agent就像一个聪明但缺乏条理的助手可能一开始就直奔最复杂的部分而忘了准备基础材料。Planning就是为这个助手配备一个“任务清单”和“应急方案”确保它能一步步、稳健地走向目标。这篇文章我将结合自己近半年在多个Agent项目中的实战和踩坑经验为你彻底拆解Agent Planning的两种核心路径纯LLM范式和混合规划模式。这不是一篇堆砌论文概念的综述而是一份聚焦于“如何选、怎么用、有何坑”的实战指南。我们会先深入8种主流的纯LLM规划方法理解其思想精髓和适用场景在下一部分再探讨8种结合了符号逻辑、搜索算法等传统AI技术的混合模式看看如何取长补短。2. 纯LLM规划范式让模型自己“想清楚”纯LLM规划顾名思义就是不引入外部规划器或符号系统完全依靠LLM自身的推理能力通过设计特定的提示词Prompt、思维过程Chain of Thought或交互机制让模型自己生成并执行任务计划。这是目前最主流、门槛最低的入门方式。其核心思想是将规划能力视为LLM的一种可通过提示激发的“涌现能力”。2.1 思维链与零样本规划规划的起点一切始于Chain of Thought。2022年那篇著名的论文告诉我们只要在提示词中要求模型“一步一步地思考”它的推理能力就会显著提升。这在规划中同样适用。零样本规划是最简单的形式。你直接告诉模型“请为完成[复杂任务]制定一个分步计划。” 例如提示词可以是“你需要为我策划一个线上产品发布会。请列出你需要做的所有步骤并说明每一步的关键产出。” LLM可能会输出一个包含“市场调研、内容策划、平台选择、宣传推广、直播执行、会后复盘”等步骤的计划。实操心得零样本规划的效果极度依赖于任务描述的清晰度和模型本身的能力。对于GPT-4级别的模型在定义良好的任务上如“制定旅行计划”、“编写项目方案”它能给出结构不错的计划。但它的缺点是计划粒度不可控可能过于笼统“执行宣传推广”或陷入无关细节“第一步打开电脑”。我通常用它来做计划草稿或头脑风暴为后续更精细的规划方法提供输入。思维链增强的规划则更进一步。它不仅要求输出步骤还要求输出每一步的“理由”。例如“请为优化网站加载速度制定一个计划。对于每一步请解释为什么这一步是必要的以及它如何帮助达成最终目标。” 这迫使模型进行更深层次的因果推理产出的计划逻辑性更强也更容易被人类审查。这两种方法是所有高级规划技术的基础。它们证明了LLM具有内在的规划潜力但就像让一个新手项目经理直接制定跨国项目计划结果往往粗糙、缺乏可操作性和容错性。因此我们需要更结构化的方法。2.2 ReAct范式将“思考”与“行动”循环起来如果说CoT让模型“想”那么ReAct就是让模型“想完就做做错再想”。它是我在构建第一个实用Agent时采用的框架也是目前绝大多数Agent框架如LangChain的AgentExecutor的底层逻辑。ReAct的核心是一个循环Thought - Action - Observation。Thought模型分析当前情况任务目标、已有观察、可用工具决定下一步该做什么。Action模型根据Thought调用一个工具如搜索、计算、读写文件或执行一个操作。Observation获取Action执行后的结果工具返回、环境反馈。这个循环直到任务完成或达到终止条件。它的强大之处在于将规划Thought与执行Action实时结合允许模型根据执行反馈动态调整计划。一个典型的数据分析Agent的ReAct循环可能如下Thought 1用户想分析销售数据。我需要先获取数据。可用工具有query_database查询数据库、read_csv_file读取CSV文件。Action 1调用query_database参数为“获取本季度所有销售记录”。Observation 1数据库返回了包含10万条记录的JSON数据。Thought 2数据量很大直接分析困难。我应该先进行数据清洗和聚合计算关键指标如月度销售额、产品类别销量。可用工具python_executor执行Python代码。Action 2调用python_executor执行一段Pandas代码进行数据聚合。Observation 2代码执行成功输出一个包含聚合结果的DataFrame摘要。Thought 3现在有了聚合数据我可以开始分析趋势并可视化。需要生成图表和文字报告。可用工具generate_chart生成图表、write_markdown撰写报告。Action 3调用generate_chart生成月度销售趋势折线图。...循环继续踩坑实录ReAct听起来很美但在实践中极易陷入循环或发散。我遇到过两个经典问题1)思维漩涡模型在Thought阶段不断重复类似的思考无法推进到Action。例如反复思考“我应该分析数据但数据有点脏我是不是该先清洗可是清洗前要不要先了解数据结构”就是不执行。2)动作迷失模型执行了Action但Observation结果不理想如工具报错、返回空数据它无法有效处理这个意外要么放弃要么尝试一个完全不相关的Action。解决方案关键在于设计高质量的提示词和工具描述。在Thought提示中必须明确强调“基于当前观察决定一个最具体、最可行的下一步动作”。工具的描述要极其清晰包括输入格式、输出示例、以及可能发生的错误。此外引入最大步数限制和关键检查点是必须的防止无限循环。2.3 Tree of Thoughts像下棋一样推演多种可能当任务存在多个可能路径且每一步的选择都会影响后续发展时比如棋类游戏、复杂决策、创意写作ReAct这种“单线推进”的方式就显得力不从心了。它就像走迷宫只试一条路碰壁了才回头。Tree of Thoughts则让模型同时探索多条路径更像一个棋手在推演多种可能的走法。ToT的核心思想是将解决问题的过程建模为一棵树。树的每个节点代表一个部分解或一种思维状态从根节点初始问题开始通过LLM“生成”多个可能的下一步扩展子节点然后LLM再“评估”这些子节点的好坏选择最有希望的路径继续深入必要时进行回溯。以“用给定词语写一首诗”为例根节点词语列表[秋 风 思念]。扩展LLM生成多个可能的第一句诗如节点A“秋风起时叶纷飞”节点B“思念如风绕指柔”节点C“金秋时节硕果累”。评估LLM或另一个评估器对这三个节点打分评估其诗意、扣题程度、作为开头的潜力。搜索假设节点A得分最高。从节点A出发再次扩展生成多个可能的第二句形成新的子节点。再评估选择最优如此往复。回溯如果从节点A发展的所有路径都走不通评估分低则回溯到根节点尝试节点B或C。实战技巧ToT的实现成本比ReAct高很多因为它需要多次调用LLM生成、评估并且要维护一个树状结构。在我的项目中我通常不会对任务的每一步都进行ToT而是用于关键决策点。例如在客服Agent中当用户问题非常模糊时如“我的账户有问题”我会用ToT让Agent并行生成几种不同的澄清问法“请问是登录问题、支付问题还是信息修改问题”评估哪种问法最可能快速定位问题然后选择它进行交互。这显著提升了处理复杂咨询的效率和成功率。2.4 Graph of Thoughts处理网状关联的复杂任务有些任务不是树状的而是网状的。步骤之间不是简单的父子关系可能存在复杂的交叉引用、信息合并和循环依赖。比如撰写一篇学术论文的“相关工作”部分你需要同时阅读多篇文献提取观点比较异同然后综合成一段连贯的文字。这个过程不是线性的也不是简单的树状分支而是一个信息不断聚合、提炼的图状过程。Graph of Thoughts将思维状态表示为图中的节点将思维操作如生成、修改、总结、比较表示为连接节点的边。LLM可以在任意节点上进行操作并将结果连接到其他相关节点从而更灵活地处理信息聚合和综合推理。一个文献综述的GoT过程可能如下创建多个节点每个节点代表一篇论文的核心摘要通过LLM提取。LLM执行“比较”操作对比节点A和节点B的异同生成一个新的比较节点C。LLM执行“总结”操作将节点A、B、C的信息融合生成一个更高层次的综述节点D。引入新论文节点ELLM执行“整合”操作将节点D和E的信息合并更新节点D。最终基于这个不断演化的知识图LLM生成最终的“相关工作”文本。个人体会GoT是概念上最强大、但也最复杂的纯LLM规划范式。它非常适合于知识密集型和综合创作型任务。我曾在构建一个“竞品分析报告生成Agent”时尝试过GoT的思路。Agent会并行爬取多个竞品网站、技术文档和新闻为每个竞品创建一个信息节点然后不断执行“对比功能”、“对比价格”、“归纳优势势”等操作生成中间对比节点最后合成一份结构化的报告。它的优势在于能保持信息的关联性和可追溯性但实现上需要对图数据结构有较好的把握且LLM调用成本很高。2.5 Reflexion与Self-Refine让Agent具备“复盘”能力无论是ReAct还是ToTAgent都会犯错。一个更智能的Agent应该能从错误中学习在同一个任务或类似任务上不再犯第二次。这就是Reflexion和Self-Refine等“自我反思”范式的目标。Reflexion在标准的ReAct循环中增加了一个“反思”步骤。当Agent的行动导致失败或结果不理想时由一个评估器判断它会触发一个反思LLM被要求分析刚才失败的原因并生成一个文字形式的教训存储到短期或长期记忆中。当下一次遇到类似情境时这个教训会被作为上下文提示给LLM从而避免重蹈覆辙。例如一个编码Agent第一次尝试用requests.get()访问一个需要API密钥的端点时失败了Observation返回401错误。在Reflexion步骤LLM生成反思“访问这个API需要先在请求头中提供Authorization: Bearer token。” 这个反思被保存。下次它需要访问类似API时这段文字会出现在它的上下文中提醒它先检查认证。Self-Refine则更侧重于对输出结果的迭代优化。它不改变规划过程而是在得到一个初始输出后让LLM自己扮演“批评者”找出这个输出的问题然后基于批评意见再扮演“改进者”生成一个更好的版本。如此循环多次。例如Agent生成了一份项目计划书初稿。Self-Refine循环启动批评LLM扮演批评者提示“请从可行性、时间安排、资源分配三个方面找出这份计划书中三个最突出的问题。”改进将初稿和批评意见一起给LLM扮演改进者“请根据上述批评重写并改进这份计划书。”迭代可以重复批评-改进步骤直到满意。避坑指南自我反思听起来很“智能”但引入它需要非常小心。最大的坑是反思的质量和幻觉。LLM生成的“教训”可能是错误的、片面的如果被盲目信任并加入上下文反而会把Agent带偏。我的经验是1) 为反思设置严格的触发条件如连续失败、特定错误码不要动不动就反思。2) 对反思内容进行过滤或验证例如只采纳那些包含具体、可操作建议的反思如“需要添加请求头X”而不是“可能出了点问题”。3) 对于Self-Refine要设定最大迭代次数防止陷入对无关细节的无限优化。2.6 提示词工程规划将复杂计划“预制”到提示中对于领域特定、流程固定的任务我们其实不需要LLM动态生成计划。我们可以把最佳实践计划直接“写死”在系统提示词里。这听起来不“智能”但在生产环境中往往最稳定、最高效。这种方法的核心是设计一个极其详细、条件清晰的“元提示词”其中包含了任务分解的逻辑、步骤顺序、步骤间的依赖关系、每个步骤的具体指令和产出标准。例如一个“代码审查Agent”的系统提示词可能如下“你是一个资深代码审查助手。当你收到一段代码时请严格按照以下顺序和标准执行安全检查扫描代码中是否存在已知的安全漏洞模式如SQL注入、XSS。列出所有发现按严重程度排序。代码风格检查检查是否符合项目的编码规范如PEP 8 for Python。列出所有不符合项。性能检查识别可能的性能瓶颈如循环内的重复计算、未使用索引的数据库查询。提出优化建议。功能逻辑检查基于代码注释和函数名推断其意图检查逻辑是否正确、有无边界条件未处理。生成审查报告综合以上四步结果生成一份友好的、鼓励性的审查报告先总结优点再列出待改进点并为每个点提供修改示例。注意如果代码为空或无法解析直接输出‘无法审查’并停止后续步骤。”经验之谈这是目前工业界落地最广的“规划”方式尤其适用于客服、审核、数据ETL等场景。它的优势是完全可控、结果稳定、速度快。缺点自然是灵活性差无法处理提示词未涵盖的异常情况。我的策略是将动态规划与静态提示结合。先用一个“规划器Agent”采用ReAct或ToT来分析用户任务的类型和复杂度。如果是标准任务如“代码审查”、“周报生成”则路由到对应的、带有固定流程提示词的“执行器Agent”如果是非标任务再启用完整的动态规划流程。这样兼顾了效率和灵活性。2.7 基于LLM的规划器评估与选择面对这么多纯LLM规划范式我们该如何选择没有一个范式是万能的。下面这个表格基于我的实战经验从多个维度进行了对比可以帮助你根据任务特性进行选型。规划范式核心思想优点缺点典型适用场景零样本/CoT规划直接要求LLM输出步骤计划简单直接无需复杂框架计划粗糙粒度不一缺乏纠错快速原型、头脑风暴、简单任务分解ReAct思考-行动-观察循环动态适应执行与规划结合框架成熟易循环/发散依赖提示词和工具设计通用任务自动化、需调用外部工具的场景如数据分析、网页操作Tree of Thoughts树状搜索并行探索多条路径能权衡不同选项决策质量高计算成本高多次LLM调用实现复杂游戏、策略决策、创意生成如写作、设计Graph of Thoughts图状结构灵活聚合信息擅长处理信息融合与复杂依赖实现最复杂成本最高概念较新学术研究、综合报告撰写、复杂知识推理Reflexion/Self-Refine从错误中学习迭代优化输出具备持续改进能力结果质量更高反思可能产生幻觉增加不确定性需要长期运行、持续学习的Agent或对输出质量要求极高的场景如文案润色提示词工程规划将固定流程预置到提示词中稳定、高效、可控、成本低完全无灵活性无法处理未知情况流程固定的标准化任务如客服SOP、代码审查、数据清洗流水线选型决策流我通常遵循以下思路任务是否标准化、流程固定是 - 首选提示词工程规划。任务是否需要与外部环境/工具频繁交互是 - 首选ReAct并考虑加入Reflexion提升鲁棒性。任务是否涉及大量创造性选择或关键决策是 - 考虑Tree of Thoughts在关键节点使用。任务是否需要深度整合多源、异构信息是 - 研究Graph of Thoughts评估其必要性。只是需要一个快速计划草案- 使用零样本/CoT规划。2.8 纯LLM规划的共性局限与挑战尽管纯LLM规划取得了惊人进展但我们在欢呼其能力的同时必须清醒地认识到其固有的天花板。这些局限不是某个方法的缺陷而是源于当前LLM本身的技术特性。缺乏真正的世界模型与常识LLM的“规划”是基于统计关联的文本生成而不是基于对物理世界或社会规则的内在理解。它可能规划出一个“先造屋顶再打地基”的建筑步骤因为它在语料中见过这样的句子组合但它不理解其中的因果矛盾。这对于安全关键型应用是致命的。长程依赖与上下文遗忘即使是128K甚至更长上下文的模型在生成长篇、多步骤计划时也容易“忘记”最初的目标或中间的重要约束。规划到第20步时可能已经偏离了第1步设定的核心方向。这限制了其处理超长、复杂任务链的能力。计算成本与延迟ToT、GoT等高级范式需要多次调用LLM成本高昂延迟也大。在实时性要求高的场景如对话机器人、游戏AI这可能不适用。结果的不确定性与幻觉LLM生成的计划可能包含虚构的步骤、不可用的工具或不存在的依赖关系。你需要额外的验证层来确保计划的可行性。对提示词的高度敏感规划的质量极度依赖于提示词的设计。一个词的改动可能导致完全不同的规划路径和结果。这给开发和维护带来了很大挑战。正因为这些局限我们才需要看向另一条道路混合规划模式。通过将LLM与符号推理、搜索算法、形式化验证等传统AI技术结合我们可以构建出更可靠、更高效、更具可解释性的规划智能体。这将是下一部分我们要深入探讨的内容。我们将看到如何用LLM的创造性思维来弥补传统规划器的死板又如何用传统规划器的严谨来约束LLM的天马行空从而实现真正的优势互补。