AI Agent：规划调研

本文是对 LLM Agent 领域的 Planning（规划）技术的调研。首发于北京邮电大学自邮之翼团队。

1 背景

1.1 规划

• 规划的核心在于创建一系列行动以达成特定目标。复杂任务会被分解成更小的、可以原子性执行的步骤。
• AI 领域的传统规划主要依赖符号方法（PDDL，Planning Domain Definition Language）或强化学习方法，但需要手工将自然语言转化成符号模型，容错低成本高。
• LLM 出现后成为灵活通用的“规则引擎”，驱动规划能力的实现。“规划”成为“智能体编排（Agent Orchestration）”的核心。

1.2 “单点智能”到多智能体系统

• 单智能体：一个 LLM Agent 通过推理、分解任务、生成步骤、调用工具等方式，独立串行完成整个任务的规划与执行。没有角色分工，没有并发执行。
• 不能解决愈加复杂的用户任务：对于“规划+执行”的长链条和复杂推理时，由于上下文窗口限制和多轮次对话的错误积累，规划会迅速偏离。
• 于是将“规划+执行”解耦，演进为基于 LLM 的多智能体系统（LLM-based Multi-Agent Systems, MAS），协作式分层编排。顶层通常设有 LLM 驱动的 Superviser/Planner智能体，负责整体规划和任务分解，底层工具智能体执行具体功能，各智能体通过编排协作完成端到端任务。

1.3 多智能体系统架构

趋同为一种主流的“Supervisor-Worker”架构：

• 顶层：supervisor/planner。一个 LLM 驱动的高级智能体，负责控制、规划和任务分解。
• 底层：tool agents。多个专用的工具智能体。

2. 需求

通过优化多智能体系统编排和 planner 智能体，使得 planner 具有以下能力：

• 任务分解：将全局任务分解为若干个可以由单个 agent 执行完成的子任务。
• 资源协调管理：planner 需要理解每个 worker 的角色和能力，包括名称、描述、输入参数和输出结果。
• 参数槽位填充：planner 需要通过 LLM 从任务的自然语言描述中提取出执行任务的 agent 需要的参数。
• 依赖关系管理：识别并管理子任务间存在的依赖关系，合理安排子任务顺序。
• 根据反馈动态调整：planner 不只是一个“分解器”，还需要具备根据中间结果或变化的用户需求调整后续计划的能力。
• 强鲁棒性：对于没有能力完成的任务，及时抛出异常通知用户。对于不确定的任务规划结果，需要用户确认或修改。

3. 产品

3.1 AutoGPT

基于 GPT-4 的开源项目（GitHub 140k stars），可以接收一个高级目标，将其分解成若干个子任务，并按顺序或并发执行这些子任务，直至目标达成。AutoGPT 的独立性使得用户无需指导每一步操作，只需要定义预期结果，系统可以自主规划确定必要步骤。

特性

• 自主任务执行 ：将复杂的目标分解成更小的步骤，并在最少的监督下执行这些步骤。
• 内存管理 ：利用短期记忆维护上下文，并利用向量数据库进行跨项目的长期记忆管理。
• 互联网和 API 访问 ：检索实时数据并与 Google Sheets、Slack 或 Trello 等工具集成。
• 多智能体协作 ：不同的智能体负责研究、分析和内容生成，同时协调结果。
• 多模态处理 ：可处理文本、图像和其他数据类型，以获得更丰富的洞察。

Classic 架构（旧）

单代理循环，只有一个核心的 LLM 在一个循环中工作。
它通过一个非常复杂的提示词（Prompt），_强迫_这个单一的 LLM 在每一步同时扮演多个角色：

• 它要「思考」(Thoughts)

• 它要「推理」(Reasoning)

• 它要「自我批评」(Criticism)

• 它要「规划下一步」(Plan)

• 它要「输出一个具体命令」(Command)

  

Forge 架构（新）

多代理协作，它把原始 Auto-GPT 循环中由_一个_ LLM 承担的不同职责拆分成了多个独立的的 Agent。

工作原理

1. 接收用户输入：提供一个高级目标和任意背景和限制信息，如“制定营销计划”。目标解读 agent 会从中提取指导后续行动的细节。
2. 创建任务：将目标分解成更小的可执行的子任务，如制定营销计划可能包括调研、内容创作和安排营销活动。
3. 任务优先级排序：优先级排序 agent 会根据依赖关系、紧急程度和可用资源，对这些子任务进行逻辑排序。
4. 任务执行：执行 agent 负责执行任务，包括研究、生成、计划等。
5. 反馈与改进：自我改进 agent 会评估输出结果，识别不足或错误，并优化任务。这种迭代循环确保 AutoGPT 无需人工干预即可持续改进结果。
6. 任务完成后报告：所有子任务完成后，最终输出结果将汇总并呈现给用户。报告 agent 还可以提供见解、建议或对未来任务的调整。如有需要，可以重复某些步骤以提高准确性和质量。

局限性

• 依赖 GPT-4 生成输出，在多个步骤中自主运行时会出现错误、幻觉的积累。且不支持其他厂商的 LLM。
• 使用成本高。
• 由于提供的功能和分解任务的能力有限，可能陷入无限循环
• 缺乏长期记忆，无法跨多个对话保留上下文信息。

它被广泛认为“不适合生产准备”，是一个概念验证而非工程方案。

3.2 Gemini DeepResearch

“Gemini Deep Research 旨在通过分解复杂的研究任务，探索网络资源（如果您选择的话，还可以探索您的工作区内容）来寻找答案，并将研究结果综合成全面的研究成果，从而帮助您解决这些复杂的研究任务。”

工作流程

1. 接收到用户的复杂查询后，系统的第一个动作不是立即搜索答案，而是制定一个详细的、结构化的研究计划，将问题分解成一系列更小、更易于管理的子任务。

2. Human-in-the-loop：第一步的计划并不会立即执行，而是呈现给用户。用户可以控制该计划并进行完善。这将 LLM 潜在的“黑盒”规划过程“白盒化”，极大地提高了复杂研究任务的可靠性，防止了 AI 在错误的路径上“自主”地浪费时间和计算资源。

3. 智能编排：用户批准研究计划后，进入执行阶段。模型会“智能地确定哪些子任务可以同时处理（simultaneously），哪些需要按顺序完成（sequentially）”。这表明系统不仅仅是在执行一个线性的待办事项列表，而是可能在内部构建了一个依赖关系图（LangGraph）。
4. 调用工具并动态调整：“利用搜索和网页浏览等工具获取信息并进行推理。在每个步骤中，模型都会对可用信息进行推理，识别缺失的信息和需要探究的差异，以决定下一步行动”，这里需要在全面性、计算量和用户等待时间之间进行权衡。
5. 实时展示思考过程：思考面板供用户了解模型目前为止的学习成果以及下一步的行动计划。

6. 综合评估并交付：“模型一旦确定已收集到足够的信息，便会将分析结果综合成一份全面的报告”。这个结果不只是简单的信息拼接，而是“批判性地评估所收集的信息”（甚至多次），识别关键主题和潜在的不一致之处，以提高报告的清晰度和细节丰富度。推测可能存在“评估者”角色。（LangGraph 实现循环和分支）

概括来说，Gemini Deep Research 的 核心是 ReAct + 函数调用 + Gemini Thinking。

Gemini Thinking（模型层）

Gemini 模型内置的 Thinking 机制。

• 演进：
  • Gemini 2.0 之前：CoT
  • 从 Gemini 2.0 Flash Thinking 开始，将推理能力内置到模型架构中，推出“思考模型”（Thinking Models）
• 核心特征：通过训练，实现在相应之前推理其思想，从而提高性能和准确性。即模型会首先在内部进行“思考”，生成一系列“原始思想”，然后再基于这些思想合成最终的、更高质量的答案。
• API 化：开发者可通过thinkingBudget 参数来精确指导模型在生成响应时应使用多少思考令牌。

• 值得参考的是，Gemini 将任务复杂性划分为以下三个等级：
  • 简单任务（无需思考）：对于不需要复杂推理的简单请求（例如事实检索或分类），无需思考。例如：
    • “DeepMind 是在哪里成立的？”
    • “这封电子邮件是要求安排会议，还是仅提供信息？”
  • 中等任务（默认/需要一定程度的思考）：许多常见请求都需要一定程度的分步处理或更深入的理解。Gemini 可以灵活运用思考能力来处理以下任务：
    • 将光合作用和成长进行类比。
    • 比较并对比电动汽车和混合动力汽车。
  • 困难任务（最大思考能力）：对于真正复杂的挑战，例如解决复杂的数学问题或编码任务，我们建议设置较高的思考预算。这类任务要求模型充分发挥推理和规划能力，通常需要经过许多内部步骤才能提供答案。例如：
    • 解决 2025 年 AIME 中的问题 1：求出所有整数基数 b > 9 的和，使得 17(b) 是 97(b) 的除数。
    • 为可直观呈现实时股票市场数据的 Web 应用编写 Python 代码，包括用户身份验证。尽可能提高效率。

Gemini Deep Think（算法层）

“Deep Think” 是 Gemini 2.5 Pro 的一种“增强推理模式”，目前仅向 Google AI Ultra 订阅者提供。

• ToT（Tree of Thoughts）
  • 传统的 CoT 推理是一条_链_：A -> B -> C。如果在 B 步出错，整个推理就会失败。
  • ToT 是一棵树：在 A 点，模型会探索多个并行的下一步（A -> B1, A -> B2, A -> B3），然后评估这些分支，只保留最有希望的分支进入下一步（例如 B2 -> C1, B2 -> C2）。
• RL：如果 ToT 负责生成一个巨大的可能性“树”，那么 RL 就负责对这棵树进行导航和剪枝。RL 被训练成一个“评估函数”，用于判断“思想树”中的哪些分支（即“推理路径”）更有前途，从而引导模型将计算资源（即“思考时间”）集中在这些高价值的路径上。
• Multi-agent 协同：使用结构化路由系统，将查询分配给专用内部代理

这种架构将 LLM 从一个“回答者”（生成下一个最可能的词）转变为一个“问题解决者”（在一个巨大的内部“规划空间”中搜索最佳的解决方案路径）。

• Gemini Deep Research 的局限性：
  • 内部机制封闭，扩展受限
  • 推理成本高，延迟高。（平均一次 Deep Research 调用应答超过 5 分钟）
  • 继承了 ReAct 架构“短视”的局限性，缺乏对最终目标的高层规划。在处理长时序任务时难以维持连贯的策略。
  • Human-in-the-loop 仅支持第一步的规划，在后续的 ReAct 规划的过程中用户无法参与。

4 技术

《Empowering Real-World: A Survey on the Technology, Practice, and Evaluation of LLM-driven Industry Agents》（2025.10.20）：哈工大深圳 & 华为提出 L1-L5 工业 Agent 能力成熟度框架，把“记忆-规划-工具”三大技术的演进与产业场景一一映射，给出可量化的“爬级”路线。

本文认为，从技术角度看，Agent 的规划能力具备 L1-L5 层级：

1. 线性规划（L1） → CoT、Re-Prompting、Zero-shot-CoT
2. 反应式规划（L2） → ReAct、Plan-and-Act、LLM+PDDL、DEPS、ProgPrompt、Routine、PoT
3. 全局规划（L3） → Tree-of-Thought、LLM-MCTS、Reflexion、 Planning with World Model、CRITIC、LEMA
4. 协同规划（L4）→ HuggingGPT、CodeEdu、RIDAS、Aime
5. 自主目标规划（L5） → Towards AI Urban Planner、SE-VLN

4.1 Chain-of-Thought (CoT)

• 论文：https://arxiv.org/abs/2201.11903（2022年）。之后提出了众多跟进研究和扩展。
• 背景问题：LLM 直接推理答案时，对长链的推理失效，缺乏可解释性
• 核心思想：要求模型“思考每一步”，在生成答案前给出详细的推理链（即 step-wise reasoning）。
• 用途：任务分解，生成子任务。适用于线性推理型多步问题，可做复合Agent的模块基础。
• 实现
  • Prompt 引导。如“让我们一步步来”、“请一步步推理出任务的关键步骤，再给出最终的计划方案。”。
  • 格式化推理模板，如：

任务: 为一个在线购物系统设计库存检查模块
请输出：
1. 思考过程（思考任务目标、约束、关键模块）
2. 最终计划（关键步骤列表）

请注意：先输出你的思考过程，再输出计划。

-  Few-shot / Zero-shot CoT：添加 0 条或若干条带有推理步骤的“示例样本”，让模型模仿这种推理格式。

• 实验和结果
  
• 局限性：对长链、动态任务适应性弱
• 后续研究：Chain-of-X、Multimodal-CoT、SCOTT和KAM-CoT等结构性扩展。

改进：自我一致性（Self-Consistency）

• 提出：Self-Consistency Improves Chain of Thought Reasoning in Language Models（2023）
• 目的：消除 CoT 单次推理的随机错误，增强逻辑一致性和鲁棒性。
• 工作机制：模型多次思考同一个问题，然后选出最一致、最合理的答案。
  • 对同一个问题，用相同的 CoT 提示，多次采样生成不同的推理路径（因为生成过程有随机性）。
  • 每条推理链都会得出一个最终答案。
  • 统计这些答案的分布，选择出现频率最高的结果作为最终输出。
• 示例：

  问题：“一个农夫有 17 头牛，除了 9 头之外都死了，还剩几头？”
  第一次思考：17-9=8 → 答案：8
  第二次思考：理解错题意，答：9
  第三次思考：再算一次，答：8
  最后：出现次数最多的是 8 → 选 8 为最终答案。

4.2 ReAct (Reasoning and Acting)

• 论文：ReAct: Synergizing Reasoning and Acting in Language Models（2023）
• 背景问题：静态规划难以应对动态环境与工具交互，CoT 缺乏和外部世界的接触且无法更新知识，导致幻觉和错误。
• 核心思想：提示 LLM 为任务生成口头推理轨迹和操作，使得系统可以执行动态推理来创建、调整下一步计划。
• 实现：在每轮交互中输出“思考、操作、观察（Thought、Action、Observation）”格式的轨迹环路。先思考当前情况、然后决定采取哪个行动（如调用工具、查找信息），再根据反馈继续思考。如：

  问题 科罗拉多造山带东部区域延伸到的区域的海拔范围是多少?
  思考 1 我需要搜索科罗拉多造山带，找到科罗拉多造山带东段延伸的区域，然后找到该区域的海拔范围。
  操作 1 搜索 [科罗拉多造山带]
  观察 1 科罗拉多造山带是科罗拉多及其周边地区造山运动的一段。
  思考 2 它没有提到东部地区。所以我需要查一下东部地区。
  操作 2 查找 [东部地区]
  观察 2 (结果 1 / 1) 东部区域延伸至高平原，称为中原造山带。
  思考 3 科罗拉多造山运动的东部区域延伸到高平原。所以我需要搜索高平原，找到它的海拔范围。
  操作 3 搜索 [高平原]
  观察 3 高平原指的是两个截然不同的陆地区域之一。
  思考 4 我需要搜索高平原（美国）
  操作 4 搜索 [高平原（美国）]
  观察 4 高平原是大平原的一个分区。从东到西，高平原的海拔从 1800 到 7000 英尺 (550 到 2130 米) 不等。[3]
  思考 5 高平原海拔高度从 1800 到 7000 英尺，所以答案是 1800 到 7000 英尺。
  操作 5 结束 [1800 到 7000 英尺]

• 不同的提示设置用于不同类型的任务。

  • 推理型任务：多思考-操作-观察步骤用于任务-解决轨迹。
  • 涉及许多操作步骤的决策任务：较少使用思考。

• 实验和结果：

  • 在知识密集型任务上：
    • 基准：问答 HotPotQA、事实验证 Fever
    • 结果：
      • ReAct 表现结果通常优于 Act (只涉及操作)
      • ReAct 在 Fever 上的表现优于 CoT，而在 HotpotQA 上落后于 CoT。
      • ReAct 在很大程度上依赖于它正在检索的信息;非信息性搜索结果阻碍了模型推理，并导致难以恢复和重新形成思想
      • 结合在 ReAct + CoT +自我一致性之间切换的提示方法通常优于所有其他提示方法。

  

  • 在决策型任务上

    • 基准：ALFWorld (基于文本的游戏) 和 WebShop (在线购物网站环境)
    • 结果：ReAct 在 ALFWorld 和 Webshop 上都优于 Act。

• 局限性：
  • ReAct 需要 LLM 扮演“决策者”和“执行者”双重角色，在几百步的长时序任务中存在巨大的“认知负荷”，导致模型“难以维持连贯的策略” 。
  • ReAct 循环本质上是“短视的”，缺乏对最终目标的高层规划。这使得 ReAct 对环境的非预期变化极其敏感。一旦出错，它很难从根本上“重新规划”，而是倾向于在错误的路径上进行“战术修补”，导致错误不断累积。
  • ReAct 高度依赖提示词中的 few-shot 提示，即提示词中“示例”与“查询”之间的句法相似性。当面对与示例不相似的新颖任务时，ReAct 的性能会急剧下降。

4.3 Plan-and-Act

• 论文：Plan-and-Act: Improving Planning of Agents for Long-Horizon Tasks（2025）
• 背景问题：ReAct 的局限性
• 核心思想：将“规划”和“执行”解耦分层。
  • Planner：接收初始用户查询，将其分解为“结构化的、高级的计划步骤”。它只关心“做什么”（What）和“为什么做”（Why）的战略层面，而不必分心去处理“如何做”（How）的繁琐实现细节。
  • Executor：接收来自 Planner 的单步高级指令（例如，“导航到贡献者页面”）。它的唯一任务是“翻译”这个高级指令，在环境中执行一系列具体的、低级的动作，如执行内部函数或调用外部工具，直到完成该步骤。
  • 动态重规划：
    • ReAct 的 Observation 仅用于指导 下一个 Thought 和 Action。这使得 ReAct 是一个反应式 (Reactive) 系统。
    • Plan-and-Act 的 Observation 被反馈给最高层的 Planner，Planner 会评估该观察对整个剩余计划的战略影响，并决定是继续、修正还是彻底放弃当前计划。这使得 Plan-and-Act 是一个更高级的审议式 (Deliberative) 系统。

• 实现：模型微调（planner 模型和 executor 模型），同时打造一个创建训练数据的可扩展的数据引擎
• 实验和结果
  
• 局限性
  • 模型微调时对基线模型高度依赖。
  • 成本和延迟更高，ReAct 理论上只需一次 LLM 调用（生成 T 和 A）。而 Plan-and-Act 涉及 Planner 和 Executor 之间的多次通信，且 Planner 可能在途中被_反复调用_以进行重规划。
  • 必须确保 Planner 生成的“高级指令”能被 Executor 准确理解和可靠执行。如果 Planner 的指令过于模糊，或者 Executor 的能力（工具）无法实现该指令，系统就会崩溃。

4.4 LLM+PDDL 符号规划

• 背景：PDDL（Planning Domain Definition Language）是传统 AI 中用于符号规划的标准形式语言，可以定义 domain（动作模型）与 problem（初始状态、目标状态），通过符号规划器求得形式上可验证的 plan。如下是一个示例的 domain.pddl 文件。

(define (domain blocks)
  (:predicates 
    (on ?x ?y)        ; x 在 y 上
    (ontable ?x)      ; x 在桌子上
    (clear ?x)        ; x 上没有别的东西
    (handempty)       ; 手是空的
    (holding ?x))     ; 手里拿着 x
  
  (:action pickup
    :parameters (?x)
    :precondition (and (clear ?x) (ontable ?x) (handempty))
    :effect (and (holding ?x)
                 (not (ontable ?x))
                 (not (clear ?x))
                 (not (handempty))))
)

• 工作流程：
  1. 用自然语言描述任务
  2. 让 LLM 理解并自动生成 PDDL
  3. 交由符号规划器执行
  4. LLM 解释执行结果
• 发展
  • Toward PDDL Planning Copilot（2025-09-16）提出并实现了 Planning Copilot：把经典 PDDL 自动规划工具（planner、validator、simulator 等）通过 MCP 暴露给 LLM，让 LLM 以自然语言调用这些工具完成 solve / validate / simulate 三类规划任务。
• 实验和结果：
  
• 局限性：PDDL 依赖 LLM 输出，不稳定

4.5 Routine

来自 Digital China AI Research 的《Routine: A Structural Planning Framework for LLM Agent System in Enterprise》（2025-07-22）

• 定位：企业环境中的规划。（需要依赖领域知识、保证稳定性）

• Routine 框架本质是一个结构化的、面向任务的规划脚本。它不再让模型在规划时进行完全自主、不可预测的“自由发挥”，而是像一份详尽的 SOP，清晰地指导模型每一步应该做什么、调用哪个工具。

• 流程：

  1. 预定义：专家会为特定场景（sub-scenarios）定义好草稿，并由 LLM 优化成结构化的 Routine。
  2. 存储记忆库：将所有预定义好的 routine 存储在“规程记忆库”中。
  3. 运行时检索：当查询到来时，系统并不是去“规划”一个新流程，而是去记忆库中检索出最匹配的那一个 Routine。
  4. 按照 Routine 执行：MCP 严格遵守 Routine 计划调用工具。可能涉及到动态执行，如分支跳转。
     

• 增强：

  • 通用Routine遵循能力训练：使用开源的多工具数据集（BUTTON），通过GPT-4o生成对应的Routine，然后用这些数据对模型进行微调。目的是让模型学会理解并遵循 Routine 这种结构化指令的语法。
  • 特定场景知识蒸馏：将 Routine 知识蒸馏到模型中，让模型在特定业务场景下，即使没有显式给出Routine“剧本”，也能稳定进行多步骤工具调用。

• 结果

  • 在没有Routine指导时，GPT-4o多步工具调用的确率也仅有41.1%。引入Routine后，其准确率升至96.3%。对于Qwen3-14B，效果同样显著，准确率从**32.6%提升到83.3%**。

4.6 ToT(Tree-of-Thought) 思维树

• 论文：Tree of Thoughts: Deliberate Problem Solving with Large Language Models（2023）
• 背景问题：
  • 许多 Agent 规划问题不是线性的、逐步思考的序列生成问题（CoT 的链式结构），而是 AI 领域的搜索问题，解决这些问题需要在一个组合的问题空间中进行搜索。
  • ToT 是 CoT 的泛化，CoT 是 ToT 的一种特殊情况，即每个树的节点只有一个分支。
• 核心思想：
  • 从链到树：维护着一棵思维树，节点代表部分解决方案。这种结构使得 LLM 能同时考虑不同的推理路径。
  • Thought（思维）作为基本的语义搜索单元。思维由连贯的语言序列表示，这个序列就是解决问题的中间步骤。
  • LLM 作为生成器和评估器，循环下面的过程：
    • 生成下一步分支
    • 评估新生成的 Thought
    • 根据评估分数，使用 BFS/DFS 等搜索算法决定下一个节点，实现前瞻和回溯

• 实验和结果：ToT 在 24点游戏、创意写作、迷你填字游戏中都显著优于所有基线方法。

• 局限性：
  • 搜索开销大，在不需要广泛探索的任务中表现低效。
  • 强依赖于 LLM 的自我评估能力，可靠性低。
  • 提示词设计难度远超 CoT 。
• 后续研究：Graph-of-Thoughts (GoT)、Forest-of-Thought (FoT)

4.7 LLM-MCTS（蒙特卡洛树搜索）

• 论文：Large Language Models as Commonsense Knowledge for Large-Scale Task Planning（2023）
• 背景问题：长时序规划中，LLM 的自回归机制导致短视（贪婪决策）、缺乏系统性探索与回溯，难以实现全局最优规划。结合 LLM 的推理能力与 MCTS 的探索-利用平衡与回溯机制。
• 核心思想：
  • LLM 生成多条分支，即思考路径（如 CoT），MCTS算法对这些路径进行采样、评分与优化，形成树状结构，不断扩展和剪枝。
  • LLM 在每次节点扩展时进行策略评估，MCTS 根据奖励反馈评估该节点优劣，并通过回溯传播奖励信息，决定全局最优动作。

• 实验和结果
  
• 局限性：
  • 高成本、高延迟
  • 奖励函数设计：MCTS 是一个最大化奖励的算法，需要有清晰、可量化的奖励信号

4.8 Reflexion 自我反思

• 论文：Reflexion: Language Agents with Verbal Reinforcement Learning（2023）
  • 代码：https://github.com/noahshinn/reflexion
• 背景问题：LLM Agent 缺乏自我反思/错误修正机制，无法系统性地学习并优化自身决策
• 核心思想：“反思-学习”闭环：每次任务完成后，回顾决策轨迹，输出标准化反思文本，并存入长期记忆，为下一轮 LLM 对话提供上下文。下次遇到类似任务时主动改进，提高长期任务表现。
• 实现：常基于ReAct架构拓展。Reflexion 由三个不同的模型组成：
  • 参与者（Actor）：根据环境观测和记忆生成内部推理和外部动作。常见实现方式有 CoT 和 ReAct。
  • 评估者（Evaluator）：使用不同的奖励函数，评估 Actor 生成的轨迹的质量，输出奖励分数。
  • 自我反思（Self-Reflection）：Reflecxion 的核心，一个 LLM。它将 Evaluator 提供的“稀疏”反馈（如二元成功/失败），“放大”成“丰富的”或“详细的”自然语言经验总结，即“反思文本”，并存储在记忆组件中。智能体利用这些经验来快速改进决策。
    
• 与 ReAct 的关系：Reflexion 不是 ReAct 的替代品，而是 ReAct 的一个“元框架”或增强器。
  • ReAct 定义了轨迹内的“推理+行动”循环
  • Reflexion 定义了轨迹间（inter-trajectory）的“执行+反思”循环。
  • 在 Reflexion 的典型实现中，ReAct 被用作其 Actor 角色的具体实现 。
• 实验和结果：Reflexion 能够显著提高 AlfWorld 上的决策任务、HotPotQA 中的问题推理以及在 HumanEval 上的 Python 编程任务性能，显著优于所有基线方法。

• 局限性：
  • 依赖自我反思机制：智能体无法纠正一个它不知道是错误的错误，甚至强化错误。且一开始的任务表现可能不好.
  • 长期记忆限制：需要使用最大容量的上下文窗口，滑动窗口仅保留最后 N 次反思，不能处理长序列任务。

4.9 PlanGEN

• 论文：PlanGEN: A Multi-Agent Framework for Generating Planning and Reasoning Trajectories for Complex Problem Solving.（2025-02 Google）
• 背景问题：
  • 现有 LLM 规划在生成解决方案时没有验证其正确性，忽视了任务的约束
  • 算法僵化：一旦选定算法（如 ToT、Reflextion）就会不加调整地应用
  • 简单任务在复杂算法下资源浪费，复杂任务在简单算法下性能不佳。
• 核心思想：构建了新的编排层，整合各种算法。
  • “规划-验证-选择”循环
    1. 初始规划：接收用户输入后，基础 LLM 生成一个初始计划。
    2. 约束提取：“约束 Agent”分析原始任务描述，生成约束列表
    3. 首次验证：“验证 Agent”获取初始计划和约束列表，对计划进行评估，并给出“奖励分数”
    4. 决策点：系统检查分数是否低于预设阈值：
       1. 若达标，循环终止，输出计划
       2. 若不达标，启动“循环迭代”循环
    5. 算法选择：“选择 Agent”基于问题复杂度、约束、反馈等信息，在算法池中选择一个最合适的算法
    6. 执行：选中的算法被执行，生成一个更新后的计划
    7. 再次验证：“验证 Agent”使用相同的约束列表评估更新后的计划，并提供新的分数和反馈
    8. 返回决策点，不断迭代，直至分数达标或到达迭代次数。

• 实验和结果
  
• 局限性：
  • 巨大开销：多次与 LLM 交互，选择的算法（如 ToT）可能达数十次
  • 递归验证：无法验证“验证 Agent”的正确性

4.10 HuggingGPT

• 论文：HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face
  • 核心 Repo：
    • https://github.com/microsoft/JARVIS
    • https://github.com/AI-Chef/HuggingGPT
• 背景问题：AI 领域中存在“推理能力强的LLM”与“执行能力强的专家模型”之间的脱节
• 核心思想：构建一个“LLM驱动的智能体”。LLM的职责不是亲自_解决_用户的多模态任务，而是_管理_一个庞大的、由“众多专家模型组成的协作执行器”（特别是 Hugging Face Hub）。
  • 任务规划：LLM 对用户请求进行规划，将请求分解为可能的可解决任务，同时确定任务的执行顺序以及任务之间的资源依赖关系。
    1. 为了让LM做高效的任务规划，HuggingGPT在设计中使用specification-based instruction和demonstration-based parsing。
    2. Specification-based Instruction：Task specification提供一个统一的模板来允许LLM进行任务解析。HuggingGPT提供四个槽，分别是task type，task ID，task dependencies和task arguments
    3. Demonstration-based Parsing：每个demonstration是一组在任务规划上的输入和输出，输入是用户的请求，输出是期望的任务序列。即 demonstration 包含解析任务之间的依赖，能有效帮助 HuggingGPT 理解任务之间的逻辑关系，并且决定执行顺序和资源依赖。

- 模型选择：对于每一个子任务，LLM充当“调度中心”，根据Hugging Face上可用的模型功能描述来选择最合适的专家模型。
- 任务执行：使用选择的模型执行任务，总结成回答返回给 LLM
- 回答生成：使用 LLM 融合所有模型的推理，生成回答返回给用户

• 实验和结果：系统的最终表现对控制器（LLM）的推理质量极其敏感。只能是概念验证，缺乏自动化任务基准
  
• 局限性
  • 性能瓶颈：需要多次与 LLM 交互（1次规划、1次模型选择、1次响应生成），且是顺序的、阻塞式的
  • 受上下文长度限制，限制了任务规划所能包含的最大步骤数
  • 鲁棒性差：严重依赖 LLM 的能力，不能处理 LLM 生成错误或执行器失败

横向对比

技术名称	所属层级	核心思想	优势	局限性	典型应用 / 框架
CoT	L1 线性规划	通过显式推理链提高可解释性与逻辑性	简单有效，增强推理透明度	无动态调整能力，易累积误差	推理任务、数学题、多步问答
ReAct	L2 反应式规划	思考+操作+观察的交互式推理	能动态调用工具，应对开放环境	“短视”，对长链任务不稳	动作式任务、网页导航
Plan-and-Act	L2 反应式规划	将“规划”与“执行”分层解耦	提高长时序任务一致性	成本高，通信频繁	长任务执行、具反馈的规划
LLM+PDDL	L2 反应式规划	自然语言到符号规划的桥梁	形式化强，可验证性高	对LLM输出依赖高，不稳定	工业自动化、任务验证
Routine	L2–L3 过渡层	结构化任务模板（SOP式规划）	稳定可靠、企业可控	通用性差，需预定义	企业流程编排、工业Agent
ToT（Tree-of-Thought）	L3 全局规划	并行搜索多推理路径	全局最优，抗局部陷阱	搜索开销大、提示复杂	创意生成、复杂推理
LLM-MCTS	L3 全局规划	LLM + 蒙特卡洛树搜索结合	具探索与回溯能力	高延迟、奖励设计难	任务规划、博弈类问题
Reflexion	L3 全局规划	自我反思+经验积累提升策略	可自我改进、长期学习	初期表现差、记忆有限	交互式Agent、持续学习
PlanGEN	L3 全局规划	动态选择最优算法的多Agent编排	灵活自适应、自动验证	成本极高、验证困难	多算法Agent系统
HuggingGPT	L4 协同规划	LLM调度专家模型协同执行	扩展强，任务多样	性能瓶颈、鲁棒性低	多模态任务编排

5 评估

用于评估 Agent Planning 能力的 Benchmark 有：

• GSM8K：提供需要多步推理的小学数学应用题。
• HotpotQA：通过基于维基百科的问答来评估多文档推理能力。
• TextAtari：将雅达利（Atari）游戏状态转换为文本描述，创建了近100个任务来测试决策过程。
• FlowBench：这是首个以工作流为导向的规划基准，涵盖6个领域的51个场景，提供多格式知识表示和多级别评估。
• Self-Reflection Benchmark：该基准证明了迭代反思机制可以显著提高LLM在解决问题任务中的表现。
• Reflection-Bench：受认知心理学启发，提供了七个任务来评估模型在预测、决策和反事实推理中的认知能力。
• PDDL-to-NL：一个能够对LLM在PDDL（规划领域定义语言）规划任务中进行大规模评估的框架。

根据 SiliconFlow 的《Ultimate Guide - The Best Open Source LLM for Planning Tasks in 2025》，规划任务最佳的开源 LLM 是：DeepSeek-R1、Qwen3-30B-A3B-Thinking-2507 和 GLM-4.5-Air。

参考资料：

1. Empowering Real-World: A Survey on the Technology, Practice, and Evaluation of LLM-driven Industry Agents https://arxiv.org/pdf/2510.17491
2. AgentOrchestra: A Hierarchical Multi-Agent Framework for General-Purpose Task Solving https://arxiv.org/abs/2506.12508v1
3. Ultimate Guide - The Best Open Source LLM for Planning Tasks in 2025 https://www.siliconflow.com/articles/en/best-open-source-LLM-for-Planning-Tasks
4. autoGPT https://github.com/Significant-Gravitas/AutoGPT?tab=readme-ov-file
5. 什么是 AutoGPT？ https://www.ibm.com/cn-zh/think/topics/autogpt
6. Gemini Deep Research https://gemini.google/overview/deep-research/
7. lanGEN: A Multi-Agent Framework for Generating Planning and Reasoning Trajectories for Complex Problem Solving https://arxiv.org/abs/2502.16111
8. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models https://arxiv.org/abs/2201.11903
9. A Survey of Chain of Thought Reasoning: Advances, Frontiers and Future https://github.com/zchuz/CoT-Reasoning-Survey
10. Self-Consistency Improves Chain of Thought Reasoning in Language Models https://arxiv.org/abs/2203.11171
11. ReAct: Synergizing Reasoning and Acting in Language Models https://arxiv.org/abs/2210.03629
12. Prompt Engineering Guide: ReAct https://www.promptingguide.ai/zh/techniques/react
13. Plan-and-Act: Improving Planning of Agents for Long-Horizon Tasks https://arxiv.org/abs/2503.09572
14. Toward PDDLPlanning Copilot https://arxiv.org/abs/2509.12987v1
15. Tree of Thoughts: Deliberate Problem Solving with Large Language Models https://arxiv.org/abs/2305.10601
16. LLM-MCTS https://llm-mcts.github.io/
17. HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face https://arxiv.org/abs/2303.17580