herder：多编程智能体的终端多路复用器，告别会话管理混乱

如果你同时运行多个编程智能体——比如 Claude Code、Codex、Pi 等——如何高效管理这些并行会话就成了一个真实的痛点。本文介绍的 herder，是一款专为编程智能体设计的终端多路复用器（terminal multiplexer），它把 tmux 的强大能力与现代化鼠标交互、智能体状态感知结合在一起。

什么是终端多路复用器？ 终端多路复用器允许用户在单个终端窗口中运行和管理多个独立会话。tmux 是目前最流行的实现，其历史可追溯至2007年——作为古老的 GNU screen 的现代替代品，tmux 引入了更清晰的 C/S 架构：服务端进程（tmux server）以守护进程方式在后台持续运行，通过 Unix 域套接字（Unix Domain Socket）与客户端通信。Unix 域套接字是一种仅用于同一主机内进程间通信的 IPC 机制，相比 TCP/IP 套接字省去了网络协议栈的开销，延迟更低、吞吐更高，且天然受文件系统权限保护——这也是 tmux 在本机上能高效传输大量终端输出数据的底层原因。即使客户端断开连接，所有会话依然存活。这一机制同时赋予了它极强的网络鲁棒性——SSH 中断不会杀死远程会话。herder 将 tmux 作为底层进程管理引擎，在其上构建了面向 AI 智能体的状态机和事件系统，实现了更高层的抽象。

值得一提的是，tmux 的「窗格」概念在 herder 的语境中被赋予了新的语义：每个窗格不再只是一块分割的屏幕区域，而成为一个独立的「智能体执行槽」——拥有自己的进程树、环境变量和 I/O 流。这种天然的进程隔离，是 herder 得以在无需额外容器或虚拟化的前提下，安全并行运行多个 agent 的关键物理基础。从操作系统视角看，每个窗格本质上是一个由 tmux server fork 出的伪终端（pseudo-terminal，pty）会话：内核为其分配独立的 pty 主从设备对，agent 进程的标准输入输出均通过 pty slave 端进行读写，而 herder 则通过 pty master 端监听和注入数据，实现对 agent I/O 流的完全感知与控制，而无需任何代码级侵入。

关于伪终端的更多细节： 伪终端（pty）是 Linux/Unix 内核提供的一种双向字符设备抽象。内核为每个 pty 分配成对的主从设备：slave 端（/dev/pts/N）行为与真实串行终端完全一致，程序写入 slave 的数据会出现在 master 端，反之亦然。这使得 tmux 等终端复用器可以在不修改任何应用程序代码的前提下，完全代理其 I/O 流——agent 进程「以为」自己在与真实终端交互，实际上所有字节都经过 tmux server 的 master 端转发与记录。正因如此，herder 对 agent 输出的轮询扫描是完全透明的：既不需要 agent 主动上报状态，也不需要在 agent 进程中注入任何钩子代码。

什么是 herder，为什么需要它

随着 AI 编程助手的普及，越来越多开发者开始「一次跑好几个 agent」：一个负责改 README，一个跑迁移调研，一个盯着开发服务器。传统的 tmux 虽然能做会话管理，但纯键盘绑定的操作方式对多智能体场景并不友好，更关键的是它无法感知每个 agent 的运行状态。

herder 的定位正是解决这个问题。它保留了 tmux 那套「工作区 / 标签页 / 窗格 / 会话」的组织结构，但额外做了两件事：一是原生支持鼠标操作，二是能实时告知每个编程智能体当前处于何种状态——空闲（idle）、运行中、需要输入还是被阻塞（blocked）。

安装过程非常简洁，官方提供一键脚本，复制到终端执行即可完成。

三步完成初始配置

使用前建议额外完成两项配置，这两步决定了 herder 能否发挥全部威力。

添加编程智能体集成

在 Quick Start 的 Integrations 页面中，为你实际使用的编程智能体（如 Pi、Codex）添加集成。这一步让 herder 能够识别并追踪这些 agent 的运行状态，也是左侧「agent state」扩展能显示智能体状态的前提。

herder 识别 agent 状态的技术原理值得简要说明：它通过持续轮询（polling）各窗格的终端输出流，结合预先配置的「状态特征字符串」（如 Claude Code 等待输入时的特定提示符格式），使用正则表达式进行模式匹配，从而推断 agent 当前所处的状态阶段。这种方式无需修改 agent 本身的代码，以「观察输出」代替「侵入进程」，是一种低耦合的状态感知方案。在工程实现上，herder 对各主流编程智能体维护了一份「状态特征库」——例如 Claude Code 在等待用户确认时会输出固定格式的提示符，Codex 完成任务后会打印特定的结束标记。herder 将这些特征以正则表达式形式预置，并以约100ms的轮询间隔持续扫描各窗格的 pty 输出缓冲区，一旦匹配即触发状态机跃迁，将该窗格的 agent 状态更新为对应枚举值（idle / running / waiting_input / blocked），再通过事件总线通知 UI 层刷新显示。

安装 Agent Skill 文件

第二步是安装 agent skill 文件，这是后文最精彩功能的基础。通过 npx skills add 指向对应的 GitHub 仓库，克隆后自动定位其中的 skill 文件，并勾选所有需要启用的编程智能体。推荐全局安装（global），这样所有会话都能调用 herder 的能力。

Agent Skill 文件是什么？ Skill 文件是一种结构化的工具描述文件（通常为 JSON、YAML 或 Markdown 格式），用于告诉编程智能体「如何调用某个外部工具」。其原理类似于 OpenAI 的 Function Calling 或 Anthropic 的 Tool Use：将工具的名称、参数和调用方式以机器可读的格式注入到 agent 的上下文中。

要理解 Skill 文件的价值，需要先了解 LLM 工具调用能力的演进背景。早期 LLM 只能生成文本，无法直接与外部系统交互。2023年 OpenAI 推出 Function Calling 机制后，开发者首次能以结构化方式告知模型「你可以调用这些函数」，模型不再只是输出自然语言，而是能生成符合预定 schema 的 JSON 调用请求，由宿主程序解析并实际执行。Anthropic 随后在 Claude 中引入了语义等价的 Tool Use 机制。这类机制的共同局限在于：工具描述与具体 agent 框架深度耦合，跨框架复用极为困难。

值得注意的是，2024年 Anthropic 推出的 Model Context Protocol（MCP） 正试图将这类工具描述标准化——类似于代码编辑器生态中的语言服务器协议（LSP）之于各类编程语言工具链。LSP 在2016年由微软随 VS Code 推出，将「编辑器」与「语言理解能力」彻底解耦：任意编辑器只要实现 LSP 客户端，就能接入任意语言的补全、跳转、重构能力，无需为每对编辑器-语言单独开发插件。MCP 的野心与此如出一辙：定义一套客户端-服务端协议，使 LLM 应用能够以统一方式接入外部工具、数据源和操作能力，目标是打破各家 agent 框架各自为政的工具描述格局。MCP 协议层基于 JSON-RPC 2.0，传输层支持 stdio 和 SSE 两种模式，截至2025年初已有数百个社区实现的 MCP Server，覆盖数据库、文件系统、浏览器自动化、代码执行等场景，多家主流 IDE 和 agent 框架已宣布原生支持。herder 的 skill 文件可视为这一方向在终端管理领域的具体实践，也可理解为 MCP 思想在该领域的早期独立实现：它将 tmux 的窗格操作（创建、分屏、读取输出、发送输入）封装为结构化的工具声明，注入到 agent 的工具列表中，使 agent 具备感知和操控终端环境的能力，从而实现跨进程的任务编排。

从信息流向看，skill 文件本质上是一座双向桥梁：agent 通过它「写入」指令到 herder（如「打开新窗格并运行此命令」），也通过它「读取」herder 的状态（如「获取窗格3当前的输出内容」）。这种读写能力的组合，才使得后文「主 agent 派生子 agent 并汇总结果」的工作流成为可能。

核心概念：工作区、智能体、标签页与窗格

输入 herder 即可启动一个会话，界面由几个关键部分组成。

工作区（Workspaces）

工作区对应一个项目。相比 tmux 必须记住一堆键位，herder 支持直接用鼠标点击「新建」「关闭」。键盘党也没被抛弃——前缀键是 Ctrl+B，按下后再按 ? 即可查看所有快捷键，例如新建工作区是 Ctrl+B Shift+N。

工作区的设计理念借鉴了现代 IDE 的「项目」概念，但在终端层面实现：每个工作区对应一个独立的 tmux session 命名空间，其中的环境变量、工作目录默认值和窗格布局均可独立配置。这意味着你可以为「前端项目」和「后端服务」各开一个工作区，它们的 NODE_ENV、PATH 等环境配置完全隔离，agent 不会因环境污染产生意外行为。在 Unix 进程模型中，每个工作区的 shell 进程从 tmux server fork 时会继承一份独立的环境变量副本，后续对该副本的修改（如 export 命令）不会跨工作区传播——这是 Unix 写时复制（copy-on-write）进程语义的天然馈赠，herder 无需任何额外的隔离机制即可获得此特性。

智能体、标签页与窗格

在工作区内，你可以通过标签页（tabs）或窗格（panes）组织不同的 agent 和进程。点击即可在多个智能体之间自由切换。

窗格用于分屏操作：Ctrl+B \ 垂直分屏，Ctrl+B - 水平分屏，Ctrl+B X 关闭窗格。这样，一个 agent 在写代码的同时，旁边的窗格可以跑着 dev server，互不干扰。

状态感知：herder 最实用的核心能力

herder 真正区别于普通终端多路复用器的地方，在于它能主动告知每个智能体的状态。当某个 agent 需要授权继续执行时，界面会标记为「blocked」，点击即可查看原因并授权；当任务完成时，herder 会发出通知提醒。

「blocked」状态的检测机制体现了 herder 的工程细节：许多编程智能体（如 Claude Code）在请求执行高风险操作（写文件、运行 shell 命令、访问网络）前会暂停并等待用户确认，这在终端输出中表现为特定的交互提示符。这类「人机确认」机制的设计初衷来自 AI 安全领域的「最小权限原则」（Principle of Least Privilege）：agent 默认不应拥有无限制的执行权限，每次涉及副作用的操作都应显式获得授权，以防止模型幻觉（hallucination）导致不可逆的破坏性操作。herder 通过预置各 agent 的「阻塞特征库」，能在毫秒级别识别这类等待状态，并在界面上以醒目的视觉标记通知用户——本质上是把分散在多个终端窗口中的「需要你注意」信号，统一汇聚到一个中央调度视图。

同时跑多个 agent 分别处理不同任务时，靠这套状态提示就能从容地在多个会话间调度，不必反复切回去确认进度。对于不想被反复打断的场景，还可以把 agent 切到 auto 模式，让它自动通过权限请求。

会话持久化：关掉窗口也不怕丢进度

多智能体工作流最怕意外关闭窗口导致进度丢失。herder 在这一点上提供了充足的安全感——即便直接关掉窗口，或用 Ctrl+B Q 退出，所有工作都不会丢失。这背后正是 tmux 服务端进程独立于客户端存活的架构优势：客户端（终端窗口）只是一个「观察者」，服务端才是真正持有所有进程状态的实体。

从操作系统原理来看，这一特性利用了 Unix 的进程组与会话（process group & session）机制：tmux server 作为独立的守护进程，其子进程（各 agent）的父进程 ID 指向 server 而非终端窗口，因此关闭终端发出的 SIGHUP 信号不会沿进程树传播到 agent。SIGHUP（Signal Hang Up，信号编号1）是 Unix 的一个经典信号，最初设计用于通知进程「控制终端已挂断（如调制解调器断线）」，现代系统中当控制终端关闭时内核会向该终端的前台进程组广播此信号，默认行为是终止进程——这正是直接关闭普通终端窗口会杀死其中所有进程的根本原因。tmux server 通过 setsid() 系统调用脱离原始控制终端，自立为新的会话领导进程（session leader），从而彻底切断了与任何客户端终端的 SIGHUP 传播路径。herder 进一步在此基础上增加了状态快照功能，定期将工作区布局、窗格内容和 agent 配置序列化到磁盘，确保即便 tmux server 本身意外重启，工作现场也能完整恢复。

只要重新输入 herder，之前所有工作区、标签页、正在运行的智能体都会原样恢复。这种持久化机制让「随手关、随手开」成为可能。

herder 还引入了「会话（sessions）」概念。默认会话叫 default，你可以额外创建 work、personal 等独立会话，彼此完全隔离。通过 herder session attach work 即可切到对应会话，各自内容互不干扰。

杀手锏：让智能体自己调度 herder

herder 最令人眼前一亮的功能，来自前面安装的 agent skill 文件。有了它，编程智能体本身就能理解如何操作 herder 的窗格。

多智能体系统的背景 多智能体系统（Multi-Agent System，MAS）的理论根基可追溯至1980年代的分布式人工智能研究，彼时研究者探索如何让多个专用「专家系统」协同解决单一系统难以独立完成的复杂问题。专家系统（Expert System）是当时 AI 研究的主流范式——将特定领域的人类专家知识编码为规则库，由推理引擎进行逻辑推断。单个专家系统受限于领域边界，MAS 研究者于是设想通过「黑板架构」（Blackboard Architecture）让多个专家系统共享一块公共数据结构，各自将结论写入黑板并读取他者的输出，从而协同解决跨领域问题。这一思想在今天 herder 的「主 agent 读取子 agent 窗格输出」机制中清晰可见，tmux 的 pty 输出缓冲区扮演了现代版「黑板」的角色。在现代 LLM 时代，OpenAI Swarm、Anthropic multi-agent 框架、微软 AutoGen 等项目重新激活了这一方向，核心挑战在于：各 agent 之间如何共享状态、避免资源竞争、汇总结果。

与此同时，LLM 推理成本在近两年内已下降约100倍（以每百万 token 计价衡量），使「用多个 agent 并行完成任务」从奢侈变得经济可行——当两个调研任务相互独立时，并行执行可将总耗时压缩近50%，而额外的计算成本已微不足道。这一经济结构的根本变化，是多 agent 工作流从「技术可行」走向「日常实践」的真正驱动力。推理成本的下降曲线与历史上 DRAM 价格下降（大致遵循摩尔定律）、云存储成本下降（S3 自2006年上线以来价格下降超过99%）的规律高度相似：当某种计算资源的单价足够低廉，开发者的架构选择就会从「节约该资源」转向「大量消耗该资源以换取其他维度（速度、质量、并行度）的提升」。以 GPT-4 为基线：2023年初其 API 价格约为每百万 token 60美元，2025年同等能力模型的价格已降至0.6美元以下，降幅超过99%——正是这一成本拐点让 herder 所代表的多 agent 并行架构从「有趣的实验」变为「合理的生产默认选项」。

herder 的方案偏工程化而非框架化：它不试图构建一套新的 agent 通信协议或消息总线，而是借助操作系统级别的进程隔离（每个窗格是独立进程）天然解决隔离问题，通过读取窗格的标准输出（stdout）实现结果汇总，且不依赖任何特定的 agent 框架 API。这意味着它天然兼容任何能在终端运行的编程工具——无论是开源的 Aider、商业的 Cursor CLI，还是尚未问世的未来工具，只要能在终端中交互，都可以纳入 herder 的调度体系。这是一种以「终端标准 I/O」为最小公约数的轻量级多智能体协作路径，以普适性换取了框架无关性。

以下是一个极具说服力的例子：Pi 本身默认不支持子智能体（sub agents），但借助 herder 的 skill，只需下达一句指令——「开两个 herder 窗格，各放一个 agent，分别调研迁移到 Python 和迁移到 REST 各需要多少工作量」——主 agent 就会加载 herder skill，自动分屏并派生出两个子智能体并行工作。

两个子 agent 各自完成调研后，主 agent 还能读取两个窗格的输出，直接给出「哪种迁移更简单」的对比结论。这一过程在架构上实现了一个完整的 MapReduce 模式：主 agent 负责任务拆解与分发（Map），两个子 agent 并行执行各自的调研（并行计算），主 agent 最终读取结果并综合分析（Reduce）。MapReduce 最初由 Google 在2004年的论文中提出，用于在廉价商用服务器集群上处理 TB 级数据，其核心洞见是：将计算逻辑拆解为无状态的 Map 函数（对各数据分片独立处理）和聚合的 Reduce 函数（合并所有 Map 输出），即可自动实现并行化与容错。

值得注意的是，herder 的多 agent 工作流天然满足 MapReduce 对 Map 函数「无状态且幂等」的核心约束：每个子 agent 窗格运行在独立的 pty 会话中，拥有自己的进程树和环境变量副本，相互之间除主 agent 的读取操作外没有任何共享状态。这意味着即便某个子 agent 崩溃或超时，主 agent 只需重新派生该窗格即可重试，不影响其他并行任务的进度——这是借助 Unix 进程隔离免费获得的容错语义，无需任何额外的错误处理框架。herder 将 MapReduce 思想从数据处理迁移到了智能体任务编排领域：任务拆解（Map）、并行执行（各窗格独立运行）、结果汇总（Reduce），而整个流程无需任何专用的多 agent 框架，仅凭终端标准 I/O 即可完成。这相当于在没有原生子智能体能力的工具上，通过 herder 实现了多智能体并行调研的完整工作流。

总结

herder 将 tmux 的组织能力、现代化鼠标交互、编程智能体原生状态感知以及会话持久化整合为一体。对于同时使用多个编程智能体的开发者来说，它解决了「管理混乱」和「进度丢失」两大核心痛点，而 agent skill 带来的「让智能体自我编排」能力，更将它从单纯的管理工具提升为多智能体协作的调度中枢。

从更宏观的视角看，herder 代表了一种务实的 AI 工具哲学：不追求构建全新的 agent 框架或通信协议，而是在现有的 Unix 工具生态（tmux、标准 I/O、进程模型）上做最小必要的抽象，让 AI 能力自然嵌入开发者已经熟悉的工作流。这种「增强而非替代」的设计思路，与 Unix 哲学中「做好一件事、并与其他工具协作」的传统一脉相承——tmux 专注于终端复用，herder 专注于 agent 状态感知与编排，二者通过标准接口组合，产生了远超各自单独使用时的协同效果。这或许正是它能够快速投入实际生产的关键所在。如果你正在使用多个编程智能体，herder 几乎是一款不可绕过的基础设施。