具身智能：具身部署模式与安全案例

具身智能一旦离开实验室，面对的就不再是“平均成功率”，而是具体责任边界、真实物理风险和持续运营问题。部署模式决定系统怎样接入业务流程，安全案例则回答一个更根本的问题：为什么我们相信它足够安全、何时必须回退、出了问题如何追责与修复。本页把具身智能系统从研究样机推向生产环境时常见的部署模式与安全论证框架做一个系统梳理。

1. 为什么具身智能部署比纯软件系统难

对话系统的错误常常是答非所问，而机器人的错误会表现为撞击、夹伤、摔落、卡死、误抓、阻塞通道或破坏物品。风险直接作用于物理世界，因此部署必须同时考虑人员安全、财产损失、任务可靠性、系统可恢复性，以及合规与责任界面。

此外，具身系统是“长链路系统”：感知、识别、规划、控制、执行器、通信、电源、机械结构缺一不可，任何一环的偏差都会被物理过程放大。

SayCan 的语言分数与 affordance 分数结合图很适合放在部署页开头：它提醒我们，真实机器人部署不能只问“语言上该做什么”，还要问“当前物理环境里能不能安全地做”。这正是安全案例和运行边界的起点。

图源：Do As I Can, Not As I Say: Grounding Language in Robotic Affordances，Figure 3。原论文图意：LLM 给候选技能打“是否符合指令”的分数，value functions 给技能打“当前环境是否可执行”的 affordance 分数，二者组合后选择下一步机器人动作。

图解：部署安全先分清 useful 和 possible

SayCan 图里的 LLM 分数回答“这个动作是否符合用户意图”，affordance 分数回答“当前环境是否允许成功执行”。部署安全也必须同时看这两件事：一个动作语言上正确，不代表物理上安全；一个动作物理上可行，也不代表符合任务和责任边界。安全案例需要继续说明 ODD、危险源、保护层、验证日志和事故复盘，而不是只给一个模型准确率。

初学者先抓住

安全案例不是一份合规装饰，而是系统为什么可以被允许运行的证据链。它要说明运行边界、危险源、保护层、验证结果和事故后的追责修复路径。

有趣例子：游乐设施开放前检查

过山车不是试跑一次没出事就能开放。要规定身高限制、检修周期、急停方案、故障记录和工作人员职责。具身智能部署也需要类似的安全案例。

2. 常见部署模式

2.1 助手模式

机器人只提供建议或执行低风险动作，人类保留最终决策权。比如仓库盘点机器人给出“疑似放错货位”的建议，由人类确认；家务机器人先规划清理顺序，由用户点击确认开始。

这种模式优点是上线快、风险低，缺点是自动化收益有限。

2.2 受限自动化模式

系统只在明确边界内独立工作，例如夜间无人时段清扫固定区域、抓取预定义货箱类型、在围栏内执行搬运，或在低速物流通道中运行。

这种模式是当前工业部署最常见的形态。关键不是追求“全能”，而是把可控边界定义清楚。

2.3 人机协作模式

机器人与人同时工作，需要共享空间、共享节拍甚至共享工具。例如装配线协作、护士站递物、餐厅传菜。这要求系统额外具备人体检测与跟踪、安全停机与速度限制、意图识别或至少路径礼让，以及更强的交互解释能力。

2.4 高自治闭环模式

系统独立完成大部分任务，人类只做监控和异常接管。例如封闭仓储中的自动搬运与拣选。此模式要求最严格的安全案例和运行监控，因为它对人工兜底依赖最低。

3. 安全案例是什么

安全案例（safety case）可以理解为一套结构化论证：系统为什么在给定场景下足够安全。它通常不是一句“模型准确率 95%”，而是由顶层主张、论据和证据组成的论证树：顶层主张说明系统在场景 S 中可接受地安全；论据说明有哪些设计、测试、约束和流程支持这个主张；证据则来自实验、日志、仿真、形式化规则、现场演练和事故复盘。

可把总风险写成一个粗略表达：

$\text{Risk} = \sum_i P(\text{hazard}_i)\cdot \text{Severity}(\text{hazard}_i).$

部署的目标不是把风险变成零，而是把高严重度风险的概率压到可接受范围，并确保出现异常时系统能进入安全状态。

4. 典型危险源

具身系统的危险源往往来自多因素耦合，而不是单一模型错误。

感知危险包括漏检人、宠物或障碍物，误识别目标对象，受反光、阴影、遮挡影响，以及坐标系漂移或标定失效。规划危险包括选择不可达目标姿态、动作路径穿越禁区、忽视动态障碍、错误估计抓取或放置可行性。控制与执行危险包括关节超速、力控异常、末端执行器卡住、紧急制动不及时。系统性危险则来自网络中断、上下游接口变化、电池低电量退化和远程更新回归。

5. 安全设计的基本原则

5.1 分层防护

不要把安全完全寄托在“大模型会判断”。通常需要任务层约束、规划层约束和硬件层约束同时存在：任务层说明哪些任务允许做、哪些场景禁止做；规划层负责禁区、速度限制、碰撞检查和力阈值；硬件层提供急停、围栏、限位、扭矩保护和冗余传感器。

任意一层失效时，其他层仍可兜底。

5.2 可降级运行

一套好的部署系统不应只有“正常工作”和“彻底瘫痪”两种状态，而应具有降级模式。例如视觉置信度低时减速运行，语言解析歧义高时请求人工确认，网络断开时切换本地安全策略，不确定性过高时回到待命位姿重新观察。

5.3 明确 ODD

ODD（Operational Design Domain）即操作设计域，描述系统在哪些条件下允许运行，例如室内平整地面、光照范围 200 到 800 lux、只处理重量小于 2kg 的物品、与人共享空间时速度上限 0.5m/s。

很多事故不是模型“突然变差”，而是系统被拿去超出 ODD 的场景使用。

6. 安全案例的组成

6.1 场景界定

首先要把场景边界写清楚：地点、对象、人类参与方式、速度范围、失败后果、应急流程。

6.2 危险分析

列出所有关键 hazards，并按照严重度和发生概率排序。可以借鉴 FMEA 风格：

$\text{RPN} = \text{Severity} \times \text{Occurrence} \times \text{Detectability}.$

RPN 高的风险项需要优先设计防护与测试。

6.3 缓解措施

每个危险项应有明确缓解措施，例如漏检行人对应冗余深度传感器和安全减速区，抓取失败滑落对应夹持力监控和失败姿态回退，错误目标识别对应双重确认和条码辅助。

6.4 验证证据

证据可以来自离线数据回放、仿真压力测试、实机封闭场演练、小流量灰度运行和历史日志统计。

7. 机器人部署中的监控指标

仅靠“任务成功率”无法支持现场运维。更应记录每小时急停次数、碰撞接近事件数、人工接管率、平均恢复时间、低置信度动作比例和安全区侵入事件。

这些指标构成持续安全运营的基础。

8. 失败恢复为何是部署关键

实验室里，失败后通常由研究员手动重置环境；真实部署里，这个成本非常高。一个系统若没有恢复能力，会在现场表现成“只要第一次没做好，就把整个工位堵死”。因此安全不仅是“不伤人”，还包括“出错时能否优雅退出”。

可把恢复策略视作一个条件策略：

$\pi_{\text{recover}}(a_t \mid s_t, e_t),$

其中 $e_t$ 表示错误类型，如抓取失败、遮挡、路径被占用。恢复策略越明确，系统越适合部署。

9. 三个具体部署案例

9.1 仓库拣选机器人

场景：围栏内无人区，处理固定尺寸纸箱和塑封件。

安全重点是误抓后掉落砸坏货品、机械臂与输送线碰撞、异常件卡住末端执行器。

适合模式：受限自动化。可以通过围栏、固定工位、对象白名单和条码二次确认，把 ODD 压缩到足够清晰。

9.2 医院配送机器人

场景：与医护、病患共用走廊，需避让人群并到站点交接。

安全重点是与人近距离通行安全、电梯和自动门接口失效、紧急情况下的人类接管。

适合模式：人机协作。要把速度限制、礼让规则、远程监控和语音提示都纳入安全案例。

9.3 家庭收纳机器人

场景：开放式家庭环境，对象杂乱、光照复杂、儿童和宠物随机出现。

安全重点是抓取玻璃器皿摔碎、儿童突然进入工作区域、误把私人物品当垃圾处理。

适合模式：助手模式或高度受限自动化。当前阶段如果没有明确 ODD 和强人工确认，不适合完全自治。

10. 安全与产品收益的关系

工程团队常担心安全约束会“压掉模型能力”。实际更常见的情况是：没有安全框架，系统根本无法进场测试，自然也谈不上收益。合理的安全设计不是阻碍，而是让系统在有限边界内稳定创造价值。

可以把部署收益近似写成

$\text{Net Value} = \text{Automation Gain} - \text{Incident Cost} - \text{Oversight Cost}.$

过于激进的自动化会提高事故成本，过于保守又会抬高监督成本。部署模式就是在这三项之间找平衡。

11. 一个生动比喻

把具身智能部署想成让一名新司机上路。你不会因为他在驾校模拟器里成绩好，就立刻让他独自跑高速夜间长途。更合理的方式是：先在封闭场地、再在低速熟路、再在教练陪同下上路，并且车上有刹车辅助、速度限制、后视镜与仪表监控。安全案例就是这整套论证：为什么他现在可以在某个边界内开车，以及一旦情况超出边界该怎么办。

12. 小结

具身智能部署的核心不是“把模型放到机器人上”，而是把模型、规则、硬件和运营流程组合成一个可被论证、监控和回退的系统。部署模式决定自治程度，安全案例决定上线资格。对于大多数现实团队，先缩小 ODD、建立分层防护、完善恢复与监控，比追求一句“通用机器人”更有实际价值。

工程收束

具身部署的关键不是把自治程度一次拉满，而是先把 ODD、接管条件、审计记录和回退动作写清楚。安全案例要能回答“为什么这个系统在这个边界内可以运行”，也要能回答“边界被突破时系统如何停下来或交给人”。