一次远程接入复盘从保存机器到跑通构建这篇是一份执行记录按真实顺序写从「保存一台机器」到「在远端跑通一次构建」中间哪一步会卡、卡了看什么。所有行为都对应插件文档里写明的机制没有猜测。想先看同类插件清单见 完整插件清单与汉化避坑指南。起点一台能 SSH 的机器前置条件只有三条能 SSH 登录、远端 node ≥ 20.12、远端 dsh 版本不是 0.1.0-rc.6。第二条容易被忽略。dsh 启动要用node:util的parseEnv这个导出从 20.12 才有版本太旧时 npm 只给一个EBADENGINE警告照样装完直到启动才崩在does not provide an export named parseEnv。也就是说装的时候不报错不代表能跑。第三条是 Linux 特有的0.1.0-rc.6 依赖的node-pty1.1.0没带linux-x64预编译产物会报Failed to load native module: pty.node。要 0.1.5-rc.2 及以上。第一步保存机器然后激活在「设置 → 远程工作区」填 host / port / user 和密码或私钥保存。这一步之后什么都不会发生——保存只是备用连接。要让当前会话用上它必须「设为当前」或者让 Agent 调rw_connect。这一步的价值在于remote context 是会话级的只有当前 session 的工作区落在远程镜像里system prompt 才会注入「Remote workspace」段落。复盘里最典型的误判以为保存了就生效然后发现所有rw_*工具都「不工作」。实际上它们工作正常只是当前会话没有远程上下文。第二步体检只读随便点设置页里的「远端 dsh 体检与部署」分两段。第一段是体检探测平台、node、npm、dsh 版本、原生模块能否启动、是否认识--no-open、代理与 npm 源。它不写任何东西。体检报告里最该看的是两项node 版本与原生模块。前者决定能不能跑后者决定 web 能不能起。其余代理、npm 源影响的是「装得快不快」。第三步需要时部署装到私有目录如果体检判定「需要且可以自动装」才出现部署按钮。它把 dsh 装到远端私有目录默认~/.dsh-remote/dsh三个「不」很关键不写系统目录、不改 PATH、不覆盖你在用的版本。因此回滚成本极低删掉那个目录就回到部署前。这也是我建议的方式——不要为了省事把远端系统环境改一遍。默认安装的版本是0.1.5-rc.2README 说这是第一个在 Linux 上能起 web 的版本。如果你远端已经有可用版本体检会判定「不需要装」。部署成功后插件会按机器记住这条 dsh 路径之后连接就用它。这一步省掉了「远端 dsh 不在 SSH 登录 PATH」的麻烦——真遇到这种情况也可以在机器卡片里手动填webAttachCommand的绝对路径。第四步选工作区等镜像建好「Add workspace」弹窗有两个页签本机、远程。切到远程选机器浏览到目录点「设为远程工作区」。这时插件做三件事创建本地镜像目录、让 harness 收养它、把所选工作区持久化到该机器。镜像的位置在$DSH_HOME/remote-workspaces下。到这里DSH 认为这是一个普通本地工作区而文件其实在远端。但镜像此刻是空的或只有目录结构——要rw_sync才会拉内容。第五步同步优先用异步第一次同步建议这样调rw_sync(path/srv/app, asyncTrue)它会返回一个taskId之后查进度、拿结果、取消都行。大目录同步不用异步就会卡在一次工具调用里直到超时。两个默认值要提前知道maxFileBytes默认 5242880050 MB超过的文件会被跳过fileReferenceExcludedDirectories默认跳过.git、node_modules、dist、build、.next等目录。所以「同步完发现少了东西」通常是预期行为不是失败。如果镜像里确实缺目录改$DSH_HOME/remote-workspaces/.dsh-remote-ignoregitignore 语法。第六步执行然后处理冲突rw_exec(commandnpm ci, cwd/srv/app, ptyFalse)commandTimeoutMs默认 20000 毫秒maxOutputChars默认 200000 字符。构建这类长任务要么调超时要么用pty: true让输出流式返回。改完文件要回推rw_push。冲突时插件的行为是跳过并列出绝不静默覆盖手动合并后重试或用forcetrue以一边为准。这条规则在一次复盘里救过一次——本地的临时改动没有覆盖远端别人提交的版本。第七步要远端界面就再开一层如果构建需要看远端真实环境的终端用「远程 DSH 界面」本机 SSH 连过去远端只监听127.0.0.1起dsh web端口经隧道搬回本机 loopback起始 3088。地址带一次性令牌不要外发。「断开」只关隧道不杀远端进程要停进程用「断开并停止远端」且它只结束由本次插件启动的那个。复盘出来的四条结论「保存 ≠ 激活」是这条链路第一个认知门槛也是最高频的「假故障」来源。镜像不是实时的。远端改、本地看中间隔着一个rw_sync。体检值得每次先跑。它只读、免费、能把「版本不对」和「连不上」区分开。回滚成本被设计得很低。私有目录 删目录即回滚这比任何「卸载脚本」都可靠。总结整条链路真正的顺序是「保存 → 激活 → 体检 → 部署 → 选工作区 → 同步 → 执行 → 回推」跳步就会得到看起来像 bug 的结果。更多 DSH 插件的中文说明见 完整插件清单与汉化避坑指南。适合与不适合适合第一次接 dsh-remote、想知道每一步失败面的人要给团队写接入文档的人需要评估「回滚要多久」的运维。不适合只需要跑一条远程命令的人期待开箱即用、不接受手动同步的人远端机器不允许装任何东西的场景。标签dsh-remote、DeepSeek Harness、落地复盘、远程工作区、运维本文由 DeepSeek Harness Hub 自动整理数据来源于插件详情页。