Herdr：并行编码 Agent 的吞吐量突破

Herdr 与并行代码 Agent 的吞吐量案例

大多数 agent 工具仍然围绕单一对话构建：一个 agent、一个任务、一个终端、一个需要监督的流。对于小任务还可以，但对于真实的工程工作来说并不理想。

Herdr 有趣之处在于它把这视为工作的默认形状。

最简单的描述方式是：Herdr 是编码 agent 的 tmux。更准确地说，它是一个运行在你现有终端内的 agent 多路复用器。它为每个 agent 提供实际的 PTY，让进程在工作发生的地方保活，展示 agent 状态，并暴露一个 CLI 加本地套接字 API。

这个区别很重要。Herdr 不是另一个桌面 agent 应用。它是你在代码和终端所在地运行的二进制文件：一台服务器、一台 Mac Mini、一个虚拟机、你办公桌下的开发机。关上笔记本电脑、分离、稍后通过 ssh 重新连接、重新附加，甚至从手机上也行。工作不会因为你的终端窗口关闭而死掉。

吞吐量问题

编码 agent 改变了开始工作的成本。我可以让一个 agent 探索一个 bug，另一个编写一个失败的测试，再另一个起草迁移计划。瓶颈在于监督。

问题在于普通终端不理解监督。tmux 和 Zellij 给你持久化和窗格，但它们不知道一个 agent 是被阻塞了、在工作、完成了、空闲了，还是在三屏之外打印了一个问题后就坐在那里。桌面应用通常更好地理解 agent 状态，但那样工作流就被绑死在有 GUI 的机器上了。Worktree 编排器可以协调并行任务，但它们通常想要拥有整个工作流。

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

性能倍增器不是魔法。它来自四个实用的特性：

• 多个 agent 在实际 PTY 中运行，每个都有自己的 shell、日志、提示符和进程状态。
• Herdr 汇总语义状态，所以你可以看到哪些 agent 被阻塞了、在工作、完成了或空闲了。
• 服务器拥有窗格，所以会话可以在客户端分离、笔记本睡眠和终端死亡后存活。
• CLI 和套接字 API 让脚本或 agent 可以直接控制多路复用器。

第四点是我最关心的。一个人监督三个窗格很有用。一个能启动辅助 agent、读取输出、等待状态转换、汇总结果的 agent，这才是复利开始的地方。

Herdr 的文档对此非常明确。套接字 API 可以管理工作区、标签、窗格和 agent。推荐的路径是先编写 CLI 包装器，然后用原始套接字 API 进行直接请求-响应控制或订阅。还有一个 agent skill 文件，由 HERDR_ENV=1 保护，它教会一个 agent 如何在一个窗格内使用 Herdr。

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

一个监督者拥有计划和评审。它创建三个窗格：

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

监督者等待状态而不是轮询终端：

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 被阻塞了，这个状态是可见的。如果另一个在你评审第一个时完成了，它会被标记为已完成直到被检查。如果 ssh 断开，服务器仍然拥有窗格和进程。

没有持久化，每个额外的 agent 都增加开销。有了持久化窗格和状态，开销就下降了。你可以为每个 repo、假设或策略运行一个 agent，只在需要时付出注意。

比较和权衡

Herdr 在心智模型中最接近 tmux 或 Zellij。它给你持久化窗格和远程重新连接，但添加了 agent 状态和一个 agent 形状的控制表面。如果你已经生活在 tmux 中，你是在采用一个年轻的工具来处理那一层。

与桌面 agent 应用相比，Herdr 不那么精致，但更诚实地对待工程工作发生的地方。工作盒上的终端多路复用器在笔记本关闭后存活。

与 worktree 编排器相比，Herdr 不那么独断。如果你想要一个拥有任务分配、worktree 生命周期、审查流程和合并策略的产品，就用编排器。如果你想要一个灵活的运行时，其中 agent、shell、测试监视器、日志和监督脚本可以共存，Herdr 是更好的形状。

有真实的风险。并行 agent 意味着并行影响范围。如果你用广泛的绕过权限运行 agent，它们可以同时做出坏的编辑。你仍然需要 git 纪律、小提示词、隔离的 worktree、diff 评审和先测试检查。

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

现代编码 agent 的当前一代不仅受模型质量限制。它受运行时人体工学限制。

单一对话 agent 工作流使每个任务看起来都是线性的。真实的工程工作是一个调查、测试、审查、失败的尝试、日志和决策的图。Herdr 的赌注是正确的界面不是一个更漂亮的聊天窗口。它是一个终端原生的运行时，具有持久化、状态和一个 API。

Herdr 不会替代判断、代码审查或品味。它不会默认让每个工程师快三倍。但对于已经在推动 agent 的工程师，它保持多个工作流活跃、可见和可控，而不会丧失上下文。

这就是吞吐量的来源。不是来自假装一个 agent 是一个团队。而是来自为一个工程师给出许多 agent 的理智控制表面，然后有纪律地使用它。

Herdr agent skill 文件文档

Herdr GitHub 仓库

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

如需进一步操作，你可以考虑屏蔽此人和/或举报滥用