对市面上的sandbox方案做一个横向对比，重点对比接入难度以及可维护性。

回复 群友 1942： 这个对比我按两个维度说：接入难度和可维护性。信息主要来自 2026 年初的一篇横向综述（https://manveerc.substack.com/p/ai-agent-sandboxing-guide），里面的性能数字有些是二手引用，选型前最好自己跑一遍。 先分层，不然容易拿 Firecracker 和 Modal 直接比，那是两个层级的东西。 第一层是底层原语，比如 Firecracker、gVisor、Cloud Hypervisor，还有微软刚出的 LiteBox（实验阶段，没有生产生态）。它们是原材料，你要自己做调度、镜像分发、网络和 warm pool。 第二层是可嵌入的运行时，像 E2B 这种托管 API，或者 microsandbox 这种自托管版本。它们把底层包成 SDK，核心是“沙箱即 API”。 第三层是托管平台，比如 Modal、Northflank、Daytona。平台本身就是运行环境，适合要 GPU、要数据本地化、不想运维的团队。 另外还有 Google 的 Agent Sandbox，是 CNCF 下的 K8s 控制器，支持 gVisor 和 Kata，自带 warm pool，适合已经在 K8s 上的团队。 接入难度，从低到高大致是这样。E2B 最低，SDK 接上基本几天能跑通，适合给 ca 加一个代码执行环境。Daytona 也比较低，因为它兼容 Docker，你现有的镜像基本能直接用。Modal 对 Python 团队很顺手，但镜像是用 SDK 定义的，迁移时会有摩擦。Northflank 配置面更宽，初期搭建比纯 API 重。Agent Sandbox 如果你已经有 K8s，接入是 YAML 级别的事；没有的话，等于先要搭一套集群。Firecracker 最难，你要自己处理 TAP 网卡、jailer、CNI，还有镜像的懒加载，这些是综述里反复提到的踩坑点。 可维护性上，我的判断是：自己拿原语搭的那套，长期维护成本最高，因为调度器、镜像缓存、网络、warm pool 的升级和排障全压在你身上，而且 warm pool 闲置浪费很容易超过平台的加价。自托管的 microsandbox 比它轻，但你仍然要管扩缩容、监控和镜像。托管 API 维护量最小，代价是锁定：SDK 和调用方式会渗进业务代码里。 这里有一个关键判断：选型时真正决定成本的通常不是隔离技术，而是会话形态。如果只是一次性执行脚本，按秒计费的 API 很划算；如果 agent 要跑几十分钟、中间还会等用户输入，闲置时长会让按秒计费越来越贵。Reddit 上有人反馈 E2B 和 Daytona 在长驻场景下比一台常开的 VPS 贵，这只是个人经验，不能当结论，但值得你算一下自己的会话时长。 隔离强度上，要先回答代码有多不可信。团队自己写的、过了 CI 的代码，普通容器可能够用；LLM 生成的代码至少要 gVisor 起步；允许用户上传任意二进制或随便装包的，要按敌对代码对待，只能上微虚拟机。Daytona 默认是 Docker，要想要微虚拟机级别隔离得显式开 Kata，这点很容易被忽略。 我的建议是：早期团队先用托管 API（E2B 或 Daytona 二选一），但一定要在外面包一层你自己的 adapter，把文件读写、会话持久化、超时、执行结果这些统一成你的接口。这样日后换成自托管或平台，只改 adapter，不动 agent 主逻辑。真到了规模化、有合规要求或 GPU 需求，再考虑 Northflank（BYOC、Kata 可选）或 K8s 上的 Agent Sandbox。自己从 Firecracker 起步，除非你的业务本身就是做沙箱平台，否则基本是把运维成本换成了技术炫技。 如果你告诉我你们的场景（代码是谁写的、单次还是长会话、是否要 GPU、现在有没有 K8s），我可以把这个对比收窄到一两个具体方案。