为什么 OpenClaw 远程 Runner 架构重要
OpenClaw 风格的工作流在 Agent 可以离开笔记本继续运行时更有价值。但远程 Runner 不应该只是“SSH 到一台机器并保持终端打开”。它应该是可替换的工作空间：有独立分支、受限凭据、日志、健康检查和 Review Gate。
Office Claws 不是原生 OpenClaw runtime。更准确的定位是：作为 OpenClaw 相邻工作流的桌面控制层，负责创建和监控 VPS Runner，把长期密钥留在本地，并在合适时使用 Codex-backed execution。运行时选择可先看 OpenClaw vs Codex 和 OpenClaw desktop manager。
OpenClaw 远程 Runner 的形状
安全架构包含五层：本地控制平面、Runner 主机、隔离 checkout、凭据边界和 Review Gate。
| 层级 | 作用 | 缺失时的风险 |
|---|---|---|
| 本地控制平面 | 启动任务、保存密钥、展示状态 | 密钥散落在每个 VPS shell |
| Runner 主机 | CPU、网络和持续运行 | 笔记本休眠导致任务中断 |
| 隔离 checkout | 一个任务一个分支 | Agent 互相覆盖改动 |
| 凭据边界 | 短期 repo token | prompt injection 获得过大权限 |
| Review Gate | PR、CI、人类审批 | 代码过早进入生产 |
目标不是最大化自动化，而是受控自治。
参考架构
Office Claws desktop
├─ provider keys 保持本地
├─ task queue 和 approvals
└─ log / health dashboard
│
▼
VPS runner pool
├─ runner-001: repo-a / branch-a / scoped token
├─ runner-002: repo-a / branch-b / scoped token
└─ runner-003: repo-b / branch-c / scoped token
│
▼
GitHub PR + CI + human review这个模式也适用于 OpenClaw background tasks、OpenClaw monitoring 和 OpenClaw remote SSH workflow。
保护远程 Agent 的边界
不要把所有 token 放到所有 Runner 上。长期 provider key 留在本地；每个 Runner 只获得需要的 repo 和 branch；使用短期 GitHub token；部署交给 CI；日志回传给操作者；任务结束后删除 Runner 或 worktree。
这也是 Office Claws for OpenClaw users 关注桌面管理、VPS Runner、日志可见性和本地密钥处理的原因。
规格与成本建议
| 工作负载 | 建议 Runner | 说明 |
|---|---|---|
| docs、scripts、小修复 | 2 vCPU / 4 GB RAM | 低成本基线 |
| 带测试的 Web App | 4 vCPU / 8 GB RAM | 常用默认值 |
| browser/E2E | 4-8 vCPU / 16 GB RAM | 隔离浏览器依赖 |
| 大型 monorepo | dedicated runner | 缓存依赖并限制并发 |
成本控制来自队列、并发限制和及时销毁，而不只是更便宜的实例。
运行检查表
- 任务有 branch、repository 和预期输出。
- Runner 从干净 image 或 worktree 启动。
- 凭据是受限且短期的。
- logs、exit state 和 diff 可见。
- CI 是唯一部署路径。
- merge 前有人类 review gate。
更多安全模型可配合 OpenClaw security best practices 和 OpenClaw secrets management。
Office Claws 的位置
Office Claws 把这套架构变成操作工作流：本地桌面控制、远程 VPS Runner、持久任务跟踪、日志和 Codex-backed execution。结果是更强的自主性、更少隐藏终端状态，以及更小的故障影响范围。