herdr：為終端編碼智能體打造可脫離、可編排的運行時

过去一年，终端里的编码智能体越来越多。Claude Code、Codex、Cursor、OpenCode 各有各的命令行界面，开发者常常同时开着好几个终端窗口：一个在改前端，一个在跑测试，还有一个停在那里等你确认权限。窗口一多，麻烦就来了。哪个智能体已经卡住了？SSH 一断，正在跑的任务会不会跟着消失？换一台机器，又得重新翻找会话。传统的 tmux 能保住会话，但它不认识"智能体"这个概念，眼里只有一堆字符流。herdr 要补的正是这一层。

它自称"编码智能体赖以生存的运行时"，既不是又一个智能体，也不打算取代任何现有智能体，而是接管这些智能体所在的终端，让它们有一个稳定、可观察、可被编排的家。项目用 Rust 写成，在 GitHub 上已有四万五千多颗星，可见这个需求相当普遍。放进行业生态里看，它位于智能体命令行工具与操作系统终端之间，更像一个面向智能体的终端复用器，外加一层调度能力。具体来看，herdr 的能力可以分成几块。第一块是脱离而不中断。关闭客户端或丢失 SSH 连接后，终端仍由后台服务进程保持运行。如果服务端或整台机器重启，herdr 会恢复保存的布局，并能续接受支持的智能体会话。但官方说得很清楚：原来的进程不会幸存，恢复的是布局与会话，不是进程本身。

第二块是多机合一。本地工作和已保存的 ssh 机器可以放在同一个窗口里，智能体列表合并显示，每台机器各自独立重连，一台掉线不会拖垮其他几台。第三块是状态标记。每个窗格都会被标成 working、blocked 或 idle，智能体停下来等你回答时，herdr 会直接告诉你，不必逐个窗口巡查。第四块最有意思，叫 agent-native。智能体可以通过命令行和 socket API 驱动 herdr：创建新窗格，给其他智能体发提示词，还能等到另一个智能体真正被阻塞之后再行动。这样一来，多智能体协作不必先搭一套额外的编排框架，终端本身就是协作的场所。兼容性方面，Claude Code、Codex、Cursor、OpenCode、Grok 等都能直接运行，herdr 只拥有它们的终端，不做包装。

交互上，tmux 风格的前缀键和鼠标点击、拖拽、分屏都是一等公民，另有插件机制和插件市场。整个产品是一个 Rust 二进制，不依赖 Electron，在你现有的终端里就能跑。上手路径很短。安装只需一行 curl 脚本，也可以用 brew install herdr 或 mise use -g herdr，Windows 有 PowerShell 安装脚本，另外还提供发布页的预编译二进制。装好后，在工作所在的目录直接运行 herdr，启动几个智能体，按需分屏，然后用 ctrl+b q 脱离，需要时再运行 herdr 重新接入。一个典型场景是在远程开发机上同时跑几个智能体，傍晚合上笔记本离开，第二天回来重新连上，布局和会话还在，哪个窗格在等你回答也一目了然。文档站覆盖面完整，包含快速上手、核心概念、支持的智能体、键位、配置、会话状态、多机连接、远程持久化、集成、插件和 socket API。如果你在开发自己的智能体，还有专门的文档讲如何加入 herdr 支持。

仓库里有 AGENTS.md 和 CONTRIBUTING.md，明确要求参与仓库的 AI 智能体在改动前先阅读，这对一个以智能体为主要用户群之一的项目来说，是很自洽的做法。想参与开发的人，用 cargo build --release 即可构建，just test 跑单元测试，just check 跑格式、测试和维护检查。从行业角度看，herdr 的意义在于它把"终端"当成智能体时代的基础设施来重新设计。过去我们把智能体当成一个个孤立的命令行程序，现在它们要长时间运行、互相协作、跨机器分布，就需要一个懂得"谁在工作、谁被卡住、谁能被唤醒"的底座。对工程团队来说，这能明显降低同时管理多个智能体的注意力成本。当然也有几处风险值得留意。其一，恢复不等于进程存活，重启后的续接依赖各智能体自身对会话恢复的支持，不能想当然。其二，socket API 让智能体能创建窗格并向彼此发指令，权限边界和安全面需要使用者自己认真把握，尤其是在多台机器之间。其三，对各智能体状态的识别需要适配，智能体升级后行为变化，适配可能要跟进。另外，输入资料中的许可证说明被截断，正式引入团队之前，应当先到仓库核对许可证条款。后续值得观察的方向有三个：插件市场能否长出真正的生态，支持的智能体范围会扩到多大，以及多智能体互相等待、互相提示的协作模式，能否在真实项目里沉淀出稳定的工作流。