引子:先被自己的一堆 AI 搞乱套

最近的工作流变成这样:终端里同时开着几个 AI agent,Claude Code 在改这个项目,Codex 在跑那个调研,另一个在出内容。多项目并行,终端是主场。

然后问题来了:我根本不知道哪个 agent 卡住了、在等什么、干完没有。 我试过 tmux,用了一阵子就扔了(下面会说为什么)。后来换成 herdr,鼠标点选、agent 状态、关终端恢复,三点都舒服。但"舒服"不等于"最优"——我有个习惯,用着顺手的东西也要横向验证一遍,顺便看看有没有更合适的。

于是我把四个"管 AI agent 的终端"从头到尾扒了一遍:tmux(基准线)、herdr、codeg、agent-deck。全部拉真实 README、许可证全文、技术栈文件、官方文档,能实测的实测。这篇是结论。

先分清物种:四个东西根本不是一回事

tmux 管的是"终端",herdr 管的是"agent 的终端",agent-deck 是"agent 部队的指挥台",codeg 是"agent 版的 IDE 工作区"。

• tmux(2007 年,C 语言,48.5k 星):通用终端多路复用器,server/client 模型,session/window/pane。脱离重连是它的看家本事。但它不认识 agent——它只知道进程和格子。我用它时的体验:开三个 pane 跑三个 agent,轮流切过去看哪个在等我批准,纯靠手动。
• herdr(2026 年,Rust,27.3k 星):官网原话是"the runtime your coding agents live on"。后台 server 拥有真实终端,UI 只是客户端,关了客户端 agent 照跑。它知道哪个 pane 里是 agent、agent 现在是什么状态。
• agent-deck(2025 年,Go,705 星):一个 TUI 管所有 agent session,conductor 编排 + git worktree 隔离。注意它底层还是依赖 tmux。
• codeg(2026 年,Tauri,2.6k 星):GUI 桌面工作区,把所有 agent 的历史会话聚合进一个可搜索 workspace,内置完整 git 客户端,还有手机客户端。

分水岭:它知不知道 agent 卡住了

这是整件事的核心,也是 tmux 和另外三个的分界。

tmux 的哲学是"持久化终端,不管内容"。herdr 官网对比页有一句话特别到位:“Multiplexers persist terminals, not agents… tmux sees panes.”——多路复用器持久化的是终端,不是 agent;tmux 只见格子。

herdr 原生区分五种状态:idle(干完了)、working(正在干)、blocked(卡住等你输入或批准)、done(干完你没看)、unknown。状态会往上层滚动——一个 agent blocked,它的 pane、tab、整个 workspace 都显示 blocked,点一下直接跳过去。

tmux 想要这个能力行不行?行,但全是 hack。生态里已经有 tmux-agent-status、tmux-ccm、ClawTab 这些插件,原理是给 Claude Code 挂 hooks,或者用 capture-pane 定时读屏幕,把状态画到 status line 上。能做到"程序性"的状态提示(BUSY/IDLE),但做不到"语义性"的状态判断——它不知道 agent 是"合理地在等一个长任务"还是"真卡死了"。而且 tmux-ccm 这类方案要你手动往 ~/.claude/settings.json 里加 hooks。

让 agent 互相派活

多 agent 的价值不只是并排跑,而是互相协作。三家路子不一样:

• herdr:agent 自己通过 CLI 和 socket API 驱动 herdr——README 原话:“agents drive herdr through the cli and socket api: they can spawn panes, prompt each other, and wait until another agent is genuinely blocked”。一个 agent 可以给另一个 agent 的 pane 发消息,等它真正 blocked 再接手。
• codeg:lead agent 用 @ 提及把任务委派给别的 agent,并行执行,结果流回主会话。走的是 ACP 协议(下面细说)。
• agent-deck:conductor 是个常驻的"指挥 agent",盯着所有 session,能自己处理的自己处理,处理不了升级给你。
• tmux:没有这回事。派活 = 你手动开 pane、手动发命令、手动读输出。

关掉终端以后还剩下什么

这是"关终端恢复"的深度对比。herdr 的 session.json 存 workspace/pane 拓扑和每个 pane 的工作目录,ctrl+b q 脱离,重开 terminal 直接 herdr 重连,历史回放还原画面。tmux 靠 resurrect + continuum 插件也能做到"程序还在、目录还在、布局还在"——但那是恢复进程,不是恢复对话上下文。codeg 更进一步,把历史会话聚合进可搜索工作区,原地续接。agent-deck 用 SQLite 存 session 记录,可归档。

实测里(见下),herdr 的配置目录非常干净:~/.config/herdr 下只有 socket、日志、session.json 三个东西。

手机遥控:只有 codeg 原生支持

如果你要在手机上发任务、批准权限、看实时输出——tmux 和 herdr 都做不到(herdr 只能 SSH 回连自己操作)。agent-deck 支持 Telegram + Slack。codeg 是唯一原生支持 Telegram / 飞书 / 微信三条渠道的,手机 app 直接点批准,还能扫码连 web service。我自己已经有 Hermes 走 Telegram 的成熟通路,这条暂时不是刚需,但如果你要,“手机遥控"就是 codeg 的独家卖点。

隐私:我踩过的雷和不踩的雷

这块我特别在意,因为我不接受工具自动读写我的认证、密钥、代理配置文件。

• herdr:我把整个集成模块的源码 grep 了一遍,没有任何对 ~/.claude.json 的引用。它只在你显式跑 herdr integration install claude 时,往 Claude Code 的 settings.json 里写一个状态上报 hook,可一键卸载。实测环境里 ~/.claude.json 的 mtime 有变化,但那是测试环境里 Claude Code 会话自己写的,herdr 源码零引用。想自己验证很简单:stat ~/.claude.json 记下 mtime,跑完 herdr 再 stat 一次。
• codeg:本地优先、无遥测,但会把 SSH keys 和 API keys 收进自己的加密 SQLite 库——它不读你的配置文件,但会"复制"凭据进自己的库,可接受与否自己掂量。
• agent-deck:这是雷。它的 ACP/MCP 集成会读共享的 auth 目录,还可能灌进 Docker 容器环境变量。对"不接受工具自动碰认证文件"的人来说,这一条直接出局。
• tmux:零隐私侵入(它根本不碰凭据),但也因此没有权限概念,server-access ACL 默认不启用。

实测 herdr(本机 WSL)

说再多不如跑一遍。我在 WSL 里装了 herdr 0.8.0 实测:

• 安装:直接下 GitHub release 的 Linux x86_64 二进制到 ~/bin,一条命令,不碰系统。
• herdr server 起无头服务,自动生成 ~/.config/herdr/session.json。
• CLI 全部可用:herdr workspace create --cwd /tmp --label test-ws 建 workspace、herdr agent list 列 agent、herdr pane list 列 pane,都能正常返回。
• 内存占用:RSS 16MB。 对 CPU/内存都敏感的人来说,这是很舒服的数字。
• 没开 agent 时 agent list 是空的、状态是 unknown——状态检测要等 pane 里有 agent 跑起来才激活,合理。
• 小插曲:CLI 的 herdr agent list 没有 --json 参数,和文档写的有点出入,小问题,不影响使用。

为什么这个品类现在才火:ACP 协议

四家里 codeg 是唯一走 ACP 的。ACP(Agent Client Protocol)是 Zed 在 2025 年发起的开源协议,解决"编辑器 ↔ agent"之间的通信标准化——编辑器负责聊天 UI、diff 预览、权限弹窗,agent 负责推理、调工具、改文件,两边用 JSON-RPC 说话。JetBrains 很快跟进,Google(让 Gemini CLI 接了)、Anthropic(给 Claude Code 出了 ACP 适配器)、OpenAI(Codex CLI 适配器)都入场了;agent 这边 Claude Code、Codex、Copilot CLI、OpenCode、Gemini CLI、Cursor、Pi 都支持。

ACP 和 MCP 是两层:MCP 管"agent ↔ 工具”,ACP 管"编辑器 ↔ agent",互补不冲突。这里也看出四家的协议取向:codeg 押 ACP,agent-deck 用 MCP,herdr 用自家 socket API,tmux 只能靠外部适配器。

而整个"管 agent 的终端"品类在 2026 年集中爆发不是偶然:多 agent 并行需求起来了(Conductor、Emdash、Superset 全都围绕 git worktree 隔离做多 agent);终端成了 agent 的主场(Warp 的 Agent Mode、Zellij 的 zj-agents 插件都在往"终端里管 agent"挤)。最根本的:当你有好几个 agent 同时干活,你最缺的不是更多终端,是"一眼看穿谁卡住了"的能力。herdr 就是在补这个洞。

各自适合谁

• 坚守 tmux 的人:老 Unix 派、把 tmux 当"SSH 上挂长任务的守护"、不接受多一个二进制、不在乎 agent 语义、愿意花时间配置。resurrect/continuum 已经把"重启恢复"做到 90 分,如果你只需要这个,tmux 就够,不用换。
• herdr:终端党、多 agent 并行、鼠标比键盘多、隐私敏感、主力 Claude Code / Codex / Hermes 系。想要 tmux 的底子但不想学 tmux 的概念负担。
• codeg:要 GUI 工作区 + 完整 git 客户端 + 手机遥控(TG/微信/飞书)的人,能接受桌面 app 常驻资源。
• agent-deck:键盘党、要 conductor 自动编排 + fork 继承上下文 + 成本追踪的高级玩法,不介意底层依赖 tmux。隐私敏感者绕道。

我的选择

终端主力继续 herdr,这次理由是全的:状态感知原生、agent 互派活、关终端恢复、鼠标优先、16MB 内存、不碰我的认证文件——前三点是我实际用出来的,后三点是实测+源码验证出来的。

codeg 留着当"手机遥控"的候选:哪天需要从手机发任务、点批准,它是我看到的唯一原生支持。但它是桌面 app,常驻资源最重,而且会把 agent 凭据收进自己的库,我不会让它常驻。

agent-deck 因为隐私那条,直接出局。tmux 留着在服务器上挂长任务,“agent 管理器"这个角色它确实不是那个物种。

如果你也在终端里跑着一群 AI,给你一条可执行的建议:先分清你要的是"终端不死"还是"agent 不死”——前者 tmux 就够,后者从 herdr 开始试,别从 tmux 开始。

附:调研方法与来源

本次调研:四个项目逐一拉取 GitHub README 全文、许可证全文(LICENSE/COPYING 整文件,不是只看标签)、技术栈文件、官方文档页(herdr.dev/docs、docs.codeg.app),GitHub API 实测星数 / issue / 最近 release(2026-08-11),本机 WSL 实测 herdr 0.8.0;ACP 协议与生态用 Tavily + Grok 双引擎交叉检索。主要来源:

• herdr:github.com/herdrdev/herdr、herdr.dev 的 README / compare / docs/agents 页,src 源码模块
• codeg:github.com/xintaofei/codeg、docs.codeg.app 的 multi-agent / chat-channels / privacy 页
• agent-deck:github.com/asheshgoplani/agent-deck
• tmux:github.com/tmux/tmux 的 README / tmux.1 / CHANGES,以及 tmux-plugins 的 tpm / resurrect / continuum
• 生态:Zed(ACP 协议)、Zellij、cmux、Warp、Conductor、Emdash、Superset、OpenClaw
• 数据:GitHub API 2026-08-11 实测(星数 / fork / issue / release 日期)

完整报告(含全部数据与逐项取证)已存档。调研过程中也常在 Linux.do 和 Telegram OpenClaw 中文社区讨论,两个社区都值得逛。