# 不报成功率，改报「多久要人插一次手」：DYNA 2.1 把 MTBI 摆上台面，但还是没给那个数

> 一台不做双腿、只做上半身加四个转向轮的机器人，宣称能独立跑完整个商业洗衣班次。它新提出的指标 MTBI 比成功率更接近生意，但公告里缺的恰恰是那个数值。

### TLDR

- **发布**：DYNA Robotics 于 **2026 年 9 月 29 日**（美国加州红木城）发布 **DYNA 2.1 physical agent**，定位半人形（semi-humanoid）机器人，已在**酒店、自助洗衣店、餐厅**部署。
- **硬件取舍**：上半身配两条手臂，末端可选平行夹爪或灵巧手；底盘是**四个转向轮**，官方口径是可以自由移动而**无倾倒风险**——不做双足。
- **系统构成**：视觉语言编排器负责工作流推理，全身控制器把行驶、伸手、弯腰、举起统一成一个连贯动作；底座是自研世界动作模型 **DYNA 2**，训练数据为**一百万小时**人类与机器人数据。
- **洗衣全流程**：装洗衣机与烘干机并启动、弯腰探入烘干机深处取出大批量毛巾、抖平折叠并按尺寸码垛、下蹲放底层或上举放顶层，并**自主纠正物理失误**（捡起掉落的毛巾、放弃失败抓取后重试）而不求助人类。
- **新指标**：官方称 DYNA 2.1 针对 **MTBI（Mean Time Between Interventions，平均介入间隔时长）**优化，即机器在需要人类介入前能连续运行多久。
- **仍缺的数**：公告通篇未给出 MTBI 的**当前数值**，也未披露部署台数、单台价格与连续运行班次时长。

### SRC

本篇素材来自 DYNA Robotics 通过 PR Newswire 发布的官方新闻稿，落款 **REDWOOD CITY, Calif., Sept. 29, 2026**，经 Morningstar 转载可检索；美东 9 月 29 日发布、北京时间 9 月 29 日夜间至 9 月 30 日早晨落地，落在素材时间窗「2026-09-29 18:00 → 2026-09-30 09:00」内。硬件形态、四个转向轮、一百万小时训练数据、洗衣全流程动作清单、MTBI 定义、Lindon Gao 与 Jason Ma 的引语、创始团队背景（Lindon Gao、York Yang 曾以 3.5 亿美元出售 Caper AI；Jason Ma 为前 DeepMind 研究科学家）、投资方 CRV 与 First Round 等均出自该新闻稿。运行数据回流机制（从推理器决策轨迹到控制器关节负载）亦为官方口径。**「一百万小时约合 170 年连续清醒时间」为二手转述补充，非新闻稿内容，已标注。**「一个班次 8 小时 = 480 分钟」「MTBI 与人力排班的换算」为作者推演，非厂商披露。与既有稿件的差异：本站 262 号稿《「跨过 ROI 门槛」这句话该怎么验》问的是 Dyna 与鼎泰丰那套机器人订阅**还没公开的五个数**（部署台数、单台月费、人工替代工时、连续运行时长、故障恢复时长），本篇是 DYNA 2.1 的产品发布与它新提出的 MTBI 指标，不重复 RaaS 订阅定价讨论，并在正文中明确回应 262 号稿留下的那个问题被回答了多少。事实与判断分开，判断以「判断：」开头。

### BODY

<div class="sec">
<div class="eyebrow">先看它放弃了什么</div>
<p>DYNA 2.1 的硬件形态很克制：上半身加两条手臂，末端可选平行夹爪或灵巧手；下面是四个转向轮。官方给的理由很直接——这样它可以自由移动而不会有倾倒风险。</p>
<p>也就是说，它放弃了双足。这个取舍在「要连续跑完一个班次」这个目标下是完全合理的：双足带来的高度与越障能力，在这场商业洗衣的场景里用不上；而摔倒一次的代价，是整班中断加人工复位。</p>
<div class="keypoint">判断：形态选择应该由「停机代价」决定，而不是由「像不像人」决定。做本体选型时，一个常被忽略的算法是：把「摔倒/卡死一次需要多久恢复」乘上「预期发生频率」，再和双足带来的能力增量做比较。在需要连续运行的商业场景里，这个账几乎总是偏向轮式。这与本站此前记录过的飒智「不做双足、只做六臂」是同一类判断。</div>
</div>

<div class="sec">
<div class="eyebrow">MTBI 这个指标，比成功率更接近生意</div>
<p>联合创始人 Jason Ma 的引语把话挑明了：目前广泛使用的「单集任务成功率」不能反映真实的商业可行性，因为连续的真实班次需要**数千个连续步骤**。所以他们改用 MTBI——机器需要人类插手之前能运行多久。</p>
<p>这个替换的意义在于量纲。成功率是「每次尝试对不对」，MTBI 是「多久才要人一次」；后者直接对应人力排班，前者不对应任何经营指标。</p>

<div class="jx-split">
<div style="flex:50">
<div class="eyebrow">成功率</div>
<p>回答「做对了吗」。<br>量纲是比例，无法直接换算成排班与成本。<br>且随任务定义变化——切得越碎，数字越高。</p>
</div>
<div style="flex:50">
<div class="eyebrow">MTBI</div>
<p>回答「多久要人一次」。<br>量纲是时间，可直接换算成「一人能看几台」。<br>不随任务切分方式变化。</p>
</div>
</div>
</div>

<div class="sec">
<div class="eyebrow">把这个指标翻译成排班表</div>
<p>MTBI 一旦有了数值，就能直接推人力配置。作者按一个班次 8 小时（480 分钟）做一次推演，仅用于说明换算方法，非厂商数据：</p>

<div class="tbl-wrap">
<table>
<tr><th>MTBI（假设值）</th><th>单台每班次介入次数</th><th>若一人可并行响应 4 台</th></tr>
<tr><td>15 分钟</td><td>约 32 次</td><td>约 1 人盯 1 台，人力账不成立</td></tr>
<tr><td>60 分钟</td><td>约 8 次</td><td>约 1 人可兼顾 2—3 台</td></tr>
<tr><td>240 分钟</td><td>约 2 次</td><td>约 1 人可兼顾 6—8 台</td></tr>
</table>
</div>
<div class="cap">表注：三档 MTBI 为作者假设值，用于演示换算逻辑；介入次数 = 480 ÷ MTBI，属简化算术，未考虑介入处理时长与并发冲突。DYNA 未披露其 MTBI 实际数值。</div>

<div class="keypoint">判断：这张表说明 MTBI 为什么是个好指标——它把「机器人自主性」这个抽象概念直接压成了一个排班数字。任何做机器人运营的团队都该自己建这一列：有了它，才算得清「一台机器配几个人」，否则 ROI 永远停留在口号。也正因如此，MTBI 的具体数值才是这份公告最该给而没给的东西。</div>
</div>

<div class="sec">
<div class="eyebrow">262 号稿问的五个问题，这次回答了几个</div>
<p>本站此前针对 Dyna 与鼎泰丰的机器人订阅写过一篇，列出「跨过 ROI 门槛」这句话还缺的五个数：部署台数、单台月费、人工替代工时、连续运行时长、故障恢复时长。</p>
<p>这次的 DYNA 2.1 公告，可以对照着看：</p>

<div class="jx-tl">
<div class="jx-tl-row"><div class="jx-tl-t">部署台数</div><div class="jx-tl-b">仍未披露——只说已在酒店、自助洗衣店、餐厅部署，未给数量</div></div>
<div class="jx-tl-row"><div class="jx-tl-t">单台月费</div><div class="jx-tl-b">未披露——本次为产品发布，非订阅定价公告</div></div>
<div class="jx-tl-row"><div class="jx-tl-t">人工替代工时</div><div class="jx-tl-b">间接靠近——用 MTBI 替代，但 MTBI 数值未给</div></div>
<div class="jx-tl-row"><div class="jx-tl-t">连续运行时长</div><div class="jx-tl-b">部分回答——宣称能完成整个班次，未给具体时长与班次长度</div></div>
<div class="jx-tl-row"><div class="jx-tl-t">故障恢复时长</div><div class="jx-tl-b">未披露——只说能自主纠正部分物理失误，未给恢复耗时</div></div>
</div>

<div class="keypoint">判断：五项里，「人工替代工时」这一项被换成了 MTBI 这个更可核对的口径，这是进步；但换完之后仍然没给数值，等于把问题的形式改好了、答案还欠着。这个模式在厂商发布里很常见——先把指标定义立住，把数值留到后续。观察窗口是下一次客户案例披露，看它是否带出 MTBI 的实测值。</div>
</div>

<div class="sec">
<div class="eyebrow">洗衣这个场景为什么值得做</div>
<p>官方列出的动作清单很具体：装洗衣机和烘干机并启动、弯腰探入烘干机深处把大批量毛巾取进篮子、把毛巾抖平、折叠、按尺寸码成垛、下蹲把成品放到最底层隔板或上举放到顶层，以及自主纠正物理失误——捡起掉在地上的毛巾、放弃一次失败的抓取后重试，全程不请求人类帮助。</p>
<p>这份清单的价值在于它的**长度与异质性**横跨了：开关设备（力控）、深腔取物（可达性）、柔性物体操作（布料）、按尺寸分类（感知与决策）、高低位放置（全身协调）、失误自恢复（容错）。六类难度叠在一次任务里，比单一指标的演示更能说明工程完整度。</p>
<div class="keypoint">判断：选场景的能力，本质上就是选「难度组合」的能力。好的落地场景不是最赚钱的那个，是**把最多类难题压缩进一个可重复流程**的那个——因为每一类难题被解决后都能迁移到别的场景。洗衣、冲饮、分拣这类「流程长但环境可控」的岗位，比开放环境的服务岗位更适合当第一站。</div>
</div>

<div class="sec">
<div class="eyebrow">数据闭环的那一句，才是长期壁垒</div>
<p>公告里有一段容易被跳过：机器人运行时会采集执行数据——从推理器的决策轨迹到控制器的关节负载——这些数据回流进系统，形成一个持续改进闭环，目标是稳步提高「每次介入之间完成的工作分钟数」。</p>
<p>翻译成白话：它把 MTBI 同时设为**优化目标**和**反馈信号**。介入事件本身就成为最有价值的训练样本，因为那正是策略失效的时刻。</p>
<div class="keypoint">判断：这套设计最值得抄的不是模型，是把「失败时的现场状态」自动留存这件事。多数团队的部署日志只记成功轨迹，而失败恰恰发生在没人看的时候。真正该建的工程能力是：每一次人工介入，自动打包介入前若干秒的多模态上下文。有了它，MTBI 才有提升的燃料；没有它，MTBI 只是个监测数字。</div>
</div>

<div class="srcline">来源：PR Newswire / DYNA Robotics 官方新闻稿，REDWOOD CITY, Calif., Sept. 29, 2026（Morningstar 转载）；素材时间窗 2026-09-29 18:00 → 2026-09-30 09:00。</div>

---

*来源：神机百见-具身解读 · https://www.shenjibailian.com/jiedu/article/dyna-21-mtbi-full-shift-metric/*