夜雨聆风"我 SSH 进服务器从沙滩写代码"——开发者们在 Termux 里愤怒地关掉终端的次数，和这句话被说出口的次数一样多。但 2026 年的今天，AI 编程代理让这个梦想变得真实：Claude Code 的 Remote Control 在 2026 年 2 月发布后迅速达到 2.5B+ ARR，OpenAI Codex 紧随其后推出 App Server 远程协议，Google Gemini CLI 也加入战局。开发者们不再需要在手机上敲代码——他们只需要用自然语言下指令，真正的编码由代理执行。
这背后藏着远超 QR 码扫码的工程深度。Claude Code 的远程控制经历了从 V1 环境注册+轮询到 V2 SSE+CCRClient 直连的两代架构演进，跨约 31 个源文件、约 11,700 行协议编排代码。Codex 的 App Server 定义了 33 个 JSON-RPC 方法、7 种审批类型。社区贡献了 CC Pocket（iOS/Android 双端）、mobilecoding（Go+PWA）、codex-relay、taskdex、cc-haha（微信/飞书/Telegram）等开源方案。
本文将从协议架构、源代码级实现、开源生态对比、自建指南四个维度，用事实和数据还原这张正在快速膨胀的技术版图。
四大技术路线与核心权衡
所有手机控制 AI 编程代理的方案，都能归入以下四条路径。它们不仅在架构本质上有根本差异，更深层的区别在于"信息在哪里中转"和"谁处理 Token"。
四大方案核心对比
📡 官方文继（Claude RC）
信息中转：Anthropic API（仅路由消息）Token 消耗：订阅额度（Pro/Max）传输协议：HTTPS 轮询 + SSE端到端加密：TLS + 声称 E2E手机发起会话：✗ · 电脑离线后：~10 分钟超时代码执行位置：本地机器 · 源文件规模：~11,700 行 / 31 文件
🔗 本地桥接（CC Pocket 等）
信息中转：你的本地机器（自托管 Bridge）Token 消耗：API Key 或订阅（取决于后端）传输协议：WebSocket端到端加密：mTLS / AES-256手机发起会话：✓ · 电脑离线后：连接断开代码执行位置：本地机器 · 源文件规模：~2,000–10,000 行
🖥️ SSH + tmux（DIY 终端）
信息中转：直连/中继（SSH 隧道）Token 消耗：订阅额度（与桌面端相同）传输协议：SSH / mosh端到端加密：WireGuard手机发起会话：✓ · 电脑离线后：tmux 延续代码执行位置：远程服务器 · 源文件规模：~0（仅有配置）
💬 IM 渠道（cc-haha）
信息中转：IM 服务器（Telegram/微信）Token 消耗：API Key（可混合路由）传输协议：IM Bot API端到端加密：IM 传输层手机发起会话：✓ · 电脑离线后：连接断开代码执行位置：本地/远程 · 源文件规模：~5,000+ 行
注："从手机发起会话"指能否在手机上输入指令启动一个新会话——这是官方 RC 目前与社区方案最大的体验鸿沟。"源文件规模"反映方案工程复杂度。
Claude Code 远程控制：两代架构的源代码级拆解
Claude Code 的远程控制是目前工程上最复杂的方案。它经历了两代架构演进：V1 的"环境注册+轮询"架构和 V2 的"SSE+CCRClient 直连"架构。理解它们是理解整个远程控制生态的技术地基。
V1 vs V2 架构对比
生命周期步数
V1：6 步（注册→轮询→确认→生成→心跳→注销）V2：3 步（创建会话→获取 JWT→连接传输）
传输协议
V1：HTTPS 长轮询（25 秒 hold）V2：SSE（读）+ CCRClient HTTP POST（写）
会话超时
V1：~10 分钟硬上限（5 次心跳丢失）V2：受 JWT 有效期控制，可刷新
重连机制
V1：指数退避 2s→60s，15 分钟放弃V2：序列号恢复 + FlushGate 消息保护
核心理念
V1：环境注册+任务分发V2：减法——移除 Environments API 轮询层
核心源文件：V1 bridgeMain.ts (~3000行) · V2 remoteBridgeCore.ts (~1009行)
2.1 V1 架构：六步生命周期与长轮询
尽管 V1 已被 V2 取代，理解它的设计能帮助我们理解为什么 V2 做了哪些减法。V1 的核心是一个六步状态机，每一步解决一个分布式系统问题：
V1 六步生命周期
① 注册POST /environments发送机器名、工作目录、git 分支、最大会话数 → 返回 environment_id + environment_secret
② 轮询GET /environments/{id}/poll长轮询——服务器保持连接最多 25 秒。动态轮询间隔：空闲 30s / 活跃 2-5s / 初始 5s。错误时指数退避：初始 2s→上限 60s→15 分钟放弃
③ 确认POST /environments/{id}/ack使用 session_token（非 environment_secret）确认已接收工作——防止重新分发导致重复执行
④ 生成解码 work secret（Base64URL JSON，内含 JWT/API URL/认证 Token/MCP 配置）→ 创建服务端会话 → fork 子进程（故障隔离——一个会话的 OOM 不影响其他会话）
⑤ 心跳POST /environments/{id}/heartbeat每 60 秒/活跃会话。使用 JWT（无需数据库查询）。服务端 TTL 300 秒（5 分钟）——允许 5 次心跳丢失。报告状态：running / idle / requires_action
⑥ 停止 + 注销有序关闭：停止接收新工作 → 强制杀死会话 → 等待 30s → 注销环境
V1 的源文件分布在约 7 个关键文件中：bridgeMain.ts（~3000 行，守护进程轮询循环+会话管理）、replBridge.ts（~2407 行，REPL 嵌入模式+环境注册）、bridgeApi.ts（~540 行，Environments API HTTP 客户端）、sessionRunner.ts（~481 行）、workSecret.ts（~147 行）、types.ts（~263 行）、pollConfig.ts。
2.2 V2 架构：SSE + CCRClient + Epoch 系统
V2 的核心理念是减法——移除 Environments API 轮询层，替换为 SSE（读）+ CCRClient（写）的分离双工架构。核心引擎在 remoteBridgeCore.ts（~1009 行）。
V2 架构：SSE + CCRClient 分离双工
📱 手机 / claude.ai ⇄ ☁️ Anthropic Relay ⇄ 💻 本地 CLI
读通道 SSE：GET /worker/events/stream增量 SSE 帧解析 · 序列号记录 → 断线恢复
写通道 CCRClient：POST /worker/eventsSerialBatchEventUploader · 批处理上限 100 条
心跳：PUT /worker默认 20 秒间隔 · JWT 中 epoch 认证
Epoch 系统——V2 的核心发明。Epoch 是一个单调递增的整数计数器，服务端维护：
每次 /bridge 调用递增 epoch
Worker JWT 中嵌入当前 epoch + session_id
旧 epoch 的心跳 → 20 秒内收到 409 epoch mismatch
新 epoch 自动使旧 epoch 失效——无需显式"取消旧连接"
保证单一活跃连接：任何时候只有一组（JWT, epoch, transport）有效
Epoch 的兼容性处理也很精细：由于 Go/protojson 的 int64 编码可能返回字符串或数字，CLI 端做了一层保护：
const rawEpoch = data.worker_epochconst epoch = typeof rawEpoch === 'string' ? Number(rawEpoch) : rawEpochif (!Number.isFinite(epoch) || !Number.isSafeInteger(epoch)) return null
2.3 FlushGate：70 行的消息保序状态机
FlushGate 是 V2 中一个精巧的设计，用于在传输重建期间保护消息顺序。它只有三个状态：
Idle（未激活）：enqueue() 返回 false → 调用者直接发送
Active（门控激活）：enqueue() 返回 true → 消息被排队
End（释放）：返回所有排队消息 → 调用者通过新传输发送
export class FlushGate<T> {private _active = falseprivate _pending: T[] = []start(): void { this._active = true }end(): T[] { this._active = false; return this._pending.splice(0) }enqueue(...items: T[]): boolean {if (!this._active) return false // 直接发送this._pending.push(...items)return true // 已排队}}
传输重建流程：当 JWT 刷新或 401 恢复触发传输重建时，系统通过序列号实现零丢失恢复：
① FlushGate.start() 开始门控——新的出站消息被排队，不丢失
② 从旧 SSETransport 读取最后序列号（getLastSequenceNum()）
③ 关闭旧传输
④ 创建新传输，传递 initialSequenceNum——服务端从该点恢复
⑤ 重绑定回调 → transport.connect()
⑥ 重新调度下一次 JWT 刷新
⑦ FlushGate.end()——通过新传输发送所有排队消息
没有序列号传递，服务端会在每次传输重建时从 seq 0 重放整个会话历史——这是 V1 和 V2 之间最关键的可靠性差异。
2.4 两种启动模式：守护进程 vs REPL 嵌入
Claude Code 支持两种远程控制启动模式，它们的架构有本质区别：
🛡️ 守护进程模式
命令：claude remote-control进程模型：独立进程，子进程 fork并发：最多 32 个并发会话源文件：remoteBridgeCore.ts
🔄 REPL 嵌入模式
命令：/rc 或 /remote-control进程模型：注入现有 REPL 会话，无子进程并发：单会话（共享现有环境）源文件：replBridge.ts (~2407行)
两种控制面：PTY 与 stdio 的架构之争
这是远程控制中最容易被忽视、却是最根本的架构决定：接入 AI 编程代理有两种完全不同的控制面，它们在传输协议、输出格式、计费模式上都有根本差异。
Headless stdio vs 交互式 PTY
🤖 Headless stdio 模式
调用：claude -p "prompt" --print输出：结构化 NDJSON（stream-json）解析复杂度：低 — JSON 解析器即可权限管控：原生支持 control_request计费池：Agent SDK 月度额度适用：自动化、CI/CD、脚本编排
💻 交互式 PTY 模式
调用：claude（不带参数）输出：ASCII/ANSI 终端字节流（TUI）解析复杂度：高 — ANSI 解析+终端大小+提示检测权限管控：需要 PTY 字节流拦截解析计费池：正常订阅（Pro/Max）适用：人机交互、远程终端、调试
计费分水岭是 2026 年 6 月后的关键变化：Anthropic 将两种模式的计费分开。交互式 Claude Code 走正常订阅额度；claude -p / Agent SDK / GitHub Actions 则使用独立的 Agent SDK 月度额度。这催生了像 claude-pty-acp 这样的方案——它用 PTY 包装交互式 Claude（走订阅计费），但对外暴露 ACP 协议接口。
claude-pty-acp 的双通道架构是目前最精巧的 PTY 桥接方案：
预览通道：从 PTY 字节流解析代理思考过程（快，~8.6s 首个 token）
权威通道：从 transcript JSONL 文件阻塞式读取（全量准确，~14s）
协议层深潜：NDJSON · JSON-RPC · JSONL
所有远程控制方案最终都归结为消息协议。无论是 Claude Code 的 NDJSON、Codex 的 JSON-RPC 2.0，还是社区方案的自定义 WebSocket 协议，理解它们的设计是开发者的核心功课。
4.1 Claude Code NDJSON 消息类型完整目录
Claude Code 在 headless/print 模式下通过 stdout 输出结构化 NDJSON，通过 stdin 接收输入。每条消息包含 type 字段。以下是完整消息类型：
NDJSON 消息类型目录
system/init（CLI→调用者）：{ session_id, cwd, tools[], mcp_servers[], model }
user（调用者→CLI）：{ message: { role: "user", content: [{ type: "text", text }] } }
assistant（CLI→调用者）：{ message: { role: "assistant", content: [{ type: "text" | "tool_use", ... }] } }⚠ content 必须是数组，裸字符串崩溃加载器
control_request（CLI→调用者）：请求工具使用审批
control_response（调用者→CLI）：返回 allow/denyallow 必须带 updatedInput，deny 必须带 message
result（CLI→调用者）：{ subtype, result, total_cost_usd, usage, session_id }
system/compact_boundary（上下文压缩后触发）· rate_limit_event（速率限制通知）
关键工程约束：控制请求必须 10-14 秒内响应，否则服务器断开 WebSocket。这个超时设计是为了防止工具调用无限等待——但也给远程控制带来了严格的人机环延迟要求。
4.2 Codex App Server JSON-RPC 2.0 协议
Codex app-server 使用 JSON-RPC 2.0 作为基础协议（连线格式省略 "jsonrpc":"2.0" 字段），支持 stdio（JSONL）和 WebSocket（实验性）两种传输。它与 Claude Code 的核心差异在于三层层次结构：
Codex App Server 三层会话模型
Thread（会话线程） — 12 个方法：start, resume, fork, read, list, archive, rollback, compact/start线程是独立会话容器，每个线程有独立的上下文窗口
Turn（对话轮次） — 3 个方法：start, steer, interrupt状态：inProgress → completed / interrupted
Item（原子操作） — UserMessage | AgentMessage | Plan | CommandExecution | FileChange | McpToolCall | WebSearch | Reasoning生命周期：item/started → ... → item/completed
33 个 JSON-RPC 方法覆盖：线程管理（12 个方法）、轮次控制（3 个）、项流式通知（4 个事件方向）、交互式审批（3 个）、远程控制管理（2 个实验性 RPC：remoteControl/client/list 和 remoteControl/client/revoke）、配置覆盖（每个 Thread 和 Turn 可以独立指定 model/cwd/approval_policy/sandbox_policy/personality/effort 等）。
Codex 的 7 种审批类型比 Claude Code 更精细：accept（单次）、acceptForSession（会话内缓存）、acceptWithExecpolicyAmendment（持久化策略）、decline（拒绝但继续）、cancel（拒绝并中断轮次）。
4.3 JSONL 会话持久化格式
无论是 Claude Code 还是 Codex，会话数据都使用 JSONL（JSON Lines）文件持久化。理解这个格式对于构建远程控制工具至关重要。
Claude Code 的 JSONL 文件位于 ~/.claude/projects/{sanitized-cwd}/{session-id}.jsonl。它包含以下条目类型：user / assistant / system（对话消息链）、summary（压缩摘要）、last-prompt（最近提示）等 15+ 元数据类型。
Parent-UUID 链是 JSONL 的关键结构：消息通过 parentUuid → uuid 形成链表。这使得分叉会话、子代理会话和上下文压缩边界成为可能。
// JSONL 条目硬规则（不遵守会崩溃加载器）： // 1. assistant content 必须是数组，不能是裸字符串 // 2. permission-mode 条目必须正好三个字段 // 3. cwd 必须是规范路径（macOS: /tmp → /private/tmp） // 4. 每个 tool_use 必须有同 tool_use_id 的 tool_result 配对
4.4 会话完整生命周期事件链
从 Claude Code 的 Hook 系统定义中，可以提取出一个完整的会话生命周期事件链——这是所有远程控制方案都必须处理的底层模型：
SessionStart → Setup（CLI 初始化） → UserPromptSubmit → UserPromptExpansion → [Agentic Loop 开始] → PreToolUse（工具前钩子，可阻断） → PermissionRequest / PermissionDenied → Tool Execution（Bash / Read / Edit / Write / Glob / Grep...） → PostToolUse（成功后） / PostToolUseFailure（失败后） → PostToolBatch（并行工具批处理结束后） → PreCompact / PostCompact（上下文压缩前后） → Stop / StopFailure → [循环直到无工具调用或触发限值]SessionEnd
远程控制架构必须映射这个完整的生命周期：在 Stop 后允许新输入、在 PreToolUse 中触发远程审批、在 Tool Execution 中流式传输输出、在 Compact 后指示 UI 上下文已被压缩。
开源方案深度拆解：五个项目的架构与协议
社区开源方案远不是"照搬官方文档"那么简单。每个项目都有独特的架构设计来应对不同的分布式系统挑战。以下是五个最具代表性的项目及其核心架构决策。
📦 CC Pocket
github.com/K9i-0/ccpocket · MIT · Flutter + TypeScript · 最完整的跨平台方案
CC Pocket 是目前协议最完整、平台覆盖最广的移动方案。架构链：Flutter App ←WebSocket (JSON)→ @ccpocket/bridge ←stdio→ Claude SDK / Codex CLI
协议：WebSocket 纯文本 JSON，默认端口 8765
Auth：API Key 可选 · 发现：QR 码 + mDNS 自动发现
推送：Firebase Cloud Messaging
容错：断线恢复 + 丢失 Streaming delta 补发 + 离线队列
关键工程决策：CC Pocket 的 Bridge 使用 Node.js 子进程模式——每会话 = 一个子进程，天然支持多会话并发，每个会话独立隔离。
📦 mobilecoding
@banlan/mobilecoding · Go 后端 + PWA 前端 · 最轻量的 Go+PWA 方案
mobilecoding 的 Go 后端采用模块化引擎架构，支持四种 Agent 驱动：
ClaudeRunner（Stream JSON）· CodexRunner（JSON-RPC）· PtyRunner（PTY 模式）· PipeRunner（通用管道）
模块架构：engine/（Agent 驱动注册）→ projection/（Stream JSON→结构化事件）→ ws/（WebSocket 编解码/连接/Replay Buffer）→ auth/（mTLS+CA+证书轮换）→ store/（SQLite+序列号+增量同步）
关键工程决策：mobilecoding 用 projection 层来解决"不同 Agent 输出格式不同"的问题——它将 Claude 的 stream-json 和 Codex 的 JSON-RPC 统一投影为结构化事件。
📦 cc-haha
基于泄露 Claude Code 源码 · Gateway-Adapter · 六层 ACL · 最复杂的 IM 适配架构
cc-haha 是目前架构最精细的 IM 渠道适配方案。它的 Gateway-Adapter 模式将 IM 控制提升到了生产级别：
核心组件
WsBridge：WebSocket 连接管理器 + 指数退避重连 + 30s ping/pong 心跳Pairing 系统：6 位 SAFE_ALPHABET 配对码 + 5 次/5 分钟速率限制ImageBlockWatcher：扫描流式输出中的 Markdown 图片引用 → 自动上传到 IM 平台MessageDedup：防止同一 IM 事件被处理两次ChatQueue：每个聊天的顺序消息处理队列
六层 ACL 安全模型：① MCP 能力声明 → ② GrowthBook 运行时特性门 → ③ OAuth 认证 → ④ 组织策略 → ⑤ 会话白名单 → ⑥ Marketplace 来源验证
📦 codex-relay
github.com/gronxb/codex-relay · Web UI · 无 App · 最专注的 Codex 方案
codex-relay 采用最简设计哲学：一行命令启动、QR 码连接、移动浏览器即 UI。架构是典型的"轻量代理"模式：
手机浏览器 ←HTTP/SSE→ codex-relay ←stdio/WebSocket→ Codex CLI
无移动 App、无推送通知、无离线队列
流式代理输出、提示词发送、线程管理、操作审批
Git diff/文件/终端输出预览
📦 taskdex
React Native · WebSocket · Expo 推送 · 唯一的多代理并行方案
taskdex 在架构上的独特之处在于它不是 1:1 桥接，而是N:M 多代理操作中心。它同时管理多个 Codex 代理实例，每个代理在不同项目上工作，全部从手机统一管理：
多代理并行：每个代理 = 独立 Codex CLI 子进程
Expo 推送通知 + 锁屏回复（iOS 通知直接回复）
Git 全操作（status/diff/commit/branch switch）
Docker + VPS 部署支持
自建 Bridge：最小可行实现与设计模式
理解远程控制方案的最佳方式是实现一个最小版本。以下是一个自建 Bridge 的核心架构和关键实现模式。
6.1 核心架构模式
Bridge 最小参考架构
📱 Phone App (Flutter / PWA) ⟷ JSON WebSocket ⟷ Bridge Server (Session Manager · Permission Gate · Auth · mDNS) ⟷ stdio pipe ⟷ 💻 Claude CLI (child proc --print --stream-json)
6.2 关键实现模式：子进程管理
Bridge 的核心是子进程生命周期管理。这里有两个已知的陷阱：
死锁风险：stdio MCP 传输在递归调用时会产生死锁。解决方案：基于文件的协调（共享临时文件）或 HTTP 传输。
1 会话 = 1 子进程：每个 Claude Agent SDK 的 query() 调用生成一个独立的 CLI 子进程。
stdin 必须先发送 user 消息：WebSocket 建立后必须立即发送一条 user 消息，否则 CLI 不会输出 system/init。
6.3 最小协议实现
WebSocket 消息协议设计
客户端→桥接：start_session（发起新会话）· prompt（发送提示词）· approve/deny（响应审批）· interrupt（中断轮次）
桥接→客户端：init（会话初始化）· text/thinking（流式文本）· tool_use（工具调用）· permission_request（审批请求）· done（轮次完成）
完整实现参考 @ccpocket/bridge（TypeScript，约 ~2000 行桥接逻辑）或 handsfree-bridge。
6.4 远程网络接入方案
远程网络接入方案对比
Tailscale
原理：WireGuard VPN，仅节点间直连 · 适合：个人使用，少量设备 · 安全：⭐⭐⭐⭐
Cloudflare Tunnel
原理：cloudflared 出站连接 → CF 边缘 · 适合：无公网 IP，企业环境 · 安全：⭐⭐⭐⭐
ngrok
原理：TCP 隧道 + 公网端点 · 适合：快速原型开发 · 安全：⭐⭐
SSH 反向隧道
原理：autossh 保持 SSH 隧道 · 适合：有公网跳板机 · 安全：⭐⭐⭐
安全模型：从密钥管理到会话劫持
将 AI 编程代理暴露到手机上，本质是在开发机器上开了一个远程代码执行通道。安全不是附加功能，而是核心架构属性。
7.1 四层防御模型（Claude Code RC）
Layer 1：传输层 — TLS 加密，仅出站 HTTPS 到 api.anthropic.com无需特殊防火墙规则，流量与正常 API 调用混在一起
Layer 2：认证 — CLI 侧 OAuth（claude /login）+ 手机侧 Max 计划登录两个独立检查链路
Layer 3：范围凭证 — 多组短生命周期 Tokensession_token（会话标识）/ relay_token（消息中继）/ auth_token（身份验证）一个 Token 泄露不影响其他
Layer 4：会话 URL（最弱环节）会话 URL 本身就是主登录凭证——获取 URL = 完全操控会话。攻击面：咖啡厅 QR 肩窥、iCloud 截图同步、浏览器历史、Slack 误粘贴
7.2 C2 背景威胁
安全研究员 AgentSteer 指出了一个结构性问题：Claude Code RC 的通信模式——持久出站连接 → 合法域名 → 自动重连 → 任意 Shell 执行——如果被攻击者劫持会话 URL，就成为一个看似合法的 C2 通道。它可通过防火墙（流量到 api.anthropic.com），能执行 Bash、访问 SSH 密钥和 .env 文件，并在网络中断后自动恢复连接。
7.3 Sandbox 模式
启用沙箱（限制文件系统到项目目录 + 限制网络）claude remote-control --sandbox默认：无沙箱claude remote-control
Sandbox 默认关闭。如果通过 /rc（REPL 嵌入模式）启动远程控制，--sandbox 参数甚至不可用。
性能与可靠性：从延迟预算到断线恢复
8.1 延迟预算（Claude Code RC）
手机 → Anthropic 中继 → 本地 CLI → 执行工具 → 本地 CLI → Anthropic 中继 → 手机
~50ms ~10ms ~0ms ~200ms ~10ms ~50ms ~50ms
· 工具执行时间（git diff — ~200ms） · LLM 推理时间（1s–30s，占延迟大头）
简单工具调用总延迟：约 320ms（不含 LLM 推理）。
8.2 重连与容错策略对比
重连策略对比
基本退避
Claude Code V1：2s→60s，指数Claude Code V2：连接 2s→120s / 通用 500ms→30sCC Pocket / Bridge：1s→30s，指数+抖动
放弃时间
V1：15 分钟 · V2：连接 10min / 通用 10min · CC Pocket：~5 分钟
心跳
V1：60s/会话，JWT 认证 · V2：20s（CCRClient 内置）· CC Pocket：30s ping/pong
消息保护
V1：Ack 确认防止重复分发 · V2：FlushGate + 序列号恢复 · CC Pocket：WebSocket 缓冲 + 重传补发
离线队列
V1：无 · V2：FlushGate 门控 · CC Pocket：在线时消息补发
8.3 已知故障模式
~10 分钟硬截止：较长时间网络中断后会话死亡——V2 已修复为 JWT 刷新 + 序列号恢复。
手机侧重连损坏：手机不跟踪连接健康状态。GitHub issue #28571 已确认。
笔记本电脑唤醒竞态：休眠后定时器刷新 + SSE 401 触发两个路径同时竞争刷新。V2 使用 authRecoveryInFlight 布尔锁防护。
双向心跳缺失：手机无法区分"服务器宕机"和"只是还没收到回复"。
应用场景与选型决策
场景选型一览
从沙发上"看着"代理干活
推荐：Claude Code RC — 扫码即用，无需部署，V2 架构 3 步直连
同时管理 Claude + Codex + Gemini
推荐：CC Pocket / CodeVibe — 原生多代理支持，一个应用全覆盖
不想装任何 App
推荐：mobilecoding — PWA 全功能，mTLS 安全，SQLite 离线
在微信/飞书里控制
推荐：cc-haha / xacpx — 零学习成本，六层 ACL 企业级安全
团队多人同时用
推荐：cc-haha（IM 渠道） — PM/设计师/工程师共享，无需安装 CLI
隐私/安全最优先
推荐：Tailscale + tmux + Termius — WireGuard E2E，代码永不经过第三方
跑多个代理在不同项目
推荐：taskdex — N:M 多代理并行，Expo 推送独此一家
云端 VPS 部署，笔记本可关机
推荐：SSH + tmux — tmux 延续，VPS 永不关机
未来：从"远程终端"到"云端代理原生"
当前所有方案本质上都在做同一件事：将本地终端"投射"到手机上。但以下三个信号指向了不同的未来。
信号一：原生的 claude serveGitHub 上有一个活跃的 Feature Request（anthropics/claude-code#24365），请求实现原生命令暴露 ACP 协议的网络接口——这将终结所有 WebSocket Bridge 方案中"wrap 子进程 stdio"的模式。
信号二：云端代理容器化Builder.io Fusion、Codex Cloud 等方案已经将代理运行在云端容器中。手机成为纯控制终端——笔记本可以关盖。容器自动隔离、按需启动、会话持久化到 SessionStore。
信号三：Agent-to-Agent 协议标准化A2A 协议的推进意味着未来的手机控制不是"一个人对一个代理"，而是"一个人对一个代理网络"——手机上的一个指令可以触发多个代理的协作。
"我们从'在手机上打字写代码'的幻想，走到了'在手机上说话让 AI 写代码'的现实。下一步是在手机上说话，让 AI 去指挥一群 AI 写代码。"
从源代码到工程权衡
本文从源代码级别拆解了手机控制 AI 编程工具背后的四大技术路线——Claude Code 的两代桥接架构（~11,700 行协议编排代码）、Codex App Server 的 33 个 JSON-RPC 方法、社区五个开源项目的架构设计、以及自建 Bridge 的工程模式。
核心发现：没有"最佳方案"，只有"最适合你的分布式系统权衡"。官方中继用减法解决可靠性（V2 移除轮询层），社区桥接用加法增加功能（多代理、离线队列、IM 渠道），而最老派的 SSH+tmux 用"不做任何事"取得了最简单的稳定性。
"手机上写代码"这个存在了二十年的 meme，终因 AI 编程代理变成了可以严肃讨论的工程命题。
📚 主要参考来源
· Claude Code Remote Control Docs· Deep Dive: How Claude Code Remote Control Works — dev.to/chwu1946· Claude Code on Your Phone — Builder.io· CC Pocket — github.com/K9i-0/ccpocket· mobilecoding — npmjs.com/package/@banlan/mobilecoding· codex-relay — github.com/gronxb/codex-relay· cc-haha — DeepWiki.com/NanmiCoder/cc-haha· taskdex — npmjs.com/package/taskdex· Codex App Server 官方文档· AgentSteer Security Analysis· ACP Protocol Docs — DeepWiki· Hex Codex SDK docs
📮 智能体定制 / AI落地咨询 / 前沿部署，加我微信
添加时备注「AI」，优先通过
