技术知识库 · 工具评测 · · 国科智飞 Gavin

给 AI 编程代理一台一次性沙箱：clawk 的隔离思路

给编程代理一台一次性 Linux 虚拟机：代理在 guest 里全权运行，宿主机文件与密钥够不着，销毁重建以秒计。

clawk 是 clawkwork 开源的 AI 编程代理沙箱，Apache-2.0 许可，Go 编写。它的口号很直白：给编程代理一台一次性 Linux 虚拟机，而不是你的笔记本。代理在 guest 里以 root 全权运行，宿主机的文件、keychain、密钥都够不着；环境玩坏了就销毁重建。目前支持 macOS（Apple Silicon），Linux 还在 experimental，项目 2026 年 7 月上线，一个月左右积累约 960 star。

这个工具回应的是一类很现实的问题：Claude Code、Codex 这类代理要真正干活，就得装依赖、跑脚本、起服务，还要不要开 --dangerously-skip-permissions？放权怕它删库，不放权它又干不了活。clawk 的答案是把整个工作负载搬进另一台"机器"。

能力与亮点

真 VM 边界，不是进程策略。 对比 Anthropic sandbox-runtime 的进程级防护：策略写错一次，keychain 可能全暴露；装包、起后台服务、嵌套容器这些操作也很难安全放行——你要枚举所有危险的系统调用和路径，漏掉一个就破防。clawk 不赌"策略写得对"，而是用 hypervisor 边界把代理和宿主机隔开：guest 内外是两个内核，guest 里能做什么，和宿主机上有什么，是两个独立问题。

任意 OCI 镜像当 rootfs。 想要完整的 Linux 发行版和项目工具链，直接指定镜像即可；首次启动构建 rootfs，之后秒级启动。不依赖 Docker daemon。

声明式配置 DSL。 一份 sandbox 定义里可以声明 CPU/内存/镜像、网络白名单、端口转发、环境变量、创建时执行的命令，以及给代理的指令。写法接近这样：

sandbox my-project (
  vm ( cpu 4 memory 8GiB image golang:1.25 )
  network ( allow api.example.com )
  forwards ( 3000 )
  env ( DATABASE_URL )
  on create ( "go mod download" )
  agent ( instructions "Ask before running destructive commands." )
)

读一遍就知道这台沙箱的边界在哪——这对团队评审"代理能碰什么"很重要，配置本身就是可审计的文档，比一堆命令行参数好维护得多。

guest 内默认全自主。 rm -rf、装包、绑特权端口随便来，破坏的只是一次性 VM 磁盘；需要保守时用 --safe 降级。

网络白名单与 ssh-agent 转发。 只放行 allow-list 里的域名（github.com 预放行），未知服务器连接直接拒绝；git push 可以通过转发 ssh-agent 完成，但私钥从不进入 VM。

每项目/每工单一沙箱。 多仓库任务用 git worktree + 协调 PR；空闲 VM 自动释放内存、suspend 到磁盘。

环境一次性，对话不是。 Agent 状态（~/.claude/projects、~/.claude/memory、~/.codex）host-mounted 在宿主机上，重建沙箱后 --resume 就能恢复旧对话——这可能是整个设计里最实用的一处：环境可以随便毁，代码和对话不会丢。

破坏自由，本质是把放权成本降到零。 传统工作流里，代理改坏本机环境要花半天恢复；在这里，最坏的结果是销毁重建一台 VM。官方把这条路径做成了常规操作而不是应急手段——惩罚足够低，人才敢把权限给足，代理也才能真正干活。

KVM 门控（opt-in）。 启用后可以在沙箱内跑 Docker、Kind 等容器工作流。

局限与坑

Pre-1.0，破坏性变更在预期内。 Linux 支持标注 experimental。生产环境或关键交付前，需要自己验证稳定性，别直接假设 1.0 的兼容性。

白名单的语义要讲透。 allow-list 只拦"未知"服务器。已放行的域名（比如 github.com）加上转发的 ssh-agent，意味着"代理能读到的，都能发布"——README 对这一点是明示的。它防的是环境破坏与凭据外泄，不是数据防泄漏的全部。把"隔离"当成一个开关的人容易误解：这套模型的前提是"放行清单里的世界是可信的"，如果仓库里本身有敏感数据，白名单并不能阻止代理把它推到被放行的服务上。

白名单是运维负担。 任务依赖新的包源或 API，就要改配置。配松了失去意义，配紧了任务失败，需要有人持续维护。

平台限制。 目前主要是 Apple Silicon macOS；Intel Mac 与 Windows 不在范围内。每个沙箱是一台真 VM，并行工单多时内存和磁盘要留出余量。

更偏个人工作流，不是团队平台。 沙箱配置默认是本地一份，多人的配置分发、变更审批、审计记录需要团队自己约定流程。它解决的是单机隔离问题，不解决"组织怎么管代理权限"的制度问题——后者仍要自己建。

适用场景

选型建议

如果你正纠结编程代理"要不要给权限"，clawk 的思路值得先试。落地路径可以很小：挑一个不重要的仓库，写一份 sandbox 配置，白名单收紧到 github.com 和必要域名，跑一周真实任务。跑通后再评估两台以上并行时的资源开销。评估时不要只看隔离强度，也要看日常摩擦——镜像构建、白名单维护、资源占用这些成本每天都会被感知到，能接受才值得长期用。

要容器级隔离可以比较 clampdown、clawker；要轻量进程级防护看 Anthropic sandbox-runtime；clawk 的差异是"真 VM + 一次性"，代价是资源占用和平台限制。也可以把它放进"放权三档"里理解：不隔离直接跑适合受控小任务；容器方案适合日常；真 VM 适合跑不可信代码和长时间自主执行。按任务风险选档，比一刀切地决定"给不给权限"更实际。Linux 用户先按 experimental 对待，生产使用等 1.0 更稳妥。Apache-2.0 可商用，私有化交付没有许可顾虑。

参考来源