herdr：给 Agent 一个专属终端运行时，是不是伪需求？

系列第 04 篇。前三篇聊了决策层分层、MCP 安全风险、技能层 ECC。这次往下走一层------Agent 跑在哪？

一、先问个实在的：你的 Agent 住在哪？

我用 Claude Code 有阵子了，平时开一个不够开两个，两个不够开三个：一个写业务代码，一个改测试，第三个做 Code Review。

问题很快就来了。

三个终端长得一模一样，我得一个个切进去看才知道哪个卡住了、哪个在等我确认。合个盖子的功夫，再打开终端还在，Agent 进程多半已经挂了。远程服务器上更糟，SSH 一断，整个会话没了，之前的上下文全丢。

用过 tmux 的人第一反应都是：这不就是终端多路复用器干的事吗？开个 tmux 不就完了？

我原先也是这么想的。直到看到 herdr。

二、herdr 是什么

官方定位就一句话：the agent runtime：编码代理的运行时。

说人话：一个专门给 AI 编码 Agent 做的终端多路复用器。重点在"专门给 AI 编码 Agent"。它不是又一个 tmux 轮子：tmux 是给人用的，herdr 是给 Agent 用的。区别在哪，往下看。

2.1 实测安装：Windows 上能跑吗？

先说结论：能，而且比我预想的顺。

我在 Windows 11 上测的。官方给了 PowerShell 一键安装脚本，但国内直连 GitHub Releases 超时（你懂的），我换成了镜像站下 zip 包，解压就用：

复制代码

herdr-windows-x86_64.zip 解压后：
├── herdr.exe              ← 主程序，25.5MB
├── conpty/                ← ConPTY 运行时
│   ├── x64/OpenConsole.exe
│   └── arm64/OpenConsole.exe
├── conpty.dll
└── herdr-conpty.json

几个点：

Rust 单二进制，25.5MB，无动态链接库依赖（但 Windows 下运行时需携带 conpty 目录，见下文）
Windows 用 ConPTY（Windows 原生伪终端），不是模拟终端，全屏 TUI 能正常渲染
版本 0.9.1 stable；官方文档页面虽仍沿用 windows-beta 标注，但文案已写明 Windows 原生支持为 Generally Available，并非 preview

跑一下确认：

复制代码

> herdr --version
herdr 0.9.1

干净。

踩过的坑 ：一开始我想只把 herdr.exe 单独拷出来用，结果启动报错------Windows 版必须带着 conpty 目录和 conpty.dll 一起，不能只复制主程序。这点文档里提了，但我没仔细看，浪费了十分钟。

2.2 技术架构一瞥

在聊功能之前，先说说 herdr 的技术选型，后面很多设计都跟这个有关。

herdr 是 Rust 写的单二进制，核心依赖就几个：

portable-pty：跨平台 PTY 库，保证每个面板是真实的伪终端，不是应用层模拟的。这是 Agent TUI 能正常显示的基础------如果是模拟终端，Claude Code、Codex 这些全屏界面会乱掉
tokio：异步运行时，处理多面板并发 I/O。几十个面板同时有输出的时候，不能阻塞
服务器/客户端架构 ：herdr-server 在后台跑，终端面板"活在"服务器里。客户端 attach 上去显示，detach 下来服务器继续跑。这就是会话持久化的基础

架构上跟 tmux 是一个路子（都是 server-client + PTY），但 herdr 在上面加了一层 Agent 感知------这是跟 tmux 最本质的区别。

2.3 命令体系比我想的复杂

herdr --help 的输出很长，我归了个类：

类别	子命令	作用
会话	`session list/attach/stop/delete`	持久化会话，detach 再 attach
工作区	`workspace list/create/close`	按项目分工作区
标签/面板	`tab create/close` `pane split/zoom`	终端分割，跟 tmux 差不多
Agent 控制	`agent list/start/prompt/wait/attach`	直接操作 Agent，不只是终端
集成	`integration install/status`	管理各 Agent 的状态检测插件
API	`api snapshot/schema`	Socket API，可编程
配置	`config check/reset-keys`	配置校验
远程	`--remote ssh://...`	SSH 连远程 herdr 服务
更新	`update [--handoff]`	热更新，实验性不中断接续

看命令体系就能感觉到------这不是个简单的终端工具。

pane 是终端面板，agent 是面板里跑的 Agent，这俩是分开的概念。你可以直接给 Agent 发 prompt、等它到某个状态、甚至单独 attach 到一个 Agent 的终端。

tmux 里没有这个设计。tmux 只知道"面板里跑了个进程"，它不关心那是什么进程。

三、最独特的功能：Agent 状态可视化

如果只能说一个 herdr 跟别的工具不一样的地方，就是这个：它知道你的 Agent 在干嘛。

herdr 自动检测每个面板里 Agent 的状态，归成四种：

working --- 干活中
blocked --- 卡住了，等你输入
done --- 干完了
idle --- 闲着，等指令

然后侧边栏里把所有状态汇总------工作区级、标签级、面板级，层层往上滚。你扫一眼侧边栏，就知道哪个在忙、哪个卡了等你确认、哪个已经完事了。不用再一个个终端切进去看。

3.1 支持多少种 Agent？

这里得区分两个概念：自动检测 和深度集成。

官方文档说开箱自动检测 22 种 Agent CLI------就是说你在面板里跑这些 Agent，herdr 能识别出来并显示状态。

我跑了 herdr integration status，列出来的是深度集成 （带生命周期 hooks/plugin，可以安装状态插件的），一共 18 种（其中 letta 为实验性）：

复制代码

pi, omp, claude, codex, copilot, devin, droid, kimi, opencode,
kilo, hermes, qodercli, qwen, cursor, mastracode, antigravity-cli,
grok, letta（实验性）

里面有几个国内用户眼熟的名字：Kimi Code、通义灵码（Qwen）、Devin。

这说明 herdr 不是只服务 Claude Code 的小圈子工具。它的定位是通用 Agent 运行时------不管你用哪家的，都能在它里面统一管。

3.2 状态检测怎么做的？准确率呢？

两层机制：

生命周期 hooks/plugin（权威状态）：Pi、OMP、Kimi Code、OpenCode 这些支持安装 herdr 的状态插件，Agent 在关键节点（开始思考、等待用户、完成任务）主动调用 hooks 上报状态。这是最准的，因为是 Agent 自己说的
Screen manifest 启发式检测（推断状态）：其他 Agent 靠分析终端底部缓冲区的内容，用 TOML 规则匹配来判断状态。准确率差点，但不用改 Agent 本身

关于准确率，得说实话：我没有实测数据。启发式检测的准确率取决于 Agent 的终端输出格式------输出格式越规范，检测越准；输出花里胡哨的，误报漏报都会多。

官方也没给准确率指标。这个东西，你用了才知道对你常用的那几个 Agent 准不准。

设计思路是务实的。有合作的走官方集成，状态最准；没合作的也能凑合用，不影响基本体验。

四、Socket API：Agent 间编排的基础设施

如果说状态可视化是给人省时间的，那 Socket API 就是多 Agent 编排的基础。

herdr 提供本地 Socket API，Agent 可以通过它：

开新面板
给另一个面板的 Agent 发 prompt
等某个 Agent 到达 blocked/done 状态
读取面板输出
管理工作区、标签

Agent 之间可以互相编排。

举几个可行的场景：

主 Agent 开三个面板，让三个 Agent 同时写三个模块，最后自己汇总
写代码的 Agent 写完后，自动开个测试 Agent 跑单测，不通过就打回去
批量处理一百个文件，开五个 Agent 并行，哪个闲了分下一个

这些用普通终端也能做------但你得自己写脚本管进程、解析输出、判断状态。herdr 把这些做成了标准化的 API。

这才是 "agent runtime" 真正的意思：它不只是让 Agent 跑得方便，它让 Agent 之间能协作。

4.1 安全隐忧：本地 Socket 谁都能连吗？

说到 API，就不能不提安全------这也是这个系列一直在关注的问题。

herdr 的 Socket API 跑在本地 Unix Domain Socket（Windows 上是命名管道）上。这里有几个安全问题值得注意：

第一，本地权限边界。 Unix Socket 的权限取决于文件权限。如果 socket 文件权限设得太松（比如所有人可读写），那同一台机器上的任何进程都能调用 herdr 的 API------包括开面板、发命令、读输出。这意味着一个被攻破的普通进程，有可能通过 herdr API 控制你所有的 Agent。

实际权限配置怎么样？我没深入验证。注意一点：Windows 上的传输层是命名管道 ，寻址方式是 \\.\pipe\<名字>，其访问控制由管道 ACL 决定，而不是普通文件权限------herdr status 显示出的 C:\Users\lenovo\AppData\Roaming\herdr\herdr.sock 更像给跨平台代码用的信息标签。这个点值得后续关注。

第二，Agent 间的权限隔离。 如果面板 A 里的 Agent 能通过 Socket API 控制面板 B 里的 Agent，那 A 面板被攻破 = 所有 Agent 都被攻破。这是个横向移动的风险。

herdr 有没有 API 鉴权机制？目前从文档和命令里没看到。可能默认就是"本地同用户 = 可信"。对个人开发来说问题不大，但如果是多人共用的开发机、或者企业环境，这就是个必须考虑的安全点。

第三，远程模式的安全。 herdr --remote 走 SSH 连接远程 herdr 服务。SSH 本身是安全的，但远程 herdr 的 Socket API 暴露面有多大？有没有额外的鉴权层？这些都还不清楚。

总结一下：对个人开发者，herdr 的安全风险跟 tmux 差不多------本地用户级别的隔离。但如果往企业级走，API 鉴权和多租户隔离是绕不开的问题。

五、从架构角度看 herdr 的位置

回到系列主题：Agent 架构演进。herdr 在整个图谱里算哪一层？

5.1 新层级：Harness 运行时

前三篇讲了决策层、安全层、技能层。herdr 代表的是一个新东西------Harness 运行时层。

复制代码

┌─────────────────────────────────────┐
│         决策层（Reasoning）          │  ← laya-mlx
├─────────────────────────────────────┤
│         技能层（Skills）             │  ← ECC / MCP Tools
├─────────────────────────────────────┤
│    ★  Harness 运行时层（Runtime） ★  │  ← herdr
├─────────────────────────────────────┤
│         基础设施层（Infra）           │
└─────────────────────────────────────┘
  ── 安全层（Security）是跨层的 ──→     MCP 鉴权 / ECC 签名 / API 鉴权

说明：安全层不是一个独立的下层，而是跨所有层的横切关注点------决策层有对齐安全、技能层有签名验证、运行时有 API 鉴权、基础设施有网络安全。之前的架构图画得不够准确，这里纠正一下。

运行时层解决的问题是：Agent 以什么形态存在、怎么被管理、怎么互相发现和协作。

在 herdr 之前，Agent 就是个终端进程------你敲命令它就跑，关终端它就没。没有"运行时"的概念。

herdr 把 Agent 提升成了运行时里的一等实体：有状态、有生命周期、有 API、可以被编排。

5.2 跟 MCP 是什么关系？互补，不是竞争

很多人会问：MCP 不也是 Agent 的标准吗？herdr 跟 MCP 是什么关系？

答案是：完全不冲突，是互补关系。

维度	MCP	herdr
解决的问题	Agent 怎么调用工具	Agent 怎么被管理、怎么协作
层级	技能层 / 工具层	Harness 运行时层
交互方向	Agent ↔ 工具（垂直）	Agent ↔ Agent（水平）
标准性质	工具调用协议	运行时 API

打个比方：MCP 是 USB 协议------规定了设备（工具）怎么跟主机（Agent）通信。herdr 是主板------上面有多个 PCIe 插槽，每个插槽插一块卡（一个 Agent Harness），主板负责供电、散热、插槽间通信。

你可以在 herdr 的每个面板里跑支持 MCP 的 Agent，MCP 管每个 Agent 内部的工具调用，herdr 管 Agent 之间的编排。两者是不同层面的东西。

甚至可以设想：将来 herdr 本身提供 MCP Server，让 Agent 通过 MCP 协议来调用 herdr 的运行时能力（开面板、查状态、等其他 Agent）。那就是标准套标准了。

5.3 跟其他 Harness 是什么关系？

你可能会问：Claude Code 本身不就是 Harness 吗？Cursor 不也是吗？herdr 跟它们抢饭碗？

不是竞争，是嵌套。

复制代码

herdr（运行时层）
  ├── 面板1: Claude Code（单 Agent Harness）
  ├── 面板2: Codex CLI（单 Agent Harness）
  └── 面板3: Kimi Code（单 Agent Harness）

Claude Code、Cursor 这些是"单 Agent Harness"------管一个 Agent 的生命周期、工具调用、对话管理。

herdr 是"多 Agent 运行时"------管一堆 Harness，让它们并排跑、能被看到状态、能互相协作。

有点像 Docker 和进程的关系。进程自己就能跑，但 Docker 给了它统一的运行环境、生命周期管理、网络隔离、编排能力。

5.4 为什么是现在火？

herdr 这个项目什么时候出来的，我没找到确切的首发时间------GitHub 上最早的 commits 大概是 2025 年中左右，但真正火起来是 2026 年。几个时间点：

2026-07：许可证从 AGPL 改成 Apache 2.0
2026-08：宣布加入 YC F26，当时 25k stars
2026-09：拿到 600 万美元种子轮，现在 40k+ stars

为什么 2026 年突然火了？我觉得核心原因是：多 Agent 正在从玩具变成刚需。

一年前，你可能一个 Claude Code 就够了。

现在，你可能同时用 Claude Code 写代码、用 Codex 调试、用 Kimi 处理中文文档。

再过半年，一个项目里同时跑七八个 Agent，可能是常态。

Agent 数量从 1 个变 5 个、10 个的时候，"怎么管"就从 nice-to-have 变成了必须解决的问题。

herdr 踩中了这个点。

六、三个视角

6.1 架构：Agent 基础设施的补全

herdr 填了个空白：Agent 运行时标准。

Web 开发有 Tomcat、Nginx；容器时代有 Docker、K8s。这些基础设施不直接产生业务价值，但没有它们上层应用跑不起来。

Agent 领域目前缺的就是这个。每个 Agent CLI 各自为政，没有统一的运行时标准。herdr 有可能成为这个标准------就像 Docker 当年成为容器运行时标准一样。

关键在 Socket API。如果它成了事实标准，上层的编排工具、监控工具、协作工具都能基于它构建，生态就起来了。

但也要看到：运行时标准的建立，从来不是技术最优者赢，而是生态最大者赢。Docker 不是技术上最好的容器运行时，但它是第一个做出生态的。herdr 能不能成，不取决于它技术多牛，取决于有多少 Agent 适配它、有多少工具基于它建。

6.2 工程：效率提升有多少？

工程最关心：这东西能让团队快多少？值不值得推？

我的判断：

单 Agent 用户：提升有限。只用一个 Claude Code 的话，herdr 就是个更好用的终端，tmux 也能凑合用
多 Agent 用户：提升明显。3 个以上 Agent 并行时，状态可视化加会话持久化能省不少来回切的时间
远程开发团队：提升最大。SSH 到开发机，herdr 里跑 Agent，断网不丢状态------tmux 也能做，但加上 Agent 状态管理，体验上一个档次

投入成本很低。学习成本跟 tmux 差不多（甚至更低，因为沿用了 tmux 的键位），装个二进制就能用，零配置启动。

但有个前提：你常用的 Agent 必须在支持列表里，而且状态检测得准。如果你主要用的 Agent 不在列表里、或者启发式检测经常误报，那体验会打折扣。

6.3 产品：商业模式和护城河

怎么赚钱？护城河在哪？

herdr 刚拿了 600 万美元种子轮，进了 YC。从公开信息看，策略大概是：

核心运行时永久免费，Apache 2.0 协议 ------ 先做生态。改许可证就是为了消除企业采用的法律障碍
企业版功能收费 ------ 团队协作、集中管控、审计日志、SSO，这些是企业刚需，也是开源项目常见的商业化路径
插件市场 ------ herdr 官方就有插件市场（plugin marketplace），YC 资料提到上线首月即超过 500 个社区插件，官网目前显示 1,332 个。能不能在此基础上做成平台抽成，现在还不好说

护城河在哪？我觉得有两层：

第一层是生态护城河。18 种深度集成的 Agent、开发者习惯了它的工作流、上层工具基于它的 API 构建------切换成本就高了。这跟 Docker 的生态护城河是一个逻辑。

第二层是网络效应护城河。用的人越多，适配的 Agent 就越多；适配的 Agent 越多，用的人就越多------正向循环。如果这个飞轮转起来了，后来者很难追。

但风险也明摆着。 为什么说这是个赢家通吃的市场？因为运行时标准有强网络效应------大家都用 A，你用 B 就意味着没有生态。操作系统、容器运行时、编程语言，都是这个逻辑。

但赢家通吃也意味着：如果有更大的玩家下场，herdr 可能直接被碾压。比如 Anthropic 官方出个 Claude Runtime、或者 OpenAI 把 Codex CLI 升级成多 Agent 运行时------它们有原生 Agent 的优势，herdr 作为第三方工具，压力会很大。

这也是为什么 herdr 要尽快做生态、尽快拿融资抢时间窗口------窗口期可能就一年。

七、说点冷静的

夸了这么多，泼点冷水。

7.1 这不就是 tmux 加了个 Agent 状态显示？

说实话，核心功能上，是的。

tmux 能做的终端多路复用、会话持久化、远程连接，herdr 都能做。多出来的就是 Agent 状态检测和 Socket API。

那值不值得专门搞个工具？

看你有多少个 Agent。1 个的话真没必要。3 个以上并行开发的话，状态可视化的价值就出来了------不用一个个切面板检查进度。

Socket API 更是如此。普通用户可能一辈子用不上，但如果你在做多 Agent 编排，这就是基础设施。

顺带提一下 zellij------另一个 Rust 写的终端多路复用器，也支持插件系统。zellij 的定位是"给人用的更好的 tmux"，herdr 的定位是"给 Agent 用的运行时"。两者出发点不一样，虽然功能上有重叠。

7.2 Windows 体验到底行不行？

这是我实测最关心的问题。目前的结论：

安装没问题，解压即用
CLI 命令全正常
但必须带着 conpty 目录一起，不能只拷 herdr.exe
完整 TUI 交互体验我在非交互环境下测不了；从文档看，Windows 原生支持已是 Generally Available（文档页仍沿用 windows-beta 标注，个别能力存在平台差异）

总体比我预期的好。很多 Rust 写的 TUI 工具对 Windows 支持都很敷衍，herdr 专门做了 ConPTY 适配，态度是认真的。

但有一说一：ConPTY 是 Windows 10 1809 以后才有的功能，老系统用不了。而且跟 Unix PTY 比，ConPTY 有些功能限制（比如终端大小变更的处理），可能会有边缘 case 的问题。

7.3 AGPL 改 Apache 2.0，是不是想商业化了？

是，而且我觉得这是好事。

时间线很清楚：7 月改许可证，8 月宣布进 YC，9 月拿了 600 万美金融资。改许可证就是为商业化铺路------AGPL 对 SaaS 不友好：如果你修改了 herdr 并通过网络对外提供服务，AGPL 会要求你把修改后的源码以开源形式提供给使用者，对嵌入云服务的场景很麻烦。改成 Apache 2.0 后，企业集成没有这类强制义务。

对用户来说：

核心功能永久免费、开源 ✅
企业可以放心用，没有许可证地雷 ✅
将来高级功能可能要付费 ⚠️
项目有商业支撑，不容易死 ⚠️

我觉得这个交易划算。一个有资金支持的开源项目，比一个靠爱发电的，活得久的概率大得多。

八、哪些是我验证了的，哪些是推断的

老规矩，分开说。

8.1 我实际验证了的 ✅

herdr 0.9.1 在 Windows 上能跑，解压即用，CLI 正常
安装包结构：25.5MB 单二进制加 ConPTY 运行时
命令体系完整：八大类，几十个子命令
支持 18 种深度 Agent 集成（含实验性 letta）：herdr integration status 实跑出来的
配置系统完善：TOML，11 种内置主题，可自定义
Socket API 存在：herdr api snapshot、herdr api schema 命令可用
服务器/客户端架构：herdr status 显示 server 状态和 socket 路径

8.2 我根据资料判断的 ⚠️

TUI 交互体验：侧边栏效果、鼠标流畅度，需要实际用
状态检测准确率：特别是启发式检测的准确率，没有实测数据，不同 Agent 差异可能很大
会话持久化可靠性：关盖子、重启机器后恢复，要用一阵子才知道
Socket API 稳定性、完整性、安全性：实际开发过才清楚，目前只确认"有这个东西"
多 Agent 编排的实际效果：理论上很美，用起来顺不顺手、有没有坑，得真做项目才知道
长期维护和商业化走向：拿了融资是好事，但开源部分会不会边缘化、企业版功能会不会闭源，还得观察

8.3 明确的局限 ❌

国内访问 GitHub Releases 慢，得用镜像或手动下
文档只有英文，中文资料少
国产 Agent 适配不全------Kimi、Qwen 有了，但豆包、智谱清言等 CLI 可能还没
纯终端工具，非技术用户门槛高
API 安全机制不明确------本地 Socket 的权限边界、Agent 间的隔离，目前没有看到鉴权设计
还没到 1.0，API 和功能可能还会变

九、最后说句实在的

回到标题的问题：给 Agent 一个专属终端运行时，是不是伪需求？

我的答案：不是伪需求，但也不是所有人都需要。

只用一个 Agent、平时就在终端里跑的------herdr 对你就是更高级的 tmux，可用可不用
同时用好几个 Agent、或者经常在远程服务器上跑的------herdr 的价值很明确，值得试试
做多 Agent 编排、或者做 Agent 相关产品的------Socket API 可能是基础设施级别的东西，建议重点关注

从架构演进的角度看，herdr 代表了一个明确的方向：Agent 正在从"终端里的一个进程"，进化成"运行时里的一等实体"。

这个趋势刚起步。herdr 是第一个跑出来的，但不一定是最后一个。未来可能会有更重量级的 Agent 运行时出现------就像 Docker 之后有了 Kubernetes。

但至少今天，如果你想体验一下"Agent 运行时"到底是什么感觉，herdr 是最好的选择------没有之一。

系列导航：

第01篇：决策层独立------laya-mlx 开源决策模型深度评测
第02篇：MCP 安全层------五份独立研究揭示的系统性风险与防御路线
第03篇：技能层 + 安全层------ECC 实测
第04篇：Harness 运行时层------herdr，给 Agent 一个专属运行时 ← 你在这
下一篇预告：记忆层------Agent 的长期记忆到底该怎么存？