通用机器人基础模型走不通？VLA 的数据死结与模块化破局之路

从 RT-2 到 π0 到 Helix 到 GEN-0，VLA（视觉-语言-动作模型）是当前机器人领域最热的方向，也是唯一最可能通向通用机器人的路径。Physical Intelligence 融了 11 亿美金，Figure AI 估值 390 亿美金，Google 拿 Gemini 做机器人大脑。但在跟踪了两年的论文和架构演进之后，我的判断是：所有人都在追的那条路——端到端训练一个完全通用的 VLA 基础模型——短期内大概率走不通。 本文将从技术原理、数据瓶颈、产业格局到替代架构，系统论证这个判断，并提出一条更务实的模块化破局思路。

一、VLA 是什么：机器人的"大语言模型时刻"

1.1 从感知到行动的范式跃迁

传统机器人系统是模块化管线：感知模块识别物体 → 规划模块计算路径 → 控制模块执行动作。每个模块之间用手工定义的接口连接，在受控环境中工作尚可，一旦环境变化或任务灵活，接口就会崩溃。

VLA（Vision-Language-Action Model）代表了一种完全不同的范式：用一个端到端的神经网络，同时处理视觉输入、语言指令和动作输出。 输入一张机器人看到的图片和一句自然语言指令（"把红色杯子放到架子上"），直接输出连续的关节控制信号。没有中间的符号化表示，没有手工管线。

这个思路的灵感直接来自 LLM 的成功。LLM 的核心洞察是：如果你把足够多的文本数据灌给一个足够大的 Transformer，它会"涌现"出理解和推理能力。VLA 的赌注是：如果你把足够多的机器人操作数据灌给一个足够大的视觉-语言模型，它也会涌现出通用的操作能力。

1.2 核心架构：从 RT-2 到双系统设计

VLA 的架构演进经历了几个关键阶段：

第一代：端到端文本化（RT-2，2023）

Google DeepMind 的 RT-2 开创了 VLA 这个品类。它的核心思路极其简洁：把机器人的动作表示为文本 token（如 "1 128 91 241 5 101 127 217"），然后把这些动作 token 和普通的语言 token 混在一起，用一个预训练的视觉-语言模型（PaLM-E 或 PaLI-X）进行联合微调。从此，机器人控制变成了"另一种语言"。

RT-2 证明了一个关键假设：互联网规模的视觉-语言预训练知识可以迁移到机器人控制中。一个从未见过苹果的机器人策略，因为底层 VLM 在互联网数据中"见过"苹果，就能理解"把苹果放到碗里"这个指令。

第二代：流匹配与连续动作（π0，2024）

Physical Intelligence 的 π0 在 RT-2 的基础上做了关键改进：用 flow matching（流匹配）替代了离散的 token 预测，直接生成连续的动作轨迹，控制频率提升到 50Hz。它基于 PaliGemma 作为 VLM 骨干，在 Open X-Embodiment 的多机器人数据上训练，实现了 8 种不同机器人形态的跨身体泛化。

第三代：双系统架构（Helix / GR00T N1，2025）

Figure AI 的 Helix 和 NVIDIA 的 GR00T N1 引入了认知科学中的"双系统"设计，这也是目前 VLA 领域的主流架构：

• System 2（"慢思考"） ：一个 7B 参数的 VLM，运行在 7-10 Hz，负责场景理解、语言解析、任务规划。它把所有语义信息蒸馏为一个连续的 latent 向量
• System 1（"快行动"） ：一个 80M-100M 参数的 visuomotor 策略网络，运行在 200 Hz，接收 System 2 的 latent 向量作为条件，生成精细的关节控制信号

这种解耦设计解决了一个根本性矛盾：语义理解需要大模型和慢推理，而精细控制需要小模型和快响应。把它们塞进同一个网络会互相拖累。

Helix 02（2026 年 1 月发布）更进一步，将这个架构扩展到了全身控制——平衡、行走、操作同时进行——用一个神经网络替换了 Figure 机器人原来的 109,504 行手工 C++ 控制代码。

第四代：Harmonic Reasoning（GEN-0，2025）

Generalist AI 的 GEN-0 提出了一种新的思路，试图超越双系统的显式分离：Harmonic Reasoning 架构让感知 token 和动作 token 在同一个 Transformer 中以异步、连续时间流的方式交织处理。"思考"和"行动"不再是两个独立阶段，而是共同演化的连续过程。

1.3 当前竞争格局：谁在做什么

公司/机构	模型	参数量	核心特点	融资/估值
Physical Intelligence	π0 / π0.6	3-5B	流匹配、跨形态泛化、开源	融资 $11 亿，估值$56 亿
Figure AI	Helix / Helix 02	~7B (S2) + 80M (S1)	双系统、全身控制、人形机器人	融资 $19 亿+，估值$390 亿
Google DeepMind	Gemini Robotics	基于 Gemini 2.0	超强推理、零样本跨形态迁移	Google 内部
NVIDIA	GR00T N1	双系统	异构数据混合训练	NVIDIA 内部
Generalist AI	GEN-0	7B-10B+	Harmonic Reasoning、27 万小时数据	未公开
Hugging Face	SmolVLA	450M	开源、轻量、社区数据	开源项目
阿里巴巴	ABot-M0	—	Action Manifold Learning	内部

二、数据死结：为什么端到端通用 VLA 短期走不通

2.1 GEN-0 揭示的 Scaling Law 真相

GEN-0 的研究提供了目前最清晰的机器人 Scaling Law 实证证据，结论令人清醒：

发现一：7B 是能力相变的门槛。

在 GEN-0 的实验中，1B 参数的模型在大规模数据下出现"骨化"（ossification）——权重失去吸收新信息的能力。6B 模型开始受益于预训练。只有 7B+ 的模型才能真正内化大规模机器人预训练数据，并迁移到下游任务。

GEN-0 团队指出，这个现象呼应了莫拉维克悖论：人类觉得轻而易举的感知和灵巧操作，对计算系统来说需要的复杂度远超抽象推理。 在 LLM 文献中，骨化现象出现在约 10M 参数级别；在机器人领域，这个阈值跃升到了 1B 级别。

发现二：下游任务误差与预训练数据量呈幂律关系——$L(D) ∝ D⁻⁰·⁵$。

这意味着数据量每翻一倍，性能只提升约 30%。要从"勉强可用"提升到"可靠部署"，需要数量级的数据增长。

这两个发现加在一起构成了一个严酷的现实：你至少需要 7B+ 的模型（否则根本无法利用数据），同时还需要海量的高质量操作数据（否则 7B 模型也白搭）。

2.2 数据采集的物理速度极限

LLM 的数据来自互联网——几十亿网页、万亿 token，爬取速度只受带宽限制。VLA 的数据必须让真实机器人在真实环境里一帧一帧录制。

GEN-0 号称 270,000 小时的操作数据，已是行业天花板。我们来算一笔账：

• GEN-0 的数据采集速度：每周 10,000 小时（意味着有大量并行采集站点）
• GPT-3 的训练数据：约 45TB 文本，数万亿 token
• VLA 的 270,000 小时视频：假设 10fps、每帧 1KB 特征表示 ≈ 约 10TB

看起来数据量级接近？问题在于信息密度完全不同。 互联网文本中每个 token 都携带语义信息。机器人操作视频中，大量帧是冗余的（机器人在等待、移动到位、空闲状态）。有效的"决策点"远少于总帧数。有研究估算，如果要通过 VLA 的 scaling law 达到真正通用的操作能力，需要的有效训练数据量可能是当前最大数据集的 2500 倍以上。

更致命的是：你有一万张 H100 也没用。数据采集被物理世界的速度卡死了。一个机器人折一件衣服需要 2 分钟，你无法让它在 2 秒内完成。物理世界没有"倍速"按钮。

2.3 模拟器能否破局？

一个自然的反应是：用模拟器生成数据。NVIDIA 的 GR00T N1 确实使用了"数据金字塔"——从互联网视频到模拟数据到真实遥操作数据的混合。Gemini Robotics 也大量使用仿真。

但模拟器面临一个根本性的困难——Sim-to-Real Gap（仿真到现实的差距）：

• 物理引擎的不完美：现实世界中软物体（衣服、食物）、流体、多体接触的物理行为极难精确模拟
• 视觉域差异：模拟器渲染的图像与真实相机拍摄的图像在纹理、光照、噪声上有系统性差异
• 长尾场景：真实世界中的意外情况（物体滑落、遮挡、变形）在模拟器中很难穷举

a16z 的一篇深度分析指出了一个残酷的现实：研究论文可以在集群上跑推理然后报告结果，但生产部署需要在机器人能实际承载的硬件上运行。 一个 7B VLA 在边缘硬件上的推理时间约 50-100ms，对应 10-20 Hz 的控制频率——这对于需要紧密反馈环的灵巧操作来说是不够的。

2.4 资源错配的核心论点

把以上分析综合起来，我的核心判断是：

在数据约束短期内无法突破的前提下，追求一个"完全通用的 action model"是资源错配。

具体来说：

1. Scaling Law 要求 7B+ 模型 + 海量数据，但当前最大的真实机器人数据集仍远不够
2. 数据采集受物理速度限制，无法像 LLM 那样通过增加爬虫来线性扩展
3. 模拟器数据的 Sim-to-Real Gap 在精细操作场景中仍然显著
4. 资本和人才注意力被 LLM 吸走，机器人方向相对投入不足

这不意味着通用 VLA 永远不可能。这意味着现阶段，把所有资源押注在"训一个完全通用的端到端 VLA"上，大概率是一条效率很低的路。

三、Claude Code 的 Skill 机制给我的启发

3.1 通用模型 + 可插拔技能的架构哲学

最近在使用 Claude Code 时，它的 Skill 机制给了我一个很直接的启发。

Claude Code 的工作方式是：Claude 本身是通用大模型，负责理解意图和推理。当遇到具体的专业任务时（比如创建 Word 文档、处理 PDF、生成 PPT），它会动态加载对应的 Skill 文件来获取专业知识和操作规范。Skill 文件是独立的、可插拔的、按需加载的。

这个架构思路背后的逻辑是：

• 通用能力和专业执行是两种不同的能力，不应该强行塞进同一个模型
• 通用能力（语言理解、推理、规划）已经被互联网规模的预训练很好地解决了
• 专业执行（具体文件格式的操作规范、领域特定的最佳实践）用轻量的、可更新的知识模块来承载

这个架构思路可以直接平移到机器人上。

3.2 VLM + Action Skill 的模块化架构

具体方案：

层一：通用 VLM 底座（共享层）

直接复用现成的通用大模型——Gemini、Qwen-VL、LLaMA-Vision 等——作为视觉-语言骨干。这层负责：

• 场景理解（识别物体、空间关系、材质属性）
• 指令解析（理解自然语言任务描述）
• 任务规划（把高层指令分解为子任务序列）
• 常识推理（"这个杯子是易碎的，应该轻拿轻放"）

这些能力已经被互联网规模的预训练很好地训练了，不需要从头训练，也不需要机器人操作数据。

层二：轻量 Action Skill（可插拔层）

针对每个垂直应用场景，训练一个轻量的 action model 作为技能模块。每个 Skill 负责：

• 将 VLM 的语义 latent 表示转换为具体的关节控制信号
• 适配特定的机器人形态和动作空间
• 处理特定场景的精细操作约束

Action Skill 的参数量可以很小——80M-100M 级别——因为它不需要"理解世界"，只需要"执行动作"。

层三：接口协议（标准化层）

VLM 和 Action Skill 之间需要一个标准化的通信接口。这个接口定义了：

• VLM 向 Action Skill 传递什么信息（latent 向量的维度和语义）
• Action Skill 向 VLM 反馈什么状态（执行是否成功、当前观察）
• 技能切换的协议（何时从一个 Skill 切换到另一个）

3.3 这个架构解决了什么问题

问题一：数据效率

每个 Action Skill 只需要对应场景的少量示范数据。DiffusionVLA（ICML 2025）的研究表明，通过将自回归推理与扩散策略结合，可以用很少的示范数据训练出可用的操作策略。SmolVLA 的实验证明，用不到 30,000 个 episode 就能训练出与大型 VLA 媲美的性能。Figure AI 的 Helix 只用了约 500 小时的示范数据就实现了对数千种未见物体的泛化。

对比来看：训练一个端到端通用 VLA 需要 270,000+ 小时数据，而训练一个场景特定的 Action Skill 可能只需要几十到几百个示范。数据效率差了几个数量级。

问题二：跨机器人适配

不同机器人的动作空间完全不同——一个 7-DoF 机械臂、一个 32-DoF 人形机器人、一个差速底盘的移动机器人，它们的关节构型、自由度、力矩限制都不一样。强求一个模型输出所有动作空间的控制信号，等于要求它同时学会弹钢琴、开飞机和做手术。

模块化架构直接绕过这个问题：不同机器人装不同的 Action Skill。VLM 底座是共享的（"把杯子放到架子上"的语义理解对所有机器人都一样），只有执行层针对具体硬件适配。

Green-VLA（2026）的研究提出了一种 Unified Action Space 的方案：把所有运动投影到统一的 R⁶⁴ 空间。但这种投影本身引入了信息损失，且对新增机器人形态需要重新设计投影方式。相比之下，可插拔的 Action Skill 更加灵活和工程友好。

问题三：延迟与部署

这是当前 VLA 部署中最被低估的问题之一。a16z 的分析指出：当前 7B VLA 在边缘硬件（如 NVIDIA Jetson Orin）上的端到端延迟中，高达 75% 被内存带宽受限的动作生成阶段消耗。

模块化架构天然解决了这个问题：

• VLM 跑云端：做低频推理（1-10 Hz），处理场景理解和任务规划
• Action Skill 跑本地：做高频控制（50-200 Hz），处理精细操作

这正是 Helix 和 GR00T N1 的双系统架构已经在做的事情。区别在于：在现有方案中，System 1 和 System 2 是端到端联合训练的；在模块化方案中，VLM 底座是预训练冻结的，只有 Action Skill 需要训练。这大幅降低了训练成本。

四、关键未解问题：接口协议怎么定义

4.1 核心挑战：latent 表示的标准化

VLM 和 Action Skill 之间的接口是这个架构的咽喉要道。如果定义得不好，模块化的优势就不存在了。

当前的双系统架构中，System 2 传递给 System 1 的通常是一个固定维度的 latent 向量。但这个向量是端到端训练出来的，没有显式的语义结构——它是一个"黑盒"表示。

要让 Action Skill 真正可插拔，接口需要更加结构化。几种可能的方向：

方向一：语义化中间表示

不传递黑盒向量，而是传递结构化的任务描述：目标位姿、约束条件、力控参数等。这类似于传统机器人中的"任务空间"表示，但由 VLM 自动生成。

方向二：自然语言子任务序列

VLM 输出自然语言格式的子任务描述（如"左手移动到杯子上方 5cm → 张开夹爪 → 下降 5cm → 闭合夹爪 → 提升 10cm"），Action Skill 解析执行。Google 的 SayCan 和 PaLM-E 已经探索了这个方向。

方向三：多层级 latent 通信

借鉴 Helix 的做法，定义多个层级的通信：高层目标（what）、中层轨迹（how roughly）、低层控制（how exactly）。每层都有标准化的维度和语义。

方向四：学习出来的通用接口

训练一个"接口转换器"（Interface Adapter），它的输入是任意 VLM 的输出，输出是标准化的条件向量。类似于 NLP 中 adapter 的思路。

4.2 MCP 给出的平行启示

值得注意的是，在 LLM Agent 领域，一个类似的接口标准化问题正在被解决。Anthropic 提出的 MCP（Model Context Protocol）定义了 LLM 与外部工具之间的标准通信协议。MCP 的核心设计：

• 工具描述标准化（每个工具声明自己能做什么、需要什么输入）
• 调用接口统一（请求格式、响应格式、错误处理）
• 工具可独立开发和部署

如果把 MCP 的理念移植到机器人领域——定义一套 Robot Skill Protocol——每个 Action Skill 声明自己能处理什么任务、需要什么传感器输入、输出什么格式的控制信号——就能实现真正的生态化分工。

4.3 生态效应：从"一家公司训一个通用模型"到"所有人贡献场景 Skill"

如果接口协议做好了，整个机器人智能的生态格局将发生根本性变化：

当前格局：每家公司独立训练自己的端到端 VLA，数据不共享，训练成本高，重复劳动严重。

模块化格局：

• VLM 底座提供商：Google（Gemini）、阿里（Qwen-VL）、Meta（LLaMA-Vision）提供通用视觉-语言理解能力
• Action Skill 开发者：垂直场景的集成商独立开发自己的操作技能——餐饮场景的抓取技能、物流场景的分拣技能、家庭场景的清洁技能
• 接口标准组织：定义 VLM-Action Skill 的通信协议
• 开源社区：像 Hugging Face 的 LeRobot 那样，社区贡献和共享 Action Skill

这个生态与当前 LLM 领域的生态高度相似：大模型厂商提供基础能力，应用开发者在上面构建垂直解决方案，接口协议（如 OpenAI API 格式）确保互操作性。

五、技术验证：哪些证据支持模块化方向

5.1 Helix 和 GR00T N1 本质上已经是模块化的

仔细看 Figure AI 的 Helix 架构：System 2 是一个 7B 的 VLM，System 1 是一个 80M 的 visuomotor 策略。它们之间通过一个 latent 向量通信。这本质上就是一种模块化设计——只不过两个模块目前是端到端联合训练的。

如果把 System 2 换成一个通用的预训练 VLM（冻结权重），只训练 System 1 的 Action Skill 部分，训练成本将大幅下降，同时可以利用 VLM 在互联网数据上获得的强大语义理解能力。

NVIDIA 的 GR00T N1 的"数据金字塔"策略也暗示了这个方向：用互联网视频和模拟数据训练通用的视觉-语言理解（对应 VLM 底座），用少量真实遥操作数据训练具体的操作策略（对应 Action Skill）。

5.2 SmolVLA 证明了小模型 + 好骨干 = 大模型性能

Hugging Face 的 SmolVLA 是这个方向最直接的实验验证。它只有 450M 参数（VLM 骨干 + 约 100M 的 Action Expert），用 LeRobot 社区数据训练，但在多个基准上达到了与 OpenVLA（7B）和 π0 媲美的性能。

SmolVLA 的架构设计处处体现了模块化思想：

• 层跳跃（Layer Skipping）：Action Expert 只关注 VLM 中间层的特征，跳过上层——因为上层更偏语言生成，对动作预测帮助不大
• 异步推理：VLM 的感知推理和 Action Expert 的动作生成解耦运行，各自按自己的频率工作
• 视觉 token 压缩：每帧只用 64 个 token，而不是 1024 个

5.3 DexVLA 验证了"VLM骨干 + 可插拔扩散专家"的可行性

DexVLA 的架构与我提出的方案高度一致：使用 Qwen2-VL 2B 作为 VLM 骨干，外加一个 1B 参数的 Diffusion Expert 作为动作专家。关键设计：

• VLM 生成"推理 token"和"动作 token"两种输出
• 推理 token 用自然语言表达任务分解
• 动作 token 作为 Diffusion Expert 的条件输入
• Diffusion Expert 使用多头输出设计，每个头对应一种机器人形态——这正是"可插拔 Action Skill"的雏形

更有意思的是，DexVLA 在 VLM 和 Action Expert 之间放了一个 stop gradient——防止动作预测的梯度"污染" VLM 的语言能力。这个设计选择明确表达了"通用理解和专业执行应该解耦"的工程直觉。

5.4 Gemini Robotics On-Device：云端+本地的混合部署验证

Google DeepMind 在 2025 年 6 月发布的 Gemini Robotics On-Device 是对"大模型跑云端、轻量模型跑本地"这个部署模式的直接验证。它是 Gemini Robotics 的轻量版，优化了本地运行的延迟和可靠性，同时保持了灵巧操作能力。

这证明了：高频控制完全可以在边缘设备上完成，不需要把整个大 VLM 塞进机器人里。

六、反驳与风险：模块化方案的局限性

6.1 端到端论者会怎么说

反驳一："端到端训练的信息传递更高效"

的确，模块化接口必然带来信息损失。VLM 内部的完整表示被压缩成一个 latent 向量或结构化描述时，某些微妙的语义信息可能丢失。端到端训练允许 System 1 和 System 2 之间发展出高效的、task-specific 的通信编码。

我的回应：这个论点在理论上成立，但在实践中被数据瓶颈压过。端到端训练的信息效率优势，需要足够的训练数据才能体现。如果数据不够，端到端训练反而容易过拟合到训练场景。模块化方案虽然接口有损，但可以用预训练 VLM 的强大泛化能力来弥补。

反驳二："通用 VLA 正在快速进步"

Physical Intelligence 的 π0.6 引入了 RECAP（从经验和纠正中学习的 RL），展示了 VLA 可以通过在线学习持续改进。GEN-0 的 scaling law 证明了数据量的增加确实能带来可预测的性能提升。

我的回应：进步是真实的，但速度不够。270,000 小时已经是天花板级的数据量，而且每周只能增加 10,000 小时。按 scaling law 的幂律关系，要达到"可靠部署"级别，可能还需要数量级的增长——这在物理采集约束下需要数年时间。模块化方案是在这个等待期内"先把能落地的事做了"。

6.2 模块化方案自身的风险

风险一：接口标准化的鸡生蛋问题

没有标准就没有生态，没有生态就没人愿意定义标准。LLM 领域之所以快速收敛到 OpenAI 的 API 格式，是因为 OpenAI 有压倒性的市场份额。机器人领域还没有这样的霸主。

风险二：Action Skill 的泛化上限

每个 Skill 只针对特定场景训练，场景之间的迁移能力有限。如果一个餐饮 Skill 遇到了训练中没见过的餐具，它可能无法处理。通用 VLA 理论上可以通过共享表示来缓解这个问题。

风险三：系统复杂度

模块化引入了额外的系统复杂度——模块间通信的延迟、版本兼容性、故障隔离等。在生产环境中，这些工程问题可能比模型性能更加棘手。

七、路线图：如果你想沿着模块化方向做事

7.1 对研究者

1. VLM-to-Action 接口的标准化研究：目前最缺乏的研究方向。需要系统性地对比不同接口设计（latent 向量 vs 结构化描述 vs 自然语言子任务）的信息保真度和泛化能力
2. 少样本 Action Skill 训练：进一步降低每个 Skill 所需的示范数据量。DiffusionVLA、TinyVLA 的方向值得继续深挖
3. Skill 组合与迁移：研究多个 Skill 如何组合执行复杂任务，以及 Skill 之间的知识迁移

7.2 对创业者

1. 垂直场景的 Action Skill 供应商：选择一个垂直场景（餐饮、物流分拣、农业采摘），针对特定机器人形态训练高质量的 Action Skill。护城河在于场景 know-how 和数据积累
2. Robot Skill Protocol 标准的推动者：成为机器人领域的"OpenAI API 格式"制定者。这需要强大的生态号召力，可能由 NVIDIA（GR00T 平台）或 Hugging Face（LeRobot）来牵头
3. Action Skill 的自动化生成：类似于 LLM 的 fine-tuning 服务，提供"上传示范数据 → 自动训练 Action Skill → 部署到机器人"的 SaaS 平台

7.3 对工程师

1. 学习 LeRobot 和 SmolVLA：Hugging Face 的 LeRobot 是目前最好的开源 VLA 训练框架，SmolVLA 是模块化架构的优秀参考实现
2. 理解双系统架构：Helix 和 GR00T N1 的论文是必读材料，它们代表了 VLA 架构的最前沿
3. 关注 MCP 在机器人领域的扩展：如果有人把 MCP 的理念适配到机器人技能协议上，这可能成为行业标准

八、结论：先用模块化把能落地的事做了

通用机器人基础模型是一个美好的愿景。在足够长的时间尺度上，它大概率会实现——当数据采集技术突破物理速度极限（比如通过高度逼真的仿真、人类视频到机器人策略的迁移、或全新的数据采集范式），当 Scaling Law 在机器人领域被充分验证，当算力成本继续下降。

但现阶段的数据现实不支撑这个愿景的短期实现。

与其把所有赌注押在"复现 LLM 的 Scaling Law 奇迹"上，不如先用模块化架构把能落地的事做了：

• 用互联网规模预训练的 VLM 解决"理解世界"的问题——这个问题已经被解决了
• 用轻量可插拔的 Action Skill 解决"在特定场景中执行特定操作"的问题——这个问题用少量数据就能解决
• 用标准化的接口协议把两者连接起来——这个问题需要生态共建

这条路不是对通用 VLA 的否定，而是在通用 VLA 成熟之前的务实过渡方案。当 Scaling Law 在机器人领域被充分验证的那天，模块化架构中的 Action Skill 自然可以被一个通用的 Action Model 替代。但在那之前，模块化让我们可以用今天能获得的数据，在今天就部署有用的机器人。

毕竟，LLM 的辉煌不是因为一步到位训了一个通用模型，而是因为它先在编程辅助、客服、写作等垂直场景中证明了价值，然后才逐步走向通用。机器人智能的路径，大概率也是如此。

致谢：本文的核心架构灵感来自 Claude Code 的 Skill 机制。技术分析基于 RT-2、π0、Helix、GR00T N1、GEN-0、SmolVLA、DexVLA、DiffusionVLA 等公开论文和技术报告。产业数据来自公开的融资和估值信息。

互动话题：你认为机器人智能的突破口在于端到端的通用模型，还是模块化的"VLM + Action Skill"架构？你所在的机器人项目中，数据瓶颈有多严重？欢迎在评论区交流。