1. 为什么要让两个 CLI 编码助手同台干活1.1 一个真实痛点两个助手各管一摊人成了搬运工我平时写代码的习惯是终端不离手Claude Code 和 Codex CLI 这两个命令行编码助手都在用。用久了就发现一个很别扭的事它们各自都很能干但彼此之间完全不说话。我经常是左边一个终端窗口让 Claude Code 帮我梳理一个模块的重构思路右边另一个窗口让 Codex 去改具体的函数实现然后我自己在中间当人肉路由器——把 Claude 的分析结论复制出来粘贴给 Codex再把 Codex 改完的 diff 复制回去让 Claude 复核。一个下午下来真正写代码的时间可能只有三分之一剩下全在搬运上下文。这个问题的本质不是哪个工具更强而是两个独立的 CLI 进程各自维护着自己的会话状态、上下文窗口和工具调用链它们没有共享的“对话总线”。你没法在一个对话里同时 两个助手让它们看到同一份任务描述、同一份代码快照然后各自动手。标题里说的“一个对话同时指挥两个”要解决的就是这个断层。1.2 核心思路用 git worktree 做隔离用一层编排做统一入口要让两个助手协同绕不开两个基础问题代码隔离和指令分发。代码隔离这块git worktree是最合适的工具。它允许你在同一个仓库下挂出多个独立的工作目录每个目录对应一个分支互不干扰。Claude Code 在一个 worktree 里干活Codex 在另一个 worktree 里干活两边改的文件物理上就是分开的不会出现两个进程同时写同一个文件导致冲突的情况。等两边都改完了再通过 merge 或者 cherry-pick 把成果合到一起。这比让两个助手在同一个目录里抢文件要稳得多。指令分发这块思路是做一个轻量的编排层。它不需要多复杂核心职责就三件事接收你的一条自然语言指令把这条指令连同必要的上下文分别投递给两个 CLI收集两边的输出再汇总成一个统一的回复给你。这个编排层可以是一个 shell 脚本也可以是一个小的 Python 程序甚至可以是 Orkas 这类任务编排工具里的一条流水线。关键不在于用什么实现而在于把“一个对话”和“两个执行体”之间的映射关系固定下来。1.3 这套方案适合谁不适合谁适合的人已经在用 Claude Code 或 Codex CLI 中至少一个日常在终端里写代码对 git 分支操作不陌生愿意花一两个小时搭一套自己的协作流程。如果你经常需要“一个人分析 一个人执行”这种分工或者想让两个助手互相 review这套东西的价值会很明显。不太适合的人完全没碰过 CLI 编码助手的新手。如果你连 Claude Code 怎么安装、Codex CLI 怎么登录都还没跑通建议先把单个工具用熟再来看协同。另外如果你的项目对实时性要求极高、容不得任何编排延迟那这套方案引入的中间层可能会让你觉得碍事。提示这套方案的核心价值在于“分工”和“互审”不是“提速”。两个助手同时干活不一定比一个快但能让你从搬运工的角色里解放出来。2. 环境准备两个 CLI 各自跑通是前提2.1 Claude Code 的安装与最小验证Claude Code 的安装方式这几年变过几轮目前比较稳的路径是通过 npm 全局安装。在 macOS 或者 Ubuntu 上先确认 Node 版本在 18 以上然后执行全局安装。Windows 用户如果不想折腾 WSL也可以用桌面版但桌面版和 CLI 的协同能力有差异做这套编排建议还是用 CLI。安装完之后第一件事是验证它能不能正常发起对话。在一个空目录里跑一次最简单的交互确认网络、认证、模型调用这条链路是通的。这一步看起来废话但我见过太多人卡在“装完了但一跑就报错”的状态然后误以为是编排层的问题其实是底层 CLI 根本没通。Claude Code 的认证方式取决于你用的接入渠道。如果你用的是官方渠道按提示走登录流程即可。如果你接的是自建或第三方兼容端点需要配置对应的环境变量把 API 地址和密钥指过去。这里有个细节环境变量的名字和格式在不同版本里可能有差异配置完一定要用一次实际对话来验证不要只看文档。2.2 Codex CLI 的安装与登录排错Codex CLI 的安装同样走 npm 全局安装的路子。装完之后最常见的两个报错一个是找不到二进制或运行时组件另一个是认证令牌不可用。前者通常是全局 bin 目录没进 PATH或者 Node 版本不匹配后者多半是登录态过期或者环境变量没配对。登录这块Codex CLI 支持几种认证模式。如果你用的是账号登录按提示完成授权流程如果你用的是 API key 模式把 key 配到对应的环境变量里。我实测下来账号登录的令牌有效期有限长时间不用再回来跑很容易碰到令牌失效需要重新登录。所以如果你打算把这套协同流程做成日常工具建议把重新登录这一步也纳入你的启动脚本里或者至少在心里有个预期。还有一个坑是 Windows 上的路径问题。Codex CLI 在 Windows 原生环境下的表现不如在 WSL 里稳如果你在 Windows 上遇到一些莫名其妙的文件路径错误优先考虑切到 WSL 里跑。2.3 两个 CLI 的版本对齐与共存检查两个 CLI 都装好之后别急着上编排。先做一件事在同一个终端里分别跑一次两个 CLI 的版本查询命令把版本号记下来。然后分别发起一次最简单的对话确认两个都能独立工作。这一步的目的是建立一个“基线”。后面编排层出问题的时候你可以快速判断是编排层的问题还是某个 CLI 本身的问题。如果两个 CLI 单独跑都有问题那编排层再完美也没用。另外要注意的是两个 CLI 可能会依赖不同版本的 Node 或者不同的全局包。如果你发现装了 Codex 之后 Claude Code 反而跑不起来了大概率是全局依赖被覆盖了。这种情况可以考虑用 nvm 之类的版本管理工具给两个 CLI 分别准备独立的 Node 环境。3. 用 git worktree 搭出两个互不打架的工作区3.1 worktree 的基本操作与分支规划git worktree的用法不复杂。假设你的主仓库在~/project当前在 main 分支上。你想给 Claude Code 和 Codex 各开一个工作区可以这样做先创建两个分支比如feat/claude和feat/codex然后分别用git worktree add把这两个分支挂到不同的目录下。cd ~/project git branch feat/claude git branch feat/codex git worktree add ../project-claude feat/claude git worktree add ../project-codex feat/codex执行完之后~/project-claude和~/project-codex就是两个独立的工作目录各自 checkout 在不同的分支上。你在project-claude里让 Claude Code 改文件不会影响project-codex里 Codex 的工作。两个目录共享同一个.git对象库所以磁盘占用不会翻倍这是 worktree 相比直接 clone 两份的优势。分支规划上我的建议是不要让两个 worktree 从同一个提交点分叉后各改各的同一批文件。更好的做法是让两个助手负责不同的模块或不同的关注点。比如 Claude Code 负责重构src/core下的逻辑Codex 负责补tests下的测试。这样最后合并的时候冲突面小很多。3.2 让每个助手只看到自己该看的目录worktree 天然做到了目录隔离但还有一个细节两个 CLI 在启动时工作目录决定了它能“看到”哪些文件。你在project-claude目录下启动 Claude Code它的文件访问范围就默认落在这个目录里。同理 Codex 在project-codex里启动。这个特性很有用。你可以利用它来做关注点隔离把 Claude Code 的工作目录设成主源码目录把 Codex 的工作目录设成测试目录或者文档目录。这样即使你在指令里没有明确限定范围两个助手也大概率不会越界去改对方的文件。但要注意worktree 之间共享 git 历史所以如果 Claude Code 执行了git log或者git diff之类的命令它看到的是整个仓库的历史不只是自己分支的。如果你希望严格隔离可以在指令层面做约束或者在编排层里对 git 命令做一层包装。3.3 worktree 的清理与常见坑worktree 用完之后要清理不然会越积越多。清理的命令是git worktree remove加上目录路径。如果目录里有未提交的改动remove 会失败需要先处理掉改动或者加--force。常见的坑有几个。第一如果你手动删除了 worktree 的目录但没有跑git worktree prunegit 会认为这个 worktree 还在后续操作可能会报错。第二worktree 不能挂在同一个分支上两次如果你尝试给两个 worktree 挂同一个分支git 会拒绝。第三worktree 里的子模块状态需要单独初始化如果你的项目用了 submodule记得在每个 worktree 里都跑一次 submodule 初始化。注意worktree 的目录路径不要放在主仓库内部否则 git 会把它当成未跟踪文件git status会很难看。放在主仓库的同级目录下是比较干净的做法。4. 编排层设计一条指令怎么同时喂给两个助手4.1 编排层的最小职责边界编排层不需要做成一个大而全的框架。它的最小职责就是接收一条指令把指令分别投递给两个 CLI收集输出汇总返回。至于投递方式、输出格式、错误处理这些都可以从最简版本开始跑通了再逐步加。我建议第一版就用一个 shell 脚本实现。脚本接收一个参数作为指令内容然后分别cd到两个 worktree 目录用非交互模式调用两个 CLI把输出重定向到临时文件最后把两个文件的内容拼在一起打印出来。这个版本可能只有二三十行但已经能跑通“一条指令、两个执行体”的核心链路。非交互模式是关键。两个 CLI 都支持通过命令行参数直接传入 prompt 并输出结果不需要进入交互式界面。你需要查一下你所用版本的具体参数名不同版本可能有差异。跑通非交互调用之后编排层才有可能自动化。4.2 指令的分发策略广播还是定向最简单的分发策略是广播同一条指令原封不动地发给两个助手。这适合那种“让两个人都看看这个问题”的场景比如让 Claude Code 分析一段代码的问题同时让 Codex 也分析一遍然后对比两边的结论。但更多时候你需要定向分发。比如你希望 Claude Code 负责分析、Codex 负责执行那指令就需要拆成两部分给 Claude 的是“分析这个模块的重构点”给 Codex 的是“根据以下分析结论改代码”。定向分发可以在编排层里用一个简单的映射来实现指令里用约定的标记区分两部分比如用---claude---和---codex---分隔脚本解析后分别投递。还有一种更灵活的做法是让编排层先调用一个助手做“任务分解”把一条高层指令拆成两个子任务再分别投递。但这会引入额外的延迟和不确定性建议先把定向分发跑顺了再考虑。4.3 输出汇总怎么把两份结果拼成一份可读的回复两个助手的输出直接拼在一起会很乱因为格式、长度、语气都不一样。汇总层需要做一点加工。最基本的加工是加分隔标识让输出里能清楚看出哪段是 Claude 的、哪段是 Codex 的。更进一步你可以让编排层在收集完两份输出后再调用其中一个助手做一次“汇总”把两份结果合并成一份连贯的回复。但这又引入了一次模型调用成本和延迟都会上去。我的做法是分场景日常快速迭代时用简单拼接需要正式产出时再用汇总。输出里还要注意保留两个助手各自的关键信息比如 Claude 可能给出了分析结论和风险点Codex 可能给出了具体的 diff 和测试结果。拼接的时候不要做有损压缩宁可长一点也不要丢掉关键细节。5. 实操全流程从零跑通一次双助手协同5.1 第一步准备仓库与两个 worktree找一个你熟悉的项目确保它是 git 仓库并且工作区是干净的。然后按第 3 节的步骤创建两个分支和两个 worktree。创建完之后分别在两个 worktree 目录里跑一次git status确认分支正确、工作区干净。这一步有个细节如果你的项目有依赖需要安装两个 worktree 各自需要装一遍依赖。因为 worktree 只共享 git 对象不共享node_modules或者虚拟环境。这一步会花点时间但只需要做一次。5.2 第二步写一个最简编排脚本下面是一个 shell 脚本的骨架展示编排层的核心逻辑。注意这里的 CLI 调用参数需要根据你实际使用的版本调整不同版本的参数名可能不一样。#!/bin/bash # dual-agent.sh - 一条指令同时投递给 Claude Code 和 Codex INSTRUCTION$1 CLAUDE_DIR$HOME/project-claude CODEX_DIR$HOME/project-codex TMP_DIR$(mktemp -d) # 投递给 Claude Code cd $CLAUDE_DIR claude -p $INSTRUCTION $TMP_DIR/claude.out 21 CLAUDE_PID$! # 投递给 Codex cd $CODEX_DIR codex -p $INSTRUCTION $TMP_DIR/codex.out 21 CODEX_PID$! # 等待两边都完成 wait $CLAUDE_PID wait $CODEX_PID # 汇总输出 echo Claude Code cat $TMP_DIR/claude.out echo echo Codex cat $TMP_DIR/codex.out rm -rf $TMP_DIR这个脚本用后台进程让两个 CLI 并行跑然后用wait等两边都结束。并行是这套方案的一个关键点如果串行跑总耗时就是两个助手耗时之和并行能把总耗时压到两者中较长的那个。5.3 第三步跑一次真实任务并观察行为脚本写好后拿一个真实的小任务来试。比如“分析当前分支相比 main 分支改了哪些文件并总结改动意图”。这个任务两个助手都能做适合用来验证链路。跑的时候观察几个点两个助手是否都正常返回了结果返回时间差多少输出里有没有报错信息。如果其中一个报错了先单独在那个 worktree 里手动跑一次同样的指令确认是 CLI 本身的问题还是编排层的问题。我第一次跑的时候Codex 那边报了认证令牌失效因为距离上次登录已经过了很久。重新登录之后就正常了。这种问题在编排层里表现为“一边有输出一边没输出”排查的时候要养成先单独验证的习惯。5.4 第四步合并两个 worktree 的成果两个助手各自改完之后成果分别在两个分支上。合并的方式取决于你的工作流。如果两个分支改的是不同文件直接 merge 通常不会有冲突。如果改到了同一个文件就需要手动处理冲突。cd ~/project git merge feat/claude git merge feat/codex合并之前建议先分别看一下两个分支的 diff确认改动符合预期。我一般会先git diff main..feat/claude和git diff main..feat/codex各看一遍心里有数了再 merge。如果某个分支的改动有问题可以在那个 worktree 里让对应的助手继续修修完再合并。合并完成后别忘了清理 worktree。如果这次协同的成果已经落地两个 worktree 就可以 remove 掉了。下次需要协同的时候重新创建保持环境干净。6. 常见问题与排查技巧实录6.1 编排层报错但单个 CLI 正常这是最常见的一类问题。表现是单独跑 Claude Code 或 Codex 都没问题但通过编排脚本跑就报错。原因通常有几个工作目录不对导致 CLI 找不到项目配置环境变量在脚本里没有继承导致认证失败或者脚本里的 CLI 调用参数和交互模式下的行为不一致。排查方法很简单在脚本里把cd之后的目录打印出来把 CLI 调用命令也打印出来然后手动在终端里执行同样的命令看是否复现。如果手动执行正常而脚本不正常那就是脚本的环境问题重点检查环境变量和工作目录。6.2 两个助手改到同一个文件导致冲突worktree 隔离的是工作目录不是文件内容。如果两个助手被分配了重叠的任务范围它们完全可能改到同一个文件。合并的时候就会冲突。预防的办法是在指令层面做范围约束。给 Claude 的指令里明确说“只改 src/core 下的文件”给 Codex 的指令里明确说“只改 tests 下的文件”。如果任务本身就无法避免重叠那就接受冲突手动合并。手动合并的时候两个分支的 diff 都在你可以逐个冲突块决定保留哪边的改动。6.3 认证失效与网络超时的处理认证失效前面提过Codex CLI 的令牌有效期是个常见坑。处理方式是在编排脚本启动前加一个认证检查如果检查失败就提示重新登录。Claude Code 这边如果用的是 API key 模式key 过期或者额度用尽也会导致调用失败同样需要在脚本里做检查。网络超时是另一类问题。两个 CLI 同时发起请求如果你的网络环境对并发请求有限制可能会出现其中一个超时。这种情况可以在脚本里加重试逻辑或者把并行改成串行。串行会慢一些但稳定性更好。6.4 常见问题速查表现象可能原因排查方向一边有输出一边没有某个 CLI 认证失效或未安装单独在该 worktree 手动跑一次脚本报找不到命令PATH 未继承或全局 bin 未配置在脚本里打印 PATH 并对比合并时大量冲突两个助手任务范围重叠检查指令是否做了范围约束总耗时接近两者之和并行未生效实际在串行检查脚本是否用了后台进程worktree 无法删除有未提交改动或未 prune先处理改动再 pruneCLI 调用无响应网络超时或端点不可达检查网络和端点配置6.5 几个我踩过的坑和对应技巧第一个坑是 worktree 里的依赖没装。我第一次跑的时候Claude Code 那边因为node_modules不存在所有涉及依赖的命令都失败了。后来在脚本里加了一步依赖检查如果目录不存在就先装。第二个坑是输出编码问题。两个 CLI 的输出里如果有特殊字符拼接后在某些终端里会显示乱码。解决办法是在脚本里统一设置LANG和LC_ALL环境变量。第三个坑是并行导致的资源竞争。两个 CLI 同时跑如果都涉及大量文件读写磁盘 IO 会成为瓶颈。这种情况可以把并行改成“错峰”让一个先跑跑完再跑另一个。虽然慢但稳。提示编排脚本建议纳入版本管理和项目代码一起维护。这样换机器或者重装环境的时候直接拉下来就能用不用重新踩一遍坑。7. 进阶玩法让两个助手互相 review7.1 交叉 review 的指令设计基础协同跑通之后可以玩一个更有意思的模式让两个助手互相 review 对方的产出。具体做法是第一轮让 Claude Code 和 Codex 各自独立完成一个任务第二轮把 Claude 的产出投给 Codex 让它 review把 Codex 的产出投给 Claude 让它 review第三轮把两份 review 意见汇总决定采纳哪些。这个模式的指令设计要点是review 指令里要包含被 review 的内容。你可以在编排层里把第一轮的输出文件路径传给第二轮让助手自己去读。或者更简单直接把内容拼进指令里。内容长的时候拼进指令可能会超出上下文窗口这时候用文件路径传递更稳。7.2 用 Orkas 做任务编排的尝试如果你不想自己写脚本Orkas 这类任务编排工具可以承担编排层的角色。它的思路是把每个 CLI 调用定义成一个任务节点用依赖关系把节点串起来。比如“Claude 分析”是一个节点“Codex 执行”是另一个节点后者依赖前者的输出。用编排工具的好处是可视化、可复用、有日志。坏处是引入了一层抽象出问题的时候排查链路变长。我的建议是先用脚本把逻辑跑通确认这套协同模式对你确实有价值再考虑迁移到编排工具上。7.3 什么场景下这套方案收益最大根据我的使用经验这套方案在几类场景下收益最明显。一是大型重构需要一个人分析影响面、一个人执行改动分工明确。二是代码 review两个助手从不同角度审同一段代码能发现单一助手容易漏掉的问题。三是测试补全一个助手分析哪些分支没覆盖另一个助手去补测试用例。反过来如果是那种很小的、单点的改动用这套方案反而累赘。启动两个 worktree、跑编排脚本、合并成果这一套流程下来可能比直接用一个助手改完还慢。所以这套方案的价值不在于“总是更快”而在于“在合适的场景下更省心”。8. 我个人的一些使用体会这套东西我断断续续用了几个月最大的感受是协同的难点不在技术在于任务拆分。两个助手能不能配合好取决于你能不能把一条模糊的需求拆成两个边界清晰的子任务。拆得好两边各干各的合并的时候几乎无冲突拆得不好两边互相踩脚你还得花时间收拾。另一个体会是不要追求全自动。我一开始想的是“一条指令下去两个助手全自动跑完我只看结果”。实际用下来发现中间还是需要人介入判断。比如 Claude 的分析结论里有一个关键假设你需要确认这个假设成立才能让 Codex 基于它去改代码。全自动的流程在这种需要判断的节点上会卡住反而不如半自动来得顺畅。最后分享一个小技巧给两个助手起固定的代号在指令里用代号指代比用“Claude”和“Codex”更顺口也更不容易在长指令里搞混。这个代号你自己定关键是保持一致性让编排脚本和你的指令都用同一套代号。
1. 为什么要让两个 CLI 编码助手同台干活1.1 一个真实痛点两个助手各管一摊人成了搬运工我平时写代码的习惯是终端不离手Claude Code 和 Codex CLI 这两个命令行编码助手都在用。用久了就发现一个很别扭的事它们各自都很能干但彼此之间完全不说话。我经常是左边一个终端窗口让 Claude Code 帮我梳理一个模块的重构思路右边另一个窗口让 Codex 去改具体的函数实现然后我自己在中间当人肉路由器——把 Claude 的分析结论复制出来粘贴给 Codex再把 Codex 改完的 diff 复制回去让 Claude 复核。一个下午下来真正写代码的时间可能只有三分之一剩下全在搬运上下文。这个问题的本质不是哪个工具更强而是两个独立的 CLI 进程各自维护着自己的会话状态、上下文窗口和工具调用链它们没有共享的“对话总线”。你没法在一个对话里同时 两个助手让它们看到同一份任务描述、同一份代码快照然后各自动手。标题里说的“一个对话同时指挥两个”要解决的就是这个断层。1.2 核心思路用 git worktree 做隔离用一层编排做统一入口要让两个助手协同绕不开两个基础问题代码隔离和指令分发。代码隔离这块git worktree是最合适的工具。它允许你在同一个仓库下挂出多个独立的工作目录每个目录对应一个分支互不干扰。Claude Code 在一个 worktree 里干活Codex 在另一个 worktree 里干活两边改的文件物理上就是分开的不会出现两个进程同时写同一个文件导致冲突的情况。等两边都改完了再通过 merge 或者 cherry-pick 把成果合到一起。这比让两个助手在同一个目录里抢文件要稳得多。指令分发这块思路是做一个轻量的编排层。它不需要多复杂核心职责就三件事接收你的一条自然语言指令把这条指令连同必要的上下文分别投递给两个 CLI收集两边的输出再汇总成一个统一的回复给你。这个编排层可以是一个 shell 脚本也可以是一个小的 Python 程序甚至可以是 Orkas 这类任务编排工具里的一条流水线。关键不在于用什么实现而在于把“一个对话”和“两个执行体”之间的映射关系固定下来。1.3 这套方案适合谁不适合谁适合的人已经在用 Claude Code 或 Codex CLI 中至少一个日常在终端里写代码对 git 分支操作不陌生愿意花一两个小时搭一套自己的协作流程。如果你经常需要“一个人分析 一个人执行”这种分工或者想让两个助手互相 review这套东西的价值会很明显。不太适合的人完全没碰过 CLI 编码助手的新手。如果你连 Claude Code 怎么安装、Codex CLI 怎么登录都还没跑通建议先把单个工具用熟再来看协同。另外如果你的项目对实时性要求极高、容不得任何编排延迟那这套方案引入的中间层可能会让你觉得碍事。提示这套方案的核心价值在于“分工”和“互审”不是“提速”。两个助手同时干活不一定比一个快但能让你从搬运工的角色里解放出来。2. 环境准备两个 CLI 各自跑通是前提2.1 Claude Code 的安装与最小验证Claude Code 的安装方式这几年变过几轮目前比较稳的路径是通过 npm 全局安装。在 macOS 或者 Ubuntu 上先确认 Node 版本在 18 以上然后执行全局安装。Windows 用户如果不想折腾 WSL也可以用桌面版但桌面版和 CLI 的协同能力有差异做这套编排建议还是用 CLI。安装完之后第一件事是验证它能不能正常发起对话。在一个空目录里跑一次最简单的交互确认网络、认证、模型调用这条链路是通的。这一步看起来废话但我见过太多人卡在“装完了但一跑就报错”的状态然后误以为是编排层的问题其实是底层 CLI 根本没通。Claude Code 的认证方式取决于你用的接入渠道。如果你用的是官方渠道按提示走登录流程即可。如果你接的是自建或第三方兼容端点需要配置对应的环境变量把 API 地址和密钥指过去。这里有个细节环境变量的名字和格式在不同版本里可能有差异配置完一定要用一次实际对话来验证不要只看文档。2.2 Codex CLI 的安装与登录排错Codex CLI 的安装同样走 npm 全局安装的路子。装完之后最常见的两个报错一个是找不到二进制或运行时组件另一个是认证令牌不可用。前者通常是全局 bin 目录没进 PATH或者 Node 版本不匹配后者多半是登录态过期或者环境变量没配对。登录这块Codex CLI 支持几种认证模式。如果你用的是账号登录按提示完成授权流程如果你用的是 API key 模式把 key 配到对应的环境变量里。我实测下来账号登录的令牌有效期有限长时间不用再回来跑很容易碰到令牌失效需要重新登录。所以如果你打算把这套协同流程做成日常工具建议把重新登录这一步也纳入你的启动脚本里或者至少在心里有个预期。还有一个坑是 Windows 上的路径问题。Codex CLI 在 Windows 原生环境下的表现不如在 WSL 里稳如果你在 Windows 上遇到一些莫名其妙的文件路径错误优先考虑切到 WSL 里跑。2.3 两个 CLI 的版本对齐与共存检查两个 CLI 都装好之后别急着上编排。先做一件事在同一个终端里分别跑一次两个 CLI 的版本查询命令把版本号记下来。然后分别发起一次最简单的对话确认两个都能独立工作。这一步的目的是建立一个“基线”。后面编排层出问题的时候你可以快速判断是编排层的问题还是某个 CLI 本身的问题。如果两个 CLI 单独跑都有问题那编排层再完美也没用。另外要注意的是两个 CLI 可能会依赖不同版本的 Node 或者不同的全局包。如果你发现装了 Codex 之后 Claude Code 反而跑不起来了大概率是全局依赖被覆盖了。这种情况可以考虑用 nvm 之类的版本管理工具给两个 CLI 分别准备独立的 Node 环境。3. 用 git worktree 搭出两个互不打架的工作区3.1 worktree 的基本操作与分支规划git worktree的用法不复杂。假设你的主仓库在~/project当前在 main 分支上。你想给 Claude Code 和 Codex 各开一个工作区可以这样做先创建两个分支比如feat/claude和feat/codex然后分别用git worktree add把这两个分支挂到不同的目录下。cd ~/project git branch feat/claude git branch feat/codex git worktree add ../project-claude feat/claude git worktree add ../project-codex feat/codex执行完之后~/project-claude和~/project-codex就是两个独立的工作目录各自 checkout 在不同的分支上。你在project-claude里让 Claude Code 改文件不会影响project-codex里 Codex 的工作。两个目录共享同一个.git对象库所以磁盘占用不会翻倍这是 worktree 相比直接 clone 两份的优势。分支规划上我的建议是不要让两个 worktree 从同一个提交点分叉后各改各的同一批文件。更好的做法是让两个助手负责不同的模块或不同的关注点。比如 Claude Code 负责重构src/core下的逻辑Codex 负责补tests下的测试。这样最后合并的时候冲突面小很多。3.2 让每个助手只看到自己该看的目录worktree 天然做到了目录隔离但还有一个细节两个 CLI 在启动时工作目录决定了它能“看到”哪些文件。你在project-claude目录下启动 Claude Code它的文件访问范围就默认落在这个目录里。同理 Codex 在project-codex里启动。这个特性很有用。你可以利用它来做关注点隔离把 Claude Code 的工作目录设成主源码目录把 Codex 的工作目录设成测试目录或者文档目录。这样即使你在指令里没有明确限定范围两个助手也大概率不会越界去改对方的文件。但要注意worktree 之间共享 git 历史所以如果 Claude Code 执行了git log或者git diff之类的命令它看到的是整个仓库的历史不只是自己分支的。如果你希望严格隔离可以在指令层面做约束或者在编排层里对 git 命令做一层包装。3.3 worktree 的清理与常见坑worktree 用完之后要清理不然会越积越多。清理的命令是git worktree remove加上目录路径。如果目录里有未提交的改动remove 会失败需要先处理掉改动或者加--force。常见的坑有几个。第一如果你手动删除了 worktree 的目录但没有跑git worktree prunegit 会认为这个 worktree 还在后续操作可能会报错。第二worktree 不能挂在同一个分支上两次如果你尝试给两个 worktree 挂同一个分支git 会拒绝。第三worktree 里的子模块状态需要单独初始化如果你的项目用了 submodule记得在每个 worktree 里都跑一次 submodule 初始化。注意worktree 的目录路径不要放在主仓库内部否则 git 会把它当成未跟踪文件git status会很难看。放在主仓库的同级目录下是比较干净的做法。4. 编排层设计一条指令怎么同时喂给两个助手4.1 编排层的最小职责边界编排层不需要做成一个大而全的框架。它的最小职责就是接收一条指令把指令分别投递给两个 CLI收集输出汇总返回。至于投递方式、输出格式、错误处理这些都可以从最简版本开始跑通了再逐步加。我建议第一版就用一个 shell 脚本实现。脚本接收一个参数作为指令内容然后分别cd到两个 worktree 目录用非交互模式调用两个 CLI把输出重定向到临时文件最后把两个文件的内容拼在一起打印出来。这个版本可能只有二三十行但已经能跑通“一条指令、两个执行体”的核心链路。非交互模式是关键。两个 CLI 都支持通过命令行参数直接传入 prompt 并输出结果不需要进入交互式界面。你需要查一下你所用版本的具体参数名不同版本可能有差异。跑通非交互调用之后编排层才有可能自动化。4.2 指令的分发策略广播还是定向最简单的分发策略是广播同一条指令原封不动地发给两个助手。这适合那种“让两个人都看看这个问题”的场景比如让 Claude Code 分析一段代码的问题同时让 Codex 也分析一遍然后对比两边的结论。但更多时候你需要定向分发。比如你希望 Claude Code 负责分析、Codex 负责执行那指令就需要拆成两部分给 Claude 的是“分析这个模块的重构点”给 Codex 的是“根据以下分析结论改代码”。定向分发可以在编排层里用一个简单的映射来实现指令里用约定的标记区分两部分比如用---claude---和---codex---分隔脚本解析后分别投递。还有一种更灵活的做法是让编排层先调用一个助手做“任务分解”把一条高层指令拆成两个子任务再分别投递。但这会引入额外的延迟和不确定性建议先把定向分发跑顺了再考虑。4.3 输出汇总怎么把两份结果拼成一份可读的回复两个助手的输出直接拼在一起会很乱因为格式、长度、语气都不一样。汇总层需要做一点加工。最基本的加工是加分隔标识让输出里能清楚看出哪段是 Claude 的、哪段是 Codex 的。更进一步你可以让编排层在收集完两份输出后再调用其中一个助手做一次“汇总”把两份结果合并成一份连贯的回复。但这又引入了一次模型调用成本和延迟都会上去。我的做法是分场景日常快速迭代时用简单拼接需要正式产出时再用汇总。输出里还要注意保留两个助手各自的关键信息比如 Claude 可能给出了分析结论和风险点Codex 可能给出了具体的 diff 和测试结果。拼接的时候不要做有损压缩宁可长一点也不要丢掉关键细节。5. 实操全流程从零跑通一次双助手协同5.1 第一步准备仓库与两个 worktree找一个你熟悉的项目确保它是 git 仓库并且工作区是干净的。然后按第 3 节的步骤创建两个分支和两个 worktree。创建完之后分别在两个 worktree 目录里跑一次git status确认分支正确、工作区干净。这一步有个细节如果你的项目有依赖需要安装两个 worktree 各自需要装一遍依赖。因为 worktree 只共享 git 对象不共享node_modules或者虚拟环境。这一步会花点时间但只需要做一次。5.2 第二步写一个最简编排脚本下面是一个 shell 脚本的骨架展示编排层的核心逻辑。注意这里的 CLI 调用参数需要根据你实际使用的版本调整不同版本的参数名可能不一样。#!/bin/bash # dual-agent.sh - 一条指令同时投递给 Claude Code 和 Codex INSTRUCTION$1 CLAUDE_DIR$HOME/project-claude CODEX_DIR$HOME/project-codex TMP_DIR$(mktemp -d) # 投递给 Claude Code cd $CLAUDE_DIR claude -p $INSTRUCTION $TMP_DIR/claude.out 21 CLAUDE_PID$! # 投递给 Codex cd $CODEX_DIR codex -p $INSTRUCTION $TMP_DIR/codex.out 21 CODEX_PID$! # 等待两边都完成 wait $CLAUDE_PID wait $CODEX_PID # 汇总输出 echo Claude Code cat $TMP_DIR/claude.out echo echo Codex cat $TMP_DIR/codex.out rm -rf $TMP_DIR这个脚本用后台进程让两个 CLI 并行跑然后用wait等两边都结束。并行是这套方案的一个关键点如果串行跑总耗时就是两个助手耗时之和并行能把总耗时压到两者中较长的那个。5.3 第三步跑一次真实任务并观察行为脚本写好后拿一个真实的小任务来试。比如“分析当前分支相比 main 分支改了哪些文件并总结改动意图”。这个任务两个助手都能做适合用来验证链路。跑的时候观察几个点两个助手是否都正常返回了结果返回时间差多少输出里有没有报错信息。如果其中一个报错了先单独在那个 worktree 里手动跑一次同样的指令确认是 CLI 本身的问题还是编排层的问题。我第一次跑的时候Codex 那边报了认证令牌失效因为距离上次登录已经过了很久。重新登录之后就正常了。这种问题在编排层里表现为“一边有输出一边没输出”排查的时候要养成先单独验证的习惯。5.4 第四步合并两个 worktree 的成果两个助手各自改完之后成果分别在两个分支上。合并的方式取决于你的工作流。如果两个分支改的是不同文件直接 merge 通常不会有冲突。如果改到了同一个文件就需要手动处理冲突。cd ~/project git merge feat/claude git merge feat/codex合并之前建议先分别看一下两个分支的 diff确认改动符合预期。我一般会先git diff main..feat/claude和git diff main..feat/codex各看一遍心里有数了再 merge。如果某个分支的改动有问题可以在那个 worktree 里让对应的助手继续修修完再合并。合并完成后别忘了清理 worktree。如果这次协同的成果已经落地两个 worktree 就可以 remove 掉了。下次需要协同的时候重新创建保持环境干净。6. 常见问题与排查技巧实录6.1 编排层报错但单个 CLI 正常这是最常见的一类问题。表现是单独跑 Claude Code 或 Codex 都没问题但通过编排脚本跑就报错。原因通常有几个工作目录不对导致 CLI 找不到项目配置环境变量在脚本里没有继承导致认证失败或者脚本里的 CLI 调用参数和交互模式下的行为不一致。排查方法很简单在脚本里把cd之后的目录打印出来把 CLI 调用命令也打印出来然后手动在终端里执行同样的命令看是否复现。如果手动执行正常而脚本不正常那就是脚本的环境问题重点检查环境变量和工作目录。6.2 两个助手改到同一个文件导致冲突worktree 隔离的是工作目录不是文件内容。如果两个助手被分配了重叠的任务范围它们完全可能改到同一个文件。合并的时候就会冲突。预防的办法是在指令层面做范围约束。给 Claude 的指令里明确说“只改 src/core 下的文件”给 Codex 的指令里明确说“只改 tests 下的文件”。如果任务本身就无法避免重叠那就接受冲突手动合并。手动合并的时候两个分支的 diff 都在你可以逐个冲突块决定保留哪边的改动。6.3 认证失效与网络超时的处理认证失效前面提过Codex CLI 的令牌有效期是个常见坑。处理方式是在编排脚本启动前加一个认证检查如果检查失败就提示重新登录。Claude Code 这边如果用的是 API key 模式key 过期或者额度用尽也会导致调用失败同样需要在脚本里做检查。网络超时是另一类问题。两个 CLI 同时发起请求如果你的网络环境对并发请求有限制可能会出现其中一个超时。这种情况可以在脚本里加重试逻辑或者把并行改成串行。串行会慢一些但稳定性更好。6.4 常见问题速查表现象可能原因排查方向一边有输出一边没有某个 CLI 认证失效或未安装单独在该 worktree 手动跑一次脚本报找不到命令PATH 未继承或全局 bin 未配置在脚本里打印 PATH 并对比合并时大量冲突两个助手任务范围重叠检查指令是否做了范围约束总耗时接近两者之和并行未生效实际在串行检查脚本是否用了后台进程worktree 无法删除有未提交改动或未 prune先处理改动再 pruneCLI 调用无响应网络超时或端点不可达检查网络和端点配置6.5 几个我踩过的坑和对应技巧第一个坑是 worktree 里的依赖没装。我第一次跑的时候Claude Code 那边因为node_modules不存在所有涉及依赖的命令都失败了。后来在脚本里加了一步依赖检查如果目录不存在就先装。第二个坑是输出编码问题。两个 CLI 的输出里如果有特殊字符拼接后在某些终端里会显示乱码。解决办法是在脚本里统一设置LANG和LC_ALL环境变量。第三个坑是并行导致的资源竞争。两个 CLI 同时跑如果都涉及大量文件读写磁盘 IO 会成为瓶颈。这种情况可以把并行改成“错峰”让一个先跑跑完再跑另一个。虽然慢但稳。提示编排脚本建议纳入版本管理和项目代码一起维护。这样换机器或者重装环境的时候直接拉下来就能用不用重新踩一遍坑。7. 进阶玩法让两个助手互相 review7.1 交叉 review 的指令设计基础协同跑通之后可以玩一个更有意思的模式让两个助手互相 review 对方的产出。具体做法是第一轮让 Claude Code 和 Codex 各自独立完成一个任务第二轮把 Claude 的产出投给 Codex 让它 review把 Codex 的产出投给 Claude 让它 review第三轮把两份 review 意见汇总决定采纳哪些。这个模式的指令设计要点是review 指令里要包含被 review 的内容。你可以在编排层里把第一轮的输出文件路径传给第二轮让助手自己去读。或者更简单直接把内容拼进指令里。内容长的时候拼进指令可能会超出上下文窗口这时候用文件路径传递更稳。7.2 用 Orkas 做任务编排的尝试如果你不想自己写脚本Orkas 这类任务编排工具可以承担编排层的角色。它的思路是把每个 CLI 调用定义成一个任务节点用依赖关系把节点串起来。比如“Claude 分析”是一个节点“Codex 执行”是另一个节点后者依赖前者的输出。用编排工具的好处是可视化、可复用、有日志。坏处是引入了一层抽象出问题的时候排查链路变长。我的建议是先用脚本把逻辑跑通确认这套协同模式对你确实有价值再考虑迁移到编排工具上。7.3 什么场景下这套方案收益最大根据我的使用经验这套方案在几类场景下收益最明显。一是大型重构需要一个人分析影响面、一个人执行改动分工明确。二是代码 review两个助手从不同角度审同一段代码能发现单一助手容易漏掉的问题。三是测试补全一个助手分析哪些分支没覆盖另一个助手去补测试用例。反过来如果是那种很小的、单点的改动用这套方案反而累赘。启动两个 worktree、跑编排脚本、合并成果这一套流程下来可能比直接用一个助手改完还慢。所以这套方案的价值不在于“总是更快”而在于“在合适的场景下更省心”。8. 我个人的一些使用体会这套东西我断断续续用了几个月最大的感受是协同的难点不在技术在于任务拆分。两个助手能不能配合好取决于你能不能把一条模糊的需求拆成两个边界清晰的子任务。拆得好两边各干各的合并的时候几乎无冲突拆得不好两边互相踩脚你还得花时间收拾。另一个体会是不要追求全自动。我一开始想的是“一条指令下去两个助手全自动跑完我只看结果”。实际用下来发现中间还是需要人介入判断。比如 Claude 的分析结论里有一个关键假设你需要确认这个假设成立才能让 Codex 基于它去改代码。全自动的流程在这种需要判断的节点上会卡住反而不如半自动来得顺畅。最后分享一个小技巧给两个助手起固定的代号在指令里用代号指代比用“Claude”和“Codex”更顺口也更不容易在长指令里搞混。这个代号你自己定关键是保持一致性让编排脚本和你的指令都用同一套代号。
