agent-manager：用tmux统一管理多个AI编程助手的开源工具

当多个编程助手同时工作，管理成了新痛点

随着 Claude Code、Codex、OpenCode 等命令行编程助手（coding agents）的普及，越来越多开发者开始尝试同时运行多个 agent 并行处理任务。这里所说的 coding agents，是指能够直接在终端中读写文件、执行命令并进行多步推理的 AI 编程助手。Claude Code 是 Anthropic 推出的商业产品，Codex 是 OpenAI 的终端 agent 工具（强调沙箱执行和安全性），OpenCode 则是社区驱动的开源替代方案。它们的共同特征是以终端为主要交互界面，通过自然语言指令驱动代码生成和修改。这三者分别代表了商业闭源、商业开源和社区开源三种路线，但在开发者的日常使用中，往往会根据任务特点混合使用。

但一个意料之外的问题随之浮现：真正吃掉时间的往往不是写代码本身，而是管理这些 agent 的状态。

一位开发者在 Reddit 上分享了他的困扰：他习惯同时开三四个 agent，但如果不逐个切换终端标签，就完全无法知道每个 agent 处于什么状态。更糟的是，常常有某个 agent 已经卡在权限确认提示框上十几分钟，而他毫不知情。为了解决这个问题，他写了一个开源工具——agent-manager。

agent-manager：基于 tmux 的轻量 TUI 管理工具

agent-manager 是一个用 Go 编写的二进制程序，它构建在 tmux 之上。tmux（terminal multiplexer）是一个终端复用器，允许用户在单个终端窗口中创建、管理和切换多个会话。它最核心的特性是会话持久化——即使关闭终端窗口，tmux 中运行的进程也不会终止。tmux 的架构由 server、session、window 和 pane 四层组成，其中 pane 是最小的执行单元。这种架构天然适合作为 agent 管理的底层基础设施，因为每个 agent 可以独立运行在各自的 pane 中，互不干扰且生命周期完全独立于管理界面本身。

agent-manager 的设计理念非常克制：没有配置文件、没有常驻守护进程（daemon），完全免费且开源。它采用 TUI（Text-based User Interface）作为交互范式——这是一种介于纯命令行和图形界面之间的界面形式，在终端中通过字符绘制出类似 GUI 的交互元素（列表、按钮、高亮等）。Go 语言生态中有 Bubble Tea、tview 等成熟的 TUI 框架，使得构建这类工具变得高效。相比 Web UI 或 Electron 应用，TUI 的优势在于零依赖、启动即用、资源占用极低，且天然贴合开发者的终端工作环境，不需要切换上下文。

它的核心价值在于把所有正在运行的 agent 汇总到一个统一的列表中，每个 agent 旁边都显示实时状态，并按照它们所处理的项目进行分组。无论你运行的是 claude、codex 还是 opencode，它们都会以相同的方式呈现在同一个界面里。

这种统一性对于混合使用多种工具的开发者尤为重要。作者提到，他会根据不同任务在这三种 CLI 之间切换，而 agent-manager 让它们在视觉和操作上保持一致。如果想接入新的 CLI 工具，也只需要在一个 toml 文件里添加几行正则表达式即可——这些正则用于匹配 agent 输出中的状态标识（如等待输入、正在执行、已完成等），从而让管理器能够自动判断每个 agent 当前所处的阶段。

无需切入终端即可回复 agent

作者最常用的功能是空格键交互。在列表中选中某个 agent，按下空格，输入内容后回车，指令就会直接送入该 agent 的 pane（窗格）中。整个过程完全不需要 attach 到具体终端。这里的 attach 是 tmux 的核心操作——通常你需要执行 tmux attach -t session_name 才能进入某个会话并与之交互，而 agent-manager 通过 tmux 的 send-keys API 绕过了这一步骤，实现了在不切换上下文的情况下向任意 pane 发送输入。

用过 Claude Code 里 agents 视图的用户会觉得这个操作很熟悉。但 agent-manager 的差异在于：同样的一个按键，也能作用于 codex 或 opencode 会话，打破了单一工具的限制。

如果把光标停在项目行上再按空格，则会创建一个新的 agent，并让它立刻开始处理你刚输入的任务——相当于一键派发新工作。

代码审查工作流：落地前先审阅 diff

除了状态管理，agent-manager 的另一半价值在于代码审查体验。

因为底层就是 tmux 会话，所以关闭管理器并不会杀掉任何正在运行的 agent。如果某个会话意外中断，按 v 就能把它连同完整的对话历史一起恢复回来。这种「进程与界面解耦」的设计，避免了管理工具本身成为单点故障。这一设计哲学与 Unix 传统一脉相承——进程的生命周期不应依赖于特定的前端界面，正如 nohup 和 screen 所体现的理念。

用 ctrl+r 查看完整函数上下文而非碎片 hunk

真正体现审查思路的是 ctrl+r 快捷键。它会把某个 agent 改动的内容以完整文件的形式打开，并高亮显示 diff。作者特别强调：这样你读到的是完整的函数上下文，而不是传统 diff 工具里割裂的一个个 hunk（差异块）。

传统 diff 工具（如 git diff）以 hunk 为单位展示变更，每个 hunk 通常只包含改动行及其前后各三行的上下文。这种展示方式在人工编写的小幅改动中效果良好，但当 AI agent 进行大范围重构时——可能同时修改一个函数的签名、内部逻辑和调用方式——割裂的 hunk 让审查者难以理解改动在整个函数或模块中的语义位置和全局影响。以完整文件加高亮的方式展示 diff，本质上是将代码审查从「逐块确认」升级为「全局理解」，更适合 AI 生成代码的审查场景。

更巧妙的是评审闭环：你可以在某一行留下评论，这条评论会自动回传到该 agent 的 pane 中。于是当你还在继续往下滚动审阅时，agent 已经开始根据你的意见修复了。这种「边看边改」的异步协作方式，把人类的审查判断和 agent 的执行能力衔接得相当自然。

多 agent 并行场景设计，单 agent 同样实用

有意思的是，作者坦言虽然这个工具是为「同时跑四个 agent」的场景设计的，但大多数日子里他其实只用它管理一个 agent。这说明 agent-manager 解决的核心问题——状态可见性和落地前审查——即便在单 agent 场景下也具有实用价值。

作者也很诚实地表示工具「在一些地方还很粗糙」，并邀请同样以这种方式使用 agent 的开发者反馈缺失的功能。

趋势观察：agent 编排正在成为新的开发界面

agent-manager 反映出一个值得关注的趋势：随着 AI 编程助手能力增强，开发者的工作重心正从「亲自写代码」转向「编排和监督多个 agent」。当 agent 数量增加，人类的瓶颈不再是编码速度，而是注意力的分配——如何知道哪个 agent 卡住了、哪个需要确认、哪个已经产出了值得审查的改动。

agent 编排（orchestration）的概念源自容器编排领域（如 Kubernetes 之于容器），核心思想是将多个自主执行单元的生命周期管理、状态监控和任务调度抽象为统一的控制平面。在 AI agent 领域，类似的编排需求正在快速涌现：微软的 AutoGen、CrewAI、LangGraph 等框架解决的是 agent 之间的协作逻辑编排——即如何让多个 agent 分工协作完成复杂任务；而 agent-manager 解决的则是人类开发者与多个独立 agent 之间的交互界面问题——即如何让一个人高效地监督和指挥多个并行工作的 agent。两者互补而非竞争，分别对应了「agent-to-agent」和「human-to-agents」两个维度的编排需求。

这类工具的出现，本质上是在为「人机协作的多进程编程」构建新的操作界面。tmux 作为底座提供了稳定的会话管理，而 TUI 层则负责把分散的状态聚合成可一览、可介入的视图。可以预见，随着更多开发者采用多 agent 工作流，类似 agent-manager 这样的编排层工具会成为一个新的、值得深耕的细分方向。未来这一领域可能会进一步分化：轻量级的如 agent-manager 面向个人开发者，而更重量级的平台可能会整合任务队列、冲突检测（多个 agent 修改同一文件）、资源配额管理等企业级功能。

核心要点