把 OpenClaw 放进 CI，本质是回答三件事：谁触发、跑在哪、如何鉴权。GitHub 托管的 macOS Runner 与 MacCloud 上的自托管 Runner可以组合使用——前者适合轻量步骤，后者适合对磁盘、内核扩展或常驻服务更敏感的工作负载。
一、触发策略：别在每次 push 上跑全量
长任务用 workflow_dispatch 或定时；对 PR 用路径过滤，减少无效分钟数。OpenClaw 相关步骤尽量单独 Job，避免和普通 lint 混在同一矩阵里被频繁打断。
二、密钥、令牌与审计
生产密钥放进 GitHub Environments，配合 Required reviewers。需要访问 MacCloud API 或工单接口时，用短期令牌并定期轮换，禁止写死在仓库文件中。审计日志里应能还原「哪次 run 用了哪把钥匙」。
底线：任何能操作生产 Mac 或费用的凭证，都要可吊销、可追踪。
三、自托管 Runner 落在 MacCloud
在独享 Mac 上注册 Runner 后，为 OpenClaw Job 打专用标签（例如 runs-on: [self-hosted, macOS, openclaw]），与通用 iOS 构建队列隔离。机器维护、系统升级前，记得在 GitHub 侧禁用 Runner，避免半升级状态抢任务。
四、缓存、制品与日志
大依赖用 Actions Cache 或内部制品库；日志与报告用 artifact 上传，便于和 OpenClaw 侧事件对照。缓存键要包含锁文件哈希，避免「命中了旧依赖却以为是最新」的隐性失败。
五、失败时怎么缩小爆炸半径
为 OpenClaw 相关步骤设置超时与重试上限；不可恢复错误（鉴权失败、配额耗尽）应立即失败并打标签，而不是无限重试占满队列。与编排场景里的退避策略保持一致。
六、自检清单
- 触发条件是否覆盖默认分支、PR、手动三类场景？
- Environment 保护规则是否挡住未审核的 fork PR？
- Runner 标签是否与 Job 矩阵一一对应、没有漏跑或误跑？
- artifact 里是否包含足够排障的日志级别？
云上常驻进程与 Runner 混用时，务必再读MacCloud 实践，对齐磁盘、优雅退出与计费边界。
