ProgPrompt

这是一份写给"完全没接触过机器人规划/大模型"的读者的精读笔记。全程类比、术语先定义。读完你能讲清"为什么让大语言模型写 Python 程序来当机器人的行动计划，比让它写大白话更靠谱"。

一句话讲什么（TL;DR）

让大语言模型（LLM）不要用大白话写机器人的行动计划，而是写成一段 Python 程序——把机器人能做的动作写成函数、把现场有的物体写成一个列表、再给几个示范程序，LLM 就能照葫芦画瓢生成一段可执行、还自带检查的计划代码。这招在 VirtualHome 家务任务上做到当时最强，还真的部署到了实体机械臂上。

所以这一节是想说：这篇论文的核心是"用写程序的方式，让 LLM 生成机器人任务计划"。

---

这是个什么场景

你对家务机器人说："帮我泡杯咖啡。" 机器人不会一步到位，它得先把这句话拆成一串具体动作：走到厨房 → 找到杯子 → 抓起杯子 → 走到咖啡机 → 放杯子 → 按开关……这个"把一句话目标拆成一串可执行步骤"的过程，叫任务规划（task planning）。

传统上，任务规划要人预先把"这个世界有哪些东西、每个动作的前提和后果"都用形式化语言写清楚（这叫定义领域知识），非常费人工。大语言模型看起来是救星——它读过海量文本，"泡咖啡要先拿杯子"这种常识它懂。于是大家想：能不能直接让 LLM 生成计划？

但直接让 LLM 写计划有两个坑：

• 它可能编出机器人做不了的动作：比如让机器人"用意念打开门"，或用一个这台机器人根本没有的技能。
• 它写的是自由文本，难以对齐到机器人真实的动作和物体：大白话"去厨房拿个杯子"要怎么精确翻译成机器人 API 调用？还得再解析，容易出错。

ProgPrompt 要解决的就是：怎么让 LLM 生成的计划既符合这台机器人的真实能力和现场物体，又能直接执行。

所以这一节是想说：目标是让 LLM 生成"贴合机器人真实能力和现场、且可直接执行"的任务计划。

---

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

• 手工定义领域知识 + 经典规划器（如 PDDL）：精确可靠，但要人把世界和每个动作都形式化写清楚，费人工、难扩展到新环境。
• 让 LLM 给候选动作打分（如 SayCan）：枚举所有可能的下一步动作，让 LLM 逐个打分选最合理的。问题是要枚举所有可能动作，动作一多就爆炸，且需要为每步准备候选。
• 让 LLM 直接生成自由文本计划：LLM 输出一段大白话步骤，但可能包含机器人做不了的动作，且自由文本难以精确对齐到机器人的真实 API 和现场物体。
• 共同短板：要么费人工（形式化），要么要枚举打分（不 scalable），要么生成的东西不可执行/不对齐。

所以这一节是想说：以前要么靠人工形式化、要么靠枚举打分、要么生成不可执行的自由文本，都不理想。

---

这篇论文的关键想法

ProgPrompt 的核心洞察非常巧妙：编程语言天生就适合表达"有哪些动作、有哪些物体、按什么顺序执行、以及执行前要检查什么"。 与其让 LLM 写大白话，不如让它写代码。三个关键点：

第一，用"程序风格"的 prompt 描述环境和能力。 在给 LLM 的提示里，把机器人能做的动作写成函数签名（如 grab(obj)、walk(room)），把现场有的物体写成一个 Python 列表（objects = ['mug', 'coffee_machine', ...]）。这等于明确告诉 LLM："你只能用这些动作、只能操作这些物体。" LLM 生成时自然就被约束在机器人真实能力和现场物体之内。

第二，给几个示范程序（few-shot examples）。 提示里附上一两个"把某任务写成程序"的完整例子。LLM 擅长模仿代码风格，照着示范就能为新任务生成结构一致的程序。

第三，程序里带断言（assert）做前提检查与恢复。 生成的计划不只是动作序列，还夹着注释（说明意图）和 assert 语句（执行前检查前提，比如"抓杯子前先确认手是空的"），检查不过就触发恢复动作。这让计划更鲁棒、更像人写的严谨代码。

所以这一节是想说：核心是"把动作写成函数、物体写成列表、给示范程序、让 LLM 生成带断言检查的计划代码"。

---

它分几步做的（方法）

方法分四块：构造程序式 prompt、生成计划程序、执行与断言恢复、以及消融出的设计建议。逐块按"输入 → 处理 → 输出"讲。

1. 构造程序式 prompt：把世界写成代码

输入。 机器人的动作集合（API）、当前环境里可见的物体列表、以及几个示范程序。

处理。 把这些拼成一段类似 Python 的提示：

• 动作写成可调用的函数（find(obj)、grab(obj)、putin(obj, place)、switchon(obj) 等）。
• 物体写成一个列表（objects = ['mug', 'coffeemaker', ...]）——这是"situated（因地制宜）"的关键：列表内容随现场变化。
• 示范放上一两个完整任务的程序实现，展示风格（含注释和 assert）。

一个示意（这是说明性代码，非本仓库代码）：

objects = ['mug', 'coffeemaker', 'table', 'sink']

def make_coffee():
    # 先确保拿到杯子
    find('mug')
    assert('mug' in hand)  # 检查前提：手里有杯子
    walk('coffeemaker')
    putin('mug', 'coffeemaker')
    switchon('coffeemaker')
    # 任务完成

输出。 一段"程序化的世界描述 + 示范"，作为 LLM 的上下文。

所以这一节是想说：把动作/物体/示范都写成代码，等于给 LLM 划定了"只能用这些积木"的规则。

2. 生成计划程序：LLM 照着写新任务

输入。 上面的程序式 prompt + 新任务的函数名/描述（如 def throw_away_lime():）。

处理。 LLM 顺着 prompt 的代码风格，为新任务生成一个函数体——一段调用现有动作、操作现有物体的程序。因为动作和物体都在 prompt 里定义好了，LLM 很难写出"不存在的动作"或"现场没有的物体"（相比自由文本大幅减少幻觉）。生成的程序还会带上注释（解释每步意图）和 assert（前提检查）。

输出。 一段针对新任务的、可执行的计划程序。

所以这一节是想说：LLM 模仿示范代码，为新任务生成受约束、可执行的计划程序。

3. 执行与断言恢复：让计划更鲁棒

输入。 生成的计划程序 + 机器人执行环境。

处理。 逐行执行程序：调用到某个动作函数时，机器人就执行对应的真实动作。遇到 assert 时检查前提是否满足（如"手里是否有杯子"）；若不满足，触发恢复动作（比如重新去找杯子），而不是硬闯导致失败。这把"闭环检查"直接写进了计划里。

断言（assert）：程序里的一句检查——"这个条件必须为真，否则出问题"。ProgPrompt 用它当机器人的"执行前确认"，不满足就补救。

输出。 一次带前提检查和错误恢复的稳健任务执行。

所以这一节是想说：程序里的 assert 让计划在执行时能检查前提、遇错恢复，比一条道走到黑更可靠。

4. 消融出的设计建议

输入。 各种 prompt 结构的对比实验。

处理。 作者通过消融实验研究"prompt 该怎么写、生成时该加什么约束"最有效——比如注释有没有用、示范放几个、物体列表怎么给。他们给出了具体、可操作的建议（细节需读原文）。

输出。 一套"如何写程序式 prompt"的实用配方，供后人照搬。

下面用 ASCII 图把整体流程画出来：

   [动作写成函数] + [物体写成列表] + [示范程序]  ── 组成程序式 prompt
                              │
                              ▼   新任务 def some_task():
                        大语言模型(LLM)
                              │  生成
                              ▼
             计划程序(调用现有动作/物体 + 注释 + assert)
                              │  逐行执行
                              ▼
   机器人执行; 遇 assert 检查前提 → 不满足则恢复动作 → 继续

再用一张 ASCII 图对比"自由文本计划 vs 程序计划"：

   自由文本: "去厨房, 拿杯子, 泡咖啡"  → 可能含做不了的动作, 难精确解析执行
   程序计划: find('mug'); assert('mug' in hand); switchon('coffeemaker')
             → 受动作/物体约束, 可直接执行, 自带检查

所以这一整节是想说：ProgPrompt = 程序式 prompt + LLM 生成计划代码 + assert 检查恢复 + 实用 prompt 配方，把"规划"变成"写受约束的程序"。

---

关键数字（What works）

数字来自论文摘要（arXiv:2209.11302）；VirtualHome 上的具体成功率、各消融数值属正文，标注"需读原文"。

项目	数值/结论	说明
计划形式	Python 风格程序	而非自由文本
环境描述	动作=函数，物体=列表	约束 LLM 输出
鲁棒机制	assert 前提检查 + 恢复	写进计划里
仿真评测	VirtualHome 家务任务 SOTA	具体数字需读原文
真机	部署到实体机械臂做桌面任务	不止仿真
无需	枚举所有候选动作	相比 SayCan 更省

三个要点：第一，**"写程序而非写大白话"**这个形式选择，直接解决了"生成不可执行动作"和"难对齐"两个老问题；第二，assert 检查 + 恢复把闭环鲁棒性内建进计划，是它比"一次性生成文本计划"更可靠的关键；第三，既在 VirtualHome SOTA、又上了真机，证明这不是纸上谈兵。

所以这一节是想说：程序化形式 + 内建检查恢复 + 仿真与真机双验证，是 ProgPrompt 的三个硬点。

---

实验结果说明了什么

论文实验主要证明：

• 程序化 prompt 有效：在 VirtualHome 家务任务上做到当时最强，证明"让 LLM 写代码"比"写自由文本"或"枚举打分"更能生成可执行、正确的计划。
• 约束减少幻觉：因为动作和物体都在 prompt 里定义，LLM 极少生成机器人做不了的动作，可执行率高。
• assert 提升鲁棒性：带前提检查和恢复的计划在执行时更抗错误（消融需读原文）。
• 能上真机：部署到实体机械臂做桌面任务，说明方法有实际落地价值，不局限于仿真。
• prompt 设计有讲究：消融给出了具体的 prompt 结构建议，对后续"用 LLM 做规划"的工作有指导意义。

所以这一节是想说：实验证明"把规划写成受约束的程序"既准、又可执行、又鲁棒，还能落到真机。

---

你应该懂的几个新词

• 任务规划（task planning）：把高层目标拆成一串可执行的具体步骤。
• LLM（大语言模型）：读过海量文本、有常识、能生成文本/代码的大模型。
• situated（因地制宜/情境化）：计划要贴合"当前这个环境有哪些物体、这台机器人能做什么"。
• program-like prompt（程序式提示）：用代码形式（函数、列表、示范）来写提示。
• few-shot（少样本示范）：在 prompt 里给几个例子让 LLM 模仿。
• assert（断言）：程序里的前提检查，不满足就报错/恢复。
• PDDL / 经典规划器：传统上用形式化语言描述世界和动作来做规划。
• VirtualHome：一个模拟家务活动的仿真环境，常用作任务规划评测。

所以这一节是想说：程序式提示、few-shot、assert、situated 是理解本篇的四个关键词。

---

它有什么搞不定的

• 依赖准确的物体列表：计划质量取决于"现场有哪些物体"这个列表是否准确、完整——需要一个可靠的感知系统来提供它。
• 动作 API 的粒度限制：LLM 只能用你给的动作函数；如果某个技能没写成 API，它就无从调用。
• LLM 常识仍会出错：对不寻常的任务或反常识情形，LLM 可能生成逻辑错误的程序。
• assert 只能检查你想到的前提：没写进程序的失败情形，仍会漏检。
• 长程复杂任务：非常长、需要大量分支和状态跟踪的任务，程序会变复杂、易错。

所以这一节是想说：它强在形式和约束，但受制于感知提供的物体列表、动作 API 覆盖、LLM 常识极限和长程复杂度。

---

它和别的几篇是什么关系

• 同代对照：SayCan（用 LLM 给候选动作打分 + 用价值函数判断可行性）——ProgPrompt 不枚举打分，而是直接生成程序，思路更简洁。
• 同代对照：Code as Policies（也让 LLM 写代码控制机器人）——两者都拥抱"LLM 写代码"，侧重点略有不同（ProgPrompt 更强调计划程序 + 断言恢复）。
• 前身思想：Inner Monologue（用环境反馈闭环）——ProgPrompt 的 assert 恢复也是一种闭环。
• 传统对照：PDDL 经典规划——ProgPrompt 用 LLM 常识替代了大量人工形式化。
• 下游影响：启发了后续大量"LLM 生成机器人代码/计划"的工作。

所以这一节是想说：ProgPrompt 与 SayCan、Code as Policies 同属"用 LLM 做机器人规划"的开创浪潮，主打程序化 + 断言鲁棒。

---

和本导读的关系

本笔记对应导读 Ch10: 规划。Ch10 讲的是"如何让机器人把高层目标拆成可执行步骤"，以及 LLM 如何介入规划。ProgPrompt 是这条线上的代表——它给出"用程序化 prompt 让 LLM 生成可执行、受约束、带检查的计划"这一经典范式。读完本篇再看同章的 saycan（打分式）、code-as-policies（写代码控制）、inner-monologue（反馈闭环），能理解"LLM 做规划"的几种主要打法。

所以这一节是想说：把 ProgPrompt 放进 Ch10，它是"LLM 生成程序化计划"这一路的开创作之一。

---

思考题

Q1：为什么"让 LLM 写代码"比"让 LLM 写大白话计划"更容易执行、更少幻觉？

提示

代码里动作是定义好的函数、物体是给定列表，LLM 被约束在这些积木内；自由文本没这种约束，容易编出做不了的动作。

Q2：物体列表为什么是 "situated（情境化）" 的关键？如果列表错了会怎样？

提示

列表告诉 LLM 现场有什么。列表错/缺，LLM 可能操作不存在的物体或漏掉该用的物体。感知的准确性直接影响规划。

Q3：assert 检查恢复相比"一次性生成计划直接执行"好在哪？

提示

现实执行会出意外（杯子没抓到）。assert 在执行前确认前提、失败就补救，形成闭环，比盲目执行鲁棒。

Q4：ProgPrompt 和 SayCan 都用 LLM，但一个"生成程序"一个"打分选动作"，各有什么优劣？

提示

生成程序简洁、不用枚举，但依赖 LLM 一次写对；打分逐步可控、能结合可行性判断，但要枚举候选、较慢。

Q5：如果机器人有一个技能没被写成动作函数，ProgPrompt 能用到它吗？为什么？

提示

不能。LLM 只能调用 prompt 里定义的函数。想想"能力必须先暴露成 API"这个前提。

Q6：assert 只能检查"你想到的前提"，这留下什么隐患？如何缓解？

提示

没写的失败情形漏检。可结合环境反馈闭环（如 Inner Monologue）、更全面的状态检查来补。

Q7：随着任务变得很长很复杂，程序化计划会遇到什么困难？

提示

程序变长、分支和状态跟踪变多，LLM 一次写对的概率下降、易出逻辑错。想想如何分层或分段生成。

---

一些好奇心问答（FAQ）

Q：ProgPrompt 生成的是真能跑的 Python 吗？

它生成的是"程序形式"的计划——函数调用对应机器人真实动作 API，逐行执行时就驱动机器人。所以是可执行的，只要动作函数与机器人对接好。

Q：它需要为每个新环境重写 prompt 吗？

物体列表要随环境更新（这正是 situated 的含义），动作函数和示范一般可复用。所以主要更新的是"现场有什么"。

Q：它和 Code as Policies 是一回事吗？

思想相近（都让 LLM 写代码），但侧重不同：ProgPrompt 更强调"任务计划程序 + assert 检查恢复"，Code as Policies 更强调"用代码组合感知/控制原语"。

Q：需要多强的 LLM？

需要有较好代码和常识能力的 LLM（如 GPT-3 系及以上）。模型越强，生成的计划越靠谱。

所以这一节是想说：它把"规划"变成"写可执行的受约束程序"，落地要点是动作 API 对接和物体列表准确。

---

如果你想再深入

1. 同代：SayCan — 理解"打分式 LLM 规划"这条对照路线。
2. 同代：Code as Policies — 看"LLM 写代码控制机器人"的另一种形态。
3. 闭环：Inner Monologue — 理解环境反馈如何提升鲁棒性。
4. 传统：PDDL / 经典任务规划 — 理解 LLM 替代的是什么。
5. 环境：VirtualHome — 理解它的主要评测场。

所以这一节是想说：把 SayCan / Code as Policies / Inner Monologue / ProgPrompt 一起读，能看清"LLM 做机器人规划"的几种范式。

---

原文信息

• 标题：ProgPrompt: Generating Situated Robot Task Plans using Large Language Models
• 作者：Ishika Singh, Valts Blukis, Arsalan Mousavian, Ankit Goyal, Danfei Xu, Jonathan Tremblay, Dieter Fox, Jesse Thomason, Animesh Garg
• 会议：ICRA 2023
• arXiv：https://arxiv.org/abs/2209.11302

@inproceedings{singh2023progprompt,
  title     = {ProgPrompt: Generating Situated Robot Task Plans using Large Language Models},
  author    = {Singh, Ishika and Blukis, Valts and Mousavian, Arsalan and Goyal, Ankit and Xu, Danfei and Tremblay, Jonathan and Fox, Dieter and Thomason, Jesse and Garg, Animesh},
  booktitle = {IEEE International Conference on Robotics and Automation (ICRA)},
  year      = {2023},
  url       = {https://arxiv.org/abs/2209.11302}
}

◼

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