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 放在隔离的执行环境中运行」——沙盒是工程实践清单上的第一道防线,而不是一道可有可无的附加层。

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

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

下面用一段 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 配一台隔离计算机」做成了产品一等公民,产品文档在 https://docs.smith.langchain.com/docs/sandbox/agents ,官方公告与设计动机在 https://blog.langchain.com/langchain-sandboxes/ ;OWASP 关于 LLM 应用的 Top 10 漏洞榜单与缓解建议在 https://owasp.org/www-project-top-10-for-large-language-model-applications/ ,每一类漏洞的修复清单都明确指向隔离执行环境。

回到最初的问题:为什么 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 预算。

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

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 官方博客 https://blog.langchain.com/langchain-sandboxes/ 的产品定位,沙盒与 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 官方文档 https://docs.smith.langchain.com/ 给出的 sandbox 抽象层,既支持 Firecracker 做生产强隔离,也允许 dev 环境用更轻的 runtime 加速开发,这是把『一等公民』做成一整套梯度而非单一口径。

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

# 网络出口治理:白名单 + 拦截 + 审计
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 文档 https://docs.smith.langchain.com/docs/sandbox/agents 建议把 sandbox 镜像与生产镜像保持一致,避免环境漂移;LangGraph Platform 集成页面 https://docs.langchain.com/langgraph-platform 则提供了把 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』两种模式在几个关键维度上做一次直观的对比,帮团队在选型时建立量化锚点:

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

从 Snapshot 派生沙盒的伪代码

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

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 配一台隔离计算机」明确作为一等公民,文档入口见 https://docs.smith.langchain.com/docs/sandbox/agents;其产品公告与设计动机可以参考 LangChain 官方博客 https://blog.langchain.com/langchain-sandboxes/。如果团队已经在用 LangGraph 编排 Agent 主循环,那么 LangGraph Platform 的沙盒与执行模型文档同样覆盖了 Snapshot / Fork 的运行时语义,入口见 https://docs.langchain.com/langgraph-platform;LangGraph 自身的概念与 API 索引在 https://langchain-ai.github.io/langgraph/。在隔离机制选型上,LangSmith 文档还会指向底层的 microVM 实现,常见参考是 Firecracker https://github.com/firecracker-microvm/firecracker 与 gVisor https://github.com/google/gvisor,这两个项目的官方仓库都给出了与 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 的设计哲学里,「最小权限 + 默认拒绝」会比「白名单脚本」更被现代团队接受。

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