Redock vs Happy

Happy 与 Redock 解决同一个现代问题：Coding Agent 可以工作很久，却可能在五分钟后因为权限、问题或错误停住。两款产品都允许开发者离开桌面而不放弃循环，也都能在手机上显示 Session、接受响应并让工作继续。

Happy 通过 Agent Companion 解决。电脑上的 CLI 与 Agent 一起运行，加密 Session 更新，再通过 Relay 同步到手机或 Web。移动端呈现 Agent 对话，而不是通用终端。这个聚焦让配置很快，内容也更易读。

Redock 从终端一侧解决。它通过 SSH 或 Mosh 直连开发机，把 Agent 当作普通 Shell 与持久 tmux Session 中的程序。Project、Action、Run、Activity 和暂存输入增加结构，但只要 Agent 不够用，底层终端始终存在。

Happy 最强的理由是简单。安装 CLI、配对设备，Agent Session 就能在 iOS、Android 或 Web 上阅读。不需要建立 SSH Host、不需要导入私钥，也不需要学习终端布局。对于唯一需求是“需要我时提醒，并让我回答”的人，这是最短路径。

产品开源，并围绕端到端加密设计。Session 数据在电脑上加密，Relay 只存储或传输 Ciphertext，配对手机在本地解密。默认 Hosted Relay 很方便，自托管又让用户控制中间层。对于会接触敏感 Prompt 和代码上下文的工具，这是很有原则的模型。

Happy 的对话 UI 在手机上往往比终端 TUI 更易读。Markdown、Code Block、Diff、Question 与 Approval 可以呈现为移动界面元素。Parallel Session、通知、语音和桌面到手机的交接，都强化了“Agent 对话就是完整工作”这一观点。

Happy 有意不做通用终端，因此界面更干净，但也形成边界。Agent 完成后，如果你要 tail Log、检查 Process、运行 psql、打开 lazygit、重启服务、用 Vim 改文件或 SSH 到另一台机器，就需要另一条终端路径。

Redock 把这条路径留在同一工作区。Agent 运行在 Shell 内，因此开发者可以中断它、执行普通命令、使用 TUI、检查 Host，然后回到 Agent。命名 Action 可以表示测试、构建、Lint、迁移检查或部署，不必把每个确定性操作都写成新的自然语言 Prompt。

当 Agent 真的覆盖一切时，这种差异不重要；当输出必须由 Agent 没有主动选择的工具验证时，它会更关键。Redock 的终端基础提供手动兜底和确定性命令入口；Happy 优化的是“对话已经足够”的更干净场景。

Happy 的连续性存在于 Happy Session 内。Companion CLI 维持与 Coding Agent 的关系，加密更新经过 Relay，配对客户端再追上状态。这使桌面到手机的 Handoff 很顺滑，也能让暂时离线的手机恢复历史。

Redock 的连续性存在于标准终端基础设施。Agent 在开发 Host 的 tmux 中运行，笔记本终端与 Redock 可以 Attach 同一 Session，看到相同 Process、Pane、Scrollback、工作目录和终端状态。Mosh 改善移动网络，tmux 保证所有客户端离开时工作仍存活。

区别在于 Live Session 的归属。Happy 拥有 Companion Session，因此可以把 Chat 呈现得很好；Redock 依赖任何兼容终端都能重连的标准 Host Multiplexer。前者适合无缝 Agent Client Handoff，后者适合与普通终端工具互操作。

Happy 的 Hosted Relay 位于网络路径中，但设计目标是看不到明文。电脑与配对设备持有 Key，服务只处理加密 Blob；不想使用 Hosted Service 的用户还可以自托管 Server。按文档实现时，这种模型兼顾连接便利与内容隐私。

Redock 通过 SSH 或 Mosh 直接连接用户开发 Host，终端数据路径不需要 Redock Session Relay。它更适合已经通过公网入口、VPN、Tailscale 或其他私网拥有 SSH 能力，并希望移动客户端像标准终端一样工作的开发者。

任何架构都不会在所有部署里自动更安全。Happy 减少 SSH 配置，并提供应用级 E2EE，但多了 Companion Process 与 Relay；Redock 使用成熟 Remote Shell 基础设施，但用户必须正确保护网络可达性、Key、Host Verification 与服务器配置。应该根据现有 Threat Model 和运维习惯选择。

Happy 的主要单位是 Conversation。Redock 的主要单位是 Project，它组合 Host、仓库目录、活跃终端 Session 和该代码库的重复命令。因此 Redock 对 Prompt 前后发生的工作更有主张。

Developer Action 很重要，因为不是每项任务都应该委托 Agent。运行标准测试、检查格式、构建预览或部署已知环境，通常更适合精确命令。Redock 可以把命令显示为命名控制，并保存 Run 输出，避免要求 Agent 再现一个确定性流程。

两款产品都支持语音交互，但体验跟随架构。Happy 可以提供与 Agent 的会话式语音；Redock 把语音作为暂存需求：听写、检查、编辑，再发给当前终端 Agent。前者更像和远端协作者交谈，后者更像给 Project 中已经运行的工具编写精确指令。

当价格、开源、快速配对、Web 访问和聚焦 Agent 对话是优先级时，Happy 是诚实的胜者。它对用户要求很少，却能很好覆盖“中断—批准”循环。如果终端只会增加杂乱，就没有必要为更宽的工作台付费。

当 Agent 控制经常跨入普通开发操作时，Redock 更合适。重连 tmux、运行精确 Action、检查 Host、切换其他 Shell 工具或返回 Project Activity，能把完整循环留在一个地方。

部分开发者也可以两边使用：Happy 负责可读的跨平台 Agent Companion，Redock 负责同一台机器上的直接 SSH/Mosh。但两者瞄准的时刻非常接近，多数人应该先选择自己信任的架构与边界——只要对话，还是对话加终端。