多个 Claude Code 与多个 Codex 协同工作：设计与实现方案

摘要：本文系统梳理了如何用多个 Claude Code 与多个 Codex 并行协同完成中大型工程编码任务。从单 Agent 的三大瓶颈出发，对比两类 Agent 的可编排接口（无头模式、SDK、MCP、Hooks、worktree、权限），盘点 Orchestrator-Worker、Blackboard、Pipeline 等五种主流编排模式与 Claude Squad、Vibe Kanban、Conductor、Terragon 四类工具生态，最终给出一套 Orchestrator → Worker Pool → git worktree 隔离 → Blackboard 共享 → Integration Layer 合并的五层端到端架构，并结合 CoDA-Bench 成本数据（Claude Code $0.11/task vs Codex$ 1.39/task）说明如何通过异构路由把成本降下来、把完成率提上去。全文强调：编排代码好写，治理才是深水区。

TL;DR

多 Agent 编排的核心矛盾是隔离与协调的三角取舍：并行加速来自物理隔离（git worktree），但隔离越深，合并成本与上下文碎片化越高------架构设计本质上是在这条曲线上选工作点。
Claude Code 与 Codex 已具备完整的程序化编排接口 ：前者通过 -p 无头模式 + Agent SDK + git worktree 原生支持并行；后者通过 codex exec --quiet + TypeScript SDK + Cloud 委托 + MCP Server 暴露能力------两者可混合部署。
推荐架构为 Orchestrator → Worker Pool → git worktree 隔离 → Blackboard 共享 → Integration Layer 合并 ，在 CoDA-Bench 中 Claude Code 单任务成本 $0.11、Codex$ 1.39，混合编排可按任务复杂度动态路由以优化性价比 $1$ 。
落地关键不在于写编排代码，而在于治理：Token 熔断、文件锁、冲突 re-dispatch、最小特权沙箱------缺少任何一层都会导致成本失控或代码污染。

一、为何需要多 Agent 协同

1.1 单 Agent 编码的瓶颈

单个 AI 编码 Agent（无论是 Claude Code 还是 Codex）在处理中大型工程任务时面临三个结构性限制：

上下文窗口饱和。一个 Agent 在深入理解模块 A 时，无法同时对模块 B 保持同等精度的上下文覆盖。当仓库规模超过数万行时，单次会话的有效产出递减。

串行执行的时间墙。即使 Agent 编码速度远快于人类，一个 session 内仍是线性执行------先分析需求、再生成代码、再运行测试、再修复 bug。10 个子任务串行完成的墙钟时间约为并行执行的 5-10 倍。

单点失败放大。一个 Agent 在第 3 步犯错可能污染后续全部步骤的上下文，而不同 Agent 各自隔离运行时，一个失败不影响其他已完成的工作。

1.2 并行带来的价值与新问题

多 Agent 并行的核心收益是时间压缩 和能力互补 。Anthropic 自身的多智能体研究系统已经采用编排者-工作者模式，由主代理将查询分解为子任务并委派给并行运行的子代理 $2$ 。

但并行引入了三类新开销：

协调开销：谁做什么、做到哪了、下一步是谁------需要一个编排层承担调度与状态追踪。
合并开销：多个 Agent 各自改了代码，最终合入一个仓库时可能产生冲突------需要隔离策略和集成层。
上下文碎片化：Agent A 做的决定可能影响 Agent B 的实现------需要共享黑板机制。

Synthesis：这三类开销构成了多 Agent 系统设计的核心张力：隔离越深越安全，但通信与合并成本越高。后续章节的架构设计本质上是在这条取舍曲线上寻找工程最优解。

二、两类 Agent 的可编排能力

2.1 能力对比总览

Claude Code 和 Codex 各自暴露了不同但互补的程序化接口。下表按编排系统关心的六个维度对比核心差异：

能力维度	Claude Code	OpenAI Codex
无头模式	`-p` / `--print` 标志，支持 `--output-format json	stream-json` 输出结构化数据 $3$ $4$
SDK / 编程接口	Claude Agent SDK（原 Claude Code SDK），支持 Python 和 TypeScript $6$	`@openai/codex-sdk` TypeScript SDK，通过 `runStreamed()` 订阅工具调用与文件变更 $7$
子智能体 / 多 Agent	原生 Subagents（同会话内委派）+ Agent Teams（跨实例协作），通过 `--agents` JSON 配置 $8$ $9$	OpenAI Agents SDK 提供 Handoffs（对等授权）和 Manager Pattern（层级编排） $10$
MCP / 工具总线	作为 MCP Client 消费外部工具；Hooks 机制在 PreToolUse/PostToolUse/Stop 等生命周期事件注入逻辑 $11$	`codex mcp-server` 模式将自身能力暴露为 MCP Server，供其他 Agent 调用 $12$
代码隔离	原生 `--worktree` / `-w` 标志，一键创建隔离目录并启动会话 $13$	Codex Cloud 在云端沙箱执行，本地通过 `codex cloud exec` 委托后拉回 diff $14$
权限 / 自动化	`--dangerously-skip-permissions` 跳过全部确认；受保护目录 `.git/` 仍触发提示 $15$ $16$	v0.128 后推荐 Permission Profiles 替代 `--full-auto` $17$ ；`--yolo` 强制绕过沙箱 $18$

2.2 关键差异的编排含义

Claude Code 的优势在于本地 worktree 原生集成 。编排系统只需调用 claude -p --worktree --output-format stream-json，即可得到一个隔离运行、结构化输出的 Worker 进程，无需额外基础设施 $13$ 。

Codex 的差异化能力是 MCP Server 模式与 Cloud 委托 。codex mcp-server 让 Codex 从"被编排的 Worker"翻转为"向其他 Agent 暴露能力的 Tool Provider" $12$ ；Codex Cloud 则把计算卸载到远端沙箱，适合计算密集型或需要特定环境的任务 $14$ 。

混合部署的经济动机 ：CoDA-Bench 数据显示 Claude Code（Sonnet 4.6）单任务 $0.11 / 53.8% EA，Codex CLI（GPT-5.5）$ 1.39 / 60.3% EA $1$ 。将简单子任务路由给 Claude Code、复杂子任务路由给 Codex，可在总预算内最大化完成率。

2.3 上下文管理与配置注入

两者均支持通过项目根目录的配置文件向 Agent 注入上下文：

Claude Code 读取 CLAUDE.md，每个会话启动时自动加载，建议控制在 200 行以内 $19$ 。
Codex CLI 读取 AGENTS.md，由 OpenAI 与 Google 等合作创建的开放标准格式 $20$ 。

编排系统可通过动态生成或修改这两个文件，向不同 Worker 注入差异化的上下文（如任务边界、API 约束、代码风格规范）。

三、协同架构模式与工具生态

3.1 编排模式分类

模式	机制	适用场景	局限
Orchestrator-Worker	单编排者分解任务、委派专业工作者、汇总结果 $21$	子任务可独立执行、需要集中调度	编排者成为单点瓶颈；编排者 token 开销大
Fan-out / Fan-in	协调 Agent 将大任务并行拆分给多个 Agent 同时执行，完成后合并 $21$	无依赖或弱依赖的并行子任务	合并阶段冲突处理复杂
Blackboard	共享知识库，专家 Agent 读写黑板，控制器根据当前状态决定下一个贡献者 $22$	无法预先规划执行顺序的开放式任务	状态爆炸风险；需要锁机制
Pipeline	顺序流水线，前一阶段输出作为下一阶段输入 $23$	有严格前后依赖的阶段性任务	无法并行；慢阶段阻塞全链路
Deterministic YAML	确定性路由，零 token 消耗编排层（如 Conductor） $24$	流程固定、路由规则明确的工作流	灵活性差；无法处理动态分支

💡 推荐组合 ：对多 Agent 编码任务，最有效的模式是 Orchestrator-Worker + Blackboard 混合 ------Orchestrator 负责任务分解与调度，Blackboard 负责跨 Agent 的状态共享与隐式通信。Anthropic 内部研究系统即采用此模式 $25$ 。

3.2 现有工具生态

工具	协调模型	代码隔离	通信机制	支持 Agent
Claude Squad	tmux 多会话管理 + TUI 控制台 $26$	git worktree 自动创建隔离分支 $27$	文件系统 + git 分支	Claude Code, Codex, Gemini, Aider, Amp
Vibe Kanban	看板任务管理 + MCP Server 暴露状态 $28$	每任务独立 git worktree + 内置代码审查 $28$	MCP Server + 自动排队 $29$ $30$	Claude Code, Cursor, Copilot, Gemini CLI
Conductor	YAML 确定性编排，零 token 消耗路由 $24$	依赖外部 worktree 配置	确定性路由 + 结构化输入输出	任意 CLI Agent
Terragon	后台并行 Agent + 自动冲突处理 $31$	隔离沙箱 + git 工作流（clone → branch → PR）	Web 面板 / CLI / GitHub 评论	Claude Code, Codex

3.3 异构混用的现状

Claude Code 与 Codex 混合使用目前主要停留在两种模式：

手动并行：开发者在不同终端分别启动两类 Agent 处理不同模块，手动协调合并。
工具层统一：Claude Squad 等工具通过可配置的启动命令支持不同 Agent 后端，但编排逻辑本身不区分 Agent 类型。

Synthesis：真正语义级的异构编排------根据子任务特征自动路由到最适合的 Agent 类型------尚缺乏成熟的开源方案，这也是第四章端到端设计的核心价值所在。

四、端到端设计与实现方案

4.1 架构总览

架构分为五层，自上而下依次为：

Orchestrator（编排层）：接收顶层需求，负责任务分解、路由决策、依赖拓扑排序。
Worker Pool（执行层）：混合部署 Claude Code Workers 与 Codex Workers，可动态伸缩。
git worktree 隔离层：每个 Worker 独占一个 worktree 与 feature 分支，物理隔离防止文件写冲突。
Blackboard 共享层 ：状态文件 + 上下文注入文件（CLAUDE.md/AGENTS.md）+ MCP Server，承担跨 Agent 的隐式通信。
Integration Layer（集成层）：预检合并、自动 rebase、语义冲突 re-dispatch、人工兜底。

核心设计原则：Worker 之间零直接通信，一切协调通过 Orchestrator 和 Blackboard 间接完成 ；Worker 只需要关心"接收任务 → 在隔离 worktree 中执行 → 产出代码 + 状态更新" $32$ 。

4.2 任务分解与分配策略

Orchestrator 收到顶层需求后，执行以下分解逻辑：

按模块/文件边界划分 是最安全的策略------不同 Agent 修改不同目录或文件，从源头消除合并冲突。代理团队模式建议团队规模 3-5 个成员，并支持共享任务列表与依赖跟踪 $33$ 。

路由决策矩阵：

子任务特征	路由目标	依据	调用方式
简单重构 / 文件迁移 / 测试补全	Claude Code Worker	性价比优（$0.11/task） $1$	`claude -p -w --output-format stream-json`
复杂算法 / 跨模块逻辑 / 需要推理链	Codex Worker	性能优（60.3% EA） $1$	`codex exec -q` 或 Codex SDK `runStreamed()`
代码审查 / 安全扫描	Codex Worker (review mode)	未披露	`codex review --no-interactive`
需要外部 API / 特殊环境	Codex Cloud	云端沙箱提供隔离执行环境 $14$	`codex cloud exec`

4.3 隔离与通信机制

物理隔离层基于 git worktree。每个 Worker 启动时自动获得独占的 worktree 和对应 feature 分支：

bash 复制代码

# Claude Code Worker: 原生一行命令完成
claude -p --worktree --base main "实现用户认证模块"

# Codex Worker: 需要编排层预先创建 worktree
git worktree add ./worktree-codex-01 -b feat/payment-module
cd ./worktree-codex-01 && codex exec -q "实现支付模块"

隔离的核心不在于协调算法，而在于基础设施层面的硬隔离------让 Agent 不需要相互感知就能并行工作 $32$ 。

**共享上下文层（Blackboard）**由三部分组成：

状态文件：JSON 格式的任务状态表，记录每个子任务的 assigned/running/done/failed 状态。
上下文注入文件 ：动态生成的 CLAUDE.md / AGENTS.md，向 Worker 传递全局约定 $19$ $20$ 。
MCP Server ：暴露跨 Agent 查询能力（如"模块 A 的接口签名是什么"），Vibe Kanban 已验证此模式可行 $30$ 。

4.4 代码合并与冲突处理

git worktree 提供了文件隔离但不能消除语义冲突------当多个 Agent 修改相同功能接口时，冲突在 PR 合并阶段显现 $34$ 。Integration Layer 的处理流程：

检测：Worker 完成后触发 git merge --no-commit 预检，发现冲突即标记。
自动解决：对无语义冲突的格式差异（import 顺序、空行）自动 rebase。
Re-dispatch：语义冲突时，将冲突文件及两个分支的 diff 作为新子任务重新分配给一个 Agent，由其做三方合并决策。
人工兜底：连续 2 次 re-dispatch 仍失败则暂停并通知人类开发者。

4.5 成本与安全治理

Token 成本控制需要多层防线：

明确规定完成标准（如测试通过），避免 Agent 无限迭代 $35$ 。
设置"禁区"（如不准修改数据库 schema），缩小 Agent 行动空间 $35$ 。
熔断器：连续 3 次无文件写入或产生相同错误时强制停止 $36$ 。
显式限制重试次数（"3 次未解决则停止并汇报"） $35$ 。

可观测性 需覆盖四个维度：执行追踪、输出评估、Token 成本归属、代理身份跟踪 $37$ 。每个 Worker 的每次 turn 都应记录 token 消耗、文件变更和执行时长，归属到对应子任务 ID。

权限治理 遵循最小特权原则 $38$ ：

Claude Code Worker：通过 allowedTools 白名单限制可用工具，仅开放目标目录的写权限。
Codex Worker：使用 Permission Profiles 替代 --full-auto $17$ 。
受保护目录（.git/、.claude/）即使在 bypass 模式下仍触发提示 $16$ 。

五、落地挑战与最佳实践

5.1 任务分配维度

实践	做法	风险缓解
按文件/目录边界分配	Orchestrator 将子任务绑定到特定目录，禁止跨目录修改	从源头消除文件级冲突 $39$
审阅者-实现者分工	一个 Agent 实现、另一个 Agent 审查	双重验证减少错误逃逸
团队规模控制在 3-5 个	Agent Teams 实验数据显示此规模协调开销最优 $33$	超过 5 个 Agent 后合并冲突概率陡增
依赖声明前置	在 Blackboard 中维护接口契约文件，Worker 开工前先读取	减少因接口变更引发的 re-dispatch

5.2 冲突处理维度

git worktree 隔离是必要条件但不是充分条件 ------它防止文件写冲突，但语义冲突仍需集成层处理 $34$ 。
分支策略 ：每个 Worker 使用 feat/<task-id> 命名分支，合并顺序由 Orchestrator 按依赖拓扑排序。
冲突预算：设定单次迭代允许的最大冲突数（如 3 个文件），超出则暂停任务重新拆分。

5.3 成本维度

异构路由是最有效的成本杠杆 ：简单任务用 Claude Code（ $0.11/task），复杂任务用 Codex（$ 1.39/task） $1$ 。
并发限制规划 ：Codex Cloud Pro 最多 3 个并发任务 $40$ ，需要据此设计 Worker Pool 上限。

5.4 安全维度

沙箱层叠加 ：Claude Code 的 Hooks 可在 PreToolUse 阶段拦截危险操作（退出码 2） $41$ 。
RBAC 粒度化 ：将权限限制在特定租户、特定操作、有限时间内 $38$ 。
弹性防线 ：重试逻辑（指数退避）+ 回退链（替代路径）+ 人工介入（高风险决策暂停） $42$ 。

⭐ 不值得做的场景：当项目代码行数 < 5000 行、子任务 < 3 个、或任务之间强耦合无法拆分时，多 Agent 编排的协调开销大于收益。单 Agent + Subagents 模式在此类场景下更经济高效。

参考资料

多个 Claude Code 与多个 Codex 协同工作：设计与实现方案