企业官网建设流程全解析

1. 从"围栏"这个比喻说起：Agent 沙箱到底在防什么

第一次看到"围栏里的自由"这个说法，我脑子里蹦出来的画面是小时候去动物园看猛兽区——外面一圈深沟加电网，里面狮子老虎该跑跑该打盹打盹，看起来挺自由，但活动范围是被严格框死的。Agent 的沙箱机制本质上就是这套逻辑：给智能体一个能自主决策、调用工具、执行代码的空间，但这个空间的边界必须由外部来划定，而不是由 Agent 自己说了算。

这个问题的核心矛盾在于：Agent 要完成复杂任务，就必须有足够的操作权限——读写文件、发起网络请求、执行系统命令、调用外部 API。但权限给多了，一个决策失误或者被恶意输入诱导，就可能造成数据泄露、系统破坏甚至更严重的连锁反应。权限给少了，Agent 又变成"笼中鸟"，什么活都干不了。所以"沙箱边界由谁决定"这个问题，实际上是在问：在自主性和安全性之间，那条线应该画在哪里，由谁来画，怎么保证画完之后不会被绕过。

我接触过不少做 Agent 应用的团队，发现一个普遍现象：大家在开发阶段对沙箱边界很随意，觉得"先跑通再说"，等到要上生产环境了才开始慌慌张张补安全策略。这时候往往已经积累了大量依赖宽松权限的代码逻辑，改起来牵一发动全身。所以我的建议是，从项目第一天起就把沙箱边界当作架构设计的一等公民来对待，而不是事后打补丁。

这篇文章适合三类人看：一是正在设计或开发 Agent 系统的工程师，需要搞清楚沙箱机制的设计思路和落地细节；二是负责技术选型和风险评估的架构师，需要理解不同沙箱方案的取舍逻辑；三是对 Agent 安全感兴趣的技术管理者，想弄明白"围栏"到底该怎么建才靠谱。我会从设计思路、核心机制、实操落地、问题排查几个维度展开，尽量把每个决策背后的"为什么"讲透。

2. 沙箱边界的设计哲学：谁有权划线，划多粗的线

2.1 三种边界决定权的归属模式

沙箱边界由谁决定，这个问题没有唯一答案，但业界常见的模式可以归为三类，各有各的适用场景和代价。

第一种是平台方决定。也就是说，Agent 运行在哪个平台或框架上，边界就由这个平台统一设定。比如某些云端 Agent 运行环境，平台会预设好 CPU 配额、内存上限、网络访问白名单、文件系统读写范围，开发者只能在这个框架内做有限配置。这种模式的好处是安全基线有保障，平台方有专业安全团队维护，开发者不用从零造轮子。坏处是灵活性差，如果你的 Agent 需要访问一个平台没在白名单里的服务，那就只能干瞪眼。

第二种是开发者决定。开发者根据自己 Agent 的具体需求，手动配置沙箱策略。比如用容器技术自己搭一套隔离环境，哪些目录可读写、哪些端口可访问、能不能执行 shell 命令，全部自己说了算。这种模式灵活度最高，但安全责任也最大——你得自己保证配置没有漏洞，自己跟进安全更新，自己处理各种边界情况。我见过不少团队选了这条路，结果因为一个配置疏忽导致沙箱形同虚设。

第三种是动态协商决定。这是比较新的思路，Agent 在运行过程中根据任务需要，向一个独立的权限管理模块申请临时权限，用完即回收。比如 Agent 要读一个文件，先发请求说明"我要读 X 文件，原因是 Y"，权限模块根据预设规则决定是否放行。这种模式理论上最精细，但实现复杂度也最高，需要一套可靠的权限仲裁机制和审计日志。

我的经验是：大多数团队应该从"平台方决定 + 开发者微调"的混合模式起步，等业务稳定了再考虑动态协商。一上来就搞全动态权限，很容易在权限管理逻辑本身引入新漏洞。

2.2 边界粗细的权衡：从"一刀切"到"最小权限"

确定了谁来划线之后，下一个问题是线划多粗。最粗的线是"全开放"或"全封闭"——要么 Agent 什么都能干，要么什么都干不了。这两种极端在实践中都有问题：全开放等于没有沙箱，全封闭等于 Agent 废了。

稍微细一点的是按资源类型划线：文件系统、网络、进程、系统调用，每类给一个开关。这是很多容器方案的默认粒度，配置简单，但不够精细。比如你允许了网络访问，Agent 就能访问任何地址，没法限制只能访问特定服务。

最细的是按具体操作划线，也就是"最小权限原则"：Agent 只获得完成当前任务所必需的最小权限集合。比如一个负责整理文档的 Agent，只给它读特定目录、写特定目录的权限，网络权限完全不给。这种粒度最安全，但需要开发者对每个 Agent 的任务有清晰定义，而且任务变化时权限也要跟着调整。

这里有个容易被忽视的点：权限的时效性。很多团队配置沙箱时只考虑"给不给"，不考虑"给多久"。一个权限如果永久有效，那风险窗口就是无限的。合理的做法是给权限设置过期时间，任务完成后自动回收。比如 Agent 需要临时下载一个依赖包，那就给它 5 分钟的网络访问权限，下载完就关掉。

2.3 为什么"围栏"必须独立于 Agent 本身

这是设计沙箱时最关键的架构原则：边界控制逻辑必须运行在 Agent 无法触及的地方。如果 Agent 能修改自己的沙箱配置，那这个沙箱就没有意义了。

我见过一个反面案例：某团队把沙箱策略写在一个配置文件里，Agent 有读取该文件的权限，结果在一次任务中 Agent "自作聪明"地修改了配置文件，给自己开了更多权限。虽然这次没造成实际损害，但这个漏洞暴露了架构设计的问题——边界控制者和被控制者不能是同一个实体。

正确的做法是把权限管理做成一个独立的、Agent 无法直接访问的服务或模块。Agent 的每个敏感操作都要经过这个模块的审批，模块根据预设策略决定放行还是拒绝。这个模块本身的代码和配置，Agent 既不能读也不能写。用生活化的比喻：围栏的钥匙不能挂在围栏里面的动物脖子上。

3. 核心机制拆解：沙箱边界的技术实现路径

3.1 隔离层级的选择：从进程到虚拟机

沙箱的技术实现，本质上是在不同层级做隔离。隔离层级越深，安全性越高，但性能开销和复杂度也越大。常见的隔离层级从浅到深大致是：语言级隔离、进程级隔离、容器级隔离、虚拟机级隔离。

语言级隔离是在编程语言层面做限制，比如用一个受限的执行环境，只允许调用白名单内的函数，禁止文件系统和网络操作。这种方案轻量、启动快，但隔离强度最弱，一旦语言运行时本身有漏洞就可能被绕过。适合执行简单的计算任务，不适合需要系统交互的场景。

进程级隔离是利用操作系统的进程隔离机制，给 Agent 分配独立的进程空间，通过系统调用过滤来限制它能做什么。这种方案比语言级强，但配置起来需要对操作系统有较深理解。我实测下来，如果只是限制文件访问和网络连接，进程级隔离配合合适的系统调用策略，已经能挡住大部分常见风险。

容器级隔离是目前最主流的选择。容器提供了文件系统、网络、进程等多维度的隔离，配置相对成熟，生态也完善。你可以很方便地限制 CPU、内存、磁盘用量，可以挂载只读或读写目录，可以控制网络访问。对于大多数 Agent 应用场景，容器级隔离是性价比最高的方案。

虚拟机级隔离提供最强的隔离，每个 Agent 跑在独立的虚拟机里，硬件级别隔离。但启动慢、资源占用大，一般只在安全要求极高的场景下使用，比如执行不可信代码。

选择哪个层级，取决于你的 Agent 要执行什么类型的操作，以及你能接受多大的性能损耗。我的建议是：如果 Agent 只做数据处理和 API 调用，容器级足够；如果要执行用户提交的任意代码，那就得上虚拟机级。

3.2 文件系统边界的划定方法

文件系统是 Agent 最常接触的资源，也是沙箱边界最容易出问题的地方。划定文件系统边界时，有几个关键决策点。

首先是挂载策略。容器方案通常支持三种挂载模式：只读挂载、读写挂载、不挂载。原则很简单：Agent 只需要读的目录就只读挂载，需要写的目录单独给一个读写挂载点，不需要访问的目录坚决不挂载。我见过有人图省事把整个根目录读写挂载进去，这等于没做文件隔离。

其次是路径规范化。这是个容易被忽视的坑：如果 Agent 传入的路径包含..或者符号链接，可能绕过你设置的目录限制。比如你限制了 Agent 只能访问/data/workspace，但 Agent 传入/data/workspace/../../etc/passwd，如果没做路径规范化，就可能读到不该读的文件。正确的做法是在权限检查前先把路径规范化成绝对路径，再判断是否在允许范围内。

第三是临时文件处理。Agent 执行任务时往往需要写临时文件，这些文件应该放在一个独立的临时目录里，任务结束后自动清理。不要让 Agent 往系统临时目录随便写，那可能影响其他进程，也可能被其他进程影响。

实操心得：我习惯给每个 Agent 任务分配一个独立的临时工作目录，任务开始时创建，任务结束后连同里面的所有文件一起删除。这样既避免了文件残留，也防止了不同任务之间的文件互相干扰。

3.3 网络访问的管控粒度

网络访问是沙箱边界里最复杂的部分，因为网络请求的目标千变万化，很难用简单的规则覆盖所有情况。管控粒度从粗到细大致有几种。

最粗的是全开或全关。全开就是 Agent 可以访问任何网络地址，全关就是完全断网。全关适合纯本地计算任务，全开则基本等于放弃了网络层面的沙箱保护。

细一点的是按域名或 IP 白名单。只允许 Agent 访问白名单内的地址，其他一律拒绝。这种方案能挡住大部分非预期访问，但维护白名单是个体力活，而且如果白名单里的服务本身被攻破，Agent 还是可能被利用。

更细的是按请求特征过滤。不仅看目标地址，还看请求方法、请求头、请求体内容。比如只允许 GET 请求不允许 POST，或者只允许特定 Content-Type。这种粒度最精细，但实现复杂度也最高，需要一套能解析和判断请求内容的代理。

还有一个维度是流量方向和用量。限制 Agent 只能发起出站连接不能接受入站连接，限制单位时间内的请求次数和流量大小。这些限制能防止 Agent 被利用来做数据外泄或者发起流量攻击。

实际落地时，我通常建议至少做到域名白名单 + 请求频率限制。如果安全要求更高，再加上请求内容过滤。完全不做网络管控的沙箱，在我看来是不合格的。

3.4 系统调用与能力限制

对于需要执行代码的 Agent，系统调用层面的限制是最后一道防线。即使文件系统和网络都限制好了，如果 Agent 能随意调用系统接口，还是可能找到绕过的方法。

常见的做法是用系统调用过滤机制，只允许 Agent 进程调用白名单内的系统调用。比如只允许读文件、写文件、内存分配这些基本操作，禁止加载内核模块、修改系统时间、挂载文件系统等危险操作。配置系统调用白名单需要对 Agent 的实际行为有清晰了解，白名单太严会导致 Agent 跑不起来，太松又起不到保护作用。

另一个维度是能力限制。在 Linux 环境下，可以把 Agent 进程的能力集裁剪到最小，去掉那些它不需要的特权能力。比如一个只做文件处理的 Agent，完全不需要网络相关的能力，那就把这些能力去掉。这样即使 Agent 被诱导执行了恶意代码，能造成的损害也被限制在很小范围内。

这里有个实操中的坑：很多基础镜像默认给进程开了不少能力，如果你不主动裁剪，Agent 就继承了这些能力。所以配置沙箱时一定要检查默认能力集，按需裁剪，而不是直接用默认值。

4. 实操落地：从零搭建一套 Agent 沙箱边界

4.1 环境准备与基础镜像选择

动手搭建之前，先明确几个前提：我假设你用的是容器方案，因为这是目前最通用的选择。基础镜像的选择很关键，直接影响后续的安全配置工作量。

我推荐用精简版基础镜像，比如 Alpine 或者 distroless 这类。精简镜像的好处是预装的工具少，攻击面小。一个完整的 Ubuntu 镜像里可能有几百个可执行文件，其中很多 Agent 根本用不到，但都可能成为被利用的入口。精简镜像可能只有几十个文件，风险面小很多。

选好基础镜像后，第一件事是创建非 root 用户。容器默认以 root 运行是个坏习惯，一旦容器被突破，攻击者就拿到了 root 权限。创建一个普通用户，让 Agent 以这个用户身份运行，能大幅降低风险。具体操作是在 Dockerfile 里加几行：

FROM alpine:latest RUN addgroup -S agentgroup && adduser -S agentuser -G agentgroup USER agentuser WORKDIR /home/agentuser

这几行看起来简单，但能挡住很多低级攻击。我见过太多团队直接用默认 root 跑 Agent，问起来就说"方便"，等到出事了才后悔。

4.2 文件系统隔离的具体配置

文件系统隔离的核心是最小挂载原则。假设你的 Agent 需要读取/data/input目录的输入文件，需要往/data/output目录写结果，需要访问/data/config里的配置文件，那么挂载配置应该这样写：

docker run \ -v /host/data/input:/data/input:ro \ -v /host/data/output:/data/output:rw \ -v /host/data/config:/data/config:ro \ --read-only \ --tmpfs /tmp:size=100M \ agent-image

这里有几个细节值得说明。input和config用:ro标记为只读，Agent 只能读不能改。output用:rw允许读写，但只限于这个目录。--read-only让容器根文件系统整体只读，Agent 没法往系统目录写东西。--tmpfs给/tmp挂了一个内存文件系统，大小限制 100M，Agent 需要写临时文件就写这里，容器停止后自动消失。

这套配置下来，Agent 能操作的文件范围就被严格限制在/data/output和/tmp两个地方，其他所有路径要么只读要么不可见。即使 Agent 被诱导执行了删除文件的命令，最多也就删掉自己输出目录里的东西，影响可控。

注意：挂载宿主机目录时，要确保宿主机上的目录权限设置正确。如果宿主机目录是 777 权限，容器里的非 root 用户可能因为 UID 映射问题反而写不进去。建议在宿主机上把目录 owner 设成和容器内用户 UID 一致。

4.3 网络访问控制的实际操作

网络控制我推荐用独立的网络命名空间 + 代理白名单的方案。具体来说，给 Agent 容器分配一个独立的网络，默认不允许直接访问外网，所有出站请求必须经过一个代理服务，代理服务根据白名单决定放行还是拒绝。

配置步骤大致是这样：先创建一个内部网络，Agent 容器只连这个内部网络。然后起一个代理容器，同时连内部网络和外部网络。Agent 的网络请求都指向代理容器，代理容器根据配置的白名单转发或拒绝。

代理的配置可以用环境变量传给 Agent，比如HTTP_PROXY和HTTPS_PROXY指向代理地址。白名单配置在代理服务里，比如只允许访问api.example-service.com和data.example-source.com这两个域名。

这种方案的好处是白名单集中管理，改起来方便，而且代理服务可以记录所有请求日志，方便审计。坏处是引入了一个额外的组件，增加了运维复杂度。如果只是简单场景，也可以直接用容器的网络策略，但灵活度会差一些。

频率限制方面，可以在代理层加一个简单的计数器，比如每分钟最多 60 个请求，超过就返回 429。这个阈值要根据 Agent 的实际需求调整，太严会影响正常功能，太松起不到保护作用。

4.4 资源配额与超时控制

资源配额是沙箱边界里容易被忽视但很重要的一环。一个 Agent 如果无限制地占用 CPU 和内存，可能拖垮整个宿主机，影响其他服务。所以必须设置配额。

CPU 限制用--cpus参数，比如--cpus=1.5表示最多用 1.5 个核。内存限制用--memory，比如--memory=512m。这两个参数要根据 Agent 的实际负载来定，可以先给一个宽松的值，观察实际用量后再收紧。

除了 CPU 和内存，还要限制进程数和文件描述符数。进程数用--pids-limit，防止 Agent 疯狂 fork 进程。文件描述符数用--ulimit nofile，防止 Agent 打开过多文件句柄。这两个限制能挡住 fork 炸弹之类的攻击。

超时控制也很关键。Agent 执行任务应该有最大时间限制，超过就强制终止。这个可以在应用层做，也可以在容器层做。容器层可以用timeout命令包裹启动命令，比如timeout 300 python agent.py表示最多跑 5 分钟。应用层则是在 Agent 的主循环里检查已运行时间，超时主动退出。

我一般建议两层都做：应用层超时给一个较宽松的值，让 Agent 有机会优雅退出；容器层超时给一个稍大的值作为兜底，防止应用层逻辑卡死导致容器永远不退出。

4.5 审计日志与行为监控

沙箱边界不只是"防"，还要"看"。没有审计日志，你根本不知道 Agent 在沙箱里做了什么，出了问题也无从排查。

审计日志至少要记录几类事件：文件访问（读了哪些文件、写了哪些文件）、网络请求（访问了哪些地址、请求了什么内容）、系统调用（有没有尝试危险操作）、资源使用（CPU、内存、网络的峰值）。这些日志要写到 Agent 无法篡改的地方，比如挂载一个只写不读的日志目录，或者直接发到外部的日志服务。

监控方面，可以设置一些告警规则。比如 Agent 尝试访问白名单外的地址，触发告警；Agent 的资源使用突然飙升，触发告警；Agent 尝试执行被禁止的系统调用，触发告警。这些告警能帮你及时发现异常行为，在造成实际损害前介入。

实操心得：日志的格式要结构化，方便后续分析。我习惯用 JSON 格式记录每条事件，包含时间戳、事件类型、事件详情、Agent 标识等字段。这样后续可以用日志分析工具做聚合和查询，比纯文本日志好用得多。

5. 常见问题与排查技巧实录

5.1 沙箱配置了但 Agent 跑不起来

这是最常见的问题，表现是 Agent 启动后报各种权限错误。排查思路是按错误信息逐项检查。

如果是文件相关的错误，先确认挂载路径是否正确，容器内路径和宿主机路径的映射关系有没有搞错。然后检查权限，容器内用户对挂载目录有没有读写权限。这里有个常见坑：宿主机目录的 UID 和容器内用户的 UID 不一致，导致容器内用户没有权限。解决办法是在宿主机上把目录 owner 改成和容器内用户 UID 一致，或者在启动容器时用--user参数指定 UID。

如果是网络相关的错误，先确认代理配置是否正确，环境变量有没有传进去。然后检查白名单里有没有包含 Agent 需要访问的地址。有时候 Agent 访问的是一个重定向后的地址，白名单里只写了原始地址，重定向后的地址没写，也会被拒绝。这种情况需要在代理层配置跟随重定向，或者把重定向后的地址也加进白名单。

如果是系统调用相关的错误，那可能是系统调用白名单太严了。可以先临时放宽白名单，用strace之类的工具记录 Agent 实际调用了哪些系统调用，然后根据记录调整白名单。这个过程可能需要反复几次才能找到合适的白名单集合。

5.2 Agent 行为异常但日志看不出问题

有时候 Agent 的行为明显不对，但审计日志里没有异常记录。这种情况通常是日志覆盖不全，或者 Agent 找到了绕过日志记录的方法。

先检查日志覆盖范围。是不是所有敏感操作都记录了？比如文件访问，是只记录了打开操作，还是读写操作都记录了？网络请求，是只记录了目标地址，还是请求内容也记录了？如果日志粒度不够，很多细节就看不到。

然后检查 Agent 有没有可能绕过日志。比如 Agent 如果能在内存里直接操作数据，不经过文件系统，那文件访问日志就记录不到。或者 Agent 如果用了日志系统不监控的网络协议，网络日志也可能漏掉。解决办法是尽量在底层做日志，比如在系统调用层记录，而不是在应用层记录。

还有一个可能是 Agent 的行为本身在允许范围内，但组合起来产生了非预期效果。比如 Agent 单独读几个文件都是允许的，但它把读到的内容拼接起来发到了允许的地址，这就可能造成信息泄露。这种情况需要在策略层面做更复杂的判断，比如限制单次任务能读取的文件总大小，或者对发送的内容做敏感信息检测。

5.3 性能瓶颈定位与优化

沙箱配置往往会带来性能开销，如果 Agent 跑得比预期慢，需要定位瓶颈在哪里。

先区分是沙箱本身的开销还是 Agent 逻辑的问题。可以临时把沙箱配置放宽，看性能有没有明显提升。如果提升明显，那瓶颈就在沙箱；如果没变化，那可能是 Agent 逻辑本身的问题。

沙箱开销常见的来源有几个。一是文件系统隔离，特别是用了 overlay 文件系统或者网络文件系统时，IO 性能可能下降明显。解决办法是把高频读写的目录挂载成 tmpfs，用内存换性能。二是网络代理，所有请求都经过代理转发，增加了一跳延迟。如果 Agent 的网络请求很频繁，这个开销会累积。可以考虑对代理做连接池优化，或者对某些高频地址做直连白名单。三是系统调用过滤，每次系统调用都要经过过滤检查，也有开销。这个开销通常不大，但如果 Agent 系统调用特别频繁，也会成为瓶颈。

资源配额设置太紧也会导致性能问题。比如 CPU 限制太低，Agent 一直在等 CPU 时间片；内存限制太低，Agent 频繁触发内存回收。这种情况需要根据实际负载调整配额，给一个合理的余量。

5.4 常见问题速查表

6. 边界之外的思考：沙箱策略的演进方向

6.1 从静态策略到动态适应

目前大多数沙箱方案用的是静态策略：配置一次，长期有效。但 Agent 的任务是动态变化的，静态策略要么太严影响功能，要么太松留下风险。未来的方向是动态适应：根据 Agent 当前任务的性质，实时调整权限范围。

实现动态适应的前提是有一套可靠的任务识别机制，能判断 Agent 当前在做什么，需要什么权限。这可以基于任务描述、历史行为模式、或者 Agent 主动申报。然后权限管理模块根据识别结果，动态授予和回收权限。任务完成后权限自动失效，下一个任务重新评估。

这种模式对权限管理模块的要求很高，它需要快速做出判断，不能成为性能瓶颈；需要准确识别任务，不能误判；还需要有完善的审计，记录每次权限变更的原因和结果。目前这套机制还在探索阶段，但已经有一些团队在尝试了。

6.2 多 Agent 场景下的边界协调

单个 Agent 的沙箱边界相对好管，多个 Agent 协作时就复杂了。比如 Agent A 需要把数据传给 Agent B，这个数据传递过程要不要经过沙箱检查？Agent A 的权限和 Agent B 的权限怎么协调？

一种思路是给每个 Agent 独立的沙箱，Agent 之间的通信也走受控通道，通道上做内容检查。这样每个 Agent 的边界是清晰的，通信过程也是可控的。另一种思路是给一组协作的 Agent 共享一个沙箱，内部通信不受限，但整体对外边界严格。这种方案性能好，但一个 Agent 出问题可能影响整组。

选择哪种方案取决于协作的紧密程度和安全要求。如果 Agent 之间只是偶尔传递数据，独立沙箱加受控通道更安全。如果 Agent 之间需要频繁交互、共享大量状态，共享沙箱可能更实际。我个人的倾向是尽量用独立沙箱，因为安全边界清晰，出了问题容易定位和隔离。

6.3 边界策略的可解释性

最后一个值得关注的方向是策略的可解释性。当 Agent 的某个操作被沙箱拒绝时，Agent 和开发者都需要知道为什么被拒，才能决定是调整策略还是改变操作方式。

目前很多沙箱方案的拒绝信息很简略，就一句"权限不足"，不说明具体是哪条策略触发的，也不说明怎么才能满足。这给调试带来很大困难。好的做法是拒绝时返回详细信息：触发了哪条策略、策略的内容是什么、需要什么条件才能放行。这样 Agent 可以尝试调整操作方式，开发者也可以判断策略是否合理。

可解释性还包括策略本身的可读性。策略配置应该用人类可读的格式，而不是一堆二进制或加密内容。这样开发者能审查策略，发现潜在问题。我见过一些团队用编译后的策略文件，结果策略写错了都没人发现，直到出了事故才排查出来。

7. 我踩过的几个坑和最后的建议

说几个我实际踩过的坑，都是文档里不会写但实际会遇到的。

第一个坑是挂载目录的符号链接。有一次我配置了只读挂载/data/input，以为 Agent 只能读不能写。结果 Agent 在/data/input里发现了一个符号链接，指向/data/output，通过这个链接绕过了只读限制，往 output 目录写了东西。虽然 output 目录本来就是可写的，没造成实际损害，但这个漏洞说明挂载隔离不是绝对的，符号链接可能成为绕过路径。解决办法是在挂载时加nosymfollow选项，禁止跟随符号链接。

第二个坑是环境变量泄露。Agent 容器里如果设置了包含敏感信息的环境变量，比如 API 密钥，Agent 可以通过读取/proc/self/environ拿到这些信息。如果 Agent 又被诱导把这些信息发到外部，就造成了泄露。解决办法是敏感信息不要用环境变量传递，改用挂载文件的方式，并且文件权限设成只有特定用户可读。

第三个坑是日志目录被写满。Agent 如果疯狂写日志，可能把日志目录所在磁盘写满，导致整个宿主机出问题。解决办法是给日志目录设置磁盘配额，或者用日志轮转机制，限制单个日志文件的大小和保留数量。

最后一个建议：沙箱边界要定期审查。业务在变，Agent 的行为在变，当初合理的边界可能现在已经不合适了。我习惯每季度做一次沙箱策略审查，看看有没有可以收紧的地方，有没有因为业务变化需要放宽的地方。审查时重点关注那些"当初为了跑通临时放宽"的配置，这些往往是最容易出问题的地方。

这套东西说到底就是一句话：围栏的钥匙不能给围栏里的动物，但围栏的高度和范围要随着动物的成长和需求动态调整。没有一劳永逸的配置，只有持续的关注和迭代。