手机端代理遥控 0x5446/rowel

Rowel

专为 DeepSeek Harness 打造的 iPhone 应用。
你的智能体正等着你——随时随地回应。

dsh 停下来请求权限时，你的手机会震动，你能看到它想运行的命令或 diff，轻点一下就能让 Mac 继续。查看智能体做了什么，回答它卡住的那个问题，在火车上启动下一件事。端到端加密；中继读不到你的流量。

rowel.novabox.ai ·加入 TestFlight · MIT，全部开源：应用、Bridle、中继、协议。

只为 dsh 打造。 Rowel 说的是 DeepSeek Harness API——会话、审批、模型、技能。它不是 Claude Code、Codex、Cursor 或其他智能体的遥控器。Harness 本身能跑很多模型（DeepSeek、GLM、Qwen 等等），Rowel 让你在它们之间挑选。

| 组件 | 是什么 | 运行在哪 |
| Rowel | iOS 应用 | 你的 iPhone |
| Bridle | 一个伴随进程，替 Harness 说话 | 运行 dsh 的 Mac |
| Relay | 一个看不到内容的交换机 | 公网——我们的，或你自己的 |

iPhone internet your Mac
┌────────┐ ┌──────────┐ ┌──────────────────┐
│ Rowel │◄──wss───►│ Relay │◄──wss───►│ Bridle ──► dsh │
└────────┘ sealed └──────────┘ sealed └──────────────────┘
└────────── Noise_IK_25519_ChaChaPoly_SHA256 ─────────┘

Bridle 主动拨出。不用端口转发，不用公网 IP，路由器上什么都不用改。 手机和 Mac 在同一网络时，应用会先尝试直连 Mac，四分之一秒后再拨中继；本地路径通常胜出，之后中继就不再承载这个会话。

没有账号。配对就是终端里的一个二维码。

目前进展

Mac 端已完成，日常在用。中继已部署。Rowel 1.1 需要 dsh 0.2 或更新版本——dsh 0.2 换掉了整套 API，应用和 Bridle 现在直接说新 API。应用在 TestFlight 上，直到通过 App Store 审核。你也可以用 Xcode 自己构建，免费，但有个七天的坑。

还在用 dsh 0.1？Bridle 0.1.x 和应用 1.0 继续可用；用 ROWEL_REF=v0.1.7 安装。升到 dsh 0.2 是单向的——先读从 dsh 0.1 升级。

跑起来

1. 在 Mac 上安装 Bridle

curl -fsSL https://rowel.novabox.ai/install | sh
需要 Node 22+ 和 git —— 脚本不会安装这两样；缺什么它就停下来告诉你 —— 还需要 dsh 0.2，脚本会检查并给出警告。它安装的所有东西都在 ~/.rowel 里，另外在 PATH 上放一个符号链接（以及 npm 的常规缓存）。它一共 144 行，其中超过三分之一是注释，如果你想先读一遍再运行，可以看看。

2. 配对

bridle pair

如果 Bridle 没在运行，它会启动 Bridle，打印一个二维码，然后保持运行。在 App 里点 Connect a Mac，再点 I've run it — scan the code。如果 Bridle 已经在运行（作为服务，或作为 dsh 的插件），它只会打印一个新码。--code 作用相同，用于手动输入而不是扫码。

如果 dsh 已经在运行 —— 手动启动的，或者由登录项保持运行 —— Bridle 无法从外部登录它：dsh 0.2 只把登录 token 交给自己的插件。改为在 dsh 内部运行 Bridle，然后重启 dsh：

bridle plugin install

bridle status 会告诉你当前是哪种情况，bridle doctor 会在两者都不是时告诉你该怎么做。如果放任不管，且没有 dsh 在运行，Bridle 会自己启动一个，并用它打印的 token 登录。

通过 SSH 连接时，终端可能画不出二维码，加上 --link 可以打印原始配对链接。当无法使用摄像头时，bridle pair --code 会打印一个 8 字符的码供你输入，然后等待：Mac 随后会显示手机的公钥并请你确认，你拿它和手机上显示的公钥核对。SECURITY.md 说明了这一步为什么存在。

3. 保持运行

bridle service install

登录后自动启动，关闭终端也不受影响。bridle service uninstall 可以把它卸掉。

bridle 命令

bridle start (and pair, on the first run)
bridle pair a pairing QR, starting bridle if none runs (--code: a code to type)
bridle status machine, relay, harness, paired devices
bridle devices list paired devices
bridle revoke <prefix> remove one
bridle backup <file> save this machine's identity, encrypted
bridle restore <file> put a saved identity back
bridle service install keep it running after login
bridle plugin install run bridle inside dsh instead (how it signs in to a dsh already running)
bridle doctor check this machine's setup

bridle 本身可用的参数：

--relay <url> a different relay (default: the public one)
--dsh <url> the harness, if it is not on a usual port
--advertise <url> an extra address to put in the pairing code — a tunnel hostname the machine cannot discover for itself. LAN and Tailscale addresses are found automatically. --direct-port <n> fix the local-network port --no-direct do not listen on the local network at all --no-auto-start never launch the harness --link also print the raw pairing link

状态保存在 ~/.rowel/bridle.json，权限 0600，里面存着这台机器的私钥。ROWEL_HOME 可以把它挪走。

一台 Mac 上跑两个 harness

一个 Bridle 只服务一个 dsh。放任不管时，它会探测常见端口（3080–3083、8080、8791），并沿用上次应答的那个 dsh——只有一个 harness 时没问题，有两个就是掷硬币。--dsh 终结这种猜测：

bridle --dsh http://127.0.0.1:3081

如果那里没有应答，Bridle 会在该端口上启动一个 harness——启动行会显示 (started by bridle)，表示是它启动的。--no-auto-start 让它改为拒绝启动。

同一个身份只能运行一个 Bridle；第二次启动会停下来，并说出第一个的名字。所以要把现有配对挪到别的端口，先停掉正在运行的 Bridle，再用 --dsh 启动。要让第二个 harness 与第一个并存，给它一个自己的身份：

ROWEL_HOME=~/.rowel-3081 bridle --dsh http://127.0.0.1:3081

它首次运行会打印自己的二维码，应用里会显示第二台机器——名字相同，靠指纹后缀区分。bridle pair 不需要这些：它什么都不启动，所以能愉快地跑在已经启动的 Bridle 旁边。

从 dsh 0.1 升级

dsh 0.2 首次启动时会重写 ~/.dsh——settings.yaml 变成 settings.yaml.imported，其中的各个 section 移入 profile——而 dsh 0.1 读不了 0.2 写入的对话。所以：

1. 升级前完整备份 ~/.dsh。想回退，就要恢复那份副本，并重新安装 @deepseek-ai/dsh@0.1.1-rc.2，而不只是降级。
2. 把 dsh、Bridle（curl -fsSL https://rowel.novabox.ai/install | sh）和应用一起升到 1.1。应用 1.0 无法与 Bridle 0.2 通信，Bridle 0.2 也无法与 dsh 0.1 通信。
3. 如果你的模型来自网关——Command Code、OpenRouter，任何配置在 llm-pi-ai 下的东西——升级后就没了：dsh 0.2 的默认 profile 不加载那个 adapter，导入时也会丢掉这个 section。把它放回 ~/.dsh/profiles/web/cordis.patch.yml，从 settings.yaml.imported 复制 providers 块（以及你的默认模型）：

- insert:
- id: llm-pi-ai
name: '@deepseek-ai/dsh-llm-pi-ai'
config:
providers:
commandcode: # as it was under llm-pi-ai.providers
apiKeyEnv: COMMANDCODE_API_KEY
api: openai-completions
baseURL: https://api.commandcode.ai/provider/v1
… its models list, unchanged

- id: agent-default-model
config:
provider: commandcode
model: deepseek/deepseek-v4.1-flash

然后重启 dsh。密钥留在原处：路由通过环境变量来引用它们。
4. 如果 Bridle 之前作为 dsh 的插件运行，它现在仍然是；否则运行 bridle plugin install 并重启 dsh（见 Pair）。

它保护什么，不保护什么

中继按电路编号在两个 socket 之间转发密封帧。它没有密钥材料，也打不开这些帧，这是形态本身的属性，而不是不承诺任何人的行为——端到端测试会通过中继抓取手机流量，只要其中出现方法名、会话 id、机器名或对话标题，测试就失败。（中继确实会从 Bridle 自己的注册信息里获知机器的显示名称；SECURITY.md 列出了它获知的全部内容。）隧道的两套实现都只用各自平台自带的原语，Node 的 node:crypto 和 Swift 的 CryptoKit。代码树里没有任何第三方密码学依赖。

人们低估的那部分： dsh 向浏览器索取的，不过是它打印出来的那个 token，而 Bridle 持有这次登录，所以配对后的手机对那台 Mac 拥有的权限，和它自己的终端一样——可以运行命令，读写文件。bridle revoke 是收回权限的唯一办法。应用里没有任何一项权限比这更小；应用只是少画了几个按钮。

SECURITY.md 是完整的威胁模型，包括中继确实会获知什么、手机解锁意味着什么，以及已知的弱点。在配对任何你在意的东西之前，值得先读一读。

从源码构建

npm install
npm test # build, docs check, unit tests. Seconds.
npm run test:e2e # the whole stack; ROWEL_E2E_DSH_BIN=<dsh 0.2> for the parts that need dsh,
ROWEL_E2E_MODEL=1 for the few that spend model turns
npm run test:ios # needs Xcode and brew install xcodegen
npm run vectors # regenerate the cross-language test vectors

protocol/ Noise, frames, pairing, relay wire format (TypeScript)
bridle/ the companion process and its CLI
dsh-plugin/ the same core, mounted inside the harness instead of beside it
relay/ the Node relay
relay-worker/ the same relay on Cloudflare Workers and Durable Objects
e2e/ tests that span all three
ios/ the app (Swift, SwiftUI, XcodeGen)

两套实现如何保持同一套协议

Noise 握手和帧编码写了两遍，一遍 TypeScript，一遍 Swift。「我的服务端和我的客户端能通话」在两端都是我自己写的时候证明不了什么，所以 npm run vectors 用固定的密钥和固定的临时密钥跑一遍握手，写出确定性的测试夹具；Swift 那边逐字节比对——握手消息、握手哈希、确认号、传输密文、配对链接、帧编码。

这里失败意味着协议分叉，不是测试不稳定。它已经抓到过一次：Foundation 的 JSONEncoder 不保证键的顺序，两端都能正常解析，自己跟自己对话再怎么聊也发现不了。

运行你自己的中继

bridle --relay wss://your.host 就是客户端侧的全部。relay/ 是单个 Node 进程，没有数据库，也没有配置文件；relay-worker/ 是同一个交换机跑在 Cloudflare Workers 上，公开的那个就跑在这上面。docs/deployment.md 里有 DNS 和 TLS 的细节。

文档

docs/ 是中文写的——它是给维护这个项目的人看的，翻译它比让它保持正确还费劲。英文读者并不是看不了关键部分：SECURITY.md 讲了威胁模型，CONTRIBUTING.md 讲了构建方式和规则，代码注释和提交信息也全程是英文。

| docs/architecture.md | 为什么是这个形态，新功能该放哪 |
| docs/protocol.md | 线上传输的确切字节，够你写第三个客户端 |
| docs/fold.md | 事件日志怎么变成屏幕画面，一条条规则讲 |
| docs/dsh-api-inventory.md | 应用用到的 dsh 0.2 端点和流，以及用在哪 |
| docs/deployment.md | 怎么跑 relay、DNS，以及上线还差什么 |

docs/README.md 说明了哪些章节是规范级、哪些是设计级。想照着设计级的章节重新实现，先来问一声。

许可

MIT。见 LICENSE。