Herdr：Agent 终于等到了自己的终端调度台

你在 tmux 里开了三个 Agent。Claude Code 在改后端 API，Codex 在修前端组件，Aider 在重构单元测试。一切看起来很和谐。

十分钟后你切回去看，Claude Code 卡在了一个权限确认弹窗上，已经等了八分钟。Codex 早跑完了，在那里空转。Aider 输出了三十行错误日志然后挂起，你完全不知道。tmux 面带微笑地看着这一切，因为它只负责管终端，不管终端里跑的是人还是 Agent。

这不是操作失误。tmux 和 Zellij 从设计之初就假设每个 pane 里是一个人在敲命令。人知道自己卡住了，知道自己跑完了，知道什么时候该切窗口。Agent 不知道。Agent 需要外部信号告诉它这些，而传统终端复用器给不了。

herdr 做的事情很简单：把 tmux 那套终端会话管理，从”给人用的”改成”给人和 Agent 一起用的”。它跟踪每个 pane 里 Agent 的状态，暴露 API 让 Agent 互相协作，把持久化做到 Agent 会话级别。这篇文章就想回答一个问题：这个差异化设计，值不值得你从 tmux 切过来。

打动我的几个地方

herdr 跟 tmux 的差距不在功能数量上，在底层假设上。tmux 假设每个 pane 里坐着一个人类用户，有手有眼睛。herdr 假设每一个 pane 的使用者可能是人，也可能是一个正在执行任务的 AI Agent，甚至是另一个 herdr pane 里跑着的 Agent 发来的 API 调用。这个假设改变了一切。

Agent 状态感知是 herdr 真正有区分度的能力。每个 pane 不只是一块终端输出，它有一个状态标签：blocked 表示 Agent 卡在输入确认上等待人类干预，working 表示正在执行中，done 表示任务完成，idle 表示闲置。侧边栏实时刷新，颜色区分状态。你不需要挨个 pane 切过去确认进度，扫一眼就知道谁在干活、谁在摸鱼、谁需要你帮忙。这个设计简单到你第一反应是”tmux 为什么不做一个”，但 tmux 确实没做。

herdr 的三层组织（workspace、tab、pane）和 Agent 状态流转构成了它区别于传统终端复用器的核心架构。workspace 是项目级隔离容器，一个项目一个 workspace，互不干扰；tab 在 workspace 内做任务分组，比如”后端开发”和”代码审查”可以是两个 tab；pane 是真实的终端进程，每个 pane 里跑一个 Agent 实例。侧边栏的 blocked、working、done、idle 四个状态标签贯穿所有层级。

Agent 可以反过来控制 herdr。这也是它跟所有终端复用器最根本的区别。herdr 提供了 CLI 和本地 Socket API，一个 Agent 可以自己创建 pane、读取另一个 pane 的输出、等待某个 pane 完成后继续执行、拆分窗口布局。你能让 Agent 跑一个工作流脚本：先开一个 pane 跑后端测试，等测试全绿后，在另一个 pane 里自动执行部署。这不是给人用的快捷键宏，是给 Agent 的程序化控制面。

持久化不止于终端输出。herdr 的 detach 和 reattach 比 tmux 多走了一步：连接的不仅是终端内容，还有 Agent 的运行时上下文。断开客户端，后台 server 和所有 pane 里的 Agent 进程继续跑。支持 SSH 远程重连、命名 session 做独立运行时隔离。对于通过官方集成接入的 Agent（Claude Code、Codex 等），herdr 甚至能在 server 重启后恢复原生 Agent 会话。这是 tmux 做不到的。

插件系统给了 herdr 一个 tmux 没有的扩展维度。herdr 把 CLI 和 Socket API 作为插件面，社区插件可以像 Agent 一样驱动 herdr：通知器、布局预设、链接处理器、Release 自动检查。插件市场正在建设，现在就能从 GitHub 提交和分享。它把终端复用从一个死工具变成了 Agent 工作流的可编程基础设施。在 tmux 里你得自己写 bash 脚本粘合一切，在 herdr 里这些可以是一个标准化的插件。

部署门槛低到几乎没有。Rust 编译出的单个二进制文件，不依赖 Electron，不需要特定终端模拟器，没有任何 GUI 包袱。安装覆盖 curl 一键脚本、Homebrew、mise、GitHub Releases 二进制。Windows 也已进入 beta。这个轻量架构对于一个面向终端重度用户的工具来说至关重要，尤其是当你需要在远程服务器、Docker 容器或者树莓派上跑它的时候。说了这么多设计层面的东西，实际上手是什么感觉？

跑起来看看

安装支持所有主流包管理器和平台，一行命令就能跑起来：

curl -fsSL https://herdr.dev/install.sh | sh

Homebrew 用户也可以 brew install herdr，mise 用户 mise use -g herdr，Windows 用户有一键 PowerShell 安装脚本，GitHub Releases 页面提供各平台预编译二进制，连 Rust 工具链都不需要装。

启动同样简单，一条命令进入 Agent 工作区，默认启动一个后台 server 并附着上去，在工作目录里跑就获得了一个 workspace：

herdr

ctrl+b shift+n 新建 workspace，ctrl+b v 或 ctrl+b - 分屏，ctrl+b c 新建 tab，ctrl+b w 切换 workspace。鼠标点击拖拽全支持，不用背快捷键也能上手。ctrl+b q 分离客户端，Agent 继续在后台跑，再跑一次 herdr 就重连回来。

有个细节值得一提。herdr 支持鼠标优先操作，这对刚接触终端复用器的人来说友好得多。点击 pane 切换焦点，拖拽边框调整大小，右键菜单完成分屏和切换。键盘党当然可以用前缀键操作，但对不熟悉 tmux 快捷键体系的人来说，鼠标支持省掉了大量学习成本。Zellij 也有类似的鼠标支持，但 herdr 的右键菜单做得更实用。

初次使用有几个容易踩到的点。

第一，herdr update 只更新二进制，旧 server 还在跑旧版本，需要手动 stop 旧 server 才能用上新版。

第二，实验性的 --handoff 命令号称能把活跃 pane 迁移到新 server，但官方明确标注仍不稳定。

第三，Agent 会话恢复依赖官方集成的深度，不是所有 Agent 都能在重启后完美恢复状态。重点关注你用的 Agent 在 herdr 文档的 Supported Agents 列表里的集成等级。

还有一个隐性问题值得提前知道。herdr 的更新频率很高，v0.7.3 是今天刚发布的版本，1063 个 commit 集中在不到四个月的时间里。这意味着 API 和配置格式可能在版本间变动。如果你打算把它嵌进 CI 流水线或者生产环境，建议锁定一个具体版本，等到了 v1.0 再考虑自动化升级。

什么时候用，什么时候别用

herdr 瞄着的是一个具体的工作状态：你的终端里同时跑着不止一个 AI 编码 Agent。如果你只是偶尔用 Claude Code 修个 bug，tmux 就够了。但如果你常态开着两三个 Agent 并行干活、需要一眼看到谁卡住了、需要让 Agent 之间能互相等待和触发，那 herdr 的设计是为你准备的。

不适用的情况也同样明确。你只是需要一个终端复用器，开几个 shell 跑常规命令，Agent 不是你的核心工作流，tmux 或 Zellij 完全够用，没必要为 Agent 专属功能切换。你在 Windows 上做重度开发，Windows 支持仍处于 beta 阶段，优先选择成熟方案。你需要图形化的 Agent 管理界面，herdr 定位在纯终端，不会出 GUI 版本。

herdr 在 Agent 状态感知、Agent API 和持久化三个维度上明显区别于传统终端复用器。tmux 和 Zellij 在终端持久化上做得很好，但对 Agent 一无所知；cmux 和 Warp 是终端应用，体验好但把你锁进了一个特定的终端环境。

不过有一类用户可能会低估 herdr 的价值：那些用 tmux 手动管理 Agent，但从来没意识到这个工作流可以更高效的人。你可能已经习惯了 tmux new-session、tmux attach、在 pane 之间切来切去确认状态，甚至不觉得这是痛点。一旦你试过 herdr 的状态侧边栏和 Agent API，回头再看手动管理，会有种”之前是在用马车送快递”的感觉。

社区怎么样了

herdr 的增长曲线是近期 GitHub 上最陡的之一。从 4 月初的 198 个 Star 到 6 月底的约 8000 个，两个月翻了 40 倍。这个速度放在任何开源项目里都算异常，放在一个终端工具上更不常见。

Stars 增速值得拆开看。198 到 8000 的增长不是靠一次 HackerNews 首页或者某个大 V 转发带来的脉冲效应，而是持续了两个月。这说明用户是在实际用过后 Star 的，而不是被标题吸引后点一下就走了。herdr 的 GitHub Issues 区活跃度也印证了这一点，功能请求和 bug 报告的质量都不低。

维护健康度方面，Bus Factor 是最大的风险。整个项目目前只有 ogulcancelik 一个人全职维护，1063 个提交集中在一个人手里。响应速度在单人项目中算快的，但一旦维护者因为任何原因减速，项目就会迅速停滞。好消息是赞助渠道已建立，GitHub Sponsors 和商业许可两条腿走路，全职开发有经济支撑。Terminal Trove 作为金牌赞助商也增加了可持续性。

社区声音方面，LinkedIn 上有用户写了一篇”为什么我从 tmux 切到了 herdr”的长文，核心观点是：herdr 保留了 tmux 真正有用的部分（真实终端 pane、持久化、detach/reattach、SSH 友好），同时把 Agent 不知道自己在干什么这个 tmux 的死角补上了。中文技术社区也出现了多篇深度分析文章，普遍认为 herdr 不是 tmux 的替代品，而是 AI 编码工作流催生的新工具品类。

值不值得跟

我对 herdr 的判断分成两层。第一层是关于这个品类的。AI Agent 会越来越多地出现在开发者的终端里，这件事已经没有争议。当终端里同时跑着不止一个 Agent 的时候，管理它们的工具必然会从”通用终端复用器”进化到”Agent 感知的多路复用器”。herdr 用不到四个月的时间证明了这个需求是真实的，不是某个开发者的自嗨。13k Stars 的同类项目在这个品类里还没有，herdr 在抢跑。

第二层是关于 herdr 这个具体项目的。我对它的架构方向是认可的：Rust 单二进制、终端原生、Agent 状态感知、Socket API 暴露控制面——这四条合在一起，构成了一个清晰的差异化价值。不是”比 tmux 多了几个功能”，而是”从底层重新定义了终端复用器的使用者是谁”。插件市场和 Agent API 把 herdr 从终端工具推向了 Agent 工作流的基础设施，这个扩展方向如果能做成，护城河会非常深。问题是，做成之前还有多少坑？我的顾虑主要集中在下面三点：

• 单人维护的风险。1063 个 commit 在一个人手里。当项目从 8000 星冲到 50000 星的时候，Issue 和 PR 的压力会指数级增长，一个人扛不住。
• v0.x 阶段的 API 变动风险。Socket API 和插件接口可能在版本间 breaking change，早期重度集成的人要做好适配成本的心理准备。
• AGPL-3.0 协议限制。如果你所在的组织对 AGPL 有合规限制，即使 herdr 提供了商业许可，也需要在正式引入前走完内部审批流程。

如果你已经在深度使用多个 AI 编码 Agent，herdr 值得花一个下午装上试试。从 ctrl+b q detach 开始体验，感受一下状态侧边栏带来的信息透明度提升。如果你只是偶尔用 Agent，保持关注但不用急着迁移。关注两个指标：核心贡献者是否从 1 人扩展到 3 人以上，以及 v1.0 的发布时间。这两个信号决定了 herdr 能不能从一个人的好想法变成一个可以长期依赖的基础设施。

我翻完 herdr 的 commit 历史和 Issue 区之后，最深的感受不是说这个项目本身有多完美，而是它找准了一个被所有人忽视的问题。tmux 在上面跑了二十年，没人认真想过”如果终端里跑的不是人而是 AI 呢”。herdr 的下一个版本我还会跟进，不是因为它是今天最好的终端工具，而是因为它指了一个对的方向。

资源地址

聊完了数据和趋势，关键的判断已经有了，剩下的就是你在自己的终端里该怎么选。

先用 Docker 跑起来

如果你经常开着两三个 AI Agent 并行干活，今天就可以把 herdr 装上。从 curl 安装脚本开始，然后 herdr 启动，分两个 pane 各跑一个 Agent，detach 一次再 reattach。等你习惯了那个状态侧边栏，回去用 tmux 管 Agent 会觉得少了一层视力。

还在观望的话，留意两件事：一是 v1.0 什么时候出，那时候 API 稳定了，适合做深度集成；二是贡献者数量什么时候突破 1 人。单维护者项目在 8000 星的时候还能扛，到了 50000 星的时候需要的是一个团队。

今天在 GitHub 上给终端工具写 README 的人很多，但真正重新思考”终端复用器应该为谁服务”的人很少。herdr 是后者。