我现在是怎么同时用 Claude Code + Codex 干活的：一套多 Agent Vibe Coding 工作流

MulaLi_

262人浏览 · 2026-08-28 10:15:10

MulaLi_ · 2026-08-28 10:15:10 发布

最近一段时间，我使用 Claude Code 和 Codex 的方式已经和刚开始完全不一样了。

刚接触 Coding Agent 的时候，我的流程基本就是：打开项目，启动一个 Agent，把需求扔进去，等它写完，自己检查一遍。后来慢慢发现，这其实还是在把 AI 当成一个"更强的代码补全工具"在用，没什么本质变化。

真正让我感觉效率发生变化的一个转折点，是我不再让一个 Agent 从头干到尾，而是开始让多个 Agent 分工。现在一个稍微复杂一点的需求，我经常会拆成四块：一个 Agent 负责实现功能，一个负责检查现有代码、找影响范围，一个负责 Review 前面的修改，还有一个负责跑测试、检查问题、补遗漏。有时候 Claude Code 和 Codex 还会混着用。

这一套跑顺了以后，我最大的感受是：模型是不是强那么百分之五，有时候已经没那么重要了。更影响效率的，其实是你怎么给 Agent 分工。这篇就分享一下我目前比较常用的方法。

一开始我犯过一个错误：什么都让一个 Agent 做

比如有一个需求，要给现有系统加一个功能，同时改前端、后端，还要补一下异常处理。最开始我的 Prompt 经常是这样的：

帮我完整实现这个需求。需要检查前后端现有代码，修改对应功能，处理异常，最后跑测试并 Review 一下代码。

然后把这一整段丢给一个 Codex。它当然也能做，但用久了以后我发现这种方式有几个挺明显的问题。

第一，Context 会越来越乱。 它得同时理解需求、前端代码、后端代码、数据库、测试，还有自己刚才做过的修改。任务做到后面，Context 里的东西会越堆越杂，尤其大项目里一个需求可能涉及几十个文件，一个 Agent 全程扛下来其实挺吃力的。

第二，Agent 很容易"自己 Review 自己"。 这点我觉得挺有意思。如果你告诉它写完之后自己检查一下，它当然会检查，但问题是它检查的是自己刚刚形成的那套思路。有时候一个错误本身就是因为它最开始就理解错了需求，那么让同一个 Agent 既产生方案、又实现方案、又验证自己的方案，很容易把同一个错误一路带到底，自己是发现不了自己的盲区的。

第三，很多任务其实根本没必要串行。 比如分析现有代码和排查测试覆盖不足，很多时候完全可以同时做。如果全部塞给一个 Agent，就变成分析、开发、测试、Review 一路串下去；而拆给多个 Agent 之后，分析现有代码、实现功能、检查现有问题这几件事可以同时启动，等主实现完成之后再进入 Review。这才是我后来觉得 Multi-Agent 真正有价值的地方。

我现在一般会把 Agent 分成四种角色

不是每次都一定开四个，但思路大致如此。

角色一：Explorer（探索者）

这个 Agent 不负责写代码，只负责一件事——搞清楚这个需求到底会影响什么。我一般会这么写 Prompt：

先不要修改任何代码。阅读当前项目并分析这个需求：涉及哪些模块，主要调用链是什么，哪些文件大概率需要修改，当前有没有类似实现可以复用，哪些地方最容易产生回归问题。最后给我一份实施建议。

这个角色我现在特别喜欢，因为 Coding Agent 一个很常见的问题就是上来就改。但很多项目真正困难的地方根本不是写代码，而是找到正确的修改位置。先让一个 Agent 做探索，很多时候能避免后面走弯路。

角色二：Implementer（实现者）

这才是真正干活的 Agent。我一般会把 Explorer 的结论和需求一起给它：

根据需求完成实现。Explorer 已经确认 xxx 是入口，xxx 是核心 Service，前端调用位于 xxx，需要注意 xxx 兼容问题。请基于现有项目风格完成实现，不要做与需求无关的大规模重构。完成后列出修改文件、实现内容、尚未确认的问题。

它的目标很明确：把功能做出来，而不是一边研究整个世界一边开发一边 Review，那样反而分心。

角色三：Reviewer（审查者）

这个 Agent 我一般会尽可能让它站在一个"没参与开发的人"的角度重新看，Prompt 大概是：

你是 Review Agent，不要假设当前实现是正确的。请结合原始需求和当前代码改动进行 Review，重点检查是否真正满足需求、是否存在漏改、是否有边界条件、是否影响旧功能、是否出现错误异常处理、是否存在重复实现、是否有明显安全问题、是否有可以直接复现的 Bug。发现问题要明确指出文件、位置、原因和建议修改方式；没问题就总结本次实现覆盖了哪些功能。

这个角色带来的价值其实比我最初预期的要大。因为 Implementer 经常会出现功能能跑，但 Reviewer 一看就发现"这个分支没处理""这个旧逻辑被破坏了""这里有个 null 场景""这里和项目原来的写法不一致"这类问题。而且让不同模型互相 Review 效果还挺有意思，比如 Codex 写、Claude Review，或者反过来，两边的盲区往往不太一样。

角色四：Fix / Test Agent（修复与测试）

最后一个 Agent 不负责重新设计方案，只负责根据 Review 结果修问题、运行测试、检查 Build、检查 Diff、确认没有遗漏。我一般会把任务限制得比较窄：

这里是 Review Agent 的结果，逐项检查这些问题，确认成立的直接修复，不成立的说明原因。全部处理完成以后，跑项目已有测试、跑构建、检查 git diff、输出最终修改总结。

这样一轮下来，基本就形成了 Explorer → Implementer → Reviewer → Fix/Test 这样一条链路。

那为什么还要"同时"开多个 Agent？

看到这里可能会有人觉得，你这不还是串行吗？确实有部分是串行的，但实际使用中有很多东西可以并行。

比如需求进来之后，可以同时开一个 Explorer 分析后端、一个分析前端、再开一个专门找类似的历史实现。或者当 Implementer 正在写功能的时候，另外的 Agent 可以同时检查现有测试、检查可能受影响的旧逻辑。等 Implementer 做完，Reviewer 其实已经通过并行跑的这几个 Agent 掌握了不少项目上下文，整个流程就不会完全串成一条线。

多 Agent 有一个非常大的坑：别让他们互相踩代码

这是我觉得 Multi-Agent 最容易翻车的地方。如果 Agent A 正在改 UserService.ts，Agent B 也在改同一个文件，两个人同时动手，最后你得到的很可能不是效率翻倍，而是冲突翻倍。

所以我现在有一个很简单的原则：可以并行的是"思考"，比如分析、Review、查代码、找风险、检查测试，这些非常适合并行；但修改同一个工作区要谨慎，尤其是两个 Agent 同时改同一个文件。如果任务能明确拆成两个互不干扰的模块，比如一个管 frontend/、一个管 backend/，那问题不大；但如果改动高度交叉，我宁愿一个 Agent 写、另一个只读 Review，也不会强行让它们并发写同一批代码。Multi-Agent 不等于什么都并行，这一点我是真踩过坑才想明白的。

还有一个坑是：不要一上来就开八个 Agent。刚开始玩多 Agent 的时候很容易有种错觉，两个能提速，八个岂不是起飞？实际不是这样。Agent 越多，人需要管理的东西也越多——这个在干什么、那个做完了吗、这个为什么停了、那个需要 Approval 吗、刚才是哪个让我确认的、这个结果和那个是不是冲突了。最后你会发现，AI 在写代码，你在调度 AI，注意力反而被吃得更快。所以我目前觉得比较舒服的区间是 2～4 个，再多的话，如果没有一个好的管理方式，人是扛不住的。

这也是我后来为什么自己做了个工具

多 Agent 用久了以后，我发现 Terminal 本身其实没什么问题，问题是 Terminal 管的是进程，而我真正想看的是 Agent 的状态。比如我更想一眼看到的是"Frontend Agent 在跑、Backend Agent 在等审批、Reviewer 已经完成、Tests 出错了"，而不是打开四个长得一模一样的 PowerShell 窗口自己去猜。另外一个我特别烦的问题是 Approval：几个 Agent 一起跑的时候，经常是 A 在工作、B 在工作、C 十分钟前就已经卡在等你点批准了，你自己都没意识到。

所以我后来给自己做了一个桌面工具，叫 Agent TUI Manager，本质上就是把我这套 Multi-Agent 工作流里比较机械的那部分集中起来管理。

项目地址：https://github.com/MulaLee4851/AgentTuiManager

具体来说，它现在主要帮我解决这几件事：

一个窗口能看到所有 Agent 的实时状态——正在运行、等待审批、已完成、异常退出，不用再靠切换 Terminal 一个个确认；多个 Agent 的审批请求会统一汇总到一处处理，重复出现的低风险操作可以设规则自动放行，真正有风险的操作还是会被拦下来，而不是图省事直接全开权限；能明确区分"正常结束""主动停止""异常退出"这几种状态，不用再对着一个不动的窗口自己猜到底发生了什么；接了钉钉 Stream，人不在电脑前也能远程看 Agent、处理审批、继续发任务，毕竟很多所谓的"无人值守"其实是假的，Agent 大部分时间都停在等审批上。

另外一个我自己用得比较多的功能，是每个窗口可以单独配置模型——baseUrl、API Key、模型本身，甚至走哪个网络出口代理都能按窗口分开设置。我自己手上有公司的 Key 和自己的 Key，做公司项目的窗口就绑公司的配置和代理，做自己项目的窗口就绑自己的账号，两边完全隔离，不用来回改配置文件，也不用担心手滑把请求发错账号。

我做这个工具的时候比较在意的一点是：不要为了 Manager 改变原来的 Agent。Claude Code 还是 Claude Code，Codex 还是 Codex，我不希望为了用这个 Manager，又必须绑定一套专门的 Session。所以目前 Agent TUI Manager 仍然完全保留官方 CLI 的原生 Session，以后不想用 Manager 了，照样可以用 codex resume <session-id> 或者 claude --resume <session-id> 继续之前的会话。这一点对我自己挺重要的，因为工具应该是改善工作流，而不是绑架工作流。

Claude Code 和 Codex 到底应该怎么分工？

这个问题我觉得没有标准答案。我自己现在不太纠结"Claude 一定负责什么、Codex 一定负责什么"，更倾向于先定义好角色——Explorer、Implementer、Reviewer、Fixer，然后再根据当前任务、模型表现、上下文情况、自己手上的额度，决定具体用谁来跑。简单说就是 Agent 角色优先于模型品牌。

相比纠结"到底 Claude Code 强还是 Codex 强"，我现在更关注的是怎么把一个软件需求拆成适合 Agent 独立处理的任务，这个能力我觉得反而越来越重要。

我现在一套完整的工作流

最后总结一下。如果今天来了一个稍微复杂一点的需求，我一般会这么走：先让 Explorer 分析代码、不动手写，找到影响范围和实施路径；接着 Implementer 根据需求和分析结果完成实现；然后 Reviewer 重新从原始需求出发做一遍 Review，不预设 Implementer 一定是对的；再由 Fix / Test Agent 处理 Review 提出的问题，跑测试、跑 Build、查 Diff；最后由人来最终确认，看一眼关键代码和整体结果。其中分析类的任务经常并行跑，真正涉及同一批代码修改的地方会控制并发。

这一套走下来，比"给一个超级长 Prompt 让一个 Agent 从头干到尾"要稳定不少。