机器人恢复作业之前，谁来验收交接后的现场

Google Cloud 在 2026 年 10 月 30 日的机器人生态文章中描述了云端规划与设备端控制的分工。相关 ER2 公共预览公告发布于 10 月 27 日。两个日期应当分开，生态介绍也不能代替生产现场的验收结果。

这种分工提出一个值得采购方提前处理的问题：一次任务被打断之后，谁有责任证明现场已经适合继续？以下是 Open Market Notes 对交付与验收的分析框架，并非对上述产品事故、缺陷或客户表现的报道。

交付边界应延伸到恢复作业

采购讨论容易围绕正常运行展开：模型能否理解任务，机械臂能否完成动作，业务系统能否接收完成记录。三个部分分别合格，仍然可能留下一个没有被任何单项验收覆盖的环节。有人介入、工件移动或任务取消以后，原来的计划依据是否还成立？

这里需要约定的不是笼统的“系统恢复正常”，而是恢复所需的具体现场条件。工件在哪里，夹具处于什么状态，原任务哪些步骤已经完成，后续步骤以什么观察为依据。软件服务重新可用，只能回答其中一部分问题。

以一个假设的包装工作站为例。机械臂放下零件后，工作人员为了排查问题把零件挪到另一只托盘。模型供应商可以确认服务正常，设备供应商可以确认运动控制正常，集成商也可能确认任务队列仍然存在。但这些确认尚未说明哪只托盘应接收下一步操作。若恢复流程只是重复旧指令，技术部件的健康状态就会被误当作整个任务的连续性。

这个例子不说明任何具体产品会犯这样的错误。它说明采购验收最好包含一次真实可观察的交接：谁更新任务状态，谁核对现场变化，谁在什么条件下批准继续。最终执行动作的系统应当知道自己接收的是新的确认，还是中断前留下的判断。

将故障归因与复工授权分开

根因调查可能需要多个供应商共同参与。模型输出、传感器观察、控制器反馈和业务记录之间的差异，也可能一时无法解释。如果必须先判清责任才能决定下一步，现场就只能等待合同争议结束。

更实用的安排是分别约定两条路径。调查路径保留相关版本、时间和证据，供后续确认原因。复工路径则由事先指定的负责人依据现场验收条件作出决定。这是治理建议，不是法律责任的判断，也不意味着降低设备安全要求。

责任人不应只作为联系人列在文档里。其权限、所需输入、可接受的证据以及无法判断时的升级渠道，都应属于交付范围。若某个条件没有人能够核验，正确的验收结论应允许任务继续停留在未恢复状态，而不是把缺失信息自动理解为通过。

测试完整的交接，而不只测试部件

采购方可以要求供应商共同设计受控的中断演练。关键不在于制造危险，而在于使用经现场专业人员批准的测试方式，验证信息和决定如何流转。例如，在模拟环境或适当隔离的测试条件下改变工件位置，观察旧任务状态是否被识别为过期，以及现场确认是否真正进入新的执行依据。

记录应覆盖从发现状态不一致，到指定负责人接手，再到满足恢复条件的整个过程。单个组件的响应速度不能代表这段时间。若需要人工参与，人工投入及等待也应进入交付评估，否则自动化收益会把重要的配套工作排除在外。

不同业务的合理条件不会相同。实验室样品、零售货架和工厂零件的处理约束各有差异。供应商可以提供通用能力，采购方仍需要说明自身允许怎样的中断、返工和人工接管。把这些限制写清楚，也有助于避免日后将业务规则误归为模型缺陷。

升级时保留共同验收的版本组合

如果模型、控制软件或任务系统由不同团队更新，原来通过的交接流程可能不再对应当前组合。建议保留一次联合验收所覆盖的版本、接口含义和现场假设；变更时根据影响重新验证相关交接，而不是仅凭每个供应商自己的测试报告判断整体仍然有效。

这会增加协调成本。对于固定、简单的工作站，过于复杂的联合流程可能不划算，因此应按任务后果和现场变化程度确定深度。采购比较也应把恢复能力的证据、责任范围与价格一起考虑，而不是要求所有场景采用同一套繁重制度。

Google 的两篇文章为讨论提供了技术背景，没有证明哪一种责任安排在所有场景中最好。真正值得在合同和试运行阶段回答的，是运营方能否观察到一次交接已经完成，以及交接未完成时是否有人拥有明确的处置责任。这样的答案，往往比再增加一项正常运行演示更能帮助判断系统是否适合交付。