一个抓取请求发给机器人，网络连接随后中断。上层智能体只看见超时，却不知道夹爪是否已经夹住工件。如果立刻重试，可能重复动作；如果直接跳过，后续流程又可能基于错误状态继续。机器人动作改变了物理世界，但消息状态未必完整反映变化。
OpenGenieMaster 是一个独立社区项目，使用 MCP 暴露具身执行能力，并围绕任务连续性、准入、反馈和长期记忆组织运行时。仓库明确声明其评测来自语义级仿真，尚未验证真机；自定义协议也不保证与被复刻对象的官方实现兼容。[1] 因而，适合借鉴的是运行时设计问题，而非把仿真成功率当成机器人性能结论。
执行状态应比成功与失败更丰富
真实任务至少需要区分未提交、已受理、执行中、已完成、已失败和结果未知。网络超时通常属于最后一种。它描述的是观察能力不足，而不是动作一定失败。对于有副作用的调用，这个状态必须触发查询或对账流程。
一个建议的执行协议可以为每条命令分配稳定的 command_id，并在机器人端持久化受理状态。重复收到同一标识时，返回原执行记录，避免再次发起动作。但即使如此，也不能轻率承诺物理动作“恰好一次”：机器人控制器与状态存储之间仍可能出现崩溃窗口，需要结合设备反馈、完成判据和恢复策略处理。
仓库采用不自动重试 execute 的策略，有助于避免通信层直接重复下发。[1] 更完整的现场方案还应提供命令状态查询与人工处置入口。机器人是否实际完成动作，最终要通过控制器和现场传感器共同确认。
准入规则需要绑定当时的物理条件
在发出动作前检查标定、工具、人员状态和资源占用，是高层系统应做的工作。但“检查通过”与“开始运动”之间存在时间间隔。目标可能移动，人员可能进入，另一台机器人也可能占用工作区。因此，准入结果应带有时间范围和适用条件，执行端也需要重新确认关键前置状态。
在建议架构中，动作请求可以包含任务版本、标定版本、工具编号、目标位姿时间戳和允许工作区。执行服务发现版本不匹配或观测过期时，返回明确的拒绝原因，让上层更新信息，而非猜测新的动作参数。
软件层的停止请求也需要确认语义。请求发出、控制器受理、运动停止和能量隔离是不同状态。上层界面必须准确展示所观察到的阶段，独立的硬件安全系统则承担其设计职责。普通智能体运行时不应因提供一个 stop 工具，就被视为已经具备经过验证的安全控制功能。
任务续接不能只恢复聊天记录
当机器人拿着工件暂停，真正需要保存的状态包括工件身份、夹持状态、最后确认位置、当前任务步骤、工具和标定版本。只恢复一句“刚才已经抓取完成”，无法支撑可靠续接。人员可能已经移走工件，夹爪也可能在断电后松开。
因此，恢复过程应先读取持久化任务，再重新观察关键物理事实。两者相符才继续；存在冲突则进入对账。多机器人交接还需要明确资源所有权，例如同一个料盒、工装或零件在同一时刻由谁操作。租约和互斥机制可以组织协作，但租约失效并不说明物理空间已经清空，仍需现场确认。
长期记忆应像工程变更一样受控
将失败经验写入长期记忆，可以减少重复试错。但经验也可能来自偶然成功、错误感知或临时环境。一条“改用另一种抓取方式”的建议，应该带有适用对象、场景条件、证据来源和验证状态。
在工业实现中，可以把记忆分成候选经验、已验证规则和已废弃版本。候选经验先通过离线回放或仿真测试，再在受控任务中验证，最后才进入默认策略。版本化与回滚能够帮助恢复软件配置；已经发生的物理动作则需要独立的补偿流程。
语义级仿真适合测试这些运行时逻辑，例如中断之后是否重复调度、失败路径是否进入正确状态、旧记忆是否被错误引用。碰撞、摩擦、抓取力和制动距离属于另一层验证，需要物理仿真与硬件试验。两层测试各有价值，也各有明确范围。
我们认为，这类 Harness 提醒开发者：任务完成状态需要能查询、恢复和审计。语言模型可以更换，底层机器人也可以更换，但动作身份、反馈语义和恢复规则应保持稳定。这样，上层系统才能依据稳定的状态信息工作。
参考资料
[1] OpenGenieMaster 官方仓库说明：https://github.com/eust-w/opengeniemaster
协议文档入口：https://github.com/eust-w/opengeniemaster/blob/main/docs/eep-spec.md
架构文档入口：https://github.com/eust-w/opengeniemaster/blob/main/docs/architecture.md