夜雨聆风代码在哪里跑、怎么隔离——Hermes 的七种终端后端
会成长的AI：Hermes Agent 底层精讲 · 第十一篇
第九篇讲工具体系时，我提到 terminal 是所有工具里权限最高、风险最大的一个。这一篇专门来讲这个问题的背面：当 Hermes 执行代码或终端命令时，这些代码究竟跑在哪里、跑在什么边界里、用什么机制保证它不会伤害你的系统？
这不是一个可以含糊过去的问题。让 AI 在你的机器上跑任意代码，和让 AI 在一个隔离的沙箋里跑代码，在安全上是两件完全不同的事。Hermes 为此提供了七种终端后端，每种后端对应不同的执行环境和隔离级别。
七种后端一览
先用一张表把七种后端的核心特征列出来，再逐一深讲：
后端 | 执行位置 | 隔离级别 | 适合场景 |
local | 本机，你的用户身份 | 无 | 本地测试、无敏感数据 |
docker | 本机容器 | 强（内核命名空间） | 自托管生产环境 |
ssh | 远程服务器 | 物理隔离 | 云服务器部署、网关与执行分离 |
singularity | HPC 容器 | 强（专为集群设计） | 学术计算集群、GPU 任务 |
modal | 云端 Serverless | 强（独立沙箋） | 低频高算力任务 |
daytona | 托管工作区 | 强（托管隔离） | 云开发环境 |
vercel | Vercel 沙箋 | 强 | Vercel 生态集成 |
Daytona 和 Modal 都提供 Serverless 持久化——你的执行环境在空闲时休眠，有任务时按需唤醒，两次任务之间的费用几乎为零。
local：零隔离的起点
local 是默认后端，上手最简单，配置为零。代码直接跑在你的系统上，用你当前的用户权限，不需要任何额外设置。
但它的代价是完全没有隔离：local 后端的 Agent 以你的用户身份运行，拥有你对文件系统、网络和环境变量的完整访问权限。如果 Agent 决定运行 rm -rf ~/code，它真的会执行。如果工具输出里混入了提示词注入攻击，注入的命令也会真正执行。
官方的建议很直接：只在没有敏感数据的测试机上用 local 后端。第九篇里讲到的危险命令审批机制在 local 后端下是存在的，能拦截一些高危操作；但这是软性防护，不是硬性隔离，执行的最终边界还是你的系统。
Docker：生产自托管的首选
需要在自己机器上稳定跑 Hermes 又想要真正的隔离，Docker 是推荐选择。
Docker 容器跑在一个只读根文件系统里。Agent 无法修改系统二进制文件，无法安装影响宿主机的包，无法改变容器的基础配置。它只能写入显式挂载的目录（工作区目录和技能目录）。
Linux 能力默认全部关闭（--cap-drop ALL），只重新开放 DAC_OVERRIDE、CHOWN、FOWNER 三项，这三项是包管理器操作所必须的。同时禁止权限提升、设置 PID 数量上限防止 fork 炸弹、用独立的 noexec tmpfs 挂载临时目录。
使用任何容器后端时，危险命令审批检查会被自动跳过——因为容器本身就是安全边界。如果 Agent 在 Docker 容器里运行 rm -rf /，它摧毁的是容器的文件系统，不是你的宿主机。
SSH：把网关和执行环境分开
SSH 后端的设计思路和其他几个不同——它不是在本机创建隔离环境，而是把命令执行这件事转移到另一台服务器上。需要设置 TERMINAL_SSH_HOST 和 TERMINAL_SSH_USER 两个环境变量，缺一不可，否则启动时会有明确的错误提示。
这个后端最典型的用途是网关与执行分离：在你本地或者一台轻量级 VPS 上跑 Gateway，把实际的代码执行发到另一台更强的远程服务器上去跑。一个处理通讯，一个处理计算，两台机器各司其职，互不影响，也互不拖累。
对于用 Hermes 处理机器学习任务的用户，这个组合很实用：网关在一台便宜小机器上 7×24 运行，GPU 服务器只在需要时用 SSH 接过来干活，不让 GPU 一直空转计费。
Modal：Serverless 的使用哲学
Modal 后端的核心吸引力是两个字：按需。
Modal 和 Daytona 都提供 Serverless 持久化：执行环境在空闲时休眠，在有任务时唤醒，两次任务之间几乎不产生费用。Hermes 的 Modal 集成会追踪快照状态，存在 ~/.hermes/modal_snapshots.json 里。快照保存的是文件系统状态，不是活跃进程、PID 空间或后台任务。
Modal 后端特别适合的场景：低频但需要 GPU 算力的任务——比如让 Hermes 帮你跑一次大型数据分析、批量生成图像、微调一个小模型。这类任务每周可能只需要一两次，用 Modal 按秒计费，比租一台 GPU 服务器 24 小时在线划算得多。
Singularity：给 HPC 用户的选项
Singularity（也叫 Apptainer）是学术界高性能计算集群里的标配容器方案。如果你在大学或研究机构的 HPC 集群上工作，这是最自然的选择。
Singularity 后端使用 --containall --no-home 参数实现全命名空间隔离，不挂载宿主机的 home 目录。这符合 HPC 环境里的安全规范——共享集群上的容器不能随意访问宿主机的用户目录。
工作目录按顺序尝试：TERMINAL_SCRATCH_DIR → TERMINAL_SANDBOX_DIR/singularity → /scratch/$USER/hermes-agent（HPC 通用路径约定）→ ~/.hermes/sandboxes/singularity。前提是 apptainer 或 singularity 命令要在系统的 $PATH 里可以找到。
凭据如何安全地进入容器
一个容器后端绕不过的实际问题：Hermes 在容器里工作时，需要用到你的 API Key、OAuth Token 等凭据，这些敏感信息怎么安全地传进容器而不被泄露？
Hermes 的做法是挂载而非硬编码。凭据文件从 ~/.hermes/ 目录自动挂载进容器，并在每次命令执行前同步一次。密鑰本体留在宿主机上，容器通过挂载路径访问，不需要把密鑰写进容器镜像或者环境变量里传递。配合 chmod 600 对 .env 文件的权限设置，以及以非 root 用户身份运行 Hermes，这套组合基本覆盖了个人用户场景下的主要安全需求。
选哪个后端？一个实用判断框架
七种后端，场景不同，选择判断可以从两个问题出发：
第一个问题：你在意隔离吗？如果只是自己本地测试，没有敏感文件，用 local 省事。如果机器上有工作文件、密鑰、私人数据，并且你想让 Hermes 帮你跑真实代码，上 Docker。
第二个问题：执行环境在哪里？如果执行要在本机发生，local 或 Docker。如果执行要在远程服务器上发生，SSH。如果你想要按需弹性、不想管服务器，Modal 或 Daytona。如果你在 HPC 集群上工作，Singularity 别无选择。
local 和 Docker 在你的机器上，免费；其他五种运行在别处，你换来的是延迟成本或金钱成本，也换来了对应的好处。
一个值得混思的安全问题
最后分享一个研究这部分时形成的观察。七种后端里，local 是风险最高的，也是默认的。这个设计是有意为之的——上手摩擦最低，让更多人能先把 Hermes 跑起来。但“默认”在心理上容易被理解为“推荐”，而 local 实际上是最不推荐在生产使用的选项。
如果你打算长期用 Hermes 处理真实工作，有一件值得做的事：把 local 换成 Docker，哪怕只是在本机跑 Docker 也好。容器的隔离边界是个非常有价値的缓冲层，在 AI Agent 这个“AI 能主动执行系统命令”的场景下，这个缓冲层的价値比你在大多数软件使用场景下更高。
下一篇，我们去看插件系统和 MCP 集成——如何给 Hermes 扩展新能力，以及 MCP 这个协议是怎么工作的。
