企业官网建设流程全解析

写这篇东西的起因很简单：我在团队里负责给几个实验性质的AI Agent做安全收口，结果被“沙箱”这两个字折磨了大半个月。网上搜了一圈，讲理念的很多，讲怎么落地到代码和配置上的很少。所以我把自己的踩坑记录整理出来，作为一个阶段性的总结，希望能帮到正在做类似事情的人。

先说清楚这篇文章解决的问题：当你的Agent需要调用工具、执行脚本、访问网络时，怎么给它一个既不影响宿主环境、又不至于什么都干不了的运行边界。适合正在折腾Agent开发、对安全问题有点敏感、但不想从零研究内核机制的后端和算法同学参考。

1. 核心思路：Agent需要的是一整套“行为围栏”

1.1 沙箱的边界到底划在哪里

很多人的第一反应是：沙箱 = 开个Docker容器，把Agent丢进去跑。这个直觉方向是对的，但距离“能落地”还差得很远。

我核心的认知转变是：Agent沙箱不是一个隔离技术问题，而是一个“权限设计”问题。容器只是承载权限策略的载体，真正决定安全边界的是你在容器内外配置的那一整套限制——文件系统范围、网络访问范围、可执行系统调用范围、资源上限、上下文生命周期。

打个比方，把Agent想象成一个新入职的实习生。你给他一把独立的办公桌（容器隔离），这解决了“他不能随便翻别人抽屉”的问题；但你还得决定他能进哪些会议室（网络策略）、能碰哪些系统（API权限）、能领多少预算（配额）、工作多久必须下班（超时销毁）。这些规则合在一起，才是一个完整沙箱。

所以动手之前，先别急着写docker run，先把你手头Agent的能力清单盘出来：它能执行什么语言脚本？它会不会调用宿主机的shell？它要访问哪些外部API？它需要写盘吗？写到哪里？这些问题的答案直接决定沙箱的复杂程度。

1.2 三个必须隔离的维度

我最终把隔离维度收敛成三条，后续所有设计和排障都围绕它们展开。

• 计算与存储隔离：Agent的运行环境要独立，临时文件、缓存、依赖都不能污染宿主环境。这层用容器或轻量虚拟机实现，重点在文件系统的只读根目录和临时目录的挂载策略。
• 网络隔离：不能让Agent任意访问内网，也不能让它把内网数据带出去。这层靠命名空间和iptables策略控制，是绝大多数人在初期会忽略的。
• 权限隔离：Agent能调用哪些API、能以什么级别的凭证调用，需要做一层“身份剥离”。沙箱内的Agent本身不应拥有任何真实密钥，所有密钥由外层沙箱管理进程按需注入，用完即焚。

这三个维度缺一不可。只做了第一维度的沙箱，本质上只解决了一半问题，后面我会详细讲为什么。

2. 技术方案选型：容器为主、系统调用为辅

2.1 为什么不是虚拟机

如果只看安全性，虚拟机当然是更硬的边界。但我们的实验Agent需要频繁迭代依赖，每次起一个虚拟机再做快照，存储和启动耗时都扛不住。容器的启动速度以毫秒计，虚拟机以秒计，对Agent这种“每次任务都可能要新环境”的使用方式来说，差距是数量级的。

所以我的选择是：默认容器 + 必要的系统调用过滤 + 宿主侧资源管控。容器解决文件系统和进程的可见性，seccomp解决系统调用的可用性，cgroups解决资源占用的上限。

具体到工具链，我没有自己造轮子，而是基于常见的容器运行时做了一层薄封装。重点配置了以下几项：

2.2 关键参数与资源配额的思考

资源配额这块，很多人随手设置就完事，但实测下来猫腻很多。

先看CPU。容器默认的CPU限制是配额制，比如cpus=1表示最多占用1个核心，但如果宿主很闲，容器可以飙到多核心。对沙箱来说，我倾向于把CPU限制做成两层：先设置cpus上限，避免单个Agent拖垮宿主；再设置cpu配额，避免Agent死循环时把整台宿主的调度器卡出明显抖动。

内存这块更要小心，我见过Agent写了一段险些内存溢出的代码，直接申请了几个G的匿名页，把宿主内存吃光，OOM Killer介入后连带其他业务容器一起遭殃。所以memory的硬限制必须设，并且要配合memory-swap做二次约束，只限制内存不限制交换分区，等于白设。

文件描述符数量和可创建的进程数也要管，默认的1024个fd对普通脚本够用，但Agent一旦批量操作文件或并发起子进程，很容易触底。建议直接把nofile和nproc用ulimit提到一个合理值，同时用cgroups的pids限制去兜底进程总数，因为ulimit是per-process的，并不限制进程总数。

2.3 镜像与依赖的防呆设计

镜像构建是另一个容易踩坑的地方。常见的做法是直接把一个满配的Python镜像丢给Agent用，但满配镜像意味着攻击面大——里面装了sed、awk、curl、python、pip、gcc等等，对Agent来说这些都可能成为被利用的工具。

我的策略是：镜像只保留业务必需的运行时和库，所有与任务无关的包一律不装。同时把包管理器默认索引指向内网私有源，避免Agent在沙箱里偷偷安装依赖。这个防呆细节看着不起眼，但能挡掉大量“Agent为了完成任务自行装包”的失控行为。

3. 实操过程：从0搭一个可用的Agent沙箱

3.1 基础环境与启动流程

一个典型的Agent任务启动流程，我拆成下面几步，每一步都有明确目的。

# 1. 拉起容器，不暴露任何端口，禁止出网 docker run -d --name agent_run_$TASK_ID \ --network none \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size=256m \ -m 1g --memory-swap 1g \ --cpus 1 \ --pids-limit 256 \ agent-base-image:latest \ python /runner.py

第一行--network none是整条命令里最重要的一次决定。初始状态不让Agent碰任何网络，需要访问外部资源时由外层调度进程通过标准输入或临时文件注入结果，而不是让Agent自己发请求。这么做的好处是Agent永远没有主动外联的能力，它只能拿到调度器“喂”给它的数据。

--read-only配合--tmpfs的意思是：根文件系统只读，只有/tmp有写权限但不可执行程序。这样脚本执行产生的中间文件有地方去，但Agent没法在/tmp里写一个可执行文件再运行，堵死了很多绕过手段。

3.2 工具调用与密钥管理的处理

Agent通常通过工具调用和外界交互。我的做法是把所有工具调用从Agent进程内部挪到外部：Agent只输出一个结构化意图，由宿主侧的工具执行器去实际执行。这样密钥永远不会出现在Agent的进程环境变量里，工具执行结果也只通过受限通道回传。

具体来说，我在宿主侧维护了一个工具白名单映射，类似这样：

TOOL_WHITELIST = { "search": {"exec": "internal_search", "timeout": 10, "network": "allow_listed"}, "calc": {"exec": "python -c", "timeout": 5, "network": "none"}, "fetch": {"exec": "http_client", "timeout": 15, "network": "allow_listed"}, }

每次Agent请求调用工具，外层进程根据白名单校验参数格式、注入对应级别的临时凭证、设置单次超时，然后执行。这比让Agent直接拿一个高权限的API Key要安全得多。

3.3 网络白名单的具体落地

网络这块我最终采取了“双重钳制”。容器侧先用--network none把所有流量挡掉，然后在宿主的调度进程里，为需要网络的任务单独起一个代理容器，这个代理容器只开放特定目标地址和端口。

代理容器的iptables策略样例（简化版）长这样：

iptables -A OUTPUT -d 10.1.2.3 -p tcp --dport 443 -j ACCEPT iptables -A OUTPUT -j REJECT

细心的读者会发现，只限制目标的IP和端口还不够，DNS解析会泄露你访问了哪个域名。所以在真实配置里，我会把DNS出口也限制到指定的内网解析器，并且只允许查询白名单域名，避免Agent借DNS做数据外带。

3.4 日志采集与任务回放

沙箱必须可观测。我在每个容器退出后保留三样东西：标准输出日志、容器内产生的临时文件快照、以及Agent对外部工具的全部调用记录。有了这三样，任何一次任务异常都能回放。

回放是个好东西。某次Agent执行的任务结果诡异，我把当时的工具调用序列重新跑了一遍，发现是工具参数里被注入了异常字符导致解析错位，问题三分钟定位。没有回放能力，这种偶现问题会消耗一下午。

4. 常见问题与排查笔记

4.1 为什么Agent“越狱”比你想象的容易

一个残酷的结论：只做容器隔离、不做系统调用过滤的沙箱，在多数场景下约等于没有，因为容器共享宿主内核，Agent只要能触发特权系统调用，就有机会影响宿主的全局状态。

实际测试中我用一段很短的代码就触发了内核计数器抖动。排查后加上了seccomp过滤，核心是禁止容器内进程发起mount、ptrace、reboot、kexec_load等系统调用。为了省事，很多方案直接采用seccomp default，但注意default策略会直接影响运行时性能，建议做成白名单模式，只放行业务确实需要的调用。

这里要提一个非常容易踩的偏门：即使你加了seccomp，容器内的用户命名空间映射如果配置不当，某些提权路径依然存在。稳妥的做法是关掉容器内的user namespace映射特权，不让Agent创建需要CAP_SYS_ADMIN权限的子命名空间。

4.2 沙箱内文件持久化的需求怎么处理

实验初期，Agent经常需要读一些公共数据集。如果把数据放根文件系统，镜像体积会膨胀到不可接受；如果放tmpfs，每次启动都要重新灌入。

我的折中方案：数据只读挂载。宿主侧维护一份共享只读目录，容器启动时以绑定挂载方式只读挂入。Agent可读不可写，数据也不会随容器销毁丢失。注意这个目录的宿主人目录权限要收缩，否则容器内的Agent可以通过路径遍历读到宿主其他文件。

4.3 幽灵进程与资源清理

沙箱运行一段时间后，最常出现的问题是“容器退了，但容器内的子进程还在宿主上挂着”。原因通常是Agent用后台方式启动了长驻进程，容器主进程退出后，这些子进程被收养成了孤儿进程，但没有被销毁。

我的做法是在创建容器时就指定init进程，让init作为1号进程接管所有子进程的回收。同时写一个定时巡检脚本，把超过预定生命周期仍未退出的容器强制stop并删除。巡检脚本本身逻辑很轻，50行以内就能搞定，但它能挡住绝大多数资源泄漏。

4.4 超时与前端卡死的边界情况

Agent调外部工具时最容易出问题是“工具没有超时返回”。之前我遇到过Agent写了个脚本循环请求一个慢接口，工具执行器没有设单次超时，结果Agent一直等，又因为多轮循环把整个任务窗口拖爆。

排查后我在工具执行器里统一加了硬超时，超时直接杀掉工具进程并返回固定错误码给Agent，让Agent自行决定要不要重试。实测下来，Agent对“工具超时”的处理要比“工具无响应”理智得多，至少不会无限等下去。

5. 一些真实的经验与反思

如果你照着上面的方案在做，有几点经验我建议直接记进自己的方法论里。

• 沙箱的验收标准要包含“恶意Agent路径测试”。我每个月都会拿几段故意写坏的代码丢进沙箱跑一轮，验证文件系统、网络、进程资源三重隔离是否都还在。这类测试看起来不起眼，却是保证沙箱不过期失效的最好手段。
• 不要把安全寄托在“Agent很守规矩”上。Agent的目标是完成任务，它会想尽办法调用一切可用工具。你要做的不是教育Agent，而是让环境中根本不存在危险能力。
• 日志比配置更重要。一次任务后复盘时，日志的完整度直接决定排障效率。宁可多留日志也不要吝啬磁盘。

最后再分享一个我踩了两次才学乖的小技巧：每次改动沙箱配置，一定要在发布前跑一遍回归用例，并且把回归用例的结果留存对比。沙箱配置改动看起来是纯增量调整，实际上很容易因为一处小改动，比如多放开一个目录的写权限，埋下一个巨大的隐患，而这个隐患往往等一两周后某个异常任务出现时才暴露。把回归做成常态化，你就能在它变成事故之前，把它当成一次正常配置变更来处理。

写完这篇，我还想继续去补一个更细节的方向：沙箱内Agent的模型请求路径本身，需不需要单独分层管理。这个我还在实验，跑出结论了再回来更新。