−25%

Windows 按年付费,截至 10 月 31 日。 查看套餐

EQVPS
开始使用

用于代码审查和 PR 检查的沙箱:批准之前先证明补丁有效

读 diff 只能知道补丁声称做了什么,运行它才知道是不是真的。把 pull request 拉进一次性 microVM,在修改前后复现 bug,跑测试,用证据做审查——每次大约半美分。

diff 显示的是补丁声称要做什么。它不会显示 bug 是否真的消失了、某个 if 的新分支是否会被执行,或者依赖升级是否会在全新安装时破坏 import。审查者都明白这一点,所以很多审查都以“LGTM,前提是测试通过”结束。

对于 AI 编写的补丁,这个缺口更大。模型能很快写出看似合理的代码,而看似合理恰恰最容易从疲惫的审查者眼皮底下溜过。便宜的解决办法是在任何人批准之前先运行这个改动——在一个它伤害不到任何东西的地方。

检查:base、head、测试

补丁能提供的最有说服力的证据,是一个在旧代码上失败、在新代码上通过的复现。沙箱把它变成一段 20 行的脚本。沙箱是一台 Firecracker microVM,内置 Python 3.12、Node.js 22、git 和 curl,大约一秒启动:

import os
from eqvps import Sandbox

REPO, BASE, HEAD = os.environ["REPO_URL"], os.environ["BASE_SHA"], os.environ["HEAD_SHA"]

def repro(sb, ref):
    sb.exec(f"cd /root/app && git checkout -q {ref}", timeout=55)
    return sb.exec("cd /root/app && python3 /root/repro.py", timeout=55).exit_code

with Sandbox.create(tariff="standard", ttl=1800) as sb:
    sb.exec(f"git clone -q {REPO} /root/app", timeout=55)
    sb.exec("cd /root/app && pip install -q -r requirements.txt", timeout=55)
    sb.upload("/root/repro.py", open("repro.py").read())
    before, after = repro(sb, BASE), repro(sb, HEAD)
    tests = sb.exec("cd /root/app && python3 -m pytest -q", background=True).wait()
    print(f"repro on base: {before}, on head: {after}; tests: {tests.state}, exit {tests.exit_code}")

repro.py 是 bug 报告里的代码片段。如果它在 base 上以非零状态退出、在 head 上以零退出,说明补丁确实修复了它声称修复的问题。把这一行连同测试摘要作为评论发到 pull request 上,审查者就能从事实出发。

测试套件作为后台任务运行,因为单条同步命令会在 55 秒时停止。30 分钟的 TTL 限制了卡住的运行最多能计费多久。

会运行代码的审查智能体

同样的思路也适用于 AI 审查者。通过 MCP 服务器连接后,智能体拥有沙箱工具:创建沙箱、执行命令、上传和下载文件。它不会写“这可能破坏与 Python 3.8 的兼容性”,而是拉取分支、运行代码、引用 traceback——或者报告一切正常。

给这样的智能体设置消费上限和只读 token,并决定它可以不经询问调用哪些工具。MCP 安全防护按风险列出了每个工具。

选哪个套餐

仓库套餐典型一次大致费用
小型库,纯 Python 或 JSsmall(0.5 vCPU,1 GB)2 分钟$0.0011
带测试套件的 Web 应用standard(1 vCPU,2 GB)5 分钟$0.0055
原生扩展、需编译的依赖plus(2 vCPU,4 GB)15 分钟$0.033

临时沙箱按秒计费,最少 60 秒。如果审查者想在几天内反复回到同一个环境,就把它创建为 persistent:它会保留磁盘最多 30 天,按每个开始的小时计费,所以为两天审查保留的 standard 沙箱约 $3.17。pull request 合并后就删除它。

值得了解的限制

  • 每个账户同时两条命令。 对于一个接一个进行的审查来说足够了。如果同时检查几十个 pull request,它们会排队。
  • 没有入站端口。 无法在浏览器里打开应用。在沙箱内启动它,再从第二条命令用 curl localhost 测试。
  • 内部没有 Docker。 需要启动容器的测试应该放在 VPS 上的 runner 中。
  • 出站网络是开放的。 正因如此 pip install 才能工作。不要把任何你不会交给补丁作者的东西放进沙箱。

开始使用

新账户可获得 $1 的沙箱时长,足够在 standard 套餐上做一百多次审查。沙箱页面列出了套餐,SDK 参考包含上面用到的每个方法,5 分钟上手 Python SDK 介绍了配置。

相关阅读:面向完整流水线的隔离 CI 测试运行,以及面向编写代码的智能体的AI 智能体沙箱。

准备好部署了?加密货币付款、无需KYC——约一分钟上线。

立即部署 →

常见问题

这和在 pull request 上跑 CI 有什么区别?

CI 回答的是现有测试是否通过。审查检查回答的是补丁是否做到了它声称的事:在旧代码和新代码上分别运行 bug 报告里的复现步骤,尝试审查者担心的边界情况,并保留一个沙箱供审查者自己探查。两者配合得很好。

AI 审查智能体能用吗?

能,而且在这里收益最大。通过 MCP,智能体获得创建沙箱、执行命令和读取文件的工具。它不再猜测某个改动会不会弄坏什么,而是直接运行代码,并在审查意见中引用输出。

拉取陌生人的 pull request 安全吗?

这正是沙箱的用途。代码在拥有独立内核的单独 microVM 中运行,里面除了你放进去的东西,没有任何属于你的内容。不要传入能写你仓库的 token;私有仓库用只读 token 就够了。

能在浏览器里打开 pull request 中的应用吗?

不能。沙箱没有入站端口,外部无法连入。你可以在沙箱内启动应用,再从另一条命令用 curl 测试;如果审查者需要点击界面,可以把预览部署到 VPS 上。

一次审查要花多少钱?

一次典型的审查——克隆、安装、复现两次、跑测试——在 standard 套餐上需要几分钟,约 $0.005。按秒计费,最少 60 秒,从预付余额扣除。

评论

暂无评论。来做第一个吧。

发表评论

评论在显示前会经过审核。