herdr：为 AI 编程智能体而生的终端复用器

你有没有遇到过这种情况

开三个终端窗口，分别跑 Claude Code、Codex 和 Cursor 的 agent 模式。切到第一个窗口，它早就在等批准了，但你没看到。切到第二个，测试跑完了，结果淹没在滚动日志里。第三个还在跑，但你不确定卡在哪一步。

三个智能体，三个终端，三种状态。你成了它们之间的路由器——一个效率很低、容易走神的路由器。

tmux 能分离会话，能分屏，能给窗格起名字。但它不知道一个窗格里跑的是 Claude Code 还是 top，不知道那个智能体已经等了你十分钟，更不可能让一个智能体去通知另一个智能体开始工作。

herdr 解决的就是这个问题。它是一个终端复用器，跟 tmux 同属一个物种，但它的设计目标从第一天起就是服务 AI 编程智能体。

herdr 是什么

一句话：agent multiplexer that lives in your terminal——住在终端里的智能体复用器。

它是一个用 Rust 写的单二进制程序，跑在你已有的任何终端里，不需要 Electron，不需要独立 GUI。你在 GitHub 上有 23,000 多颗星可以验证它的受欢迎程度。

跟 tmux 一样，herdr 可以分屏、分离会话、远程重连。但它多做了一件 tmux 做不到的事：理解窗格里跑的是什么。herdr 能自动识别 AI 编程智能体（Codex、Claude Code 等），追踪它们的状态，然后在侧边栏给你一个全局视图——哪个智能体在等你回复，哪个在埋头工作，哪个已经干完了。

更进一步，herdr 对外暴露了一套 Socket API。智能体自己可以通过这套 API 创建窗格、读取其他窗格的输出、等待某个条件达成。这意味着你可以编排多个智能体协作：一个写代码，一个跑测试，一个做 code review，它们之间的协调不需要你手动传递信息。

架构：四层抽象

herdr 的架构从上到下分四层，每一层都有明确的职责边界。

Workspace（工作区）

最顶层。一个工作区通常对应一个项目仓库或一项具体任务。你可以在 herdr 里同时打开多个工作区，比如一个处理 text-matrix 的 Hugo 迁移，另一个调查线上数据库的慢查询。工作区之间相互隔离，但可以在同一个界面里快速切换。

Tab（标签）

每个工作区可以包含多个标签页。标签页是布局容器，你可以按功能组织：一个标签放智能体，一个标签看日志，一个标签跑本地服务器。这种组织方式让多任务并行变得清晰——你不需要在二十个窗格之间来回找，标签已经帮你分好类了。

Pane（窗格）

窗格是实际的终端。一个标签页里可以水平或垂直分割出多个窗格，每个窗格都可以独立运行命令、重命名、调整大小。关键特性：窗格在客户端断开连接后仍然存活。你关掉笔记本，明天早上打开，窗格里的进程还在跑。

Agent（智能体）

这是 herdr 区别于其他终端复用器的核心概念。当 herdr 检测到某个窗格里运行的是 AI 编程智能体时，它会自动开始追踪这个智能体的状态——不需要任何额外配置。智能体被视为窗格之上的一等公民，有自己的生命周期、状态机和操作接口。

四层之间的关系可以用 ID 体系直观体现：工作区是 w1，它下面的标签是 w1:t1，标签里的窗格是 w1:p1。层级清晰，ID 稳定且不复用——关闭的窗格 ID 永远不会被分配给新窗格。

智能体状态机：五种状态

herdr 给每个被识别的智能体维护一个状态标签。五种状态覆盖了智能体的全部生命周期。

这个状态机的设计哲学很务实。它不试图理解智能体在"思考"什么，只关心一个对外接口层面的问题：这个智能体现在需不需要人来看一眼？ blocked 和 done 是两个需要关注的信号，working 说明一切正常，idle 说明已经处理完毕。

侧边栏会聚合所有工作区中所有智能体的状态。你扫一眼就能知道：三个项目里有两个智能体在等你批准——该去看看了。

Socket API：智能体编排的基石

herdr 最有想象力的设计，是让智能体自己成为 herdr 的客户端。

herdr 暴露了一套基于 Socket 的 API，外部程序（包括运行在窗格里的智能体本身）可以通过命令行调用这些 API。Agent Skill 文件（skills/herdr/SKILL.md）教智能体如何使用这些命令。当环境变量 HERDR_ENV=1 时，智能体知道自己在 herdr 管理的窗格里运行，可以开始利用 herdr 的能力。

三层原语

API 按职责分为三层，从底层到高层依次递进。

Layout 层管拓扑结构。创建工作区、添加标签、分割窗格——这些命令定义了终端的物理布局。智能体可以用这些命令为自己搭建工作环境：开一个窗格写代码，再分割一个窗格跑测试服务器。

Pane 层管终端控制。在一个已经存在的窗格里执行命令、发送按键、读取输出、等待特定输出出现。这是智能体与终端交互的原语级别——相当于编程语言里的系统调用。

Agent 层管智能体生命周期。按名称启动智能体、给智能体发 prompt、等待智能体进入特定状态、读取智能体的输出。这一层让"智能体控制智能体"成为可能。

三层协作的例子

假设你有一个代码仓库需要做全面的 code review。你可以这样编排：

# 创建一个专门的工作区
herdr workspace create --cwd ~/my-project --label "review-session"

# 在工作区里开一个标签放 review agents
herdr tab create --workspace w1 --label "reviewers"

# 分割出两个窗格
herdr pane split --current --direction right --cwd "$PWD" --no-focus
herdr pane split --current --direction right --cwd "$PWD" --no-focus

# 在两个窗格里分别启动不同职责的智能体
herdr agent start security-reviewer --kind codex --pane w1:p1
herdr agent start style-reviewer --kind codex --pane w1:p2

# 分别给它们下达指令
herdr agent prompt security-reviewer "审查所有认证相关代码的安全风险" --wait --timeout 120000
herdr agent prompt style-reviewer "审查代码风格一致性并提出改进建议" --wait --timeout 120000

这段脚本做的事情：开两个智能体，一个负责安全审查，一个负责风格审查，并行工作。你不需要在两个窗口之间切来切去，herdr 的侧边栏会告诉你它们的实时状态。

当两个智能体都进入 done 状态后，读取它们的输出：

herdr agent read security-reviewer --source recent-unwrapped --lines 120
herdr agent read style-reviewer --source recent-unwrapped --lines 120

如果想更进一步，写第三个智能体来汇总两份报告——给它一个窗格，让它先等待 security-reviewer 完成，读取输出，再等待 style-reviewer 完成，读取输出，最后生成综合报告。Socket API 让这种链式编排完全可编程。

安全边界

智能体操作 herdr 有明确的规矩。Agent Skill 里内置了几条安全规则：

• 首先检查 HERDR_ENV=1，不在 herdr 管理的窗格里就停止操作
• 不关闭不是自己创建的工作区、标签或窗格
• 不从活动会话里执行 herdr server stop

这些约束保证了多智能体协作不会互相破坏对方的工作环境。

安装与上手

安装

三种方式，选你习惯的：

# 官方安装脚本
curl -fsSL https://herdr.dev/install.sh | sh

# Homebrew
brew install herdr

# mise
mise use -g herdr

安装完成后只有一个二进制文件，不需要额外依赖。

第一个工作区

# 在项目目录创建工作区
cd ~/my-project
herdr workspace create --cwd "$PWD" --label "my-project"

herdr 会启动一个服务器进程，打开工作区界面。你会看到侧边栏显示当前工作区的标签和窗格，主区域是你的终端。

试试分割窗格：

Ctrl+b, "

跟 tmux 一样的快捷键。或者直接用鼠标——拖动分割线调整窗格大小，点击标签切换，右键弹出菜单。herdr 的鼠标支持是原生集成的，不是通过终端模拟器的鼠标事件转译。

启动一个智能体

在窗格里直接运行你的 AI 编程智能体（比如 codex 或 claude），herdr 会自动检测并开始追踪状态。不需要额外配置。

侧边栏会出现这个智能体的状态标签。当它需要你批准操作时，标签变成 blocked；当它完成任务时，标签变成 done——你知道该去看一眼了。

远程访问

herdr 的会话是服务器端的持久化进程。你可以从任何终端重新连接：

# 从另一台本地终端
herdr attach my-project

# 通过 SSH 从远程机器
ssh my-server -t "herdr attach my-project"

断开连接用 Ctrl+b, d，跟 tmux 一样。智能体继续在后台运行，下次连接时状态还在。

Session State：四层恢复保障

智能体跑着跑着，机器重启了怎么办？herdr 设计了多层次的恢复机制来应对各种场景。

分离/重连是最常见的场景。你 detach 之后，进程没有受到任何影响——它根本不知道客户端断开了。重连时拿到的就是完整的实时终端，包括屏幕上正在滚动的内容。

服务器重启意味着进程丢失。herdr 会从持久化的快照中恢复工作区布局——你的窗格结构、标签组织、工作区列表都会回来。屏幕历史方面，herdr 保存了终端输出的快照，重连后能看到之前的内容。至于智能体的对话状态，取决于智能体自身是否支持 session restore——herdr 会触发这个机制，但恢复的完整度由智能体决定。

版本更新有两种模式。默认情况下 herdr 更新时不传 --handoff 参数，服务器如果兼容就保留。如果传了 --handoff，herdr 会尽力把旧会话的状态迁移到新版本，包括屏幕历史和对话上下文。

这套设计的核心理念：不要因为基础设施的变动丢失智能体的工作进度。你不需要担心升级 herdr 会让正在跑的 review 半途而废。

跟 tmux 的关系

herdr 公开承认自己继承了 tmux 的设计遗产。前缀键 Ctrl+b、分离/重连模型、窗格分割——这些 tmux 用户耳熟能详的概念在 herdr 里完全一致。如果你会用 tmux，上手 herdr 几乎没有学习成本。

但 herdr 在三个维度上走得更远。

智能体感知。 tmux 把窗格里的内容当作无差别的字符流。herdr 能识别 AI 编程智能体，追踪它们的状态变化，在 UI 上实时反馈。这不只是 UI 美化——它改变了人机协作的模式。你不再是逐个窗格检查智能体在干什么，herdr 主动告诉你哪个需要关注。

鼠标原生。 tmux 的鼠标支持是通过终端转译实现的，体验取决于终端模拟器的配合程度。herdr 把鼠标交互作为一等公民设计：点击切换窗格、拖动分割边框、右键菜单、拖选复制、Ctrl+点击打开链接。这些操作在 tmux 里要么做不到，要么需要复杂的配置。

Socket API。 这是最大的差异。tmux 有控制模式（tmux -C）和命令接口，但它的设计目标是被人操作，不是被程序操作。herdr 的 Socket API 专门为智能体编排设计，三层原语（Layout / Pane / Agent）覆盖了从创建拓扑到控制智能体的完整操作链。这让 herdr 不仅仅是一个终端工具，更是一个多智能体运行时。

换个说法：tmux 是给人用的终端复用器，herdr 是给人和智能体一起用的终端复用器。

插件生态

herdr 提供了插件系统，可以扩展窗格功能和工作流。插件市场在 herdr.dev/plugins，目前生态还在早期建设阶段。

插件的典型用途包括：自定义状态指示器、特定智能体的深度集成、工作流自动化脚本、自定义 UI 组件等。如果你有特定的工作流需求，插件系统提供了标准化的扩展接口。

谁应该用 herdr

如果你现在的工作流是：

• 同时跑多个 AI 编程智能体
• 经常需要在智能体之间切换上下文
• 通过 SSH 在远程服务器上运行智能体
• 希望自动化多智能体的协作流程

herdr 值得一试。

它不会替代你的终端模拟器（iTerm2、Alacritty、Kitty 都照用），也不会替代你的智能体（Claude Code、Codex 各跑各的）。它填补的是智能体和终端之间的那层——调度、监控、编排。这层以前是空白的，你用记忆力和 Alt+Tab 来填补，效果不好。

一个 Rust 二进制，brew install herdr，几分钟就能感受出差别。