大多数代理工具仍然围绕单一对话构建：一个代理、一项任务、一个终端、一条需要照看的流。这对于小任务来说还可以，但不适合真正的工程工作。

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

最简单的描述是：Herdr 是 coding agents 的 tmux。更准确地说，它是一个运行在现有终端中的代理多路复用器。它为每个代理提供一个真实的 PTY，在工作发生的地方保持进程存活，显示代理状态，并暴露 CLI 以及本地 socket API。

这种区别很重要。Herdr 不是另一个桌面代理应用。它是一个运行在代码和终端所在位置的二进制文件：一台服务器、一台 Mac Mini、一台虚拟机、一台放在你桌下的开发机。合上笔记本、分离会话、稍后通过 SSH 重新连接、甚至从手机连接——工作不会因为终端窗口关闭而终止。

吞吐量问题

Coding agents 改变了启动工作的成本。我可以让一个代理去探索一个 bug，让另一个写一个失败的测试，再让另一个起草迁移计划。瓶颈在于监督。

问题在于普通终端不理解监督。tmux 和 Zellij 提供了持久化和窗格，但它们不知道一个代理是阻塞、工作、完成、空闲，还是在三屏之前打印了一个问题后就停在那里。桌面应用通常能更好地理解代理状态，但工作流就被绑定在有 GUI 的机器上。Worktree 编排器可以协调并行任务，但它们通常希望掌控整个工作流。

Herdr 处于一个有用的中间位置：终端模型，加上代理感知。

性能倍增器并非魔法。它来自四个实际特性：

  1. 多个代理在真实 PTY 中运行，每个都有自己的 shell、日志、提示和进程状态。
  2. Herdr 汇总语义状态，因此你可以看到哪些代理被阻塞、正在工作、已完成或空闲。
  3. 服务器拥有窗格，因此会话在客户端分离、笔记本睡眠和终端死亡后依然存活。
  4. CLI 和 socket API 允许脚本或代理直接控制多路复用器。

第四点是我最关心的。一个人监督三个窗格是有用的。而一个代理能够启动辅助代理、读取输出、等待状态转换并整合结果，才是复利开始的地方。

Herdr 的文档对此有明确说明。socket API 可以管理工作区、标签页、窗格和代理。推荐路径是先使用 CLI 封装器，然后使用原始 socket API 进行直接请求-响应控制或订阅。还有一个由 HERDR_ENV=1 保护的代理技能文件，用于教导代理从窗格内部使用 Herdr。

一个具体的工作流

想象一位资深工程师在监督一次重构：替换内部客户端、调整测试、检查部署。我会把它拆分。

一个主管代理负责计划和审查。它创建三个窗格：

herdr

进入全屏模式 退出全屏模式

在 Herdr 内部，它可以拆分窗格并启动代理：

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."

进入全屏模式 退出全屏模式

然后它启动另外两个代理：

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."

进入全屏模式 退出全屏模式

主管等待状态而非轮询终端：

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、回答被阻塞的代理、拒绝糟糕的方案、判断测试，并在生产环境之前阻止爆炸半径。

并行加上零上下文丢失

仅并行是不够的。打开五个终端很容易。午饭后还能理解它们才是难点。

Herdr 之所以有效，是因为它将并行执行与持久化和状态结合在一起。如果一个代理被阻塞，该状态是可见的。如果另一个在你审查第一个时完成，它会被标记为完成，直到检查为止。如果 ssh 断开，服务器仍然拥有窗格和进程。

没有持久化，每个额外代理都会增加开销。有了持久窗格和状态，开销就会下降。你可以为每个仓库、假设或策略运行一个代理，只在需要时关注。

比较与权衡

Herdr 在心智模型上最接近 tmux 或 Zellij。它提供持久窗格和远程重新连接，但增加了代理状态和代理形的控制面。如果你已经生活在 tmux 中，你是在为那一层采用一个更年轻的工具。

与桌面代理应用相比，Herdr 不那么精美，但更诚实地反映了工程工作发生的位置。工作机上的终端多路复用器能在笔记本合上后继续存活。

与 worktree 编排器相比，Herdr 不那么有主见。如果你想要一个掌控任务分配、工作树生命周期、审查流程和合并策略的产品，请使用编排器。如果你想要一个灵活的运行时，让代理、shell、测试观察器、日志和主管脚本共存，Herdr 是更好的形态。

存在真实风险。并行代理意味着并行的爆炸半径。如果你在运行具有广泛绕过权限的代理，它们可以同时进行糟糕的编辑。你仍然需要 git 纪律、小型提示、隔离的工作树、diff 审查和测试优先检查。

我最强烈推荐它给有经验的工程师。任何人都可以打开几个窗格，但 API 奖励那些知道如何拆分工作、定义边界、审查补丁并注意可疑变化的人。

我的看法

当前一代 coding agents 不仅仅受限于模型质量。它受限于运行时人体工程学。

单聊天代理工作流让每个任务都感觉是线性的。真正的工程工作是一个由调查、测试、审查、失败尝试、日志和决策组成的图。Herdr 的赌注是，正确的界面不是一个更漂亮的聊天窗口。而是一个具有持久性、状态和 API 的终端原生运行时。

Herdr 不会取代判断、代码审查或品味。它不会默认让每个工程师快三倍。但对于已经在大力使用代理的工程师来说，它能让多条工作流保持活跃、可见和可控，而不会丢失上下文。

这就是吞吐量的来源。不是假装一个代理是一个团队。而是给一个工程师一个用于管理多个代理的合理控制面，然后有纪律地使用它。

参考

测试我的项目时，我使用 Railway。如果你想获得 20 美元 USD 起步资金，请 使用此链接。