云端 Agent 内核：客户端只剩浏览器

形态：内核在云上，客户端只剩浏览器

要的不是「再写一个远程控制台」，而是把整条链路搬上去：内核、代码、执行环境都在云主机，电脑和手机退化成只读一个网页的客户端。

• 内核：hermes-agent v0.22.4，hermes serve :9119 提供 JSON-RPC + WebSocket，只绑 127.0.0.1，永不公网。
• 常驻：hermes gateway install 装成 systemd 服务，崩了自动重启；一个进程用 multiplex_profiles 服务全部 profile（coder / ops / research 各一套记忆与技能）。
• 客户端：电脑是 Desktop 的 remote gateway（本地 / 云 / SSH 并存的多连接注册表）；手机是响应式 dashboard，加到主屏即可用；社交端只做入口。

这里有一个明确的取舍：hermes 已经把内核、消息网关、dashboard、多实例注册做到了八成，不自研主控 App、不写自己的控制台——省下的时间放在整体设计与异常路径上，而不是重写一遍别人已经做对的部分。

多端控制：换设备不换环境

「上云」真正解决的不是远程登录，而是同一份工作状态可以在任何一块屏幕上继续：

场景	客户端	做什么
办公室	电脑 · Desktop remote gateway	重活：写方案、跑长任务、看日志、审 diff
通勤 / 排队	手机 · dashboard 加到主屏	看进度、批一条危险命令、让 Agent 继续下一步
出差 / 会议	平板 · 同一个 URL	当第二块控制屏，一边开会一边盯任务板
不想开控制台	飞书 / 微信 · 发一条消息	「把登录页的按钮改大一点」——改完回传 diff 与截图，回一句「可以」即完成

关键在于三件事同时成立：同一份会话（不是把仓库拷到另一台机器再同步）、同一套权限（设备进不了 tailnet 就什么都看不到）、同一份证据（改了什么、跑了什么检查、截图在哪，都在会话里）。

于是「拿手机发消息就能开发」不是一句口号：消息只是入口，真正的执行发生在云主机的内核里——它拿得到代码、跑得动测试、留得下记录，人只负责判断与验收。

为什么值得做：AGI 时代的中间态

模型能力每几个月翻一页，今天的「最佳工作流」明年大概率要重写。所以我没有去追一个「全自动」的终点，而是先把中间态做扎实：

• 人保留三件事：判断（要做什么）、授权（危险动作点确认）、验收（结果是否可接受）。
• Agent 承担三件事：执行、留痕、复述——每一步都能被观察、被中断、被接管。
• 系统保证两件事：任何一步可回退；模型全挂时仍有人能救（见下面的旁路指令层）。

这样当模型变强时，换掉的是执行者，不是整套体系；当模型出错时，损失被限制在一步之内。在 AGI 到来之前，能稳定接管的半自动，比不可控的全自动更有价值。

接入层：零入站端口

云主机的 443 不开，所有入口都是「设备进了 tailnet 才算数」：

通道	做法	为什么
Tailscale tailnet	设备级 ACL，tailscale serve 签 HTTPS 证书	不暴露 443，权限按设备发
Auth Gate	public_url 加 basic_auth，反代回环也照样鉴权	只要能被转发到，就必须再验一次
飞书 / Lark	WebSocket 长连接，无公网回调	审批卡片按钮 = 危险命令在手机上确认
微信	iLink bot 身份，long-poll，仅结果推送	群消息常不投递，只当通知通道
Hermes Desktop	直连云主机的 gateway	桌面端仍是重活的主场

社交平台能做的事有限，而且都是别人家的规则：改协议容易被封。所以分工固定为——主控端处理重型，社交端处理轻型。

控制面：只能有一个写者

多节点最先要回答的不是「怎么扩容」，而是「谁有权写」。这里的结论是单写：

• state.db 是 SQLite：两个节点同时写同一会话 = WAL 冲突、会话撕裂，hermes 会直接拒绝「另一个进程持有旧 WAL」。
• kanban.db 的调度器必须单所有者：多 dispatcher 会重复 spawn 同一个任务。
• 危险命令的审批是进程内状态：两个 master 各自弹审批，等于同一条命令批两次，或者一边批一边拒。

所以第二个节点不是「另一个 master」，而是主动 / 被动灾备：节点互呼走 API server :8642 + API_SERVER_KEY 单向授权，/v1/runs 幂等、可 steer、可 stop；谁死了由谁接管，而不是两边同时抢着干活。

旁路指令层：不经过大模型

最脆弱的一环是模型网关：它挂了，Agent 就没法思考，也就没法自救。于是把「救」这件事从模型里摘出来，写成脚本：

• watchdog.sh 以 cron 的 no-agent 模式每 5 分钟跑一次，只读 /api/status，异常才输出，正常零输出。
• 全程零 token，stdout 直接进飞书——模型全部不可用时照样送达。
• 自愈白名单只有两条：重启本机服务、导出死因。跨节点只通知，绝不下发任意命令。

配套的兜底是备份：hermes backup 定时快照到异地，冷恢复演练过一遍再谈双活。

供应商与调度

云主机上除了内核和消息平台，还接了一套二开的 magpie（本页之外的另一个项目：Magpie Plus），用来统一管理各个 agent 与各家大模型供应商：账号池、余额到期、路由都收在一个入口，内核只认一个 base_url。

下一步是把「调度」也写进这套东西：hermes 负责调度与验收、Claude Code 负责编码，再往下用子 agent 拆活省 token——重点是多轮次、长时程任务里每一步都能被观察和接管。

明确不做

• 自写 Flutter 主控 App：先有网页，够用再说。
• 各节点互为 master 全互信：写冲突不是靠信任解决的。
• 双活双写 state.db：会撕裂会话。
• 改微信 / 飞书的客户端协议：封号风险换不来收益。
• 给社交端开放终端与文件写入：手机上点错一下就是事故。

还在继续

• 执行面继续上云：现在代码还能留在本机（terminal: ssh），目标是把 terminal 也收进云主机的容器，隔离优先，客户端彻底只剩浏览器。
• 状态聚合：把各节点状态压成一张卡片，手机上打开就能看清「谁在跑、谁挂了、余额还能撑几天」。
• 网络硬化：Tailscale ACL 收紧到具体端口，public_url 的鉴权换成短时会话。
• 灾备演练：备份恢复走成固定剧本，而不是出事时现查文档。