Herdr：编码代理多路复用器，像 tmux 一样管理并发 Agent

大多数关于 AI 编程工具的讨论，仍然把注意力集中在 Agent 本身：模型、IDE 扩展、benchmark、演示。

这些固然有用，但并不完整。一旦 Agent 足够强大，瓶颈就会转移到协调上。

如果一个 Agent 可以在我审查 diff 的同时调查一个 bug，那么三个 Agent 就可以同时调查三件不同的事情。真正的挑战在于：让它们持续运行、了解哪一个需要关注，以及避免终端崩溃或笔记本进入睡眠后丢失上下文。

这正是 Herdr 最吸引我的地方。

Herdr 并不是又一个编程 Agent，而是一个 Agent multiplexer。简而言之，它是“面向编程 Agent 的 tmux”，但这里真正重要的词是 multiplexer。它运行在实际工作发生的地方，让真正的终端 pane 持续存活，理解 Agent 的状态，并提供 CLI 和 JSON socket API。这让它更像是运行时基础设施，而不是一个应用。

在工作所在之处运行

Herdr 的主页明确说明了它的产品形态：它是一个二进制程序，而不是一个应用。它可以运行在任何带有终端的机器上，包括服务器、Mac Mini、VM 或笔记本电脑。每个 Agent 都运行在自己独立的真实终端中。即使终端客户端已经断开，Herdr server 仍会让 pane 保持运行；你可以在本地重新连接，也可以通过 SSH，甚至可以从手机尺寸的终端重新接入。

严肃的 Agent 工作很少只是聊天。它需要 repository、依赖、测试数据库、日志、本地服务、限定范围的凭证，有时还需要运行某条你不希望因为合上笔记本屏幕而被终止的命令。

多年前，tmux 就已经为人类的终端工作解决了这个问题。Herdr 正在把同样的基本思路应用到 Agent 工作中，并在此基础上补充 tmux 所不具备的 Agent 专属能力。

手机这个卖点听起来有些讨巧，直到你真正开始使用 Agent。我不想在手机上审查一次支付迁移，但我确实希望能在手机上回答一条被阻塞的“run the dry-run command?” prompt。

真正的倍增器是并行执行与上下文不丢失

最朴素的 AI 编程循环仍然是串行的：提出要求、等待、阅读、调整方向、再次等待。这已经比所有事情都手动完成要好，但人类依然承担着调度器的角色。

Herdr 的价值在于，它为另一种工作循环提供了必要的组成部分：

• N 个运行在真实 PTY 中的 Agent，每个 Agent 分别处理自己的任务、repo 或 worktree
• blocked、working、done 和 idle 等语义状态
• 持久化 session，即使终端消失，工作也不会丢失
• 用于创建 pane、发送输入、读取输出和等待状态的 CLI 与 socket API
• Agent skill 文件，让运行在 Herdr 内部的 Agent 能够学习如何控制 Herdr 本身

这种性能提升并不是什么魔法，而是普通的并行执行，只不过减少了注意力的浪费。

如果三个任务彼此独立，却还要一个接一个执行，那就是人为制造延迟。人们之所以仍然这么做，是因为在普通终端里监管多个 Agent 非常麻烦。语义状态改变了这一点。如果 multiplexer 能告诉我“这个 Agent 被阻塞了”“这个 Agent 正在工作”“这个 Agent 已经完成”，我就可以把注意力用在真正重要的地方。

API 让这件事开始产生复利效应。Herdr 的 socket API 暴露了 pane、Agent、事件、等待机制和 session 快照。CLI 封装了常用操作，最近的版本还新增了一个面向在线 Agent 的 CLI facade，提供具名的 start、prompt、send-keys，以及由 server 管理的 wait 工作流。监督者不必再是一个盯着终端看的人类。

下面是我会采用的一套具体工作流。

首先，由一个人在 repo 中启动 Herdr session，然后创建三个 Agent pane：

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

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

接下来，由人类或 Agent 担任监督者，为它们分配范围明确的任务：

herdr agent prompt w1:p1 "Find why refund_webhook_test is flaky. Report evidence only."
herdr agent prompt w1:p2 "Upgrade the Stripe SDK. Run unit tests. Stop before config changes."
herdr agent prompt w1:p3 "Review pending migrations and propose a backfill plan."

现在，监督者可以等待状态变化，而不是同时盯着三个屏幕：

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

该项目周边的一些示例采用了 herdr wait agent-status 这种形式。当前版本的 release notes 表示，wait 工作流已经移到了 agent wait 下，因此请以已安装版本的 CLI reference 为准。设计思路并没有改变：等待语义状态发生变化，然后读取相关 pane。

人类仍然需要审查所有内容。改进之处在于，人类不再需要耗费脑力去记住每个终端分别在做什么。

与其他工具相比，它处于什么位置

tmux 和 Zellij 是最显而易见的比较对象。它们都是非常优秀的终端 multiplexer，能够持久化 pane，支持 detach 和 reattach，并且天然适合通过 SSH 使用。它们的局限在于：它们能够理解终端，却不能理解 Agent。tmux pane 可以让 Claude 或 Codex 持续运行，但 tmux 不知道该 Agent 是处于 blocked、done、idle，还是正在等待批准。

桌面端 Agent 应用通常面临相反的取舍。它们更了解 Agent 的使用体验，可以提供精致的审查界面、通知和 onboarding 流程。代价是，它们往往只能存在于 GUI 所在的地方。如果实际工作发生在服务器、Mac Mini 或 VM 上，以应用为中心的模式就会变得很别扭。

Worktree orchestrator 是另一个类别。Conductor、Emdash 和 Superset 等工具更接近工作流管理器。它们可以负责创建 branch、分配任务、收集 diff 和组织审查流程。Herdr 所处的层级更低。它提供持久存活的实时终端、Agent 状态和控制界面。你可以将它与 worktree、脚本、审查工具，以及任何你已经信任的编程 Agent 配合使用。

这种灵活性是它的优势。缺点则是，Herdr 仍然是一款以终端为原生环境的工具。如果你的团队需要 dashboard、托管的历史记录，以及便于管理层阅读的报告，那么 Herdr 并不打算解决这些问题。

爆炸半径也会随之扩大

并行 Agent 会成倍增加产出，也会成倍放大错误。

因此，我认为经验丰富的工程师最能发挥 Herdr 的价值。任何人都可以运行它，但 API 和并行监管都是锋利的工具。如果一个 Agent 能产生一份糟糕的 diff，那么三个 Agent 就能迅速产生三份糟糕的 diff。

正确的工作流其实很朴素：拆分范围明确的任务，在必要时使用相互隔离的 branch 或 worktree，进行明确的验证，并开展真正的人工审查。请谨慎对待 bypass-permissions mode。便利性不能代替安全模型。

我喜欢那些能提升吞吐量、同时又不会假装问责责任已经消失的工具。Herdr 看起来就属于这一类。它为工程负责人提供了一个更好的控制平面，用来管理基于终端运行的 Agent，但它并不会让审查负担凭空消失。

这是件好事。我想要的未来，是拥有这样一个运行时：可以在靠近代码的地方运行多个 Agent，让工作持续存活，一眼查看状态，并自动完成那些枯燥的协调工作。Herdr 瞄准的正是这一层。

Herdr 对比页面

Herdr socket API 文档

Herdr Agent skill 文件文档

Herdr GitHub repository

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

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