herdr：智能体终端复用器

在单个终端窗口中运行一个 AI 编程智能体，是一种可控、甚至相当愉悦的体验。但如果你同时运行十个智能体，分散在不同仓库里，各自以各自的节奏推进，事情很快就会变得像是在没有雷达屏幕的情况下做空中交通管制。某个智能体十五分钟前就完成了任务，从此一直闲置；另一个卡在等待一个没人注意的问题上；还有第三个，正在某个一小时前就已滚出视野的窗格中，苦苦运行一个耗时极长的任务。

一个名为 herdr 的开源项目正是为了解决这个问题而构建的。它给每个编程智能体一个真正属于自己的终端，同时让你在一瞥之间掌握整个智能体编队的运行状态——而且这一切都由一个轻量级二进制文件完成，而不是一个笨重的桌面应用。

1、当智能体开始成倍增加时出现的问题

对于单一任务来说，单个终端窗口完全可以胜任。麻烦始于并行智能体工作从例外变成常态的那一刻——而这正日益成为许多开发者习以为常的工作方式。编程智能体经常需要等待决策、遇到权限提示，或仅仅是在任务中途暂停，等待某个外部条件发生变化，而这些等待都不会大声宣告自己的存在。如果缺乏某种跨所有运行会话的统一视图，实际结果就是开发者手动在一堆终端标签页或窗口中点来点去，努力回忆哪个窗格属于哪个仓库，以及它是在积极做有用的事，还是已经悄悄卡住了二十分钟。

herdr 直接解决了这个问题：它将每个被管理智能体的状态汇总为简单、一眼可读的状态——阻塞（blocked）、工作中（working）、已完成（done）或空闲（idle）。仅此一点就省去了手动逐个检查窗格的麻烦，取而代之的是一个侧边栏，它一眼就能回答唯一真正重要的问题：现在哪个智能体需要关注。

2、herdr 究竟是什么

从技术核心来看，herdr 是一个终端多路复用器（terminal multiplexer）——这类工具允许在单个窗口内运行多个终端会话，按窗格、标签页和工作区组织，而且关键在于，无论某个特定窗口在某个时刻是否打开，这些会话都能独立存活。任何熟悉 tmux 的人都会立刻认出这个概念，因为 herdr 直接将自己描述为同一想法的重新实现，只不过它专门为自主编程智能体而重新构建，而不是为普通的 shell 会话。

通过 herdr 管理的每个智能体，都运行在它自己真实的终端会话中，而不是某种视觉上的近似品。这个区别比表面看起来重要得多。许多编程智能体及其调用的工具，会渲染相当复杂的全屏文本界面，而一个试图在视觉上重绘或重新解释这些输出的包装应用，往往会在细微之处出错。正因为 herdr 给每个智能体的是真实的终端，而不是模仿品，即便是复杂的全屏文本界面也能完全按预期方式渲染。

智能体可以在它们通常运行的任何地方运行：直接在本地机器上、通过 SSH 连接的远程服务器上，或任何其他可以存在终端会话的地方。窗格可以组织成工作区和标签页，通过点击、拖拽和拆分来排列，所有这些都原生支持鼠标交互，而不要求你把每个操作都记成键盘快捷键。

合上笔记本电脑并不会终止任何正在运行的智能体。后台服务器能让每个窗格和每个智能体保持存活，而不管是否有客户端窗口当前连接着它。这意味着之后可以从完全不同的终端、甚至通过 SSH 连接的手机重新附加到会话上，从上次中断的地方继续。

也许最引人注目的是，考虑到当前智能体工具生态中大量倾向于笨重桌面应用的现状，herdr 以一个本地 Rust 二进制文件交付，体积大约只有十兆字节。没有需要安装的图形应用，没有在后台消耗内存的 Electron 包装层，没有仅限 macOS 的打包，不需要注册账户，也没有在后台收集使用数据的遥测。

3、与现有工具的对比

两大类现有工具分别解决了 herdr 所要解决问题的相邻部分，理解它们各自的短板，有助于解释 herdr 为何以这样的方式构建。

传统的终端多路复用器（如 tmux）已经提供了持久化会话、分离与重新附加的能力、通过 SSH 进行远程操作，以及窗格、标签页和工作区的灵活排列。但它们完全缺乏对"运行在某个窗格中的智能体到底在做什么"的感知。普通终端多路复用器没有"窗格被阻塞、正在工作或已完成"的内置概念，因为在设计这些工具时，这个概念根本不存在。技术上确实可以手动拼接出某种近似的感知——为每个单独的智能体框架接上响铃字符或自定义钩子——但这需要为涉及的每个工具持续进行手动配置，而且即便如此，也无法在同时运行的整个智能体编队上提供一个统一的共享视图。

图形化智能体管理器应用则走相反路线，将智能体感知作为一等公民特性来构建。这确实代表了当下有用且值得期待的功能，本身已经算不上差异化优势了。这些应用的短板在于围绕核心功能的一切。许多是闭源的，往往仅限 macOS，而且它们是在自己的自定义应用包装器内重绘终端输出，而不是呈现真正的终端会话——这恰好重新引入了前面描述的渲染不一致问题，凡是运行复杂全屏文本界面的东西都会受影响。

herdr 的定位是结合两类的优势而不继承各自的弱点：传统多路复用器的持久性、可移植性和真实的终端保真度，加上图形管理器提供的智能体状态感知，全部打包在一个二进制文件中，运行在开发者已经在用的任何终端里，并且可以从任何能建立 SSH 连接的地方访问。

4、安装 herdr

在 Linux 或 macOS 上安装 herdr，只需从项目自己的域名运行一个安装脚本：

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

Windows 的预览版 beta 构建可以通过类似的方式使用 PowerShell 安装：

powershell -ExecutionPolicy Bypass -c "irm https://herdr.dev/install.ps1 | iex"

如果你更愿意通过现有的包管理器而不是独立安装脚本来管理工具，herdr 也可以通过 Homebrew、mise、Nix 获取，或直接从项目发布页下载一个普通、稳定的二进制文件。运行 herdr update 只会升级最初通过项目自带安装器安装的版本；而通过 Homebrew、mise 或 Nix 安装的版本，则要通过当初安装它所用的那个包管理器来更新。

5、启动第一个会话

让一个会话跑起来，只需运行命令本身：

herdr

这会启动一个新的后台服务器，或附加到一个已在运行的服务器上，打开一个工作区，随时准备在窗格内直接启动一个智能体。

herdr 是彻底"鼠标原生"的，也就是说，点击和拖拽窗格、标签页和分割边框，就能处理大多数日常导航，完全不需要记住任何键盘快捷键。对于喜欢用键盘操作的人，herdr 保留了一个前缀键——Ctrl 加 b——这样 herdr 自己的快捷键就不会干扰某个窗格内正在运行的 shell 或应用。按下这个前缀、松开，再按下一个特定的动作键，就会触发相应的命令：按 Ctrl+b 再按字母 c 会创建新标签页。

一系列常见操作都遵循这个前缀模式。按 Ctrl+b 再按 Shift+n 创建新工作区。按 Ctrl+b 再按 v 或减号键，分割当前窗格。按 Ctrl+b 再按 w，在现有工作区之间切换。按 Ctrl+b 再按 q，完全从当前会话分离，让每个智能体安全地在后台继续运行，之后只需再次运行 herdr 即可恢复。按 Ctrl+b 再按问号，会在终端内直接显示完整的可用按键绑定列表。

6、使用远程服务器

herdr 提供的一个比较独特的能力，是在远程服务器（如虚拟专用服务器）上运行，同时仍能从本地终端舒适地控制它。使用 remote 标志运行 herdr，会让本地终端成为那个远程服务器的真正客户端，而不是简单地通过 SSH 隧道传递原始终端会话。

herdr --remote workbox
herdr --remote ssh://you@yourserver:2222

这一区别解决了一个具体而此前恼人的限制，它影响着普通 SSH 加传统终端多路复用器的组合：在标准的 SSH 加 tmux 连接上，将图片直接粘贴到智能体的终端会话中通常无法正常工作，而 herdr 专门的远程客户端模式保留了这一功能，以及其他原始终端透传连接通常会破坏的客户端侧便利。

7、如今哪些智能体支持 herdr

herdr 能自动检测各种各样的现有编程智能体，它将进程名匹配与基于终端输出本身的启发式规则结合起来，对大多数常见工具无需任何手动配置，就能立即开始报告有用的状态信息。

对一大串智能体，herdr 已经提供跨空闲、工作和阻塞三种状态的完整检测，包括 Claude Code、Codex、Droid、Amp、OpenCode、Grok CLI、Hermes Agent、Kilo Code CLI、Devin CLI、Cursor Agent、Antigravity CLI、Kimi Code CLI、GitHub Copilot CLI 和 QoderCLI。名为 Pi 的工具支持空闲和工作状态检测，阻塞状态检测目前仅部分实现；Kiro CLI 支持空闲和工作检测，但完全没有专门的阻塞状态检测。另外两个工具 Gemini CLI 和 Cline 已被成功检测到，但项目尚未认定它们经过了充分测试。

除了这份已经相当可观的名单之外，任何其他编程智能体在 herdr 中依然可以工作，无论它是否拥有专门的状态检测——因为 herdr 核心就是一个真正的终端多路复用器；未被识别的智能体只是作为一个普通终端会话运行，只是没有受支持智能体所获得的语义状态标签而已。对于有兴趣为自己的智能体添加完善支持的工具作者，自定义集成可以通过 herdr 的 socket API 直接上报标签和状态，而不必等待上游检测启发式规则跟上。

还有一小部分智能体受益于官方更深度的集成，这些集成增加了原生会话恢复能力，在某些情况下还能直接上报语义状态，而不是仅仅依赖输出模式匹配。这些官方集成可以直接通过 herdr 本身安装：

herdr integration install <agent>

这条安装路径目前支持 Pi、Omp、Claude、Codex、Copilot、Devin、Droid、Kimi、OpenCode、Kilo、Hermes、QoderCLI 和 Cursor。

8、让智能体直接控制 herdr

herdr 的用处不止于被动显示智能体状态——智能体本身可以通过本地 Unix socket 与它主动交互。通过这个 socket 接口，智能体可以创建新的工作区、拆分或缩放现有窗格、派生额外的辅助进程、直接读取终端输出，以及订阅状态变更通知，而无需反复轮询更新。

这实际上允许智能体以编程方式编排自己的工作环境，根据需要为子任务或辅助进程启动额外的窗格，而不是局限于人类操作员预先设置好的那种手动布局。

一个可复用的技能包让这种集成很容易加入现有的智能体工作流：

npx skills add ogulcancelik/herdr --skill herdr -g

9、从源码构建 herdr

有兴趣直接构建 herdr 而不是使用预构建二进制的开发者，可以使用标准的 Rust 工具链：

git clone https://github.com/ogulcancelik/herdr
cd herdr
cargo build --release
./target/release/herdr

项目还为常见的开发工作流提供了便捷的任务运行器命令，包括运行单元测试套件，以及运行覆盖代码格式化、测试和一般维护的更广泛的检查集：

just test
just check

10、为什么 Rust 的根基至关重要

选择将 herdr 构建为一个单一、无依赖的 Rust 二进制文件，并不是一个偶然的实现细节；它直接塑造了使用该工具的实际体验。因为整个应用编译成一个体积很小的自包含可执行文件，所以没有需要单独安装的运行时环境，没有需要解析的包管理器依赖，也不会与系统上已有的其他软件发生版本冲突的风险。

这也解释了 herdr 如何能在保持约十兆字节体积的同时，仍然作为一个内置智能体感知的完整终端多路复用器工作——这与通常以 Electron 为基础的桌面应用形成了鲜明对比：后者为了渲染一个用户界面，要捆绑整个嵌入式浏览器运行时，占用大量内存和磁盘空间。

Rust 的性能特性同样直接关系到手头的核心任务：管理多个实时终端会话、跟踪它们的输出以运行状态检测启发式规则，并在同时运行的智能体数量增长时保持一切响应迅速。一个意在安静地待在后台、同时监控多个活动进程的工具，会从一门围绕可预测性能和低资源开销而设计的语言中受益匪浅。

11、结束语

herdr 将一个成熟的想法——终端多路复用器——加以更新，以适应一种日益常见的、同时运行多个自主编程智能体而非单一交互式 shell 会话的工作方式。它给每个智能体一个真正的终端而非模仿品，无需任何配置即可自动呈现阻塞、工作中、已完成和空闲状态，让每个会话在后台服务器上保持存活而无论客户端是否保持连接，并且以一个轻量级 Rust 二进制交付，没有图形包装层、不需要账户、也没有遥测——正是这些特性，精准击中了并行智能体工作从偶尔变为日常的那一刻所浮现的痛点。

对于已经习惯于在终端中工作的开发者来说，它提供了一种自然、低开销的方式，终于可以同时跟踪整个智能体编队，而不再迷失于哪个窗格需要关注、哪个早在二十分钟前就完成了任务。

原文链接：One Terminal to Watch Them All: Inside herdr, the Open Source Multiplexer Built for the Agent Era

汇智网翻译整理，转载请标明出处