技能库与端到端策略之争
端到端策略对阵技能库：构建人形机器人的两条路线，各自会在哪里失败，以及每种策略想要的截然不同的训练数据。
构建一个会做早餐的人形机器人有两条路。一条是训练单一网络，把摄像头像素直接映射到整段任务的电机指令，从头到尾一气呵成。另一条是备一架子命名好的技能：打蛋、倾倒、翻面、码放，再由一个规划器按序调用它们。这个选择看起来是架构决策，账单却落到了数据团队头上。
这是机器人学习中最古老、至今仍在争论的话题之一：端到端策略对阵技能库。它没有定论，也不该有定论。两种策略在不同的地方失败，想要的数据也不同。在不清楚自己究竟能采集到哪种数据的情况下就贸然选边，正是项目做到半年就卡住的原因。
端到端这一注
端到端策略把从观测到动作的整个映射，当作单一函数来学习。没有人为设计的技能边界，也没有脚本化的交接。模型自己琢磨出如何从端起平底锅过渡到把它放上灶头，而这个过渡不过是同一个策略在继续运行。
好处是实实在在的。阶段之间的过渡正是手工搭建的系统崩溃之处，而端到端模型从来不必去缝合它们，因为它压根没把它们拆开过。它还能发现流畅、彼此重叠的运动，把一个动作的收尾融进下一个动作的开头，这是僵硬的技能序列所不允许的。秉持这种思路的通用策略，正是 Physical Intelligence blog 所描述的方向，也是 NVIDIA Isaac GR00T 等大型多任务模型背后的取向。
代价是数据与可读性。一个覆盖长任务的单一网络，必须在多种条件下反复见到整段任务，而长时程示范恰恰是采集成本最高的一类。当策略失败时，没有模块可供归咎，也没有干净的介入点。你只能靠喂更多数据来调试这个黑盒，指望那种失败模式逐渐变稀。对于一段精修过的演示视频，这种不透明尚可容忍；可对于一个必须撑完整个班次的系统，它就成了你要带进每一次事故复盘的负担，因为一个你无法审视的策略，也是一个你难以认证的策略。
技能库这一注
技能库采取相反的立场。构建一组可复用的基元，每个都是一个职责清晰的小型闭环策略，再用更高层的规划器或策略把它们组合起来。早餐于是变成一段在技能之上运行的短程序，而不是一条冗长的反射弧。
优势在于可读性与复用。一个训练一次的抓取基元，能服务于数百个涉及抓取的任务。出问题时，你知道是哪个技能失败了，可以单独重新训练它。每个基元都是短时程的，因此只需较少的示范就能学好，而为一个任务采集的数据会强化每一个共享其基元的任务。追求广义操作的团队，包括 Skild AI 所讨论的工作，都依靠这种可组合性来覆盖多种行为，而无需为每种行为都定制一个模型。
弱点在于接缝。技能之间的每一次交接都是可能失败的地方。抓取结束时物体的角度略有偏差，而下一个技能被训练成假定一个干净的起点，接触的瞬间就崩了。管理这些过渡，并在一个技能交棒给下一个技能的边界处采集数据，才是那张整洁示意图所掩盖的难点。
你选择的架构，是在赌你更愿意把成本花在哪里：是花在吸收整段任务的模型容量上，还是花在把它由零件组合起来的数据结构上。
每种策略对数据的要求
正是在这里，选择不再抽象。两种策略想要的是物理上不同的数据集，而你往往在采集当下就已决定了自己能追求哪一种，远早于任何模型被训练出来。
| 维度 | 端到端策略 | 技能库 |
|---|---|---|
| 示范形态 | 长、连续、整段任务 | 短、按基元切分 |
| 标注需求 | 任务级的目标或指令 | 逐段的技能标签与边界 |
| 样本效率 | 较低；整段任务每次都要重新学 | 较高；基元跨任务共享 |
| 故障诊断 | 不透明；只能喂更多数据重训 | 可定位到某个命名的技能 |
| 长时程可靠性 | 随时程增长而退化 | 取决于过渡如何处理 |
跨本体语料库让这种对比更加鲜明。像 Open X-Embodiment 这样的混合数据集，用模块化技能更容易加以利用，因为一个基元可以在执行过它的任意本体上训练；而端到端策略则必须在互不匹配的动作空间之间，调和整段任务的轨迹。两条路都并非不可能，只是要求不同的记账方式。
中间路线正在胜出
如今大多数严肃系统都坐在两极之间。分层策略把技能与编排一起学习，于是基元不是手工脚本写死的，过渡也不是手工调出来的。arXiv Robotics (cs.RO) 上近期的操作类论文，越来越多地描述在一个学得的高层控制器之下，运行学得的底层技能，既保留了技能库的复用性，又保留了端到端训练的流畅性。这是务实的答案，而它同时继承了两位父母的数据胃口。需要老实承认的是，分层并不能消灭接缝。它只是把接缝挪进了模型内部，在那里它们更难被看见，但至少不再由一个凭感觉猜阈值的工程师去手工调校。
为你无法逆转的方向而采集
战略要点在于可选择性。连续、无标注、整段任务的示范可以服务于端到端模型，但事后你没法在不做昂贵切分和大量猜测的前提下，把它们干净地拆成基元。而带有技能边界标记的切分好、标注好的数据，随时都能重新拼接回整段任务序列。一个方向廉价，另一个则不然。
所以数据决策先于架构决策。采集时保留干净的分段边界、逐技能的标签，并把过渡与恢复的时刻都记录下来，你就同时保住了两种选项。采集成一条冗长、无标注的数据流，你就已经悄然选择了端到端，无论你是否有此本意。
没有放之四海皆准的赢家。端到端策略买来流畅，代价是数据与不透明；技能库买来复用与可读性，代价则在接缝处。保持灵活的团队，是那些不再把这当作一次性架构投票、而开始把它当作一项及早做出的数据采集决策的团队，从而让两种模型都留在桌面上。把数据结构化好，架构之争就变成一件你日后可以重新审视的事，而不是一件你被困于其中的事。