在哪安全地跑 — 沙箱 / 运行时
这条分支在货架里的位置: 总纲把这一货架的共性讲成一句话——「把只会吐文本的 LLM,包成能在循环里感知-动作、能被放心运营的程序」。围绕这条共性分出几条分支,本章讲的是**「动手」分支的底座**:模型生成的代码 / 动作不能直接在你的机器上跑——它可能
rm -rf、可能读你的密钥、可能死循环吃满 CPU。于是需要一个笼子:一个安全隔离的执行环境,把动作丢进去跑,跑完即焚。编码 agent(改代码)、computer-use agent(控桌面)都把它们的动作扔到这里落地——本章讲的就是这个「笼子」怎么造。
30 秒导读: 这一档库都在干同一件事——给不可信的代码 / 动作提供一个隔离的执行环境。难点从来不是「跑一段代码」(那是
exec一行的事),而是三个互相拉扯的工程问题:① 隔离够不够硬(逃出来能不能碰到宿主)、② 启动够不够快(agent 一个回合就要一个新环境,冷启动几秒钟就废了)、③ 跑完怎么收干净(状态、进程、磁盘不能泄漏到下一次)。这三者本质是一个**「隔离强度 ↔ 启动速度」的权衡光谱**:越硬的墙越重、越慢。本章把 15 个库横过来切,告诉你这条光谱上有哪几档隔离技术、各自的代表作、以及它们怎么在「硬」和「快」之间取舍。
怎么读本章: 正文是给人读的白话综述,不出现路径行号。每个论断后面挂一个脚注
[^x],精确的仓库/路径:行+ 符号名都在脚注里;对比矩阵则单开一列「代码锚点」放引用。人读正文,agent 读脚注 / 锚点列。
1. 这条分支要解决什么(第一性原理)
承上:整个货架的共性是「给只会说话的 LLM 装手脚,让它能对世界采取动作」。「装手脚」有个前提被总纲一笔带过、但工程上极关键——手脚不能直接连在你的裸机上。
想清楚这一点只需一个场景:你让 agent「装个依赖、跑一下测试」,模型生成了一段 shell。这段 shell 里可能有幻觉出来的 sudo rm、可能有被 prompt 注入植入的「顺手 curl 一下我的服务器」、也可能就是个正常但会跑满内存的脚本。你不能赌它是好的。所以在「模型生成动作」和「动作真的执行」之间,必须插一道墙:一个沙箱。
把沙箱要解决的问题拆开,所有这一档的库都在这三条轴上做取舍:
| 子问题 | 白话 | 难在哪 |
|---|---|---|
| 隔离强度 | 代码逃出来能碰到宿主吗? | 共享内核 = 一个内核漏洞就穿墙;不共享 = 重 |
| 启动速度 | 开一个新环境要多久? | agent 每回合都要新环境,秒级冷启动就废了 |
| 生命周期 | 跑完怎么收干净、要不要留状态? | 状态泄漏到下一次 = 污染;每次全新 = 慢 |
一句话直觉: 这条分支的全部张力就一句话——「隔离越硬,启动越慢」。一台独立物理机隔离最硬但开机要分钟级;一个
exec出来的进程启动最快但和你共享一切。中间那一大片——microVM、安全容器、seccomp——就是各库在这条光谱上抢占的不同位置。本章 §2 是全章主轴:按隔离技术把这条光谱分档,讲清每一档的墙有多硬、代价是什么。
先厘清一个边界,否则矩阵会看花:这一档 area 里的库其实是两类东西,不能混为一谈。
- 隔离引擎(本章主角): 亲自造墙——决定用 microVM 还是容器、怎么起、怎么焚。e2b / e2b-infra、microsandbox、dify-sandbox、opensandbox、beta9、cloudflare-sandbox-sdk、cua、aio-sandbox、daytona 属于这类。
- agent 编排运行时(借墙的人): 它们管的是「agent 的会话 / 步骤 / 状态怎么持久编排」,代码执行这一步委派给上面的隔离引擎,自己不造墙。julep(基于 Temporal 的有状态工作流)、yao、ogx、iii 属于这类。1
本章 §2–§4 只深挖第一类(造墙的),§5 再把第二类归位。
2. 流派:按「墙用什么造」分档(本分支的灵魂)
这是分化最剧烈的一条主轴。「给不可信代码一堵墙」——按墙的材质,从最硬最重到最轻最快,长出五档。
怎么读这张图: 从左到右是「隔离强度递减、启动速度递增」。最左边每个沙箱有自己的内核(microVM),一个宿主内核漏洞也穿不过去;越往右越共享宿主内核,靠拦截系统调用兜底,轻快但墙更薄。
隔离最硬 / 最重 ──────────────────────────────► 最轻 / 最快
独立内核 共享宿主内核
┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ ① microVM │ │ ② 安全容器 │ │ ③ 普通容器 │ │ ④ 进程内 │ │ ⑤ 托管/边缘 │
│ 独立内核 │ │ 拦截 syscall │ │ namespace │ │ seccomp │ │ 平台代管 │
│ Firecracker/ │ │ 的沙箱内核 │ │ + cgroup │ │ syscall │ │ 容器隔离由 │
│ libkrun │ │ gVisor/Kata │ │ (runc) │ │ 过滤 │ │ 平台负责 │
└──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘
e2b · micro- opensandbox · beta9(默认)· dify-sandbox cloudflare ·
sandbox beta9(可选) aio-sandbox daytona · cua(桌面VM)
下面逐档接地。关键洞察:①②的差别是「有没有自己的内核」,而不是「像不像虚拟机」——gVisor 看起来是容器,但它用一个用 Go 写的用户态内核去接管客户进程的系统调用,所以隔离比普通容器硬、比真 VM 轻。这是理解整条光谱的钥匙。
2.1 microVM:每个沙箱一个独立内核(最硬)
思路:用一个极度精简的虚拟机监控器(VMM)给每个沙箱开一台真 VM——有自己的 guest 内核、自己的虚拟设备,和宿主之间只隔着一层薄薄的 VMM。因为不共享内核,一个 guest 内核漏洞也碰不到宿主。代价是要装内核、要虚拟化,历史上「重」——microVM 的全部工程努力就是把这份重压到毫秒级。
- e2b / e2b-infra:E2B 是面向 agent 的 microVM 沙箱运行时,底座 e2b-infra 用 Firecracker 编排。每个沙箱是一个 Firecracker 进程,被起在独立的 Linux 网络命名空间里(
ip netns exec … firecracker --api-sock),VM 内跑一个envd守护进程接管进程 / 文件系统 API。2 「快」靠内存快照:把预热好的 VM 内存做成 memfile,新沙箱直接从快照恢复,而不是冷启一个内核。3 - microsandbox:本地优先的 microVM 运行时,底层是 libkrun——把 VMM 做成一个库直接链进进程,
Sandbox::builder(...).create()就地把一个 microVM 拉起来当子进程,无需外部基础设施。4 它主打亚百毫秒启动,并自带 MCP server,让 agent 直接把这个 microVN 当工具调。5
2.2 安全容器:共享内核但拦截系统调用(硬,但轻于真 VM)
思路:不给每个沙箱开真 VM,但也不信任宿主内核直接暴露给客户进程。在两者之间插一层沙箱化的运行时——要么是用户态内核(gVisor / runsc),要么是极简的 VM 化容器(Kata)。对上它伪装成一个标准 OCI 容器运行时,对下它把客户进程的系统调用统统截下来自己处理,不让它们直接打到宿主内核。硬度介于 microVM 和普通容器之间。
- opensandbox(阿里):这是把「安全容器」抽象得最干净的一个。它有一个 runtime resolver,把配置里的
gvisor/kata/firecracker翻译成后端要的运行时名——Docker 后端翻成 OCI 运行时(gvisor→runsc、kata→kata-runtime),Kubernetes 后端翻成 RuntimeClass(gvisor→gvisor、kata→kata-qemu、firecracker→kata-fc)。6 换句话说,同一套沙箱生命周期代码,底下的隔离档位是一个可配置项——这是这一档最清晰的教科书。7 - beta9(Beam):自托管的 serverless 运行时,每个 pool 可配
runc或gvisor两种容器运行时,gVisor 走runsc。8 它还叠了一层冷启动加速:用 CRIU 做 checkpoint/restore,把跑起来的容器内存快照下来热恢复(是否启用由 pool 的CRIUEnabled决定,和用哪种运行时无关)。9
2.3 普通容器:namespace + cgroup(轻,但共享内核)
思路:就用 Linux 原生的 namespace(隔视图)+ cgroup(限资源),即标准 runc。启动快、生态成熟,但客户进程和宿主共享同一个内核——一个内核提权漏洞就能穿墙。适合「代码来源相对可控、看重速度和便利」的场景。
- beta9 默认档就是
runc(gVisor 是可选升级)。8 - aio-sandbox(字节 agent-infra):把 Browser / Shell / File / MCP / VSCode Server / Jupyter 全塞进一个 Docker 容器,SDK 用一组子系统 namespace(shell / file / jupyter / mcp / browser…)去驱动它。10 它优化的是**「一个容器搞定一个 agent 需要的全套工具」**,隔离用的是普通容器这一档——胜在开箱即用,不是隔离最硬的那一挂。
- daytona:面向「跑 AI 生成代码」的弹性基础设施,主打快速启动的沙箱 + SDK + 自托管,同属容器化弹性运行时这一路(仓库为多语言 monorepo,以 README 为总入口)。11
2.4 进程内 seccomp:不开容器,只锁系统调用(最轻)
思路:连容器都不开——就在当前进程里,用 seccomp 给内核装一张 BPF 过滤器,把这个进程能调的系统调用收窄成一张白名单,白名单外的直接杀进程 / 返错。极轻(没有容器启动开销),但隔离最薄(还是宿主内核、还是同一进程树)。适合「只跑一小段解释器代码、追求极致轻快」的场景。
- dify-sandbox:这是这一档的代表。它给 Python / Node 解释器进程装 seccomp——默认动作是
ActKillProcess(白名单外直接杀),再逐一AddRule放行必需的系统调用,最后用SYS_SECCOMP把 BPF 过滤器载入。12 联网与否也做成 seccomp 层的开关:enable_network决定网络相关系统调用是放行还是拒绝。13 轻到可以嵌进 Dify 的工具执行链里。
2.5 托管 / 边缘:隔离由平台负责,你只管调 API
思路:不自己造墙,而是把沙箱架在一个已经提供隔离的平台上,你拿到的是「一个能跑代码的对象」,墙由平台代管。对使用者最省心,代价是绑定平台。
- cloudflare-sandbox-sdk:把沙箱做成 Cloudflare 的 Durable Object(
Sandbox extends Container),getSandbox()拿到一个绑定到某容器的有状态对象,exec/execStream通过一条 WebSocket 上的 RPC 打到容器侧执行。14 隔离由 Cloudflare 边缘的容器平台负责,你写的只是 Workers 代码。 - cua(trycua):面向 computer-use agent——它要的不是「跑一段代码」而是「控一整台桌面」,所以沙箱是整机 VM。它抽象出多个 VM provider(本地的 lume / qemu、云端的 cloud),支持 macOS / Linux / Windows 客户机,agent 通过 WebSocket 对这台 VM 做鼠标键盘截屏。15 隔离粒度是「一台完整虚拟桌面」,是这条光谱在 computer-use 场景的特化。
- e2b-code-interpreter:严格说不是新造一档隔离,而是 E2B microVM 之上的一层「代码解释器」SDK——在沙箱里跑一个 Jupyter 内核,
run_code把代码丢给内核、拿回富输出(图表 / stdout)。16 它证明了一件事:隔离层稳定后,上面能长出「有状态 REPL」这种高层能力。
3. 让沙箱「快」的两条暗线(跨档共通)
隔离档位定了「墙多硬」,但几乎每个认真的运行时都要额外解决「怎么快」——因为 agent 是高频开合沙箱的(每个任务、有时每个回合一个)。冷启一个内核 / 容器要几百毫秒到几秒,乘上高频就爆了。两条几乎人人都走的暗线:
| 加速手段 | 白话 | 代表做法 | 代码锚点 |
|---|---|---|---|
| 快照恢复 | 预热好一个环境,把内存冻成快照,新沙箱从快照恢复而非冷启 | e2b 的 memfile 快照;beta9 的 CRIU checkpoint/restore | 3 · 9 |
| 库化 VMM / 本地起 | 把 VMM 做成库直接起子进程,省掉外部编排的往返 | microsandbox 的 libkrun 就地起 microVM | 4 |
领域智慧: 「隔离要硬」和「启动要快」看似矛盾,工程上却是用快照把它们解耦——墙的硬度由隔离技术决定(一次性成本),启动速度由「恢复而非冷启」决定(每次成本)。这就是为什么 microVM 这种「理论上重」的方案,配上内存快照后反而能做到毫秒级——e2b 从 Firecracker 快照恢复、microsandbox 亚百毫秒启动,靠的都是「预热 + 恢复」而不是「每次从零装内核」。
4. 对比矩阵(逐格接地)
维度:隔离档位(§2)、隔离技术、启动加速(§3)、生命周期 / 状态、定位。描述列写白话,精确
path:line+符号 全在最右「代码锚点」列。—表示该维度对此库不适用或未在克隆中体现。
| 库 (id) | 隔离档位 | 隔离技术 | 启动加速 | 定位 | 代码锚点 |
|---|---|---|---|---|---|
| e2b | ① microVM | Firecracker + 独立 netns,VM 内 envd | 内存 memfile 快照恢复 | 面向 agent 的开源 microVM 沙箱运行时 | e2b-infra .../sandbox/fc/script_builder.go:53;fc/memory.go:80 |
| e2b-infra | ① microVM | Firecracker VMM 编排(自托管底座) | 快照恢复 + 池化 | E2B 云的自托管 Go 基础设施 | .../sandbox/fc/script_builder.go:53;fc/client.go:42 loadSnapshot |
| microsandbox | ① microVM | libkrun(VMM 作为库,子进程起 VM) | 本地起 + 亚百毫秒启动 | 本地优先 microVM 运行时 + MCP server | crates/runtime/lib/vm.rs:1046 krunfw_path;README Instant Startup |
| opensandbox-alibaba | ②(可 ③/①) | runtime resolver:gvisor→runsc / kata→kata-runtime / firecracker→kata-fc | Docker/k8s 生命周期 + 快照 | 阿里沙箱运行时,隔离档位可配 | services/runtime_resolver.py:51-60;config.py:733 |
| beta9 | ③ 默认 / ② 可选 | runc(默认)或 gvisor/runsc(pool 可配) | CRIU checkpoint/restore 热恢复 | 自托管 serverless 运行时(E2B 替代) | pkg/types/runtime.go:6-7;pkg/worker/worker.go:304;CRIU worker.go:348 |
| dify-sandbox | ④ 进程内 | seccomp BPF:ActKillProcess 默认 + 系统调用白名单 | —(本就轻,无需快照) | 多语言代码执行沙箱(Dify 用) | internal/core/lib/seccomp.go:16;网络门控 runner/python/python.go:143 |
| cloudflare-sandbox-sdk | ⑤ 托管/边缘 | Durable Object(Sandbox extends Container),RPC over WS | 平台代管 | 在 Cloudflare 边缘跑沙箱的 TS SDK | packages/sandbox/src/sandbox.ts:947;exec/execStream :755/:776 |
| cua | ⑤ 整机 VM | VM provider(lume/qemu 本地、cloud 云), 支持 mac/linux/win 客户机 | provider 各自快照/池化 | computer-use agent 的桌面 VM 基础设施 | libs/python/computer/computer/computer.py:104(provider);providers/ |
| aio-sandbox | ③ 普通容器 | 单 Docker 容器塞 Browser/Shell/File/MCP/VSCode/Jupyter | —(常驻容器,重用) | 一站式 agent 沙箱(全套工具打包) | sdk/python/agent_sandbox/client.py:86-98(子系统 namespace) |
| daytona | ③ 容器化弹性 | 快速启动沙箱 + SDK + 自托管(多语言 monorepo) | 快速启动(fast-start) | 跑 AI 生成代码的弹性基础设施 | README.md(总入口;healthOnly,高频演进) |
| e2b-code-interpreter | 借 ①(E2B microVM) | 不新造墙:E2B 沙箱内跑 Jupyter 内核 | 继承 E2B 快照 | E2B 之上的「代码解释器」SDK | python/.../code_interpreter_async.py:105 run_code;:63 jupyter url |
| julep | 编排层(委派隔离) | Temporal 有状态工作流编排 agent 步骤,代码执行委派外部沙箱 | —(靠底层沙箱) | 有状态 agent 后端 / 运行时 | agents-api/.../workflows/task_execution/__init__.py:8(temporalio) |
| yao | 编排层 | Go 单二进制 agent/web 运行时 + 内建 DSL(非隔离引擎) | — | 构建 agent/web app 的 Go 运行时 | agent/(README 总入口) |
| ogx | 编排层 | 标准化 agent/inference/safety API 的 GenAI 栈(原 llama-stack) | — | Open GenAI Stack | src/(README 总入口) |
| iii | 编排层 | 把 agent/API/workflow 组合成带可观测性的 step 运行时( 原 Motia) | — | 组合式后端运行时 | README.md(总入口) |
矩阵里两个「家族」值得点名:E2B 家族(e2b 面向用户 / e2b-infra 是底座 / e2b-code-interpreter 是解释器 SDK,三者共用 Firecracker microVM 内核)和编排层家族(julep/yao/ogx/iii 都不亲自造墙,把隔离委派出去)。长尾库不必逐一拆解——它们要么落进上面某个隔离档位,要么属于「借墙」的编排层。
5. 模式与权衡(可带走的领域智慧)
读完矩阵,几条横跨全分支的规律浮出来:
-
隔离强度是一条连续光谱,不是「安全 / 不安全」的二值。 从 microVM(独立内核)→ gVisor(用户态内核)→ Kata(极简 VM 化容器)→ runc(共享内核)→ 进程内 seccomp,墙一档比一档薄、启动一档比一档快。选型不是「要不要隔离」,而是**「你能容忍多薄的墙换多快的启动」**。
-
「有没有自己的内核」是隔离硬度的分水岭。 microVM 和安全容器(gVisor/Kata)都不和宿主共享内核,所以能扛「客户内核漏洞」;普通容器共享内核,扛不住。opensandbox 把这做成一个可配置档位(改个
type就换硬度),是理解这条分水岭的最佳样本。 -
「快」和「硬」用快照解耦。 天真地看 microVM「重」,但配上内存快照 / CRIU 恢复,毫秒级启动 + 硬隔离可以兼得。启动慢的锅往往在「每次冷启」而不在「隔离技术本身」——这是这条分支最反直觉、也最值钱的一条智慧。
-
「造墙的」和「借墙的」是两类库,别混。 隔离引擎(e2b/microsandbox/dify-sandbox/opensandbox…)亲自决定墙的材质;agent 编排运行时(julep/yao/ogx/iii)只管会话 / 步骤 / 状态,把执行委派下去。同一个 area 里两类共存,选型时先问「我要的是墙,还是编排」。
-
粒度跟着场景走。 编码 agent 要的是「跑代码 / 装依赖」,沙箱粒度是一个文件系统 + shell(e2b/dify/opensandbox);computer-use agent 要的是「控整台桌面」,粒度就得是整机 VM(cua)。同一条隔离光谱,粒度按「动作是什么」拉伸。
-
托管 vs 自托管的取舍。 cloudflare-sandbox-sdk / daytona 让平台代管隔离(省心、绑定平台);e2b-infra / microsandbox / beta9 让你自托管(可控、自己扛运维)。这是「造墙」层内部的第二条取舍轴。
6. 演化趋势(这条分支往哪走)
把时间轴拉出来,三条趋势很清楚:
-
「容器够用」→「microVM 成为不可信代码的默认」。 早期跑 AI 代码多用普通容器(runc);但「共享内核 = 一个漏洞穿墙」的风险,让面向不可信 LLM 代码的新一代(e2b、microsandbox)直接倒向 microVM,再用快照把它的「重」压掉。opensandbox 把 gVisor/Kata/Firecracker 并列成可配档位,正是这场迁移「进行中」的活化石。
-
「隔离引擎」→「隔离 + 高层能力」的分 层。 隔离层稳定后,上面长出更高层的抽象:e2b-code-interpreter 在沙箱里包一个 Jupyter 内核变成「有状态 REPL」;aio-sandbox 把 Browser/MCP/VSCode 打包成「一站式工具箱」;microsandbox 自带 MCP server 让 agent 直接调。沙箱正从「一个能跑代码的盒子」长成「一个 agent 的完整工作台」。
-
「自己运维一套 Firecracker」→「调一个 API 就有沙箱」。 cloudflare-sandbox-sdk 的 Durable Object、daytona 的托管弹性基础设施,都在把「造墙」这件重活变成一次 API 调用。自托管路线(e2b-infra/beta9)仍在,但默认心智正从「我搭一套」滑向「我调一个」。
三条趋势同源:隔离这件事正在「下沉」成基础设施——就像早年数据库从「自己装 MySQL」下沉到「调一个托管库」。这也呼应总纲的共性:把 LLM 包成可信程序,关键不只在模型多聪明,更在于它动手时,底下那道墙够不够硬、起得够不够快、收得够不够干净。
7. 代表作 + 深入读哪些
按隔离档位点名代表作,想深入就从这里下钻:
| 想学的东西 | 代表作 | 入口 |
|---|---|---|
| microVM 编排(Firecracker + 快照,必修) | e2b-infra | 克隆 packages/orchestrator/pkg/sandbox/fc/ |
| 库化 microVM(libkrun 本地起,亚百毫秒) | microsandbox | 克隆 crates/runtime/lib/vm.rs |
| 安全容器档位可配(gVisor/Kata/Firecracker 一键切) | opensandbox-alibaba | 克隆 server/.../services/runtime_resolver.py、config.py |
| runc vs gVisor + CRIU 热恢复 | beta9 | 克隆 pkg/worker/、pkg/types/runtime.go |
| 进程内 seccomp(最轻隔离,读懂 BPF 白名单) | dify-sandbox | 克隆 internal/core/lib/seccomp.go |
| 托管 / 边缘沙箱(Durable Object + RPC) | cloudflare-sandbox-sdk | 克隆 packages/sandbox/src/sandbox.ts |
| 整机桌面 VM(computer-use 场景) | cua | 克隆 libs/python/computer/computer/providers/ |
| 隔离之上的「代码解释器」(Jupyter REPL) | e2b-code-interpreter | 克隆 python/e2b_code_interpreter/ |
| 一站式工具沙箱(容器内塞全套工具) | aio-sandbox | 克隆 sdk/python/agent_sandbox/client.py |
| agent 编排运行时(借墙,不造墙) | julep · yao · ogx · iii | julep src/agents-api/;各库 README |
给入门者的学习路径: 先读 dify-sandbox 的 seccomp(最短路径搞懂「隔离到底在拦什么」)→ 再读 opensandbox 的 runtime resolver(一处代码看全 gVisor/Kata/Firecracker 三档的取舍)→ 然后读 e2b-infra 的 Firecracker + 快照(理解 microVM 怎么又硬又快)→ 想看极简本地方案就读 microsandbox 的 libkrun。四步下来,你能自己回答「我这个 agent 的动作,该丢进哪一档墙里跑」。读完回总纲,你会发现:编码 / computer-use 分支讲的是「怎么想出动作」,而本章讲的是「动作落在哪里跑才安全」——它们是同一件事的两半。
8. 代码地图(导航索引)
给 agent 的精确入口表(库 / 路径 / 符号),按隔离档位排:
| 主题 | 路径 | 符号 / 说明 |
|---|---|---|
| Firecracker VMM 启动脚本 | e2b-infra/packages/orchestrator/pkg/sandbox/fc/script_builder.go:53 | ip netns exec … firecracker --api-sock |
| Firecracker 快照加载 | e2b-infra/packages/orchestrator/pkg/sandbox/fc/client.go:42 | loadSnapshot |
| Firecracker 内存 memfile | e2b-infra/packages/orchestrator/pkg/sandbox/fc/memory.go:80 | originalMemfile / dedup cache |
| libkrun microVM 构建 | microsandbox/crates/runtime/lib/vm.rs:1046 | krunfw_path(VmBuilder) |
| 安全运行时解析(gvisor/kata/fc) | opensandbox-alibaba/server/.../services/runtime_resolver.py:51 | DEFAULT_DOCKER_RUNTIMES / DEFAULT_K8S_RUNTIME_CLASSES |
| 安全运行时配置模型 | opensandbox-alibaba/server/.../config.py:733 | type: Literal["","gvisor","kata","firecracker"] |
| runc / gvisor 运行时常量 | beta9/pkg/types/runtime.go:6 | ContainerRuntimeRunc / ContainerRuntimeGvisor |
| gVisor runsc 装配 | beta9/pkg/worker/worker.go:304 | RunscPath: "runsc" |
| CRIU checkpoint/restore | beta9/pkg/worker/worker.go:348 | CRIUEnabled / InitializeCRIUManager |
| seccomp BPF 白名单 | dify-sandbox/internal/core/lib/seccomp.go:16 | sg.NewFilter(sg.ActKillProcess) |
| seccomp 网络门控 | dify-sandbox/internal/core/runner/python/python.go:143 | {{enable_network}} |
| Cloudflare Sandbox DO | cloudflare-sandbox-sdk/packages/sandbox/src/sandbox.ts:947 | class Sandbox extends Container |
| Cloudflare exec/execStream | cloudflare-sandbox-sdk/packages/sandbox/src/sandbox.ts:755 | stub.exec / execStream |
| cua VM provider 选择 | cua/libs/python/computer/computer/computer.py:104 | provider_type(lume/qemu/cloud) |
| Jupyter 代码解释器 | e2b-code-interpreter/python/e2b_code_interpreter/code_interpreter_async.py:105 | run_code |
| aio-sandbox 子系统 namespace | aio-sandbox/sdk/python/agent_sandbox/client.py:86 | _shell/_file/_jupyter/_mcp/_browser |
| julep Temporal 工作流 | julep/src/agents-api/agents_api/workflows/task_execution/__init__.py:8 | from temporalio import workflow |