Herdr：编码Agent的终端复用与并行管理方案

大多数 Agent 工具仍围绕单一对话构建：一个 Agent、一个任务、一个终端，以及一条需要你时刻盯着的输出流。应付小任务还行，但不适合真正的工程工作。

Herdr 的有趣之处在于，它把这种工作方式视为默认形态。

最简单的描述是：Herdr 是面向编程 Agent 的 tmux。更准确地说，它是一个运行在现有终端里的 Agent 多路复用器。它为每个 Agent 提供真实的 PTY，让进程持续运行在实际工作发生的环境中，同时展示 Agent 状态，并提供 CLI 和本地 socket API。

这个区别很重要。Herdr 并不是又一个桌面端 Agent 应用。它是一个直接运行在代码和终端所在环境中的二进制程序：服务器、Mac Mini、VM，或者桌子底下的开发机。你可以合上笔记本、断开连接，之后再通过 ssh 连回来并重新接入，甚至可以用手机操作。你的终端窗口关闭了，但工作并不会随之终止。

吞吐量问题

编程 Agent 改变了启动一项工作的成本。我可以让一个 Agent 调查 bug，让另一个 Agent 编写失败测试，再让第三个 Agent 起草迁移方案。真正的瓶颈变成了监督。

问题在于，普通终端并不理解什么是监督。tmux 和 Zellij 可以提供持久会话和窗格，却不知道某个 Agent 是被阻塞、正在工作、已经完成、处于空闲状态，还是仅仅因为三屏之前输出了一个问题，此后便一直停在那里。桌面应用通常更了解 Agent 的状态，但工作流也会因此被绑定在运行 GUI 的机器上。worktree 编排器能够协调并行任务，却往往希望接管整个工作流。

Herdr 恰好处于一个很实用的中间位置：保留终端模型，同时具备 Agent 感知能力。

它带来的性能倍增并不是什么魔法，而是源于四项切实可用的特性：

多个 Agent 分别运行在真实的 PTY 中，每个 Agent 都有自己的 shell、日志、prompt 和进程状态。

Herdr 会汇总语义状态，让你看到哪些 Agent 被阻塞、正在工作、已经完成或处于空闲状态。

窗格由 server 持有，因此即使 client 断开、笔记本进入睡眠状态或终端崩溃，会话仍能继续运行。

CLI 和 socket API 允许脚本或 Agent 直接控制这个多路复用器。

我最看重的是第四点。由人来监督三个窗格确实很有用，但真正产生复利效应的，是让一个 Agent 能够启动辅助 Agent、读取输出、等待状态变化，并汇总最终结果。

Herdr 的文档明确说明了这一点。socket API 可以管理 workspace、tab、pane 和 Agent。官方建议优先使用 CLI wrapper，需要直接进行请求—响应控制或订阅时，再使用原始 socket API。此外，它还提供了一个由 HERDR_ENV=1 保护的 Agent skill 文件，用于教会 Agent 如何从窗格内部使用 Herdr。

设想一名 Staff Engineer 正在监督一场重构：替换内部 client、调整测试并检查部署。我会把工作拆开。

由一个监督 Agent 负责计划和审查，并创建三个窗格：

herdr

进入 Herdr 后，它可以拆分窗格并启动 Agent：

split=$(herdr pane split --current --direction right --no-focus)
api_pane=$(printf '%s\n' "$split" | jq -r '.result.pane.pane_id')

herdr agent start api-change --kind codex --pane "$api_pane"
herdr agent prompt api-change "Replace the legacy client in the API layer. Keep the diff minimal."

然后再启动两个 Agent：

test_split=$(herdr pane split --current --direction down --no-focus)
test_pane=$(printf '%s\n' "$test_split" | jq -r '.result.pane.pane_id')

herdr agent start tests --kind codex --pane "$test_pane"
herdr agent prompt tests "Add or update tests for the new client behavior."

deploy_pane=$(herdr pane split --current --direction right --no-focus | jq -r '.result.pane.pane_id')
herdr agent start deploy-review --kind codex --pane "$deploy_pane"
herdr agent prompt deploy-review "Review config, deploy scripts, and rollback implications."

监督 Agent 不需要轮询终端，而是等待状态变化：

herdr agent wait api-change --until blocked --timeout 120000
herdr agent read api-change --source recent-unwrapped --lines 80

对于普通的进程输出，也可以这样处理：

herdr pane run w1:p3 "just test --watch"
herdr pane wait-output w1:p3 --regex "passed|failed" --timeout 120000

人类则上升到更高层级：审查 diff、回应被阻塞的 Agent、否决糟糕的方案、判断测试质量，并在影响扩散到生产环境之前控制住爆炸半径。

并行执行，同时不丢失上下文

只有并行还不够。打开五个终端很容易，难的是午饭回来以后，仍然能看懂每个终端里正在发生什么。

Herdr 之所以有效，是因为它把并行执行、持久性和状态结合在了一起。如果某个 Agent 被阻塞，这个状态清晰可见。如果你在审查第一个 Agent 时，另一个 Agent 完成了任务，它会被标记为已完成，并保持这个状态，直到你检查它。即使 ssh 连接中断，server 仍会继续持有窗格和进程。

没有持久性时，每增加一个 Agent，都会带来更多开销。有了持久窗格和状态管理，这些开销便会下降。你可以针对每个 repo、假设或策略分别运行一个 Agent，只在需要时才投入注意力。

对比与权衡

从心智模型来看，Herdr 最接近 tmux 或 Zellij。它提供持久窗格和远程重新接入能力，同时增加了 Agent 状态，以及面向 Agent 设计的控制界面。如果你原本已经重度依赖 tmux，那么相当于要在这一层采用一个更年轻的工具。

与桌面端 Agent 应用相比，Herdr 没有那么精致，却更诚实地面对了工程工作真正发生的地方。运行在工作机器上的终端多路复用器，不会因为笔记本合盖而停止。

与 worktree 编排器相比，Herdr 的约束更少。如果你希望某个产品全面负责任务分配、worktree 生命周期、审查流程和合并策略，那就使用编排器。如果你想要一个灵活的 runtime，让 Agent、shell、测试 watcher、日志和监督脚本共存，那么 Herdr 的形态更合适。

它也确实存在风险。并行 Agent 意味着并行扩大的爆炸半径。如果你给 Agent 配置了权限范围很广的 bypass，它们可能同时做出错误修改。你仍然需要遵守良好的 git 纪律，使用范围明确的小型 prompt、相互隔离的 worktree、diff 审查和测试优先的检查方式。

我尤其推荐经验丰富的工程师使用它。任何人都能打开几个窗格，但只有那些懂得如何拆分工作、划定边界、审查 patch 并识别可疑修改的人，才能真正发挥 API 的价值。

这一代编程 Agent 的瓶颈并不只是模型质量，还包括 runtime 的易用性。

单一聊天式的 Agent 工作流会让每项任务看起来都是线性的。但真正的工程工作是一张由调查、测试、审查、失败尝试、日志和决策组成的图。Herdr 的赌注在于：正确的交互界面不是一个更漂亮的聊天窗口，而是一个具备持久性、状态和 API 的终端原生 runtime。

Herdr 不会取代判断力、代码审查或品味。它也不会默认让每位工程师都快上三倍。但对于那些已经在高强度使用 Agent 的工程师来说，它能让多条工作流持续运行、清晰可见且始终可控，同时不丢失上下文。

吞吐量正是由此而来。不是假装一个 Agent 就是一支团队，而是为一名工程师提供一个合理的控制界面来管理多个 Agent，并保持足够的纪律性去正确使用它。

Herdr Agent skill 文件文档

Herdr GitHub 仓库

为了测试我的项目，我使用 Railway。如果你想获得 20 美元的启动额度，可以使用这个链接。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。