OpenClaw 风格的自治只有在运行模型足够「无聊」时才有价值。代理可以探索、修改、测试并回报结果，但围绕它的架构必须把每条边界讲清楚：任务从哪里开始，哪个 runner 负责它，它能看到哪些 secrets，以及哪个 gate 决定工作是否可以发布。
Office Claws 不是原生 OpenClaw runtime。我们把它用作 OpenClaw 相邻、Codex-backed workflows 的桌面和 VPS 控制层：把任务放入队列，隔离 runner，流式传输 logs，缩小 key 权限，并把 review 作为默认路径。如果你还在选择 runtime，先看 OpenClaw vs Codex 和 Office Claws for OpenClaw users。
OpenClaw 代理架构的形状
安全的 OpenClaw 代理架构有五层。每一层都应该可以替换，而不需要过度信任其他层。
| 层 | 职责 | 设计规则 |
|---|---|---|
| 控制平面 | 接收任务、显示状态、保存操作者状态 | 长期 key 留在本地 |
| 队列 | 限制并发并分配归属 | 一个任务应该只有一个活跃 runner |
| Runner | 在 worktree 或 VPS 中执行命令 | 让它可丢弃 |
| Secret 边界 | 只授予当前任务需要的访问权限 | 优先使用受限、短期 token |
| Review gate | 将输出变成 PR、release note 或拒绝 | 生产变更由人批准 |
这种分离能避免自治编程变成「品牌更好看的共享终端」。队列让工作可见，runner 把状态关在边界内，review gate 防止一次成功命令自动变成部署。
参考蓝图
把这张蓝图当作起点，而不是某个单一产品功能的图。真正重要的是组件之间的契约。
Office Claws desktop control plane
├─ task queue
├─ local provider keys
├─ approvals and status
└─ log viewer
│
▼
Runner pool
├─ local runner: small edits, docs, quick tests
├─ VPS runner: long tasks, stable network, CI triage
└─ disposable worktree: one branch per task
│
▼
Git provider
├─ branch + pull request
├─ CI checks
└─ human review before merge如果涉及远程执行，可以配合阅读 OpenClaw remote runner architecture。如果关注长期任务可靠性，再看 OpenClaw background tasks 和 OpenClaw monitoring。
最重要的边界
风险最高的错误，是把代理当成一台可信的开发者笔记本。它不是。它是一个 worker，有任务、有上下文窗口，也会自信地犯错。
先建立这些边界：
- 任务边界： 在 runner 启动前定义 repo、branch、允许路径和成功 gate。
- 文件系统边界： 使用干净 worktree 或一次性 VPS image，不要使用永久共享 checkout。
- 凭据边界： 不要把 billing、production 或组织级 token 放到 runner 上。
- 网络边界： 清楚任务真正需要哪些外部服务。
- Merge 边界： 进入
main前要求 PR review、CI 或其他显式 gate。
这就是为什么 OpenClaw 风格 workflows 需要一个操作层。Office Claws for OpenClaw users 关注桌面控制、VPS runner、logs 和 Codex-backed execution，而不是给每个代理一只带着所有 secrets 的永久 shell。
需要提前设计的失败模式
好的架构会假设代理以普通方式失败。系统应该让这些失败可见、可恢复。
| 失败模式 | 症状 | 更安全的响应 |
|---|---|---|
| 上下文丢失 | 代理重复工作或扩大范围 | 停止任务并总结剩余工作 |
| Runner 变脏 | 测试只因本地状态而通过 | 重建 runner 或 checkout |
| Token 暴露 | logs 或 diff 中出现 secrets | 撤销 token、删除 runner、审计 branch |
| 无限循环 | 命令反复重试但没有进展 | 设置 timebox 并展示 logs |
| 修复过宽 | 小 bug 变成大重写 | 拒绝 PR，并用更窄任务重启 |
目标不是阻止每一次失败尝试。目标是让失败足够便宜：停止、检查、重置，然后用更紧的任务契约再试一次。
先构建什么
如果你从零开始构建 OpenClaw 代理架构，不要先做复杂 scheduler。先做能保持工作可 review 的最小闭环：
- 一条任务记录，包含 owner、repo、branch 和预期输出。
- 每个活跃任务一个隔离 runner。
- 即使关闭标签页或笔记本睡眠也能保留的 log stream。
- 一个验证命令，例如
npm run build、go test ./...或npx velite build。 - merge 或 deploy 前基于 PR 的 review gate。
等这个闭环稳定后，再加入并发限制、runner pools、成本追踪和自动清理。它们都很有价值，但次于核心契约：一个任务，一个 runner，一个 branch，一个 review 路径。
Office Claws 的位置
Office Claws 把这套架构变成日常 workflow：本地桌面管理、VPS runners、持久后台任务、状态可见性，以及面向需要 OpenClaw 风格自治但不想失去运行控制的团队的 Codex-backed execution。
它不需要假装每个代理默认安全。更安全的假设是：代理强大、有用，也会出错。架构给它们工作空间，同时把 secrets、branches 和 production 放在显式 gates 后面。
这就是 OpenClaw agent architecture 的实用版本：让自治可观察，让 runners 可替换，并让发布成为经过 review 的决定，而不是副作用。
相关阅读
- OpenClaw vs Codex — 比较 runtime 和运行模型。
- OpenClaw desktop manager — 面向 OpenClaw 相邻 workflows 的本地控制。
- OpenClaw security best practices — 在代理接触真实 repos 前降低 blast radius。