先说一个让人有点意外的场景。
一个机器人面前摆着一堆积木，任务是把它们放进架子。听起来简单，对吧？但架子上的积木有的是立方体，有的是等边三角形，有的是直角三角形，每种形状怎么摆、往哪个方向转，都会影响能不能放进去。如果是人类工程师来设计这套系统，他得先搞清楚积木有几种、架子的物理约束是什么，然后手写一堆规则和采样算法，光是这套"脚手架"可能就要花上几周时间。
现在有人做了个实验：不写这些规则，直接把一个能自己写代码、自己跑测试的AI程序员扔进这个环境里，给它一个任务描述和一个能交互的模拟器，让它自己摸索出一套解决方案。
结果呢？某些版本的AI真的琢磨出了办法，甚至比人类工程师设计的系统解决问题更多、更快。这就是普林斯顿大学、卡内基梅隆大学等机构联合发表的这篇论文想要回答的核心问题：写代码的AI，能不能自己搞定机器人的物理世界难题？
这事难在哪
要理解这个问题为什么有意思，得先知道机器人在物理世界里做决策到底难在哪。
任务与运动规划*：英文缩写TAMP，指的是机器人既要做"抓哪个、放哪里"这种离散决策，又要保证每一步动作在物理上真的可行，比如手臂不会撞到桌子、抓取角度不会让物体掉落。这两类问题必须同时满足，缺一不可。
这类问题早就被证明在理论上是"formally hard"，翻译过来就是计算上极其困难，不存在捷径。原因是离散选择（选哪个物体、用什么工具）和连续约束（几何形状、运动学、动力学）死死绑在一起，改变一个物体数量，碰撞检测的复杂度就跟着涨。而且机器人任务通常horizon（完成任务所需的步骤数）很长，奖励很稀疏，往往要做几十步动作才知道成不成功，中间几乎没有反馈可以纠错。
过去解决这类问题的主流思路叫广义任务与运动规划（generalized TAMP），核心想法是：与其每次遇到新任务都从零开始算，不如学一些能跨任务复用的东西，比如采样器、可行性预测器、搜索启发式。但这些方法有个共同的痛点，就是需要大量针对TAMP领域的手工工程，得有专家去设计谓词、算子、技能库。这活儿耗时又依赖专业知识，很难规模化。
这就引出了论文的动机。已有证据其实是矛盾的：一方面，AI编程助手在软件工程类任务上进步飞快；另一方面，之前有研究发现，当直接让大语言模型去做TAMP系统里的几何和物理决策时，即便把相关的几何信息喂到提示词里，模型表现依然很差。所以没人知道，编程能力的进步到底能不能迁移到物理推理上。
研究团队因此设计了一场大规模实验，用两家公司的编程智能体（Claude Code搭配Opus 5，以及Codex搭配GPT-5.6 Sol和GPT-6 Astra），在28个模拟环境里，跑了七种程序合成方法，每种方法每个环境跑五次，每个生成的程序在100个从未见过的测试实例上评估，总共98000次评估。规模之大，在这个细分领域里相当罕见。
智能体怎么"学"：交互式合成的设计
这个实验最值得细讲的地方，是研究者怎么设定这个AI程序员的工作方式。
在主要实验设置里，AI智能体拿到的东西极其有限：一段任务描述，一个能调用reset（重置环境）和step（执行一步动作）的模拟器接口，外加一个固定的"预算"，也就是允许花多少模型调用成本去做实验和写代码。它没有环境的源代码，没有任何预先写好的TAMP组件，比如谓词、算子或者采样器。
在这个预算范围内，智能体自己决定做什么：写脚本反复调用reset去看看不同的初始状态长什么样，故意制造一些边界情况来测试自己的程序，观察失败案例然后回去改代码。整个过程结束后，它交出一个程序，程序会被冻结，之后测试阶段不再有任何大语言模型参与，纯粹是这段冻结代码在跑。
这个设计思路其实很值得琢磨。如果直接让大语言模型看一遍任务描述就一次性吐出一段代码，会发生什么？
论文里专门做了对照实验，叫one-shot生成，就是只让模型生成一次程序，不给任何调试和迭代的机会。结果这个one-shot基线表现极差，在多个环境里成功率是0%，在稍微复杂点的环境里也就10%到20%左右。
这就好比让一个从没修过车的人，光看一本汽车维修手册，然后一次性把车修好，不允许试错，不允许打开引擎盖看看实际情况。哪怕手册写得再详细，真实世界的具体状况一定和手册描述有细微出入，比如某个螺丝生锈了、某根管子的位置和图纸略有不同。没有反复触摸、拧动、观察反馈的过程，光靠"读一遍就上手"几乎不可能修对。这也是为什么研究者坚持给智能体"交互权"，而不是一锤子买卖式的生成。
交互式合成方法（AgenticGenPlan）：论文对这套"允许智能体自主选择实验、写测试、反复修改代码"的核心方法的命名，区别于一次性生成或者只给固定反馈不让智能体自主探索的方法。
有意思的是，这种交互不仅仅是"多试几次"这么简单。日志显示，智能体会主动去校准物理模型。比如在一个叫Shelf的环境里，某次Opus的运行记录显示，它先凭自己对Kinova Gen3机械臂的既有知识构建了一个初始运动学模型（注意，这时候它没有联网查资料，全靠训练数据里的先验知识），然后发现环境只暴露物体的位置信息，不直接告诉它机械手的位置。于是它想了个办法：让机械臂抓住一个方块当"标记物"，通过移动机械臂到不同姿态，观察方块的实际位置和自己预测的位置之间有多大误差，用这些数据拟合出六个描述机械臂安装偏移和抓取偏移的参数。
这个校准过程把预测误差从38.9毫米降到了1.8毫米，然后它就拿着这个校准后的模型去做逆运动学求解。这已经不是简单的代码生成了，这是一套完整的实验设计、数据采集、模型拟合流程，跟一个真实的机器人工程师在实验室里干的事情几乎一模一样。
意外的策略：AI真的在"想办法"，不只是套模板
如果说校准物理模型体现的是严谨，那论文里另一组发现更让人意外：这些智能体琢磨出了一些连研究者自己都没预料到的操作方式。
比如在一个叫ScoopPour（舀取倾倒）的动态环境里，目标是用一个工具把很多小球舀起来。Opus生成的某个程序想出了一招：把工具旋转过来，从另一侧重新抓握，这样一次能舀起的球明显更多。在另一个叫SweepIntoDrawer（把方块扫进抽屉）的环境里，本来环境提供了一个专门的扫帚工具，但一个拿到源代码的Opus程序直接放弃了这个工具，改用机械臂的夹爪一个一个地把方块捡起来放进抽屉，效果反而更好。
还有一个叫Blocked的环境特别能说明问题。这个任务里，机器人面前有个被障碍物挡住的物块，同时远处的桌子上可能还有一个没被挡住的备用物块。很多Opus生成的程序会一根筋地反复尝试抓取那个被挡住的物块，因为障碍物的朝向让抓取变得困难，程序就在那儿死磕。而Sol生成的某个程序在某次代码修订中加入了一个"后备方案"：如果尝试抓取失败，就转而去拿远处那个没有障碍的备用物块。这一个改动直接让成功率从15%跳到56%，新增解决了41个原本失败的实例，而且没有牺牲任何一个原本能成功的实例。后续的几次修订又把这个成功率推到了83%。
这个细节挺值得琢磨的。人类工程师在设计系统时，往往会给每个问题找一个"最优解"，追求精确和完美；但AI在反复试错的过程中，更容易想到"这条路走不通就换一条"这种朴素但实用的策略。这种差异某种程度上反映了两种不同的问题解决哲学：一个追求单点最优，一个追求鲁棒性和覆盖面。
论文作者特意强调，这些"意外策略"里有一些，据他们所知，在已发表的针对这些基准环境的研究工作里从未出现过。这个细节很重要，因为它意味着这些策略大概率不是模型从训练数据里"背"出来的现成答案，而是真的在交互过程中被推导出来的。
数据说话：AI程序员到底赢了没有
光讲故事不够，得看数字。
在16个提供了传统规划器（也就是那套基于符号搜索加采样约束满足的手工系统，简称Planner）作为对照的环境里，三种智能体配置全部跑赢了这个规划器基线。具体来说，Claude Code（Opus 5）平均成功率82%，是规划器47%的1.7倍；Codex搭配GPT-6 Astra平均达到95%，是表现最好的配置；Codex搭配GPT-5.6 Sol平均56%，稍弱但依然超过规划器。
细看不同环境族群的表现，GPT-6 Astra在运动学2D环境（不涉及动力学，只关心几何和运动学约束）平均成功率99%，动力学2D环境（涉及接触力、速度、摩擦力等物理效应）97%，运动学3D环境93%，更难的动力学3D环境65%，PDDLStream域（一套专门测试符号规划与连续采样结合的基准）接近100%。
规划器：论文里指的是遵循经典TAMP研究范式的系统，依赖人工设计的谓词、算子、采样器和运动规划技能，每次遇到新的问题实例都要重新计算一遍完整的规划过程。
随着物体数量增加，这个优势变得更明显。规划器的表现是"越来越吃力"：物体越多，需要考虑的碰撞约束越复杂，规划器解决问题的能力下降，耗费的计算时间反而上升。相比之下，AI程序员生成的程序表现更稳定，而且计算时间大幅领先：在有多个物体数量档位的环境里，Opus和Astra程序处理单个实例平均只需要2.1秒和0.5秒，而规划器平均要29秒。
这个时间差距不是一星半点的领先，是近乎一个数量级的差距。这就好比两个人去超市买东西，一个人每次进店都要重新研究一遍商场地图，另一个人早就把常去的几条路线记熟了，直接抄近道。前者理论上更"严谨"，能应对店铺随时调整货架的情况，但代价是每次都慢；后者牺牲了一部分应变灵活性，换来的是速度上的巨大优势。规划器每次都要重新规划整条路径，而AI程序生成的策略往往把"套路"提炼进代码里，遇到新实例直接套用，不用每次都重新搜索一遍。
不过这不意味着AI程序员没有短板。论文特别提到，一些需要"扫（sweeping）"或"倒（pouring）"很多小物体的动态三维环境依然大部分没被解决，比如同类型的SortClutteredBlocks环境，即便是表现最好的GPT-6 Astra，主设置下的成功率也只有0%左右（在给了源代码后才提升到明显更高的水平）。这提示我们，涉及大量小颗粒物体的连续动力学交互，仍然是当前这套方法的天花板。
三个AI智能体的性格差异
有意思的是，三个智能体配置之间的表现差异，展现出某种类似"性格"的东西。
GPT-6 Astra在28个环境中有20个的平均成功率超过Opus。但研究者进一步分析发现，这20个里有11个，Opus生成的最佳单次程序其实并不比Astra的最佳程序差，Astra赢的原因主要是稳定性更高。以Shelf环境为例，Opus生成的五次程序成功率在0%到100%之间剧烈波动，最差的一次甚至根本没搞明白方块该放哪个具体的架层；而Astra的五次程序全部经过多达八个方块的实例测试和修订，每次都能达到至少98%的成功率。
这个反差挺能说明问题。同样是"聪明"的模型，一个可能灵光一现搞出个精彩方案，但状态不稳定，容易"翻车"；另一个可能没那么惊艳，但每次都靠谱。这有点像团队里两种不同类型的同事：一种是那种偶尔憋出神来之笔但发挥不稳定的天才型选手，另一种是水平线一直很平稳、每次都能稳稳交付的踏实型选手。如果这套系统要部署到真实场景里，稳定性显然更重要，因为你没法预知拿到手的是"神来之笔"版本还是"翻车"版本。
而Opus相比GPT-5.6 Sol，在22个环境里表现更好，只有4个打平，只在Dynamo和Blocked两个环境里Sol反超。这种整体性的强弱排序，某种程度上反映了不同模型版本在推理能力上的代际差异，也提醒我们评估这类系统的时候，模型底座本身的能力依然是决定性因素之一，交互式合成方法只是把这份能力更充分地释放了出来。
给源代码会不会更好用
论文还做了一组补充实验，叫做"+source"设置，就是额外把环境的源代码开放给智能体，让它能看到具体实现，甚至可以直接调用里面写好的逆运动学求解器等辅助函数。
结果是，源代码访问确实提升了平均成功率：Opus从74%涨到84%，Astra从86%涨到95%。但研究者特别强调，单纯给源代码并不足够。
这里有个很关键的对照实验。论文里还测试了另一种方法，叫LLMGenPlan，这也是一种依靠大语言模型生成程序的方法，同样给了源代码，同样用的是Opus 5模型，同样是20美元的预算，但它有个关键限制：这个大语言模型不能自己跑代码，不能写自定义测试，只能拿到一套预先设计好的、非常有限的反馈（比如报错信息、非法动作提示，或者失败实例的随机种子）。它没法像编程智能体那样主动去探索、验证自己的假设。
结果LLMGenPlan的平均成功率只有28%，而拿到同样源代码的Opus智能体（能自主运行代码、写测试）达到了84%，在27个环境里都比LLMGenPlan表现更好。
这组对比说明了一件事：真正起决定性作用的，不是"有没有看到源代码"，而是"能不能自己动手试"。
这就好比学一门乐器，光把乐谱和乐理书全塞给你，跟允许你天天拿着乐器练习、反复试错调整指法，效果完全不是一回事。乐谱（源代码）提供的是信息，但把信息转化成能力，靠的是动手实践的过程，是不断弹错、听出问题、再调整的循环。如果只给乐谱不让碰乐器，纸上谈兵，学不出真本事。
源代码带来的另一个好处，是让程序运行时的计算成本上升了。论文的时间统计显示，主设置下Opus程序平均每步决策只需要11.7毫秒，而拿到源代码的Opus程序均值涨到42.5毫秒，涨幅超过3倍，原因是很多程序会在决策时直接调用环境源代码来做规划，相当于把一部分"思考"留到了运行时才做，而不是提前把逻辑固化进代码里。
这个细节也挺有启发。没有源代码逼着智能体必须把学到的东西"蒸馏"成自包含的代码逻辑，这反而让最终生成的程序运行更快。这类似于一个人考试前，如果允许一直翻书，可能反而懒得把知识点真正理解消化、内化成自己的东西；而如果被迫闭卷，逼着自己把知识点提炼、记熟，考试时反应速度反而更快。限制条件有时候不是坏事，它逼出了更紧凑、更高效的解决方案。
沙盒环境：为了防止意外，研究者把这些编程智能体关在一个隔离的Docker容器里，独立文件系统，完全断网，还专门做了红队测试，尝试读取环境源代码、导入被禁止的库、或者试图突破容器连到宿主机和网络，以此验证隔离措施是否牢靠。
写在后面
读完这篇论文，最触动我的其实不是那些漂亮的成功率数字，而是那个机械臂"抓着方块给自己当尺子"去校准运动学模型的细节。
这个动作背后藏着一种朴素但深刻的问题解决方式：你不知道自己身体的精确参数，那就想办法用手边现有的东西造一个测量工具。这不是任何人预先教它的操作，是它自己在"没有直接观测手部位置"这个约束下，想出的迂回办法。读到这一段的时候我愣了一下，因为这正是人类工程师在真实实验室里会做的事情，只不过这次做这件事的是一段代码。
论文里还有个细节值得单独拿出来说：作者反复强调这些"意外策略"在已发表文献里从未出现过，这不是随口一提，而是他们特意用来论证"这不是背答案"的证据。这提醒我们，评估AI能力的时候，"它做出了正确答案"和"它是不是只是记住了训练数据里见过的答案"这两件事，需要非常小心地区分开来，而这篇论文选择用"策略的新颖性"作为间接证据，这个思路本身值得其他研究借鉴。
但论文也留了一个没解决的口子:那些需要"扫"和"倒"大量小颗粒物体的动态三维场景，几乎所有配置都表现糟糕。这类任务的共同特点是,涉及大量微小物体之间连续、高频的物理交互，一个物体的运动轨迹极度依赖上百次碰撞的累积效应，几乎无法用几条简洁规则去概括。这或许意味着，当前这套"靠交互摸索规律再写成程序"的思路，面对真正高维度、高随机性的物理混沌时，还是会碰壁。这个天花板在哪里，什么时候能被突破，是个我很想继续追问下去的问题。
Q&A
Q1：AgenticGenPlan是什么？
A：AgenticGenPlan是论文提出的研究方法，指让编程智能体（如Claude Code、Codex）在给定任务描述和模拟器访问权限的情况下，自主选择实验、编写代码、反复调试，最终生成一段可复用的程序来解决任务与运动规划问题，测试时不再需要大语言模型参与。
Q2：这些AI编程智能体在机器人任务上表现如何，是否超过传统规划器？
A：在16个有传统规划器可对比的环境里，三种智能体配置全部超过规划器，平均成功率56%到95%，而规划器只有47%，同时计算耗时大幅更低，物体数量增多时优势更明显。
Q3：给AI智能体看环境源代码会不会明显提升效果？
A：会提升，但源代码本身不是决定性因素。对照实验显示，同样拿到源代码但不能自主运行代码测试的方法只有28%成功率，远低于能自主交互调试的智能体的84%，说明关键在于能否自主试错，而不只是掌握信息。
