关掉笔记本，代码还在跑：把 AI 编程助手搬进 30 欧元的 Linux 盒子

想象一个场景：你在机场，登机口开始广播，于是合上笔记本的盖子，拎起包走向登机口。但就在盖子合上的那一瞬间，那个已经跑了 40 分钟、眼看就要完成的 build，也跟着你的笔记本一起睡着了。

这种「任务和笔记本绑死」的体验，几乎是每个 AI 编程助手用户的日常。Claude Code、Codex 这些 agent，本质上都是在你的本地终端里跑一个进程。笔记本一关，进程就停，任务就断。

Dan Hopwood 受够了这种生活。他今年频繁在几个城市之间穿梭，于是做了一个干脆的决定：让 agent 彻底离开笔记本，住进一台月租 30 欧元、永远不关机的 Linux 盒子。笔记本和手机，从此只是看它干活的「窗口」。

他在博客里把整套方案拆得很细，连建盒子的脚本都放了出来。我读完最大的感受是：这不止是一篇「怎么搭」的教程，更是一套关于「agent 到底该住在哪里」的思考。

为什么托管产品救不了你#

按直觉，遇到「想在多设备之间无缝切换」这种需求，第一反应应该是用托管产品。于是 Hopwood 让六个研究 agent 并行调研了一圈，把 965 行结论汇总成一份 runbook，结论却高度一致：市面上的打包产品，没有一款能满足他。

问题出在两条线上。

托管 agent 产品的通病，是「一个会话 = 一个仓库 + 一个厂商」。 不管是网页版 Claude Code、Anthropic 的 Managed Agents、OpenAI 的 Codex cloud，还是 Google 的 Jules，都会把一个会话限定在一个 GitHub 仓库、一家厂商的 CLI 上。这对只维护一个代码库的人够用，但 Hopwood 的工作涉及 13 个互相引用的仓库（编码仓库要读知识库，知识库要读规格文档）、16 个 MCP 服务器（用来给 agent 接 Gmail、Linear、Slack 和浏览器）、还有好几家厂商的 CLI 指向同一批文件。没有任何一款产品能「看穿」这种跨仓库、跨厂商的网状结构。

云开发环境的问题则相反，它们天生就是为「关机」设计的。 GitHub Codespaces 空闲 30 分钟就自动停，E2B 把会话硬性限制在 24 小时，唯一肯常驻的 Sprites 要价每月 460 美元。而他真正需要的，只是一台内存翻四倍、月租 30 欧元的普通 VPS。

所以他绕回了那个最古老的答案：一台永远不关机的 Linux 盒子，家里所有的设备都只是接入它的终端。

一个心智模型：盒子为主，设备只是窗口#

动手之前，他先定下一个决定一切的心智模型：笔记本上什么都不跑。 进程树住在盒子上，设备只是随时 attach、随时 detach 的「窗口」。合上笔记本盖子的本质，不是「暂停任务」，而是「摘下窗口」，任务在盒子上照常推进。

这套模型一旦想通，后面的技术选型就水到渠成了。我把他的整条技术栈拆成一张表：

这张表里，每个选型都对应一个具体的痛点：Tailscale 解决的是「别把 SSH 暴露到公网」，mosh 解决的是「网络断了会话别断」，tmux 解决的是「关盖子之后任务别死」。它们不是随便堆砌的工具，而是「盒子为主」这个心智模型在各个层面上的自然落点。

最关键的决定：绝不同步#

整篇文章里，Hopwood 反复强调一个设计原则，我认为这是全篇最有价值的一句话：盒子是主，绝不搞同步。

很多人的第一反应是把笔记本当主设备，再用 Mutagen、Syncthing 之类的工具把盒子「同步」到一致。这恰恰是同步工具翻车的重灾区：两边同时有 agent 在改未提交的文件，冲突、覆盖、丢失，全来了。

他的做法更狠：笔记本上保留一份 checkout，但只遵守一条铁律，「只做 git 托管的活，切设备之前先 commit 再 push」。换句话说，凡是不在 git 里的东西，在笔记本上就等于不存在。

这条规则之所以成立，是因为他几乎所有的工作都已经 git 化了。当「唯一的事实来源」是 git 而不是某个设备的本地文件系统时，同步这个动作本身就消失了，剩下的只是「从 git 里 pull 下来」这一个方向的操作。这比任何同步工具的冲突消解逻辑都干净。

日常怎么用#

搭好之后，日常操作简单得有点无聊。

在笔记本上敲一个 box，就掉回上次离开的那个会话；敲 box fidero-os，就定位到指定项目。手机上通过 t 这个盒子侧的命令进入同一个 tmux 会话，看到的还是那半句没写完的对话。

后台无人值守的任务走 claude agents 这个 supervisor，每个任务跑在独立 worktree 里，任何一台登录的设备都能看到任务队列和 PR 状态。于是 /build 这种长任务不再需要一个专门的 tmux 窗口占着，而「验证能力」这件事，从「只有笔记本开着才能跑」变成了「任何时间都在跑」。

三个没想到#

他把这套方案落地之后，总结了三个和直觉相反的点，每一个都挺值钱。

第一，官方推荐的远程功能，本身还是依赖 tmux。 Claude 的 remote-control 是这套方案里唯一「原生适配」的功能，它能把实时会话投到 iOS App 上。但 Anthropic 自己的文档都要求把它跑在 tmux 或 screen 里，否则连接一断会话就没了。所以它只是「套在 tmux 上的一层手机界面」，不是 tmux 的替代品。至于网页版 Claude Code、routines、--teleport，全都跑在 Anthropic 的机器上，既不支持你的 MCP 服务器，也读不到你的跨仓库依赖。

第二，沙箱只包住了 Bash。 Claude Code 内置的 sandbox 只约束 Bash 工具，MCP 服务器和 hooks 在宿主上是不受约束地跑的。真正起控制作用的不是沙箱，而是权限层：auto 模式、只读工具的 allow-list，以及凡是「发送、删除、发帖」类操作都要过问的 ask-list。他的无人值守任务永远不会用到 ask-list 里的工具，所以能一路跑到底，而任何会触达「另一个人」的操作，都会停下来等他确认。

第三，用订阅登录，而不是 API key。 安全调研一开始建议在盒子上放 API key，理由是条款干净、有硬性支出上限。但这个假设针对的是无人值守流水线。他的场景本质上是「把交互式环境挪到另一台机器」，属于普通个人使用，成本只有零头，而且 remote-control 本来就要求订阅登录。

已知的坑：Codex 和 Gemini 的短板#

Hopwood 很坦率地列了这套方案的三个窟窿，其中一条对 Codex 用户尤其扎心。

Codex 和 Gemini 没有手机端桥梁。 这套方案里，Claude Code 靠 remote-control 把会话投到手机上，而 Codex 和 Gemini 只能走 tmux，没有任何类似的手机桥接。换句话说，如果你主力是 Codex，你依然能在手机上通过 Termius 连进 tmux 会话，但那是一个纯粹的终端，没有 Claude 那种「原生 App 视图」。

另外两个窟窿更通用：.env 这类被 gitignore 的敏感文件不会跟着仓库走，他是一台一台手工拷过去的，重建盒子时这些文件会缺席，除非也搬进 1Password。以及，prompt injection 触达「能发送」的工具的风险，和在本地上是一样的，护栏也相同：他让 agent 读邮件、扒网页，但只指向具体的线程和发件人，任何发送动作都得他亲手批准。他给自己划的红线是：只有当无人值守任务开始「自己去翻未可信内容、自己挑活干」的那天，才需要给每个任务加一层真正的容器隔离。

我的看法#

这篇文章的价值，不在于那套具体的技术栈，因为 Tailscale、mosh、tmux 都是老熟人。真正值得记住的是它逼我们回答的一个问题：当 agent 开始替你长时间干活，它该住在哪里？

过去我们默认 agent 住在「我面前这台机器」上，因为编程就是「我盯着屏幕，机器执行」。但当 agent 的一次任务要跑 40 分钟、甚至要跑一整夜时，把它绑在一台会关机的笔记本上，就成了一种自我设限。

Hopwood 的答案是「让它住在云端的一台常驻盒子里，设备只是窗口」。这个答案未必适合所有人，它假设了你有频繁移动、跨设备接续、长时间无人值守这些需求。如果你一天到晚坐在同一台台式机前，这整套东西的收益就大打折扣。

但它至少提醒了一件事：AI 编程正在悄悄改变「编程发生在哪里」这个前提。当 agent 能连续工作好几个小时，甚至在你睡觉的时候接着写，那么「设备」和「任务」之间的强绑定，就该被重新审视了。你可能不需要立刻买一台 30 欧元的盒子，但至少该想想：你的 agent，现在是不是也跟你的笔记本盖子绑在了一起？

参考来源：Running coding agents on a €30 Linux box，作者 Dan Hopwood