HermesAgent连接Docker容器：沙箱环境配置与代码安全执行

一、启用Docker后端并配置基础沙箱参数

想让Hermes Agent在安全的隔离环境中运行代码，但容器总启动失败，或者代码一跑就遇到权限、网络或资源问题？这多半是因为Docker沙箱的安全约束没打开。别担心，咱们一步步来加固。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

核心思路很简单：通过修改Hermes Agent的主配置文件，强制所有终端操作都在Docker容器里执行，并设定一套默认的“隔离规矩”。这么做的目的，就是让代码既“跑不出去”，也“耗不尽”宿主机的资源。

首先，打开配置文件：~/.hermes/config.yaml。

关键改动在这里：把 terminal.backend 的值设为 "docker"。这还没完，还得补充几个沙箱专用的字段：

• 把镜像换成 python:3.12-slim。这个镜像更轻量，自带的东西少，潜在的攻击面自然就小了。
• 加上 network_enabled: false。这一招是釜底抽薪，彻底断掉容器对外连接的能力。
• 声明资源上限：memory_limit: "512m" 和 cpu_quota: 1.0。给内存和CPU都戴上“紧箍咒”，防止代码把资源吃干抹净。
• 最后，指定工作目录为 /workspace。避免挂载宿主机的敏感路径，让代码在专属的“小房间”里活动。

这几步下来，一个基础但有效的沙箱环境就配置好了。

二、使用Docker Compose部署带资源限制的沙箱服务

如果你的场景更复杂，比如需要沙箱长期运行，还得和API网关、日志收集器这些服务打交道，那么手动传参就容易出纰漏。这时候，用Docker Compose来统一管理会更稳妥。

方法就是创建一个 docker-compose.sandbox.yml 文件，把所有运行时约束都白纸黑字地声明在里面。

先写上版本声明：version: '3.8'。

然后定义核心的 hermes-sandbox 服务。镜像同样选择 python:3.12-slim。

资源限制放在 deploy.resources.limits 下面：cpus: '1' 和 memory: 512M，清晰明了。

网络隔离是关键，直接设置 network_mode: "none"，关闭整个容器的网络栈。

挂载配置目录时，记得加上只读（:ro）标志，比如：- ~/.hermes:/root/.hermes:ro。

最后，设置启动命令，确保进入正确目录并以沙箱模式运行：["sh", "-c", "cd /app && hermes run --sandbox"]。

这样一来，所有配置都固化在了文件里，部署和复现都变得轻而易举。

三、构建最小化非root沙箱镜像

上面两种方法是在运行时做限制，我们还可以更进一步，从镜像构建的源头就把风险堵住。核心是创建一个没有特权、默认以低权限用户运行的镜像。

新建一个Dockerfile，从 python:3.12-slim 开始。

接下来是关键操作：创建一个专属的非root用户和用户组。

RUN groupadd -g 1001 -f sandbox && useradd -r -u 1001 -g sandbox sandbox

这行命令创建了一个名为`sandbox`的用户组和用户，UID/GID设为1001。`-r`参数表示创建系统用户，权限更低。

然后，把Hermes Agent的运行时依赖复制到容器内的 /app 目录。

使用 USER sandbox 指令切换执行身份。从此，容器内进程默认就以`sandbox`这个低权限用户运行了，想写入系统关键路径或者调用敏感操作？门都没有。

再通过 WORKDIR /workspace 设定工作目录。

最后，声明入口点，指向一个非交互式的执行脚本：ENTRYPOINT ["python", "-m", "hermes.exec.sandbox"]。

构建镜像：docker build -t hermes-sandbox:strict .。一个从内到外都强化了安全性的沙箱镜像就诞生了。

四、集成Ja va Docker客户端实现动态沙箱生命周期控制

对于一些高级场景，比如希望每次代码执行都用一个全新的、用完即焚的容器，彻底杜绝状态残留的风险，就需要动态的生命周期控制。通过Ja va Docker客户端编程实现，是个不错的选择。

首先，在项目里引入必要的依赖，比如 docker-ja va-core 和 docker-ja va-transport-httpclient5。

然后，定义一个 SandboxSettings 内部类，用来固化沙箱配置：镜像还是用 python:3.12-slim，网络强制关闭（networkEnabled = false），再设置一个超时时间（比如300秒），防止代码陷入死循环一直占用资源。

动态控制的精髓在于“每次都是新的”。为每个执行请求生成一个唯一的容器名，格式可以用 hermes-sandbox-{uuid}。

接着，调用 DockerClient.createContainerCmd() 方法，并把内存、CPU限制等参数传进去，创建一个按需定制的容器。

最后，执行 startContainerCmd.exec() 启动容器，并严密监控其退出状态码。代码执行完毕，容器也随之销毁，不留一丝痕迹。

五、禁用危险系统调用并挂载只读文件系统

如果说前面的方法是给容器上了几道锁，那么这最后一步，就是给容器的内核层也穿上“防护甲”。通过Linux的命名空间和seccomp机制，我们可以进行更深度的加固。

目标是双重的：一是阻止容器内进程执行高危的系统调用（如mount, chroot, setuid），二是防止对宿主机文件系统的意外写入。

首先，准备一个seccomp策略JSON文件（比如叫 sandbox-seccomp.json）。这个文件里只放允许的系统调用（白名单），其他的统统拒绝。

然后，在运行容器时（无论是通过docker run命令还是Compose配置），引用这个策略文件：security_opt: ["seccomp=sandbox-seccomp.json"]。

光限制系统调用还不够，文件系统也要锁住。添加 read_only: true 参数，让容器的根文件系统变成只读的。

当然，有些程序运行时确实需要临时空间。我们可以显式地挂载一个 /tmp 目录为可写的tmpfs：volumes: ["/tmp:/tmp:rw,size=64m"]，同时限制其大小。

另外，移除所有额外的能力（--cap-add），并确保默认丢弃所有能力（--cap-drop=ALL）。再设置 no_new_privileges: true，彻底堵死进程提权的路径。

配置完成后，怎么验证呢？很简单，在容器里试试执行 touch /etc/test 或者 unshare --user 这类命令。如果都失败了，恭喜你，这个沙箱的防护等级已经相当高了。