wtf 是 Crabbox 以及它如何让你多提交 10 倍 PR

我以前同时只能管理 2 到 3 个 Claude Code 会话。从今年四月开始，这个数字迅速增长，尤其是在我们搭建了循环（loop）之后。现在任何时候，我至少有 5 到 10 个会话在并行运行。其中大多数我从未直接提示过：它们来自循环，自行发现问题、接手工作、验证更改并打开 PR。实际上，Peter Steinberg（openclaw 的作者）从 2026 年初就开始这样工作了。

这样会生成大量以前不可能实现的 PR。但它也带来一个新问题：每一个 PR 都必须经过审核并交付给真实用户，而且每一个都有破坏某些东西的风险。因此瓶颈已经转移。

瓶颈不再是写代码，而是将代码合并到代码库中。

这篇文章介绍的是解决这个问题的工具部分，以及 Peter 的新副业项目 Crabbox 是如何解决它的。

代理需要自己的盒子来验证工作

现在常见的做法是让一个代理生成一个子代理，用 Playwright CLI 测试工作，并记录证据：一张截图，或整个流程的视频，附加到 PR 上。这样才能让代理的工作易于信任和合并。我不再需要相信它的话，而是可以看到它工作。

当我运行 3 或 4 个代理时，这还行。但一旦有了多个并行会话，很快就会出问题，因为它们最终会在同一个环境中测试，互相冲突。

为了验证，每个代理需要开发服务器真正运行在自己的代码上。即使你给每个 ticket 分配自己的 git worktree，那也只是隔离了写代码。在本地多次运行应用，无法扩展：

• 端口通常是硬编码的（有充分理由）。第二个实例无法启动。
• 一台笔记本只有一个 Docker 守护进程、一个数据库、一个操作系统。每个“隔离”的会话都在暗中共享它们。一个代理尝试新 schema 可能会立刻破坏所有其他会话。
• 真实的生产栈也会消耗内存和 CPU。五个这样的栈根本装不下。

唯一能扩展的做法就是停止在单台笔记本上运行所有东西。

每个代理应该获得云上独立的隔离环境：自己的机器、自己的数据库、自己的开发服务器。这些沙盒互不干扰。

@SToneoneX 实际上为我们的平台 @SuperDesignDev 手工打造了一个版本，效果神奇。我们在 Fly.io 上运行：一个 Firecracker VM，内部包含完整栈（通过 docker-in-docker 的本地 Supabase、Redis 和开发服务器），从带有持久卷的基础镜像启动。我们添加了一个机载编排器来启动所有服务、一个 CDP 浏览器来驱动它、支持挂起和恢复（盒子在约 3 秒内热恢复），还有一个空闲监控器，45 分钟后自动关闭，这样我们永远不会为别人忘记停止的盒子付费。这解锁了很多能力。

但它仍然有一个尖锐的问题：要让代码进入盒子，它通过 git fetch 从 GitHub 拉取分支。你必须先推送。未提交的工作区更改根本无法验证。所以当代理在盒子上测试、发现 bug、并在本地机器上修复后，你就卡住了。你本地有一个脏文件，而盒子只知道已经推送的内容。正常的提交、推送、CI 流程在这里表现得不好。你的仓库会充满垃圾提交。你也不希望每次都从头重建盒子。

你真正想要的是简单的。

进行更改，并在几秒钟内重新测试。

这就是我们看到 Peter 的新副业项目 Crabbox 的地方：https://github.com/openclaw/crabbox

Crabbox 的工作原理

Crabbox 让代理预热云上的一个盒子，同步本地工作树中的脏 diff，并实时运行测试。三个命令：

1. crabbox warmup 启动一个盒子。 2. crabbox run -- <command> 运行任何命令，就像在本地一样，但在云盒子上执行。每次运行前会先同步你机器上的 diff。你甚至不需要提交。只要文件夹已初始化 git，它会同步所有未提交的更改，然后运行。 3. crabbox stop 关闭盒子并删除它。

这就是整个循环。代理完成任务后可以：预热，运行 setup 安装依赖并启动开发服务器，运行测试或自己驱动 Playwright，如果遇到 bug，在本地修复并再次运行。最新的更改会自动同步，所以总是测试最新版本。然后停止。

“在本地修复，重新运行，最新更改自动同步”这部分是关键。没有垃圾提交，没有盒子重建，你总是在几秒钟内测试最新版本。

设置只需要三个文件

• 一个 Dockerfile，封装了本地机器上的一切：Node、包管理器、任何 CLI（我的情况是 Supabase CLI）、一个浏览器。你可以提示代理写出这个文件。
• 一个 .crabbox.yaml。这是每个 Crabbox 命令的配置。它定义了沙盒提供商、要跳过同步的文件以及要转发的环境变量。
• 一个 setup.sh，这样代理可以运行一个脚本来启动整个开发服务器，而不是手动一步步执行命令。

关于同步排除：通常你不需要列出 node_modules、.next 或 .env*，因为它们已经被 .gitignore 忽略了。真正的价值是排除你不需要在盒子上保留的沉重文件夹（我的有一个 evidence 文件夹）。你列出的环境变量会通过加密的 SSH 连接直接推送到盒子上。它们从不经过代理，也从不写入同步的仓库。相对安全。

整个东西就是几个文件。这就是让任何代理能在隔离的云盒子上验证代码库所需的全部足迹：cbx.sh 是一个小的便利工具，它将预热和轮询的流程封装成一个命令。而技能则让我只需说“通过 Crabbox 测试这个”，代理就能自行知道整个流程：预热盒子，运行 setup，驱动 Playwright，带回证据，停止。上面三个文件完成了真正的工作。cbx.sh 就是全部的更改。应用本身保持不变。

获取证据

Crabbox 提供了很好的原语来获取证据：

• 任何运行中的 --artifact-glob 会在命令完成后自动下载匹配的文件。当代理编写了一个生成视频或截图的 e2e 脚本时，这很有用。文件会自动回到你的机器上。
• crabbox artifacts collect 截取盒子屏幕的截图。
• crabbox artifacts video 对会话进行屏幕录制。
• crabbox artifacts publish 直接上传到你的 S3 存储桶，这样你就可以将图片或视频以内联方式放入 PR 评论中。

一点来自经验：哪些可用取决于提供商。最后会更多说明。

一个值得了解的标志：--no-sync

默认情况下，每次 crabbox run 都会先同步你的脏 diff 到盒子上。这才是重点。但有时你并不想这样。当命令只是读取或驱动一个已经包含你代码的盒子，并且自上次运行以来没有做任何更改时，使用 --no-sync：

• 读取文件、查看日志、检查状态
• 在盒子中驱动 Playwright CLI（你正在测试已经在那里的代码，你不想每次点击都重新上传）
• 轮询长时间运行的命令，中途重新同步可能会覆盖正在运行的文件

经验法则：当你更改了代码并想测试新版本时进行同步。对于任何只是读取或驱动正在运行盒子的操作，使用 no-sync。

/Crabbox-setup 技能

我将所有这些打包成一个技能：Crabbox 测试套件，以及它连接的更广泛的代码库工具。它是开放的，你可以在这里获取：https://github.com/AI-Builder-Club/skills

指向你的仓库，它会根据你的技术栈生成上述组件（Dockerfile、.crabbox.yaml、setup.sh 以及 crabbox-test 技能）。如果你想看完整的步骤说明，我们还有逐步的工作坊，深入探讨这如何融入在 @aibuilderclub_ 运行复合循环。