一个人对着四个终端窗口,分别开着 Claude Code、Codex、OpenCode、Grok Build,写代码的速度确实上去了。问题是,四个代理里有一个卡住了,你可能十分钟后才发现——它不会主动喊你,只会在某个标签页里安静地等着。
这就是开源工具 Agent Manager 要解决的事。它用 tmux 把这几款编码代理装进同一个终端界面,状态、提示、代码改动都在一个列表里看完,不用在多个终端标签间来回切换。
它到底解决了什么
每个代理会话跑在独立的 tmux session 里。退出 Agent Manager,会话照样在后台干活;断线了,一键就能恢复。
核心功能只有三件:状态汇总、按项目分组发提示、代码改动实时审查。选中一个会话按空格,提示直接发进对应窗格,不用手动 attach。改动出来了,打开全文 diff,逐行写评论,评论自动打包发回给代理,让它当场改。
状态识别不是所有工具都一样可靠。
| 工具 | 状态识别方式 | 可靠性 |
|---|---|---|
| Claude Code | 通过 hooks 主动上报状态 | 相对可靠 |
| Codex / OpenCode / Grok Build | 正则匹配终端文字 + 定期轮询 | 靠“看字面推断”,复杂输出容易误判 |
平台上,Agent Manager 依赖 tmux,原生只支持 macOS 和 Linux,Windows 用户得绕道 WSL2。
谁该装,谁不用管
同时并行跑三四个编码代理、需要来回审查的重度用户,这工具能省下不少切换终端的时间,值得装一个试试。
只开一个 AI CLI 慢慢聊的开发者,基本用不上——单会话状态一眼就能看清,没必要多装一层 TUI。
Windows 用户如果不想折腾 WSL2,可以先观望,等社区出原生适配再动手。
从现有功能看,它更像个人本地工具,没有权限隔离或多人协作的迹象,团队想拿它当任务调度平台用,还得再等等。
我的判断
这类工具冒出来,说明一件事:编码瓶颈正在往后挪。以前卡在“AI会不会写代码”,现在卡在“人有没有精力盯着、审着、管着上下文”。
会写和写得对是两回事,AI程序员开再多,验收的人只有一个。多开几个代理,审查负担、资源占用、上下文切换的成本是同步涨的,不是白捡的产能——这一点 Agent Manager 自己也解决不了,它只是把管理成本从“到处找”变成“一眼看”。
风险提示:靠正则猜状态的工具,遇到复杂输出容易把“卡住”看成“完成”,重度依赖状态列表做决策,最好留个心眼,手动瞟一眼终端。
接下来该看的不是哪个模型分数又高了,而是有没有工具能把多代理调度做成原生能力——不靠 tmux 和正则表达式硬凑,状态上报也不用一半工具自觉、一半工具靠猜。