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 用 ConPTYWindows 原生伪终端不是模拟终端全屏 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/closepane split/zoom终端分割跟 tmux 差不多Agent 控制agent list/start/prompt/wait/attach直接操作 Agent不只是终端集成integration install/status管理各 Agent 的状态检测插件APIapi snapshot/schemaSocket 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——就是说你在面板里跑这些 Agentherdr 能识别出来并显示状态。我跑了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 APIAgent 间编排的基础设施如果说状态可视化是给人省时间的那 Socket API 就是多 Agent 编排的基础。herdr 提供本地 Socket APIAgent 可以通过它开新面板给另一个面板的 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 SocketWindows 上是命名管道上。这里有几个安全问题值得注意第一本地权限边界。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 是什么关系答案是完全不冲突是互补关系。维度MCPherdr解决的问题Agent 怎么调用工具Agent 怎么被管理、怎么协作层级技能层 / 工具层Harness 运行时层交互方向Agent ↔ 工具垂直Agent ↔ Agent水平标准性质工具调用协议运行时 API打个比方MCP 是 USB 协议——规定了设备工具怎么跟主机Agent通信。herdr 是主板——上面有多个 PCIe 插槽每个插槽插一块卡一个 Agent Harness主板负责供电、散热、插槽间通信。你可以在 herdr 的每个面板里跑支持 MCP 的 AgentMCP 管每个 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 HarnessClaude Code、Cursor 这些是单 Agent Harness——管一个 Agent 的生命周期、工具调用、对话管理。herdr 是多 Agent 运行时——管一堆 Harness让它们并排跑、能被看到状态、能互相协作。有点像 Docker 和进程的关系。进程自己就能跑但 Docker 给了它统一的运行环境、生命周期管理、网络隔离、编排能力。5.4 为什么是现在火herdr 这个项目什么时候出来的我没找到确切的首发时间——GitHub 上最早的 commits 大概是 2025 年中左右但真正火起来是 2026 年。几个时间点2026-07许可证从 AGPL 改成 Apache 2.02026-08宣布加入 YC F26当时 25k stars2026-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 marketplaceYC 资料提到上线首月即超过 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 的定位是给人用的更好的 tmuxherdr 的定位是给 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 月宣布进 YC9 月拿了 600 万美金融资。改许可证就是为商业化铺路——AGPL 对 SaaS 不友好如果你修改了 herdr 并通过网络对外提供服务AGPL 会要求你把修改后的源码以开源形式提供给使用者对嵌入云服务的场景很麻烦。改成 Apache 2.0 后企业集成没有这类强制义务。对用户来说核心功能永久免费、开源 ✅企业可以放心用没有许可证地雷 ✅将来高级功能可能要付费 ⚠️项目有商业支撑不容易死 ⚠️我觉得这个交易划算。一个有资金支持的开源项目比一个靠爱发电的活得久的概率大得多。八、哪些是我验证了的哪些是推断的老规矩分开说。8.1 我实际验证了的 ✅herdr 0.9.1 在 Windows 上能跑解压即用CLI 正常安装包结构25.5MB 单二进制加 ConPTY 运行时命令体系完整八大类几十个子命令支持 18 种深度 Agent 集成含实验性 lettaherdr integration status实跑出来的配置系统完善TOML11 种内置主题可自定义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.0API 和功能可能还会变九、最后说句实在的回到标题的问题给 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 的长期记忆到底该怎么存