为什么 OpenClaw 需要 GitHub 工作流
OpenClaw 风格的代理之所以有用，是因为它们会在第一个 prompt 之后继续工作。同一个优点也让 GitHub 纪律变得不可省略：一个代理可以改几十个文件，另一个代理可以修测试，第三个代理可以审查 diff。没有分支和 pull request 模式，团队拿到的只是一堆没有明确负责人的变更。
Office Claws 不是原生 OpenClaw runtime。我们把同样的运营经验用在 Codex 支撑的代理上：一个任务对应一个 runner、一个分支、一条日志流和一个可审查的 PR。如果你正在比较 runtime，请先看 OpenClaw vs Codex，然后把下面的工作流作为任一方案外面的安全 GitHub 层。
OpenClaw 分支模式
在代理写代码之前，先给它一个分支。分支名应该让审查者不用打开 PR 就能知道发生了什么。我们喜欢这种格式：
agent/<ticket-or-topic>-<short-purpose>
fix/<bug>-agent
docs/<topic>-agent一点命名纪律可以避免两个常见故障：代理直接 push 到 main，以及人类搞不清哪个 runner 拥有哪些 diff。在 Office Claws 中，桌面视图把任务映射到 runner 和日志流；GitHub 分支就是对应的源码控制把手。
| 步骤 | 负责人 | 闸门 | 避免的故障 |
|---|---|---|---|
| 创建分支 | 人类或调度器 | 分支名包含任务 | 代理修改 main |
| 运行代理 | 隔离 runner | 每个任务一个 worktree | 多代理文件冲突 |
| push 草稿 PR | 代理 | CI 立即开始 | 隐藏的本地变更 |
| 审查 diff | 人类或审查代理 | 必需批准 | 静默的架构漂移 |
| 合并 | 人类 | CI 通过 | 生产分支损坏 |
有用的规则很简单：代理可以提出代码，但不能做最终集成决定。
代理审查之前先过 CI 闸门
在请另一个代理审查工作之前，先运行那些无聊的检查。当审查代理不用把上下文浪费在 TypeScript 格式错误上时，它更擅长发现架构问题、边界情况和缺失测试。
一个面向 OpenClaw 相邻 web 仓库的最小 GitHub Actions 闸门如下：
name: agent-pr
on:
pull_request:
branches: [main]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
cache: npm
- run: npm ci
- run: npm run lint --if-present
- run: npm test --if-present
- run: npm run build对 Office Claws 用户来说，这正是桌面管理器发挥价值的地方：让 coding 代理运行在 VPS 上，把 provider 密钥保存在本地，并让 GitHub 成为人类检查最终 diff 的中立位置。管理层请看 面向 OpenClaw 用户的 Office Claws，runner 架构请看 OpenClaw on VPS。
代理之间的安全交接
交接应该是明确的。不要只告诉审查代理「检查这个仓库」。告诉它哪个 PR、哪些测试通过了、改了什么，以及你希望它审查哪类风险。
Review PR #42 on branch agent/billing-export.
CI is green. Focus on data-loss risk, auth boundaries, and migration rollback.
Do not push unless you create a separate reviewer branch.
Return: blocking issues, non-blocking suggestions, and merge recommendation.
权限也要同样明确：
- Coding 代理只能 push 到自己的分支。
- 审查代理可以评论，不能合并。
- release token 不出现在代理 runner 上。
- 人类保留最终 merge 按钮。
这个模型适用于 OpenClaw、Codex，或任何未来的代理 runtime。重要的不是代理品牌，而是围绕它所写代码的审查边界。
推荐工作流
- 每个任务都从新分支和隔离 worktree 开始。
- 让代理尽早 push 草稿 PR，即使工作还没完成。
- 在审查代理反馈之前要求 CI 通过。
- 让 provider 密钥和 release 凭据留在 runner 之外。
- 只有在人类读过 PR 摘要、测试输出和高风险文件后才合并。
如果你正从临时 OpenClaw 会话迁移到团队可以信任的流程，这套 GitHub 工作流就是第一个该建立的习惯。Office Claws 为 OpenClaw 风格团队提供桌面管理、VPS runner 隔离、Codex 支撑的执行，以及更安全的本地密钥处理，让这些习惯更容易坚持。
相关阅读
- OpenClaw vs Codex — 每种 runtime 适合哪里。
- OpenClaw Desktop Manager — Office Claws 面向 OpenClaw 风格工作的管理层。
- OpenClaw Security Best Practices — 密钥处理、runner 隔离和审计日志。