but 我是在 windows 上跑，有什么可以替代 bubblewrap 的吗🤔然后就是这个是个人用户在本地部署所以不用考虑多租户的情况

回复 群友 7309 Windows 上 bubblewrap 没有直接对应物，得换思路。本地个人部署其实是最好办的情况，因为威胁模型很弱：你要防的只是 agent 写错代码、误删文件、死循环，而不是防恶意逃逸。 推荐路线：WSL2 + bubblewrap 最省心的做法就是直接在 WSL2 里跑。WSL2 本身是个轻量 VM，你在里面用正常 Linux 的 bwrap/nsjail 完整跑一遍，隔离边界来自 WSL2 的 VM，比 Windows 上拼一堆 API 干净得多。缺点是浏览器要跑在 Windows 侧，通过 localhost 转发通信，这个正好符合“代码在沙箱、浏览器在沙箱外”那套架构。 纯 Windows 原生方案的替代 一是 Windows Sandbox（Windows 专业版自带，基于 Hyper-V 的轻量容器），一次性环境，跑完整个丢弃，很适合做“执行完就重建”。缺点是每次启动几十秒，且共享目录受限，不适合高频短任务。 二是 AppContainer / Job Object。Job Object 能做的正是你要的那几件事：内存上限、CPU 时间、进程数、禁止子进程逃逸，以及 kill 整个进程树。这是 Windows 上最接近 cgroup 的东西，做资源约束必用。AppContainer 提供文件系统和网络的能力限制，但 API 比较繁琐，要用 StartAppContainer 那套，通常配合 CreateProcessAsUser 用受限 token 跑。 三是受限 Token + 低权限账号：单独建一个低权限本地用户，用 CreateProcessWithTokenW 以它的身份跑脚本，配合 ACL 只给它一个 workspace 目录的读写。这个成本最低、效果最直接，Windows 的权限模型在这里其实够用。 四是文件系统层，用 NTFS ACL 而不是挂载隔离：只给 workspace 目录写权限，其他盘符用 deny ACL。比想办法“挂只读根”简单得多。 网络这块 Windows 上反而更好办 Windows Filtering Platform（WFP）可以按进程 PID 阻网，或者最简单：给那个低权限账号配一条出站防火墙规则默认阻断，需要时再开。本地部署建议直接默认断网，脚本根本没有出网的理由。 异常回滚 Windows 上没有 overlayfs，别想着快照回滚。做法是：每个任务一个独立 temp 目录，跑完整个删掉；进程用 Job Object 保证超时后整棵树被杀；有副作用的外部动作照旧走幂等键加意图日志。真的脏了就重建工作目录，而不是修。 最低可行组合 低权限用户 + 受限 token 启动 + Job Object 限资源限时 + 只给 workspace 的 ACL + 防火墙默认断网 + 每任务独立目录。这套纯 Windows 原生能搭起来，不需要额外装东西，一天能搞定。如果嫌 API 麻烦，就套 WSL2，一劳永逸。