企业官网建设流程全解析

终端里的命令还在逐行滚动，我盯着屏幕，感觉哪里不对——Agent 正在按照一条"清理临时文件"的指令，把日志目录一个接一个删掉。等我把进程拉停，好几个小时的分析数据已经没了。这不是小说里的情节，是群里真实有人复盘过的场景。事后大家讨论了一圈，结论出奇一致：这 Agent 根本没进沙箱，或者说，配置里那个"沙箱"形同虚设。

现在聊大模型 Agent，十个开发者有八个都会跟你说"要放到沙箱里跑"。可"沙箱"这个词被用得太随意了，有人觉得是一个软件，有人觉得是虚拟机快照，还有人以为是某个开关一打开就有保护。这篇文章我想把这事一次性说清楚：沙箱到底是个什么东西、为什么 Agent 这种会自己动手的程序离不开它、你在自己项目里怎么搭一个能用的沙箱，以及我在真实使用中踩过的那些坑。适合正在接 Agent 功能的开发者、在做平台的同学，以及刚对智能体安全边界感兴趣的新手。

1. 先拆穿沙箱的神秘面纱：它其实是一套约束规则

1.1 沙箱不是一个具体组件，而是一组"权限边界"的总和

很多初学者会问：沙箱在哪个目录？要不要装？其实操作系统里没有一个按钮叫"打开沙箱"。所谓沙箱，指的是你用操作系统的各种隔离机制，把某个进程的活动范围限制在一个可控边界里。

边界之内，这个进程随便折腾；边界之外，它既看不见也碰不着。这个"边界"通常由几层机制叠加出来：文件系统视图、网络视图、进程视图、资源配额、系统调用过滤。你把它们组合起来，就得到了一个行为上被圈住的环境。在 Linux 这类系统上，这些机制本身就存在，比如命名空间能改变进程看到的资源视图，资源组能限制 CPU 和内存用量，安全模块可以做系统调用级别的拦截。沙箱不是额外引进的魔法，而是把这些底层能力按需组合起来的一种用法。

1.2 想想切菜板，你就懂了

我总觉得"沙箱"这个词就该用厨房来类比。家里切完生肉，你不会直接在客厅地板上切，对吧？生肉的汁水会弄脏地面，还可能污染其他食物。正确的做法是拿到专门的切菜板上，用完洗净，再收起来。

Agent 就是那块生肉。它本身没有恶意，但它运行携带的数据、生成的命令、访问的资源都不可预测。沙箱等于给了它一块专用的操作台：台面有防溅挡板（文件系统隔离），有排水道（网络限制），台边还有摄像头（行为日志）。你在台面上怎么切都行，但别想弄脏客厅、别想用厨房之外的水龙头。这样一想，沙箱的核心价值就很清楚了：它允许你给 Agent 足够的操作空间，同时又把你真正在乎的东西保护起来。

1.3 一个能用的沙箱，最少要管住这四件事

我整理过一个表，每次配置沙箱都照着这几项过一遍，基本不会漏：

这四件事对应着四个问题：它动得了你的数据吗？它能往外传信息吗？它会把机器搞瘫吗？它能借助内核漏洞跳出去吗？只要这四个问题都有明确答案，你的沙箱就算有了骨架。

1.4 沙箱不是虚拟机，别搞混

虚拟机是把一台电脑完整地模拟出来，有虚拟 CPU、虚拟内存、虚拟硬盘，里面跑一个完整的操作系统。沙箱不做这些，沙箱不给 Agent 单独的硬件，只是给 Agent 所在进程套上限制，让它以为自己在一个安静的小房间，实际上共用着宿主机的内核和硬件。

这个区别很重要。虚拟机重、启动慢，但隔离彻底；沙箱轻、启动快，但逃逸的理论风险更高。对 Agent 场景来说，绝大多数任务不需要一台完整的虚拟机，沙箱在轻量和够用之间拿捏得刚好。很多人把两者混为一谈，结果要么嫌重不敢用，要么以为沙箱像虚拟机一样绝对安全——这两种判断都误事了。

2. 为什么 Agent 这种"会自己动手"的程序，尤其离不开沙箱

2.1 Agent 和传统脚本的本质区别：命令不是人写死的

传统的自动化脚本，每一步都是开发者手工写出来的。命令就算再危险，至少在提交之前过了一遍人的脑子，你为自己的决定负责。

Agent 完全不是这个逻辑。它的工作链路是：大模型理解任务，生成计划，通过工具调用接口去执行操作，然后再观察结果，继续下一轮。也就是说，真正被执行的命令是模型根据上下文现编出来的，不是人逐字写好的。命令本身可能来自用户模糊的表达，也可能来自一份被污染的网页内容，就算模型在大多数时候表现得很好，只要一次判断失误，执行的后果就是实打实的系统操作。

我在社区里看到最多的例子就是：Agent 被要求"清理一下临时文件"，模型图省事，直接拼出了一条递归删除命令，范围还写错了，把项目根目录也带了进去。没有沙箱，这一下就够人难受好几天。

2.2 没有沙箱时，Agent 闯祸的四种常见姿势

我见过的真实事故，大致可以分成四类，这里列出来大家可以对号入座：

• 文件读写事故：Agent 读走配置里的数据库密码，或者误删了不该删的文件。这类最常见，根源在于"文件系统权限给得太宽"。
• 网络外泄事故：Agent 在对话中收到了内部资料，再通过某次网络请求把它们发出去。更隐蔽的是，模型本身被提示词注入，诱导它主动外传数据。
• 资源耗尽事故：Agent 写了一个带死循环的小程序并执行，CPU 和内存一路飙高，把同一台机器上的其他服务拖垮。
• 越权横向移动：沙箱没做进程和网络隔离，Agent 执行的代码能访问同内网的其他机器，等于给攻击者留了一条从代码到内网的通道。

这四类事故，根子上都是同一个问题：Agent 的自主行动范围等于宿主系统的行动范围，它能误伤的面积太大。

2.3 最小权限原则：别给 Agent"除了它不该要的，其他都给"

安全里有个老掉牙但极其关键的原则叫最小权限：每个程序只拿到完成自身任务所必需的那部分权限，不多给。这个原则放在 Agent 身上尤其适用，因为 Agent 的调用方式决定了它经常是基于概率决策的，不是一个百分之百可靠的程序。

你给 Agent 一个能删全盘的 shell，那它一旦"想"删全盘，你没有任何挡得住的兜底；你只给它一个能操作临时目录的接口，那就算它彻底走火入魔，造成的损失也极其有限。沙箱的本质，就是把最小权限原则变成技术上的强制约束，不是靠模型自觉，而是让越界动作在系统层面直接失败。

2.4 Agent 的工具调用机制，恰好把危险点集中在了沙箱边界上

现在的主流 Agent 框架都支持工具调用，模型输出一个结构化的函数调用，后台代码负责真正执行。很多人误以为这个机制天然安全，错。工具调用只是在"生成命令"和"执行命令"之间画了一条线，但执行器的权限如果没有被收住，这条线约等于没有。

好的架构是：工具调用层保持很薄，真正的执行逻辑放在沙箱外部——意味着沙箱里允许暴露什么工具、以什么身份暴露、能访问哪些资源，全部由外围代码显式控制。模型只能调用你允许的工具，工具只能作用在沙箱边界之内。这样一来，模型误导、提示注入、越权操作都会被挡在执行层之外。

3. 沙箱实现方案怎么选：从重到轻，各有主场

3.1 容器级沙箱：当下最普遍的起点，隔离和便捷的平衡点

很多人一上来就想到容器。容器今天能成为 Agent 沙箱的主流方案，靠的不是虚拟化，而是内核自带的命名空间和资源组机制。容器内进程看到独立的文件系统和进程列表，CPU、内存、进程数又受到硬性限制，启动速度还快，几秒钟就能拉起一个干净环境。

我建议刚接触 Agent 安全的人，从容器级沙箱起步。它不需要改内核，不用额外维护虚拟机镜像，对模型生成的代码来说隔离力度也够用。而且生态成熟，镜像管理、日志收集、生命周期清理都有现成工具链。代价是容器共享宿主机内核，如果宿主内核本身存在漏洞，理论上存在逃逸可能。这个问题后面我会展开说。

不少团队还会在容器外面再包一层更严格的安全内核，把系统调用都在用户态做一遍检查，这样即便一个危险的系统调用被发出，也会在执行前被拦截。这类方案比普通容器更接近"高安全隔离"的水平，代价是性能损耗和实现复杂度，适合应对不可信代码、多租户场景。如果你做的是对外平台的 Agent 执行服务，这一步值得考虑。

3.2 轻量进程级沙箱：不想上容器时的快速选择

有些场景只是想让一个工具临时跑一下，不想动容器引擎，那还有一类更轻的选择：用操作系统直接提供的隔离机制，单独把一个进程的权限收紧。

比如可以给 Agent 的执行进程设置一个受限的文件系统视图，把它看到的根目录切到一个空壳目录，再把网络权限剥夺掉。这类方案启动几乎无感，适合平时自己机器上快速实验。缺点是隔离维度没有容器完整：进程间隔离、网络隔离、文件系统重定向都得手工调，配置错了容易产生"看起来隔离了，实际还裸奔"的错觉。我见过有人只切了文件系统视图，忘了关网络，Agent 照样能往外发请求。

如果你只是想跑个几秒钟的小实验，不想引入太重的基础设施，这个方案完全可用。一旦 Agent 的权限开始变大、任务开始涉及敏感数据，我建议还是往容器方案迁移。

3.3 语言级沙箱：执行字节码，而不是执行原生进程

第三种思路很有意思，干脆不让 Agent 生成的代码以原生进程的方式运行，而是编译成一种中间字节码，在一个解释器或虚拟机里执行。字节码本身没有能力直接发起系统调用，所有操作都要通过一层受限的 API 桥接出去。

这种方案启动速度能压到毫秒级，一个进程里可以跑成千上万个互不干扰的"小沙箱"，非常适合插件系统、代码执行服务这类并发量大的场景。缺点也明显：不是所有语言和生态都能编译成这种字节码，涉及操作系统底层能力、高性能计算、复杂 I/O 的程序，在这类沙箱里会束手束脚。

对 Agent 本身来说，如果你只是想在工具调用场景里安全地执行一段"不太可信"的代码，语言级沙箱值得研究；但如果你要跑完整的 Agent 工具链，容器方案会更接近现成可用的状态。

3.4 几种方案的取舍，我总结成了一张表

做选型时别只看隔离强度最高的那个，还要算上团队维护成本。先想清楚一个问题：你最坏的情况下，Agent 闯祸会造成什么后果？如果是自己本地实验，容器起步足够；如果是平台对外服务，再往上加安全容器和审计系统不迟。

4. 实操：给一个会写代码并执行测试的 Agent 套上容器沙箱

这一节我写一个能直接照着用的最小方案。我们不绑定具体的容器引擎品牌，命令用通用的<容器引擎>表示，读者在自己环境里替换成实际使用的引擎名称即可。这个示例的目标场景是：一个 Agent 能写代码、能跑测试、能操作专属工作目录，但碰不到宿主机的其他文件，连不了网络，也不能把资源耗尽。

4.1 先定边界，再写配置

动手前先列一下这个 Agent 的权限边界，这一步比写命令重要得多：

• 文件系统：宿主机的/data/jobs/A目录映射到沙箱内的/workspace，Agent 只能读写这个目录。
• 网络：默认断开，Agent 连外网都不需要。
• 系统资源：内存上限给 1GB，CPU 上限 1 核，进程数上限 128。
• 用户身份：用一个非特权用户执行命令，不要用管理员身份。

之所以把网络直接断开，是因为演示场景里 Agent 只需要在本地跑测试，不需要访问任何外部服务。现实中的 Agent 可能需要联网查资料，那就在第 5 章讲附加防线时再放开。

4.2 准备一个精简的执行环境

为了让沙箱内外的依赖一致，我通常先准备一个精简执行镜像。这里用一段示例文件，里面包含 Python 运行时和一些基础测试工具。日常你可以把项目需要的支持库提前装进去，避免沙箱里现装。

注意一个关键诀窍：安装依赖的步骤要放在构建镜像的阶段完成，不要在运行阶段让沙箱联网安装。构建阶段可以联网，运行阶段保持断网，这样既满足了依赖需求，又保住了网络隔离。

4.3 拉起沙箱容器

接下来是核心命令。每次 Agent 要执行任务，就用下面的方式启动一个一次性容器：

<容器引擎> run --rm \ --name agent-sandbox \ --user 10001:10001 \ --read-only \ --tmpfs /tmp \ --network none \ --memory 1g \ --cpus 1 \ --pids-limit 128 \ -v /data/jobs/A:/workspace \ <基础镜像> \ bash -c "cd /workspace && python run_agent.py"

逐项解释一下。--rm表示容器退出后自动删除，不残留垃圾；--user 10001:10001指定沙箱内使用非特权用户；--read-only把整个根文件系统挂成只读，这是防止 Agent 乱改系统文件的关键；--tmpfs /tmp单独给/tmp一个内存临时盘，因为很多工具运行时需要可写的临时目录，而根文件系统已经是只读的；--network none直接拿掉网络；后面的--memory、--cpus、--pids-limit分别对应内存、CPU、进程数量上限。

这里README也许有人会问：/workspace没有标成只读，因为 Agent 必须在里面写代码和测试结果，所以它是唯一可写区域。整个设计的思路就是：其他任何路径对它都是只读的，只有工作目录和内存临时盘能写。

4.4 验证沙箱是否真的在起作用

配置写完之后，一定要做验证，而不是假设它有效。我会在容器里跑几条破坏性命令，确认每一层都被挡掉：

我见过不少同学配置完直接跳过验证，结果后来出了事才回头查。这个步骤花不了五分钟，但能让你对沙箱的每一层边界有确切把握。

4.5 结果取回要设计好出口

沙箱跑完了，结果怎么带出来？不建议让 Agent 直接写宿主机路径，也不建议在容器里开放任意端口。最稳妥的做法是：Agent 把输出统一写到/workspace/output目录，宿主机通过挂载卷直接读取，或者容器退出后用统一的收集命令把这个目录内容搬到长期存储。

这里有个细节：挂载卷是双向的，Agent 能写到的宿主机目录，就是它实际能影响的宿主机目录。所以挂载的路径越少越好，宁可多准备几个专用目录，也不要图省事把一个大的数据根目录直接挂进去。我见过有人把用户主目录整个挂进去，结果 Agent 一次误操作，主目录下的配置文件被清了个干净。

5. 只装沙箱还不够，这四道附加防线建议一起上

5.1 网络按需放行，默认关死

沙箱里的网络策略，我的习惯是"默认关死，白名单放行"。Agent 如果需要访问特定 API，不要直接开全量网络，而是走一层可控的代理或网关。在容器方案里，可以先保持--network none，然后把可能用到的域名或 IP 加到允许列表里，再通过代理转发。

这样哪怕 Agent 被提示词注入，想要外传数据，它也只能访问白名单内的地址。攻击者要往自己服务器传文件，会被拦在代理层之外。这个设计等于给数据外泄的路径上了一道闸门。

5.2 文件系统只读化，把"读"变成默认许可

沙箱内文件系统的推荐姿势是"默认只读，按需可写"。根文件系统只读，需要写的地方单独用卷或临时盘给。这样即使是 Agent 自己生成的恶意代码，在系统目录里也翻不出浪花。

注意临时目录的选择很讲究。我一开始只设置了根文件系统只读，把临时目录直接映射到宿主机/tmp，结果 Agent 往里面写入了大量临时垃圾。改成--tmpfs /tmp之后，每次容器退出，临时盘里的内容就自动清空，既干净又隔离。

5.3 高危操作改成"申请制"：危险命令不直接放行

沙箱只能限制"能不能做"，但有些动作即使能做成，也值得让人类再确认一次。比如删除文件、修改配置、安装依赖、发布内容，这些应该走一个审批层：Agent 发出申请，系统展示给维护者，确认后才执行。

这个审批机制不一定很复杂，一个简单的接口就够了：Agent 真正执行删除命令前，先调用一个封装函数，把将要执行的命令发到审批队列。等审批通过，再真正执行。这样做的一个额外好处是，你积累了一批 Agent 行为日志，后续优化提示词和权限策略都有依据。

5.4 审计日志要放在沙箱外面

沙箱自身的日志有个致命问题：如果只存在沙箱里面，容器一销毁日志就跟着没了。而 Agent 真的闯祸时，日志恰恰是第一手的排查证据。我现在的做法是：沙箱内的标准输出、操作记录统一转发到宿主机侧的日志收集进程，再写入独立的日志存储。审计日志的权限设置成只追加，普通操作者没有删除权限。

加一句经验：给沙箱加的每一层防护，都要能独立验证，不要说"应该有用"。日志这一层很简单，跑完一次任务就去看看外置日志是否完整记录了每一步，确认以后再做别的。

6. 我在真实使用中踩过的几个沙箱坑

6.1 权限映射没有理清，挂载目录直接拒绝访问

容器内指定了非特权用户，但挂载进来的/workspace目录属主和这个用户 ID 对不上，结果 Agent 一写文件就报权限不足。这个现象挺有迷惑性，因为从外面看挂载目录权限明明是对的。

后来排查发现，问题出在 UID 映射上：宿主机上的目录属主是 1000，容器里的用户 ID 是 10001，两边根本不匹配。解决办法是手动把宿主机目录的属主改成容器内用户对应的 UID，或者在启动容器时用参数把用户 ID 映射到宿主机某个已有用户。这种问题第一次遇到会折腾很久，建议在验证阶段就把"能不能正常写文件"列为第一条测试项。

6.2 沙箱默认断网，结果依赖装不上

最早我把沙箱的网络直接关死，任务一跑就报错，因为运行脚本需要装额外的库。当时我还没有把依赖准备阶段和运行阶段分开，于是陷入两难：开网络怕不安全，关网络没法装库。

后来我改成两阶段策略：构建镜像时可以联网，把依赖全部写进镜像；运行沙箱时保持断网。如果某个任务确实需要临时装包，就单独开一个"安装专用容器"，装好之后把产物复制到共享卷，再拿去运行沙箱里用。这个模型既保住了网络隔离，又解决了依赖问题。

6.3 资源限制设得太宽，差点把宿主机搞崩

我给沙箱设置内存上限 8GB、CPU 上限 4 核，想着"给足资源跑得快"。结果同时起了好几个这样的沙箱，宿主机直接进入高负载，其他服务都开始变慢。排查下来才发现，单个沙箱的限制虽然不算离谱，但多个沙箱叠加起来不受控。

资源限制要按任务实际需求去定，而不是按"跑得快"去给。我现在的默认值是内存 512MB、单核 CPU、128 进程数，绝大多数 Agent 任务都能完成，跑不动再加也不迟。同时我还在宿主机层面对沙箱并发数做了队列控制，防止任务同时涌进来。

6.4 时间问题和随机数问题，影响比想象中大

有些 Agent 生成的代码需要时间戳、随机数，但沙箱里面/etc是只读的，时间配置和随机源如果没处理好，程序会表现得"玄学失败"。比如某次测试脚本生成 UUID 时突然报错，就是因为沙箱内没有正确的随机设备挂载。

处理方式是在沙箱配置里显式保留随机设备入口，并把时区设置成宿主一致，或者让 Agent 的代码统一通过环境变量来获取时间信息，不依赖系统默认配置。这类小问题本来不会暴露，但沙箱环境跟常规开发环境差异大，只要程序里用到底层设施就很容易踩中。

6.5 沙箱逃逸概率低，但不能当它不存在

最后说一个容易被忽视的事情：容器沙箱不是绝对安全。内核本身存在漏洞的时候，沙箱内的进程理论上可能利用漏洞影响宿主机。虽说实际逃逸成本很高，攻击者也未必盯着你的 Agent 实例，但作为工程实践，我们不能把"逃逸概率低"当成"不可能"。

要做的就是尽量避免叠满风险：不要把宿主机根目录或敏感设备挂进沙箱，不要把容器管理接口的套接字暴露给沙箱进程，保持宿主内核及时更新。这也是为什么我总是强调，沙箱只是防线之一，真正的高安全场景需要"沙箱 + 最小权限 + 网络白名单 + 独立审计"一起上，而不是指望单点防护。

我自己从最开始建一个普通文件夹当"沙箱"，到后来用容器做只读隔离，再到加上网络白名单和审计日志，这个演进过程踩了不少坑，但也越来越确信一件事：沙箱不是拖慢开发的枷锁，反而是让 Agent 能大胆执行任务的底气。给 Agent 划清楚"哪里可以乱来，哪里绝对不能碰"，它才能真正放开手脚帮你干活，你也能睡个踏实觉。如果你现在刚开始做 Agent 集成，我建议不要去追求最重的方案，先用一个只读文件系统加断网环境的容器沙箱跑起来，把边界理清楚，再一步步把防线补全。