1. 当所有人都在卷微调时Pigey走了另一条路第一次看到16.7%到97.3%这组数字我的反应和大多数人一样又是哪个团队偷偷训了个新权重吧。毕竟这两年具身智能圈的默认玩法就是——模型效果不行上数据、加卡、微调、再不行就重训。VLAVision-Language-Action模型尤其如此π0.5这类模型动辄几十亿参数光是推理部署就够喝一壶更别说在真机上跑出稳定成功率。但Pigey这个项目的核心主张恰恰相反不碰π0.5的任何权重一行梯度都不更新纯靠外挂一层任务与运动规划的调度逻辑把真机成功率从16.7%硬生生拉到97.3%。这个数字跨度太大了大到第一眼会让人怀疑是不是换了评测任务。我花了不少时间把它的思路拆开看越看越觉得这套东西值得写一篇——因为它代表了一种被严重低估的工程范式当基础模型的泛化能力已经够用但不够稳时真正卡住落地的往往不是模型本身而是模型外面那圈没人愿意认真做的调度层。这篇文章适合三类人一是正在做VLA真机部署、被成功率折磨的工程师二是做TAMPTask and Motion Planning任务与运动规划但想搞清楚它和VLA怎么结合的研究者三是单纯好奇不训练权重怎么可能提升这么多的从业者。我会把Pigey的核心机制、π0.5在真机上为什么只有16.7%、TAMP层到底做了什么、以及我自己复现时踩过的坑全部摊开讲。关键词先摆在这Pigey、π0.5、TAMP、VLA、agent.ts后面每一节都会围绕它们展开。先说结论性的判断Pigey不是更好的模型它是更好的模型使用方式。这两者的工程含义完全不同前者要算力要数据要时间后者要的是对任务结构的理解。而后者恰恰是很多团队忽略的地方。2. π0.5真机只有16.7%问题到底出在哪一层2.1 先搞清楚π0.5是什么以及它不是什么π0.5属于VLA模型家族输入是图像加语言指令输出是动作序列。它的设计目标是通用——你给它一句把杯子放进抽屉它应该能理解语义、识别物体、生成抓取和放置的动作轨迹。在仿真环境或者精心布置的桌面场景里这类模型的表现通常很漂亮论文里的成功率动辄七八十。但真机是另一回事。16.7%这个数字换算一下大概是六次里成功一次。这个水平意味着什么意味着你没法把它直接放进任何生产流程因为操作员要盯着它、随时准备接管人力成本比手动操作还高。很多团队卡在这一步然后本能地反应是模型不够好得微调。这里有个关键认知需要先建立π0.5的输出是动作意图不是可执行的安全轨迹。它输出的是一串关节位置或者末端执行器的位姿增量但这些动作在真实物理世界里能不能走通模型本身是不保证的。它没有碰撞检测没有可达性验证没有抓取稳定性判断。这些保证传统上是由TAMP层来提供的。2.2 16.7%的失败大部分不是看不懂而是做不对我把Pigey相关材料里提到的失败模式梳理了一下真机失败基本可以归成几类而且它们的分布很说明问题失败类型典型表现占比感受根因层级抓取位姿偏差手爪擦过物体、抓空高动作精度碰撞手臂撞到桌面、碰到其他物体高运动规划缺失中途丢失目标物体被遮挡后动作乱掉中状态跟踪语义理解错拿错物体、放错位置低模型本身动作序列不连贯抓起来又放下、反复试探中任务分解看这张表就明白了真正属于模型语义能力不足的失败占比其实不高。大部分失败发生在从我知道要干什么到我实际怎么动之间的那段鸿沟里。π0.5知道要抓杯子但它给出的抓取位姿可能偏了两厘米它知道要移动到抽屉但它规划的路径可能穿过桌沿。这就是为什么单纯微调π0.5效果有限——你在用数据去教模型别撞桌子但碰撞是个几何问题用几何方法解决比用数据解决高效一万倍。Pigey的洞察就在这把几何问题交还给几何把语义问题留给模型。2.3 为什么不训练权重反而是优势很多人第一反应是不训练权重那不就是个规则系统吗能有多强这个质疑合理但忽略了几件事。第一π0.5的权重是宝贵的通用能力载体。你一旦开始微调就会不可避免地把模型往特定场景拉偏通用性下降换个任务又得重来。这在工程上是灾难——每换一个工位就要重新采数据、重新训、重新验证。第二训练权重的成本不只是算力。真机数据采集极贵一次成功的抓取演示背后可能是几十次失败和大量人工标注。而Pigey这种外挂方案调的是规划参数和任务逻辑改一次几分钟就能验证迭代速度完全不是一个量级。第三也是最容易被忽略的权重不变意味着可解释、可回滚、可审计。当系统在客户现场出问题时你能明确知道是规划层哪个参数导致的而不是面对一个黑盒说模型今天心情不好。这在工业落地里是硬需求。所以Pigey的路线选择本质上是把提升成功率这个目标从模型能力问题重新定义成了系统工程问题。定义一变解法就完全不一样了。3. Pigey的调度层TAMP和VLA到底怎么分工3.1 一句话说清TAMP和VLA的关系TAMP是Task and Motion Planning的缩写任务与运动规划。传统机器人领域里TAMP负责的是先做什么后做什么任务层和每个动作具体怎么走运动层。它强在逻辑严谨、有几何保证弱在需要人工定义每个任务的原语泛化性差。VLA强在泛化看到没见过的物体和指令也能给出合理动作弱在动作不精确、没有物理保证。Pigey干的事说白了就是让VLA当大脑负责理解意图让TAMP当小脑和脊髓负责把意图变成安全可执行的动作。两者不是替代关系是分层协作。具体分工可以这样理解VLAπ0.5负责理解语言指令、识别场景中的目标物体、给出高层的动作意图比如抓取、放置到某区域、在开放场景里做语义决策。TAMP层负责把抓取翻译成具体的抓取位姿候选、做碰撞检测、规划无碰撞路径、验证可达性、处理抓取失败后的重试、维护任务状态机。这个分工的关键在于接口设计。VLA输出的是意图TAMP需要的是约束。中间这层翻译做得好不好直接决定成功率。3.2 agent.ts调度逻辑的落点热词里出现了agent.ts这不是偶然。Pigey的调度层大概率是用TypeScript写的agent逻辑这其实是个很有意思的工程选择。为什么不用Python因为调度层要处理的是异步事件、状态机、超时重试、多模块通信这些恰恰是TypeScript/Node.js生态的强项。而且agent.ts这种命名暗示它是一个智能体循环——感知、决策、执行、反馈的闭环。一个典型的agent循环大概长这样// 伪代码展示Pigey调度层的核心循环结构 async function agentLoop(instruction: string) { // 1. VLA解析指令产出高层意图 const intent await vla.parse(instruction, currentObservation); // 2. TAMP把意图翻译成可执行动作序列 const plan await tamp.plan(intent, sceneGraph); // 3. 逐个执行每步都做验证 for (const action of plan.actions) { const result await execute(action); if (!result.success) { // 4. 失败不是终点是重规划的触发点 const recovery await tamp.replan(action, result.failureReason); if (!recovery) break; } } }这段伪代码里最关键的是第4步失败被当作一等公民处理。传统VLA部署里模型输出一个动作序列执行完就完了失败了就整体重来。而Pigey的调度层把每个动作都当成可验证、可重试的单元失败信息会反馈给TAMP重新规划。这一层失败恢复机制是成功率从16.7%往上跳的核心贡献者之一。3.3 为什么这个分层能work一个生活化类比你可以把π0.5想象成一个刚来公司、业务理解很强但手很生的新人。你让他把这份文件归档到三号柜他完全懂你要什么但他可能走到柜子前发现柜门锁着、或者文件太大塞不进、或者走错了柜子。传统做法是培训这个新人让他反复练练到不出错。这就是微调。Pigey的做法是给这个新人配一个熟悉办公室的助理。新人说我要归档到三号柜助理说三号柜锁了用二号柜路径走这边不撞桌子文件先折一下才塞得进。新人还是那个新人但整个任务的成功率完全不一样了。这个类比里助理就是TAMP层新人就是VLA。助理不需要懂业务只需要懂物理世界和流程。这就是为什么Pigey不需要训练权重——它补的是物理常识和流程严谨性不是业务理解。4. 从16.7%到97.3%成功率是怎么一步步抠出来的4.1 拆解提升来源每一层贡献了多少97.3%这个数字不是一步到位的它是多个机制叠加的结果。我根据Pigey的思路把提升来源拆成几个层次这个拆解对想复现的人特别重要因为你需要知道每一层的ROI机制解决的问题预估贡献实现难度抓取位姿候选生成与筛选抓空、抓偏大中碰撞检测与路径规划撞桌子、撞物体大中高动作级失败重试单步失败导致整体失败中低任务状态跟踪中途丢目标中中语义意图校验拿错、放错小低执行超时与安全兜底卡死、异常小低注意这个排序贡献最大的两项都是几何层面的不是语义层面的。这再次印证了前面的判断——真机失败的主因在动作执行不在理解。抓取位姿候选生成这块具体做法通常是VLA给出一个粗略的抓取点TAMP层在这个点附近采样一批候选位姿然后用抓取质量评估比如力闭合分析、接触面积估计筛掉明显不行的剩下的按评分排序依次尝试。这一步就能把抓空类失败砍掉一大半。碰撞检测和路径规划更直接VLA给的目标位姿TAMP用运动规划器比如RRT类算法算一条无碰撞路径。如果算不出来说明这个目标在当前场景下不可达直接反馈给上层换策略而不是硬走。4.2 失败恢复被低估的成功率放大器我特别想强调失败恢复这一层因为它是很多团队做VLA部署时完全没做的。他们的逻辑是模型输出动作序列执行看结果。但真机环境里单步失败太常见了——抓取时物体滑了一下、路径上临时多了个障碍、某个关节到了限位。Pigey的调度层对每个动作都有明确的成功判据和失败分类。失败不是重来一遍而是带着失败信息重新规划。比如抓取失败它会区分是没碰到物体还是碰到了但滑脱前者调整位姿重试后者调整抓取力或换抓取点。这种分类恢复比无脑重试高效得多。实测中这一层的价值在于它把很多本来会导致整个任务失败的单点问题降级成了多花两秒重试一下。在成功率统计上这就是从失败变成成功的差别。4.3 97.3%意味着什么以及它不意味着什么97.3%听起来接近完美但我要泼盆冷水这个数字高度依赖任务定义和评测条件。如果任务是在固定工位上抓取固定几类物体并放置到固定区域97.3%是可信的。但如果任务是在完全开放的家庭环境里完成任意家务那这个数字不可能达到因为开放环境的语义复杂度远超TAMP层能覆盖的范围。所以看这个数字正确的姿势是看它的适用边界Pigey这套方法在任务结构相对固定、但物体和场景有变化的场景里威力最大。这恰恰是工业和服务机器人的主流场景。它不适合的是任务本身都说不清的完全开放场景那种场景还是得靠模型本身的泛化。理解这个边界比记住97.3%这个数字重要得多。5. 复现Pigey思路时我踩过的那些坑5.1 接口设计VLA输出什么给TAMP这个决定成败我一开始想当然地让VLA直接输出目标位姿TAMP拿去规划。结果发现VLA输出的位姿经常在物理上根本不可达——比如让机械臂去抓一个它够不到的位置或者抓取方向会让手爪撞到物体本身。后来改成VLA输出语义目标抓取杯子由TAMP层自己根据场景几何生成候选位姿效果好很多。这个改动的本质是不要让VLA做它不擅长的事。VLA擅长的是哪个物体不擅长的是从哪个角度抓。把后者交给几何算法各司其职。提示接口设计的第一原则是让每个模块只做它最有把握的事。VLA的位姿输出精度在厘米级而抓取需要毫米级这个gap必须由TAMP补不能指望VLA。5.2 状态跟踪物体被遮挡后整个任务就乱了真机场景里机械臂自己就会遮挡摄像头。物体一旦被手爪挡住VLA的下一帧观测就丢了目标动作立刻开始乱。我在这上面卡了很久。解法是维护一个场景图scene graph把物体的位姿在TAMP层做持续跟踪即使视觉暂时丢失也能靠运动学推算维持估计。等物体重新可见时再校正。这样VLA的输入就不完全依赖当前帧而是依赖一个更稳定的世界状态。这个改动让中途丢目标类失败大幅下降。代价是场景图的维护逻辑不简单要处理物体被移动、被遮挡、被其他物体覆盖等各种情况。5.3 重试逻辑不设上限会死循环设了上限会误判失败重试听起来简单做起来全是细节。我最初没设重试上限结果遇到一个永远抓不起来的物体系统在那死循环机械臂反复做同一个失败动作看着特别蠢。后来加了重试上限但又遇到新问题有时候第三次就成功了上限设成两次就误判了。最后的方案是按失败类型设不同上限位姿偏差类允许重试3次因为采样有随机性碰撞类只允许1次因为几何上不行就是不行重试浪费语义类不重试直接上报。这个策略调整后既避免了死循环又不会过早放弃。这种细节文档里不会写只有真跑过才知道。5.4 时序问题VLA推理慢TAMP等不起π0.5这类模型推理一次要几百毫秒甚至更久而TAMP的规划是毫秒级的。如果串行执行——VLA推理完TAMP再规划——整个循环会非常慢机械臂动作一顿一顿的。Pigey的调度层显然考虑了这点。合理的做法是流水线化VLA在推理下一步意图的同时TAMP在执行当前步的规划执行器在执行上一步的动作。三层并行整体延迟就藏起来了。agent.ts这种异步友好的技术栈在这里就体现出优势了。不过流水线化会带来状态一致性问题——VLA基于的是稍早的观测可能和当前实际状态有偏差。所以每步执行前还是要做一次轻量的状态校验确认前提条件还成立。6. 这套思路能迁移到哪些场景6.1 不只是机械臂任何模型给意图、系统保执行的场景Pigey这套不训练权重、外挂调度层的思路本质上是通用的。任何场景只要满足两个条件就能用一是有一个泛化能力够用但执行不稳定的基础模型二是执行结果可以被明确验证。比如自动驾驶里的决策规划感知模型给出前方有行人的意图规划层负责生成安全轨迹这本身就是分层。再比如文档处理Agent大模型负责理解需求工具调用层负责保证每个操作可回滚、可验证。逻辑是相通的。6.2 什么时候该训练权重什么时候该加调度层这是个决策问题我给个简单的判断框架如果失败原因是**模型根本不懂这个任务**那必须训练或换模型调度层救不了。如果失败原因是**模型懂但做不准、做不稳**优先加调度层成本低见效快。如果失败原因是**任务本身太开放、边界不清**那要先收敛任务定义再谈技术方案。大部分真机部署的失败属于第二类但很多团队误判成第一类于是花大力气微调效果还不一定好。Pigey的价值就在于它用实际数字证明了第二类问题的正确解法。6.3 一个容易被忽略的前提可验证性这套方法能work有个隐藏前提每个动作的结果必须可验证。抓取成功没成功可以通过力传感器或者视觉判断放置到位没到位可以检测。如果动作结果无法验证失败恢复就无从谈起整个调度层的价值会大打折扣。所以在设计系统时验证手段要和执行手段一起设计不能事后补。这是我从这个项目里得到的最重要的工程教训之一。7. 我个人的几点实操体会做这类模型外挂调度层的项目最大的感受是难点从来不在算法在工程细节的密度。抓取位姿采样用什么分布、碰撞检测用哪个库、重试上限怎么定、状态图怎么更新、超时阈值设多少——每一个都是小问题但几十个小问题叠起来就是16.7%和97.3%的差距。另一个体会是关于克制。Pigey最难得的地方是它没有去动π0.5。在一个人人都想训模型的圈子里忍住不训、转而把工程做扎实这需要判断力。我见过太多团队模型换了一茬又一茬成功率还是上不去因为他们的瓶颈根本不在模型。最后分享一个具体的小技巧如果你也在做VLA真机部署先把失败案例录下来逐帧看给每个失败打上分类标签。等你标够一百个失败案例你会惊讶地发现真正需要模型解决的可能不到两成。剩下的八成都是调度层能搞定的事。这个统计做完你的技术路线基本就清晰了。至于Pigey后续还能怎么扩展我觉得方向是把调度层的经验做成可复用的模板——不同任务共享同一套TAMP骨架只换任务定义。这样新场景的冷启动成本会进一步降低。不过这是另一个话题了等有更多实践再聊。