先把问题钉死。过去三年，所有编程 Agent（Claude Code、Codex CLI、Copilot CLI、OpenHands）都跑在「人面前那个终端窗口」里。这带来一个隐性假设：Agent 的生命周期 = 终端窗口的生命周期。窗口关了，进程死了；电脑合盖了，进程死了；网络断了，Agent 拿不到模型响应，任务就卡在那。
老玩家会说：这不就是 tmux / screen / nohup 解决的问题吗？为什么还要专门做一个 Herdr？
答案分三层。
第一层，tmux 保存的是「终端字节流」，不是「任务语义」。tmux 让你 detach 之后终端窗口还在，但它不知道那个窗口里跑的是 Claude Code 还是 vim，也不知道这个 Agent 现在在改哪个文件、改到哪一步、下一步要调用哪个工具。当你 reattach 回去，看到的是一堆滚屏的日志——你得自己认出「哦这是我的重构任务，它卡在了第 47 行」。对单 Agent 单任务，这还凑合；对多 Agent 并行，这就是灾难。
第二层，Agent 进程需要的不只是「活着」，还需要「可观察、可干预、可交接」。一个真正的 Agent 运行时要回答：这个 Agent 现在在干嘛（跑测试 / 改代码 / 等模型响应）、它干了多久、产出了什么文件、要不要把它杀掉 / 重启 / 把它的上下文交给另一个 Agent。这些信息 tmux 都不知道，因为它只看到 shell 的 stdout，不理解 Agent 的状态机。
第三层，多 Agent 协作要求运行时理解「Agent 之间的关系」。当你同时跑三路 Claude Code——一路改前端、一路改后端、一路写测试——它们之间是有依赖关系的。运行时需要知道：前端 Agent 改的接口字段，后端 Agent 是不是对齐了？测试 Agent 跑的是不是最新的代码？这种「任务图」层面的感知，是 tmux 完全不具备的。
所以 Herdr 的定位是：不是「让终端窗口活得久一点」，而是「让 Agent 任务活得久一点，并且运行时知道任务在干嘛」。这是一个质的差别，不是量的差别。
Herdr 官方宣传的核心能力是「detach 后不停工」——关掉笔记本、人在地铁上、电脑合盖，Agent 还在后台继续跑。这句话听起来像 tmux 的老口号，但实现路径完全不同。
拆解一下，要做到这件事，运行时必须解决三个工程问题：
传统 CLI Agent 的进程是绑在你的终端 emulator 上的。你一合盖，macOS 给终端发 SIGHUP，进程收到信号就死了。要让进程在「人走了之后」继续跑，必须把 Agent 进程从控制终端（controlling terminal）里 detach 出来——让它成为一个真正的后台守护进程，不响应 SIGHUP，stdout/stderr 重定向到运行时自己管理的日志通道，而不是你的窗口。
这一层技术上不新鲜（nohup / systemd-run / launchd 都做得到），但 Herdr 把它做成了「Agent 原生」的——不是你手动 nohup 一个命令，而是运行时在启动 Agent 的那一刻就决定了它的生命周期不依附于你的终端。待验证：Herdr 具体用的是进程守护、容器还是虚拟机
这是更关键的一层。Claude Code 这类 Agent 的「状态」不只是 stdout 日志，它包括：当前对话上下文、已经读过哪些文件、已经做过哪些改动、正在调用哪个工具、工具返回了什么。这些状态大多在进程内存里。如果进程死了（哪怕是 OOM、是机器重启），你 detach 之后再 reattach 看到的是一个「失忆」的 Agent。
要做到真持久化，运行时必须让 Agent 的状态周期性落盘——对话上下文、文件改动、工具调用历史，都写到运行时管理的存储里。这样即使进程被重启，运行时也能从最近的快照恢复 Agent 的上下文，而不是从零开始。这一层是 tmux 完全没有的——tmux 重启之后，进程里跑的那个 shell 也是失忆的，它只是从「最近一个命令」重新开始，之前 cd 到哪个目录、环境变量是什么，都得重新来。
编程 Agent 是「一半在本地跑命令，一半在云上调模型」。网络一断，Agent 卡在等模型响应这一步。tmux 能让它不被 SIGHUP 杀掉，但网络恢复之后它能不能自动继续？这是 Herdr 这类运行时要处理的——模型调用的网络重试、超时退避、以及「网络断的时候 Agent 该干什么（暂停 / 把待调用的请求排队 / 给人发通知）」。待验证：Herdr 的网络弹性策略细节未在公开资料中完整披露
「放牧」范式最有意思的部分不是单 Agent 后台化，而是多 Agent 并行。一个开发者同时跑 3-5 路编程 Agent 已经是 2026 年 9 月的常见场景——但这些 Agent 之间怎么协作，是个开放问题。
Herdr 给出的答案不是「让 Agent 互相通信」（那是 OpenClaw / LangGraph 这类编排层的事），而是「运行时给 Agent 提供一个共享的任务棋盘」。
| 协作维度 | tmux 方案 | Herdr 这类运行时方案 |
|---|---|---|
| 进程生命周期 | 每个 Agent 一个 tmux window，detach 后进程还在 | 每个 Agent 一个运行时托管进程，detach 后状态快照落盘 |
| 状态可见性 | 人自己去每个 window 看 stdout | 运行时统一展示：哪个 Agent 在跑 / 哪个卡住 / 哪个完成 |
| Agent 间交接 | 人手动把 A 的产物拷贝给 B | 运行时知道 A 改了哪些文件，B 是否基于最新版本 |
| 资源配额 | 无——谁先抢着谁用 | 可配置每个 Agent 的 CPU / 内存 / 并发上限 |
| 失败恢复 | 人手动 reattach 重启 | 运行时自动从最近快照恢复，或通知人介入 |
这个表格想说明的是：Herdr 的差异化不在「让 Agent 跑得更久」，而在「让 N 个 Agent 同时跑的时候，人能管得过来」。当你跑 1 个 Agent，tmux 够用；跑 3 个，tmux 开始累；跑 5 个以上，tmux 就崩溃了——你根本记不住哪个 window 对应哪个任务，更别说它们之间的依赖关系。
运行时的价值就在这里：它把「终端窗口列表」升级成「任务看板」。人面对的不再是 5 个黑底白字的终端，而是 5 个有名字、有状态、有产物的任务卡片。这是「放牧」范式能成立的前提——你不可能放牧一群没有身份、没有状态、没有标记的羊。
把上面三层拆开之后，再回头看「放牧」这个词，会发现它其实描述的是一种时间结构的改变。
传统开发者工作流是同步式的：你坐在终端前，敲一个命令，Agent 开始干活，你盯着它跑，遇到报错你介入，改完你验收，再敲下一个命令。你的时间被 Agent 绑定——Agent 在跑，你也得在。这是 2024 年 Claude Code 刚出来时的典型形态。
「放牧」范式是异步式的：你早上到公司，给 Agent 派 5 个任务（重构模块 A、写模块 B 的单测、修模块 C 的 bug、升级依赖 D、跑一次全量测试），然后你去开早会。下午回来，5 个任务有 3 个完成了、1 个卡住了、1 个还在跑。你看一眼任务看板，验收完成的、介入卡住的、继续等在跑的。你的时间不再被 Agent 绑定——是 Agent 在等你的时间，不是你在等 Agent 的时间。
这个转变的深层含义是什么？
第一，开发者的角色从「驾驶员」变成「验收员」。以前你要盯着 Agent 每一步干什么，怕它跑偏；现在你只需要在任务派出前把需求写清楚、在任务完成后把产物验收到位。中间过程你不需要看。这要求两件事：任务描述要精确（不然 Agent 跑偏你也不知道），验收标准要可执行（不然回来一堆你不知道对不对的代码）。
第二，「派活」本身成为一种新的工程技能。能不能把一个大任务拆成 5 个可以并行的小任务、每个小任务的边界在哪、产物怎么交接——这是过去工程师很少专门训练的能力。以前拆任务是给人拆，现在是给 Agent 拆。给人拆任务要求理解人的能力边界，给 Agent 拆任务要求理解 Agent 的上下文窗口、工具能力、以及错误模式。这是一种新的技能树。
第三，「等待时间」被重新定义。以前 Agent 在跑的时候你刷手机、查邮件——这段时间是「被浪费的」，因为你既不能干别的正事（随时可能要介入），也不能放松（任务还在跑）。放牧范式把这段时间解放出来了——Agent 在后台跑，你去做真正需要人做的事（开会、写设计文档、和同事对齐）。这是生产力的真提升，不是「Agent 更快了」那种虚的提升。
到这里必须回答一个绕不开的问题：Herdr 和现有的这一圈工具，到底是什么关系？
| 工具 | 定位 | 解决的问题 | 与 Herdr 的关系 |
|---|---|---|---|
| Claude Code / Codex CLI / Copilot CLI | 单个编程 Agent 的交互界面 | 人在终端前用自然语言指挥一个 Agent 写代码 | Herdr 是它们的「运行时宿主」——Agent 跑在 Herdr 上面 |
| tmux / screen | 终端复用器 | 一个终端窗口里开多个 shell | Herdd 是 tmux 的「Agent 升级版」——理解任务语义而非终端字节 |
| OpenHands（原 OpenDevin） | 完整的 AI 软件工程师平台 | 从需求到部署的全流程自动化 | OpenHands 是「Agent 本身」，Herdr 是「Agent 跑的地方」 |
| OpenClaw | 个人 AI 助手的协作 / 分发层 | 跨渠道（微信 / Discord / 邮件）与用户交互、调度子任务 | OpenClaw 管「人怎么调度 Agent」，Herdr 管「Agent 怎么跑起来」——互补不冲突个人推断 |
这个对比的关键洞察是：工具栈在分层。2024-2025 年大家都在做「更聪明的 Agent」（Claude Code、Codex、OpenHands）；2026 年开始，大家开始补「Agent 跑起来需要的基础设施」——持久化运行时（Herdr）、协作编排（OpenClaw）、产物管理（各种 artifact store）。这是成熟软件生态的必然路径：先有应用，再有框架，再有运行时。
对开发者来说，这意味着什么？意味着不要把 Herdr 当成「另一个 Claude Code」去选——它不是替代 Claude Code 的，它是让 Claude Code 用起来更顺手的底层设施。类比一下：你不会在「nginx vs Apache」里选 nginx 然后就不写代码了——nginx 是让你的 Web 应用跑起来的基础设施。Herdr 之于 Claude Code，就是 nginx 之于一个 Node 应用。
Herdr 在 GitHub 上开源（herdrdev/herdr），9K 星，具体协议需到仓库确认。从公开资料看，它是一个可以本地部署的运行时——你在自己的机器上跑 Herdr 服务，然后 Claude Code / Codex 这类 CLI Agent 作为「客户端」接入。它不是 SaaS，不需要把代码上传到第三方服务器。待验证：是否有托管版/商业版
理论上 Herdr 应该是「兼容现有 CLI Agent」的——你不需要重写 Agent，只需要把 Agent 进程放到 Herdr 的运行时里跑。但具体的迁移成本（是否需要改启动命令、是否支持从旧的 tmux 会话导入）要看官方文档。待验证
这是一个真实问题。每个 Agent 进程本身不重（CLI 工具），但它们调用的模型 API 是远程的、文件 IO 是本地的、跑测试时的编译 / 单测进程是吃 CPU 的。Herdr 的价值之一就是统一管理资源配额——避免 5 个 Agent 同时跑全量测试把 CPU 打满。但具体的资源占用数据（每路 Agent 多少 CPU / 内存）公开资料里没有，需要实测。待验证
「放牧」的前提是你能把任务拆清楚。对新手来说，连「怎么给 Claude Code 派一个任务」都还在学习阶段，直接上「放牧 5 个 Agent」大概率会跑偏——5 个 Agent 都在干你没想清楚的事。建议路径：先用单 Agent 跑 2-4 周，熟悉 Claude Code / Codex 的能力边界和错误模式，再尝试同时跑 2 个 Agent，最后再上「放牧」。这不是工具的问题，是「任务分解能力」的问题。
这是两个不同层的东西。OpenClaw 管「人怎么给 Agent 派活」——你在微信里给 OpenClaw 发一句话，OpenClaw 调度子 Agent 去干。Herdr 管「Agent 在什么环境里跑」——OpenClaw 的子 Agent 可以跑在 Herdr 上面，也可以跑在普通终端上。两者互补：OpenClaw 是「调度层」，Herdr 是「运行时层」。具体到「该装哪个」：如果你只是想让 Claude Code 后台跑、 detach 不停工，装 Herdr；如果你想跨渠道（微信 / Discord）和 Agent 交互、让 Agent 定时干活，装 OpenClaw。理想态是两者一起用，但不是必须。个人推断，非官方定位
三点说明：① 本文基于公开资料（Herdr GitHub 仓库、官方文档、2026 年 9 月 AI 编程圈的公开讨论）撰写，未做本地实测部署——所有工程实现细节（状态快照频率、网络弹性策略、资源配额机制）均为基于「持久化运行时」这一定位的合理推断，文中已用「待验证」标签标注；② 文中涉及与 OpenClaw 的定位对比，是从「分层架构」角度的个人分析，不代表 OpenClaw 或 Herdr 官方立场；③ 「放牧」范式的描述基于 2026 年 9 月社区公开讨论的观察，不构成对任何具体团队工作方式的评价——是否采用这套范式取决于个人工作习惯和任务类型，不是「先进 vs 落后」的判断。