一个好的 SSH 客户端当然有价值。它应该稳定连接、正确渲染终端、处理密钥，并尽量不打扰用户。SSH 仍然是很多远程开发工作流的基础。但在手机上使用 coding agent，会出现裸 SSH 客户端原本不负责的问题。
关键差异不是 SSH 是否重要。SSH 当然重要。真正的问题是：产品是否只停留在远程 Shell 访问，还是能帮助你完成开发循环，包括选择项目、启动 agent、发送 prompt、运行验证、保活任务、检查结果和稍后恢复。
Shell 连接不是完整工作流
打开终端后，它并不知道哪个仓库重要、哪个命令启动 agent、哪个测试命令可以安全运行、哪个 tmux session 属于当前任务。你需要手动重建这些上下文。
在电脑上这只是麻烦。在手机上，它会直接决定你是否愿意继续这次操作。
Agent 驱动开发中，经常需要反复恢复这些信息：
- 要连接哪台 Host。
- 当前仓库的工作目录。
- 启动 agent 的命令。
- 当前分支、测试命令、构建命令或日志命令。
- 哪个 tmux session 承载当前任务。
- 发送下一条指令前需要阅读的最近输出。
如果每次手机打开终端都要重新拼这些内容，工具虽然能用，但工作流仍然很脆弱。
Coding agent 需要可重复入口
Agent 工作流有一些高频动作：在项目目录启动 agent、恢复上次会话、运行验证命令、查看日志、检查 Git、启动后台任务。这些动作应该能在手机上快速触发，而不是每次都凭记忆重新输入。
Redock 用 Project 和 Action 把这些入口显式化。Project 给终端提供工作上下文。Action 给重复任务一个名称和运行方式。
| 需求 | 裸 SSH 习惯 | Redock 工作流 |
|---|---|---|
| 打开仓库 | 手动输入或粘贴 cd ... |
打开保存好的 Project |
| 启动 agent | 重新输入命令 | 点击 agent Action |
| 运行测试 | 回忆具体脚本 | 运行保存的验证 Action |
| 保持任务运行 | 手动管理 tmux | 使用 tmux 会话入口 |
| 稍后看结果 | 翻终端回滚 | 查看 Run 输出或 Activity |
| 发送长 prompt | 直接打进 Shell | 先在待输入区组织 |
这不是隐藏终端，而是减少手机上围绕终端的重复步骤。
结果应该容易回看
快速检查应该留下可回看的输出。后台任务应该暴露日志。长时间 agent 会话应该可以恢复。传统 SSH 客户端通常把这些区分留给用户自己处理。
这会在移动端产生很多不确定性：命令到底跑完了吗？App 进后台后是不是失败了？输出在哪个 session 里？Agent 还在运行，还是网络断开后进程也没了？
对开发工作来说，这些状态不是细节，而是产品层面应该暴露的信息。移动端用户经常在网络、应用和注意力之间切换，工具需要帮助用户看清当前工作状态。
移动端输入不同
在手机上输入原始 Shell 字符很慢，而 agent prompt 往往是一整段话，里面包含意图、限制、文件名、测试名和后续要求。把这种内容逐字符塞进终端行，并不是好的移动交互。
移动端输入需要一个缓冲区。你应该能先写、粘贴、口述、修改，再决定是否发送。对 CJK 输入、中英混合 prompt、命令名、路径和代码符号来说，这尤其重要。转写或输入时的小错误可以在草稿阶段修正，但不应该直接发送到 Shell。
Redock 的待输入区、snippets 和语音转写，都是围绕这个差异设计的。
什么时候普通 SSH 客户端就够了
如果你只是偶尔登录服务器、执行一个简单命令，或者外接键盘后直接控制终端，普通 SSH 客户端完全够用。如果你已经知道精确命令，也不需要恢复会话或保存上下文，它也足够。
Redock 更适合这些情况：
- 你经常在多个项目之间切换。
- 你使用 Claude Code、Codex、OpenCode 这类终端 agent。
- 你经常运行相同测试、构建、日志或部署检查。
- 你希望长任务在 App 进后台或网络切换后继续运行。
- 你想先组织或口述较长 prompt，再发送给 agent。
快速结论
SSH 提供远程访问，但 AI coding 工作流需要的不只是访问。它还需要 Project 上下文、保存的 Action、适合 agent 的输入、可恢复的 tmux 会话、可见的任务输出，以及手机断联后继续回到工作的能力。Redock 补上的就是终端周围这一层工作流。