如何让 Claude Code 和 OpenAI Codex 组成一个团队协同工作

让擅长规划和审查的一方，搭配出手快的实现者，让它们直接对话，你也不用再做两个终端窗口之间的“复制粘贴层”。本文讲清楚这种搭配为什么有效，以及具体怎么搭建。

作者 Team Agent 工程团队 发布于 阅读约 7 分钟
要点速览
  • 只要各自运行在独立终端、分工明确，Claude Code 和 OpenAI Codex 完全可以同时在一个仓库里工作。
  • 一种流行的分工是 Claude Code 负责规划和审查，Codex 负责实现。由另一个模型来审查代码，能发现作者模型自己反复忽略的问题。
  • Team Agent 用你现有的登录状态在 tmux 中启动这两个 CLI，在它们之间转发消息；关掉终端或重启机器后，还能把团队原样拉回来。
  • 搭建只需三步：npx @team-agent/installer@latest install、team-agent claude，然后用大白话让它组队。

01为什么要让 Claude Code 和 Codex 一起干活？

大多数开发者都是从“一个 AI 编程 Agent + 一个终端”起步的。任务一大，等待就成了常态：它写后端时，前端在等；它跑测试时，你在等。再加一个 Agent 是最直接的解法，而把两款不同的产品搭配起来，好处远不止并行这么简单。

  • 各取所长，人尽其才。很多团队用 Claude Code 做规划、架构讨论、测试设计和代码审查，用 Codex 快速实现边界清晰的任务。每个模型只做自己最擅长的事，而不是让一个模型包打天下。
  • 真正的“第二意见”。模型审查自己写的代码，往往会放过自己的盲区。让 Claude Code 审查 Codex 写的代码（反过来也一样），审查者不带作者的先入之见，能揪出更多真问题。
  • 把已付费的订阅用足。如果你同时有 Anthropic 和 OpenAI 的套餐，让两者并排干活，两份额度能同时为你工作，而不是闲置一份。
  • 真正的并行。API 接口、前端页面、测试用例这类彼此独立的任务，可以同时推进。

02手动协调会遇到什么问题

你当然可以开两个终端，一个跑 claude、一个跑 codex，自己居中协调。但大多数人试不到一天，就会撞上同样几堵墙：

  • 你成了人肉消息总线。每一份方案、API 定义、报错日志和审查意见，都得从一个窗口复制到另一个窗口。
  • 上下文说没就没。合上笔记本、SSH 断开或者重启机器，两个会话一起消失。第二天早上，项目背景又得重讲一遍。
  • 没人对整体负责。每个 Agent 只看到自己那一块。集成、先后顺序（“API 没好之前别开始写测试”）和最终审查，全都落回你头上。

你真正需要的是：一位你只管和它对话的组长 Agent，一群能接任务、彼此直接沟通的队员，再加上一个让它们始终在线的机制。这正是 Team Agent 做的事。

03准备工作

  • macOS（Apple 芯片或 Intel）或 Linux x64，Windows 可通过 WSL 使用。
  • Node.js 18 或更高版本，仅用于一次性安装。
  • tmux。不需要你会用 tmux，Team Agent 会替你操作。
  • 已安装并登录的 Claude Code 和 OpenAI Codex CLI。先确认 claude 和 codex 在终端里都能正常启动。
无需 API Key

Team Agent 从 PATH 调用官方 CLI，沿用你平时的配置，所以每个 CLI 当前登录的是哪个订阅或账号，用的就是哪个。只有当你主动挂接基于 API 的配置档时，才需要 API Key。

04分步搭建

第 1 步：安装 Team Agent

npx @team-agent/installer@latest install
team-agent --version

安装器会为你的平台放置一个原生的 team-agent 二进制。不需要启用任何服务，命令结束后也没有任何东西留在后台运行。

第 2 步：把 Claude Code 作为组长启动

在项目根目录打开终端，运行：

team-agent claude

这就是你熟悉的 Claude Code：界面、模型、工具都一样。区别在于，这个对话现在是团队的组长，可以拉起并协调队员。更习惯用 Codex 当组长？改成 team-agent codex 即可。

第 3 步：用大白话让它组队

直接告诉组长你想要什么，比如：

这活儿一个 Agent 忙不过来，帮我组个团队：
- backend：用 Codex，负责实现 /v1/invoices 接口
- reviewer：用 Claude，审查每一处改动的 bug 和缺失的测试
先给我看方案。

组长会先提出角色方案。在启动任何队员之前，它会就每名队员和你确认两件事：用哪个 CLI，以及是否允许跳过权限确认。Team Agent 从不擅自替你做这两个决定。你确认之后，它会写好团队文件，并在各自的 tmux 窗格中启动每名队员。

第 4 步（可选）：自己定义团队

如果你更喜欢可以提交、可以评审的配置文件，也可以直接手写。一个团队就是一个目录，里面有一份 TEAM.md，再加上每个角色一个 Markdown 文件，文件名就是队员的名字。

.team/current/
  TEAM.md
  agents/
    backend.md
    reviewer.md

TEAM.md 描述目标：

---
name: billing-api
objective: 交付带测试、并经过审查的 /v1/invoices 接口
---
组长负责规划和集成，backend 负责实现，
reviewer 在每次合并前审查所有改动。

agents/backend.md 运行在 Codex 上：

---
provider: codex
dangerously_skip_permissions: false
---
你负责在这个仓库里实现后端功能。
保持改动小而聚焦，汇报前先跑一遍测试，
每次汇报都列出你改过的文件。

agents/reviewer.md 运行在 Claude Code 上：

---
provider: claude
dangerously_skip_permissions: false
---
审查每一处改动的正确性、安全性和测试覆盖。
按严重程度列出具体问题。
不要自己修改产品代码。

然后在组长所在的终端里启动团队：

team-agent start --from .team/current

你还可以在角色文件的头部设置 model 和 effort。用 team-agent models --provider codex 可以列出本机 CLI 支持的准确模型名。

第 5 步：派活和查看结果

大多数时候，你只需要继续和组长对话，由它替你派活。你也可以在任意终端里直接指挥团队：

team-agent send backend "给 GET /v1/invoices 加上分页，并补上测试"
team-agent status
team-agent inbox leader -n 3

status 会列出每名队员的供应商、活动状态和健康状况，inbox 显示最新的回复。消息发出去不等于任务完成：队员做完会主动汇报，再由组长汇总。

第 6 步：今天收工，明天接着干

team-agent stop        # 收工：停止团队，保留已保存的会话
team-agent start       # 第二天：同一批队员，同样的上下文

每个 Agent 都运行在 tmux 里，所以关掉终端或 SSH 断线都不会让团队停下。机器重启后，team-agent start 会把团队拉回来；只要 CLI 支持，每个 Agent 的对话都会接着恢复。

05推荐的分工方式

没有放之四海而皆准的答案，但下面几种组合都是不错的起点：

团队形态组长队员适用场景
实现 + 审查Claude CodeCodex（backend）、Claude（reviewer）带质量关卡的日常功能开发
并行功能小组Claude CodeCodex（后端）、Codex（前端）、Claude 或 Pi（测试）按层拆分的全栈功能
Codex 主导CodexCodex（实现）、Claude（架构与审查）想要设计和审查搭档的 Codex 用户
开发、测试、修复闭环Claude CodeCodex（开发）、Claude（测试）由测试者持续反馈、直到全部通过的修 bug 场景

队员也不限于写代码。有人用同样的方式做多位审稿人交叉评审论文、多角色头脑风暴，或者组建调研小组。

06让 Claude + Codex 团队更高效的几条经验

  1. 一个功能方向，一位组长。每个功能方向只对应一个组长对话，由它决定怎么拆分、怎么集成，你始终坐在产品负责人的位置上。
  2. 把审查定成规矩，而不是看心情。在 TEAM.md 里写明“所有改动必须经过 reviewer”，组长会严格执行。
  3. 让队员直接沟通。前端可以直接问后端接口长什么样，不必经过你。节省下来的时间，大多来自这里。
  4. 任务要小，并且可验证。“加上分页并补测试”远比“优化一下 API”好用。测试是两个 Agent 都认的客观裁判。
  5. 想清楚再决定权限。跳过权限确认能让无人值守的工作更顺畅，但也给了 Agent 更大的执行权限。不跳过也不等于沙箱，它只是保留每个 CLI 原生的确认行为。
  6. 不用盯着每个窗格。想看或想插手时，窗格随时都在；汇报会自动回到组长的对话里。

07排查问题

觉得哪里不对劲时，先运行内置的健康检查：

team-agent doctor --workspace .

一切正常时它只输出一行。出了问题时，它会给出一份简短报告，停在第一个失败的环节，并给出一条修复命令。常见情况：

  • 某个队员没有回应。先看 team-agent status。如果它的 CLI 已经退出，team-agent start backend 只会重启这一名队员，不影响其他人。
  • 长时间运行后某个队员“犯迷糊”了。单独重置这一个 Agent、给它一个全新的上下文，其他队员照常工作（参见 team-agent agent --help）。
  • CLI 没有登录。Team Agent 从不替你登录。先单独启动一次 claude 或 codex 完成登录，再重新启动团队。

08常见问题

Claude Code 和 OpenAI Codex 能同时在一个项目上工作吗？

可以。让两个 CLI 各自运行在独立的终端会话里，并分别承担不同角色，比如一个负责实现、一个负责审查。借助 Team Agent 这样的协调工具，两者都在 tmux 中启动，任务和消息由它在中间转发、结果由它汇总，既不会互相覆盖，也不需要你手动搬运上下文。

同时使用 Claude Code 和 Codex 需要 API Key 吗？

不需要。Team Agent 运行的是官方 Claude Code 和 Codex CLI，沿用你现有的账号或订阅登录。只有当你主动挂接基于 API 的配置档时，才需要 API Key。

组长应该用 Claude Code 还是 Codex？

两种都可以。常见做法是让 Claude Code 当组长，因为它擅长规划、权衡方案和代码审查，再由 Codex 队员专注实现。你也可以让 Codex 当组长，把 Claude Code 安排为审查者。

怎样让团队过夜或在重启后继续运行？

每个 Agent 都运行在 tmux 中，关掉终端不会让它停下。收工时执行 team-agent stop，第二天执行 team-agent start 即可拉回同一支团队；只要 Agent CLI 支持，已保存的对话都会恢复。

延伸阅读
架构本地 AI Agent 需要进程监管，而不是笨重的后台守护进程 工程实践终端 AI Agent 之间如何可靠通信