同时跑多个 Claude Code / Codex 后，真正的瓶颈不是模型，而是“阻塞”

MulaLi_

301人浏览 · 2026-09-04 14:05:29

MulaLi_ · 2026-09-04 14:05:29 发布

"Claude Code / Codex 已经够强了，我为什么还要给它们再做一个 Manager？"

最近我突然发现一个挺有意思的问题。

Claude Code、Codex 已经越来越强了。以前一个需求，我可能要自己看代码、找入口、写代码、改 Bug、跑测试、Review 一路做下来。现在很多事情一句话扔给 Agent："帮我把这个功能实现一下，尽量保持现有代码风格，最后跑一下测试。"然后它自己就开始搜索代码、读文件、改代码、跑命令、修问题、继续执行。

按理说，Agent 越强，人应该越轻松才对。但我实际用了一段时间以后，发现情况有点不一样。尤其当我开始同时跑 Claude Code 改前端、Codex 改后端、再开一个 Codex 做 Review、另外一个 Agent 跑测试之后，我发现新的瓶颈出现了——而且这个瓶颈不是模型。

最大的问题变成了：Agent 在等我

举个我自己经常遇到的场景。我开了三个 Agent，然后想着让它们自己跑吧，我去干点别的。过了二三十分钟回来，本来以为差不多该做完了，结果一看：Agent A 完成，Agent B 还在 Working，Agent C 停在 Please approve。再仔细看时间戳，Agent C 十八分钟前就已经在等我了。

也就是说，我以为它工作了二十分钟，实际上真正干活的时间只有 2 分钟，剩下 18 分钟都在等我点批准。这种事情一个 Agent 的时候还好，三个、四个同时跑以后，就特别明显。

AI 没偷懒，是我变成瓶颈了

以前开发效率的瓶颈可能是"我写代码太慢"，现在变成 Agent A 需要 Approval、Agent B 已经做完、Agent C 异常退出、Agent D 还在 Running，而我需要不停 Alt+Tab、看 Terminal、再 Alt+Tab、找另一个、再切回来——哦，这个在等审批。

到这里我才意识到，Coding Agent 本身越来越强以后，人可能反而会成为整个工作流里最慢的一环。AI 在写代码，人负责看状态、点批准、处理异常、继续任务、记住每个窗口在干什么。有点像是 AI 在干活，我在值班。

我一开始也想过：那就直接全自动不就好了？

最简单的解决方案当然是 Full Auto、YOLO，自动批准所有操作，这样 Agent 就不用等我了。但我自己一直不太喜欢这种方式，原因其实很简单——git status、git diff、npm run test、npm run build 这类操作，和大量删除文件、严重权限修改、下载未知内容后直接执行、修改关键系统配置这类操作，明显不是一个风险级别。

所以我的想法一直是：不是"要不要自动化"，而是"哪些东西值得自动，哪些东西必须让人看一眼"。低风险、重复出现的东西可以尽量减少确认，真正危险的东西还是应该拦下来。

于是我给自己做了个 Agent"值班室"

后来我干脆写了一个小工具，叫 Agent TUI Manager。

GitHub：https://github.com/MulaLee4851/AgentTuiManager

它不是一个新的 Coding Agent，也不会替代 Claude Code、Codex、Pi。我做它的目的其实特别简单——把这些已经很好用的 Agent 放到一个地方统一看着。现在我的工作方式更像是打开一个面板，一眼看到 Frontend 在 Working、Backend 在 Waiting、Review 已经 Finished、Test 出了 Error。我不需要再去记"第三个 PowerShell 是干什么的"，只需要知道哪个 Agent 现在需要我。

第一个功能：多 Agent 总览

这个是我自己每天用得最多的。以前同时开几个 Agent，看到的是四个长得一样的 Terminal 窗口；现在看到的是每个 Agent 各自的状态——谁还在跑，谁已经结束，谁异常了，谁需要处理，一眼就够。区别看起来不大，但多 Agent 用久了会发现，我真正关心的是 Agent 状态，而不是 Terminal 窗口本身。

第二个功能：把 Approval 集中起来

这是我做这个工具最直接的原因之一。以前每个 Agent 需要审批时都得自己去找；现在所有 Agent 的审批请求会汇总到一个处理中心，哪个需要人工确认都能集中看到。一些低风险、重复出现的操作可以通过规则减少重复批准，但我没有做成"所有东西全部放行"，高风险行为依然需要保留安全限制。

我比较希望达到的状态是：90% 没必要打断人的操作自动处理，10% 真正需要人判断的操作找我——而不是 100% 都问我，或者 100% 都不问我。

第三个功能：Agent 停了，至少告诉我它为什么停

这个也是多 Agent 以后特别烦的一件事。一个 Terminal 不动了，可能是完成了，可能是等输入，可能是等 Approval，也可能是主动停止或者进程异常。一个 Agent 的时候还好自己看，四五个以后真的很烦。所以 Manager 会区分这些 Agent 的生命周期状态，至少不用再通过"Terminal 最后一行是什么"去猜"这个 Agent 到底还活着没有"。对于异常退出，我也不喜欢直接无脑发一句 continue，因为异常原因不确定，先判断状态再决定怎么恢复，至少会稳一点。

后来我甚至把钉钉也接进去了

这个功能最开始纯粹是因为我懒。我想解决一个很具体的问题：人不在电脑前的时候，Agent 能不能别因为一个 Approval 停半小时？所以后来接了钉钉 Stream，现在可以在手机上看 Agent、看待处理事项、批准或拒绝、给 Agent 发消息、停止或重启、查看审计。

理想情况就是上班启动几个任务，Agent 自己跑，我去开会、吃饭、干别的，正常情况完全不用找我，真的遇到需要人工判断的节点，手机处理一下再继续。我现在觉得这才比较接近真正的"让 Agent 自己干活"。

还有一个我比较坚持的：不要绑架原生 CLI

因为我本身就喜欢 Claude Code / Codex 的 TUI，所以我没有想过再重新造一个 AI Chat UI。原来的 Agent 怎么显示还是怎么显示，原来的 CLI 还是原来的 CLI，原来的 Session 也还是原来的 Session——Agent TUI Manager 不会把 Claude Code / Codex 的历史转成自己的一套私有格式。哪天不想用这个 Manager 了，回 Terminal 用 codex resume <session-id> 或者 claude --resume <session-id>，原来的东西还能继续。

我自己比较讨厌一种开发工具：用起来很爽，但一旦用了以后就离不开它自己的数据格式。所以这里我一直希望 Manager 可以随时被替换，但你的 Agent Session 不应该跟着消失。

我也专门做了安装包

这个事情看起来很小，但我自己作为用户其实特别烦：看到一个 GitHub 项目，觉得挺有意思，打开 README，clone、npm install、Python、pip、环境变量、编译原生依赖、改配置文件……然后就放弃了。所以 Agent TUI Manager 现在 Windows 和 macOS 都直接提供安装产物，Windows 直接下载安装包，macOS 也有 Intel / Apple Silicon 对应版本。本机已经有 Claude Code / Codex 的话，装完就可以开始添加 Agent。我觉得工具真正想让别人用起来，安装这一步最好不要成为技术挑战。

这个东西现在适不适合你？

我觉得其实挺好判断。如果你平时只开一个 Claude Code，偶尔问两句，Terminal 用得非常舒服，那我觉得没必要装，一个 Terminal 真挺好的。

但如果你已经开始 Claude 写前端、Codex 改后端、再开一个 Agent 做 Review、另一个跑测试，然后天天找窗口、看状态、找 Approval、处理异常，那这个工具可能比较适合你。它真正解决的不是"Agent 不够强"，而是"Agent 已经强到你开始同时用好几个以后，怎么别让自己变成新的瓶颈"。

项目已经开源

项目：Agent TUI Manager GitHub：https://github.com/MulaLee4851/AgentTuiManager

目前主要支持 Claude Code、Codex、Pi，平台覆盖 Windows、macOS Intel、macOS Apple Silicon。目前主要在做的是多 Agent 总览、集中 Approval、审批安全规则、异常状态与恢复、独立 Agent 配置、钉钉远程值班、原生 Session、No lock-in 这几块。

项目还比较早期，不过这不是一个我为了"做开源项目"想出来的东西，是我自己同时跑 Agent 以后受不了现在这套操作方式，先做出来给自己用，后来觉得也许其他重度 Claude Code / Codex 用户也会遇到一样的问题，所以才开源出来。