AI Agent 把笔记本拖慢了怎么办？Rig 用云桌面隔离每个开发分支
同时让几个 Claude Code、Codex 或 OpenCode 任务运行时，真正吃掉笔记本资源的往往不只是 Agent：每个分支还要启动开发服务器、浏览器、测试进程和一整套 CLI。Rig 的思路很直接：每个开发分支对应一个云端 Linux 桌面，本地只保留 Agent，代码执行、浏览器和测试都在远端完成。
Rig 是一个 MIT 许可的开源项目，命令行包发布为 @shadowwalker2014/rig。它基于 E2B 云沙箱，云桌面空闲 15 分钟后暂停，README 声称唤醒约需两秒。这里的重点不是“把终端搬到云上”，而是给每个 Agent 一台可暂停、可接管、带浏览器的独立工作机。
它解决的不是单纯的远程开发
传统远程开发通常围绕一台长期运行的服务器；Rig 更像是按分支创建短生命周期工作区。rig up 会为当前分支创建 box，复制代码、安装依赖并启动开发服务器；本地修改后用 rig sync 推送，测试则通过 rig exec 在云端执行。
浏览器也属于同一个工作区。Agent 可以使用 rig browser 驱动已登录的 Chrome，开发者则用 rig desktop 打开桌面，在需要输入验证码或完成登录时接管。完成配置后，rig save 可以把一个已设置好的桌面保存为默认模板，让之后创建的 box 继承工具和登录状态。
这套模型尤其适合三个场景：并行跑多个前端分支、需要真实浏览器验证 UI 的 Agent 任务，以及本地内存有限但又不想牺牲每个任务独立性的开发环境。
安装与初始化
README 给出的前置条件是 Bun 1.2+ 和 E2B 账号。先安装 CLI：
npm install -g @shadowwalker2014/rig rig help
然后登录并构建一次基础镜像：
rig login rig image build rig doctor
rig login 用于配置 E2B 密钥；在 macOS 上密钥可交给 Keychain 处理。非 macOS 环境可以把密钥放入 ~/.config/rig/.env，变量名是 RIG_E2B_API_KEY。不要把它复制进仓库或写进 Agent 会读取的项目配置。
在项目目录中，最小工作流如下：
cd my-repo rig up rig sync rig exec -- bun test rig browser rig shot
第一次执行 rig up 时，Rig 会运行初始化流程，检测包管理器、开发命令和端口，并询问是否复制诸如 .env.local 这类被 Git 忽略的文件。rig shot 可将云端浏览器画面保存到本地，适合让 Agent 或开发者检查 UI 结果。
MCP 和浏览器登录要谨慎
Rig 还提供 rig mcp，让 Claude Code 使用截图返回的原生工具执行计算机操作。它的优势是 Agent 不只读 DOM，也能看到完整屏幕；但这也意味着登录态和浏览器权限必须单独治理。
项目提供了 Cookie 推送命令：
rig cookies browsers rig cookies sites --from chrome rig cookies push --site github.com,linear.app
默认推送会排除银行和支付网站；--all 才会包含它们，并且需要在终端确认。更重要的是，Cookie 值不会打印，传输也不是把明文写进仓库。对 Google 等不接受跨机器登录的站点，应该在 rig desktop 中手动登录，再用 rig save 保存桌面。不要把已登录的 1Password 保存进模板，否则云端桌面可能持有过大的凭据权限。
什么时候值得用 Rig
Rig 的价值在于把“Agent 编码、服务运行、浏览器验收”放进同一个可复现边界，而不是单独提供一个远程 Shell。它适合需要并行工作区和浏览器闭环的个人开发者；如果只是偶尔运行一条测试命令，直接使用本地容器或现有 CI 可能更简单。
采用时建议从一个低风险仓库开始：先验证 rig up 的依赖安装和端口检测，再验证 rig sync 的增量更新，最后才迁移 Cookie 或部署凭据。云桌面隔离了进程和文件，但不能替代最小权限、密钥轮换与人工确认。对 AI Agent 来说，最可靠的远程环境不是“完全放权”，而是让每个分支都有清晰的边界、可暂停的运行成本，以及随时能被人接管的屏幕。
相关链接