机器人基础模型、视频即提示词、具身智能这三个词放在一起就是今天要聊的主题Skild S1。接触过机器人控制或具身智能项目的人应该都有体会过去要让机器人执行一个任务通常要写任务描述、给目标图像、设计奖励函数甚至逐帧标注动作轨迹。而 Skild S1 想换一种交互方式——把一段人类演示视频直接当作提示词输入让机器人理解视频里发生了什么任务、涉及哪些物体、动作顺序是什么然后在物理世界中复现。这种视频即提示词的范式本质上是在降低机器人任务定义的门槛让机器人从听指令干活走向看视频干活。先说清楚核心特点。Skild S1 是一类机器人基础模型而不是某个只能在固定环境跑固定脚本的专用算法它的交互入口是视频用户提供演示素材模型自行拆解任务并生成控制策略它面向的硬件是物理机器人本体或仿真环境不是 AIGC 领域那种出图出视频的生成模型围绕它的工程问题主要集中在数据采集、视频预处理、动作控制、仿真验证和真机部署。本文会从概念拆解、技术原理、实验环境、验证流程、API 化方向和工程排查几个角度展开帮你在不用动手之前就能判断这个方向适不适合自己团队跟进。这篇文章适合的读者很明确做机器人控制、具身智能、仿真到真机迁移的研究和工程人员关注 AI Agent 向物理世界延伸的产品和技术负责人以及正在评估视频即提示词这套交互范式能否落到自有业务场景的开发者。需要先说清楚Skild S1 目前的公开信息更多集中在技术方向和研究思路上具体部署参数、开源权重、接口地址都要以官方资料为准。所以本文会提供一套通用验证框架和工程思路不会伪造一张所谓的实测显存表。1. 核心能力速览先给一张总览表把最核心的信息放在前面。下面这些描述基于公开信息整理凡是涉及具体部署参数的地方标注为需以官方资料为准避免误导。能力项说明项目类型机器人基础模型Robot Foundation Model核心交互方式视频即提示词输入人类演示视频输出机器人任务理解和控制策略主要能力任务拆解、动作序列生成、物体交互理解、跨本体泛化技术方向具身智能、多模态学习、视觉-语言-动作模型、模仿学习适用硬件物理机器人本体、仿真环境需要以官方支持列表为准是否支持 CPU 推理不确定大型基础模型通常依赖 GPU需以官方环境要求为准是否支持批量任务从工作流设计上支持批量处理具体取决于部署方式和接口设计是否有 API不确定需以官方发布的服务形态为准是否开源需以官方公告为准适合场景机器人操作研究、仿真测试、视觉-动作关联学习、自动化任务演示与复现从这张表能看出什么Skild S1 的价值不在多了一个大模型而在改变了机器人任务的定义方式。传统机器人流程里定义任务通常需要精细的状态机、行为树、或者是强化学习里的奖励函数。而视频即提示词把任务定义直接变为给一段视频模型自己负责把视频理解成可执行的动作策略。对研究团队来说这能显著缩短任务设定时间对工程团队来说则需要重新设计数据管理、视频预处理和真机验证链路。2. 什么是视频即提示词视频即提示词是理解 Skild S1 的关键。先对比一下传统做法和新做法之间的差异。传统方式大致是这样的机器人工程师先定义任务目标然后把目标拆成一系列子步骤每个子步骤对应一个状态检测和一个动作指令。复杂任务还要设计状态机或行为树遇到环境变化时经常要重新调整分支逻辑。即使使用强化学习也要精心设计奖励函数否则训练出来的策略在真实环境里很容易产生意料之外的行为。整个过程的时间成本很高而且高度依赖工程师的经验。视频即提示词换了一个思路任务的定义不再依赖文本和奖励函数而是依赖视频示范。模型看一段视频提取里面的人类动作、物体状态变化和交互顺序然后把这些信息映射到机器人的动作空间里。这里的视频不是简单的目标图片序列它天然包含了时序信息、手-物交互方式、工具使用过程以及任务完成的标准。从信息论的角度看视频比文本和单帧图像都更适合表达物理世界中的任务。视频作为提示词还有一个重要优势它把任务描述和任务示范合二为一。在用文本提示词时模型要先理解抽象的语义再想象物理世界的执行过程中间有信息损失。而视频直接展示了执行过程模型要做的是理解与复现而不是想象与猜测。这也是为什么机器人基础模型的研究普遍在向视频输入靠拢。不过要提醒一点视频即提示词目前还不是一个万能解法。机器人要复现视频中的行为前提是模型已经掌握了相应的运动能力和物体的物理属性。如果任务涉及的交互过于复杂比如多步工具操作、柔性物体处理视频即使提供了示范也不一定就能生成稳定可执行的动作策略。更稳妥的判断是视频即提示词擅长的是中低复杂度的操作任务尤其是那些可以被分解为接近-抓取-移动-放置-操作这类基本动作组合的任务。3. 技术原理与架构理解Skild S1 这类机器人基础模型的技术栈可以从四个层面理解视频编码、任务理解、动作解算、与机器人本体的对接。3.1 视频编码层视频输入不能直接塞给传统的全连接网络需要先做时空特征提取。常见做法是把视频切分为短片段每个片段通过 3D 卷积或 Video Transformer 编码为时空特征向量。特征里必须包含空间信息物体在哪、长什么样和时间信息物体怎么移动、手怎么操作。对于机器人任务来说手-物交互建模尤其关键模型要能识别手正在抓取杯子的把手和手正在推杯子的侧面这两者之间的动作差异。3.2 任务理解层拿到视频特征之后模型要回答三个问题任务目标是什么、当前状态是什么、完成标准是什么。这个层面通常会借助语言模型和视觉模型的联合推理也就是把视频特征映射到任务语义空间里。例如一段倒水的视频模型需要理解到目标是让液体从一个容器进入另一个容器完成标志是动作结束且没有明显溢出。3.3 动作解算层这是机器人基础模型和通用视频理解模型最不一样的地方。理解视频只是第一步最关键的是把理解结果变成机器人的关节角度、末端位置或力控指令。动作解算层要根据机器人的运动学模型、当前关节状态和环境约束生成一条可行的运动轨迹。常见的输出形式包括关节位置序列、末端执行器速度指令、动作基元序列。由于视频里的示范者是人体而执行者是机械臂两者运动学和动力的差异是动作解算层必须处理的核心难点。3.4 本体适配层同一个模型能否适配不同型号的机器人是评判基础模型成色的一个重要依据。不同机器人的关节数量、自由度、抓取器类型、传感器配置都不同所以模型需要有一个本体适配模块把统一的动作表示映射到具体机器人的执行指令上。从公开研究趋势看这种适配通常通过两种路径实现一种是在训练阶段加入大量异构机器人数据让模型学会忽略本体差异另一种是在部署阶段做少量参数微调适配新本体的运动学参数。4. 适用场景与使用边界4.1 适合谁用首先适合高校和企业的机器人实验室。实验场景里经常需要让机械臂完成固定动作比如抓取、分拣、组装、搬运。过去每换一个任务就要重新写逻辑用了视频即提示词之后演示一遍就可以作为任务输入迭代速度会快很多。其次适合做仿真到真机迁移的团队。仿真环境里可以批量生成大量演示视频这些视频可以直接作为模型训练和验证的输入。模型在仿真里学到的策略再迁移到真机时可以通过真机演示视频 仿真策略初始化的方式快速对齐。第三适合自动化和智能制造领域的方案商。如果业务里有大量重复但非标准化的操作比如不同型号零件的装配、检测、包装传统自动化产线改造成本很高。视频即提示词提供了一条快速重新定义任务的路径给机器人看一段示范视频它就能切换操作方式。4.2 不适合什么场景不适合对精度和安全性要求极高、且任务允许用传统自动化方式实现的场景。工业场景里如果任务是每秒重复几千次的高精度装配传统 PLC 或专用运动控制方案依然是最可靠的选择。大模型当前更适合处理柔性、多变、非标准化的任务它的输出稳定性和精度还需要更多工程验证。不适合实时性要求极高的场景。视频推理、任务理解和动作解算这三步都需要时间目前很难做到毫秒级响应。如果机器人需要在高速运动过程中实时决策那基于预训练基础模型的方案不一定比传统控制回路更快。4.3 使用边界与合规提醒使用机器人和视频演示相关技术时有几个边界必须守住。第一采集演示视频时要注意隐私和肖像授权。如果视频里有真人操作者的正面、手部特写或私人环境需要获得当事人和环境所有者的明确授权尤其是用于商业用途时。第二涉及人形机器人、仿人动作、人体运动数据时要避免产生对特定人群的偏见或歧视性行为同时注意生物识别数据的安全存储和合规使用。第三机器人操作涉及物理安全。在测试阶段必须设置急停、力度限制和安全围栏防止机器臂在复现视频动作时因为理解偏差而对人或设备造成伤害。任何物理世界里的实验都要保证测试环境的合法合规和安全边界。5. 环境准备与实验条件虽然 Skild S1 的官方文档尚不完整但机器人基础模型类项目的实验环境是有共性可循的。下面给出一套通用环境准备思路具体依赖项需要按实际项目替换。5.1 硬件环境机器人基础模型通常涉及视觉编码和动作解码GPU 几乎是必须的。建议优先准备一块支持 CUDA 的 NVIDIA 显卡显存大小取决于模型规模和数据分辨率越大的视频输入和批量处理任务越消耗显存。没有官方显存数据时不要轻信网上流传的最低要求要以实际部署时的日志为准。磁盘空间方面视频数据集通常很大建议预留 500GB 以上空间方便存放原始视频、预处理后的特征和模型权重。如果团队预算有限可以先在仿真环境里跑流程验证再考虑真机部署。仿真环境对硬件的压力相对较低调通后再租用 GPU 实例做训练和推理测试是一种成本可控的实验方式。5.2 软件环境通用软件栈可以这样组织# Python 环境建议 3.10 或更高版本 conda create -n robot_vlp python3.10 conda activate robot_vlp # 深度学习框架安装时注意 CUDA 版本匹配 pip install torch torchvision # 视频处理 pip install opencv-python ffmpeg-python # 科学计算与可视化 pip install numpy scipy matplotlib这里有个容易踩坑的点视频编解码库的版本。采集到的演示视频可能是 H.264、H.265甚至是手机拍摄的 MOV 格式。建议统一转换为 mp4 或 npy 序列后再进入模型流程否则帧率不稳定、分辨率不一致会导致预处理阶段反复报错。5.3 仿真环境准备如果没有真机建议先搭一个仿真环境。常见的机器人仿真工具有 MuJoCo、PyBullet、Isaac Sim 等选择哪个取决于团队熟悉程度。仿真环境里可以快速生成演示视频也可以通过随机化初始状态和物体位置来生成大量变体视频用于测试模型的泛化能力。# 伪代码示例仿真环境中生成演示视频并记录动作 import numpy as np def record_demo_video(env, agent, video_path, episode_len200): frames [] actions [] obs env.reset() for step in range(episode_len): action agent.act(obs) obs, reward, done, info env.step(action) frames.append(env.render(modergb_array)) actions.append(action) if done: break save_video(frames, video_path) save_actions(actions, video_path.replace(.mp4, .npy))这段伪代码展示了仿真环境中视频 动作联合采集的基本思路。真实项目中视频和动作数据需要严格对齐时间戳不一致会直接影响训练效果。6. 部署与启动方式机器人基础模型不像常规 Web 服务那样有统一的部署模式一般包括离线推理、在线服务和真机部署三种形态。下面给出每一种形态的启动思路。6.1 离线推理模式离线模式下模型一次性读取多个视频文件输出对应的动作策略文件。适合批量验证和数据集处理。启动流程一般是加载模型、读取视频目录、逐条推理、保存结果。# 通用启动命令模板实际路径需要替换 python run_inference.py \ --model_path ./checkpoints/skild_s1_latest.pt \ --video_dir ./demo_videos/ \ --output_dir ./output_policies/ \ --batch_size 4 \ --device cuda:06.2 在线推理服务如果要把模型集成到自己的工具链里通常会把推理封装成 HTTP 服务。参考通用的推理服务框架启动时先加载模型到显存然后开一个 HTTP 端口接收视频请求。注意服务端需要做请求队列避免多个视频同时到达时显存溢出。# 通用 FastAPI 推理服务模板 from fastapi import FastAPI, File, UploadFile import torch import tempfile app FastAPI() model None # 实际项目中在这里加载模型 app.post(/infer) async def infer_video(video: UploadFile File(...)): with tempfile.NamedTemporaryFile(suffix.mp4, deleteTrue) as tmp: tmp.write(await video.read()) tmp.flush() # 在这里调用模型推理 result model.infer_from_video(tmp.name) return {action_sequence: result}# 启动服务 uvicorn main:app --host 127.0.0.1 --port 8000正式项目里模型加载通常放在 lifespan 事件中避免每个请求重复加载权重同时要加超时控制视频推理时间可能比普通接口长很多默认的 30 秒超时大概率不够用。6.3 真机部署真机部署有几个额外环节先通过离线模式把视频生成策略保存下来再用仿真环境做一次策略回放验证只有在仿真验证通过后才加载到真机控制器上。真机部署时要特别注意安全和异常处理一旦模型输出越界需要立即触发急停。7. 功能测试与效果验证7.1 测试目标拿到一个机器人基础模型之后最先要验证的并不是它能做多复杂的任务而是四件事任务理解准确度、动作序列合理性、跨视频泛化能力、长时程稳定性。7.2 测试用例设计建议按下面的维度设计测试集。测试维度测试场景判断标准单一动作识别抓取、推、拉、旋转、放置动作意图识别准确错误率低对象属性依赖不同大小、材质、形状的物体面对新物体时动作策略仍然合理多步任务拆解倒水、叠衣服、搬运分拣任务被正确拆解为有序子任务干扰鲁棒性视频背景变化、光照变化、视角变化任务执行不受无关变化干扰运动学适配同一段视频送给不同机器人本体动作能正确适配本体的运动学约束7.3 验证流程第一步准备 5 到 10 段演示视频覆盖不同的任务类型。每段视频控制在 10 秒到 1 分钟之间画面稳定操作过程清晰。第二步将视频输入模型检查模型输出的任务描述。这个描述应该包含任务目标、关键物体和动作顺序。如果这一步就不准确后面基本不用测了。第三步在仿真环境里回放动作策略观察机器人是否完成了任务。同时记录成功率、任务完成时间、是否有碰撞或越界行为。第四步将同一段演示视频做轻微的干扰处理比如改亮度、旋转角度、加少量遮挡再送入模型。检查输出是否稳定。这一步能快速判断模型的泛化能力。第五步用不同的参考视频测试同一类任务的输出一致性。如果两段视频表达的是同一个任务但模型输出的策略差异很大说明模型可能记住了视频表面特征而不是理解了任务本质。因为现在缺少 Skild S1 的真实运行数据上面的验证流程给出了通用的做法。更稳妥的方式是先看官方发布的技术报告和演示视频了解他们推荐的任务类型和数据格式再按官方配置跑一套 min 测试。8. 接口 API 与批量任务机器人基础模型的 API 化和批量任务设计是实际工程落地时最关心的部分之一。下面给出通用设计思路需按实际项目接口调整。8.1 API 调用示例如果服务端已经启动客户端可以通过 HTTP 上传视频并获取结果。参考下面的 Python 请求示例import requests # 替换为实际服务地址 url http://127.0.0.1:8000/infer with open(demo_videos/pick_up_cup.mp4, rb) as f: response requests.post( url, files{video: (pick_up_cup.mp4, f, video/mp4)}, timeout300, ) result response.json() print(result[action_sequence])8.2 批量任务设计批量处理的核心是目录 队列 日志三个组件。先把所有待处理视频放在输入目录然后按顺序提交任务每个任务记录状态和错误信息失败时自动重试。import os import json from pathlib import Path input_dir Path(./input_videos) output_dir Path(./output_policies) output_dir.mkdir(exist_okTrue) failed_tasks [] for video_path in sorted(input_dir.glob(*.mp4)): task_name video_path.stem output_path output_dir / f{task_name}.json # 跳过已处理的任务支持断点续跑 if output_path.exists(): continue try: # 调用推理接口 result run_inference(str(video_path)) with open(output_path, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2) except Exception as e: failed_tasks.append({video: str(video_path), error: str(e)}) # 输出失败任务清单便于排查 with open(output_dir / failed_tasks.json, w, encodingutf-8) as f: json.dump(failed_tasks, f, ensure_asciiFalse, indent2)批量任务有几个工程经验值得提前注意。第一输入视频的命名规范一定要固定。用任务类型_序号_参数.mp4的格式命名方便后续做任务筛选和结果对比。第二推理结果建议保存为 JSON 和视频预览两个文件。JSON 存动作序列和任务理解视频预览用于快速查看机器人执行效果省去每次都打开仿真器。第三增加超时重试机制。模型推理偶尔会因为显存问题或临时性异常失败做好重试能把批量任务成功率从 90% 拉到 99% 以上。9. 资源占用与性能观察虽然无法给出 Skild S1 的具体显存数字但性能观察的方法是通用的。9.1 显存占用观测如果是 NVIDIA GPU直接用 nvidia-smi 看实时占用。# 每秒刷新一次显存使用率 nvidia-smi --query-gpumemory.used,memory.total,utilization.gpu --formatcsv -l 1推理时重点观察这几个指标模型加载到显存后的静态占用视频推理过程中的峰值显存以及批处理时显存是否线性增长。峰值显存最危险一旦超限程序会直接 OOM 崩溃。9.2 性能影响因素影响推理时间和显存占用最大的三个因素通常是视频分辨率、视频帧数、批处理大小。分辨率越高、帧数越多视觉编码耗得越久batch size 越大显存占用越高但单个视频的平均推理时间会下降。如果显存不足优先做三件事降低视频分辨率、抽帧间隔调大、batch size 降到 1。这些操作会损失一些精度但可以先把流程跑通。9.3 CPU 与 GPU 推理差异机器人基础模型通常默认 GPU 推理。如果项目支持 CPU 推理速度会很慢只适合做功能验证。原因很简单视频编码涉及大量矩阵运算CPU 在并行能力上和 GPU 差距明显。正式测试和批量处理建议至少准备一块 12GB 显存以上的 NVIDIA GPU。具体够不够用要按实际模型加载后的峰值显存来定。9.4 端口与服务资源如果启动了 HTTP 服务注意端口被占用的典型错误。Linux 下可以用下面的命令检查# 查看端口占用情况 lsof -i :8000 # 或者 netstat -anp | grep 8000服务退出后如果进程没有正常结束显存不会自动释放要杀掉残留进程再重新启动。10. 常见问题与排查方法结合机器人基础模型和本地服务类项目的通用情况整理一份排查清单。问题现象可能原因排查方式解决方案视频无法加载编解码格式不兼容检查视频扩展名和编码格式用 ffmpeg 统一转码为 mp4 / H.264模型加载报错权重文件缺失或损坏检查权重文件路径和 MD5重新下载或核对模型版本CUDA out of memory显存不足运行 nvidia-smi 查看显存占用降低分辨率、缩小 batch size、减少抽帧数启动后页面或接口打不开端口被占用或服务未启动查看服务日志和端口状态换端口或杀掉残留进程真机执行时动作异常视频中动作与机器人运动学不匹配在仿真环境回放策略调整动作映射或加入运动学约束批量任务部分失败视频损坏或网络超时查看失败任务日志添加重试机制跳过损坏视频任务理解不准确视频包含过多无关信息检查输入视频质量裁剪视频突出核心操作区域输出动作不稳定视频帧率抖动检查原始视频帧率统一抽帧保证时间戳对齐11. 最佳实践与使用建议11.1 数据层面视频数据质量决定模型能力上限。采集演示视频时要控制变量背景尽量简洁光线稳定操作者手部不要遮挡目标物体避免视频中出现无关人员。同一个任务建议录 5 个以上变体比如不同位置、不同物体、不同视角这样能降低模型对示范视频表面特征的过拟合。11.2 工程层面第一次跑通流程时用小任务小参数起步。不要一上来就尝试高分辨率、长视频、大批量推理。建议准备三套目录结构分别存放视频素材、视频特征、输出策略保持数据链路清晰。11.3 验证层面先仿真后真机。任何新策略都要先在仿真环境里回放确认动作序列安全后再加载到真机。真机测试时要设置力矩限制和急停开关首次测试建议速度降到正常速度的 30%。11.4 合规层面涉及人体动作数据、人脸视频、私人场所录像时必须获得授权。涉及版权内容素材时不能未经授权用于训练。最终要对外发布或商业化的模型一定要做完整的数据来源审计。12. 总结与下一步Skild S1 和视频即提示词这个组合最值得关注的地方在于它把机器人任务定义的门槛从写代码降到了拍视频。对于做机器人研究和工程的人来说这意味着可以更快地迭代新任务也可以用一个统一模型处理多种操作的描述。这个方向目前还处于快速演进期最值得先验证的是三件事一段演示视频能否被准确理解为任务、仿真环境能否稳定复现动作、以及同一个模型能不能适配不同机器人本体。最容易踩的坑是视频数据质量和动作-视频对齐问题很多模型效果不好的原因并不在模型本身而是输入视频拍得太随意。下一步可以关注几个方向官方是否开放模型权重或在线 Demo是否提供仿真环境的标准评测集合是否支持自定义视频-动作数据集的微调。建议收藏本文等你有实际测试环境后可以直接按里面的验证流程和排查清单来跑一轮。如果后续公开了更多技术细节可以再补一篇针对具体部署的实操文章。