Kaiwu 各组件如何协同运作
三大核心组件、套接字上实际传输的内容，以及在其前端配置代理时这意味着什么。
Kaiwu 由三部分组成，其形态源于实际工作的运行位置：在你的设备上，而非服务器上。
- CLI 及其守护进程运行在你掌控的计算机上。你的代码仓库与 Agent 凭据都在这里，编码 Agent 也在此实际执行。
- 中继负责存储加密有效负载以及路由所需的同步元数据。中继不运行 Agent，且在默认存储策略下无法读取其内容。
- 客户端包括移动端、网页端与桌面端，供你观察状态并进行操控。
会话通过中继实现同步，因此手机和笔记本电脑能看到完全一致的对话内容。这就是中继的全部职责：在你的各端设备与负责执行任务的设备之间传递密文。
Socket 中传输的内容
这一点比听上去更加关键，因为在自托管中继前配置反向代理时，人们最容易在这里踩坑。
双向 WebSocket 是主数据通路。 它并非只是用来通知客户端去通过 HTTP 获取内容的通知通道。
- 下行方向，
new-message承载了完整消息（{ id, seq, content, … }），而非仅仅是“有内容更新”的 ping 探测信号。 - 上行方向，客户端通过同一个 Socket 发起写入：
message、update-metadata与update-state均为客户端到服务器的事件。
写入操作采用乐观并发控制。带版本的字段——元数据、Agent 状态、产物分片、访问密钥、KV 等——都会携带 expectedVersion。若写入过期，系统不会静默覆盖，而是会返回带有当前版本的 version-mismatch。冲突解决逻辑交由客户端处理，这使得两台设备无需加锁即可协同处理同一个会话。
长连接 Socket 不擅长处理的场景则由 HTTP 接管：例如断连后的大批量数据补录，以及不属于消息流范畴的传输。
自托管：请根据长连接且通信频繁的 WebSocket 流量来配置反向代理的规格，而非仅按传统的请求/响应流量评估。自托管中最常见的故障，是空闲超时时间短于服务器自身的心跳间隔，导致设备被静默断连。环境变量中提供了具体的数值参考。
重新连接
客户端在设计上就考虑到了 Socket 断开与恢复机制：重新连接、拉取遗漏数据、执行确定性的状态对齐。休眠一整天的设备唤醒后，其最终状态应当与始终在线的设备保持一致。正因如此，消息依赖单调递增的 seq，而非到达先后来确定顺序。
加密机制的位置
数据内容在离开设备、到达中继之前便已完成加密，密钥由你的账户保管而非存放在服务器端。这一机制能提供哪些保障，以及在哪些存储策略下不适用，详见安全性与加密模型。