Claude Code 与 Codex 同仓协作的常见坑

Claude Code 写代码、Codex 做审查，听起来只要开两个终端。真正麻烦的是：上下文怎么传、文件会不会互相覆盖、审查针对哪个提交、出问题由谁继续处理。原文作者给出的答案，是用自己开发的开源工具 Quorus，把这些协作杂务自动化。

这篇值得看的是它列出的具体故障，以及没有回避的限制：独立 worktree 能隔离改动，却不能限制代理权限；交叉审查可以发现问题，但 Quorus 当前并不等审查通过才发布代码。

两个代理为什么经常只干出一个人的活

原文把手工协作分成三种。

第一种是在 Claude Code 中通过 codex exec ... 调用 Codex，或者反过来用 claude -p ... 调用 Claude。如果调用会阻塞，外层代理只能等待，得到的是两份意见，实际仍然串行。

每次无界面调用还会开启新会话。内层代理能读仓库和指令文件，却不会自动知道外层对话里的计划、失败尝试和取舍。这些上下文需要显式传递。

连传 diff 都有坑：普通 git diff 不包含未跟踪文件。原文提醒先执行 git add -N .，否则审查者可能根本看不到新增文件。

第二种是一写一审，由人复制计划、diff 和审查意见。作者引用 Rashid 的记录：每周六次交接，每次约 11 分钟，大约花掉一小时。对方还发现，手工同步的 CLAUDE.md 与 AGENTS.md 在「一周内」就出现偏差。两个代理共用 checkout，则让 git status 变得难以辨认。

这些是被引用的个人记录，不是普遍适用的效率测量。但它们指出了一个实际问题：代理增加以后，人可能从写代码变成了搬消息。

独立 worktree 解决文件冲突，谁来处理剩下的杂务

第三种方案是每个代理使用独立的 Git worktree 和分支。可以把它理解为：共用仓库历史，各自在不同工作目录里改代码。

方向合理，使用细节却不能忽略：

• 同一个分支不能同时被两个 worktree 检出。
• 新 worktree 不会自动带上被忽略的 .env 和 node_modules。
• git stash 是共享的，不是各目录独立。
• git worktree remove --force 会丢弃未提交改动，直接 rm -rf 又会留下注册记录。

Quorus 在这个方案上加了房间和消息中继，负责创建、维护 worktree，并让代理在后台等待点名。

下面这组命令把 Claude Code 和 Codex 加入同一房间、连接同一仓库：

pipx install quorus-ai
quorus            # 首次运行：选一个名字，按 Enter；在本机启动中继
quorus agent add claude --room general --repo ~/code/my-app --mode autonomous
quorus agent add codex  --room general --repo ~/code/my-app --mode autonomous
quorus chat general

要特别看两条注册命令里的 --mode autonomous：它涉及自主执行权限，不只是后台运行。

随后可以在房间发送 @<you>-claude fix the crash in split() with tests, then have <you>-codex review it。代理完成后，Quorus 把分支发布回仓库，并在房间通知；审查者针对具体 commit 检查，给出 /vote approve <sha> 或阻断性意见。

用户还能看到代理正在编辑什么、持续多久，并在完成、提问或卡住时收到桌面通知。只有用户本人及其代理可以让代理修改代码，其他房间成员的消息只触发只读处理。

但审查结论到达时，代码已经发布回仓库。

阻断性意见会成为构建代理的下一项任务，或者由用户回退。这里的「阻断」并不等于合并前的质量闸门。

另一个边界是权限。Quorus 不为自主代理提供沙箱；原文明确指出，Claude Code 和 opencode 在该模式下使用当前用户权限运行。独立工作目录隔离了文件修改位置，不能据此推断代理只能访问该目录。

提交统计能回答谁更可靠吗

quorus scorecard 按代理和厂商统计提交的去向：保留、回退，或被审查标记。作者在自己项目的公开历史上运行同一套统计代码，给出了截至 v0.6.5 的结果：

• 公开 main 共 544 个提交。
• 332 个提交能通过发布时记录的 notes 归因到代理。
• 另外 212 个没有归因信息，未作猜测。
• 已归因提交中检测到三次显式回退。

作者称，全新 clone 可以逐字节重建统计结果。但可复算不代表能据此给模型排名。任务分配不均、代理参与开发统计工具，以及发布时的 cherry-pick，都影响结果。没有进入 main 的失败工作，也无法从这份历史中完整观察。

跨模型审查同样只是策略。原文认为，代理自审容易重复写代码时的盲点，却没有提供 Claude Code 与 Codex 交叉审查的对照收益。

想体验流程，可以运行：

pipx install quorus-ai
quorus demo

这里要留意第二行：它启动的是临时仓库中的演示，由两个代理修复预置 bug 并审查。默认需要 opencode 2.x，可用 brew install opencode 安装；如果缺少 opencode，或免费模型全部繁忙，会回退到已登录的 Claude Code 或 Codex，消耗相应额度。

作者报告，两次使用干净 HOME 的 0.6.5 测试中，从演示发出消息到修复进入 main，分别用了 39 s 和 51 s。安装及演示自身的准备检查不计入时间，因此这两个数字不能当作日常开发提速幅度。

我的判断

我认同先处理协作机制：明确工作目录、提交身份和消息交接，比直接增加代理数量更有价值。Quorus 的具体价值，是接管了一部分原本由人完成的调度工作。

不过，传统的独立分支加 PR 审查，可以把人工批准或 CI 检查放在合并前；Quorus 文中描述的流程则先发布，再处理审查结果。团队若依赖合并前审批，就还需要补充约束。

统计部分的表述也比较克制。三次显式回退不能证明其余提交都正确，39 s 和 51 s 不能证明复杂任务也快。作者没有给出与双终端方案的系统对照，节省多少时间仍是经验判断。此外，新 worktree 的 .env、依赖安装具体如何处理，原文没有说清。

能拿来做什么

• 在前端或 Node 仓库中尝试双代理前，先统一 CLAUDE.md 与 AGENTS.md 的规则来源，检查新工作目录的环境文件和依赖是否齐备。
• 把审查任务绑定到具体 commit SHA，并补充任务目标、约束和验证结果；如果传递 diff，先确认新增文件已包含在内。
• 如果团队要求审查通过才能进入共享分支，就保留 PR 与 CI 门禁，先确认 Quorus 的发布流程如何接入。
• 先用 quorus demo 观察交接过程，并留意额度回退；后续用自己仓库的 scorecard 追踪返工线索，不急着把它变成模型排行榜。