Tailscale 远程工作区实战

很多开发者习惯让 Bot 常驻在一台小规格的 2C4G 云 VPS 上——它能全天候在线守候 Webhook、接收指令、响应事件。但一旦涉及实际的代码编写与工具调用，这台低配服务器就会显得力不从心：克隆庞大仓库吃紧、本地编译吃力、环境依赖与模型凭据同步繁琐。可你身边的个人开发电脑（例如一台性能充沛的 Mac）坐拥完整的本地工具链与代码仓库，却无法也不该 24 小时开着公网端口。

把整套开发环境硬塞进 VPS 并不是唯一的解法。另一种架构思路是让各端做自己擅长的事：让 VPS 负责全天候在线接收与分发任务，而由你身边的电脑在受控的本地工作区内完成执行，最后将结果安全返回 VPS。

为了验证这条链路的可行性，我们使用一台标准的 2 vCPU、约 4 GiB 内存的 VPS 与一台 Mac 进行了真实验证：由 VPS 发起会话调度，Mac 在本地已有项目目录下执行受限只读任务，人类在网页端对关键命令进行审核审批，最终 VPS 独立读回已完成的执行结果。

在深入技术细节前，必须明确本次验证的事实边界：这是一次针对会话协议与网络拓扑的 CLI 资格验证实验，并非 DeepSeekBot 已发布的正式远程执行功能。 普通 SSH 路线可随时独立使用；而基于 T3 的远程会话路线，则依赖于我们专门搭建的独立 Nightly 测试服务与试验客户端。更重要的是，这套机制旨在实现安全的远程协同与受控执行，并不代表执行速度更快、成本更低，更不意味着为远端开放无限制的本机系统权限。

先选路线：SSH，还是远程会话？

在动手配置前，首先要理清方向与流量归属。Tailscale 解决的是设备之间的点对点私网连通，但网络接通绝不等于自动拥有了 SSH 登录、应用访问或本地文件执行权限。

在这条私网通路上，你可以选择运行传统的底层 SSH，也可以挂载具备独立鉴权的应用层接口。二者的控制方向与安全模型截然不同：

实际诉求	适用路线	核心执行与授权实体
让本机 Codex / 终端登录 VPS，查看服务状态或执行运维命令	普通 SSH（流量经由 Tailscale 私网转发）	VPS 操作系统中的 SSH 用户、密钥及本地权限
从 VPS 调度 Mac 上的本地工作区，发起可查看、可审批的执行任务	私网 HTTPS（经 Tailscale Serve 访问独立 T3 MCP）	Mac 上的独立 T3 测试服务、应用授权凭据与本地执行器
使用移动设备随时查看任务进度、发送提示或进行命令审批	手机浏览器直连已获准入的 T3 服务端口	手机在 tailnet 的网络准入，以及浏览器的独立配对授权

这里有一个极易混淆的概念：如果你只是需要让 Codex SSH 到 VPS 执行运维，完全不需要部署 T3。 此外，我们在实验中使用的是最标准的 OpenSSH 公钥认证，仅仅是让 SSH 流量流经 Tailscale 分配的内网 IP；我们并未启用 Tailscale SSH。Tailscale SSH 是由 Tailscale 原生接管 SSH 证书签发与节点访问策略的一套独立功能。仅仅因为连接地址是 Tailscale IP 或 MagicDNS 域名，绝不能将二者混为一谈。

路线一：让本机 Codex SSH 到 VPS

在这条由内向外的常规运维链路中，Codex 依然稳妥地运行在你本机的开发环境里，它通过调用本机的系统终端与 ssh 客户端向外发起连接。所有的远程命令最终在 VPS 的操作系统 shell 中执行，并返回标准输出。Codex 进程本身绝不会因为执行了 SSH 而迁移到 VPS 上。

本机 Codex
  → 本机 ssh 客户端
  → Tailscale 私网通道
  → VPS 的 sshd 守护进程
  → 返回远程命令执行结果

规范的搭建与加固步骤如下：

1. 网络准入：本机与 VPS 分别安装并登录 Tailscale，加入同一 tailnet（或通过 ACL 规则互通）。若组织开启了设备审批（Device Approval），须先在管理后台批准新设备接入。
2. 服务端加固：在 VPS 上运行标准的 sshd 服务，必须创建专用的非 root 普通用户；配置操作系统防火墙以及 Tailscale ACL，只允许来自授权客户端的 SSH 流量访问端口。
3. 密钥分发：在本机生成专用的 SSH 密钥对，将公钥追加到 VPS 对应用户的 ~/.ssh/authorized_keys 中。切勿为了图省事把其他服务器或私人电脑上的私钥复制到当前机器。
4. 指纹核验：首次发起连接时，务必通过 VPS 云服务商控制台等带外可信信道严格核对主机公钥指纹，再写入本机的 ~/.ssh/known_hosts。绝不可为了自动化而盲目关闭主机公钥检查。
5. 人工先验：在将 SSH 别名交给 Codex 等 AI 助手前，务必先由人类在终端里成功完成一次交互式连接与验证。

推荐在本机 ~/.ssh/config 中配置清晰的 Host 别名：

Host bot-vps
    HostName <VPS_TAILSCALE_IP_OR_NAME>
    User <VPS_USER>
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

将尖括号内的占位符替换为你自己的 Tailscale 节点 IP/MagicDNS 名称与用户名后，先在终端手动执行 ssh bot-vps。确认首次指纹核验通过、且密钥无需密码短语交互（或已载入本地 ssh-agent）后，再使用以下非交互只读命令验证脚本化通路：

ssh -o BatchMode=yes -o StrictHostKeyChecking=yes bot-vps 'uname -s; pwd'

随后你便可以在本机给 Codex 下达提示词：“请通过 ssh bot-vps 检查服务器的操作系统信息与当前工作目录，现阶段切勿修改任何系统配置。”Codex 所在的工作区仍需保留对终端和网络权限的正常管控；如果它触发了本地客户端的审批弹窗，照常人工确认即可。需要始终牢记：远程命令所拥有的权限完全等同于 VPS 上该 SSH 用户的权限，遵循最小权限原则，切勿随意将 root 账号作为 Bot 的默认凭据。

路线二：VPS 调度，Mac 执行

我们实验真正想要攻克的，是反向的高价值场景：不是由人从电脑上去登录操作云服务器，而是让全天候在线的 VPS 作为调度中枢，把具体的 AI 工作区任务指派给 Mac 本机来执行。

拓扑关系如下：

VPS 上的试验 CLI
  → Tailscale 私网 HTTPS
  → Mac 上的 Tailscale Serve
  → 仅监听 loopback (127.0.0.1) 的独立 T3 服务 /mcp
  → Mac 上的本地执行器与绑定的真实项目目录
  → 人工网页审批 → 本地命令完成 → 任务结果 → VPS 独立读回

必须着重指出：这条任务通信管道完全没有通过 SSH 登录 Mac。 SSH 仅用于我们从开发机登录并管理 VPS、在 VPS 上触发测试客户端；而从 VPS 到 Mac 派发任务的整个过程，完全基于应用层接口与专属会话协议传输。

在工程隔离上，测试环境做到了极度克制：Mac 上原本就运行着日常使用的桌面版 T3。为了不干扰日常工作、避免意外升级或污染本地状态，我们完全没有触碰原有的桌面版 T3，而是在完全独立的数据目录和端口下，启动了一个平行的后台测试服务。原桌面版稳定停留在 0.0.45；而实验服务则采用专门编译的 v0.0.46-nightly.20261010.2935，源码严格固定在 commit 98beed1a。软件版本直接决定了外部鉴权流程与会话控制能力的差异，切不可把开发分支里的特性等同于当前稳定发行版的现状。

对于一个已经在 Mac 本地启动、且只监听本地回环地址（如 127.0.0.1:43864）的测试服务，利用 Tailscale Serve 将其安全暴露给 tailnet 私网的标准命令如下（此代码仅为服务入口映射示例，并非 T3 的安装启动脚本；执行前须确保端口可用，并提前检查已有的 Serve 配置）：

tailscale serve status
tailscale serve --bg --https=8443 http://127.0.0.1:43864
tailscale serve status

MagicDNS 与 HTTPS 证书等先决条件请参考 Tailscale Serve 官方文档配置；若你的本地服务监听其他端口，请对应调整映射关系。特别警示：Serve 只在 tailnet 内部节点间提供私有安全入口，绝不可使用面向公共互联网开放的 tailscale funnel 来替代！ 此外，操作时切勿滥用全局 tailscale serve reset，以免误伤当前设备上其他业务正在使用的 Serve 配置。

在网络路由打通之后，要使整套链路安全运转，还需要严密闭环以下四项准备：

• 最小化应用授权：必须为 VPS 客户端申请独立的应用 OAuth 授权。在本次测试中，我们严格将权限限定在 orchestration:read 与 orchestration:operate 两个最小 scope 内，既不导出 Mac 桌面端的内部登录凭据，也不在两端之间复制模型密钥。
• 本地执行器就绪：在 Mac 端预先确认独立执行器能够正常唤起，环境变量 PATH 配置完整，且模型账号配额正常。网络连通无法弥补本地模型 Token 欠费或环境缺失。
• 真实工作区绑定：在任务派发前，必须在 Mac 服务中正确登记本地真实代码目录的绝对路径，并在任务会话中明确绑定；绝不可将 VPS 端的文件系统路径误作为 Mac 端的工作区路径。
• 强制人工命令审批：全程严格开启 approval-required 模式，所有关键系统与文件指令必须由人类在浏览器界面中逐一点击 Approve 批准。允许远端客户端提交会话任务，绝不等于给予执行器任意读写电脑系统的白纸黑字。

需要再次提醒：实验中所使用的 VPS 客户端是一个尚未作为正式功能交付的试验性 CLI facade，并不是当下拿来就能用的 deepseekbot remote 原生命令。如欲在生产或个人体系中复刻这种跨设备调度模式，仍需自行构建或适配相应版本的客户端组件、管理鉴权生命周期并设计可靠的防重试与幂等机制。

我们实际验证了什么？

为了得出经得起推敲的技术结论，我们采取了步步为营的递进式验证策略：

第一步：最小问候验证（连通性与模型推理回路）

在触碰真实的本地代码仓库之前，我们首先从 VPS 发送了一个最小化的提示词任务：要求执行器直接输出“你好”，严禁调用任何本地工具。这一阶段的目标非常纯粹，即排除文件系统与工具执行的干扰，单独核验任务投递、会话创建、模型响应及结果回传的基础链路。

图 1：先确认远端任务能完整送达本地执行器并收到模型回答，再进入真实目录环节。正文所有过程截图均在测试结束后从原会话记录中提取裁剪并完成脱敏，保留真实执行证据；测试并未重新执行，也未刻意还原当时的即时审批弹窗。

问候验证的成功，证明了网络与会话控制链路完好，但绝对无法证明执行器具备读取或操作工作区文件的权限。

第二步：受限只读工作区任务（目录确认与哈希核验）

2026 年 10 月 11 日（日本时间），我们在真实 VPS 上创建了一次正式会话，并将工作区精确绑定至 Mac 本机已有的真实 BotHarness 仓库目录。

为了严格锁死操作范围，任务提示词施加了清晰的前提限制：仅允许执行器确认当前工作目录路径、检测底层操作系统环境、读取仓库根目录下的 AGENTS.md 文件，并精确计算其字节大小与 SHA-256 校验和；严禁修改任何文件、严禁安装任何依赖包、严禁运行测试套件，亦严禁探查该项目外的任何文件。

图 2：原任务的历史执行轨迹展开视图。可以看到执行器按部就班发起了 pwd 与文件读取指令。界面条目中的 “Waiting for next input” 属于该任务执行期间的历史状态记录，并不代表抓取截图时当前仍有未处理的审批项；该条目亦不可直接作为审批弹窗交互本身的替代证明。

任务启动后，Mac 端的管理网页首先弹出了针对首条探测命令 pwd 的人工审批提示。在人类审阅并点击 Approve 批准后，执行器继续调用系统工具链完成核验：成功识别出宿主系统为 Darwin 25.6.0 arm64，当前工作路径与绑定的真实项目相符，读取到的 AGENTS.md 大小精确为 16,687 字节，计算得出的 SHA-256 哈希值与本地预先测得的基准数据完全吻合。

与此同时，VPS 侧通过独立状态接口读回的最终状态明确呈现为：status: completed、runCount: 1、pendingRequestCount: 0；Mac 端的前端网页同步展示出最终模型回复。

图 3：原会话中展示的最终文件分析输出与 Supervised 模式标识。为保护隐私，截图对机器完整路径进行了局部裁剪，保留了项目名、系统平台、文件规格与校验哈希；VPS 端的任务完成与清理状态是由独立的后端接口读回确认的，不可仅凭前端画面的视觉渲染作为最终判定依据。

在整个任务执行的前后，我们比对了该工作区的 Git 状态以及所有已跟踪文件的版本差异（diff），确认没有任何改动产生。需要严谨说明的是：这仅仅是一次针对特定代码仓库的有界审计，绝不等于整台电脑没有任何文件发生变动。详细脱敏执行日志已归档于 资格验证 Issue #1364。

事实边界与未验证项声明

本次实验确凿证明了一条端到端通道的闭环：远端提交指令 → 本地真实目录受限执行 → 人工介入审批命令 → 远端独立读回完成状态。

同样必须郑重声明，本次实验尚未验证以下关键场景与假设：

1. 生产环境 Bot 接入未验证：尚未接入真实生产运行中的 DeepSeekBot 对话流与高并发调度。
2. 文件修改与写入未验证：尚未验证代码编辑、多文件改写或复杂构建等破坏性任务的容错与恢复。
3. 原桌面应用会话同步未验证：独立服务与本地常驻桌面应用之间完全独立，不存在自动状态同步。
4. 实体移动端体验未验证：尚未在实体 Android 手机等移动设备上进行过完整的操作、审批与交互 QA。

任何诸如“完全自动化”、“零安全风险”、“全设备开箱即用”或“生产就绪”的说法，均超出了本次验证的事实范围，切勿轻信。

四个容易踩的坑

在搭建这套跨机器、跨协议的调度环境时，有四个非常隐蔽的工程陷阱值得特别警惕：

“Invalid OAuth state” 不一定是授权按钮点错

在早期测试试验客户端时，我们曾频繁遭遇 Invalid OAuth state 报错。经过深度排查发现，问题根源并不在点击动作或用户误操作，而是客户端进程留下了上次未正常释放的 OAuth 回调监听端口。当新的登录流程启动时，代码先在内存中写入了全新的 pending state，却在后续步骤中因端口被旧实例霸占而导致监听挂载失败——最终接收回调的进程与当前 state 不属于同一周期。

解决此类问题的关键，在于保证先成功绑定并独占回调监听端口，再持久化保存 pending state；一旦绑定失败，必须立即清理计时器与暂存状态。排查时应重点检查后台遗留的孤儿进程、端口占用情况以及授权重定向 URL 是否属于当前这次登录尝试。切不可把反复盲目点击授权当成解决方案，更绝不能为了省事而在客户端代码中直接关闭 state 校验。

配对码过期，以及已有登录状态的浏览器干扰

跨端配对链接（Pairing URL）通常具备严格的有效窗口期，一旦过期必须为指定客户端重新签发，复用失效的过期码只会徒劳报错。此外，在我们测试的特定版本中，如果浏览器此前已经存在有效的常规登录态，直接在地址栏输入无参数的 /pair 路径往往会被系统自动重定向回常规应用首页；此时如需为该浏览器替换配对授权，必须使用该版本特制的完整配对专用链接。

这类配对链接往往直接内嵌了一次性鉴权凭据，严禁将其粘贴到公开聊天群、截图或公开发布的文档中，仅应在受信任的目标终端私密打开。由于不同软件版本对路由与配对凭据的处理逻辑有所演进，请务必以具体版本的文档为准，切勿将某一版本的行为视作永久不变的约定。

能看到会话，不代表能审批

在初始测试中，我们在浏览器端接入了一个仅拥有只读权限（read-only grant）的授权身份。此时在前端界面中虽然能清晰实时看到执行器正在发起的命令细节，但底部的 Approve 按钮却呈现不可点击的灰色禁用状态。直到由人类为该浏览器单独补全了经过获准的操作权限（operate grant）之后，审批按钮才恢复可用。

这提醒我们：VPS 客户端提交任务的权限，与浏览器端批准命令的权限是两套完全独立的授权实体。 切勿将两端的 Access Token 混用，也不能想当然地以为只要能够“观摩”会话就必然具备“执行/审批”的处置权。

独立网页里的会话，不会出现在原桌面

前文提到，我们在 Mac 上采用的是完全平行的独立后台服务，它拥有自己独立的数据持久化路径与状态数据库。虽然它与你的日常桌面客户端运行在同一台物理 Mac 上，但二者底层的数据集完全物理隔离。

因此，通过 VPS 调度的任务只会实时呈现在对应测试端口所服务的 Web 界面中；在原有的桌面应用里苦等界面刷新或盲目排查“丢失记录”，只是徒劳无功。我们并未升级桌面客户端，也未对会话数据库执行任何跨版本迁移或双向同步。

新设备应该配置哪一层？

当需要向你的私有拓扑中加入新设备时，应当根据其承担的系统角色，精准配置必要的权限层次，切忌一刀切地全盘克隆：

新设备角色	必须配置的核心项	严禁复制或无意义照搬的项目
新电脑上的 Codex（仅需 SSH 到 VPS 运维）	Tailscale 网络互通、该机独立生成的专属 SSH 密钥对、VPS 用户与 authorized_keys、严格核验主机指纹	T3 服务端环境、开发电脑上的模型凭据
新增的工作区执行机（承接任务的 Mac / 工作站）	Tailscale 接入、匹配版本的本地服务、本地运行的执行器与环境登录、本地真实项目路径绑定、独立应用授权	原 Mac 的本地路径、私钥文件、旧服务的状态数据库
移动设备（如 Android 手机，仅用于查看状态与审批）	Tailscale 移动端入网、能访问受控服务端口的浏览器、独立完成的浏览器配对授权	SSH 守护进程、私钥、Codex CLI 工具链

这里还需要特别强调物理设备的运行状态限制：手机或移动端在当前阶段只是后续架构演进的预期方向，绝不能等同于已经完成实体机 QA 的成熟能力。 此外，当执行机处于睡眠、待机、关机或网络脱机状态时，云端的 VPS 无论性能多强，也绝不可能凭空唤起或使用它的本地计算资源。在计划将此类架构投入长期日常使用之前，必须专门针对主机休眠策略、网络保活与重连、长任务异常中断的恢复、授权令牌的主动注销以及测试服务的生命周期清理等环节进行系统性的可靠性演练。

安全边界比“连上了”更重要

构建跨网络与跨主机的 AI 智能体体系，最核心的考量绝非“链路是否通畅”，而是安全防线是否清晰、可控、可收敛。推荐在架构设计中始终保持以下四层相互解耦的防御边界：

1. 网络与设备准入层：由 Tailscale tailnet 配合严格的 ACL 策略负责。仅允许被信任的设备彼此建立通信握手，阻断任意非授权节点的探测。
2. 应用与服务鉴权层：由底层标准的 SSH 公钥或应用层 OAuth 凭据负责。网络连通仅提供了传输信道，必须凭借精准授予的身份令牌或密钥方能建立会话。
3. 工作区目录作用域：由执行器配置与具体绑定的绝对路径负责。严格限制执行器能触碰的代码与文件目录，坚决防止任意系统级路径穿越。
4. 运行时动态命令审批：由人在回路（Human-in-the-loop）的强制机制负责。即便具备写入或操作权限，高危命令依然必须经过人类的实时审视与手动确认方可下发执行。

在客户端软件设计上，长周期运行的后台调度进程在遭遇网络超时等异常时，必须从协议层面严格区分“请求尚未送达提交失败”与“任务已在本地开始执行但网络暂时未读回结果”这两种状态，避免因盲目的网络超时重试而导致任务被重复下发、甚至触发冲突性操作。同时，两台机器上的私钥、Session 凭据与内部状态应各自闭环保留在各自的存储介质中。未来在需要收回权限时，也应做到精准撤销——明确区分是阻断 Tailscale 网络准入、在 VPS 上移除特定的 SSH 公钥，还是在服务中撤回特定的应用级 OAuth 授权。

从哪里开始最划算？

面对不同的需求层次，最具性价比的推进路径应该是逐步演进、由简入繁：

• 如果你当下的诉求，只是想借助本机的 Codex 更优雅、安全地管理云服务器：建议直接采用普通 SSH 方案，利用 Tailscale 私网配合专用的普通用户和严格核验的公钥，完成上述只读命令探测。这套方案成熟稳定，不需要额外引入复杂的中间件服务。
• 如果你确实需要构建“云端常驻分发、本地安全工作区执行、可视化监控与人类闭环审批”的高阶工作流：建议先在完全隔离的测试端口与沙箱目录中评估应用级会话协议，切勿在尚未跑通全套异常流程之前，贸然侵入或迁移你日常工作的生产桌面环境。

如果你已经在使用 DeepSeekBot，建议进一步查阅官方的能力说明与安装指南，以便精准区分当前生产版本所具备的稳定功能与本次前沿探索性实验的技术分界。轻量级小 VPS 与高性能开发机确实可以通过精巧的架构设计各展所长，但在把这条远端工作区调度链路正式接入你的日常生产 Bot 之前，依然需要针对具体业务场景完成独立的安全加固与可靠性验收。

参考

• Tailscale：普通 SSH over Tailscale
• Tailscale SSH：独立 SSH 功能与访问策略
• Tailscale Serve：私网服务入口
• Tailscale：添加设备
• T3 实验版本源码
• 真实 VPS 到 Mac 的完成记录