ARTICLE · 1090771
合上笔记本,AI 编程助手继续通宵干活
AI TOOL · 一条龙拆解 ｜ 每小时 0.14 美元起 · 5 档规格 · 单次最长 24 小时
PART 01 · BACKGROUND · 先说一个尴尬的场面
你有没有为了让 AI 把活干完，把自己变成了看护工？
我干过。一个跨几十个文件的重构丢给 agent，它开始干活了。我十分钟去看一次进度，因为我知道接下来会发生什么：只要我把笔记本盖子合上，它就停在那儿——不是报错，也不是退出，就是停在「正在读取文件」，像被按了暂停键。第二天早上我打开，它还在那一步。
所以我不敢合盖。吃饭没合，洗澡没合，睡觉合了，代价是第二天重跑。
问题不在模型。现在的模型已经能一口气干几个小时的活，是笔记本不配。笔记本是给人设计的：人要睡觉所以盖子会合，人要省电所以电池模式会降频，人要挪窝所以网会断。这三件事对一个跑 30 秒的任务毫无影响，对一个跑一整夜的任务全是致命伤。
Docker 给这个功能的理由就一句话：开发者已经在并行跑多个几小时的任务了——「一次跑十几个，每个 5 小时、10 小时、21 小时，谁都不盯着」。
这就是今天要聊的事：Docker 把 AI 编程助手的工位，从你的笔记本搬到了云上。
合上盖子，跑到一半的助手就僵在那里
PART 02 · WHY · 为什么非搬不可
先看一组没法反驳的数字。
据公开报道，JetBrains 今年对 1.5 万名以上开发者的调查里，90% 每周至少用一次编码智能体，68% 每天用。但同一份调查里，对 AI 准确性的信任度一年内从 43% 掉到 29%，主动不信任从 31% 升到 46%。
翻译一下：用的人越来越多，信的人越来越少。
这个组合会直接导向同一个动作——盯着。因为你不敢不看。而「盯着」这件事，恰好跟「让 agent 跑一整夜」是矛盾的：你要么守着笔记本，要么放弃长任务。
于是就有了那个荒谬的中间态：白天拿 agent 干些几分钟的小活，晚上让它闲着。等于花大价钱买了辆车，只在小区里倒车。
Docker 的判断是这条路已经走到头了：agent 的任务时长从几分钟涨到几小时，而你的笔记本还是按「人要用它」来设计的。
PART 03 · WHAT · Docker 做了四件事
SKILL 1｜把 agent 关进一间独立的屋子
每个云沙箱是一个 microVM：自己的内核、自己的 Docker daemon。
这句话的技术含量在于，它不是「容器式沙箱」。容器共享宿主机内核，隔离的是进程；microVM 有自己的内核，隔离的是整台机器。Docker 总裁 Mark Cavage 的说法很直白——容器不是为 AI agent 需要的那种隔离级别设计的。
实际用处：agent 可以在里面随便装包、跑命令、起容器、把环境搞乱，只要那东西不在你开的窗口里，它就碰不到你宿主机上的文件。
每个助手一间自己的屋子，连地基都是独立的
SKILL 2｜一条命令，来回搬
sbx move my-project --to cloud反方向是 --to local。
这是整个功能里最实用、也最容易误会的一条：搬的是文件系统快照，不是活的进程。 跑到一半的东西过不去，到对面是重新起。
所以正确的用法是：本地把任务跑到一个干净的节点（比如前几个文件已经改完、测试能过），再搬；别在它正在写文件的时候搬。
Docker 自己的说法是，这是给「白天在本地起个头，收工前推到云上」这种节奏准备的。
SKILL 3｜钥匙不给它，它偷不到
这是我觉得设计上最聪明的一处。
沙箱里的密钥（模型 key、第三方 token）不是塞给 agent 的，而是存在外面，由一个代理在每次请求时注入。官方给的理由：一次提示词注入偷不走 agent 从来没有过的钥匙。
配套的还有两个：MCP 服务器配一次，所有 agent（本地、云上、别的客户端）都能过一个网关连上；网络策略单独管，明确限制 agent 能访问哪些端点。
SKILL 4｜价目表
按秒计费，暂停不收费。
注意两件事：
默认跑一次最长 1 小时，可以设到 24 小时。到期后能恢复的会被挂起，不能恢复的直接删。 这个价格不含模型费用——模型 key 是你自己带的，token 钱另算。
粗算一下：默认规格跑一整夜 8 小时，大约 1.12 美元。顶配跑满 24 小时，大约 27 美元，还不含 token。
除了钱，还有两个数字值得记住：新账号有限时 250 美元额度；本地沙箱免费，而且不需要 Docker Desktop。
门槛是 sbx 0.45.1 以上版本加 Docker Personal 或 Pro 的按量套餐，装法就一行：brew install docker/tap/sbx。
从一核两 G 到十六核三十二 G，都按秒数钱
PART 04 · CASE · 一个夜里跑的活该怎么串
下面这套流程是按官方文档和定价推演的，不是我实测的账单，你先看结构。
CASE 01｜把一整夜的重构搬上云
需求：一个跨 40 多个文件的重构，本地估计要 6 到 8 小时；笔记本合盖就睡；人不想整夜守着，也不想整夜开着笔记本。
方案：
本地起沙箱，让 agent 先跑前几个文件，确认方向没跑偏、测试能过 sbx move my-project --to cloud搬上去，用默认的 Small 规格 合盖走人；第二天 sbx move my-project --to local搬回来，看 diff
输出：一个跑完的分支、一堆能 review 的 diff、一张几美元的账单。
关键在第一步：先本地验证方向，再搬上云。 反过来做，你会在第二天早上收到一份跑得非常认真、但方向全错的结果——而它为此跑了 8 个小时。
PART 05 · LIMITS · 它没解决什么
不能只讲好处。这个发布在 Hacker News 和 Reddit 上被挑得很准，我把最硬的两条摆出来。
第一，沙箱解决「跑在哪」，不解决「能不能碰」。 反驳者的意思大致是：一个有用的 agent 总得连 PyPI、Docker Hub、Hugging Face 这些外部服务；它完全可以老老实实待在沙箱里，然后把这些服务搞坏。隔离的是你的机器，不是外界。
第二，有人觉得沙箱这个抽象太粗。 更彻底的主张是「对象能力」（object capabilities）——精确到「这个 agent 能碰哪个对象、用什么方式碰」，而不是「能上网或不能上网」。这一派认为传统沙箱不是正确的抽象。
还有四条使用上的实话：
搬的是快照不是活进程，搬的时机得自己规划 本地和云的凭据、网络策略是分开管的，搬过去要重新配 云沙箱碰不到你本地的路径和硬件——要在本地用 GPU 的，还是得在本地跑 企业级的集中治理（跨机器统一下发策略）官方说后面才来
PART 06 · SUMMARY · 一句话结论
这个功能不是给所有人用的。
如果你的用法是「让 agent 改两个文件、跑一下测试」，那你不需要它，本地够用，一分钱不花。
但如果你已经出现过「因为不敢合笔记本，所以放弃了一个长任务」，那这笔账没什么可算的：每小时 0.14 美元，换回你合上盖子的自由。
适合的场景：
跨多个文件的重构、批量迁移、跑一整夜的测试补齐 同时并行跑好几个长任务（本地跑两个风扇就开始尖叫了） 想让 agent 的权限边界写进配置文件，而不是靠口头约定
不适合的场景：
需要本地硬件（GPU、外设）的任务 几分钟就完事的小改动 想省 token 钱的——它省的是你的机器和注意力，不省模型账单
参考资源：Docker Sandboxes 文档在 docs.docker.com/ai/sandboxes；沙箱权限规范 Kits v3 已按标准 OCI 镜像格式提交给 CNCF，想做厂商中立权限标准的可以跟一下。
最后说句实在的。工具一直在换，但你要盯的东西没换过：把活交给机器的那一刻，你得知道它跑在哪、能碰什么、跑砸了谁来收拾。 沙箱只把第三个问题的答案，从「不知道」改成了「合上盖子也行」。
这个号只写我上手过、也敢下判断的 AI 编程工具。觉得这篇有用就点个关注——下次你踩到同类坑，至少知道该翻哪一篇。