我把 Claude、Codex、Copilot、Gemini 拼成了一个工作流，接力写代码
提示
现在主流的 AI coding agent 各有所长，Claude Code 的 plan、Codex 的 debug、Copilot CLI 的 GitHub 工作流、Gemini 的 UI 直觉，没一个是真正全能的。我做了一个叫 CodeMux 的客户端，让它们之间能互相接力——一个出方案，一个查 bug, 一个写代码，共享同一份上下文。
这两年 AI coding agent 出得快，社交平台上隔一阵就吵一波"哪个最强"。我自己倒没太纠结过这件事——打开终端会看到四个 agent 的窗口同时挂着：Claude Code、Codex、Copilot CLI, 还有跑在 OpenCode 里的 Gemini。一开始只是想都试试看哪个顺手，用着用着就再也合不回一个了。
一个不太被讨论的事实：现在主流的 AI coding agent, 没有一个是真正全能的。Claude Code 的 plan 拆解我用得最多，长上下文也耐受得住，但偶尔 debug 时会绕远路；同样的问题丢给 Codex 反而经常能挖到根因。Copilot CLI 的强项也不在模型，而在它对 GitHub 工作流的熟悉度——处理 issue 和 code review 自带一种肌肉记忆。Gemini 我用得没那么频繁，但出 UI 草图时常常给我一些惊喜。
各有各的擅长，也各有各的死角。与其逼一个 agent 把全部活都干了，不如让它们各自做最对味的事——这是过去几个月我用下来的核心体感。
我手头这几个 Agent, 各自管什么活
具体到工作流里，这几个 agent 在我这有相对固定的分工。
Claude Code 是我的主 agent,coding plan 和 codebase analysis 几乎都交给它。它的 harness 设计得很扎实，长上下文里追溯多个文件之间的关系不容易掉链子。我习惯让它先做架构层面的判断——"这个改动应该改哪几个模块、依赖关系会不会出问题、有没有更小的 patch 能达到同样目的", 这类问题它经常能给出比我自己想得更全面的答案。
真正棘手的 bug 我会丢给 Codex, 挂 GPT-5.5。 这是我后来摸出来的搭配。有些 bug 不是表面的 typo 或者 null check, 是工程师自己看了半天都觉得"这地方逻辑没毛病但就是不对"的那种——可能涉及多线程时序、可能是某个第三方库的隐式假设、可能是状态机里被忽略的边界 case。Codex 在这类问题上的"思考深度"我感受得很明显，它愿意去挖根因而不是给一个"试试这样改"的快修。
Copilot CLI 是我处理 GitHub 相关任务的首选。 这一点不太被讨论，但我猜它训练数据里塞了大量真实开源项目的 issue / PR / review 历史——所以让它读 issue 找 root cause、起草 review comment、按 maintainer 的语气回复 contributor, 它做出来的东西比通用模型自然得多。同样一份 PR diff,Claude Code 的 review 是"这里逻辑可以改成 X",Copilot CLI 给出来的会带"我们 repo 里另一处类似的实现是 Y, 要不要保持一致"——这种 codebase 内部一致性的视角，挺加分的。
Gemini 我主要用在 UI/UX 设计上, 挂在 OpenCode 里跑。3.1 推出之后我做前端原型时偶尔会试一下，它对视觉层级、信息密度的直觉确实和写代码的模型不太一样。
把这几个组合起来用，月度 token 用量在 billion 量级。原因不是我故意烧，是好用之后回不去单引擎模式了——同样的需求，正确的 agent 一次就能给出能用的结果，错的 agent 来回拉扯几轮反而更贵。
真正卡人的不是模型，是切换
但同时挂着四个 agent 用，会很快撞到一个问题：它们之间什么都不共享。
最典型的场景是这样的：Claude Code 帮我把一个新 feature 的方案想清楚了，plan 写得很完整，接下来就该动手了。这时候按我的工作流应该切到 Codex 或者别的 agent 去执行——但 plan 是 Claude 自己 session 里的产物，Codex 看不见。我得手动复制 plan、贴到 Codex 的输入框里、再补一段背景"我在做 X 项目，目前的代码结构大概是 Y, 你按这个 plan 帮我实现"。每次切换 agent 都来一遍，每次都要重新讲一遍上下文。
更烦的是 debug 场景。Claude 跑了半天没找到根因，我想换 Codex 试试——但 Codex 没有"刚才尝试过哪些假设、排除了什么"的记忆，我要么自己总结一遍，要么让 Codex 从头开始走一次相同的探索路径，白白烧 token。
问题不在模型本身，在工具链没有为"多 agent 协作"设计过。 现在的 coding agent 客户端基本都假设你只用一个 agent—— Cursor 锁 Claude，Codex 锁自家模型，各家原生 CLI 又各自为政。想跨 agent 接力，只能靠人肉做 context broker。
我也不是没考虑过让一个 agent 包打天下——但前面说过了，真正逼我多 agent 切换的不是好奇心，是每个 agent 的 harness 和模型都有自己的脾气，硬塞同一个干所有活，效率反而更低。再说一个现实问题：好模型的 token 收费很高。 顶配模型用来做 90% 的常规任务是浪费，只在它真正擅长的环节用，能省下来的成本远超工具切换的麻烦。
所以问题就变成了：能不能有个东西，把"哪个 agent 做什么"和"它们之间怎么共享上下文"这两件事接管下来，我只管定义任务？ CodeMux 是我对这个问题做的回答。
把"用谁"和"做什么"拆开
CodeMux 的核心抽象其实很简单——它把角色 (role) 和引擎 (engine) 拆成了两个独立维度。
平时我们说"我用 Claude Code 做 plan", 这句话里其实捆了两件事：角色是"做 plan 的那个人", 引擎是"Claude Code"。但这两件事不应该耦合——做 plan 的角色今天可以是 Claude, 明天可以是 Codex, 后天 Gemini 出新版了也可以挂上去试试。
CodeMux 里有 5 个预定义角色：explorer（探索 codebase)、researcher（查资料）、reviewer（审查产出）、designer（出设计）、coder（写代码）。每个角色独立挂载一个引擎——同一个 explorer 角色，可以挂 Claude 也可以挂 Codex, 看你当前任务更需要哪种风格。
这种解耦带来的直接好处是搭配自由。我自己常用的一套配置是：
- explorer 挂 Claude Code, 负责吃透项目结构、给主 agent 喂 context
- coder 挂 Codex, 因为它写代码时对 plan 的执行度最稳
- reviewer 也挂 Codex, 跨视角看代码更容易发现问题
- designer 挂 OpenCode + Gemini, 出 UI 部分
但你完全可以反过来——让 Codex 做 explorer 因为它读代码细致，让 Claude 做 reviewer 因为它表达更结构化。配置存在 settings 里，跨任务复用，不用每次重新搭。
权限也是按角色分的。explorer 和 reviewer 默认 readonly——它们只该读，不该改。这不是靠 prompt 约束的，是 CodeMux 在调起子 agent 时直接通过 CLI 参数把 write 权限关掉。如果一条规则重要，就别交给 LLM 去自觉遵守。
为什么是 DAG, 不是一个长 prompt
光有角色还不够，真正让多 agent 协作跑起来的，是任务编排那一层。
最朴素的做法是这样：把整个需求扔给一个"主 agent", 让它自己决定先做什么后做什么、什么时候调谁。这种做法在 demo 里看着很厉害，实际跑起来问题很多——agent 容易在长流程里失焦、回头改前面已经做完的事、或者干脆陷入"再分析一轮看看"的死循环。
CodeMux 选了另一条路：主 agent 只做一次拆解，把任务拆成一张 DAG, 后续调度由系统接管。
具体流程是这样：用户给一个 prompt, 主 agent 收到之后做的第一件事是 decomposeTask——它输出一个 JSON 数组，每一项是一个子任务，带 description、role（谁来做）、dependsOn（依赖哪些子任务）。这一步主 agent 必须先把整体上下文吃透，因为它需要判断"什么任务可以并行、什么必须串行、谁的输出是谁的输入"。
为什么是 DAG 不是一个长 prompt? 因为依赖关系本身就是图结构。 把它显式化，有几个直接的好处： 第一，ready 状态的子任务可以并行 dispatch。系统每轮扫一遍所有 blocked 状态的子任务，把"依赖全部完成"的提到 pending 然后丢进执行队列。Claude 在做模块 A 的同时，Codex 可以同时做不依赖 A 的模块 B, 而不是傻傻地等。
第二，主 agent 不用记住整个流程的状态。每个子任务跑完之后，把 result summary 写回 DAG, 系统拿这些 summary 去满足下一批子任务的依赖输入——主 agent 只需要在最后做一次 aggregate, 根本不需要在中途维护一个超长的"我做到哪一步了"的心智状态。
第三，子任务可以跑在隔离的 git worktree 里。CodeMux 自动给每次编排开一个 worktree, 每个 coder 子任务在独立目录里改文件，跑完之后再统一合并回主分支。这样并行的 coder 之间不会互相覆盖，主仓库也不会在编排过程中被半成品代码污染。
我承认这套机制不是没有局限——拆解质量高度依赖主 agent 的能力，主 agent 拆错了后面就全跑偏。所以我习惯在主 agent 拆完之后会有一个 confirming 状态，让我自己过一遍 subtask 列表，改掉不合理的拆分再 dispatch。这一步在自动化和可控性之间找了个平衡——纯人工太累，纯自动信不过。
单 Agent 用着也省心
写到这可能有人觉得 CodeMux 是个重型编排工具，只有跑大任务才划算。其实不是——它日常作为单 agent 客户端用也挺顺手的, 这部分我反而花了更多精力打磨。
最实在的一点是多引擎共存于同一个窗口。我不需要在四个 terminal 之间 alt-tab,sidebar 里就能看到 Claude / Codex / Copilot / Gemini 各自的 session 列表，点一下就切过去。每个 engine 的 session 历史独立保存，切回来还在原地。
第二是完整的思维链可见。Claude Code 的 reasoning、tool call 的 input/output、plan 模式下的步骤树、permission 请求的上下文——这些底层 CLI 通常折叠掉或者只显示一行的内容，在 CodeMux 里都展开成可读的格式。我经常在 agent 走错的时候靠这层可见性回溯哪一步开始判断错了，这件事在原生 CLI 里几乎做不到。
第三是跨设备访问。CodeMux 内置了 Cloudflare Tunnel 支持，你可以让在家里的 Mac 跑 agent, 在外面用手机或 iPad 直接访问同一个 session 继续对话。出门坐地铁时，我经常用手机看 agent 跑长任务的进度、回复 permission 请求、或者发个新指令。这个能力对"我希望让 agent 在我不在的时候自己跑"的场景特别重要。
第四是外部消息渠道。CodeMux 支持把 agent 接到飞书 / Telegram / Teams 这些 IM 上——agent 完成长任务之后会主动通知你，你也可以在 IM 里直接给它发新指令。我把它当成一种"低成本远程工位", 不需要随时盯着窗口。
现在跑成什么样
需要先做个区分。单 agent 那部分用着已经相当完善了——多引擎共存、完整思维链可见、permission 请求、skill 调用，全部跟着各家原生 CLI 走，没有阉割也没有再包一层。装上 CodeMux 之后，我日常大部分时间都跑在这一层，再也不需要为了换 agent 而在四个只支持单一引擎的客户端之间来回切换。这部分体验我打磨了挺久，可以稳定接管日常 coding。
orchestration 是另一回事——多 agent DAG 编排是最近才构思出来的架构，还比较粗糙。它能跑，我自己每天也会用，但跑得顺的场景目前比较窄。
跑得比较好的场景是有清晰边界的中等复杂度任务。比如"把这个组件的状态管理从 Context 迁移到 Zustand, 顺便补上单元测试", 这种任务拆成 3-5 个子任务、有明确依赖、最后能合并验证，DAG 调度的优势能体现出来。我最近一周用 CodeMux 做的事大概就在这个尺度——一个引擎适配器的重构、一次跨语言的字符串国际化、几个 bug 的定位和修复。
跑得不太好的场景集中在 orchestration 这一层： 任务边界模糊的探索性需求。"帮我看看这个项目能不能加个 X 功能"这种问题，主 agent 拆出来的子任务质量经常飘忽——有时候拆得过细，有时候漏掉关键步骤。这类需求我现在还是直接用单 engine 模式手动迭代，等有了清晰方向再切到编排模式。
跨 agent 风格融合。 不同 agent 写代码的风格差异不小——同一个 codebase 里 Claude 写的部分和 Codex 写的部分，过几周回头看能一眼分辨。这件事 reviewer 角色可以缓解一些，但没彻底解决。
编排嵌套。 现在子任务之间不能再开新的编排，一层 DAG 就是一层。我有几个场景想要"子任务自己再 fan out 出一组并行任务", 但暂时只能在 prompt 里手动展开，这个之后想做。
总的来说，CodeMux 不是一个"装上就能让 AI 替你写代码"的工具——它更像是一个让你能更精细地组织 AI 工作流的客户端, 前提是你已经知道自己想要什么，知道哪个 agent 擅长什么。
结语
最近一直在想一个类比——之前写代码，程序员要自己装编辑器、配各种语言扩展、串好编译器和调试器、维护自己的快捷键集合。那个年代的"开发体验"很大程度上是手动凑出来的，每个人的工位都长得不一样。后来 IDE 厂商把这些抽象成了"扩展商店"和默认配置，大多数人就不再为基础设施操心了。
agent 时代的我们，正处在那个"手动凑"的阶段。每个开发者在自己机器上手动协调几个 agent CLI、手动复制 plan、手动管理 context、手动决定什么时候用谁。CodeMux 是我个人的一次尝试，看能不能把这件事抽象成一个客户端——但我并不觉得它就是终态。终态应该是更自然的：也许 agent 之间通过某种标准协议直接互通，也许操作系统级别会出现一个 agent runtime, 也许我们今天讨论的这些角色 / 编排概念，最后会被一个完全不同的范式取代。
但在那之前，我们这些每天和多个 agent 打交道的开发者，还是得有个东西把它们组织起来。如果你也在为"切换 agent 时丢上下文"、"想用最对味的 agent 干每件事但操作成本太高"这类问题烦恼，可以来 github.com/realDuang/codemux 看看这个项目——开源、跨平台、windows/mac/linux全平台支持，欢迎尝鲜。
agent 不会替我们思考。能做的只是把当下的工具组织得更顺手一点，让我们多省下一点心智去想真正值得想的问题。