By Jermine

☰

AI Coding Agent 已经能够编写代码、运行测试、修改配置，甚至调用另一个 Agent 做代码审查。但当 Agent 数量增加后，新的问题很快出现：哪个任务已经完成？哪个 Agent 正在等待授权？哪个终端已经卡住？如果合上笔记本，后台任务还能继续吗？

传统做法通常是打开多个终端标签页，或者使用 tmux、screen 一类终端复用器。它们能解决“进程不要因为终端关闭而退出”，却不知道终端里运行的是哪一个 Agent，也无法理解 Agent 当前是在工作、等待输入还是已经完成。

Herdr 的定位正是补上这一层：它不是新的 AI Agent，而是一个面向 Coding Agent 的终端工作空间与运行时。它负责托管 Agent 所在的真实终端，保持会话持久化，识别 Agent 状态，并为 Agent 之间的协作提供 CLI 与 Socket API。

本文根据 Herdr 的公开项目资料整理，重点讨论其设计思路，不把项目宣传数据当作独立性能测试结论。

一、为什么 tmux 还不够

tmux 仍然是优秀的通用终端复用器，但它的抽象对象是 session、window 和 pane，而不是 AI Agent。这会造成几个具体问题。

1. tmux 不知道 pane 里运行的是什么

在 tmux 看来，运行 Claude Code、Codex、普通 shell 或测试脚本的 pane 没有本质区别。用户必须自己记住每个 pane 的用途，无法直接查询“哪个 Agent 需要我处理”。

2. tmux 无法理解 Agent 状态

“终端有没有输出”并不等于“Agent 当前状态”。一个 Agent 可能正在执行任务，也可能暂停在权限确认、问题询问、错误提示或最终结果页面。tmux 能保留屏幕内容，却不会把这些内容转换为可操作的状态。

3. pane 之间缺少 Agent 协作语义

让一个 Agent 写代码、另一个 Agent 做审查，传统方式通常是人工复制 diff、切换 pane、粘贴上下文，再把审查结果复制回来。终端复用器提供了多个终端，但没有提供“启动另一个 Agent、向它发送任务、等待它完成、读取它的结果”这类接口。

4. 重连后仍然需要人工巡检

tmux 可以让进程在客户端断开后继续运行，但重新连接时用户往往要逐个检查 pane，才能知道哪些任务已完成、哪些任务失败、哪些任务正在等待输入。Agent 数量一多，这种巡检本身就变成了新的工作。

所以，Herdr 的价值不在于重新发明终端复用，而在于把终端复用器的状态模型从“进程和 pane”提升到“项目、Agent 和任务”。

二、Herdr 的基本架构：后台服务器与终端客户端

Herdr 将负责运行任务的后台 Server 与负责交互的 Client 分离：

1Client（终端 UI）  <──连接──>  Server（后台运行）
2                              ├── Workspace
3                              ├── Tab / Pane
4                              └── Agent / Process

Client 只是用户当前连接的界面。关闭终端、断开 SSH 或暂时离开时，后台 Server 继续管理 workspace、pane 和其中的进程。用户再次运行 herdr，客户端重新连接，原来的布局和输出仍然可见。

最基本的操作可以理解为：

1# 在当前项目目录启动或连接 Herdr
2herdr
3
4# 使用 tmux 风格的前缀快捷键断开客户端
5# 默认：Ctrl+B，然后 Q
6
7# 再次打开终端并重新连接
8herdr

这解决的是 Agent 运行时最基础的问题：用户界面可以消失，但任务不应因为界面消失而停止。

需要区分的是，“客户端断开后继续运行”和“机器重启后原进程继续运行”不是同一件事。Herdr 的公开说明提到，它可以保存会话状态，并在重启后恢复布局；原来的进程是否能够存活，则取决于机器是否重启以及 Agent 是否支持恢复。不要把它理解为可以跨机器、跨重启无条件保存所有进程上下文。

三、Agent 状态检测：把“卡住了”变成可见状态

Herdr 的核心能力之一，是为终端中的 Agent 标注状态。公开资料中常见的状态包括：

状态 含义
working Agent 正在执行任务
blocked Agent 等待用户输入、授权或确认
idle Agent 当前空闲，等待下一条指令
done Agent 已完成当前工作，等待用户查看
unknown 暂时无法可靠判断状态

它并不是简单地通过“最近有没有输出”判断状态，而是结合多个信号：

  1. 前台进程识别：判断 pane 中运行的是哪一种支持的 Agent CLI；
  2. 屏幕模式匹配：读取终端底部或近期内容，匹配 Agent 的界面特征；
  3. 状态推断：根据提示符、等待确认界面和输出变化，推断 Agent 处于工作、阻塞或空闲状态。

例如，一个 Agent 进入权限确认界面时，Herdr 可以把对应 pane 标记为 blocked。用户不需要挨个翻看终端，只需查看侧边栏或 workspace 汇总，就能优先处理真正需要人工介入的任务。

这是一种很重要的交互转变：终端不再只是输出日志的地方，而是成为 Agent 的状态面板。

四、Agent 间协作：让一个 Agent 指挥另一个 Agent

Herdr 还提供面向 Agent 的 CLI 和 Socket API。借助这些接口，一个 Agent 可以对另一个 Agent 执行结构化操作，例如：

  • 创建新的 pane 并启动另一个 Agent；
  • 向指定 Agent 发送任务提示；
  • 等待另一个 Agent 进入指定状态；
  • 读取另一个 Agent 的近期输出；
  • 向 Agent 发送按键，例如取消当前操作。

示意命令如下：

 1# 启动一个用于审查的 Agent
 2herdr agent start reviewer --kind codex --pane w1:p2
 3
 4# 发送审查任务并等待结果
 5herdr agent prompt reviewer \
 6  "Review the current diff and report actionable findings." \
 7  --wait --timeout 120000
 8
 9# 读取审查结果
10herdr agent read reviewer --source recent-unwrapped --lines 120

这样就能形成一条自动化链路：

1主 Agent 编码
2      ↓
3启动审查 Agent
4      ↓
5发送审查任务
6      ↓
7等待并读取结果
8      ↓
9主 Agent 根据反馈继续修改

与“把所有 Agent 放进多个 pane”相比，这里多了一层真正的编排语义。Agent 可以把其他 Agent 当作可调用的执行单元，而不是只能依赖用户手工复制粘贴。

不过，Agent 间可通信不等于 Agent 间天然安全。生产使用时仍然应该限制：

  • 哪些 Agent 可以创建其他 Agent；
  • 哪些 Agent 可以发送命令或按键；
  • 哪些目录和凭据可以被访问；
  • 哪些操作必须回到人工审批。

尤其是 send-keys 这类能力，本质上接近直接操作另一个终端。权限边界应当和普通 Shell 自动化同样严格对待。

五、Workspace：按项目组织 Agent

Herdr 使用层级化的工作空间模型：

1Workspace
2  └── Tab
3        └── Pane
4              └── Agent / Shell / Server

Workspace：项目级隔离

一个 Workspace 可以对应一个项目或一组紧密相关的任务。后端、前端、基础设施和文档项目可以分别放在独立的 Workspace 中，避免所有 Agent 混在同一个全局列表里。

Tab：同一项目的不同视图

同一个项目可以建立多个 Tab：

  • agents：运行 Claude Code、Codex 等 Agent；
  • server：运行本地开发服务器；
  • logs：查看构建、测试或服务日志。

Pane：真实终端进程

Pane 不是只能显示日志的面板，而是完整的终端环境。你可以在里面运行 Agent、Shell、测试命令或开发服务器。这个设计保持了现有 CLI 工具的兼容性，也避免把每个 Agent 强行封装成特殊插件。

这种模型的关键好处是：项目边界、视图边界和进程边界同时可见。 用户能够先切换到项目，再查看该项目的 Agent 状态，而不是在所有终端里寻找某个进程。

六、鼠标与键盘：降低终端工具的学习成本

传统终端复用器通常键盘优先。熟悉快捷键的用户效率很高，但新用户需要记住前缀、分屏、切换和关闭等操作。

Herdr 将鼠标和键盘都作为一等交互方式：

  • 点击 pane 切换焦点；
  • 拖动分隔线调整大小；
  • 右键打开上下文菜单；
  • 使用 tmux 风格的 prefix 快捷键；
  • 通过 CLI 和 Socket API 自动化操作。

这形成了三种使用层级：

  1. 新手可以先用鼠标完成基本管理；
  2. 熟悉 tmux 的用户可以继续使用类似的键盘习惯；
  3. 自动化系统和 Agent 可以通过 CLI/API 直接控制工作空间。

一个好的终端工具不应要求所有人都使用同一种交互方式。人负责判断和审批，键盘负责高频操作，Agent 或脚本负责重复编排。

七、如何搭建一个可靠的 Agent 运行时

从 Herdr 的设计中，可以抽象出一份不依赖具体工具的检查清单。

1. 会话持久化

  • 客户端断开后，后台任务继续运行；
  • 用户重新连接后，布局、输出和状态可恢复；
  • 不同项目使用命名会话或独立 Workspace；
  • 机器重启后的恢复边界清晰可验证。

2. Agent 状态可见

  • 区分 working、blocked、idle 和 done；
  • 有统一的侧边栏或列表汇总状态；
  • 对等待授权、输入或确认的任务提供提醒；
  • 状态识别失败时明确标记为 unknown，不要假装确定。

3. Agent 可协作

  • Agent 可以启动或请求另一个 Agent；
  • 可以等待明确的状态转换，而不是盲目 sleep；
  • 可以读取结构化、可追踪的输出；
  • 对创建进程、发送命令和访问凭据设置权限边界。

4. 项目可隔离

  • 每个项目有独立 Workspace；
  • Agent、日志和服务可以放在不同 Tab；
  • 每个 Pane 的工作目录、环境变量和权限都可追踪；
  • 重要操作保留审计记录。

八、Herdr 适合什么场景

Herdr 特别适合以下工作流：

  • 同时运行多个 Coding Agent；
  • 一个 Agent 编码，另一个 Agent 做审查或测试；
  • 需要长时间运行测试、构建或迁移任务；
  • 通过 SSH 在远程开发机上工作；
  • 希望合上笔记本后任务仍然继续；
  • 需要在多个项目间快速切换 Agent 集合。

它并不能替代所有工具：

  • 只运行一个短命令时，普通终端更简单；
  • 只需要通用会话保持时，tmux 仍然足够；
  • 需要完整 IDE 调试能力时，仍应使用 IDE 或专用调试器；
  • 需要复杂跨机器调度时，还需要队列、权限、日志和资源管理系统。

Herdr 解决的是“本地或远程终端里如何可靠托管多个 Coding Agent”这一层问题，而不是完整的分布式 Agent 平台。

结语：Agent 能力之外，还需要运行时

大家通常关注哪个模型更聪明、哪个 Agent 更会写代码，但多 Agent 系统的实际效率还取决于运行时：任务能否持续、状态是否可见、Agent 是否能协作、人工是否只在必要时介入。

Herdr 的设计可以概括为四点：

  1. 后台服务器让终端客户端断开后任务继续运行；
  2. 状态检测让用户快速发现等待输入或已经完成的 Agent；
  3. CLI/API 协作让 Agent 能够启动、指挥和读取其他 Agent；
  4. Workspace 模型让项目、视图、终端和 Agent 形成清晰层级。

如果你只运行一个 Agent，tmux 可能已经足够。如果你开始同时运行编码、测试、审查和调研 Agent，那么“终端复用器”就不再只是布局工具，而会逐渐变成 Agent 的运行时基础设施。

参考资料