当 AI 自己给自己写规划器：三个 coding agent 在 28 个仿真环境里，用 9.8 万次试验打败了人类写的 TAMP 规划器

关联论文：2609.30233

一句话故事

arXiv 2609.30233（Coding Agents for Generalized Task and Motion Planning Problems，2026-09-26 更新）把"广义任务与运动规划"这个问题整个翻了过来——过去要靠工程师一个环境一个环境地写专属 TAMP planner，现在让 coding agent 在 simulator 里反复试错，自己合成"能泛化到新实例"的规划程序；最终在 28 个 KinDER/PDDLStream 环境、98,000 个 held-out episodes 上以 56%–95% 平均成功率击败了 47% 的手工 planner，单实例计算量比手工 planner 低一个数量级。这件事的意义在于：① 它把"generalized TAMP"从"learning over sketches / neural TAMP"那种"还得靠专属工程"的路线里拉出来，给出一条"靠通用 coding agent 就足够"的更便宜的路；② 它提供了一个 28 环境 × 98K episodes 的大规模 protocol，比 SWE-bench / HumanEval 类评测的样本量高一个量级；③ 它把"simulator-in-the-loop"这个 pattern 在 TAMP 这种最干净的场景下做了标杆，让 web agent / tool agent / code agent 都能借鉴其"frozen program on held-out instances"思想。

为什么这件事重要

如果你是做机器人规划、做工业自动化、做任务与运动规划（TAMP）的研究员或工程师，你大概率都被同一个问题反复卡住：

每一个新环境都要重新写一个专属 planner，这事儿到底什么时候是个头？

主流 TAMP 研究里的痛点是结构性的：

离散层和连续层必须联合求解。"先抓 A 再抓 B"和"先抓 B 再抓 A"在运动学上完全不同——task planning 的离散选择会直接改 motion planning 的约束空间。
写一个能用的 TAMP planner 巨贵。PDDLStream 这种框架需要 TAMP-specific 的 stream samplers、连续谓词、与 motion planner 的紧密耦合。一个新场景 = 几个月工程师工时。
Generalized TAMP 想跨实例复用规律。learning over sketches、neural TAMP 路线虽然方向对，但依然要大量专属工程，没真正降低门槛。
手工 planner 的上限飘忽不定。KinDER / PDDLStream 系列 benchmark 上，planner 一遇到 object 数量上去就崩；它不是"差"，而是这种问题的结构本身对搜索空间爆炸没抵抗力。

本文给出了一个粗暴但有效的解决思路——别让 agent 当规划器，让 agent 自己写规划器。

这件事为什么重要？因为它直接回答了 TAMP / 通用 planning 领域悬而未决的关键问题：

广义 TAMP 必须靠专属学习/搜索，还是通用 coding agent 就够了？

专属学习/搜索路线（sketch learning, neural TAMP）→ 本文路线
通用 coding agent + simulator 交互 → 本文路线 ✨

两条路线决定了 TAMP 在未来 5 年的工程投入曲线。本文给出了"通用 coding agent 路线已经能打败手工 planner"的硬证据。

它做了什么

第一件：把 generalized TAMP 重新定义成 code-synthesis 问题

作者把任务与运动规划（TAMP）的整个评测框架做了一个概念切换：

# 旧思路：agent 当 planner
def old_tamp_eval(model, env, instance):
    return model.plan(env, instance)        # 让模型直接给动作序列

# 新思路：agent 写 planner
def new_code_synthesis_eval(agent, simulator, budget):
    program = agent.synthesize(
        simulator=simulator,
        env=env,
        budget=budget,                      # 固定 LLM 调用次数 / wall-clock
    )                                       # agent 自己写代码
    # 冻结程序，在 unseen 实例上批量跑
    return run_program_on_held_out(
        program=program,
        instances=held_out_100,             # 100 unseen instances
    )

这个 framing 直接决定了 protocol 设计——agent 不再负责"在测试时给答案"，而是负责"在训练时给出一份能用的代码"。

⚠️ "fixed synthesis budget" 是多少？ abstract 没有明确给出——是 50 次 LLM 调用还是 30 分钟 wall-clock？这是一个会被行业反复追问的关键实验参数。

第二件：部署三个 agent 配置

论文里出场了三个 coding agent 配置：

#	Agent	说明
1	Claude Code (Opus 5)	Anthropic 的 coding agent，跑 Opus 5 模型
2	Codex (GPT-5.6 Sol)	OpenAI 的 coding agent 配置
3	Codex (GPT-6 Astra)	OpenAI 的另一 coding agent 配置（abstract 自报）

⚠️ "GPT-6 Astra" 这个名字 abstract 自己给出来的，但截至 abstract 发布日我在 abstract 之外没找到独立佐证——论文未明确给出该模型的 model card。读者复现前应自行核实该模型是否已公开发布；这一点原文未明确澄清。

第三件：评测对象——28 个环境 + 98,000 episodes

环境来自两个池子：

KinDER（物理仿真，覆盖机器人运动/接触力学相关问题）
PDDLStream（符号+连续混合，覆盖经典 TAMP 任务）

⚠️ 亮点：评测做了一次 scale-out——评测的 object count 超过原始 benchmark 的范围（"object counts beyond those evaluated in the original benchmark"）。这意味着 agent 程序不是只在"原版难度"上赢 planner，而是在"难度外推"上赢 planner。

每个环境每个 program-synthesis 方法生成 980 个 program（在 100 held-out instances 上评估），加起来 98,000 evaluation episodes——这是目前 coding agent 评测里规模最大的之一。

第四件：设置了三个对照项

对照项	在哪个环境上可用	核心目的
Hand-engineered planner	16/28 环境	人类写的 TAMP planner（"工业级基线"）
One-shot generation	28/28	让 LLM 一次性生成 program，不交互（"无 sim-in-the-loop"基线）
LLM-as-generalized-planner	28/28	把 LLM 当通用 planner 用，不写代码（"LLM-as-planner"基线）

注意"手工 planner 只覆盖 16/28 环境"——这意味着有 12 个环境没有手工 planner，agent 在这些环境上的成绩没有绝对参照物。

第五件：报出来的关键数字

维度	数字	备注
环境数	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 措辞

⚠️ "56%–95%" 是三个 agent 配置的 range，没说哪个 agent 最强；abstract 未明确排序。要排最强得读正文 §5。 ⚠️ "一个数量级" 是 qualitative 描述，abstract 未明确具体倍数（10×？20×？）。

第六件：核心观察——object count 上去时谁跌得慢

这是本文的机制性观察：

随 object 数量增长，agent 程序的成功率比手工 planner 下降更慢。

为什么会这样？传统 planner 的搜索分支因子随 object 数指数爆炸（n 个 object、n! 种顺序）；agent 写出来的程序则可能学到抽象 pattern（"只要 X 物理条件成立，先抓 A 再 B"），object 数量上去时不会相应崩。

这条观察比"平均胜出 9–48pp"更重要——它决定了 TAMP 是否值得被 coding agent 结构性接管，而不是在某一些 benchmark 上碰巧赢了。

关键数字：abstract 可证伪层面

⚠️ 由于 abstract 没有给出 per-environment 的完整 breakdown，下列数字均为 abstract 可证伪层面：

Agent mean success 56%–95%：三 agent 配置 × 28 环境的整体均值的 range；abstract 未明确披露完整 per-environment 表。
手工 planner 47%：仅在 16 个有 planner 的环境上算出来；abstract 未明确具体 planner 实现细节或 tuning 程度。
单实例计算量"一个数量级"：abstract 措辞；具体倍数未在 abstract 给出。
可证伪条件（可复现性抓手）： 1. 模型真实性：在 HuggingFace / OpenAI cookbook 查"GPT-6 Astra"是否可访问；若不可访问，protocol 不可复现，须换成 GPT-5 或 Claude Opus 5 重跑。 2. Per-environment 表：正文 §4 应有 28 个环境的 breakdown；若始终未公开，本文可复现性存在根本性缺陷。 3. Budget 归一化：用 llm-call-count × avg-token-count × GPU-cost-per-token 换算成美元，与 planner 的 Mujoco runtime cost 做横向比较。 4. Scale-out 曲线：object count 提升 1×/2×/4× 时，agent vs planner 的 success 下降斜率——abstract 给了"agent 下降更慢"的结论，但具体函数形式没给。

跟同类工作的关系

相关工作	与本文的关系
PDDLStream / KinDER / SMOL	被纳入 benchmark 的 TAMP 经典框架与仿真器，本文是首次把它们放进"代码合成评测协议"
Learning over sketches / Generalized TAMP (Bonet & Geffner 等)	被取代的"广义规划"路线——本文展示通用 coding agent + simulator 可以不依赖这些专属方法就能跨实例泛化
LLM-as-planner / SayCan / Code-as-Policies	coding agent vs LLM-planner 的边界——本文证明前者强于后者（针对 TAMP）
SWE-bench / HumanEval / RepoBench	coding agent 通用评测——本文 protocol 与其同源思想（"frozen program on held-out"），但规模量级更高（98K episodes）
RoboBrain / RT-2 / π₀	机器人基础模型路线，与本文"agent 写程序"路线互补——前者是"端到端"，后者是"程序合成"
Voyager / AlphaCode / CodeT	长 horizon agent / code synthesis，与本文共享 sim-in-the-loop pattern，但本文专做 TAMP

本文的核心贡献在于：首次把 coding agent + simulator-in-the-loop pattern 在 TAMP 这种"离散+连续混合、奖励明确、状态 object-centric"的领域做出可量化结论，并提供了一个规模化的评测 protocol。但这只是一段新起点——它在 sim 之外还没说什么。

对工程落地的启发

启发 1：把 TAMP 工程的"重写 planner"变成"接 simulator"

现实工程里很多团队卡在 TAMP 的工程实施上，每个新客户/场景都要重写 planner。本文给了一个新解法：

写好 simulator（KinDER 风格，物理引擎 + object-centric 状态）；
接 coding agent（synthesize 一个 program 在固定 budget 内）；
冻结 program + 在新实例上跑。

这条链路理论上比"为每个场景写专属 planner"便宜一个数量级。

⚠️ 关键坑：simulator 接入时一定要验证仿真器步长与真实机器人控制频率（通常 100–500Hz）的 ratio 是否 match，否则 sim-to-real gap 会系统性偏移结果。

启发 2：coding agent 评测的金标准升级——"frozen program on held-out"

SWE-bench / HumanEval / RepoBench 这一类 coding agent 评测都可以借鉴本文的协议思想：

固定 budget（不是 fix time，是 fix 调用次数，便于横向比较）；
冻结 program（不让 agent 在测试时偷看）；
批量 held-out instances（n=100 起步，给出统计可信的 mean success 区间）。

这条 protocol 比"在固定测试集上跑一次"更接近真实部署场景（"你的代码要被部署到多个 unseen 任务上"），可以泛化到 code agent 评测整个子领域。

启发 3：机器人基础模型的过渡方案——让 LLM 写 TAMP 程序

当 LLM 直出 action（end-to-end 机器人基础模型）不再够用时，让它写一段可执行的 TAMP 程序是一条更便宜的过渡方案。本文提供了证据：这种过渡方案已经能赢手工 planner。

工程链路：

自然语言指令 → LLM 写 Python TAMP 程序 → simulator 验证 → 部署到机器人
                              ↑
                  coding agent 在 sim 里反复试错

⚠️ 不建议把本文结论外推到"coding agent 能写所有规划器"——TAMP 状态空间 object-centric、reward 明确，正好是 agent 擅长区间；开放世界 embodied AI 完全不同。

启发 4：五个具体工程指标上线

如果你打算基于本文做生产系统，建议上线以下五个监控指标：

指标	阈值	触发动作
synthesis budget 拐点	跑 ablation，找 success rate 拐点对应的 budget	拐点 = sweet spot
frozen program simulator 一致性	0.95+	低于此值说明 simulator 版本没锁
per-environment success spread	监控 worst-case	若某环境三个 agent 全灭，考虑 fallback planner
object count scale-out 斜率	监控斜率	斜率变陡说明泛化性退化
sim-to-real physics gap	监控碰撞模型差异	大于阈值则要再做 fine-tune

⚠️ 边界坑（落地前必须看）

坑点 1："GPT-6 Astra" 模型名无公开端点

这是最高风险点。

⚠️ abstract 自报使用 Codex (GPT-6 Astra)，但截至 abstract 发布日我在 abstract 之外没找到独立佐证。
如果该模型不可用，整篇 protocol 不可复现；须在 GitHub Issues 或 Model Registry 核实。
落地前必查：搜 "GPT-6 Astra model card" 或 OpenAI cookbook，确认该配置是否在 API 上可访问。

坑点 2：Synthesis budget 模糊——结果不可比

⚠️ 原文未明确 budget 是 LLM call 计数还是 wall-clock。
同等 compute 下与 planner 比才公平；建议用 GPU-hour 归一化。
坑：budget 太大 → agent 过拟合当前 instance 的交互历史；budget 太小 → 程序泛化性虚高（因为根本没学到跨实例规律）。

坑点 3：12/28 环境无 planner 对照——绝对值解读需谨慎

⚠️ 这 12 个环境的 agent 性能没有绝对参照物。
若其中恰好有工业常见场景（与制造业/物流有关），agent 60% 成功率可能并不算"赢"，只是"没有 planner 也没别的招"。
落地核查：把这 12 个环境单独跑一遍，找领域专家评估"60% 成功率在工业上是否够用"。

坑点 4："一个数量级"未量化——部署成本估算有 gap

⚠️ abstract 给的是 qualitative 描述。
若真实是 5× vs 10×，对部署成本估算影响巨大。
必须读正文 §5 拿具体数字；若 §5 也没给，可以认为"一个数量级"是营销修辞。

坑点 5：sim-to-real gap 完全没覆盖

⚠️ TAMP 的真实价值在真实机器人/工业场景；abstract 只承诺 simulation。
物理引擎的碰撞模型 vs 真实机器人接触力学系统性不同。
落地核查：在小规模真机上做 n=50 trials 的 sim-vs-real 对比；若 success rate 跌破 30%，本文结论不可外推到生产。

坑点 6：56%–95% range 掩盖 worst-case

⚠️ 若某环境三个 agent 全灭，而该环境恰好是工业常见场景（如多机器人协同抓取），则实用价值大打折扣。
落地核查：拿到正文 §4 的完整 per-environment 表，找到 worst-case 三个 agent 的 environment；该 environment 必须有 fallback planner。

坑点 7：Frozen program 无法在线修正

⚠️ frozen 之后，agent 不能在新 instance 上"再调一下代码"。
真实部署遇到 novel objects 时 agent 无法重新 synthesis，这是架构限制不是参数问题。
落地核查：评估"在线修正"的需求频率；若 >1%/天，说明本文 protocol 不够用。

坑点 8：one-shot 生成 baseline 的能力边界不清晰

⚠️ 如果用更强的模型做 one-shot 或多轮 CoT 规划（不写代码），LLM-as-planner 能否追平 agent 写的程序？
abstract 未明确给出 GPT-5/Claude-as-planner 的对照。
落地核查：用 Claude Opus 5 / GPT-5 直接当 planner 跑同一 28 环境，看是否逼近 agent mean success 的下沿（56%）。

🎯 你能立即做的事

TAMP 研究者：✅ 本文是方法论分水岭——"agent 写程序"路线已经击败手工 planner，下面 5 年的 TAMP 工作可能都得围绕 coding agent 重新组织。建议：复现 protocol（用 Claude Opus 5 + KinDER 起步），把"object count scale-out 曲线"画出来。
机器人规划工程师：✅ 与其为一个新客户写一个 TAMP planner，不如写一个 simulator + 部署 coding agent；这是一条比 fine-tuning 通用 planner 更便宜的路。建议：先从客户最常重复的 3 个场景开始 harness。
Coding agent 评测工程师：✅ 28 环境 × 98K episodes 提供了规模化 protocol。建议：把 SWE-bench 升级成 SWE-bench-Hard-Eval（frozen program on held-out instances），横向比 "agent 写程序 vs agent 当 planner"。
Robotics foundation model 团队：⚠️ LLM 直出 action 不再够用时，让它写 TAMP 程序是过渡方案。本文提供了"过渡方案已经能赢手工"的证据；但不要把"能赢手工 planner"当作"能赢生产"，必须做 sim-to-real gap 评估。
AI for code / Code Agent 系统工程师：⚠️ 本文 protocol 用了 Claude Code / Codex，但 prompt 是关键——搜论文 GitHub 找 open-source prompt，复现性取决于 prompt 公开度。
产品经理 / 非技术：❌ 太专，先读一篇"TAMP 是什么"的科普，否则抽象度接受不了。
不适合：纯应用层 LLM 调用者——domain 太专，与你的工作流距离太大。

📌 一句话总结：arXiv 2609.30233 把 TAMP 评测整个翻过来——让 coding agent 在 simulator-in-the-loop 下合成跨实例泛化的 TAMP 程序，在 28 个 KinDER/PDDLStream 环境、98,000 个 held-out episodes 上以 56%–95% 平均成功率击败 47% 的手工 planner，且单实例计算量比手工 planner 低一个数量级；这把 TAMP 工程的"重写 planner"变成"接 simulator + 让 agent 写"，给机器人规划、coding agent 评测、机器人基础模型三条路线都指了新方向；但 GPT-6 Astra 模型真实性、Budget 模糊、12/28 环境无 planner 对照、sim-to-real 未覆盖、56%–95% range 掩盖 worst-case 五个坑必须在落地前补完。

🔔 评论区聊聊：如果你的团队正考虑让 coding agent 接管 TAMP 工单，你会把它放到"全场景替代"还是"新场景 first deployment"？它与传统 planner 在工业产线的成本曲线差几个数量级？

TAMP #CodingAgents #TaskAndMotionPlanning #Robotics #PDDLStream #KinDER #SimInTheLoop #arXiv2609.30233 #论文科普 #机器人规划 #推理自动化

三个标题变体

反直觉版：别再让 AI 当规划器了——arXiv 2609.30233 让 AI 自己写规划器，9.8 万次试验击败人类写的 TAMP planner
数字钩子版：56%–95% vs 47%——三个 coding agent 在 28 个仿真环境里，用 9.8 万次 held-out episodes 打赢手工 TAMP planner，且单实例计算量低一个数量级（arXiv 2609.30233）
类比版：相当于让程序员自己招一个写代码的 AI 同事——arXiv 2609.30233 把 TAMP 整个翻成 coding agent 自己写 planner 的活

📱 小红书风格卡片文案（直接可用）

🤖 别再让 AI 当规划器了！arXiv 2609.30233 让 AI 自己写规划器，9.8 万次试验击败人类写的 TAMP planner 🤯

姐妹们！👀 你有没有被「TAMP 任务与运动规划」折磨过？

离散层（task planning）和连续层（motion planning）必须联合求解——"先抓 A 再抓 B"和"先抓 B 再抓 A"路径完全不同；写一个能用的 TAMP planner 巨贵，每个新场景 = 几个月工程师工时 💸；hand-engineered planner 一遇到 object 数量上去就崩 😭

🆕 arXiv 2609.30233（Coding Agents for Generalized Task and Motion Planning Problems）给出了一个粗暴答案——别让 agent 当规划器，让 agent 自己写规划器！

🔄 新范式：

# 旧思路：agent 当 planner
def old_tamp_eval(model, env, instance):
    return model.plan(env, instance)        # 让模型直接给动作序列

# 新思路：agent 写 planner
def new_code_synthesis_eval(agent, simulator, budget):
    program = agent.synthesize(
        simulator=simulator,
        env=env,
        budget=budget,                      # 固定 LLM 调用次数 / wall-clock
    )
    # 冻结程序，在 unseen 实例上批量跑
    return run_program_on_held_out(
        program=program,
        instances=held_out_100,             # 100 unseen instances
    )

📊 三大关键数字：

环境数：28 个（KinDER + PDDLStream）🧪
总 evaluation episodes：98,000（目前 coding agent 评测里规模最大的之一）🎯
Agent mean success：56%–95%（三 agent 配置范围）vs 手工 planner 47%（16 环境）💥
单实例计算量：比 planner 低一个数量级 ⚡

🤖 三个 agent 配置：

#	Agent	说明
1	Claude Code (Opus 5)	Anthropic 的 coding agent
2	Codex (GPT-5.6 Sol)	OpenAI 的 coding agent 配置
3	Codex (GPT-6 Astra)	OpenAI 的另一 coding agent 配置

⚠️ "GPT-6 Astra" 模型名无公开端点——abstract 自报但 abstract 之外找不到独立佐证；落地前必须核实该模型是否已公开发布 💣

🆚 三个对照项：

对照项	覆盖环境	结论
Hand-engineered planner	16/28	47% success，agent 赢 9–48pp
One-shot generation	28/28	无 sim-in-the-loop，agent 显著赢
LLM-as-generalized-planner	28/28	不写代码当 planner，agent 赢

🧠 核心机制观察：

随 object 数量增长，agent 程序的成功率比手工 planner 下降更慢——传统 planner 的搜索分支因子随 object 数指数爆炸（n 个 object、n! 种顺序）；agent 写出来的程序则学到抽象 pattern（"只要 X 物理条件成立，先抓 A 再 B"），object 数量上去时不会相应崩 🔥

⚠️ 这条观察比"平均胜出 9–48pp"更重要——它决定 TAMP 是否值得被 coding agent 结构性接管，而不是"碰巧赢" ✨

💡 四条工程启发：

1️⃣ 把 TAMP 工程的"重写 planner"变成"接 simulator"：写好 KinDER 风格 simulator（物理引擎 + object-centric 状态）+ 接 coding agent synthesize 程序 + 冻结 program 在新实例上跑。理论上比"为每个场景写专属 planner"便宜一个数量级 💡

2️⃣ coding agent 评测的金标准升级——"frozen program on held-out"：固定 budget（不是 fix time，是 fix 调用次数，便于横向比较）+ 冻结 program（不让 agent 在测试时偷看）+ 批量 held-out instances（n=100 起步）。比 SWE-bench 当前协议更接近真实部署 🎯

3️⃣ 机器人基础模型的过渡方案——让 LLM 写 TAMP 程序：当 end-to-end 机器人基础模型不再够用时，让 LLM 写一段可执行的 TAMP 程序是更便宜的过渡方案。本文提供了"过渡方案已能赢手工 planner"的硬证据 🚀

4️⃣ 五个具体工程指标上线：synthesis budget 拐点（找 sweet spot）+ frozen program simulator 一致性（≥0.95）+ per-environment success spread（监控 worst-case）+ object count scale-out 斜率 + sim-to-real physics gap 📊

⚠️ 八个边界坑（落地前必看）：

GPT-6 Astra 模型真实性：抽象最大风险——abstract 自报但 abstract 之外找不到独立佐证。落地前必查 HuggingFace / OpenAI cookbook 📣
Synthesis budget 模糊：原文未明确是 LLM call 计数还是 wall-clock；同等 compute 下与 planner 比才公平；建议 GPU-hour 归一化 ⚖️
12/28 环境无 planner 对照：agent 在这些环境上的成绩没有绝对参照物——若其中恰好有工业常见场景，60% 成功率可能并不算赢 ⚠️
"一个数量级"未量化：真实是 5× vs 10×，对部署成本估算影响巨大；需正文 §5 数字 📏
sim-to-real gap 完全没覆盖：物理引擎碰撞模型 vs 真实机器人接触力学系统性不同；在小规模真机上做 n=50 trials 对比，若 success 跌破 30% 结论不可外推到生产 🛡️
56%–95% range 掩盖 worst-case：若某环境三个 agent 全灭，而该环境是工业常见场景，实用价值大打折扣 💔
Frozen program 无法在线修正：架构限制不是参数问题；真实部署遇到 novel objects 时 agent 无法重新 synthesis 🔒
one-shot baseline 能力边界不清晰：用 Claude Opus 5 / GPT-5 直接当 planner 跑同一 28 环境，看是否能逼近 56% 下沿 📊

🎯 适合谁：

TAMP 研究者：✅ 方法论分水岭——"agent 写程序"路线已经击败手工 planner，下面 5 年的工作都得围绕 coding agent 重新组织 🔬
机器人规划工程师：✅ 与其新客户写 planner，不如 simulator + coding agent；先从客户最常重复的 3 个场景开始 harness 🏭
Coding agent 评测工程师：✅ 协议借鉴——把 SWE-bench 升级成 "frozen program on held-out instances"，横向比 "agent 写程序 vs agent 当 planner" 📈
Robotics foundation model 团队：⚠️ 当 end-to-end 不再够用，写 TAMP 程序是过渡方案；但 sim-to-real gap 必须做 💡
AI for code / Code Agent 系统工程师：⚠️ Prompt 是关键——搜 GitHub 找 open-source prompt，复现性取决于 prompt 公开度 🛠️
产品经理 / 非技术：❌ 太专，先读"TAMP 是什么"科普 🪜
不适合：纯应用层 LLM 调用者——domain 太专，与工作流距离太大 🚪

TAMP #CodingAgents #TaskAndMotionPlanning #Robotics #PDDLStream #KinDER #SimInTheLoop #arXiv2609.30233 #论文科普 #机器人规划 #推理自动化