从一个 WebSocket 到四个组件:多端操控 AI Coding CLI 的架构演化
从一个 WebSocket 到四个组件:多端操控 AI Coding CLI 的架构演化 手机远程操控电脑上的 AI Coding CLI,直觉上只需一个 WebSocket。CLI 在电脑上跑着,手机连上去,发消息,收输出,结束。 Kimi CLI 的 Web UI 做到了这一步。执行 kimi web,本地起一个 HTTP + WebSocket 服务,浏览器打开就能用。底层 Wire 协议(JSON-RPC 2.0)支持多个 WebSocket 客户端同时接入,消息通过 BroadcastQueue 广播给所有订阅者。手机套个 WebView 就行了? 但 Happy 项目把同样的需求拆成了四个独立组件:CLI、Daemon、Server、App。四个进程,三种 Socket 连接类型,一套 RPC 转发机制,外加端到端加密(E2EE)。 为什么? 这篇文章用两个真实项目的源码回答。从最简的直连方案开始,每遇到一个绕不过去的约束就加一个组件。四层方案逐层淘汰,最终会发现:四组件不是过度设计,而是五个硬约束逐层叠加的必然结果。 读完后能得到: 每个组件存在的「不可替代的理由」,以及没有它会怎样 Happy 和 Kimi CLI 在消息路由、进程管理、控制权协调上的关键设计细节 一棵决策树,根据自己的场景判断需要几个组件、哪些可以省 现有 Wire 协议哪些能复用、哪些必须新增的分层分析 阅读路线: 只想知道为什么不是一个 WebSocket → 第 1 节 + 小结 想理解 Happy 的核心机制 → 第 4 节(scope / RPC / 租约 / E2EE)+ 第 5 节(Daemon) 想设计自己的远程操控系统 → 第 6.3 节(五维度扫描)+ 小结决策树 想做协议复用 / 迁移评估 → 第 7 节 1. 五个硬约束 拆解方案之前,先定义检验标准。「手机远程操控电脑上的 AI Coding CLI」拆成五个约束: ...
