企业官网建设流程全解析

三种把 DSH 搬到手机的方案，差的不是功能而是中间那台服务器

把zexadev/dsh-tether、liguobao/ds-harness-remote、chokwinlee/deepseek-harness-desktop三个项目的 README 摊在一起，很容易做成一张勾选表：谁能远程、谁支持 Android、谁有 iOS、谁能在手机上跑 agent。勾完会发现差距不大，都有会话、都有审批、都能在手机上看 agent 干活。

但勾选表回答不了真正决定长期使用的是哪个问题：这条连接中间那台服务器，最后由谁承担。三个项目恰好给了三种答案——没有人、项目方（可以换成你自己）、你自己的网络。

三个都是社区项目，都不是 DeepSeek 官方出品——这一点先记住，后面所有信任判断都跟它有关。

方案一：直连优先，中间没有人

dsh-tether的默认路径是两端用 iroh 打洞直连。直连成功时流量不经过任何第三方——不是「经过一台你自己搭的机器」，是真的没有中间节点。只有打洞失败才回退到中继，而这台中继只承载它读不懂的密文：它没有消灭中继，但把中继降级成了一个看不见内容的转发者。

中间没有人，意味着没人替你运维

这是它最大的好处，也最容易被低估。你不需要一台有公网 IP 的机器，不需要配证书，不需要关心那台机器什么时候挂、什么时候欠费。装完插件、粘一行配对文本，剩下的交给两端。对一个只想在通勤路上看看 agent 跑到哪一步的人，这个成本差是决定性的。

代价是「能不能连通」不完全由你决定

打洞成功与否取决于两端 NAT 的类型，没有配置项可以调。README 给了真机证据：手机 Wi-Fi 关闭只留 5G、电脑在家宽，插件在选定路径上报出公网地址，说明确实打穿了。但同一份 README 也写了：relay 回退尚未在真实网络触发过。最坏情况下的体验没有实测数据。三个项目的完整对照，包括宿主版本区间，完整插件清单与汉化避坑指南 里有整理。

方案二：登录它的服务，四级回退

ds-harness-remote的路径是 LAN → P2P → TURN → Relay 逐级往下退，客户端覆盖 PC、Android、Web，没有原生 iOS App。这是更工程化的设计：每一级都有明确的失败条件，退到下一级还能用，而且 relay 支持自建。纯连通性看，这套覆盖的网络环境比「直连 + 一层回退」更多，尤其是那些打洞注定失败的环境。

代价写在前两行：要登录

它的入口是登录它的服务。一是多了一个账号——意味着有一方知道你在用这个工具、大致什么时候在用，记录到什么程度取决于服务端，README 层面看不到。二是多了一台默认由别人运维的服务器。它支持自建 relay，这是重要的出口：你可以把这台机器换成自己的。但「支持自建」和「默认自建」是两回事，多数人会先用默认的。

一个容易忽略的细节：许可证

dsh-tether的 README 对比表里写着，ds-harness-remote仓库没有 license 文件（它自己是 MIT）。这不是功能问题，但对「要不要放进公司内网」有直接影响：没有 license 文件意味着默认版权保留，能不能改、能不能再分发、能不能内部二次开发，得自己去问作者。个人用无所谓，团队引入就是必须先解决的问题。

方案三：同 Wi-Fi 或自建 Tailscale

deepseek-harness-desktop走最保守的一条路：两端在同一个 Wi-Fi，或者你自己搭一个 Tailscale 网络把它们连起来。中间方是「你自己的网络」——没有第三方，也没有需要新信任的服务。

它的边界作者自己写了

README 明确说明它不在手机上跑 agent——agent 始终在你的机器上，「没带电脑但想用」这个场景它不覆盖。另一条边界是网络：不同 Wi-Fi 就得靠 Tailscale，而 Tailscale 要你自己装、自己配、自己维护节点。它把中间那台服务器明确交给了你。

iOS 这件事值得单独提

它的 iPhone 客户端通过公开 TestFlight beta 分发，这比「未签名 IPA、自己用 AltStore 签、免费 Apple ID 七天过期」省事得多。dsh-tether的 iOS 是 beta，只在 CI 构建、从未在真机运行过、需要自己签名。这不是同一水平的「支持 iOS」。主力机是 iPhone 的话，这个差异比功能表上任何一项都重要。

勾选表漏掉的四件事

手机能不能自己跑 agent：只有dsh-tether有本地模式，且只在 Android 的arm64包。它把 Node 24 和 dsh0.2.1-rc.2的依赖树打进 APK，首次启动解包约 9 秒、之后约 2 秒。iOS 不允许子进程，这个入口不存在。

手机上没有 bash：本地模式听起来像「手机变开发机」，其实不是。手机没有 bash、没有完整 coreutils，依赖 shell 的工具不完整，聊天和文件读写不受影响。

后台连接：dsh-tether打开才连，不保持后台连接，README 给的理由是 Android 的 doze 本来也不允许。审批通知能送到锁屏，但连接本身不会一直在。

包体积：arm64的 APK 约 83 MB（含本地模式运行时），其余架构约 32 MB。

「中间那台服务器」到底意味着什么

把三个方案放回这个框架，区别就具体了。

信任面：没有中间方，你要信任两端的实现和 iroh 的加密；中间方是项目方的服务，你多信任一个运营方；中间方是你自己的网络，你信任自己的配置。

故障域：没有中间方，故障来自 NAT 和两端，排查不了但也不用修；中间方是别人的服务，它挂了你只能等；中间方是自己的网络，挂了你只能自己修。

成本与退出：软件成本都接近零，但第二种要决定「要不要自建 relay」，第三种要维护 Tailscale 节点。退出成本最少被考虑：无账号的方案卸载就是卸载，有账号的要连数据一起处理，自建网络的要拆掉自己搭的东西。

这四项没有一项会出现在功能对比表上，但它们决定三个月后你还在不在用。

这个插件自己的账单

选它之前先把成本摊开。

安全档位是静态扫描的「🔵 含敏感能力」——可执行外部命令、读写删除本地文件、发起外部网络请求，共 5 处证据；尚无人工评估，本站也尚未做风险分级。对一个要在机器侧拉 sidecar、要跨网络传流量的插件，这三项能力在预期之内；但「在预期之内」不等于「评估过」。

两条已知边界要一起看：浏览器信任规则挡不住本机进程——本机进程能给出 loopbackHost、自己换码把自己配成「手机」，能在这台机器上执行代码的攻击者可以换来长期访问；手机端本地代理只听127.0.0.1，但同机任何 App 都能连、端口由 host 推导更好猜。

再加上：relay 回退没有真实网络数据、iOS 只在 CI 构建过、dsh 0.1.7 起会直接拒绝版本范围不覆盖的安装。这些不是劝退项，是「知道自己买的是什么」。

怎么选

只用手机在家里连同一台机器，deepseek-harness-desktop那条路最直接，Tailscale 你可能本来就有。经常在外网、又没有一台能长期挂着的中转机，dsh-tether的直连优先是成本最低的答案，代价是接受「打洞失败时的表现没有实测数据」。需要覆盖尽可能多的网络环境、也愿意为一套更完备的回退链路承担账号或自建 relay 的成本，ds-harness-remote的四级回退更稳，前提是先把 license 问清楚。

三种方案没有高下，只有「中间那台服务器你愿意交给谁」。想清楚这一句，选项会自动收敛。

总结

三个项目在功能上高度重叠，真正的分水岭是中间那台服务器的归属——没有人、项目方、还是你自己；更多同类插件的中文清单见 完整插件清单与汉化避坑指南。

适合与不适合

适合：正在三个方案之间做选型的人；需要向团队解释「为什么不选自建 relay」的人；主力机是 Android、又想在没有电脑时也能用 agent 的人；能接受「先直连、失败再说」这种不确定性的人。
不适合：要求所有链路都有实测数据才敢上线的人——relay 回退没有真实网络记录；团队引入前必须解决 license 归属、而这边暂时给不出答案的场景；只在家里同一个 Wi-Fi 用手机的人，Tailscale 或 LAN 方案更简单。

标签：dsh-tether、DeepSeek Harness、选型对比、点对点连接、远程开发

本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。