Tree-Planner

这是一份写给"完全没接触过 AI"的读者看的精读笔记。术语首次出现配类比，公式翻译成人话。

一句话讲什么（TL;DR）

让大模型一次写好十份"菜谱"，把重复步骤合成一棵树，做事时照树走，错了就换条岔路，全程不用反复打电话问。既省 LLM 调用，又自带纠错。

所以这一节是想说：Tree-Planner 用"一次采样多条计划 + 合并成树 + 树上执行回溯"把 LLM 规划做得又省又稳。

---

这是个什么场景

周末你想做一顿西红柿炒鸡蛋，但你完全不会做饭，得边问边学。

朴素做法：每切一刀、每开一次火都掏出手机打电话问大厨"下一步呢？"。每问一次 5 块钱话费，大厨还记不住你刚才问过啥，可能上一句让你"放盐"下一句又让你"加糖"，前后打架。

Tree-Planner 的做法：一开口就让大厨一口气写下 10 份完整菜谱。10 份菜谱开头几步几乎一模一样（"洗西红柿、打鸡蛋"），把这些重复步骤合并掉，只在大厨意见不一致的地方留出岔路——这就成了一棵"动作树"：树根是共同开头，越往后岔路越多。

做菜时你照树走，遇到岔路口看锅里现在啥情况、挑最合适的一条；如果这条路烧糊了（这一步在真环境里执行失败），就退回上个岔路口换另一条试。整个过程只在最开始打了一通电话。

对应到论文里：机器人在虚拟厨房里完成 "make breakfast" 这类需要十几步动作（拿杯子 → 倒牛奶 → 打开烤箱 → …）的长任务，每一步都得真在环境里执行。

LLM（大语言模型）当规划器（planner）：让大模型把一句自然语言任务（"做早餐"）拆成一串机器人能执行的动作步骤。

所以这一节是想说：Tree-Planner 面对的是"用 LLM 给机器人做长任务规划，但反复问 LLM 又贵又前后不一致"这个矛盾。

---

之前的人怎么做的，为什么不够好

• 迭代式规划（Iterative planning，如 ReAct、Inner Monologue）：每一步都让 LLM 看当前状态再决定下一步。token 消耗大，LLM 还容易"前后失忆"，规划不一致。
• 先规划后执行（Plan-and-Execute，如 SayCan、ProgPrompt）：LLM 一次生成完整计划，机器人照着执行。问题是计划中途出错（环境和预期不符）时没有回退机制。
• 思维树（Tree-of-Thought, 2023）：在推理任务上反复展开树，但每个节点都要再调 LLM 评分，开销大，且面向纯推理不是具身任务。
• 自洽采样（Self-consistency）：多次采样同一问题然后投票，但只用于单步答案，没把多条计划"结构化合并"。

所以这一节是想说：以前要么"每步都问 LLM"（贵又善变），要么"只问一次但不能纠错"，Tree-Planner 想两头的好处都要。

---

这篇论文的新想法

像把十份手抄菜谱叠在一起对齐——你会发现前几页几乎一字不差，差别都在后半段。

核心观察：LLM 一次采样多条计划，里头大量动作前缀是重复的。那为什么不把重复部分合并、只在分歧处留岔口？这样得到一棵"动作树"：从根走到任一叶子是一条完整计划，被合并的节点代表 LLM 在这一步意见一致，分叉则代表它觉得可以有好几种走法。

执行阶段不再问 LLM，而是在这棵已经画好的树上做 grounded 搜索（落地搜索：看环境此刻真能干什么）：环境告诉你当前状态、哪些动作能做，你就在树里挑能走的分支。走错了能回溯到上一个分叉。

收益：

• LLM 调用从 O(计划长度) 降到 O(1)（只有最初采样那次）。
• 错误恢复来自树结构本身，不需要 LLM 重新规划。
• 一次采样多样化的计划，提升整体成功率。

所以这一节是想说：Tree-Planner 的新意是"把多次采样的计划结构化合并成树，执行时在树上落地搜索 + 回溯"，用一次规划换来纠错能力。

---

它分几步做的（方法）

这一节是全篇核心，拆成"采样、建树、落地执行、回溯"四步。

整体流程 ASCII 示意：

   LLM 一次采样 N 条计划 ┐
                          ├─► 合并成前缀树(trie) ─► 执行时: 到每个节点问环境能做啥 ─► 挑能走的分支
   任务+物体+动作+示例 ──┘                              执行失败 ─► 回溯到兄弟/父节点换一条

第 1 步：Plan Sampling（计划采样）——让大厨一口气写 10 份菜谱

输入：一个 prompt——任务描述 + 环境物体列表 + 可用动作列表 + few-shot 示例。

处理：把 LLM 的"温度"调高一点（让它发挥得活泼些），采样 N 条完整计划（N 一般在 10-50 量级，需查原文）。每条计划是一串动作，如 [walk to kitchen, open fridge, grab milk, ...]。

输出：N 条多样化的完整计划。

等等，先慢一拍——temperature（温度） 是什么？可以理解成 LLM 的"放飞程度"：温度低它每次都给最稳妥那份；温度高就允许它写出几份不一样的菜谱，多样性才出得来。多样性很关键——树要能覆盖到正确路径，采样就得够花。

第 2 步：Action Tree Construction（动作树构建）——把 10 份菜谱叠起来对齐

输入：N 条计划。

处理：合并成 trie（前缀树：把相同开头折叠在一起的数据结构）——相同前缀共享一条路径，从第一个分歧点才分叉。一个节点底下挂几个子节点，就代表 N 份计划在这一步提了几种不同的下一步动作。

输出：一棵动作树，最多有 N 条从根到叶子的路径。

trie（前缀树）：把多个序列合并、共享公共前缀的数据结构。这里用它把 N 条计划压成一棵树。

第 3 步：Grounded Deciding（落地执行）——照树走、看锅里实际情况挑岔路

输入：动作树 + 环境当前状态。

处理：agent 在环境里一步步走。每到一个树节点：

• 问环境此刻哪些动作能做（grounding 落地：比如 "milk 不在视野里就不能 grab milk"）。
• 在这个节点的子节点里筛出能做的那几个。
• 若还有多个能做，用启发式排序挑一个（比如哪个子节点下面挂的计划份数最多、或跟当前情境最像）。
• 执行成功就走进这个子节点。

输出：一步步落地执行的动作序列。

第 4 步：Backtracking（回溯）——走迷宫撞墙了退回上个路口

输入：某一步执行失败（动作报错 / 环境反馈和预期不符）。

处理：回到当前节点的兄弟节点试别的；兄弟都试完就退到父节点那一层换条路。一直退到能继续往下走的位置。整个回溯过程不再问 LLM，纯粹在树上做。

输出：一条绕过失败点的可行路径（如果树里存在的话）。

backtracking（回溯）：搜索算法走死路时退回上一个分叉重新选择的机制。这里指执行失败时退回树上的上一个节点。

所以这一节是想说：Tree-Planner 的方法 = 高温采样 N 条计划 + 合并成前缀树 + 落地筛选能走的分支 + 失败时树上回溯，四步把"一次规划"变成"能纠错的规划"。

---

下图概括本篇在「关键数字」节前的核心结果脉络（便于对照后文表格）：

【Tree-Planner · 关键结果概览】

   设定 / 数据          方法要点              主结果
        │                   │                    │
        ▼                   ▼                    ▼
   训练           ──► 方法核心                   ──► …
   评测           ──► 主指标提升                  ──► ↑ 论文主结论

   （对照下方表格中的原文数字与消融）

---

关键数字（What works）

下表整理关键设定与定性结论；具体成功率/token 节省比例请查原文，此处不编造。

维度	说明
主环境	VirtualHome（家庭场景长序任务）
LLM 调用次数	从 O(计划长度) 降到 O(1)（只在采样时调）
采样数 N	一般 10-50 量级（需查原文）
纠错来源	树结构 + 回溯，不再调 LLM
评估指标	成功率、可执行性、LLM token 成本
对比基线	ReAct（迭代）、ProgPrompt（一次性）、单条采样

关键结论：Tree-Planner 相比迭代式方法token 省一到两个数量级，同时因为多采样 + 树回溯，成功率还更高——省钱和更强居然可以兼得。前提是初始采样足够多样，否则树覆盖不到正确路径。

所以这一节是想说：数字告诉我们，把 LLM 调用从"每步一次"压到"总共一次"，不仅没掉分，反而靠树回溯涨了成功率。

---

实验结果说明了什么

主要在 VirtualHome（家庭场景虚拟环境，机器人执行做饭、清洁等长序任务）上做。

评估指标：

• 成功率（Success Rate）：机器人最终是否完成目标。
• 可执行性（Executability）：生成动作中能被环境接受的比例。
• LLM token 成本 / 调用次数：相比迭代方法省多少。

对比基线：迭代规划（ReAct）、一次性规划（ProgPrompt）、单条计划采样。论文一般在多个任务复杂度（短序/长序）上分别报告，并消融 N 和回溯策略的影响。

所以这一节是想说：实验证明"结构化合并多条计划"这个思路在省成本和提成功率上都成立，且对长任务尤其有用。

---

你应该懂的几个新词

• 具身智能体（embodied agent）：在虚拟或真实环境里有"身体"、能感知和执行动作的 agent，输出会改变环境。
• grounding（落地）：把 LLM 输出的"理论动作"对齐到"环境此刻真能执行的动作"。LLM 说 "grab the cup" 但视野里没 cup，这动作就 not grounded。
• trie（前缀树）：把多个序列合并、共享公共前缀的数据结构。
• backtracking（回溯）：走死路时退回上一个分叉重选的机制。
• temperature（温度）：控制 LLM 输出多样性的参数，高温更花、低温更稳。
• Plan-and-Execute vs Iterative Planning：一次给完整计划再执行 vs 每步重新规划。Tree-Planner 介于两者之间——一次规划但留多条路。

所以这一节是想说：这几个词是理解"LLM 做具身规划"这条线的通用语。

---

它有什么搞不定的

• 依赖初始采样质量：如果 N 条计划里没有一条接近正确路径，树里就没答案，回溯也救不了。
• 多样性 vs 正确性两难：温度太低树覆盖不全，太高又可能全是垃圾计划。这个平衡不好调。
• grounding 依赖环境反馈：需要环境能告诉 agent "此刻哪些动作可行"，在反馈稀疏的真实场景里更难。
• 静态树的局限：树是一开始就画死的，遇到采样时完全没预料到的新情况，没法即时生成新分支（不像迭代式能随时问 LLM）。
• 主要在仿真验证：VirtualHome 的动作 API 是离散、干净的，真机的连续、噪声环境会更难。

所以这一节是想说：Tree-Planner 的短板集中在"树是死的、依赖采样覆盖"上——省 LLM 调用的代价是失去了随时重新规划的灵活性。

---

它和别的几篇是什么关系

• vs ReAct / Inner Monologue（迭代式）：Tree-Planner 把 LLM 调用从每步降到一次，token 省一两个数量级；代价是初始采样必须够多样。
• vs SayCan / ProgPrompt（一次性规划）：Tree-Planner 通过多采样 + 树结构具备了错误恢复能力，而单条计划一旦中途出错就完蛋。
• vs Tree-of-Thought（推理任务）：思想类似（搜索树），但 ToT 每个节点都要 LLM 打分扩展，Tree-Planner 一开始就把整棵树物化，执行时不再调 LLM。是 ToT 思想在具身规划上的"廉价化"。
• 后续影响：和 LLM-Planner、AdaPlanner 一起被列为 "LLM as Planner" 范式的代表方法。后续工作会进一步把树结构与世界模型、价值函数结合。

所以这一节是想说：Tree-Planner 是"LLM 做规划"这条线里介于迭代和一次性之间、兼顾省钱和纠错的代表方法。

---

和本导读的关系

本篇对应导读 Ch10: 规划。Ch10 讲 LLM 怎么给机器人做任务规划，核心权衡是"每步问 LLM（灵活但贵）"和"一次给完整计划（省但脆）"。Tree-Planner 正是这个权衡的一个漂亮折中——一次采样、结构化合并、执行时树上纠错。读完本篇，配合同章的 saycan（一次性 + 技能库）、inner-monologue（迭代式），能看清 LLM 规划三种范式的取舍。

所以这一节是想说：把 Tree-Planner 放进 Ch10 的规划主线里读，它是"一次规划 + 结构化纠错"这一格的代表。

---

思考题

Q1：为什么把多条计划合并成前缀树能省下大量 LLM 调用？

提示

迭代式每步都问 LLM（O(计划长度) 次）。Tree-Planner 只在最开始采样时问一次（O(1)），之后执行和纠错全在树上做，不再碰 LLM。这就是省一两个数量级的来源。

Q2：为什么采样温度太低会让 Tree-Planner 失效？

提示

温度低 LLM 每次都给几乎一样的计划，树几乎不分叉，退化成单条计划。没有多样的分支，就没有纠错时可切换的备选路径。

Q3：如果 N 条采样计划里根本没有正确路径，会发生什么？回溯能救吗？

提示

救不了。回溯只能在已有的树分支里换路，树里没有的路径它变不出来。这是静态树相对迭代式（能随时问 LLM 生成新动作）的根本局限。

Q4：在岔路口有多个可执行分支时，用什么启发式挑选比较合理？

提示

论文用"哪个子节点下挂的计划份数最多"（多数投票的空间版）或"跟当前情境最像"。前者利用了采样的集体智慧——多数 LLM 都选的路更可能对。

Q5：Tree-Planner 和 Tree-of-Thought 都用树，为什么前者便宜得多？

提示

ToT 每扩展一个节点都要调 LLM 评分/生成，树是"边搜边长"；Tree-Planner 一次采样就把整棵树物化好，执行时零 LLM 调用。物化 vs 动态扩展的区别。

Q6：把 Tree-Planner 搬到真实机器人（而非 VirtualHome），你预计哪些环节最先出问题？

提示

grounding（判断"此刻哪些动作可行"）在真机上更难，因为感知有噪声、动作有连续性；执行失败的检测也更模糊。仿真里干净的离散反馈是它 work 的隐含前提。

所以这一节是想说：这几个问题带你把"省调用、多样性、静态树局限、启发式选择、物化 vs 动态"这些核心点自己推一遍。

---

一些好奇心问答（FAQ）

Q1：Tree-Planner 需要训练模型吗？

不需要。它是"用现成 LLM 做规划"的方法，靠 prompt + 采样 + 树结构，不训练任何新模型。这也是它工程上轻的原因。

Q2：它能用在任何 LLM 上吗？

原则上可以，只要 LLM 能按 prompt 输出结构化的计划。计划质量取决于底座 LLM 的能力。

Q3：树最多有多少条路径？

最多 N 条（采样了 N 条计划）。合并后节点变少，但从根到叶子的完整路径不超过 N。

Q4：执行失败怎么判断？

靠环境反馈——动作报错、或执行后状态和预期不符。这依赖环境能提供可靠反馈，VirtualHome 这类仿真提供得很干净。

Q5：它和 SayCan 到底差在哪？

SayCan 一次性生成计划、用技能库打分，中途出错没退路。Tree-Planner 采样多条、合并成树、执行时能回溯纠错，且不依赖固定技能库的边界。

Q6：读完 Tree-Planner 接下来看什么？

想看迭代式对照看 ReAct / Inner Monologue；想看一次性 + 技能库看 SayCan；想看几何中间表达的规划看 VoxPoser。

所以这一节是想说：要不要训练、能用什么 LLM、和 SayCan 差在哪——这些实操问题都有明确答案。

---

如果你想再深入

按"对照范式 → 思想来源 → 邻居"排序：

1. 对照：SayCan —— 一次性规划 + 技能库，看 Tree-Planner 多了什么纠错能力。
2. 对照：Inner Monologue / ReAct —— 迭代式规划，看 Tree-Planner 省了多少调用。
3. 思想来源：Tree-of-Thought —— 树搜索的推理版，看 Tree-Planner 怎么"廉价化"。
4. 邻居：VoxPoser —— 另一种"LLM 帮机器人规划"的思路（几何中间表达）。

所以这一节是想说：把 SayCan + Inner Monologue + Tree-Planner 连起来读，就能看清 LLM 具身规划三种范式的取舍。

---

原文信息

• 标题：Tree-Planner: Efficient Close-loop Task Planning with Large Language Models
• arXiv：https://arxiv.org/abs/2310.08582
• 会议：ICLR 2024
• 年份：2024

BibTeX：

@inproceedings{hu2024treeplanner,
  title     = {Tree-Planner: Efficient Close-loop Task Planning with Large Language Models},
  author    = {Hu, Mengkang and Mu, Yao and Yu, Xinmiao and others},
  booktitle = {International Conference on Learning Representations (ICLR)},
  year      = {2024},
  url       = {https://arxiv.org/abs/2310.08582}
}

所以整篇是想说：Tree-Planner 用"一次采样多条计划、合并成树、执行时树上纠错"这一招，让 LLM 给机器人做长任务规划既省钱又能纠错——它证明了"少问 LLM"和"更强"可以兼得。

◼

@online{eai_tree_planner_2026,
  title       = {(readable note) Tree-Planner},
  author      = {Xun, Jason},
  year        = {2026},
  note        = {Note on a 2024 paper},
  howpublished = {\url{https://estelledc.github.io/embodied-ai-reading-station/papers/tree-planner/}},
  organization = {Embodied AI: Zero to One}
}