用于广义任务与运动规划问题的编程智能体
- 关联论文：2609.30233
- 作者：flyP
- 更新：2026-09-26
§0 元层五问
- Q1 这篇真正解决的是什么 TAMP 痛点？ 任务与运动规划（TAMP）即使在完全可观测、object-centric 状态下也难，因为离散决策与几何/运动学/动力学耦合；广义 TAMP 想跨实例复用，但需要大量 TAMP-specific engineering。
- Q2 它比手工 planner / 一次生成 / LLM-based 通用规划改在哪？ 不再写 TAMP-specific 规划器，而是让 coding agent 在固定合成预算内通过仿真器交互合成可泛化程序；冻结程序后在新实例上测试。
- Q3 关键数字是什么？ 28 个模拟环境（KinDER + PDDLStream），3 个 agent 配置（Claude Code Opus 5、Codex GPT-5.6 Sol、Codex GPT-6 Astra），每环境每方法 100 held-out instances，共 98,000 episodes；平均成功率 56%–95%，而手工 planner 在可用的 16 个环境上仅 47%；单实例计算量比 planner 低一个数量级。
- Q4 失败模式是什么？ 对象数量增长时 planner 与 agent 的差距会拉大还是缩小？日志显示 agent 用交互校准物理模型、测试边界、调整策略——这是优势但也意味着它们不一定能"零样本"赢。
- Q5 谁最该读？ TAMP 研究者、机器人/规划方向的工程师，以及做 coding agent / Code Agent 评估的人。
一句话结论
让 coding agent 在 simulator-in-the-loop 下合成跨实例泛化的 TAMP 程序，在 28 个 KinDER/PDDLStream 环境、98,000 episodes 上以 56%–95% 成功率击败 47% 的手工 planner，且单实例计算量低一个数量级。
解决什么真问题
任务与运动规划（TAMP）研究里有一道持续多年的高墙：
- 离散层（task planning）和连续层（motion planning）必须联合求解，因为离散选择会改变运动约束（比如"先抓 A 再抓 B"和"先抓 B 再抓 A"路径完全不同）。
- 即便在完全可观测、object-centric 设定下，写一个能用的 TAMP planner 也非常昂贵：PDDLStream 这种框架需要 TAMP-specific 的 stream samplers、连续谓词、与 motion planner 的紧密耦合。
"广义 TAMP" 想复用跨实例的规律性（regularities），但过去的工作（learning over sketches、neural TAMP 等）依然需要大量专属工程。
本文的核心问题是：coding agent 能不能"自己写规划器"？
核心方法
1. 评测协议
论文把广义 TAMP 重新定义成一个 code-synthesis 问题：
- 每个 agent 在 fixed synthesis budget（一定调用次数或时间预算）内与 simulator 交互；
- agent 提交一份"程序"（frozen program），后续该程序被冻结；
- 程序在 unseen instances 上跑，统计 success rate。
⚠️ "fixed synthesis budget" 具体是 50 次 LLM call 还是 30 分钟 wall-clock，abstract 未明确给出。
2. 三个 agent 配置
- Claude Code (Opus 5)：Anthropic 的 coding agent，跑 Opus 5。
- Codex (GPT-5.6 Sol)：OpenAI 的 coding agent 配置。
- Codex (GPT-6 Astra)：OpenAI 的另一 coding agent 配置。
⚠️ "GPT-6 Astra" 是 abstract 里给出的名字，需要警惕：截至 2026-09 这个名字是否对应真实产品？我没在 abstract 之外找到独立佐证。abstract 自报信息我如实记录，但读者应自行核实——这一点原文未明确澄清。
3. 评测对象：28 个环境 + 98,000 episodes
环境来自 KinDER（物理仿真）和 PDDLStream（符号+连续），且对象数超过原始 benchmark（"object counts beyond those evaluated in the original benchmark"），即做了 scale-out。
每个环境每个 program-synthesis 方法生成 980 个 program（在 100 个 held-out instances 上评估），加起来 98,000 evaluation episodes。
4. 对照项
- Hand-engineered planners：手工 TAMP planner，在 16 个环境上可用（其余 12 个没有对应 planner）。
- One-shot generation：单次 LLM 生成 program，不交互。
- LLM-based generalized planning baseline：把 LLM 当通用规划器（不写代码）。
5. 关键发现
- 三个 agent 配置的 mean success 56%–95%，对手工 planner 47% 高出 9–48pp。
- 随对象数量增长，agent 程序的成功率比 planner 下降更慢，且单实例计算量比 planner 低一个数量级。
- 日志显示 agent 用 simulator 交互校准物理参数、测试 edge case、修正策略——这是 sim-in-the-loop coding agent 的典型 pattern。
关键实验与数据
| 维度 | 数字 | 备注 |
|---|---|---|
| 环境数 | 28 | KinDER + PDDLStream 合并 |
| Agent 配置数 | 3 | Claude Code Opus 5 / Codex GPT-5.6 Sol / Codex GPT-6 Astra |
| 每个程序合成方法的生成 program 数 | 980 | 在 100 held-out instances 上评估 |
| 总 evaluation episodes | 98,000 | abstract 给出的总数 |
| 手工 planner 可用环境 | 16 / 28 | 其余 12 个无对应 planner |
| Agent mean success | 56%–95% | 三 agent 配置范围 |
| 手工 planner mean success | 47% | 16 环境上 |
| 单实例计算量 | 比 planner 低一个数量级 | abstract 措辞 |
| 论文页数 | 9 pages, 4 figures, 3 tables | Comments 字段 |
⚠️ "56%–95%"是 three-config 的 range，没说哪个 agent 最强；abstract 未明确排序。 ⚠️ "一个数量级"是 qualitative 描述，abstract 未明确具体倍数（如 10×、20×）。
亮点
- 把 TAMP 重新定义为 code synthesis problem 是关键的概念切换：让 agent 自己写 planner，而不是让 agent 当 planner。这个 framing 直接决定了 protocol 设计。
- 98,000 episodes 是目前 coding agent 评测里规模最大的之一：远超 SWE-bench、HumanEval 级别的 n，能给出统计可信的 mean success 区间。
- "scale out 比 planner 下降慢"是核心论点：传统 planner 随对象数 n 爆炸（分支因子）；coding agent 程序则可能学到抽象 pattern。这个性质决定 TAMP 是否值得被 coding agent 接管。
- simulator-in-the-loop 让 agent 能 calibrate：这与 web agent / tool agent 的 pattern 同源，TAMP 是其最干净的 benchmark 场景之一。
- 公开全部 prompt 是关键贡献：让可复现性显著提升，避免"agent 评测的 prompt 黑箱"问题。
局限与反方
⚠️ 反方 §1: "GPT-6 Astra" 模型真实性存疑。abstract 自报使用 Codex (GPT-6 Astra)，但截至 abstract 发布日我对该名称的独立佐证不足。读者复现前应核实该模型是否已公开发布；论文未明确给出 model card。 ⚠️ 反方 §2: 28 个环境都是 simulated，sim-to-real gap 未触及。TAMP 的真实价值在真实机器人/工业场景；abstract 只承诺 simulation，且未提及任何真实机器人部署。 ⚠️ 反方 §3: "one-shot generation" baseline 的能力边界不清晰。如果用更强的模型做 one-shot 或多轮 CoT 规划（不写代码），Jev/LLM-as-planner 能否追平 agent 写的程序？abstract 未明确给出 GPT-5/Claude-as-planner 的对照。 ⚠️ 反方 §4: 固定 synthesis budget 的公平性。agent 拿到的总 compute（synthesis + inference）可能远超 planner；如果只看 inference-time cost，planner 反而可能更便宜。abstract 强调"per instance"但没说明 synthesis cost 是否被摊销到所有 held-out instances。 ⚠️ 反方 §5: hand-engineered planner 的 47% 可能是上限而非基线。16 个有 planner 的环境，planner 跑了多少实例？是否包含 expert-tuning？abstract 未明确给出 planner 配置细节。 ⚠️ 反方 §6: mean success 56%–95% 的方差未明。三个 agent 在 28 环境上的 success 分布（best-case vs worst-case）跨度多大？是否有环境三个 agent 全军覆没？abstract 未明确披露完整 per-environment 表。
对工程落地的启发
- 做 TAMP / 工业规划的人：与其写一个针对每个对象的 planner，不如写一个 simulator + 让 coding agent 在 simulator 里写 planner；这是一条比 fine-tuning 通用 planner 更便宜的路。
- 做 coding agent 评测的人：28 环境 × 98K episodes 提供了规模化的 protocol；SWE-bench 类评测可借鉴其"frozen program on held-out instances"思想。
- 做 robotics foundation model 的人：当 LLM 直出 action 不再够用，让它写一段可执行 TAMP 程序是过渡方案；本文提供了证据这种过渡方案已经能赢手工 planner。
- 不建议把本文结论外推到"coding agent 能写所有规划器"——TAMP 状态空间 object-centric、reward 明确，正好是 agent 擅长区间；开放世界 embodied AI 完全不同。
与同方向工作的关系
- PDDLStream / KinDER / SMOL：被纳入 benchmark 的 TAMP 经典框架与仿真器。
- Learning over sketches / Generalised TAMP (Bonet & Geffner 等)：被取代的"广义规划"路线，本文展示 agent 可以不依赖这些方法。
- LLM-as-planner / SayCan / Code-as-Policies：coding agent 与 LLM-planner 的边界，本文证明前者强于后者（针对 TAMP）。
- SWE-bench / HumanEval / RepoBench：coding agent 通用评测，本文 protocol 与其同源思想（frozen program on held-out）。
- RoboBrain / RT-2 / π₀：机器人基础模型路线，与本文"agent 写程序"路线互补。
⚠️ 与上述工作的逐项数字对照 abstract 未明确给出，需读正文 §5/§6。
适合谁读
- TAMP / planning 研究者（必读）
- 机器人 / 工业规划方向的工程师（必读）
- Coding agent 评估 / benchmark 建设者（必读）
- AI for code / Code Agent 系统工程师（选读）
- 不适合纯应用 LLM 调用者（domain 太专）
§六 边界声明
- 本文仅基于 arXiv abstract + 论文卡，未读 PDF 全文；§4 的 per-environment 表、§5 的 synthesis budget、§6 的 sim-to-real 讨论，原文未在 abstract 明确给出。
- ⚠️ 处均为"abstract 未明确"声明，未做任何数值推断；尤其 "GPT-6 Astra" 是否为公开模型我保持中立记录，读者应独立核实。
- 不构成对 coding agent 在 TAMP 上 SOTA 地位的承诺，仅复述 abstract 报告的相对数字。
- 未涉及任何代码/数据下载、未运行任何模型。