Orca 怎么并行运行 Codex 和 Claude Code：Worktree、任务比较与手机审批

同一个 bug 或功能，交给 Codex 和 Claude Code 各做一遍，常常比让一个 Agent 无限重试更快发现盲点。但真正难的是控制过程：两份改动不能互相覆盖，结果要能比较，人在离开电脑时也要能知道任务何时完成、该不该继续。Orca 把多个终端 Agent 放在独立 Git worktree 中运行，并在同一处追踪会话、diff 和任务状态。Orca 官方仓库

本文把重点放在“比较后再审批”：并行运行不是自动合并；手机端也不是替代代码审查，而是让你及时查看进度、发送追问并决定哪些结果值得回到电脑前仔细审阅。

先建立正确边界：并行执行，不等于自动采纳

Orca 可以将 Codex、Claude Code 以及其他终端 Agent 并排运行，每个 Agent 使用自己的 Git worktree。官方 README 的工作方式是把同一提示分给多个 Agent，在隔离工作树中完成后比较结果，再合并胜出的方案。

因此整个流程应分成三层：

阶段	由谁完成	产物
执行	Codex / Claude Code	独立分支、diff、测试输出、说明
比较	Orca + 人工审阅	方案差异、风险点、候选结论
审批与合并	人工	被采纳的提交、必要的补充修改

不要把“两个 Agent 都说完成”当成审批通过。尤其是权限、数据库迁移、依赖升级和删除文件，必须在合并前审查实际 diff。

任务怎么拆，比较才有意义

如果两个 Agent 收到完全模糊的“修复登录问题”，最终往往得到了两份无法横向比较的大改动。应给每个任务统一验收基线，再让策略不同：

1
2
3
4


共同条件：复现登录 token 过期后的重试失败；必须通过现有登录测试；不改 API 协议。

Codex：从请求重试链路定位根因，提交最小修复，并说明为何不会影响刷新逻辑。
Claude Code：先写失败复现与回归测试，再提出最小修复；不改无关认证模块。

比较时只看四个问题：

哪个方案真正复现并覆盖了问题？
哪个 diff 更小、边界更清楚？
哪个测试命令实际运行过，输出是否可重现？
哪个方案引入的依赖、权限或回归风险更低？

这样 Codex 和 Claude Code 的差异成为可衡量的工程选择，而不是比较谁写的说明更有说服力。

Worktree 让两份候选改动不互相污染

Git worktree 让同一仓库的不同分支拥有不同工作目录。Orca 在每个隔离工作树中运行 Agent，因此 A 的格式化、依赖安装或文件删除不会直接改到 B 的目录，也不会直接污染你的主目录。

开始前仍建议把主工作区整理干净：

1
2
3
4


git status
git fetch --all --prune
git switch main
git pull --ff-only

再为候选方案使用可读的分支名：

1
2
3


agent/login-fix-codex
agent/login-fix-claude
agent/login-tests

隔离并不能消除合并冲突：如果两个方案最终都修改同一个认证文件，合并仍需选择一个主方案，或从另一个方案挑选独立测试提交。不要把多个候选分支一次性 merge 到 main。

在 Orca 中启动两个 Agent 的实用顺序

具体按钮随版本变化，但下面的顺序不会变：

在 Orca 中打开 Git 仓库，确认基线分支和当前未提交改动。
为 Codex 与 Claude Code 分别创建/选择独立 worktree。
复制共同验收条件，再写出各自不同的子任务与禁止范围。
要求 Agent 在结束时列出修改文件、执行的测试、未验证假设和建议的提交说明。
完成后先读 diff 和测试输出，再决定是否让其中一个继续修正。

Orca 还支持从 GitHub、Linear 的任务打开 worktree，以及在 diff 行上留下评论回传给 Agent。把评论写成可执行反馈，例如“只保留测试，撤回依赖升级”或“解释此处缓存失效顺序”，比笼统说“再改好一点”有效。

如何在手机上做“审批”

Orca 的 Mobile Companion 用于在手机上监控和引导 Agent：完成时接收通知，并可从任意位置发送 follow-up。它支持 iOS 和 Android 配套应用，需与桌面端配对。

这里的“手机审批”应该理解为任务级决策，不是在手机上盲目完成 Git 合并：

1
2
3
4


通知到达
  → 查看 Agent 的完成摘要、测试状态和风险提示
  → 决定：追问 / 让它补测试 / 停止另一个候选 / 标记为待电脑审阅
  → 回到桌面端查看完整 diff、运行关键测试、再合并

适合在手机上做的操作包括：让 Agent 解释失败测试、要求缩小改动范围、补一个回归用例、或停止明显偏题的任务。不适合只凭通知摘要批准数据库迁移、生产配置、权限修改或大范围重构。

一份可复用的比较与审批清单

当两个 Agent 都完成时，按此顺序处理：

1
2
3
4
5
6
7


[ ] 两个方案是否都基于同一基线分支？
[ ] 是否都列出了修改文件和运行过的测试？
[ ] 是否有一个方案引入了无关依赖或大范围格式化？
[ ] 是否存在同一文件的竞争修改？
[ ] 主方案能否独立通过测试？
[ ] 次方案中是否有可单独挑选的测试、注释或修复？
[ ] 是否已在桌面端审查完整 diff，再执行 merge？

合并前可以在主工作树比较候选：

1
2
3


git diff main...agent/login-fix-codex
git diff main...agent/login-fix-claude
git log --oneline main..agent/login-fix-codex

确认后只合并被采纳的分支，或用 git cherry-pick 选择单独提交。保留未采纳 worktree 到验证结束，再清理，方便在回归时找回另一份思路。

常见问题

Codex 和 Claude Code 可以同时修改同一个文件吗？

可以，因为它们在不同 worktree。但这只是避免运行时互相覆盖，不会自动解决合并时的逻辑冲突。最好指定一个主实现 Agent，另一个负责测试、审阅或备选方案。

手机上看到“完成”就能合并吗？

不应如此。手机适合接收通知和发送追问；完整 diff、实际测试、敏感配置和合并决策仍应在可信的桌面环境完成。

为什么两个 Agent 的结果都不满意？

通常是任务边界或验收条件不够具体。先让其中一个 Agent 只做代码阅读，列出根因假设与最小影响文件；确认方向后再启动并行实现，成本会更低。

小结

Orca 让 Codex 和 Claude Code 在隔离 worktree 中并行执行，真正的收益来自随后可比较的 diff、测试和风险说明。手机伴侣应用适合把“收到通知—追问—决定下一步”提前完成，但不替代人工的完整审查与 Git 合并。把执行、比较、审批分开，才不会因为多 Agent 并行而放大代码风险。