Codex / Claude Code · 进阶

Claude Code 与 Codex 如何协同完成项目

用任务卡、隔离 worktree 和单一部署者组织 Claude Code 与 Codex;结合 2026 年 8 月的跨会话协作、后台任务和 Codex 插件能力,避免两个 Agent 同时抢改文件。

  • Claude Code
  • Codex
  • 任务卡
  • 协同
更新于 2026-08-13

一句话结论

不要按产品名称固定分配长短任务;根据当前客户端、项目环境和实测结果选一个主执行者,另一个独立复核,中间用任务卡交接。

适用场景

  • 想让 Claude Code 和 Codex 一起完成一个网站、脚本、知识库或自动化项目
  • 两种工具都能做短任务、长任务和多文件工程,但当前客户端、权限、后台并行、恢复与成本体验不同
  • 希望一个 Agent 负责方案和体验,一个 Agent 负责工程落地和验证
  • 项目已经有线上站点或生产服务,不能让两个工具同时乱改

常见现象

  • 两个工具同时开,结果互相改同一批文件
  • Claude Code 说完成了,但没有 build、测试或线上验证
  • Codex 跑很久,却在做 Claude Code 已经做完的内容
  • 交接只写一句继续,下一位 Agent 不知道前面做过什么

原因解释

  • 两个 Agent 都有代码能力,但没有固定角色就会抢同一块工作
  • 模型越强越需要边界:文件范围、验收命令、禁止触碰区域都要写清楚
  • 协同的关键不是让两个模型同时发挥,而是让一个负责判断,一个负责落地,再互相复核
  • 2026 年 5 月案例曾使用 Opus 4.7 和 GPT-5.5;当前应直接从各自客户端选择适合任务且账号可用的模型,流程不依赖固定型号
  • Claude Code 2.1.221—2.1.228 增强了独立 worktree、跨会话 SendMessage、自托管 runner 和同步 Skills 安全,但这些能力不会替你决定文件边界或批准敏感动作

解决步骤

  1. 先定角色:一个工具做本轮主执行,另一个做独立复核。角色按项目环境、当前功能、权限和同类任务实测结果确定,不按产品名称或任务时长固定。
  2. 第一轮只让规划者输出任务卡,不急着大改代码。任务卡必须包含目标、用户、路由、文件范围、不准碰的区域、验收命令。
  3. 把任务卡交给主执行者,要求它先读项目结构,再按文件范围实现,完成后必须运行 build、测试或线上检查。
  4. 主执行者完成后输出四件事:改了哪些文件、验证命令结果、线上或本地地址、剩余风险。
  5. 把主执行者的结果交给另一种工具做独立复核,重点看事实、代码风险、文案、界面一致性和用户路径。
  6. 最后只让一个 Agent 负责部署,另一个只做复核,避免两个 Agent 各自部署不同版本。

可复制命令

# 给 Claude Code 的首轮提示词
你是这个项目的产品和体验负责人。本轮先不要大面积改代码。

项目路径:<填项目路径>
目标用户:<填谁会用>
本轮目标:<填要做成什么>
模型:<从当前客户端选择适合本任务且账号可用的模型>

请先完成:
1. 阅读项目结构、路由、数据源、构建方式。
2. 输出一张任务卡,写清要交给 Codex 的文件范围和验收命令。
3. 标出不准触碰的目录、线上服务、密钥和用户已有改动。
4. 给出小白能看懂的页面文案方向。

输出格式:
- 目标
- 要改的页面/路由
- 建议修改文件
- 禁止触碰区域
- 交给 Codex 的任务
- 验收命令
- 复核重点
# 给 Codex 的执行提示词
你是工程执行负责人。请选择当前客户端中适合本任务且账号可用的模型,不要照抄旧文章型号。

请根据下面这张 Claude Code 任务卡落地实现:
<粘贴 Claude Code 任务卡>

要求:
1. 先完整检查项目结构、路由、数据源和构建脚本。
2. 只修改任务卡允许的文件,不要碰禁止区域。
3. 修改完成后运行验收命令,例如 npm run build / npm run test。
4. 如果是静态站,确认 dist 里对应路由 HTML 能直接搜到核心正文。
5. 如果需要部署,只部署指定项目,不要碰其他站点。

最后输出:
- 改了哪些文件
- 新增/修改了哪些路由
- build/test 是否通过
- 线上或本地验证结果
- 仍然需要 Claude Code 复核的点
# Claude Code 和 Codex 交接卡

## 本轮目标
<一句话写清楚>

## 已完成
- <文件/页面/功能>

## 已验证
- 命令:<npm run build 等>
- 结果:<通过/失败>
- 地址:<本地或线上 URL>

## 禁止触碰
- <生产服务、密钥、无关项目、用户已有改动>

## 下一位 Agent 要做
1. <继续项 1>
2. <继续项 2>

## 风险
- <还有什么不确定>
# 在 Claude Code 里安装 OpenAI Codex 插件
/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

# 常用命令
/codex:review --background
/codex:adversarial-review --background 检查这个实现有没有隐藏风险
/codex:rescue --background 修复当前失败的测试
/codex:status
/codex:result
/codex:cancel

# 需要把当前 Claude Code 上下文继续交给 Codex 时再用
/codex:transfer
# 可选 hook:它会把当前 commit 内容发送给你配置的 Codex provider,并产生网络传输与用量费用。
# 先运行 codex review --help 确认支持 --commit,并确认仓库内容允许发送给该 provider。
# 安装后默认不启用;明确同意后才运行:git config --local agent.codexReview true
cat > .git/hooks/post-commit <<'EOF'
#!/usr/bin/env bash
set -u
[ "$(git config --bool --get agent.codexReview 2>/dev/null || true)" = true ] || exit 0
umask 077
review_dir="$(git rev-parse --git-path agent-reviews)"
mkdir -p "$review_dir"
chmod 700 "$review_dir"
output="$(mktemp "$review_dir/codex-review.XXXXXX.md")"
if ! codex review --commit HEAD > "$output" 2>&1; then
  printf '%s\n' "Codex review failed; inspect $output" >&2
else
  printf '%s\n' "Codex review saved to $output"
fi
EOF
chmod 700 .git/hooks/post-commit

# 只有在你明确接受出站传输、provider 数据政策和费用后才启用:
# git config --local agent.codexReview true
# AGENTS.md(两边共享的核心规则)

## 项目目标
这个项目要服务谁、解决什么问题。

## 常用命令
- 构建:npm run build
- 本地预览:npm run preview

## 禁止触碰
- 不要打印 token
- 不要改生产数据库
- 不要回滚用户已有改动

## 验收标准
- build 通过
- 关键路由能访问
- 主要正文能在 HTML 源码中搜到

# CLAUDE.md(Claude Code 专属薄壳)
@AGENTS.md

## Claude Code 专属
- 先做体验复核和任务拆分。
- 大范围修改交给 Codex 前,先输出任务卡。

仍然不行怎么办

  • 如果两个工具都在改同一批文件,先停一个,只让 Codex 做工程合并,Claude Code 做阅读复核。
  • 如果 Claude Code 和 Codex 给出相反方案,按真实验收命令和线上结果决定,不按谁说得更像专家决定。
  • 如果模型名在你的客户端里不可选,用同等级的最强代码模型替换,角色分工和交接方式不变。
  • 如果项目涉及生产部署、密钥、数据库或付费接口,先让一个 Agent 写风险清单,再决定是否执行。

2026 年 8 月新增的协同能力

  • Claude Code 2.1.221 的 `/fork` 会为分叉会话创建独立 worktree;2.1.222 又补上了主工作树隔离,适合并行任务,但开始前仍要核对分支、未提交改动和允许修改的目录。
  • Claude Code 2.1.224 在 macOS 和 Linux 加入跨会话 `SendMessage` 与 `ListAgents`;消息发送仍受权限判断,不能把另一会话的消息当成人工授权。
  • Team / Enterprise 可用 `claude self-hosted-runner` 把自有机器或容器接给 Web、移动端和桌面会话;这是受套餐和组织策略约束的部署能力,不是个人版默认功能。
  • Claude Code 2.1.224 支持从 HTTPS zip 安装插件并可固定 SHA-256;只有来源可信、哈希固定、内容已审阅时才使用归档安装。
  • Claude Code 2.1.228 加固了从 claude.ai 同步的 Skills:不允许覆盖本地命令或 MCP prompt,也不会在本机执行 `!` 命令或展开 `@` 文件;本地与第三方 Skill 仍需独立审查。
  • OpenAI 的 `codex-plugin-cc` 仍是 Claude Code 内调用 Codex 的专用插件;Codex 自己的官方 Plugins 是另一套分发机制,两者不要混为同一个安装入口。

推荐分工

  • Claude Code 和 Codex 都可以承担需求理解、跨文件实现、构建测试与长任务;先核对当前版本、账号和运行环境实际提供的功能。
  • 需要交互、后台会话、多 Agent、工作树、桌面操作或云端执行时,分别检查当前客户端是否支持,并用小任务验证,不按旧印象判断。
  • 主执行者负责改动与验证,另一种工具负责只读复核;下一轮可以交换角色,比较哪种组合更稳定、更省成本。
  • 真正稳的是任务卡、权限边界、单一部署者和可复现验收,不是固定指定哪家只能做规划或只能做工程。
  • 如果安装了 openai/codex-plugin-cc,可以让 Claude Code 直接调用 Codex 做 review、adversarial review 和 rescue;如果你主用 Codex,也可以用类似 cc-plugin-codex 的反向方案让 Claude Code 做 review。

外部社区里最常见的 6 个共识

  • 插件路线正在成型:OpenAI 的 codex-plugin-cc 已经把 Codex review、adversarial-review、rescue、status、result 这类动作放进 Claude Code 工作流里。
  • 反向路线也有人做:在 Codex 里调用 Claude Code 做 review / rescue,适合主工作台是 Codex、但想借 Claude 复核的用户。
  • 共享规则文件很关键:AGENTS.md 放通用规则,CLAUDE.md 第一行引用 @AGENTS.md,再放 Claude Code 专属规则,可以减少两套文件漂移。
  • Git hook / Claude hook 是轻量联动:提交后自动跑 Codex review,把结果写到临时文件或 review 文件,让 Claude Code 下一步先读。
  • 长任务要用 manager-worker:一个工具当监工,另一个工具按 TODO 一轮一轮做;每轮新 session,避免上下文爆掉。
  • 多 Agent 不是越多越好:社区反馈里最稳的做法通常是一个主任务文件、一个共享规则文件、一个执行者、一个复核者。

三种可选协同架构

  • 插件架构:Claude Code 是主界面,Codex 通过 /codex:review、/codex:rescue 进入。适合你已经习惯 Claude Code,但希望 Codex 做第二意见和后台修复。
  • 双终端架构:Claude Code 和 Codex 各开一个终端,共享 AGENTS.md、CLAUDE.md、PLAN.md、TODO.md。适合中小项目,最容易排错。
  • 监工架构:一个工具负责启动和观察另一个 CLI,让主执行者每次完成 TODO 里的下一项并写回进度;两者角色可互换,长任务必须有清晰 TODO、停止条件和人工检查点。
  • 反向复核架构:Codex 是主执行者,Claude Code 通过插件或手动命令做设计挑战、边界检查、UI 文案复核。适合 Codex 跑得更顺的工程项目。

一次完整协作流程

  1. 人先写一句目标:我要做什么页面、工具、Bot 或自动化。
  2. 规划者用当前账号可用且适合任务的模型读项目,输出任务卡和验收标准。
  3. 人确认任务卡,删掉不该碰的范围。
  4. 主执行者用当前账号可用且适合任务的模型按任务卡执行,完成后运行 build/test。
  5. 复核者检查主执行者的 diff、事实、界面文案和用户路径。
  6. 人确认后由预先指定的唯一部署者或固定部署工具上线。
  7. 上线后把结果写入 Obsidian 或项目记忆,下一轮继续。

长任务监工模式

  1. 让本轮主执行者先生成 TODO.md,把任务切成 30-60 分钟能完成的小块。
  2. 在 AGENTS.md 里写清:看到 continue 时必须先读 TODO.md,完成一项后更新 TODO.md 和 progress.md。
  3. 复核者只负责观察主执行者是否完成;如果采用 Claude Code 调 Codex,可运行 codex exec "continue to next task",但不要同时改同一批文件。
  4. 主执行者每轮结束必须写三件事:完成了哪项、改了哪些文件、下一项是什么。
  5. 复核者每轮只读摘要,不读完整日志,避免上下文被执行输出撑爆。
  6. 连续失败两轮就停下来让人看,不要无限自动重试。

什么时候用 review,什么时候用 rescue

  • review:只看不改,适合 Claude Code 刚完成一批修改后,请 Codex 独立检查 bug、遗漏测试、风险点。
  • adversarial-review:专门挑战方案,适合数据库迁移、鉴权、计费、部署、缓存、并发这类高风险改动。
  • rescue:允许 Codex 尝试修复,适合测试失败、类型报错、构建失败、回归 bug。
  • status / result:后台任务必须用这两个命令收尾,避免你以为它完成了,其实只是开始跑。

不要这样协同

  • 不要同时让两个 Agent 改同一个文件夹,尤其是 styles.css、data.ts、路由入口这类中心文件。
  • 不要让 Claude Code 直接接着 Codex 的一句完成继续做,必须先给它变更清单和验证结果。
  • 不要让两个 Agent 都去部署,线上只认最后一次部署,很容易覆盖掉刚刚验证过的版本。
  • 不要把 token、密码、生产数据库连接串贴给两个 Agent;用环境变量和脱敏日志。
  • 不要把 CLAUDE.md 和 AGENTS.md 写成两份完全不同的长文。越长越容易漂移,越难知道哪个规则正在生效。
  • 不要一上来开启 review gate 或自动钩子循环。它们很有用,但也可能烧额度、卡住会话或形成 Claude/Codex 来回互相改的循环。

验收清单

  • 项目目标是否已经变成用户能点击、能看到、能复制的页面或功能。
  • 规划者是否留下清楚任务卡,主执行者是否按任务卡执行。
  • 主执行者是否运行了 build/test,并把结果写清楚。
  • 复核者是否检查了事实、体验、文案、视觉和小白可读性。
  • 线上页面、sitemap、robots 或关键 API 是否已经验证。
  • 是否写入 Obsidian 或项目记忆,方便下一次 Agent 接续。

参考来源

相关问题

还卡着?

仅把删除凭证、客户数据和环境变量值后的必要截图、日志片段、需求说明或当前页面链接发到 zhemuy@gmail.com。