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

Fri, 11 Sep 2026 09:00:00 +0800

想象一个场景：你在机场，登机口开始广播，于是合上笔记本的盖子，拎起包走向登机口。但就在盖子合上的那一瞬间，那个已经跑了 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。

远程开发 on Codexer

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

为什么托管产品救不了你