从单 Agent 到吞吐量模型：Herdr 的多 Agent 并行工作流

大多数 AI 编程工具在讨论时，仍然默认生产力的基本单位是“一名工程师搭配一个 Agent”。这种模式用来演示很直观，但未来的工作流不会止步于此。

真正值得关注的问题是：能否让多个 Agent 持续推进任务，同时又不丢失终端状态、不失去对代码 diff 的控制。

这正是 Herdr 吸引我的地方。

Herdr 将自己定义为一个 Agent 多路复用器（agent multiplexer）。这个定位上的区别很重要。它并不想成为承载所有工作的应用，而更像是为编码 Agent 打造的 tmux：在终端持久化模型之上，增加了对 Agent 状态的感知。

你可以把它运行在真正承载工作的环境中，比如服务器、Mac Mini、VM 或远程开发机。Agent 会在真实的终端 pane 中运行。即使合上笔记本电脑，会话也会继续执行。你可以通过 ssh 重新连接，甚至可以用手机接入。

我认为，Agentic Development 正朝着这个方向发展：少一些“一个无所不能的神奇应用”，多一些“用于受监督并行工作的运行时”。

吞吐量来自并行

最直观的收益，是可以让多个 Agent 并排工作。一个 pane 修复 bug，另一个编写测试，第三个研究依赖升级。每个 Agent 都有自己的 PTY、工作上下文和终端进程。

你当然也可以手动打开三个终端标签页来完成这些工作。问题在于注意力。启动第二个或第三个 Agent 之后，瓶颈就不再是模型速度，而是监督：哪个被阻塞了？哪个已经完成？哪个还在等待？

Herdr 真正实用的增量，是语义化状态。它会将 Agent 标记为 blocked、working、done 或 idle。这样一来，终端 pane 就更像一个运维仪表盘，却又不需要真的变成浏览器里的仪表盘。你可以快速扫一眼整个会话，跳转到需要你介入的 pane，进行批准或调整方向，然后继续处理下一个。

这才是真正的吞吐量模型：

• 可以同时激活更多 Agent

• 人类只在确实需要关注时投入注意力

• 断开连接后，终端状态仍然保留

• Agent 可以通过 Herdr 的控制界面相互协作

其中能够产生复利效应的，是最后一点。

Herdr 提供了 CLI 和 JSON socket API。文档展示了用于创建 workspace、tab 和 pane，运行命令、读取输出以及等待 Agent 的各种命令。socket API 也提供了类似的控制能力，覆盖 workspace、tab、pane、Agent、事件和状态。

这意味着，多路复用器不只是为人类准备的，Agent 同样可以使用它。

herdr workspace create --cwd ~/src/payments --label payments
herdr pane split w1:p1 --direction right
herdr pane run w1:p2 "npm test"
herdr agent wait w1:p1 --until done
herdr pane read w1:p2 --source recent --lines 50

不要把它仅仅理解成一个讨巧的自动化技巧，而应该把它看作一种全新的工程工作流形态。负责监督的 Agent 可以创建 pane、启动辅助 Agent、等待状态变化、读取它们的输出，并总结出需要人类审查的内容。

设想一次服务迁移，其中包含三块相互独立的工作。

Agent 1 负责 API 变更、请求校验、响应序列化和契约测试。

Agent 2 负责数据库相关工作，包括 migration、seed data 和本地集成测试套件。

Agent 3 负责客户端与文档变更，包括 SDK、示例和 changelog。

第四个 Agent 充当监督者。它在不同的 pane 中启动另外三个 Agent，等待状态变化，在某个 pane 进入 blocked 或 done 状态时读取其最近输出，并维护一份简短的协调记录。当 Agent 2 已经完成，而 Agent 1 因契约测试失败陷入阻塞时，监督 Agent 会将这个问题呈现出来。

人类仍然要审查每一处 diff。人类仍然要决定这次 migration 是否可以接受。最终的 merge 仍然由人类负责。

但等待时间发生了变化。三条工作流不再顺序执行，而是在监督者留意中断事件的同时并行推进。假设每项任务需要 25 分钟的 Agent 时间和 5 分钟的人类审查时间，那么真正的收益并不是“AI 写了代码”，而是 75 分钟的 Agent 工作时间彼此重叠了。

这是一种实际可用的生产力倍增机制。不是魔法，而是调度。

最接近的心智模型是 tmux 或 Zellij。它们提供持久化终端会话、pane，以及分离和重新连接能力，都是非常出色的工具。我自己依然喜欢 tmux。但它们不知道什么是 Agent，也无法告诉你某个编码 Agent 是 blocked、done、idle，还是仍在 working。

桌面端 Agent 应用的取舍正好相反。它们通常能够感知 Agent，并提供更友好的任务视图和更明确的审查流程。代价则是运行位置：如果应用运行在带 GUI 的机器上，工作就会被绑定到那台机器。当真正的工作环境位于服务器、Mac Mini 或 VM 上时，这会很别扭。Herdr 的核心主张是：运行时应该存在于工作实际发生的地方。

Worktree 编排工具可能非常强大，因为它们掌控了整个工作流，包括分支、worktree、检查流程和审查界面。代价则是结构约束。对于拥有标准流程的团队来说，这可能是好事；但如果你只是想为今天使用的任意 Agent、repo 或任务形态准备一个灵活的终端运行时，这种约束就可能令人厌烦。

Herdr 并不会天然胜过这些工具。它的定位更窄，也更具 Unix 风格。你需要习惯终端、pane、ssh，以及审查 diff。如果你想要一个精致的桌面控制台，它可能会显得过于底层。如果你想要一个从 ticket 一路负责到 PR 的产品，Herdr 又可能显得过于灵活。

这没有问题。我更喜欢清楚自己定位的工具。

爆炸半径也会并行扩大

这个警告显而易见，但仍然值得明确说出来。

并行 Agent 意味着并行的爆炸半径。

如果你让三个拥有宽泛权限的 Agent 在三个 repo 中运行，那么你增加的不只是产出，也增加了错误指令或鲁莽的 shell 命令可能造成破坏的位置数量。

Herdr 并不能消除对工程判断力的需求，反而会让这种需求变得更强。审查 diff，控制任务范围，不要随意向 Agent 授予绕过权限的能力，并谨慎处理 secrets 和生产环境访问权限。

因此，我认为经验丰富的工程师最能发挥 Herdr 的价值。任何人都可以运行它，但真正的杠杆来自这些能力：知道如何安全地拆分工作、哪些任务可以委派、何时需要中断，以及如何验证结果。如果你已经习惯从自动化边界和故障模式的角度思考问题，那么它的 API 尤其值得关注。

Herdr 不能取代判断力。它的作用，是让你能够在正确的时间，把判断力投入正确的 pane。

在我看来，这才是关于 AI 编程吞吐量更诚实的叙事。未来并不是一个 Agent 完美地替你完成工作，而是多个并不完美的 Agent 并行运行，同时具备足够可靠的持久化、状态管理和监督机制，让人类可以始终站在噪声之上。

这听起来不像常见的 AI 生产力宣传那样神奇，但听起来更接近真实的工程工作。

Herdr Agent skill 文件

GitHub 上的 herdrdev/herdr

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

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