如果你几个月前安装过 Herdr，herdr 多半意味着侧栏、项目工作区，以及多个运行 Coding Agent 的终端 Pane。现在再打开官网，首页展示的却是一款建立在 herdr-core 之上的桌面 App。
最重要的区别是：Herdr TUI 拥有自己的 Server；herdr-core 是独立的终端 Runtime，通过 hc 控制，也是新桌面 App 的底层。 在其中一套环境启动的 Agent，不会出现在另一套中。Herdr 官方 FAQ 明确说明了这一点。调整现有远程工作流之前，应该先分清这条边界。
调研核验日期：2026 年 11 月 4 日。本文依据公开文档和 Release Notes 撰写，不包含本地性能实测。
Herdr TUI 与 herdr-core 快速对比
即使安装在同一台机器，两者也是独立的运行时：
| 问题 | Herdr TUI | herdr-core |
|---|---|---|
| 使用什么命令？ | herdr，原来的终端应用 |
hc，无界面 Runtime 的 CLI |
| 在哪里操作？ | 包含 Workspace、Tab、Pane 和 Agent 侧栏的 TUI | Shell、新 Herdr App，或调用 API 的 Client |
| 谁管理终端？ | TUI 自己的后台 Server | 独立的 Core Runtime |
| 如何获得 Agent 状态？ | 屏幕检测，以及 Agent／Integration 上报 | 程序通过 OSC 7501 上报 |
| 能否远程连接？ | SSH 到 Host 后 Attach TUI | 在 Host 上运行 hc，或使用 Core 的 SSH Machine 功能 |
| 两套环境共享运行中的 Agent 吗？ | 不共享 | 不共享 |
依据：Herdr TUI、TUI Agent Detection 和 Core 官方介绍。
本文比较的是哪些版本？
核验时，GitHub 上最新的 TUI 稳定版是 v0.9.5，发布于 2026 年 10 月 14 日。其中一个与使用体验有关的修复是：Codex 状态重新由屏幕检测提供，官方提示老用户重新安装 Codex Integration。因此，旧文章关于 Codex Turn Hook 的描述需要结合版本理解。
Core 的官方 Changelog 中，最新的带日期条目是 0.1.17，2026 年 11 月 2 日。它修复了 macOS 在没有后台运行许可时，退出 App 会停止 Agent 的问题，让 Core 与 App 分开运行；已经启动的 Agent 需要下次启动才会获得这项修复。这是 Core 的 Changelog 版本，不是 TUI 或桌面 App 的版本号。
排查问题时，先记录自己更新的是 TUI、Core，还是 App，再查看对应组件的说明。只说“我已经更新 Herdr”仍然可能指向三件不同的事。
从完整终端工作区，到可复用 Runtime
Herdr TUI 为人提供了一整套组织 Agent 工作的方式：选择 Workspace、安排 Pane、查看状态，再进入需要关注的终端。它的 Server 与界面围绕这套工作流共同设计，用户无需自己搭建界面，也不必考虑终端应该如何出现在 App 中。
Core 暴露的则是更底层的基础能力。API 文档分别介绍了终端请求、Attach Stream 与事件；hc schema 可以返回 OpenRPC 描述。桌面 App、编辑器面板或其他 Client 可以用不同方式组织这些能力，同时让终端继续在 Host 上执行。
这会改变评估重点。对 TUI，要看它的工作区与导航方式是否适合自己；对 Core，还要看所选 CLI 与 Client 能否把上下文清楚地呈现出来。后台 Runtime 的能力再完整，也不会自动带来项目侧栏、好用的手机键盘，或易读的对话视图。
这层拆分之下还有一个重要细节。Core 的安全与运行时文档说明，真正持有终端的是独立的 holder 进程。Core 管理进程更新或重启时，holder 可以继续保留程序。可以按以下层级理解：
| 层级 | Herdr TUI | herdr-core |
|---|---|---|
| 访问与呈现 | Attach 的 TUI Client | hc、桌面 App 或其他 API Client |
| 协调与管理 | TUI Server 及其工作区模型 | Core 的终端、机器、状态与事件 API |
| 实时终端归属 | Server 管理的 Pane 进程 | 保留终端的 holder 进程 |
因此，“窗口关闭”“管理进程重启”和“执行主机重启”不能当成同一种故障。之前的 Herdr 原理文章讨论的是原始 TUI，不能把其中的 Server 模型原封不动地套用到 Core。
独立 Runtime 意味着什么？
Client 是查看和控制工作的入口；Runtime 才是让工作持续存在的地方。两个界面能否看到同一批任务，取决于它们是否连接同一套 Runtime、操作同一批对象。
这里，从旧 TUI 切换到新桌面 App，并不会自动连接旧 Server。官方明确说明，两者的 Agent 是分开的。因此，新 App 中找不到一个 Agent，可能只是 Runtime 不同，并不意味着任务已经退出。
尝试另一套环境之前，先记住三个信息：
- Agent 实际运行在哪台机器？
- 它的终端最初由
herdr还是hc启动？ - 回来时，应该用哪个命令或 Client 重新连接？
让长任务继续留在原来的环境，用可随时结束的小任务测试另一套。真正迁移时，选择明确的暂停点，保留仓库状态，以及需要时由 Agent 自身提供的对话引用。不要假定两者存在共享 Session 列表或自动迁移机制。
Agent 状态：兼容性规则与主动上报
TUI 可以根据前台进程和终端画面识别受支持的 Agent，也可以采用 Integration 或 Agent 自己上报的状态。检测文档 同时说明了限制：没见过的审批界面可能被回退为 idle。侧栏能帮助分配注意力，但回复之前仍应看清真实 Prompt。
Core 选择了另一条路线：官方状态模型不猜测屏幕文字，而是使用 OSC 7501，也就是 Program Status Protocol。没有发送该协议的程序仍然可以运行，但放进 Core 并不会自动获得完整状态。
我们的理解是：TUI 可以通过持续维护检测规则来兼容 Agent；Core 则把状态报告变成程序与 Client 之间的显式接口。无论哪种方式，状态标签都不能代替对 Agent 请求的实际审查。
有意思的是，Superlogical 的 Rex 也公开了 OSC 7501 文档。使用相同的状态协议，并不意味着共享 Session、身份认证或 Client API。
Core 如何让 Agent 协作更明确？
在分屏中运行多个 Agent，只是并行工作的开始。接下来还要有人分配范围明确的任务，记住任务对应哪个终端，收集结果，并决定 Helper 应该何时结束。
Core 的 Agent 工作流为这些操作提供了明确入口：用 hc run 启动，用 hc send 补充指令，用 hc read 查看，用 hc wait 等待。在 hc 终端中启动的 Agent 会成为该终端的子级；子级需要关注或结束时，父级会收到提示。除非使用 --outlive-parent，子级默认随父级结束。
这种生命周期适合临时 Reviewer：Review 属于当前实现任务，也可以随它一起清理。开发服务器的预期则不同。如果希望分配任务的 Agent 退出后，服务仍然可用，就应明确安排它的生命周期，而不是把“后台运行”理解成永远独立存在。
Core 还提供 Agent Template：用 Markdown 文件组合已安装的命令与可复用角色说明。例如，Reviewer 角色预先约定检查方式和报告格式，每次只补充文件与任务范围。Template 方便启动 Agent，但其中的文字不会强制建立文件系统沙箱，也不会让程序自动获得状态协议支持。
启动成功之后，还要关注 Agent 是否真正准备好接收任务。Template 文档说明，默认会等待状态报告再发送开场指令；旧 Agent 或启动时的信任对话框，都可能影响这个过程。先读返回结果与真实终端，再决定是否重发，避免第二次输入落在错误的交互中。
实际使用时，可以先从一个实现 Agent 加一个 Reviewer 开始。给 Reviewer 明确的只读范围，保留人工 Review；如果 Helper 也要编辑代码，则安排独立工作目录。Runtime 可以协调终端，而并行修改最终如何合并，仍由 Git Branch、Worktree 和 Review 流程决定。
断线、更新和重启是三种不同情况
手机工作流最需要的保证很直接：离开 Client，不应该结束 Host 上的任务。两套方案都把终端生命周期与当前查看它的界面分开。
具体能保留什么，取决于停止的是哪一层：
- TUI：恢复文档分别介绍了实时 Detach、保存的 Layout，以及通过 Integration 恢复符合条件的 Agent 对话。恢复后的对话运行在新进程里。
- **Core：**在受支持的更新、重启路径中，只要 holder 仍然存活，就可以保留原程序。如果终端中的程序确实丢失，README说明，使用
--keep的终端会恢复成新的 Shell，不会重新执行旧任务。桌面 App FAQ也明确说，主机重启不会自动重启 Agent 或恢复其进行中的工作。
| 事件 | 应当怎样理解 |
|---|---|
| 手机 SSH 断开或查看端 Detach | Host 与 Runtime 仍存活时，重新连接已有终端 |
| TUI Server 停止 | 原 Pane 进程结束，之后重建 Layout 或恢复符合条件的对话 |
| 按受支持的路径更新 Core | holder 可以让原程序穿过管理进程重启继续运行 |
| Host 重启，或实际持有终端的进程丢失 | 原程序已经结束，需要采用对应方案的恢复路径 |
例如，重启后重新看到目录与终端，不代表执行到一半的数据库迁移或测试套件一直在后台继续。重新执行前，要检查命令自己的结果与 Checkpoint。恢复 Agent 对话，也不等于恢复它之前启动的每一个命令。
早期的 Console 评测可以帮助理解原始 TUI 的吸引力：持久 Agent Session 和 SSH 访问。它早于 Core 拆分。评测中关于 Live Handoff 的提醒，应结合当前 TUI 恢复文档阅读；后者仍将这项能力标为实验性、主动开启。
实际部署原则没有变化：将持续任务放在保持唤醒的机器上。手机断开没关系；执行任务的 Host 休眠，构建也无法继续。
根据实际 Runtime 选择命令
按照 TUI 安装文档，在开发主机安装原来的终端应用：
curl -fsSL https://herdr.dev/install.sh | sh
cd ~/projects/your-app
herdr
进入 Pane 后启动平常使用的 Agent。按 Ctrl+B 再按 q Detach；之后重新连接同一 Host，再执行 herdr。
如果要单独尝试 Core，官方 README给出的安装地址与命令体系如下：
curl -fsSL https://releases.herdr.dev/core/install.sh | sh
cd ~/projects/your-app
hc run --bg --name review codex
hc ls
hc read review --lines 60
hc attach review
这组示例从普通 Host Shell 执行。Attach 后用 Ctrl+\ Detach。只安装 Core 不会获得桌面界面，而执行 herdr 也不会连接到这里的 review。
连接一台 Host，还是管理多台机器？
访问远程 Core 工作有两条实用路径：直接 SSH 到执行主机，使用当地的 hc；或者在另一台机器的 Core 中注册这台 Host。后一种方式由本地 Core 汇总终端列表，而远程 Core 继续把程序与文件保留在远程主机。
在目标机器已安装 Core、SSH 已经连通的前提下，Machine 指南给出了这样的流程：
hc machine add you@development-host --name workbox
hc machine ls
hc run --bg --on workbox --cwd /srv/app --name tests npm test
hc read workbox/tests --lines 80
hc attach workbox/tests
把 /srv/app 改成真实的远程仓库目录，并使用命令实际返回的地址。同名项目分布在多台机器时，显式目录尤其有用。与 workbox 的连接断开，不会把任务搬回笔记本，也不会让远程 Host 停止执行。
对同时管理笔记本、工作站和服务器的人，这提供了一个发现远程工作的共同入口；只想从手机短暂访问一台机器时，直接 SSH 仍然可能更省步骤。无论选哪条路径，代码、凭据和构建工具都需要准备在真正执行任务的地方。
准备开发 Client 时，也要理解权限模型。Core API 使用 Host 账号已有的命令与文件权限；独立 Core Session 用于组织状态，并不隔离权限。使用文档提供的本地或 SSH 访问路径，Agent Template 中的角色说明也不等于独立的操作系统账号。
一个 Core Client 实际需要完成哪些事？
开放 API 让另一种界面成为可能，但不同界面的能力不会自动相同。协议文档区分了请求／响应调用、实时终端 Stream 与事件通知。只列出终端名称的 Client，与能正确 Attach、转发输入、处理 Resize 并保持画面同步的 Client，承担的工作量差别很大。
这种差别在手机上尤其明显。旋转屏幕会改变终端宽度；从后台返回时，需要重新取得当前状态；状态变化还必须指向正确机器上的正确终端，而不是一个名字相似的任务。触屏控件与审慎的输入处理，都属于 Runtime 之上的 Client 工作。
这也解释了，终端 API 不会自动变成结构化对话 API。终端输出包含渲染与交互细节；要把 Agent 消息呈现成干净的 Chat，还需要理解对应的对话数据。评估集成时，应分别考虑 Runtime 控制、终端渲染与对话呈现。
Core 当前仍将 API 标为 Preview。文档中的兼容性规则对 Client 开发者很有价值，但实际集成仍应读取运行中 Server 的 Schema，并针对支持的版本检查重连、输入与 Resize 行为。
已有 TUI 用户如何逐步尝试？
不必迁移所有项目，才能判断 Core 有没有价值。分阶段比较，更容易得到明确结论：
- 记录现有 TUI 配置。 记下 Host、仓库路径、Workspace 名称、Agent 版本与 Integration，并保留能进入旧 Server 的入口。
- 选择一个小任务。 聚焦 Review 或可随时结束的测试任务，比已经积累大量上下文的长任务更容易评估。
- 走完整的返回路径。 启动、Detach，再从另一终端或手机重新连接，通过实际返回的地址找到任务。
- 用真实 Agent 检查状态。 看见终端和收到 OSC 7501 状态是两件事；分别观察任务完成与确实需要输入的情况。
- 检查周边工作流。 能否找到 Diff、读取测试结果、确认仓库，以及理解 Helper 如何结束？这些步骤决定新环境是否省时。
- 在明确暂停点迁移实际任务。 需要时保留 Agent 原生对话引用，再有意识地在新 Runtime 中启动。新路径用顺之前，保留旧 Workspace。
这样，选择依据就从“哪个项目更新”变成了“自己究竟在哪里遇到摩擦”。已经熟悉 TUI 的开发者，可能更需要快捷的项目入口；准备开发自定义界面、跨机器委派任务的人，则可能更看重 Core 明确暴露的 Runtime 能力。
在手机上分别访问它们
网络通路与 Runtime 选择是两个问题。先通过 SSH 连接拥有该终端的机器，再执行对应的 Attach 命令：
ssh you@development-host
# 进入已有的 TUI Workspace：
herdr
# 或者，连接已经在 Core 中启动的终端：
hc ls
hc attach review
Host 继续管理终端进程，手机负责访问：
Redock 已有文档中的 Herdr 会话保持选项、工作区面板与 Pane 切换，指的是 TUI 集成，具体操作见在 Redock 中深入使用 Herdr。不要默认这些原生控件也能操作 Core 的另一套对象和 API。
你可以通过普通 Redock SSH 终端运行 Host 上的 hc 命令。这是终端访问能力，不代表已经提供原生 Core 集成。Project 保留 Host 与仓库上下文，Action 可以承担周边的 Git、测试和构建检查。需要从外网访问开发机时，可以先参考 Tailscale 指南。
一次有价值的手机 Check-in，可以先明确目标再进入终端。要回答 Blocked Agent，就直达对应 Runtime，阅读真实 Prompt；要确认构建，就查看命名的测试终端或保存的 Action 结果；要 Review 修改，就从 Project 的仓库上下文进入并查看 Diff。
这样既能缩短手机操作时间，也能为稍后的 Review 保留上下文。持久化回答的是“工作还在不在”；Host、项目入口和 Client 控件回答的是“能不能迅速回到正确的工作”。舒服的手机编程流程需要两者一起成立。
FAQ
herdr-core 是 Herdr TUI 改名吗？
不是。两者是拥有独立 Server 的不同程序。原来的终端界面继续作为 Herdr TUI 提供，Core 则驱动新的桌面 App，并提供 hc CLI。
TUI 中的 Agent 会出现在新 Herdr App 吗？
不会。官方 FAQ 明确说两者不共享 Agent。先确认终端是由哪套 Runtime 启动，再选择对应 Client。
已有 Redock 配置应该选哪一个？
如果依赖已文档化的 Herdr 工作区控件，继续使用 TUI 路径。需要 Core API 或新桌面 App 时，再单独评估 Core。普通 SSH 可以访问两者各自在 Host 上的 CLI。
重启之后，重新连接就会恢复任务吗？
连接仍然存活的终端，与主机重启后的恢复不同。Core 可以在受支持的更新路径中通过 holder 保留原程序，但主机重启会丢失旧进程。TUI 可以恢复符合条件的 Agent 对话；Core 文档中的恢复则让保留的终端进入新 Shell，不会重新执行旧任务。