Herdr：Agent 并行管理工具

AI 提升生产力这件事，真正有用的版本依然很朴素：当更多彼此独立的工作能够同时进行，又不至于让系统失控时，吞吐量就会提高。

这正是 Herdr 值得关注的原因。

不是因为它又是一个 coding agent。它并不是。Herdr 是一个 Agent 多路复用器。最简单的解释是“面向 coding agent 的 tmux”，但这只说对了一半。与 tmux 一样，它能让真实的终端会话持续运行；与 tmux 不同的是，它会跟踪 Agent 当前是在工作、受阻、已完成还是空闲，并提供 CLI 和 socket API，供脚本或 Agent 调用。

最后这一点比 UI 更重要。真正更大的收益来自这样的能力：你可以同时监督多个 Agent，为每个 Agent 分配范围明确的任务，只在系统需要做决策时才投入人的注意力。

工作实际发生的机器

Herdr 运行在工作实际发生的那台机器上：你的笔记本电脑、服务器、Mac Mini、VM，或者任何能使用终端的地方。这个项目将自己描述为一个二进制程序，而不是一款 app。它没有 Electron 外壳，不需要账户，不收集 telemetry，也不会把托管式 dashboard 当作整个系统的中心。

如果 Agent 要完成真正的工程工作，它们就需要访问代码仓库、依赖、测试环境、日志、权限受限的 secrets，以及长时间运行的命令。这些工作通常更适合放在一台稳定运行的机器上，而不是那台你晚饭前就会合上盖子的笔记本电脑。

在 Herdr 中，pane 都是真实的 PTY，即使终端关闭，会话也会继续存在。之后你可以在本地重新连接、通过 SSH 重新连接，或者使用 Herdr 的 remote mode 重新连接。用手机重新连接听起来像个噱头，直到你离开键盘时，某个 Agent 恰好因为一个只需回答“是”或“否”的决定而受阻。

我不想在手机上审查复杂的 diff。但如果只是回复那个正在等待运行 migration dry run 权限的 Agent，我很乐意。

性能倍增器在于注意力路由

最朴素的 Agent 循环是串行的：

它确实有用，但人始终处于关键路径上。

Herdr 所塑造的工作流则是：

• N 个 Agent 运行在真实的 PTY 中，每个 Agent 分别处理自己的任务、仓库或 worktree
• 整个会话范围内的语义状态
• 只关注受阻或已经完成的 Agent
• 即使终端退出，会话依然持续存在
• 自动创建 pane、发送 prompt、读取输出并等待状态变化

这种提升并不神奇。它来自并行处理，以及更少的上下文损耗。

如果我有三个彼此独立的任务，就可以启动三个 Agent：一个调查不稳定的测试，一个更新依赖，另一个起草 migration 方案。我不应该盯着它们所有人的屏幕。真正需要知道的是，哪一个 Agent 需要我介入。

Herdr 的状态模型提供了这样的观察界面。它的 API 则提供了更进一步的能力：herdr pane run、herdr agent wait、herdr pane read，以及底层的 JSON socket API。

herdr workspace create --cwd ~/work/payments --label payments
herdr pane split w1:p1 --direction right

herdr pane run w1:p1 "codex"
herdr pane run w1:p2 "claude"
herdr pane run w1:p3 "opencode"

监督者分配工作：

herdr agent prompt w1:p1 "Find the flaky refund webhook test. Report evidence."
herdr agent prompt w1:p2 "Update the Stripe SDK. Run tests. Stop before production config."
herdr agent prompt w1:p3 "Review migrations and propose a safe backfill plan."

现在，监督者不必反复查看屏幕，只需等待状态变化：

herdr agent wait w1:p1 --until done
herdr pane read w1:p1 --source recent --lines 80

人依然需要承担责任。不同之处在于，人不再充当终端保姆。人要审查的是结论、diff、命令和风险。

为什么不直接使用 tmux 或 Zellij？

tmux 和 Zellij 已经解决了持久化问题。它们能让 pane 持续运行，可以干净地断开和重新连接，也支持通过 SSH 使用。

但它们并不了解 Agent 的状态。

tmux pane 就只是一个 pane。它不知道 Claude 是否正在思考，不知道 Codex 是否在等待审批，也不知道 OpenCode 是否已经完成任务。你可以编写脚本绕过其中一些问题，但多路复用器本身并不具备 Agent 感知能力。

Herdr 押注的是：coding agent 如今已经重要到足以成为终端中的一等公民。多路复用器应该理解它们，而不只是显示 stdout。

为什么不使用桌面 Agent app？

桌面 Agent app 通常面临相反的取舍。它们比 tmux 更了解 Agent，但往往只能运行在配有 GUI 的机器上。如果你真正的工作发生在服务器、VM、Mac Mini 或通过 SSH 连接的开发机上，这种限制就会成为问题。Herdr 保持了终端原生的工作流，因此运行任务的位置和连接会话的位置可以不同。

代价则是产品的精致程度。桌面 app 可以提供更丰富的可视化审查、更紧密的通知集成，以及更具引导性的上手流程。Herdr 是一个终端工具。如果你讨厌终端工作流，它解决不了这个问题。

为什么不使用 worktree 编排器？

当你希望工具接管整个工作流时，worktree 编排器非常有用：创建分支、分配任务、汇总结果并生成审查产物。对于结构化的 issue 队列，这可能是正确选择，代价则是灵活性。

Herdr 位于技术栈的更底层。它为你提供持久化 pane、Agent 感知能力和控制 API。它可以配合 worktree 和审查工具使用，但不必接管整个流程。我更喜欢这种形态，因为真实的工程工作总是混乱而复杂的。

爆炸半径确实存在

并行运行 Agent，也意味着错误会并行发生。

这正是炒作容易让人陷入麻烦的地方。如果一个 Agent 能删错一个文件，那么三个 Agent 就能以更快的速度删错三个文件。一群 Agent 可以生成一大堆看起来很有说服力、实际却很糟糕的 diff。

Herdr 对经验丰富的工程师最有价值，因为他们可以利用 API 和并行监督能力，同时又不会假装代码审查是可选项。正确的工作流应该包括：范围明确的任务、必要时使用独立分支、显式验证，以及朴素而扎实的人工审查。

使用 coding agent 的 bypass-permissions mode 时要格外谨慎。它们确实很方便，有时也是长时间运行任务所必需的，但便利性并不等于安全模型。Agent 应该只拥有完成任务所需的最低限度权限，而审查 diff 时，应当把它当作一名手脚很快的初级工程师提交的代码。

Herdr 给人的感觉，正是 coding agent 下一阶段发展所需要的抽象层。第一波工具让人与 Agent 的沟通变得更加容易。下一个真正有用的层次，是让监督 Agent 也变得更加容易。吞吐量正是从这里产生的。

我不需要另一款承诺取代工程判断的 app。我需要的是这样一种工具：让我可以在代码所在的地方运行 Agent，让会话持续存活，看清哪个 Agent 需要关注，并自动完成围绕它们展开的那些枯燥协调工作。

这似乎就是 Herdr 的目标：它不是 Agent，不是 IDE，也不是某种工作流信仰，而是一个多路复用器。

如果 coding agent 成为常规的工程基础设施，多路复用器这一层就会变得非常重要。

Herdr 对比页面

Herdr socket API 文档

Herdr Agent skill 文件文档

Herdr GitHub 仓库

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

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