第 12 章部署¶

Lab 到客户家的那段路是大部分具身公司死掉的地方。这一章不讲怎么训出 95%，讲那 95% 怎么进客户家变成 60%，又怎么爬回来。

考虑这样一个 2025 年春天 pilot 现场的典型走势。一家 A 轮的家庭机器人公司，做擦桌子和收拾餐具。在 lab 里跑了三个月每天验收，最后一周连续五天 task success rate 都是 94-96%。机器人装进白色泡沫箱送到 Mountain View 一个工程师的两居室做家庭试用。

第一天 71%。第二天 64%。第三天 58%。

Slack 上的 log 贴到凌晨三点。问题清单大概这些：

客厅的灯比 lab 暗 1.5 个档，餐桌反光改了，VLA 看餐巾纸的边缘看不清楚。家里那只 12 公斤的拉布拉多走过来嗅了一下机器人然后趴在脚边，机器人的足下障碍模块把狗当成静态物体绕过去，绕到一半狗动了，机器人卡住等了 40 秒然后报 timeout。Wi-Fi 是 mesh，从客厅走到厨房切了 AP，云端 planner 那一调 RPC 重试两次断开。第二天客户家保姆来打扫，把一把椅子从原位置搬到了餐桌另一边，机器人 VSLAM 的地图没更新，规划路径直接撞椅腿。

lab 到家的 gap 不是模型问题。是分布外问题、网络问题、人和宠物乱入问题、光照问题、家具被搬动问题加在一起的问题。每一项单看都是已知的，加在一起是新的。把那台机器人在那一户家里爬回 90% 通常要四个月。然后下一户又掉到 60%。

听起来夸张但不是孤例。同一时间段做工厂场景的几家公司里，第一周从 lab 数字掉 25-40 个百分点是常态，掉得最少的也要掉 15 个。掉的来源大致五五开：一半是真的环境分布外，VLA 没见过那种地砖反光、那种工件颜色、那种工人工服图案；另一半是工程问题，网络抖、电源不稳、温度比 lab 高 8 度让相机自动曝光走样。前者修一次值一次，后者每个新场地都要重修一次。

这一章讲的就是这件事。

lab 到 pilot 到 paid customer 是三段不同的路¶

很多创始人的脑子里这是一条线性曲线：lab 数据多了 → pilot 部一点 → 客户付钱。错的。这是三段斜率完全不同的曲线。

flowchart LR
  L["Lab<br/>0% → 90%<br/>3-12 个月<br/>斜率最陡"] -->|进客户场地| P["Pilot<br/>90% → 95%<br/>6-12 个月/家<br/>斜率突然变平"]
  P -->|签合同收钱| C["Paid customer<br/>95% → 99%+<br/>1-3 年<br/>追低方差和 SLA"]
  C --> S[规模化]
  P -.->|烧完没爬上来| DEAD((大多数公司<br/>死在这一步))

lab 阶段斜率最陡。从零到 90% 的 task success，端到端 + teleop 数据 + sim 兜底，一年内做到不算稀奇。2024 年这一年 OpenVLA、π0、GR00T 把这一段的门槛打到了某些任务三个月一个 milestone。

pilot 阶段斜率突然变平。从 90% 到 95% 在 lab 之外要花 6-12 个月。原因是每进一个新场地，前两周都在补这个场地特有的分布。Agility 的 Digit 在 GXO 仓库（2024 年初开始正式商用 RaaS（Robot-as-a-Service：客户按小时/按月付费用机器人，不买断）部署）跑到第三个客户场地的时候，他们公开过一个数字：每个新场地的前 200 小时是 deploy team 现场坐着调，第二个 200 小时变成远程协助为主，800 小时之后才接近 lab 数字。

paid customer 阶段斜率第三次变。客户付钱之后你要的不是更高的 success rate，是更低的方差和更可预测的 SLA（Service Level Agreement：服务质量合同，比如"每小时至少完成 X 个任务，否则扣费"）。一个每天能干 95% 但偶尔会漏 1% 把碗摔了的机器人，比一个每天稳定 88% 从不出意外的机器人难卖。客户买的是确定性，不是均值。这件事 Locus Robotics 在他们的 RaaS 合同里明白得很早，他们卖给 DHL 这种客户的 SLA 是按"每小时拣货数下限"写的，不是按平均拣货数。

99% 那条墙¶

从 0 到 90% 是一条曲线。从 90% 到 99% 是一面墙。

经验数字大概这样：0 到 90% 的工程成本，跟 90% 到 99% 的工程成本，比例是 1 比 5 到 1 比 10。这条规则在自动驾驶被反复证实，Cruise、Argo、Waymo 都在 99% 的最后两个 9 上烧掉了几十亿美元。具身机器人现在正在踩同一条坑。

为什么？因为前 90% 大部分覆盖的是分布内的行为，靠数据堆能解决。后 9% 大部分是 long tail：某个角度的反光、某种没见过的容器、某个客户家特有的家具布局、某种宠物毛色让 vision encoder 把它认成抹布。每一种 case 单独 hit rate 千分之一，加起来覆盖了你从 90 到 99 的所有缺口。long tail 不会被一个新数据集解决，它要被一个流程解决：现场采集 → 标注 → 进训练集 → 重新部署 → 看 telemetry → 再迭代。

这也是大部分 A/B 轮具身公司死的地方。他们 demo 跑出 90% 拿到下一轮，然后用 18 个月去追那 9%，钱烧完了产品还差一截。写在墙上：90% 不是产品。95% 不是产品。99% 才进入产品的入场券。家庭场景比工厂场景还要再加半个 9，因为家里没有 maintenance window，没有 IT 部门，客户的容忍度跟你 lab 里的工程师不在一个量级。lab 工程师看见机器人卡住会兴奋地打开 log；客户看见机器人卡住第三次就退货。

具体怎么爬这条墙？没有捷径，但有套路。先把 long tail 分桶：哪些是感知问题、哪些是 planner 问题、哪些是控制问题、哪些是硬件问题。每一桶用不一样的方法处理。感知 long tail 进训练集，planner long tail 写规则兜底，控制 long tail 调阻抗参数，硬件 long tail 改 BOM 或加冗余传感器。混在一起处理永远爬不上去。

Pilot 案例的真东西¶

挑五个有公开信息的 pilot 案例看一眼。每个例子下面只挑一两件别人在 marketing 里不会主动讲的事。

Agility Robotics Digit at GXO / Amazon（2024 起）。Digit 在 GXO 的 Spanx 仓库做 tote 搬运，是当下最接近真正商用的人形 pilot。RaaS 模式，按小时计费，公开说大概 30 美金/小时这一档。GXO 自己的 supply chain VP 在 2024 年的财报会上说了一句业内人都听得懂的话：成本目前还没有比人便宜，但他们是为了下一代打基础。Digit 在仓库里靠的是预先 mapping 过的环境 + 固定的 tote 类型 + 受控的灯光。别拿"人形已经在仓库工作"当通用具身已成的证据。它在一个高度受控的子集上工作。

Figure 02 at BMW（2024 起）。Figure 把 02 部到 BMW Spartanburg 工厂做 sheet metal 装配。Figure 公开过 video，看起来非常成熟。BMW 这边公开说的更克制：是 evaluation 阶段，不是产线。这个区别重要。"在产线旁边走"和"在产线上担责任"不是一件事。真正进产线意味着任何一次失败要走 BMW 的 quality 流程，赔的是车，不是 demo。

1X NEO Beta（2024 年底起在选定家庭试用）。1X 是这一波最早把人形送进真实家庭的公司。他们自己讲得很坦白：NEO 在家里大量任务通过远程 teleop 接管完成，他们把这件事写在产品页和访谈里。1X 的 CEO Bernt Børnich 在 2024 年的几次访谈里讲过 roadmap：先把 teleop 跑通，然后慢慢把更多任务从 teleop 转成 autonomy，把每户家庭采到的数据回训模型。这是非常聪明的部署策略：用真实家庭做数据采集源，同时用远程人保证服务质量。

Apptronik Apollo at Mercedes-Benz（2024 起，德国 Sindelfingen 厂）。Apollo 在 Mercedes 做 case 搬运。Apptronik 跟 Mercedes 都没有公开效率数字。这本身是一个信号。当 pilot 部署方都不愿意贴具体数字时，通常意味着数字还没到值得贴的位置。

Sanctuary AI Phoenix（加拿大，泛工业 pilot）。Sanctuary 是这一波里把"远程人介入"工程化做得最透的一家。他们的 control system 公开过分层：自主、远程协助、远程接管，三层切换。这套架构的好处是它不假装"全自动"，它直接把人留在系统里当一个有 SLA 的兜底层。这个立场看起来不性感，但它最接近 2026 年的真东西。

把这五家排在一起会看到一件事：当下没有一台真正全自动跑在客户家或工厂的人形机器人。所有"全自动"的演示，背后要么有 lab 工程师远程盯着，要么有 teleop 操作员，要么有现场的 safety operator。这不是丑事，是工程现实。把这件事讲明白比包装它，对客户、对投资人、对自己的工程团队都更健康。

部署时该看的指标，不是 demo 里那几个¶

Demo 给外部看 task success rate。pilot 部署给自己看的指标是另一套。

Intervention rate：每小时被人介入接管几次。这是当下机器人公司内部最重要的单一指标。1X 自己把它当 KPI。Sanctuary 把它写进客户合同。低于多少才算可接受？仓库 / 工厂里大概 0.5 次/小时是商用门槛，家庭里大概 0.1 次/小时才算"客户能忍"。

MTBF (Mean Time Between Failures)。这里 failure 不光是机器报错，包括任何需要人现场处理的事件。包括卡住、撞东西、关节过热、电池低于阈值、wifi 掉线没自动恢复。客户家里 MTBF 应该按天计，工厂按小时计。

Tasks per hour。光看 success rate 没用，要看完成数。一个 95% 但每个任务做 10 分钟的机器人，跟一个 88% 每个任务做 3 分钟的，后者商业价值大三倍。

Coverage：这台机器人在这个客户场地里能干客户期望任务的百分之几。你跟客户讲家里 50 件事，部署完只能干 12 件。客户买不买不取决于那 12 件做得多好，取决于剩下 38 件你有没有 roadmap。

Cost per task。把硬件折旧、电费、远程协助 operator 的工资、云端推理费、运维上门次数全加起来除以任务数。这个数字今天大部分家庭机器人是赔本干的。Locus 这种成熟的仓库 RaaS 厂商已经把 cost per pick 压到接近人工的水平，但他们花了十年。家庭机器人这边目前没有任何一家把 cost per task 公开过，原因不难猜：把分母里 operator 工资加进去之后，数字会很难看。

这五个数字一起看才是真东西。单看 task success rate 是 demo 思维。一个 dashboard 上同时有这五条曲线，每周复盘哪一条变好哪一条变差，公司里不同岗位看得懂同一张图，这才是 deploy 团队该有的样子。

OTA、telemetry、shadow mode、A/B：机器人 deploy 跟 web 不一样的几件事¶

机器人的 deploy pipeline 长得像 web，但有几件根本不一样的事必须想清楚。

OTA 不能随便 push。Web 应用 push 一个 bug 用户最多看到错页面。机器人 push 一个 bug 可能直接砸东西。所以正经的具身公司部署都是分阶段的：先在内部测试机做完整 regression，再 shadow mode（新模型在线推理但不出动作，只跟旧模型 logits 比较），再 1% 客户灰度，再全量。任何跳过 shadow 的部署在工程文化上是不可接受的。这件事 Tesla Autopilot 用十年血换出来的教训，具身机器人正在重学。

Telemetry 是产品。客户家里那台机器人每天产生 GB 级别的 sensor stream。哪些回传、哪些只在本地保留、回传的延迟和带宽预算、客户隐私边界，这些不是后置工程，是产品定义的一部分。不规划 telemetry 的部署等于盲飞。1X 公开过他们 NEO Beta 的隐私模式，客户可以一键关闭某些区域的视觉回传。这个功能不是隐私工程师加的，是销售加的，因为客户不让进卧室。

Shadow mode 是新模型上线前的法定通道。新 VLA 在客户家里推理但不发动作，跟旧 VLA 的 action 算 distance。distance 太大的样本回流到 lab 复盘。等 distance 分布稳定之后才切流量。这一套在自动驾驶是默认的，具身这边 2025 年才慢慢标准化。

A/B 部署在物理世界很怪。Web 的 A/B 是用户级别的随机分桶，机器人级别的 A/B 是机器人级别的。你不能让同一台机器人这一秒跑 A 下一秒跑 B，policy 切换的瞬态会出怪事。所以 A/B 一般是按机器人 ID 或按场地分桶。这意味着A/B 的统计 power 比 web 低两个数量级，因为你的 N 不再是 100 万用户，是 100 台机器人。这件事很多 ML 工程师从 web 转过来时低估了。

客户介入闭环：把人留在系统里，明明白白留¶

我前面说"当下所有全自动都是把人藏在了介入接口后面"。这件事有具体的工程形态。

远程 teleop 接管。1X 这一线公开承认家庭里大量任务由远程操作员实时驾驶机器人完成。客户家里看到的是"机器人在帮我洗碗"，背后是一个戴着 VR 头盔的操作员在挪威或菲律宾办公室里通过低延迟链路操作那台机器人。这条线对延迟极其敏感，120ms 以下勉强能用，200ms 以上没法做接触任务。

远程协助。比 teleop 弱一档，操作员不接手，只在机器人卡住时发指令："右边那个杯子是装满水的，先别动那个，先收拾左边的盘子"。这种交互每小时几次，一个操作员可以同时盯 5-10 台机器人。Sanctuary、Diligent Robotics 都用这一套。

本地手势接管。客户在家或工厂的工人按一下机器人身上的按钮、做一个手势、说一句"停"，机器人立刻交出控制权。这件事看起来简单，工程上很难做对：手势识别不能误触，"停"这一句不能在背景嘈杂时漏听，急停按钮的位置要让任何人在任何姿态下都按得到。Apptronik 的 Apollo 在 Mercedes 现场是有专门的 safety operator 的，operator 手里有一个无线急停。

把这三层叠在一起，你才有一个"在客户家能跑"的系统。没有这三层的演示视频可以漂亮，但不能商用。

这一套介入闭环还有个被低估的副产品：它是你最好的训练数据来源。每一次操作员介入意味着自主策略在那一刻不够好，介入轨迹本身就是一条带标签的演示数据。1X 的 strategy 公开过这一点，他们把家庭里 teleop 的轨迹回训进 NEO 的下一代模型。这种"先靠人保证服务，同时把人的操作变成数据"的飞轮，是这一波具身公司里最像 Tesla 早期 fleet learning 的部分。没有介入闭环的公司既没有服务保障，也拿不到真实分布的数据，等于双输。

SLA 和合同：行业还在摸索的那一段¶

机器人的 SLA 不像 SaaS。SaaS 的 SLA 是 uptime，99.9% 还是 99.99%。机器人的 SLA 是个多维向量。

要写哪几条？至少这些：

每小时 intervention 上限。每天最长 unattended 时间。MTBF 下限。故障 24 小时内有人到现场的承诺。每月 software update 频次和回滚保障。客户数据回传的隐私边界。机器人造成损害的赔付上限和保险归属。

这些条款 service robotics 行业到今天没有共识模板。Locus Robotics 这种成熟的 RaaS 厂商在仓库这个垂直里写得相对清楚，因为客户的工种和场景定义得很死。家庭机器人这边几乎没有。1X 的 NEO Beta 早期客户合同据说是个性化谈的，每户都不一样。

这件事会在未来 18-24 个月被几起官司或几次大召回拍出标准。早期入场的公司会按自己的合同模板影响整个行业。现在你写的合同条款，可能就是 2028 年的行业默认。

值得提的一点：保险这一块今天几乎是空白。家用机器人砸坏一台 5000 美金的电视该谁赔，砸到人该谁赔，碰到宠物该谁赔。Allianz、Munich Re 这些保险大厂 2025 年开始研究具身机器人产品险，但还没有标准产品。没有保险产品就没有标准化合同，没有标准化合同就没有规模化部署。这件事是行业的一个隐形路障。

买断 vs RaaS：定价模式不是商业问题，是工程问题¶

机器人怎么卖，业内现在有四种典型路线。

买断：客户一次性付硬件钱，软件订阅另算。Boston Dynamics 的 Spot 用这个模式，单台大概 7-10 万美金，加 enterprise 软件订阅。

纯 RaaS：按小时或按完成任务量付。Locus Robotics 的仓库机器人是按拣货数计费，Diligent Robotics 的 Moxi 在医院按月付。Agility Robotics 的 Digit 也是 RaaS，2024 年公开过约 30 美金/小时这个数字。

混合：硬件买断 + 任务量分成。少数 vertical SaaS 模型在用。

赠送 + 数据：1X 的 NEO Beta 2024 年的早期客户基本是低价或免费，作为交换客户家里的数据被回训。这种模式很有 Tesla 早期的味道。

定价模式表面看是商业策略，底下是工程决策。RaaS 意味着你必须做：远程监控基础设施、24/7 operator 队伍、按小时计费的精准 metering、SLA 监控告警、远程 OTA、远程协助接入。买断模式意味着你必须做：本地完整自治、客户自己运维、本地诊断 UI、客户 IT 集成。你没决定卖法之前，工程栈不知道往哪个方向砸钱。这件事很多创始人到 B 轮才想明白，已经晚了一年。

立场：垂直窄，比通用大一万倍重要¶

最后留一个立场。

这两年所有具身公司的 deck 上都印着一句"我们做通用平台"。理解这句话为什么会被印上去：投资人喜欢通用平台，因为 TAM 大。问题是通用平台需要解决无穷多种 long tail，而 long tail 的钱是花不完的。

垂直场景意味着：固定的客户类型、固定的任务子集、固定的环境复杂度、固定的 SLA 模板、固定的合同模板、固定的 deploy 流程。每一个"固定"都在给你的工程团队减少一个数量级的复杂度。Locus 只做仓库拣货。Diligent 只做医院里送药送检。Boston Dynamics Spot 在 inspection 这一垂直被磨了七年才赚钱。垂直窄，比通用大一万倍重要。

通用平台不是不能做。但它是 D 轮以后的事，不是 A 轮的事。A 轮就喊通用平台的公司，绝大多数会在 B 到 C 之间死掉。Boston Dynamics 做了三十年才在 inspection 这一窄垂直里盈利，Locus 做了十年才在仓库拣货里盈利。具身大模型把上限抬高了，没把垂直窄这一规律抬掉。这一代机器人公司的赢家，最先到第一千万美金 ARR 的，几乎肯定是从一个非常窄的场景里出来的。

练习¶

找一段最近的人形机器人 demo video（Figure、1X、Apptronik、Sanctuary、Agility 任选）。按这一章里的指标重新看：你能从画面里推测它的 intervention rate 吗？画面剪辑里有没有提示远程协助存在的痕迹（语音延迟、镜头切回、外部控制台）？看完之后再读这家公司同一时期的官方 blog 或访谈，对比你的推测。

挑一家做 service robot 已经盈利或接近盈利的公司（Locus Robotics、Symbotic、Diligent Robotics、Boston Dynamics 的 Spot 业务），找它的 RaaS 合同模板或 case study。把它的 SLA 条款抄下来，逐条问：这一条具身大模型时代的人形公司能不能复制？为什么不能？

画一张你自己产品的"99% 路线图"。假设你现在 task success 是 90%。从 90% 到 99% 这九个百分点，你打算怎么爬？每一个百分点的增量，是靠数据、靠分层、靠远程介入、还是靠缩小 scope？写完之后给自己估一个总成本和总时间。如果这个数字让你不舒服，说明你的 roadmap 还不诚实。

找一个你认识的具身机器人创始人，问一个问题：你的第一个付费客户在哪个城市，第一年合同金额多少，去年这个客户续约了吗。如果三个问题里有任何一个答不上来，这家公司还没真正开始 deploy，无论 demo 多漂亮。

下一章：第 13 章团队与资本

第 12 章 部署¶