并行 Codex 工作流：如何把一个功能拆给多个 Agent

并行不是让五个 Agent 做同一件事

并行 Codex 工作流的前提是：每个 Agent 拥有问题中相互隔离的一块。失败的模式通常是所有 Agent 都修改同一批文件，提出不同设计，最后交给你一个巨大的 merge 冲突。

目标很简单：把一个功能拆成几个安全的 workstream，让 Codex 在独立的 VPS Agent 上运行，只在测试和 review 后合并。Office Claws 让这件事更容易，因为每个 Agent 都有自己的主机、分支、终端状态，以及桌面应用里可见的座位。产品判断仍然由你做；等待、测试和机械改动交给 Agent。

规则：按边界拆，不按愿望清单拆

一个糟糕的拆法是：

• Agent A：实现功能
• Agent B：写测试
• Agent C：更新文档

看起来并行，但 B 还不知道接口，C 也可能在记录马上会改变的行为。

更好的拆法沿着技术边界：

• Agent A：数据库迁移和 repository 层
• Agent B：API route 和校验
• Agent C：UI 的 empty/loading/error 状态
• Agent D：接口稳定后写文档和 release note

如果两个 Agent 需要修改同一个文件，拆分大概率有问题。

一个实用的四分支流程

1. 先写 contract

启动 Agent 前，在主分支写一个很小的 contract：类型、endpoint 形状、文件名和测试命令。

Endpoint: POST /api/runs/:id/retry
Request: { mode: "failed-only" | "all" }
Response: { runId: string, queuedTasks: number }
Tests: npm run test -- retry
不要重命名已有 RunStatus 值。

这很无聊，但它正是并行和混乱的分界线。

2. 一个 Agent 一个分支

按职责命名分支：

• feat/retry-runs-api
• feat/retry-runs-ui
• feat/retry-runs-tests
• docs/retry-runs-release-note

在 Office Claws 里，每个 Codex Agent 都在自己的 VPS 和分支上工作。失败实验会留在原地，不会污染其他 workstream。

3. 写窄 prompt

你只负责 retry runs 的 API route 和 validation。
不要编辑 UI 文件。不要重命名 shared status enums。
结束前运行：npm run test -- retry
返回 summary、修改文件，以及任何需要的 contract 变更。

这些禁止项不是礼貌用语，而是 merge 冲突预防。

Merge 顺序很重要

先合并最基础的部分：data model，然后 API，然后 UI，最后 docs。每次合并后，把剩余分支 rebase 到最新状态，让所有 Agent 都看到当前 contract。

1. repository/database 分支测试通过后合并
2. rebase API 分支，修正 contract drift，再合并
3. rebase UI 分支，接入真实 endpoint
4. tests/docs 最后收尾

不要等到最后一次性合并所有分支。那会制造巨大的 review，并隐藏设计变化发生的位置。

什么时候值得并行

并行适合有自然边界的工作：

• Backend + frontend + docs
• Migration + adapter + tests
• 一个 Agent 重构 package，另一个更新 call sites
• 同时调查三种修复方案，然后只保留最好的一种
• 把同一模式移植到多个独立 integration

如果只是 20 行 bug fix，一个 Codex session 更快。

Office Claws 的位置

你当然可以用 SSH tabs 和 tmux 手动做。难点是记住哪台机器、哪个分支、哪个终端负责哪一块。Office Claws 提供的就是这个 control plane：多个运行在 VPS 上的 Codex Agent，都从一个桌面应用里可见。

如果你从 OpenClaw 迁移过来，先看 OpenClaw vs Codex 对比。如果你已经确定要托管 Codex Agent，价格页 说明了 self-hosted 和 managed 选项。

启动前三 Agent 的 checklist

• 是否有书面 contract？
• 每个 Agent 是否拥有不同文件？
• 每个 prompt 是否明确禁止区域？
• 每个分支是否有验证命令？
• 开始前是否知道 merge 顺序？
• 是否有一个人负责接受或拒绝 contract 变更？

并行 Codex 工作流强大，是因为它让 Agent 保持狭窄。胜利不是让 Agent 变成自治经理，而是让它们不再互相等待，同时架构仍在你手里。