前几天刷到 OpenAI 的 Dots 时我第一反应不是“又多了一个新玩具”而是想起上个月凌晨两点半那件事。那晚我让一个 Agent 跑长编译等不了合上笔记本去睡了。第二天开会前打开电脑任务停在半小时处进度全丢。没有后台执行没有远程重连笔记本就是那段任务的“容器”合上它任务就跟着“断电”。所以看到“Dots自带云电脑合上笔记本也能继续工作”这句话时我几乎是一下子就理解了它想解决什么问题。简单说Dots 把执行环境从你手边设备里挪走放到云端一个持续运行的“电脑”上。你的笔记本只承担输入输出真正干活的是云端那个环境。这篇文章不会给你复述一份官方功能清单因为目前能看到的资料也确实不完整。我会从“合上笔记本为什么是个高频刚需”切入拆一拆云电脑和本地开发的关系再给一套自己也能模仿的工作流最后聊一聊成本和边界。如果你已经在用云主机跑任务或者正准备把 Agent 类工具迁移到云端这篇应该能帮你省下不少试错时间。1. “合上笔记本”为什么是刚需Dots 要解决的那类痛1.1 一段我自己经历的最典型翻车现场事情的经过其实很普通白天我把一个数据清洗脚本拆成了几个阶段先做特征提取再做样本过滤最后跑一轮回归验证。单看每一步都不慢但全量数据一跑半小时打底。那会儿已经夜里两点我不想盯着日志干等就把笔记本盖子合上了。问题就出在这个“合上”的动作上。绝大多数操作系统在笔记本合盖后的默认行为是休眠或睡眠进程会整个冻结。你以为它在“后台运行”其实它只是暂停在某一行代码上。第二天我重新打开电脑日志下面出现的是“已中止”前面半小时的计算不但没成果连断点续跑的入口都没有。那是我第一次觉得本地作为执行环境这件事在长任务面前真的太脆弱。后来我查过设置。合盖不操作、电池供电不休眠、外接电源时禁止休眠这些都改过一遍但笔记本的内置电源策略还是会在一段时间后介入。更重要的是就算不触发休眠合上盖子的电脑也可能因为散热、唤醒、系统更新等原因重启。本地跑长任务本质上就是拿一台随时可能“失去意识”的设备当生产环境。1.2 “自带云电脑”的翻译把笔记本从执行环境变成遥控器Dots 这句宣传点最打动我的是“自带云电脑”这五个字。按我的理解它意味着 OpenAI 在尝试改变一个默认前提任务不一定非要运行在你手边的这台机器上。台式和笔记本的价值从此可以拆成两块——一块负责和人交互一块负责长期执行任务。这有点像本地文件存储和网盘存储的区别。本地文件存在自己的磁盘里电脑坏了文件可能跟着遭殃网盘里的文件换任何一台设备都能接着往下用。Dots 做的就是把“任务执行”也变成网盘里的东西。你人在办公室笔记本合上云端那台电脑还在继续跑模型、跑测试、跑 Agent。等你回到家里打开 iPad 或台式机直接同一个环境继续看。我觉得这个方向的意义不在于“远程桌面”这个功能本身而在于它把开发者的工作模式从“带着电脑跑”变成了“带着窗口跑”。你不需要把计算资源、依赖环境、运行状态都塞进背包只需要一个能打开窗口的设备。1.3 哪些人会对这个功能“一眼爱”我身边已经有几类朋友提前兴奋起来了。第一类是跑 AI Agent 长任务的人。现在很多 Agent 任务已经不是“点一下按钮三秒出结果”那种而是要在一个工作区里反复修改代码、执行命令、看测试反馈跑个十几分钟都很正常。这类人最怕电脑中途休眠最需要 Dots 这类常驻云环境。第二类是经常通勤、开会、跨设备切换的人。白天在公司建模晚上回到家想继续看进度出差路上打开笔记本只想看到“一切正常”的结果而不是“电脑休眠导致任务失败”的提示。对这些人来说云端环境几乎就是刚需。第三类是团队协作者。如果一套云电脑环境是共享的那么多人可以在同一份代码、同一份数据目录上接力操作。你合上电脑同事在另一个城市继续操作中间不用打包同步也不用担心“我改的文件还没推送走”。这种连续感比任何炫酷的功能列表都实在。2. 云电脑、云主机和云端 IDE 到底什么关系2.1 三个概念别搞混聊 Dots 之前先把几个常见词理顺。很多人一听到“云电脑”就想到远程桌面一听到“云主机”就想到服务器一听到“云端 IDE”就想到网页端写代码。它们方向相似但层次不一样。名词核心特征和本地电脑的关系云主机VPS/ECS一台永远开机的 Linux/Windows 远程机器你通过 SSH 登录相当于把“整台电脑的主机”搬到数据中心云端 IDECodespaces 类在浏览器里打开一个完整编辑器运行环境已经在云端本地只剩浏览器几乎不消耗计算资源云电脑DaaS提供完整桌面环境甚至带图形界面可以远程操作本地是一个远程桌面客户端看到的全是云端画面Dots 管自己叫“云电脑”但按照我揣测的产品形态它可能既不是传统的远程桌面也不是单纯的云端 IDE而是一个后台运行环境叠加开发者工作流入口的东西。也就是说它既要有云主机那样“进程不死”的能力又要像云端 IDE 那样方便你随时接入。2.2 从“按需远程桌面”到“程序员的常驻后台”传统云电脑解决的问题是“这台机器不在我手机上但我能拿到它的桌面”。程序员用起来往往很别扭因为你通常不需要桌面需要的是终端、编辑器、正在跑的进程、以及一个不会断的连接。Dots 这类“自带云电脑”的产品真正改变了我理解中的执行模型。本地和云端不再是一份“拷贝同步”关系而是执行现场的转移。代码可以不变但跑代码的“发动机”换成了云上那台始终开机的环境。本地合盖、断网、关机云上进程完全不感知。打个比方这就像叫外卖后你不需要在厨房一直盯着锅厨师是独立在现场干活的。你只需要在手机上看一眼“出餐进度”。本地从“厨房”变成“菜单”菜单可以随便放下厨房时间照走。2.3 为什么 AI 编程代理时代把这一需求推到了前台过去我们说的“后台任务”多半是编译、打包、跑测试这类任务虽然耗时长但逻辑是确定的代码不变结果大概率可以预期。现在不一样了AI 编程代理会自主地“看代码、改代码、跑命令、再看报错”每一步都可能分支整个任务时长经常以小时计。热搜词里有一条和 Codex 安装相关说明已经有很多人开始把 Codex 这类工具装到本机尝试。但本机跑 AI Agent 有一个很现实的问题Agent 正在改文件的时候你合上电脑相当于把一个人的手从键盘上打断。它不会记住你离开后的上下文进程一冻结前面的状态就没了。所以你能看到一条清晰的暗线AI 编程代理需要长期后台运行长期后台运行需要常驻环境常驻环境天然属于云端。Dots 的“云电脑”定位本质上就是给这个需求提供一个官方顺手的外壳。一旦这个模式跑通Agent 就不再受限于“主人是否在线”。3. 自己搭一套“云端后台工作区”的实操路线3.1 先决定你的执行环境放在哪一层Dots 能不能立刻用我还没法替你确认。但如果你是看了这个概念心痒痒其实现在就能用一套并不复杂的方案复刻出八成体验。我自己的路线是这样的本地编辑器负责写代码云主机负责跑任务中间用 SSH 和 tmux 把两者连起来。先选执行环境。我不建议第一反应就去开一台带图形桌面的云电脑编程场景下图形界面的成本很高运维也重。更实用的做法是租一台 Linux 云主机按核数和内存选基础款就行。初期你跑一个 Agent 任务2 核 4G 起步等发现内存不够再升配置。云主机和本地通过 SSH 连接你本地看到的仍然是熟悉的终端和编辑器。如果你有现成的容器平台也可以直接用容器作为执行环境。但容器本身不具备“常驻”属性你仍然需要宿主节点保证它不被打断。因此最稳妥、最好理解的方式还是“一台云主机 一个进程守护工具”。这套组合的可靠程度已经被几十年的服务器运维验证过了。3.2 让进程“断线不销号”的三个工具很多人第一次在云主机上跑任务直接在终端窗口里npm start。这个做法有个坑一旦 SSH 连接断开终端窗口挂掉任务也跟着没了。原因很简单——启动的进程是当前终端会话的子进程终端的宿主管道断了子进程也会收到信号后退出。所以要引入的第一个工具是 tmux 或 screen。它们可以在云主机里开一个独立会话进程运行在这个会话里SSH 断掉也只是断开了“观看窗口”进程本身继续跑。你可以随时重新登录、重新接入日志和上下文都还在。# 创建独立会话 tmux new -s dev # 在会话里正常启动你的服务或 Agent node agent.js # 断开但不结束会话 Ctrlb 然后按 d过几个小时想回去看进度重新登录云主机用一条命令接回去tmux attach -t dev如果你连 tmux 都不想用还有更工程化的方案systemd。把任务包装成系统服务即使主机重启服务也会被拉起。适合那些需要“每天定时跑、跑完自动退出”的稳定任务。[Unit] Descriptionlong-running-agent Afternetwork-online.target [Service] Userubuntu WorkingDirectory/srv/workspace ExecStart/usr/bin/node /srv/workspace/agent.js Restartalways RestartSec5 [Install] WantedBymulti-user.target把上面内容放到/etc/systemd/system/agent.service然后执行sudo systemctl enable --now agent这台云主机就会替你把任务一直养着。优先级上如果你想快速验证思路用 tmux如果你想让它变成可靠的生产流程用 systemd。3.3 最小可复现流程从零在有到一台能接力工作的云主机我把整套流程压缩成五步照着走基本不会跑偏。第一步准备一台云主机。选择哪家并不重要按你已有的习惯来就行。安装系统时优先选 Ubuntu 22.04 或 Debian 12后续文档多、坑少。第二步把本地的 SSH 公钥复制过去。这一步是为了后面不用每次输密码。本地执行ssh-copy-id ubuntu你的云主机IP第三步安装基础环境。Node 建议直接装 LTS 版本Python 看你的项目需要。如果只是跑 Agent 类工具Node 20 LTS 是最稳的。sudo apt update sudo apt install -y tmux git curl curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt install -y nodejs第四步在云主机上把项目拉下来进入tmux会话装依赖并启动。整个操作从本地终端连续敲就行不需要额外工具。第五步按下Ctrlb再按d退出会话直接断开 SSH合上本地笔记本。第二天重新 SSH 登录后运行tmux attach -t dev你会看到日志进度比昨晚推进了一大截。这套流程体验过几次之后你会很自然地对“合盖断任务”这件事产生生理性厌恶。3.4 把本地编辑器和云端目录打通终端是连通了但很多人不习惯完全在命令行里写代码。没关系用 VS Code 的 Remote-SSH 就能把整个编辑器的窗口指向云主机。先在本地给云主机起一个 SSH 别名编辑~/.ssh/configHost mycloud HostName 你的云主机IP User ubuntu然后在 VS Code 里安装 Remote - SSH 插件命令面板输入 “Remote-SSH: Connect to Host”选择mycloud。它会重新打开一个窗口左下角显示“SSH: mycloud”然后你就能像操作本地目录一样打开云主机上的文件夹、写代码、跑终端。文件保存是秒传的因为保存动作直接发生在那台云主机上。如果任务需要在本地浏览器里预览比如调试一个 Web 服务还可以做端口转发。在 SSH 连接后终端里执行ssh -L 8080:localhost:8080 mycloud这样云主机上的 8080 端口就映射到了你本地直接访问http://localhost:8080。你的笔记本此时真的就是一块“遥控器屏幕”。4. 从本地切到云端先处理掉 Codex 安装和依赖的坑4.1 热搜高频报错missing optional dependency 是怎么来的在趋势词里看到一条很典型的报错missing optional dependency openai/codex-win32-x64. reinstall codex: npm in。这说明很多人已经开始在自己的机器上把 Codex 装起来但被平台依赖问题卡住。这个报错背后的机制其实不复杂。npm 有一种依赖分类叫“可选依赖”optionalDependencies通常用来按操作系统和 CPU 架构自动安装对应的二进制包。比如openai/codex-win32-x64这个包名里就写明了目标平台Windows、x64 架构。npm 在安装时应该自动识别当前系统并选择对应包但如果你的安装缓存、镜像配置、lock 文件状态不对就可能出现“主包装好了可选平台包没装上”的结果。从本地切到云端的动作往往会放大这类问题。因为你可能在 Windows 本机上习惯了自动安装成功到了 Linux 云主机上路径、权限、平台解析规则全变样同样的命令就暴露问题。4.2 一套完整的复现与处理流程我用过的处理顺序按成功率从高到低排列先删掉全局 CLI重新安装。Codex 这类工具如果之前装过一次但平台包损坏再跑一遍安装命令不一定能修复。先卸载再说npm uninstall -g openai/codex清掉 npm 缓存里可能存在的旧平台包索引npm cache verify重新安装npm install -g openai/codex如果项目里通过package.json依赖 Codex删掉node_modules和package-lock.json再执行npm install这一步会让 npm 尽可能重新解析所有平台依赖。注意删除 lock 文件会影响整个依赖树版本稳定性项目里还有其他依赖时先备份。 5. 最后检查系统架构是不是确实匹配。在 Linux 云主机上执行uname -mx86 机器看到x86_64ARM 机器看到aarch64。如果你在云主机上用的是 ARM 架构却期望安装x64的二进制包也会撞到类似的缺包问题。4.3 在云端装 Agent 前先确认 Node 版本和 npm 配置另外一个很容易被忽略的坑是 Node 版本。很多 Agent 类工具要求 Node 18 起步推荐 Node 20 LTS。云主机默认源的 Node 版本往往偏旧所以我在 3.3 里特意用了 NodeSource 的安装脚本。装好后先确认node -v npm -v如果node -v输出的版本低于 18后面装任何新工具都容易收到奇怪的引擎兼容提示。不要急着怀疑工具坏了先回头把运行时升级。再检查一个 npm 配置项npm config get optional正常应该是true。如果被设置成了falsenpm 会主动跳过可选依赖openai/codex-win32-x64这类平台二进制包就永远不会被安装。这个开关平时很少有人碰但一旦被某些“性能优化脚本”或者历史迁移改动过就会变成隐蔽的坑。我在排查依赖问题时会把npm config完整看一遍而不是只盯着最后一行报错。4.4 我遇到过的“假成功”场景有一类问题最耗时间终端提示安装成功CLI 也能正常输出版本号但一运行就报“缺少某个模块”。这种多半是二进制包只装了一半npm 把外层命令文件放好了内层平台相关的可执行文件没有落位。检查办法很直接全局安装路径下直接找那个包。Linux 上可以执行npm root -g然后把得到的路径末尾拼上openai看看目录下有没有codex-win32-x64或对应的 Linux 平台包。如果发现其他平台名字的包说明 npm 可能用了错误的平台元数据或者安装过程跨了机器。最笨也最有效的办法就是卸载重来并且保证当前环境中没有npm_config_platform这个环境变量。5. 成本、体验与什么时候别把所有东西塞进云端5.1 算一笔账包月云主机 vs 按量云电脑 vs 纯本地要把工作模式切到云端最现实的障碍往往是成本。但平心而论这笔账不能只看“多花多少钱”还要看“少亏了多少时间”。我按常见配置算了笔方案租赁形式适合场景对你的要求本地笔记本硬件已花钱快速原型、小脚本不能长期合盖跑长任务云主机 2 核 4G包月几十到一百多长任务、Agent、服务端会一点 SSH、tmux 就够高配 GPU 云主机按小时收费大模型推理、训练用完记得释放实例云电脑桌面按小时或套餐图形化操作、临时办公网络要求高如果你每天都离不开 Agent 任务云主机的包月费其实约等于一两杯咖啡。如果是偶尔需要高算力按小时租一台 GPU 机器反而比买本机显卡更划算。关键是你把云资源当成“生产环境”而不是“测试玩具”钱才会花得值。5.2 云上工作流的不适感还是要提前有预期把执行环境搬到云端之后体验不全是变好有几个地方会明显不一样。首先是网络依赖。没有网络的时候你连“看一眼进度”都做不到。高铁穿过隧道、飞机起飞后本地文件还能看着有点安全感云端任务就只能靠信任。我的做法是重要任务必须写日志日志文件本身落在云主机上回来后第一件事看日志而不是凭感觉。其次是输入延迟。编辑器通过 SSH 操作云主机网络好的时候几乎无感网络波动时会觉得光标有点“肉”。写代码时我对延迟比较敏感所以本地编辑器和云端通过 Remote-SSH 连接把大部分渲染放到本地延迟体感会小很多。再有是密钥和访问权限管理。云端环境不能像本地一样“默认可信”代理配置、API Key、Git 凭据都要更小心。我个人会把密钥单独放环境变量文件里不进版本库权限设成 600最小范围暴露给 Agent 工具。5.3 什么情况下我会劝你别急着切到云端不是所有项目都适合上云。我自己的判断标准很简单如果你每天的核心工作是写一个两三分钟内就能跑完的脚本且需要频繁交互修改那本地体验更好云端只会增加操作成本。如果你的任务链路长、一次执行超过十五分钟、运行期间你会离开电脑或者切换设备那云端几乎是唯一正确的答案。还有一种情况要特别注意数据敏感度高的项目。云主机不是保险箱如果你处理的是不可以出内网的数据先问清楚公司制度和安全标准千万不要为了方便直接把数据复制到云环境。工具再顺手也不能拿合规底线换效率。6. 我用云主机的实际体会Dots 或许只是把这件事标准化6.1 本地和云端同步比想象中更重要我折腾云主机一段时间后最大的体会是真正决定体验上限的不是计算规格而是“状态能不能平滑跟随用户”。本地写了一半的代码云端能不能继续云端的运行日志本地能不能便捷查看环境变量、依赖版本、当前分支这些碎片如果不一致每次切换设备都是重新造轮子。所以我习惯把所有工作目录都放在云主机上本地只保留一个和云端同步的编辑入口。这样笔记本丢了也不慌因为你丢的不是工作本身只是一个屏幕。Dots 如果真能把 OpenAI 自己的工具链、云环境和本地编辑器接成一条顺畅的管道这一步的体验会比通用云主机好很多。6.2 对普通开发者别一上来就上高配最后说说我踩过的弯路。第一次尝试云开发时我直接租了一台八核十六G的机器心想反正云端扩展容易结果一个月账单出来吓一跳实际使用率不到百分之十五。后来又遇到一堆平台依赖问题时间全耗在环境迁移上。如果你的目的只是体验“合上笔记本任务继续跑”这个感觉我强烈建议先按 2 核 4G 起步用 tmux SSH 把最小闭环跑通。等你习惯了在手机上打开云厂商的监控页面看任务进度觉得这套模式确实省心再根据任务规格逐步升配。云计算的弹性优势就在于可以循序渐进没必要第一天就把预算拉满。如果以后 Dots 真的把“合上笔记本还能继续工作”做成默认能力那我们这批靠手工云主机折腾出来的人反而会有点怀念在 SSH 终端里敲 tmux 命令的那几天。毕竟理解了底层原理之后无论换什么产品你都不会再被“界面好看”这个表象迷惑而是会直接问一句任务到底跑在哪台机器上
