herdr

一个在后台持有智能体终端的服务端，并且知道哪一个正卡着等你。

herdr 是一个 Rust 写的终端工作区管理器，血统来自 tmux：后台服务端持有真实的 PTY，客户端可以随时 attach / detach，中间进程一直在跑。它加在上面的东西是 **对智能体的感知**——它能识别哪些 pane 里跑着编程智能体，把每一个归类为 working、blocked、done 或 idle，再把状态向上汇总到 tab 与工作区，让你直接跳到那个正等你拿主意的 pane。智能体本身也能通过 CLI 与本地 socket API 驱动它，包括用 `herdr agent wait --until blocked` 等另一个智能体。它跑在你现有的终端里，而不是取代你的终端。

这不是第一天要做的决定。它在你**同时跑不止一个智能体**、并且不逐个读 pane 就分不清哪个跑完了、哪个从午饭前就卡在权限确认上的时候，才变得相关。多路复用器能让终端活着，但完全不知道里面装着什么。这一个缺口就是它存在的全部理由 —— 反过来也意味着：如果你一次只跑一个智能体，一个终端标签页依然够用。

我们的判断

当你开始**同时跑不止一个智能体**时它才值得装，因为那正是多路复用器不够用的时候： tmux 能告诉你某个 pane 安静下来了，却分不清它是干完了还是在等你点同意。 herdr 的全部价值就是这一个区分。不过在假设它适用于你之前，先看一眼它的支持列表——对 Claude Code、Codex 与 Cursor Agent CLI，状态是靠规则匹配可见屏幕推断出来的，只有带生命周期钩子或插件的那几个智能体才是权威上报。

最后核实于 2026-09-10

最适合

并行跑多个编程智能体，需要知道哪一个在等你
在远程机器上跑长任务，SSH 上去又会断开的场景
需要等待另一个智能体状态的脚本化 / 智能体驱动工作流

局限

对多数智能体，blocked 是靠匹配可见屏幕判断的，智能体改一次 UI 就可能判错
服务端重启会杀掉 pane 进程；回来的只有布局，以及受支持智能体的会话
重启后默认不保留 pane 回滚内容，需要手动开——因为输出里可能有密钥
仍在 1.0 之前且迭代很快，配置与 API 表面还在变

什么时候该选别的

一次只跑一个智能体的人，一个终端标签页就够了
不允许再多一个持有全部终端的后台守护进程的环境
希望智能体状态来自智能体本身、而不是来自屏幕匹配的人

主要功能

后台服务端持有 PTY，detach 或断开 SSH 都不会让工作停下
每个 pane 都有语义化状态——working / blocked / done / idle——并向上汇总到工作区
提供 CLI 与 socket API，智能体可以自己开 pane、读输出、互相等待
服务端重启后，能上报 session id 的智能体可以原生恢复会话
跑在你现有的终端里；单个 Rust 二进制，不带 Electron

herdr 的替代品

如果 herdr 不合适，这些工具解决的是类似问题。

herdr 的替代品 →