机器人技能商店 V1：商店负责什么，技能负责什么

普通应用商店面对的是软件依赖，机器人技能商店还要面对 GPU、操作系统、摄像头、CAN 接口、机械臂和灵巧手。V1 的目标不是包办技能执行，而是准确展示、判断兼容性、完成下载，并把执行交给技能自身。

先确定边界

商店负责四件事：读取云端技能元数据、展示、下载、发起执行。技能包负责自己的运行环境准备、设备连接、模型加载和动作逻辑。

商店是分发与编排入口，不是所有机器人技能的统一运行时。

这个边界能避免商店为了适配每个技能，逐渐变成包含所有驱动和模型框架的巨大程序。

用 Manifest 描述真实依赖

id: fine-assembly-terminal
version: 1.2.0
runtime:
  os: [ubuntu-24.04]
  arch: [x86_64]
  gpu:
    vendor: nvidia
    min_vram_gb: 16
hardware:
  cameras:
    - family: realsense
      models: [D435i, D455]
  can:
    required: true
    fd: true
  robots:
    - type: arm
    - type: dexterous-hand
entrypoint:
  command: ./run.sh

Manifest 的价值不是展示更多标签，而是让客户端在下载前回答一个关键问题：这台机器能否运行该技能。

兼容性检查分为三层

“未检测到”与“不兼容”必须区分。摄像头暂时未插入不等于机器永远不能运行技能；GPU 显存不足则是明确不兼容。

下载与安装必须可回滚

技能包建议按版本独立存放，下载到临时目录，完成校验后再原子切换。这样网络中断或解压失败不会破坏当前可用版本。

skills/
  wave-hand/
    1.3.0/
    1.4.0/
    current -> 1.4.0
  fine-assembly-terminal/
    1.2.0/

至少记录包哈希、安装时间、来源、Manifest 和最近一次运行结果。V1 不必立即实现复杂依赖解析，但必须保留版本边界。

执行协议要小而稳定

即使技能内部完全不同，商店仍需要知道启动是否成功、当前状态以及如何停止。可以约定最小生命周期：

• prepare：检查环境和设备；
• start：启动技能；
• status：返回运行状态和摘要；
• stop：安全停止并释放设备。

V1 可以通过子进程与标准化 JSON 日志实现，不必先引入复杂容器编排。

Docker 可以参与，但不能替代硬件设计

容器适合隔离 Python、CUDA 和模型依赖，但 CAN、USB、RealSense 与 NVIDIA GPU 都需要显式透传。某些实时性或驱动安装场景，宿主机运行更简单可靠。

V1 最小闭环

1. 云端维护技能元数据和版本；
2. 客户端读取列表并展示兼容性；
3. 用户下载指定版本；
4. 客户端校验、安装并记录；
5. 执行前再次检查真实设备；
6. 启动技能进程，展示状态和日志；
7. 支持停止、卸载和版本回退。

这个闭环已经能够覆盖挥手、加油等通用动作，也能描述精细装配、抓手指、插端子等高配置技能，而无需让商店理解每个技能内部算法。

下一阶段

在 V1 稳定后，再逐步加入依赖缓存、模型分层下载、许可证、签名验证、设备占用仲裁和技能组合。最重要的是先让元数据可信、安装可恢复、执行可停止。