我把 coding agent 挪到常开机器上，手机随时指挥
上一篇剩下的问题
上一篇我把账号轮换搞定了：几个 claude 账号在撞五小时墙之前自己切到下一个，不用重登，session 也不掉。但那套东西还有个问题没解决，agent 还是跑在我笔记本上，我一合盖它就没了。账号会自己轮了，人还是得坐在电脑前看着。
我想要的用法大概是这样的：比如排队等编译的间隙，或者干脆躺在床上，掏出手机看一眼几个 agent 在干什么，给卡住的那个补一句话，顺手再派个新活，然后手机揣回兜里，它们接着跑。机器在云上常开，笔记本合不合盖跟它没关系。
要做到这个，得把三件事分开解决：session 在哪跑，agent 之间怎么通讯，手机怎么连进去。这三件事互不相干，我给每件各挑了一个工具。
三个工具各管一段
- herdr 管 session。你可以把它理解成懂 agent 的 tmux，一个 headless 的 server 托管所有 agent 的终端 pane，你关掉观察窗、断掉 SSH、退出手机，server 和里面的 agent 都照跑。detach / reattach 是它的看家本事，整套方案能一直开着，靠的就是它。
- hcom 管通讯。它让一堆各自独立的 agent 互相发消息（
@名字、@组），互相召唤，一起干活。用hcom claude/hcom codex把 agent 拉起来挂到总线上，外部脚本也能往总线里丢任务。就是一群平级 agent 在一个群里聊。 - Moshi 管手机。它是 iOS 原生的终端 app，连上那台常开机器以后，能看 pane、操作 pane，也能收推送。
这么一分，agent 全都常驻在那台常开机器上，笔记本和手机一样，只是连上去看和操作的客户端。长活直接派到常开机器上跑，笔记本想合盖就合盖。
三个开源件各管一段：herdr 管 session、hcom 管通讯、Moshi 管手机，全常驻在一台常开机器上，手机和笔记本只是连上去看的客户端。
先搞一台常开的机器
云上一台便宜的小 VM 就够了。我用的是一台 8 核的 Linux 机器，但说实话跑 agent 不怎么吃 CPU，要的是一直开着、网络稳。家里闲着的机器，树莓派往上的东西，也都行。要求就两条，一是一直开着，二是你能 SSH 进去。
机器上要装 agent 本体（claude、codex）和三件套（herdr、hcom、moshi-hook），再加上你平时用的工具链。三件套各自的 repo 里都有安装脚本，一行就装好。
具体搭起来就四步
第一步，把 herdr 做成常驻服务。整套方案能「合盖不掉」，靠的就是这一步。用 systemd 的用户级 service 把 herdr 的 server 拉起来，同时把 linger 打开，这样它就不依赖你的登录 session 了，退出登录也好，重启机器也好，它都能自己回来：
loginctl enable-linger "$USER" # 服务不依赖登录会话
systemctl --user enable --now herdr.service
service 本身就三行，ExecStart=%h/.local/bin/herdr server 加 Restart=on-failure。这一步我踩过一个坑，后面单独说。
第二步，让 hcom 把 agent 起在 herdr 里。装好 hcom 以后告诉它拿 herdr 当终端后端，这样 hcom claude 起的 agent 就会直接进 herdr 的 pane，由 server 托管：
hcom config terminal herdr
第三步，配对 Moshi。手机上装好 Moshi，在机器上跑一次 moshi-hook host setup 就配上了。配好以后，手机就能连进那台机器的 herdr session，所有 pane 都看得到。
第四步，验收。用手机连上去，开一个 pane，敲 hcom claude（或者直接 claude），派个活看它跑。手机上能开 pane、能跑 agent、能看着它干活，第一层就算通了。
SSH 和 mosh 的差别比想象的大
这段得说清楚，手机上用着卡不卡全看它。免费版的 Moshi 只走 SSH。SSH 走的是 TCP，没有本地回显，也没有预测渲染。你在手机上每滚一下、每敲一个键，都要先发到远端，等远端把整屏重画一遍，再把字节流传回来，走一个完整的往返。手机 wifi 再一抖、一丢包，TCP 就要重传，整条流都跟着卡住。所以滚起来一顿一顿的。
能让它顺起来的是 mosh 协议，要 Moshi Pro 才解锁。mosh 走 UDP，不怕丢包，也没有 TCP 那种队头阻塞，再加上它会在本地预测渲染，你一滚，本地马上就画出来，后台再慢慢和远端对账。mosh 当年就是为手机上开终端这种场景发明的。我实测过，手机到机器这条网络路径其实很干净，直连，几十毫秒。所以卡不怪网络，怪的是 SSH 这层传输没法预测。
手机终端为什么卡：SSH 每次操作都要发到远端、整屏重画、字节流传回，一个完整往返；mosh 走 UDP 加本地预测渲染，你一滚本地立刻画出来，所以顺。
所以如果你真打算拿手机当主控，mosh 那一档基本少不了，开了还顺带有原生的 herdr session 选择器和「贴图给 agent」。免费版拿来试整套流程能不能跑通就够了，跑通了再上 Pro。
撞用量墙之后自动续跑
到这里手机已经能看、能指挥了，但还差一块，就是撞了用量墙，也得不用我盯着就能接着跑。这就接回上一篇的账号轮换。
我在那台常开机器上放了三个 claude 账号，配了一条 fallback 链，最后一个账号留 30% 的余量当储备。然后又加了个小看门狗。claude 每次因为用量墙中断，都会触发一个 hook，落下一个标记文件。有个定时器每两分钟醒一次，读到标记就去查账号余量，如果账号管家还没切，它就切到还有余量的号，然后往卡住的那个 pane 里补一句「continue」，让它接着跑。实在续不上，就在群里 @ 我一声。
撞用量墙自动续跑的看门狗回路：agent 中断落一个标记文件，每两分钟醒一次的定时器读到标记就自动换号、往卡住的 pane 里补一句 continue。
串起来用是这样的。我在地铁上派了个重构任务，手机揣回兜里。它跑着跑着撞上五小时墙，底下账号自动轮到下一个，看门狗把任务续上，我全程没看手机。等下了地铁掏出手机一看，活已经往前走了一大截。
有一点要说，这个看门狗是我自己写的胶水，三件套里没有。而且 hcom 偏偏看不见用量墙，它那一堆 hook 里没有管这个的类型，所以发现撞墙得靠 claude 原生的中断 hook，hcom 在这里只当通知总线用。我原本以为 hcom 会把这块也包了，结果没有，只能自己补一段。搭这类系统，不少时间就花在这种地方。
几个前提，和踩过的坑
这台机器的权限是全放开的。agent 要无人值守地跑，就不能每一步都停下来等人批准，所以机器上的 claude 开的是 bypass 权限，codex 关了审批也关了沙箱。我敢这么干，是因为这台机器只干这一件事，用的是我个人的身份，网络也锁死了，只有我能连，只跑我的活。反过来，这种机器上千万别放工作凭据，也别让它碰生产系统。权限敢全放开，是因为这台机器物理上就够不着重要的东西。
detach 管不了重启。关手机 app、断 SSH、退出登录，agent 都还活着，herdr 就是干这个的。但要是 server 进程真重启了（崩溃，或者机器重启），内存里那些终端就没了，正在跑的 agent 也跟着死，server 回来的时候是空的。所有终端多路复用器都这样，tmux 也一样。所以长活得放在那台常开机器上跑，合盖对它没影响，要是放在笔记本上，哪天笔记本一重启，里面跑着的东西就全没了。
herdr 常驻的那个坑。herdr 的 server 可以管默认 session，也可以管一个具名 session。我一开始让 systemd 起的是具名 session，结果手机连上去一看是空的，因为我的 agent 全在默认 session 里，两边对不上。改成让 service 管默认 session 就好了。你要是手机连上去看到的是空的，先查这个。
别在非交互 SSH 里 spawn。用 ssh 机器 '一行命令' 这种非交互的方式让 hcom 起 agent，很容易卡在 launch_blocked，从交互式 session 或者手机上起就没事。因为一行式的 SSH 不加载你的 shell 配置，环境少了一截。
哪些验过了，哪些还没
撞墙自动续跑这套是我这两天才接上的。我拿一个假的中断信号试过，它会切号，会往 pane 里补话，续不上也会在群里 @ 我。但真撞上一次五小时墙会是什么样，我还没亲眼见过，这个得先说清楚。
「合盖不掉」倒是天天在验。晚上笔记本一合我就去睡了，第二天早上用手机连上去，昨晚派的活还在那台机器上跑着，或者已经跑完了在等我 review。
