LLM+P: Empowering LLMs with Optimal Planning

这是一份写给零基础读者的精读笔记。术语第一次出现先给类比，公式一律翻成人话。

一句话讲什么（TL;DR）

让 LLM 只当翻译——把你说的话翻译成机器格式，真正的规划交给老牌算法去算。LLM 管说话，算法管动脑子。

所以这一节是想说：LLM+P 不让大模型自己规划，而是让它把自然语言翻成规划器能吃的格式，靠专业算法算出最优解。

---

这是个什么场景

你出国旅行想订一趟最便宜的转机航班，但你不会英文，也不会用航空公司的查询系统。

幸好你有个朋友：他中英文都行，还会用机场那台只认命令的老查询机。于是流程变成这样：

• 你用中文说："我想从北京去纽约，预算 5000，不能在芝加哥转机。"
• 朋友把这段话翻译成查询机认的命令，敲进去。
• 查询机吭哧吭哧算半天，吐出一个最优航班组合。
• 朋友再把结果翻译成中文："明天早上 8 点，北京飞东京转机，2 小时后接纽约航班，3800 块。"

这篇论文做的事一模一样：你（用户）说人话，朋友（LLM，大语言模型）做翻译，查询机（经典规划器，classical planner）真正去算最优解，中间那套"机器命令"就是一种叫 PDDL 的格式。LLM 自己不会规划，但它擅长在两种语言之间倒腾。

PDDL（Planning Domain Definition Language，规划领域定义语言）：规划领域的"标准格式"，1998 年起作为规划比赛的统一输入语言。分 domain（世界规则）和 problem（具体任务）两部分。

所以这一节是想说：场景是"用户说人话但规划器只认 PDDL"，LLM+P 让 LLM 当中间的翻译层。

---

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

• 纯 LLM 规划：让 LLM 直接生成动作序列（"先拿杯子，再倒水，再喝"）。问题：步数一多就胡说，不保证可达目标，也不保证最优。
• 链式思考（CoT, Chain-of-Thought）：让 LLM 分步推理。简单问题上不错，但在 Blocksworld 这种需要多步搜索的经典规划任务上仍会失败。
• 强化学习（RL）规划器：训练专门的策略网络。泛化差，换个领域就要重训。
• 经典规划器（如 Fast Downward）：算法保证完备性和最优性，但只接受 PDDL 输入——而把人类需求写成 PDDL 是专家活。
• 结果：此前一直没人桥接"自然语言 → PDDL"这一关，所以经典规划器没法被普通用户用起来。

经典规划（classical planning）：完全可观察、确定性、离散动作的规划问题。Blocksworld（积木世界）是教科书例子。

所以这一节是想说：以前 LLM 直接规划不可靠，经典规划器可靠但门槛高，缺一座"自然语言到 PDDL"的桥。

---

这篇论文的新想法

把 LLM 当作"自然语言 ↔ PDDL"的翻译层，而不是规划器本身。

核心洞察：LLM 在符号生成（写代码、写格式化文本）这件事上比在长程推理上更可靠。所以与其让它做它不擅长的事（一步步推规划路径），不如让它做擅长的事（生成符合语法的 PDDL 文件），把推理交给保证正确性的工具。

这是一个典型的 neuro-symbolic（神经-符号混合） 思路：神经网络负责模糊的语言理解，符号系统负责精确的逻辑搜索。

neuro-symbolic（神经-符号）：把神经网络（擅长模糊感知/语言）和符号系统（擅长精确逻辑/搜索）组合起来，各扬所长。

所以这一节是想说：新想法 = 扬长避短，让 LLM 只做"翻译成 PDDL"，规划交给保证最优的经典规划器。

---

它分几步做的（方法）

这是全篇最核心部分，分四段讲清楚"进什么、做什么、出什么"。

1. 专家先写好"世界规则"，LLM 只填今天的订单

输入：一个领域的世界规则（由人类专家一次性写好）+ 用户的自然语言任务。

处理：像餐厅一样——厨房有什么锅、能做什么菜（domain file，领域文件）由大厨提前写一次；今天客人点了什么、要做成什么样（problem file，问题文件）每次现填。论文让人类专家提前写好 domain，LLM 只负责把客人的话翻译成 problem。

输出：一个待填的框架——domain 固定，problem 由 LLM 生成。

等等，先慢一拍——PDDL 的 domain 和 problem 到底是什么？你可以理解成"游戏规则"和"这一关的关卡设定"。规则只写一次（这个世界里能做什么动作、有什么前置条件），关卡每次不一样（积木现在长什么样、要堆成什么样）。

domain file / problem file：domain 写一次描述世界（有哪些谓词、动作、前置条件、效果），problem 每次写描述当前任务（初始状态 + 目标）。

2. 照葫芦画瓢做翻译（few-shot prompting）

输入：用户任务 + 一个"自然语言 + 对应 PDDL"的示范样例。

处理：像教小孩做应用题——先给一道带答案的例题，再让他做新题。给 LLM 看一个样例，它就能模仿着把新任务翻译成 problem.pddl。LLM 不用真的懂规划，它只在做"模式匹配 + 填空"。

输出：一份 problem.pddl（当前任务的形式化描述）。

few-shot prompting（少样本提示）：在提示里塞几个示例（典型 1–3 个），让 LLM 模仿生成，无需重新训练。

3. 把活儿交给老黄牛——经典规划器

输入：LLM 写的 problem.pddl + 人写的 domain.pddl。

处理：把两者一起塞给 Fast Downward（一个开源经典规划器），它会算出一条保证最优（步数最少或代价最小）的动作序列。这一步不靠 AI，靠的是几十年的搜索算法。

输出：一条符号形式的最优计划，如 (pick-up A) (stack A B)。

Fast Downward：开源经典规划器，工业界标杆。给它合法的 PDDL 就返回最优计划。

4. 把"机器话"再翻回人话

输入：规划器输出的符号计划。

处理：规划器吐出来的是 (pick-up A) (stack A B) 这种符号，LLM 再把它读成："先把积木 A 拿起来，然后放到 B 上。"

输出：用户看到的自然语言步骤。用户全程只看到自然语言进、自然语言出，中间那台老黄牛对他完全透明。

ASCII 总览：

用户自然语言 ──►[LLM 翻译(few-shot)]──► problem.pddl
                                            │
人类专家写的 domain.pddl ────────────────────┤
                                            ▼
                              [Fast Downward 经典规划器]
                                            │ 保证最优
                                   符号计划 (pick-up A)(stack A B)
                                            │
                                  [LLM 翻回人话]──► 用户看到的步骤

5. 为什么让 LLM"只当翻译"是全篇的灵魂

这个分工哲学是理解 LLM+P 的钥匙，值得讲透。

输入：一个需要多步规划、还要保证正确的任务。

处理：人们最初的期望是让 LLM 直接输出计划——"你聪明，你自己想步骤"。但 LLM 在多步规划上有个根本弱点：它是靠"接下来最可能说什么"生成文字的，没有真正的搜索和验证机制。任务一长，它就容易漏前置条件、给出走不通甚至自相矛盾的步骤，而且它不会告诉你"我不确定"。经典规划器恰好相反：给它一个形式化正确的问题，它能用几十年积累的搜索算法保证找到最优、可行的解，但它一个字的自然语言都读不懂。LLM+P 的洞察是——让两者各干自己最擅长的：LLM 干"把人话翻成形式语言"这件它擅长的模式匹配活，规划器干"在形式空间里搜出正确最优解"这件它擅长的硬算活。这就是典型的神经-符号（neuro-symbolic）互补：神经网络管感知与语言，符号系统管逻辑与保证。

输出：一个"会说话"和"会严谨推理"被拼在一起、各扬其长的系统。

打个比方：让一个能言善辩但不会算账的销售，和一个不善言辞但算账绝不出错的会计搭档——销售负责听懂客户要什么、把结果讲清楚，会计负责把账算到分毫不差。

6. 为什么 domain 要人写，而不是也让 LLM 写

输入：一个领域的"世界规则"（有哪些动作、前置条件、效果）。

处理：LLM+P 有一个诚实且关键的设定——领域文件（domain）由人类专家一次性写好，LLM 只负责每次任务的 problem 文件。为什么这么分？因为 domain 描述的是这个世界的底层规则，它稳定、可复用（写一次，这个领域所有任务都用它）、而且对正确性极其敏感——规则写错，规划器算得再对也是错的。把这种"一次性、高价值、要求绝对正确"的部分交给专家，是合理的；而 problem 是每个任务都不同、变化频繁的部分，正适合 LLM 来快速翻译。这个分工也坦诚地划出了方法的边界：它不是"全自动、什么都不用人管"，而是"把最需要保证正确的骨架交给人，把繁琐多变的填空交给 LLM"。承认这一点，反而让方法更实用、更可靠。

输出：一个稳定复用的 domain + 由 LLM 每次现翻的 problem 的清晰分工。

所以这一节是想说：把"稳定且要求绝对正确"的规则留给人，把"多变且繁琐"的翻译交给 LLM，是一种清醒的责任划分。

7. 翻译这一步靠不靠谱，few-shot 为什么够用

输入：用户的自然语言任务 + 一个"自然语言 → PDDL"的示范样例。

处理：整套系统的可靠性，很大程度上压在"LLM 能不能把 problem 翻对"这一步。好在这一步对 LLM 相对友好：problem 文件结构高度规整（初始状态 + 目标），LLM 只要看一个带答案的例题（few-shot），就能照葫芦画瓢地把新任务填进同样的模板——它做的是"模式匹配 + 填空"，而不是真正的推理，这恰是 LLM 的强项。不过这一步也是整个系统最脆的环节：如果 LLM 漏掉一个物体、把目标写错，规划器会在一个错误的问题上算出一个"正确但无用"的计划。所以翻译的准确性直接决定成败，这也是后续很多工作（加校验、加反馈修正）改进的重点。

输出：一份 LLM 通过模仿样例生成的 problem.pddl——省事，但需警惕翻译错误。

8. 为什么"正确与最优"必须由规划器而非 LLM 保证

输入：形式化正确的 problem + domain。

处理：这一步是 LLM+P 相比"让 LLM 直接规划"最本质的优势。经典规划器（如 Fast Downward）有一个 LLM 给不了的东西——可靠性保证：只要输入的 PDDL 合法，它要么返回一个真正可行且最优的计划，要么明确告诉你无解，绝不会像 LLM 那样一本正经地编一个走不通的步骤。把"找计划"这件必须正确的硬活，从爱幻觉的 LLM 手里拿走、交给一个被验证了几十年的求解器，等于给整个系统上了一道正确性的锁。LLM 的错误被限制在"翻译"这一层（可以检查、可以重试），而"推理正确性"这一层则由符号求解器兜底。这种"把易错的交给可纠错的环节、把要求保证的交给有保证的环节"的结构，正是神经-符号方法的价值所在。

输出：一条有正确性与最优性保证的计划——保证来自规划器，而非 LLM 的自信。

所以这一节是想说：专家写 domain（稳定、要求正确的骨架）、LLM 翻 problem（擅长的模式匹配填空）、经典规划器算最优（提供 LLM 给不了的正确性保证）、LLM 再翻回人话——四步各司其职，核心是让神经网络和符号系统各扬其长、互相兜底。

---

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

【LLM+P: Empowering LLMs with Optimal… · 关键结果概览】

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

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

---

关键数字（What works）

LLM+P 是 arXiv 2023 论文，各领域成功率、最优性提升的精确数值需以原文为准，本笔记不编造。下表说明它"测什么、和谁比"。

关注点	对比对象	结果方向（原文为准）	具体数值
长程规划成功率	纯 LLM、CoT	LLM+P 在需搜索的任务上几乎全胜	原文未在本笔记转录
最优性	纯 LLM	规划器保证最优（步数/代价最少）	由算法保证
纯 LLM 失败点	——	5+ 步任务经常失败	见原文
失败模式	——	LLM 翻译时漏谓词/写错对象名会整条废掉	见原文讨论

提醒：任何成功率数字请以 arXiv 原文（2304.11477）为准。

所以这一节是想说：核心结论是"LLM+P 在长程规划上远胜纯 LLM，且最优性由算法保证"，具体值回原文。

---

实验结果说明了什么

• LLM 不擅长长程规划，但擅长翻译：纯 LLM 在 5+ 步任务上经常失败，而只让它翻译成 PDDL、把规划交给算法后，长程任务几乎全胜——印证"扬长避短"的核心主张。
• 最优性来自算法而非模型：计划的最优性由 Fast Downward 保证，与 LLM 强弱无关。这是 neuro-symbolic 相对纯神经方法的硬优势。
• 翻译误差是主要失败源：LLM 偶尔漏一个谓词或写错对象名，整个 pipeline 就废——说明这套架构的可靠性瓶颈在"翻译对不对"。
• domain 仍靠人写：世界规则由专家提供，LLM 只填 problem。这既是它可靠的原因，也是它的局限。

所以这一节是想说：实验证明"让 LLM 只翻译、规划交算法"能可靠解长程任务，但翻译误差和人写 domain 是软肋。

---

你应该懂的几个新词

PDDL（规划领域定义语言）：规划的标准格式，分 domain（世界规则）和 problem（具体任务）。

classical planning（经典规划）：完全可观察、确定性、离散动作的规划问题，Blocksworld 是典型。

domain file / problem file：domain 描述世界规则（写一次），problem 描述当前任务（每次写）。

Fast Downward：开源经典规划器，给合法 PDDL 返回最优计划。

neuro-symbolic（神经-符号）：神经网络 + 符号系统的混合架构。

few-shot prompting（少样本提示）：提示里塞几个示例让 LLM 模仿，无需微调。

所以这一节是想说：抓住"PDDL、经典规划、domain/problem、Fast Downward、neuro-symbolic、few-shot"这几个词，就抓住了 LLM+P。

---

它有什么搞不定的

• domain 还是人写的：世界规则要专家手写 PDDL，换个新领域就得重写，没有真正做到"全自动"。
• 翻译一错全盘皆输：LLM 漏一个谓词或写错对象名，规划器要么报错要么算错，整条 pipeline 崩。
• 只适用经典规划假设：完全可观察、确定性、离散动作。涉及概率、连续值、部分可观察的任务，这套架构不适用。
• 表达力受 domain 限制：如果用户需求超出 domain 能表达的范围（比如带时间窗、资源约束的复杂任务），就翻译不出来。
• 不处理感知：它假设世界状态已知（能写成 problem），不解决"从图像/传感器获得状态"这一步。

所以这一节是想说：LLM+P 可靠但受限——domain 靠人写、翻译易错、只吃经典规划、不管感知。

---

它和别的几篇是什么关系

• 与 SayCan / Inner Monologue 等"LLM 直接当 planner"路线对比：LLM+P 走相反方向——不让 LLM 规划，只让它翻译，立场更"谦虚"。
• 与 Code as Policies 一脉：都是"LLM 生成结构化语言，交给底层执行"。CaP 生成 Python，LLM+P 生成 PDDL。
• 与 GenSim 对比：GenSim 让 LLM 写"训练任务代码"，LLM+P 让 LLM 写"规划问题描述"，都在借用 LLM 的符号生成能力。
• 后续工作：启发了 LLM-DP、PDDLego、AutoTAMP 等一系列"LLM + 形式化规划"工作，也是 TAMP（任务与运动规划）社区接入 LLM 的范本。
• 对比 ReAct：ReAct 让 LLM 边推理边交互；LLM+P 是"一次性翻译完，规划器搞定"，更适合静态、目标明确的任务。

所以这一节是想说：LLM+P 是"LLM 生成符号交给工具"这一家族里最典型的神经-符号样本，与 SayCan 的"LLM 直接规划"形成对照。

---

和本导读的关系

• 主线章节：Ch10 高层规划。LLM+P 是"LLM + 经典规划器"神经-符号路线的代表，与 SayCan/Code-as-Policies 并列。
• 对具身的意义：机器人任务常需长程规划，LLM+P 展示了"把可靠规划外包给算法"的思路，对具身 agent 设计有直接借鉴。

所以这一节是想说：LLM+P 落在 Ch10（高层规划）的核心位置，是理解神经-符号规划的入门样本。

---

思考题

Q1：为什么让 LLM 只做"翻译"而不做"规划"反而更可靠？

提示

LLM 擅长符号生成（写格式化文本），不擅长长程逻辑搜索。把它擅长的（翻译成 PDDL）留给它，把不擅长的（搜索最优）交给算法，整体更可靠。

Q2：PDDL 的 domain 和 problem 为什么要分开？

提示

domain 是不变的世界规则（写一次），problem 是每次不同的任务设定。分开后规则可复用，只需对每个新任务生成 problem。

Q3：LLM+P 的可靠性瓶颈在哪一步？为什么？

提示

在 LLM 翻译成 problem.pddl 这一步。漏一个谓词或写错对象名，规划器就报错或算错，整条 pipeline 崩。

Q4：为什么这套方法不适用于带概率或连续值的任务？

提示

经典规划假设确定性、离散动作、完全可观察。概率/连续值超出 PDDL 经典表达能力，规划器无法处理。

Q5：LLM+P 和 SayCan 都用 LLM 做机器人任务，立场有何根本不同？

提示

SayCan 让 LLM 直接当 planner 排动作；LLM+P 不让 LLM 规划，只翻译，把规划交给保证最优的经典规划器。

Q6：domain 仍需人写，这限制了 LLM+P 的什么？可能怎么改进？

提示

限制了自动化和跨领域扩展。改进方向：让 LLM 也尝试生成/补全 domain（后续 PDDLego 等工作在做），但可靠性会下降。

Q7：如果任务需要从摄像头识别世界状态，LLM+P 能直接用吗？

提示

不能直接用。它假设状态已知（能写成 problem），不处理感知，需要先接一个感知模块把图像变成符号状态。

所以这一节是想说：想清楚这些题，你就理解了"扬长避短""domain/problem 分工""翻译瓶颈""经典规划的假设"这几件核心事。

---

一些好奇心问答（FAQ）

Q：LLM+P 是开源的吗？

作者放了 GitHub 仓库，可跑 Blocksworld 等例子，亲眼看到自然语言变 PDDL 又变回自然语言。

Q：它用什么 LLM？

主要用 GPT 系列做翻译。因为只做翻译，对 LLM 的推理能力要求没那么高。

Q：它一定能算出最优解吗？

只要 LLM 翻译正确、任务在 domain 表达范围内，Fast Downward 就保证最优。翻译错则整条失败。

Q：能扩展到机器人真机吗？

需要额外接感知（把世界变成 problem）和底层控制（把符号动作变成电机指令），LLM+P 本身只管中间的符号规划。

Q：为什么它是 2023 年的重要工作？

它清晰示范了"LLM 不万能，遇到不擅长的任务就外接工具"，是 neuro-symbolic 的经典样本，被后续大量引用。

所以这一节是想说：LLM+P 对零基础读者极友好——论文短、思路清、不需懂深度学习细节，读完就能讲清 neuro-symbolic。

---

如果你想再深入

1. 先理解 PDDL 长什么样 —— 找一个 Blocksworld 的 domain + problem 例子读 5 分钟。
2. 跳读论文 pipeline 流程图 —— 看清 LLM 输入输出的边界。
3. 跑一遍 demo —— GitHub 仓库跑 Blocksworld，亲眼看翻译过程。
4. 对照 Code as Policies / SayCan —— 理解"LLM 生成符号交工具"vs"LLM 直接规划"。
5. 想它的限制 —— domain 靠人写、超出表达能力就失效，思考如何改进。

所以这一节是想说：先懂 PDDL，跑一遍 demo，再横向对比 SayCan/Code-as-Policies 理解神经-符号路线。

---

原文信息

• 标题：LLM+P: Empowering Large Language Models with Optimal Planning Proficiency
• arXiv：https://arxiv.org/abs/2304.11477
• 发表：技术报告（arXiv）
• 年份：2023

@article{liu2023llmp,
  title  = {LLM+P: Empowering Large Language Models with Optimal Planning Proficiency},
  author = {Liu, Bo and others},
  journal = {arXiv preprint arXiv:2304.11477},
  year   = {2023}
}

BibTeX 作者字段据公开信息填写，完整作者与页码请以官方版本为准。

◼

@online{eai_llm_plus_p_2026,
  title       = {(readable note) LLM+P: Empowering LLMs with Optimal Planning},
  author      = {Xun, Jason},
  year        = {2026},
  note        = {Note on a 2023 paper},
  howpublished = {\url{https://estelledc.github.io/embodied-ai-reading-station/papers/llm-plus-p/}},
  organization = {Embodied AI: Zero to One}
}