1. 项目概述ZeroClaw 的代码执行不是“跑起来就完事”而是具身智能体的神经反射弧OpenClaw 是腾讯开源的具身智能Embodied AI硬件平台而 ZeroClaw 是其轻量级、可嵌入式部署的核心运行时——它不是传统意义上的“服务端程序”也不是一个封装好的黑盒 SDK而是一套在资源受限设备如 ESP32、树莓派 CM4、Jetson Nano上实时调度传感器输入、执行动作规划、并安全桥接大模型决策指令的 Rust 系统。标题里写的“代码执行”绝非指cargo run后终端打印出一行Hello, world!那种层面的执行它指的是整个具身闭环中最敏感、最不可控、也最易被误用的一环将 LLM 输出的自然语言动作指令经语义解析、安全校验、上下文绑定后最终转化为物理设备可执行的底层操作序列并确保该过程不越界、不阻塞、不崩溃、不被注入恶意逻辑。我第一次把 ZeroClaw 烧录进 ESP32-C3 开发板时看到串口日志里Executing action: move_arm_to(0.32, -0.18, 0.45)这行输出以为“执行成功”了。结果机械臂纹丝不动LED 灯却疯狂闪烁红光——后来查了三天才发现那行日志只是“解析完成”真正的执行卡在了ActionExecutor::dispatch()里的一个MutexGuard死锁上。这让我彻底明白ZeroClaw 的“代码执行”本质是一套带时空约束、状态快照、权限沙箱和失败回滚的确定性动作管道Deterministic Action Pipeline。它不像 Web 后端那样可以重试、可以降级、可以熔断一次执行失败可能意味着夹爪捏碎目标物、轮式底盘撞墙、或电机过热烧毁。所以本篇笔记不讲怎么编译、怎么烧录只聚焦一个核心问题当 ZeroClaw 收到一条skill(open_drawer)指令后从字符串到物理动作中间到底发生了什么每一步谁在控制谁在监督谁在兜底关键词里反复出现的Rust不是装饰——它是整个执行链路的基石。forlifetime泛型约束不是语法糖而是为了在ActionContext生命周期内严格绑定传感器采样时间戳与动作执行时刻async不是为了并发吞吐而是为了让wait_for_sensor_feedback(timeout: Duration)这类阻塞调用不冻结整个事件循环rce代码执行过滤绕过这类热词虽属误传ZeroClaw 无远程命令执行接口但恰恰暴露了社区对“执行安全”的普遍焦虑我们真能信任 LLM 输出的system(rm -rf /)被正确拦截吗还是说它只是被转成了shell_exec(rm -rf /)再丢进白名单这些都不是理论问题而是我在调试micropythonpycoclaw与 ZeroClaw 协同时亲眼见过的真实故障现场。本文所有内容均来自我在 OpenClaw 官方 GitHub 仓库main分支commit:a7e9f3c逐行阅读 实机复现 故障注入后的实操总结不抄文档不贴 API 列表只讲真实发生过的执行路径。2. 执行链路全景拆解从 Skill 调用到物理动作的七层穿透ZeroClaw 的代码执行不是单线程直通而是一个分层、异步、带状态检查的七层穿透结构。每一层都承担明确职责且任意一层失败都会触发对应层级的错误处理策略而非简单 panic 或 abort。这种设计直接源于具身硬件的物理刚性——你不能像处理 HTTP 请求那样“500 错误重试三次”机械臂关节一旦超限再重试只会加剧损伤。下面这张图文字描述版就是我画在实验室白板上的执行流[LLM Output] ↓ 解析为 SkillCall 结构体JSON → Rust struct [Skill Dispatcher] ↓ 根据 skill_name 查 registry获取 SkillDef [Permission Context Checker] ↓ 校验 caller_id、device_state、battery_level、last_action_time [Action Planner] ↓ 将 high-level skill 映射为 low-level action sequence含坐标变换、逆运动学求解 [Execution Scheduler] ↓ 插入全局 action queue按 priority deadline 排序预留 sensor feedback slot [Hardware Abstraction Layer (HAL)] ↓ 调用 platform-specific driverESP32 PWM / Jetson GPIO / ROS2 topic [Physical Device] ↓ 电机转动、舵机旋转、摄像头曝光——此时才真正“执行”2.1 第一层SkillCall 解析 —— 字符串到结构体的可信转换所有执行起点都是SkillCall定义在zeroclaw-core/src/skill/call.rs#[derive(Deserialize, Serialize, Clone, Debug)] pub struct SkillCall { pub skill_name: String, pub args: HashMapString, Value, pub caller_id: String, pub timestamp: u64, // nanoseconds since epoch pub session_id: OptionString, }注意timestamp是u64而非SystemTime这是为了跨平台序列化稳定——ESP32 没有完整 RTC靠内部计数器累加所以必须用整数。args是HashMapString, Value而非serde_json::Value因为后续所有参数校验比如target_x必须在-0.5..0.5区间都基于Value的类型做分支判断避免 JSON 解析后二次转换开销。关键点在于解析本身不信任任何输入。SkillCall::from_json()方法内部会强制执行三重校验skill_name必须匹配SKILL_REGISTRY.keys()白名单硬编码在zeroclaw-skill-registry/src/lib.rs中非动态加载args中每个 key 必须存在于该 skill 的SkillDef::required_args列表中timestamp与本地系统时间差必须 MAX_CLOCK_SKEW_MS默认 500ms超时则拒绝——防止重放攻击或 NTP 同步失败导致的指令错乱。提示很多新手在写自定义 Skill 时直接serde_json::from_str(input)然后.unwrap()结果遇到{skill_name:open_drawer,args:{pos:left}}就 panic因为pos类型应为f64而非String。ZeroClaw 的解析器会返回Err(SkillParseError::InvalidArgType { field: pos, expected: f64, got: string })你必须捕获并处理而不是让程序崩掉。2.2 第二层Skill Dispatcher —— 静态注册表驱动的技能路由ZeroClaw 没有运行时插件机制所有 Skill 都在编译期静态注册。zeroclaw-skill-registrycrate 中的register_skill!宏展开后会生成类似这样的代码// 自动生成不可手写 pub const OPEN_DRAWER_SKILL: SkillDef SkillDef { name: open_drawer, required_args: [target_height], optional_args: [speed, force_limit], permission_level: PermissionLevel::User, timeout_ms: 3000, ..Default::default() };Dispatcher 的核心逻辑在zeroclaw-core/src/skill/dispatcher.rs的dispatch()函数pub async fn dispatch( self, call: SkillCall, context: mut ActionContext, ) - ResultActionHandle, DispatchError { let skill_def self.registry.get(call.skill_name) .ok_or(DispatchError::UnknownSkill(call.skill_name.clone()))?; // 权限校验前置见下节 self.check_permission(call, skill_def, context).await?; // 参数校验调用 skill_def.validate_args(call.args) skill_def.validate_args(call.args)?; // 构建 ActionPlan调用 skill_def.planner(call.args, context) let plan skill_def.planner(call.args, context).await?; // 创建 ActionHandle 并加入 scheduler let handle self.scheduler.schedule(plan, call.caller_id).await?; Ok(handle) }这里的关键是ActionHandle—— 它不是执行结果而是一个可取消、可查询、可等待的执行句柄。你可以handle.await等待完成也可以handle.cancel()中止正在运行的动作比如用户喊“停”。这个设计让 ZeroClaw 具备了真正的交互能力而不是“发令即不管”。2.3 第三层Permission Context Checker —— 具身世界的硬性规则引擎权限检查不是简单的 RBAC基于角色的访问控制而是融合了设备状态、环境上下文、历史行为的复合判断。check_permission()方法会依次验证Caller Identitycaller_id是否在ALLOWED_CALLERS白名单中如web_ui、voice_assistant、local_cliBattery Levelcontext.battery_soc() 20.0时禁止所有move_*类技能Thermal Statecontext.cpu_temp() 75.0时降频执行所有动作 85.0时直接拒绝Last Action Gap同一caller_id在MIN_ACTION_INTERVAL_MS默认 200ms内重复调用同一 skill视为抖动自动合并或丢弃Safety Zone Violation若context.current_pose().x.abs() 0.8则拒绝move_arm_forward防止机械臂撞墙。这些检查全部在ActionContext的 immutable borrow 下完成不修改状态只读取。一旦任一条件失败立即返回DispatchError::PermissionDenied(...)并附带具体原因如battery too low: 18.3%方便上层 UI 给出精准提示。注意ActionContext是 ZeroClaw 最核心的抽象它封装了所有传感器数据、设备状态、时间戳、安全围栏等信息。它的生命周期与单次 Action 绑定且通过ArcRefCell实现线程安全共享。很多开发者试图在planner中修改context结果触发RefCell的panic!(already borrowed)—— 正确做法是context.clone()获取新引用或使用context.with_mut(|c| c.set_flag(...))安全修改。2.4 第四层Action Planner —— 从语义到运动学的数学翻译Planner 是 ZeroClaw 的“大脑皮层”负责把{target_height: 0.35}这样的高层语义翻译成[(joint_0: 1.23, joint_1: -0.45, joint_2: 0.89), ...]这样的关节角度序列。以open_drawer为例其 planner 实现在zeroclaw-skill-open-drawer/src/planner.rspub async fn plan_open_drawer( args: HashMapString, Value, context: ActionContext, ) - ResultActionPlan, PlannerError { let target_height args.get(target_height) .and_then(|v| v.as_f64()) .ok_or(PlannerError::MissingArg(target_height))?; // 1. 获取当前 drawer 状态从 context 读取 hall effect sensor let drawer_state context.drawer_state().await?; if drawer_state DrawerState::Open { return Ok(ActionPlan::empty()); // 已开无需动作 } // 2. 计算目标关节角度调用 IK solver let ik_result inverse_kinematics( context.robot_model(), Point3D::new(0.0, 0.0, target_height), )?; // 3. 生成平滑轨迹50ms 间隔100 点 let trajectory generate_spline_trajectory( context.current_joint_angles(), ik_result.joint_angles, Duration::from_millis(2000), ); Ok(ActionPlan::new(trajectory)) }这里inverse_kinematics()调用的是zeroclaw-mathcrate 中的纯 Rust 实现非 ROS 的 MoveIt支持实时求解。generate_spline_trajectory()使用三次样条插值确保加速度连续避免电机抖动。所有 Planner 都必须返回ActionPlan且其trajectory长度不能超过MAX_TRAJECTORY_POINTS默认 200否则 scheduler 会拒绝——这是防止内存溢出的硬限制。2.5 第五层Execution Scheduler —— 带优先级与截止时间的动作队列Scheduler 是 ZeroClaw 的“小脑”负责协调多个动作的并发与抢占。它的核心是PriorityQueueActionPlan排序规则为Deadline Firstplan.deadline()越早越优先如语音指令要求 1s 内响应Priority Second同 deadline 下plan.priority()高者优先Emergency User SystemInsertion Order Last前两者相同时先入先出。每个ActionPlan在入队前scheduler 会为其分配一个feedback_slot—— 这是一个固定大小的 ring buffer默认 128 entries用于存储执行过程中传感器反馈如电机电流、编码器位置、力矩传感器值。如果某动作预计耗时 2s采样率 100Hz则需至少 200 个 slotscheduler 会检查 buffer 是否足够不足则拒绝。实操心得我在 Jetson Orin 上测试时发现当同时提交move_arm和take_photo两个 high-priority 动作take_photo总是被延迟。排查后发现take_photo的deadline设置为Instant::now() Duration::from_millis(500)而move_arm是2000但take_photo的priority是Emergency理应抢占。最终定位到scheduler.rs中一个 bugPriorityQueue的peek()方法未正确处理相同 deadline 下的 priority 比较已提 PR 修复#427。这说明 scheduler 的逻辑必须极其严谨毫秒级偏差都可能导致物理行为异常。2.6 第六层Hardware Abstraction Layer —— 硬件无关的驱动桥接HAL 层定义在zeroclaw-halcrate提供统一接口pub trait MotorDriver: Send Sync { fn set_pwm(self, channel: u8, duty_cycle: f32) - Result(), HalError; fn read_encoder(self, channel: u8) - Resulti32, HalError; } pub trait CameraDriver: Send Sync { fn capture_frame(self) - ResultRawImage, HalError; }不同平台实现不同 traitesp32-hal基于 ESP-IDF 的ledc和gpio驱动linux-hal通过 sysfs GPIO 和 V4L2 ioctl 控制ros2-hal发布/motor_cmdtopic订阅/encoder_feedback。关键设计是HAL 不做任何业务逻辑只做原子操作。set_pwm()必须是幂等的多次调用同一参数不应累积效果read_encoder()返回原始计数值单位换算由上层ActionContext完成。这样保证了 HAL 可被单元测试mock driver且更换硬件时只需重写 HAL 实现不影响上层 planner 和 scheduler。2.7 第七层Physical Device —— 真正的“执行”在此发生最后一层没有代码只有物理世界。当HAL::set_pwm(2, 0.75)被调用ESP32 的 LEDC 模块输出 75% 占空比 PWM 信号驱动 MOSFET 导通电流流过舵机线圈产生电磁力矩带动齿轮组旋转最终改变机械臂关节角度……这个过程不可逆、不可暂停、不可撤销。ZeroClaw 唯一能做的是在此之前设置好硬件看门狗Watchdog Timer和电流保护阈值Current Limit。在esp32-hal初始化时会配置watchdog_enable(WDT_LED, 2000)若 2s 内无feed_watchdog()调用自动复位motor_driver.set_current_limit(2500)单位 mA超限立即关断 PWM。这意味着真正的“执行”发生在硬件层而 ZeroClaw 的全部价值在于让这一不可逆过程变得可预测、可监控、可中断在动作开始前。这也是为什么rce代码执行过滤绕过这类热词是伪命题——ZeroClaw 根本不执行任意代码它只执行预编译、预校验、预限幅的确定性动作序列。3. 核心执行模块深度解析ActionExecutor 与 ExecutionLoop 的协同机制如果说前面七层是执行的“经络”那么ActionExecutor和ExecutionLoop就是 ZeroClaw 的“心脏”与“血液循环系统”。它们共同构成了代码执行的 runtime 核心决定了整个系统是稳定如钟表还是脆弱如薄冰。3.1 ActionExecutor动作执行的原子单元与状态机ActionExecutor定义在zeroclaw-core/src/executor.rs它不是一个单例而是每个ActionHandle持有一个独立实例。其核心字段pub struct ActionExecutor { plan: ActionPlan, hal: Arcdyn HalInterface, feedback_buffer: ArcMutexRingBufferFeedbackEntry, state: ArcAtomicU8, // 0Idle, 1Running, 2Paused, 3Cancelled, 4Completed start_time: Instant, }state是AtomicU8而非enum因为要支持 CASCompare-And-Swap无锁操作。start_time记录动作开始的精确时刻用于计算elapsed和remaining时间驱动plan中的轨迹插值。执行流程高度状态化pub async fn execute(self) - ResultExecutionResult, ExecutorError { self.set_state(State::Running)?; // 1. 初始化硬件如使能电机驱动器 self.hal.init_motor_drivers().await?; // 2. 主循环按 plan.step_interval() 定时执行 let mut step 0; while step self.plan.trajectory.len() self.state.load(Ordering::Relaxed) State::Running as u8 { let target_pos self.plan.trajectory[step]; // 3. 写入目标位置到 HAL self.hal.set_joint_positions(target_pos).await?; // 4. 读取当前反馈并存入 buffer let feedback self.read_feedback().await?; self.feedback_buffer.lock().await.push(feedback); // 5. 等待下一个 step 时间点 let next_step_time self.start_time self.plan.step_interval() * (step as u32 1); let sleep_duration next_step_time.saturating_duration_since(Instant::now()); tokio::time::sleep(sleep_duration).await; step 1; } // 6. 清理关闭电机保存 final feedback self.hal.disable_motor_drivers().await?; self.save_final_feedback().await?; match self.state.load(Ordering::Relaxed) { State::Completed as u8 Ok(ExecutionResult::Success), State::Cancelled as u8 Ok(ExecutionResult::Cancelled), _ Err(ExecutorError::UnexpectedState), } }注意tokio::time::sleep()的使用它不是粗暴的thread::sleep而是异步睡眠不阻塞 executor 线程。saturating_duration_since防止next_step_time已过期时sleep传入负值导致 panic。关键细节set_joint_positions()调用的是 HAL 的批量接口一次写入所有关节目标值而非逐个set_pwm。这是因为多关节协同运动必须严格同步否则会出现“甩臂”现象。ESP32 的ledc驱动实现了硬件级 PWM 同步通过ledc_timer_config_t的clk_cfg字段启用LEDC_AUTO_CLK确保所有通道时钟源一致。3.2 ExecutionLoop心跳驱动的全局执行中枢ExecutionLoop是 ZeroClaw 的主事件循环位于zeroclaw-core/src/loop.rs。它不是传统意义上的while true而是基于tokio::select!的异步事件驱动pub async fn run(mut self) - Result(), LoopError { let mut scheduler_watcher self.scheduler.watch_queue(); let mut feedback_collector FeedbackCollector::new(self.hal.clone()); loop { tokio::select! { // 事件1新动作入队 Some(action) scheduler_watcher.recv() { self.spawn_executor(action).await?; } // 事件2传感器反馈到达如 IMU 数据 Some(feedback) feedback_collector.recv() { self.context.update_sensor_feedback(feedback).await?; } // 事件3定时健康检查每 100ms _ tokio::time::sleep(Duration::from_millis(100)) { self.health_check().await?; } // 事件4外部信号如 SIGTERM _ signal::ctrl_c() { self.shutdown().await?; break; } } } Ok(()) }spawn_executor()是关键它使用tokio::task::spawn启动ActionExecutor::execute()但做了重要包装async fn spawn_executor(self, action: ActionHandle) - Result(), LoopError { let executor ActionExecutor::new(action.plan, self.hal.clone(), self.feedback_buffer.clone()); // 为每个 executor 设置超时防止死循环 let timeout action.plan.timeout_ms(); tokio::spawn(async move { match tokio::time::timeout( Duration::from_millis(timeout), executor.execute() ).await { Ok(Ok(result)) { // 更新 context 状态 action.complete(result).await; } Ok(Err(e)) { action.fail(e).await; } Err(_) { // 超时强制 cancel action.cancel().await; action.fail(ExecutorError::Timeout).await; } } }); Ok(()) }这里tokio::time::timeout是第二道保险——即使ActionExecutor内部逻辑有 bug 导致无限循环也会在timeout_ms后被强制终止。action.complete()会更新ActionContext中的last_action_result供后续 skill 依赖如close_drawer需确认open_drawer已成功。3.3 Execution Context 的生命周期管理从创建到销毁的全程追踪ActionContext不是全局单例而是随每次dispatch()调用动态创建、随execute()完成自动销毁。其生命周期管理是 ZeroClaw 安全性的基石。创建时ActionContext::new()会 snapshot 当前所有传感器值IMU、encoder、battery、temperature生成唯一context_idUUID v4用于日志追踪和 debug设置created_at Instant::now()作为所有时间计算的基准。执行中executor通过ArcRefCellActionContext弱引用访问 context只读取current_pose()、battery_soc()等状态feedback_collector通过强引用ArcActionContext写入新反馈触发context.update_sensor_feedback()该方法会检查新反馈是否超出safety_limits如关节角度 180°若越限立即调用self.executor.cancel()并记录SafetyViolation事件更新context.last_feedback_time用于wait_for_sensor_feedback()的 timeout 判断。销毁时executor.execute()返回后ActionContext的Arc引用计数减一若计数为 0Droptrait 被触发自动清理关闭所有打开的 HAL 设备句柄清空feedback_bufferring buffer记录ContextDestroyed日志包含duration_ms和max_memory_usage_kb。实操心得我在调试openclaw龙虾 windows离线整合包时发现 Windows 版 ZeroClaw 在长时间运行后内存泄漏。用heaptrack分析发现ActionContext的Drop未被调用。根本原因是tokio::spawn的 task 未被正确 await导致Arc引用永远不释放。解决方案是在ExecutionLoop::shutdown()中添加self.active_executors.join_all().await等待所有 executor task 结束。这个坑官方文档没写但源码里tests/integration_test.rs的teardown函数里藏着答案。4. 安全执行保障体系过滤、校验、沙箱、回滚的四重防线ZeroClaw 的“代码执行”之所以能用于真实机器人不在于它多快而在于它多稳、多安全。这套安全体系不是附加功能而是从SkillCall解析开始就深度耦合在每一层的 DNA 里。它由四重防线构成输入过滤、语义校验、执行沙箱、失败回滚缺一不可。4.1 输入过滤从字符串到 SkillCall 的第一道闸门所有外部输入HTTP API、WebSocket、串口、ROS topic在进入dispatch()前必须经过InputFilter。它不是简单的正则匹配而是基于 AST 的结构化过滤pub struct InputFilter { max_json_size: usize, // 默认 1024 bytes allowed_keys: HashSetstatic str, disallowed_patterns: VecRegex, } impl InputFilter { pub fn filter(self, input: str) - ResultString, FilterError { // 1. 大小检查 if input.len() self.max_json_size { return Err(FilterError::TooLarge); } // 2. JSON 语法检查不解析只验证结构 if !is_valid_json_structure(input) { return Err(FilterError::InvalidJson); } // 3. Key 白名单检查解析为 serde_json::Value遍历所有 keys let value: Value serde_json::from_str(input)?; if let Some(obj) value.as_object() { for key in obj.keys() { if !self.allowed_keys.contains(key.as_str()) { return Err(FilterError::DisallowedKey(key.clone())); } } } // 4. 模式黑名单如禁止 system\(, eval\(, os\.system for pattern in self.disallowed_patterns { if pattern.is_match(input) { return Err(FilterError::MatchedPattern(pattern.to_string())); } } Ok(input.to_string()) } }disallowed_patterns包含 12 条正则覆盖常见注入模式r#rce|exec|system|popen|subprocess\.run#ir#\$\{.*?\}#Shell 变量替换r#.*?#命令替换注意InputFilter运行在zeroclaw-gateway层而非zeroclaw-core。这意味着即使你绕过 gateway 直连 coreSkillCall::from_json()的第一层校验skill_name白名单依然生效。双重过滤互为备份。4.2 语义校验SkillDef 的声明式约束SkillDef中的validate_args()方法是第二道防线它基于类型和范围进行静态校验impl SkillDef { pub fn validate_args(self, args: HashMapString, Value) - Result(), ValidationError { // 检查 required_args 是否全部存在 for req in self.required_args { if !args.contains_key(req) { return Err(ValidationError::MissingRequiredArg(req.clone())); } } // 检查每个 arg 的类型和范围 for (key, value) in args { let schema self.arg_schema.get(key).ok_or_else(|| { ValidationError::UnknownArg(key.clone()) })?; match schema { ArgSchema::Float { min, max } { let f value.as_f64().ok_or_else(|| { ValidationError::WrongType(key.clone(), float.to_string()) })?; if f *min || f *max { return Err(ValidationError::OutOfRange( key.clone(), *min, *max, f )); } } ArgSchema::Enum { values } { let s value.as_str().ok_or_else(|| { ValidationError::WrongType(key.clone(), string.to_string()) })?; if !values.contains(s.to_string()) { return Err(ValidationError::InvalidEnum( key.clone(), values.clone(), s.to_string() )); } } // ... 其他类型 } } Ok(()) } }arg_schema在register_skill!宏中定义例如open_drawer的target_heightschema 是Float { min: 0.0, max: 0.6 }。这意味着即使InputFilter放过了{target_height: abc}validate_args()也会在第二层报错WrongType。4.3 执行沙箱硬件层的物理围栏与软件层的资源隔离ZeroClaw 的沙箱是软硬结合的硬件沙箱ESP32 的ledc驱动内置duty_cycle_limitset_pwm()调用时会自动 clamp 到[0.0, 1.0]Jetson 的 GPIO 驱动使用sysfs的direction和value文件写入前检查value是否为0或1非法值直接 ignore。软件沙箱ActionExecutor的execute()方法中所有hal调用都包裹在match中match self.hal.set_joint_positions(target_pos).await { Ok(()) {} Err(HalError::OutOfBounds(pos)) { // 硬件拒绝执行记录 error 并跳过此 step warn!(Joint position out of bounds: {:?}, pos); continue; } Err(e) { // 其他错误如通信失败标记为 failure return Err(ExecutorError::HalError(e)); } }更重要的是ActionContext的safety_limits是动态的。例如当context.current_pose().z 0.1机械臂接近桌面move_arm_down的min_z限制会从0.05自动收紧到0.08防止碰撞。这个 limit 表由SafetyZoneManager维护它监听context的pose_update事件实时调整。4.4 失败回滚从 partial success 到 graceful degradationZeroClaw 不追求“全有或全无”而是设计了细粒度的回滚策略Step-level rollback单个 trajectory step 失败如某个关节未到达目标ActionExecutor会记录PartialFailure但继续执行后续 steps最后返回ExecutionResult::PartialSuccess。上层可据此决定是否重试或降级。Action-level rollback若execute()报错如HalError::TimeoutActionExecutor会调用self.hal.emergency_stop()该方法向所有电机发送duty_cycle 0.0并触发context.set_emergency_state(true)。Context-level rollbackActionContext::drop()时若检测到emergency_state true会自动执行context.restore_last_safe_pose()该 pose 是context创建时 snapshot 的确保设备回到已知安全状态。实操心得我在测试由于找不到 rstrtmgr.dll,无法继续执行代码这类 Windows DLL 错误时发现它其实与 ZeroClaw 无关——那是 Windows 系统服务Restart Manager的缺失影响的是openclaw-gateway的 Windows 服务安装而非zeroclaw-core的执行。但这个错误提示暴露了一个关键点ZeroClaw 的错误信息必须精准指向问题根源而非泛泛而谈。因此我在zeroclaw-core的所有 error enum 中都强制要求Displaytrait 输出包含file!(),line!()和module_path!()例如ExecutorError::Timeout的显示为executor.rs:142: Action execution timed out after 3000ms。这样用户一眼就能定位到是哪个模块、哪一行代码出了问题而不是在茫茫日志中大海捞针。5. 常见执行问题与实战排查指南从日志到硬件的全链路诊断在真实部署中ZeroClaw 的执行问题极少是单一原因往往是多层叠加的结果。下面是我整理的 7 类高频问题每类都附带现象、根因、排查步骤、修复方案全部来自实际故障现场。5.1 现象ActionHandle::await永远不返回串口