herdr：让不同AI Agent在终端层互发消息协作

从Claude Code的新功能说起

昨天Claude Code官方发布了一条更新：你的各个会话现在可以互相发消息了。这个功能解决了一个真实的痛点——以前每次换个会话，你都得把上下文和背景重新解释一遍，费时费力。有了会话互通后，你可以直接让一个Claude会话去跟另一个会话「对话」，省去了大量重复劳动。

这个功能确实非常实用，但它有一个明显的限制：这种互通只发生在Claude和Claude之间。换句话说，官方的实现是「应用层」的互通，Claude对Claude发送的是一段摘要信息，天然被锁死在同一个生态内。

如果你同时在用Codex、Cursor、或者其他编码Agent，它们之间就无法通过官方渠道对话。而今天要介绍的工具——herdr，则把这个能力提升到了另一个层次。

herdr是什么

herdr是一个终端复用器（terminal multiplexer），用Rust编写，编译成单个二进制文件，通过一行cargo install就能安装完成。官网给它的定位很直接：你的编码Agent住在herdr上。

如果你用过tmux，那herdr的底子会让你觉得很眼熟——都是在终端里管理多个窗格。但两者关注的问题截然不同。

tmux只回答一个问题：进程还活着吗？ 它是一个通用的会话管理工具，并不关心你在窗格里跑的是什么。

而herdr回答的是另一个问题：活着的这个进程，正在等谁？ 这是专为AI Agent协作场景设计的思路。它会认出每个窗格里跑的是哪个Agent，并为每个Agent维护一个有限状态机。

四种Agent状态一目了然

herdr为每个Agent维护的状态包括：

• Working：正在干活
• Block：卡在等你拍板做决定
• Idle：干完了活但你还没看，暂时没事干
• Unknown：识别不出来当前状态

当你同时跑着五六个Agent时，这个设计的价值就体现出来了——扫一眼侧边栏，谁在干活、谁在等你，一目了然，不用逐个窗格去检查。

终端复用器（terminal multiplexer）是一类允许用户在单个终端窗口中同时管理多个独立终端会话的工具。最广为人知的实现是tmux和screen。其核心价值在于：进程与终端的解耦——即使用户断开SSH连接，运行在复用器内的进程也会持续存活；同时支持窗格分割，让多个进程的输出可以在同一屏幕上并排展示。对于AI Agent这类需要长时间运行、且往往同时启动多个实例的工作负载，终端复用器天然是理想的宿主环境。herdr在继承这一基础能力的同时，在其上构建了专为Agent协作设计的状态感知与进程间通信层。

有限状态机（Finite State Machine，FSM）是计算机科学中描述系统在有限个离散状态之间如何转移的模型。herdr为每个Agent维护有限状态机，意味着它不只是被动展示Agent的输出文本，而是主动解析输出内容，通过模式匹配等手段识别Agent当前处于哪个阶段——例如，Agent输出了等待用户输入的提示符，就被判定为Block状态；输出流停止但进程仍在运行，则判定为Idle。这种状态驱动的设计使得herdr能够在Agent之间做出「等对方干完再发消息」这类需要感知对方状态的协调动作，而不仅仅是盲目地发送命令。

核心能力：为Agent设计的命令行

herdr最关键的设计在于：它的命令行是设计给Agent自己用的，而不只是给人用的。

这意味着，让一个Agent给另一个Agent发消息，就是一行命令的事：herdr agent prompt。更进一步，「发消息」和「等结果」还能被合成为一次原子调用——Agent发出请求后可以直接等待对方的响应，形成完整的协作闭环。

herdr的文档里有一句话很讲究：它不包装、也不替换任何Agent，只是拥有它们的终端。这句话点明了它的设计哲学——herdr不去干预Agent本身的逻辑，只是通过掌控终端这一层，实现对任何Agent的识别和通信。

这种「终端层」的定位，正是它区别于Claude Code官方方案的根本所在。

实际体验：三个Agent的对话

UP主实际动手玩了一下：开了三个窗格，分别跑着Pi、Pimmy和Hermes三个Agent。

然后让Pi给Hermes发了一句「Hi，来自herdr的问候」。消息发出后，Hermes的状态立刻从Idle变成了Working，开始思考如何回应。而Pi则像个等回信的人，隔几秒读一次Hermes的终端，看到对方有动静后，直接喊出「成功了」。

整个过程展示了Agent之间自主协作的完整链路：发起、等待、感知对方状态、确认结果。

最有意思的插曲是，Hermes在整个过程中一直在猜「herdr」到底是什么，它甚至以为这是某个飞书机器人的名字——一个AI在努力理解另一个陌生工具身份的场景，颇为生动。

应用层 vs 终端层：两条路线的差异

回到开头那条Claude Code的更新，我们可以把两种方案做一个清晰的对比：

官方方案：应用层互通

• 互通发生在应用层
• Claude对Claude发送的是一段摘要
• 仅限于Claude生态内部
• 集成度高、开箱即用

herdr方案：终端层互通

• 互通发生在终端层
• 任何能被herdr识别的Agent都能互发消息
• 目前官方集成已达17个，包括Claude Code、Codex、Open Code、Pi、Cursor等
• 需要用户自行搭建和配置

说个细节，无论哪种方案，本质上都是让Agent之间开始对话。但终端层的路径明显适配了更多场景。

「应用层」与「终端层」的划分对应了不同的集成抽象层次。应用层互通要求协作双方使用同一套SDK或API协议，本质上是厂商主动开放的功能，平台方对数据格式和传递内容有完整的控制权；其优势是集成体验好、安全边界清晰，但天然形成生态壁垒。终端层互通则绕过了应用层协议，直接在操作系统的进程与I/O层面进行拦截和注入——herdr通过「拥有终端」，可以向任意进程的标准输入写入数据、从标准输出读取内容，因此对Agent本身没有任何接口要求，只要该Agent运行在终端里、能被识别状态即可纳入协作体系。这种方式的代价是配置成本更高，且依赖herdr自身对各Agent输出格式的适配维护。

能搭建什么样的工作流

终端层互通带来的最大想象空间，是跨Agent的自动化工作流。

举个最直接的例子：Agent A写完代码后，自动把结果发给Agent B去做Code Review。这样的工作流，借助herdr你今天就可以搭建起来，而不用等待某个厂商在应用层做官方集成。

更广泛地看，随着多Agent协作成为编码领域的新趋势，「谁负责哪一环、如何传递上下文」将成为关键问题。herdr这种不侵入、只掌控终端的思路，为异构Agent之间的协作提供了一个轻量而灵活的底座。

对于同时在使用多个AI编码工具的开发者来说，herdr值得一试——它不强迫你迁移到某个生态，而是让你现有的各种Agent学会「彼此对话」。