Marico's space
给 AI Agent 完全访问你整台电脑的权限，这事儿想想就挺刺激的。
尤其是当这个 Agent 能够：
这些能力恰恰是 Hermes Agent 强大的地方。
但同时也引出了一个关键问题：
这些操作到底应该在什么环境里跑？
与其把 Hermes Agent 直接跑在宿主机上，我决定把它塞进 Docker 容器里，明确控制它能访问什么。
目标不是把 Hermes 往 Docker 里一放就"自动变安全"了。
目标很简单：
只给它需要的东西，别让它碰整台电脑。
这篇把完整配置流程过一遍，包括：
Hermes 不只是个聊天机器人。
它能跟环境交互，替你执行操作。
比如，取决于你启用了哪些工具，Hermes 可以操作文件、执行终端命令、安装依赖、调用外部服务、自主完成各种任务。
这非常实用。
但如果 Agent 直接跑在主机上，你得认真考虑它能访问哪些文件、凭证和系统资源。
这时候 Docker 就派上用场了。
与其让 Hermes 直接在宿主机环境里横冲直撞，不如把它关进容器，明确决定什么东西能穿过这个边界。
我们最终搭出来的架构大致是这样的：
┌──────────────────── HOST MACHINE ────────────────────┐
│ │
│ Docker │
│ │
│ ~/.hermes-docker ───────────────┐ │
│ │ │
│ ┌──────────────▼──────────────┐ │
│ │ Docker Container │ │
│ │ │ │
│ │ Hermes Agent │ │
│ │ │ │
│ │ /opt/data │ │
│ │ Gateway │ │
│ │ Dashboard │ │
│ └─────────────────────────────┘ │
│ │
│ Personal files / SSH keys / other directories │
│ NOT mounted into container │
│ │
└──────────────────────────────────────────────────────┘
Hermes 有自己的专属环境和持久化数据目录。
机器的其他部分都在边界之外，除非你明确暴露。
macOS 或 Windows 上装 Docker Desktop，确保 Docker 引擎在运行。
Linux 上按发行版的说明装 Docker Engine。
验证一下 Docker 是否正常：
docker --version
Docker 跑起来之后，就可以给 Hermes 搞个隔离环境了。
先建一个专门给 Docker 化 Hermes 实例用的目录：
mkdir -p ~/.hermes-docker
这个目录很重要，原因有两个。
Docker 容器是用完就扔的。
如果删掉重装 Hermes 容器，总不能把配置、会话、内存、Skills、Profile、日志这些都丢了吧。
所以这些东西存在 ~/.hermes-docker 目录里，容器外面。
这个目录里的东西都是有意暴露给 Hermes 的。
不挂载整个 home 目录，只给 Agent 一个专用位置。
这个区别很重要。
现在启动官方 Hermes Agent 镜像，运行设置流程：
docker run --rm -it \ -v ~/.hermes-docker:/opt/data \ nousresearch/hermes-agent setup
这里最关键的部分是：
-v ~/.hermes-docker:/opt/data
-v 参数在宿主机目录和容器内目录之间创建绑定挂载。
可以这么理解：
HOST CONTAINER
~/.hermes-docker ───────▶ /opt/data
左边是我们刚在宿主机上创建的目录。
右边是这个目录在 Docker 容器里出现的位置。
所以当 Hermes 把配置、会话、内存、Skills 或其他持久化数据存到 /opt/data 时，这些文件其实存在宿主机上的 ~/.hermes-docker 里。
这意味着可以销毁、重建容器而不丢失 Hermes 环境。
更重要的是，我们只共享了一个专用目录，而不是整个宿主机文件系统。
首次运行会下载所需的 Docker 镜像，启动 Hermes 设置向导。
按正常的 Hermes 配置流程走就行。
我的配置：
配置完成后会存在持久化目录里。
以后用同样挂载的容器可以直接复用。
现在把 Hermes 作为后台容器启动：
docker run -d \ --name hermes-docker \ --restart unless-stopped \ -v ~/.hermes-docker:/opt/data \ -p 18642:8642 \ -p 19119:9119 \ -e HERMES_DASHBOARD=1 \ nousresearch/hermes-agent gateway run
有几个关键点。
后台运行
-d
以 detached 模式启动容器。
给容器起个名字
--name hermes-docker
方便后续管理：
docker logs hermes-docker
docker stop hermes-docker
docker start hermes-docker
保持持久化目录
还是挂载同一个目录：
-v ~/.hermes-docker:/opt/data
这样 Hermes 能看到我们在设置时创建的配置文件。
启用 Dashboard
-e HERMES_DASHBOARD=1
开启 Hermes Dashboard。
注意我用的是：
-p 18642:8642
-p 19119:9119
Docker 端口映射的格式是：
HOST_PORT:CONTAINER_PORT
所以：
18642 → 8642
19119 → 9119
右边的端口是 Hermes 在容器内部用的。
左边的端口是暴露在宿主机上的。
我故意用了不同的宿主机端口，因为本地已经跑了另一个 Hermes 实例，不想端口冲突。
如果只跑 Docker 实例，可以直接用默认端口 8642 和 9119，不需要 18642 和 19119。
运行：
docker ps
应该能看到 hermes-docker 容器在跑。
如果有问题，先看容器日志：
docker logs hermes-docker
配置 Dashboard 的时候这个特别有用。
我刚打开 Dashboard 的时候，它没正常启动。
没把这部分从教程里藏起来，因为这是个很好的排查例子。
查看：
docker logs hermes-docker
发现 Dashboard 需要认证 provider。
Hermes 提供了多种认证选项来保护 Dashboard 访问。
我用 Nous Portal 认证配置的。
配置完成后 Dashboard 就正常启动了。
按我的端口映射，访问地址是：
localhost:19119
现在 Hermes Dashboard 在跑了，而 Hermes 本身还在容器里。
也可以直接进入正在运行的容器：
docker exec -it hermes-docker bash
然后启动 Hermes：
hermes
这时候你是在 Docker 容器里的终端跟 Hermes 交互，而不是在宿主机上直接跑 Hermes。
测试的时候挺有用的。
但每次要用 Agent 都进容器也挺麻烦的。
有更好的方式。
Hermes Desktop 可以连接到容器里跑的 Gateway。
打开 Hermes Desktop，导航到：
Settings → Gateway → Remote Gateway
配置成使用 Docker 容器暴露的 Gateway。
我的配置里 URL 是：
http://localhost:19119
认证之后保存配置并重连。
现在 Hermes Desktop 跟 Docker 化 Hermes 实例通信了。
从用户角度，我还是有方便的桌面界面。
但 Agent 本身是在容器里跑的。
这可能是教程里最重要的一部分。
在 Docker 里跑 AI Agent 不会自动变安全。
Docker 给了我们一个有用的隔离边界，但这个边界很大程度上取决于容器的配置方式。
举个例子，想象你这么搞：
Host machine │ ▼
Entire home directory │ ▼
Docker container │ ▼
Hermes Agent
技术上你确实把 Hermes 容器化了。
但你也把机器的很大一部分暴露给它了。
这不是我想要的配置。
应该这样：
Host machine │ ├── Personal files ❌ ├── SSH keys ❌ ├── Other projects ❌ ├── Docker socket ❌ │ └── ~/.hermes-docker ✅ │ ▼ Hermes Container
容器只应该拿到任务所需的资源。
如果把整个 home 目录挂进容器，Hermes 可能会访问到容器权限允许范围内的各种东西。
可能包括个人文件、源代码、配置文件、凭证或其他敏感数据。
这就是为什么我用的是：
~/.hermes-docker
作为专用位置。
Hermes 不需要的东西就不要暴露。
同样的原则适用于 API 密钥和令牌。
只提供 Hermes 实际需要的凭证。
避免不必要地暴露：
~/.ssh
或其他云服务的凭证和密钥。
容器化没多大用，如果你把各种敏感凭证都塞进容器的话。
我还特意没挂载：
/var/run/docker.sock
把宿主机的 Docker 守护进程暴露给容器，会大幅扩展容器的权限范围。
对于自主 Agent 来说，这是一个特别需要考虑的边界。
如果 Hermes 不需要控制宿主机的 Docker，就别给它这个能力。
还有另一个重要的限制。
AI Agent 仍然可能遇到恶意或对抗性内容。
比如，网页、仓库、文档或其他外部来源的内容可能试图操纵 Agent 执行非预期操作。
把 Agent 放 Docker 里不能消除这个问题。
区别在于 Agent 尝试操作之后会发生什么。
如果 Hermes 只能访问：
/opt/data
那它的操作环境是受限的。
如果挂载了整台电脑、暴露了敏感凭证、还给了 Docker 守护进程权限，那潜在影响就完全不一样了。
这就是为什么我认为容器化更多是"爆炸半径缩减"，而不是什么 AI 安全银弹。
随着 AI Agent 能力越来越强，我认为一个传统安全原则变得比以前更重要：
最小权限。
Agent 应该获得完成任务所需的最小访问权限。
不是：
Agent │ └── Everything on my computer
而是：
Agent │ ├── Required files ├── Required credentials ├── Required network services └── Required tools
不多给。
随着 Agent 获得越来越长的自主运行时间、终端访问、浏览器访问、外部集成、定时执行以及多工具协作能力，这个原则变得越来越重要。
Docker 不是隔离自主 Agent 的唯一方式。
也可以用：
VM 通常比标准应用容器提供更强的隔离边界，因为它虚拟化了更大范围的环境。
不过 Docker 更轻量、更方便本地开发。
对于我的 Hermes 配置，它给了我一个实用的中间地带：
Direct Host Execution ↓
Docker Container ↓
Virtual Machine / Dedicated Environment
具体用哪种边界，取决于你给 Agent 的能力以及它能访问什么资源。
配置完成后，我的结构大概是这样的：
┌─────────────────────────────┐ │ Host Machine │ │ │ │ Hermes Desktop │ └──────────────┬──────────────┘ │ Remote Gateway │ ▼ ┌─────────────────────────────────┐ │ Docker Container │ │ │ │ Hermes Gateway │ │ Hermes Dashboard │ │ Hermes Agent │ │ │ │ /opt/data │ └───────────────┬─────────────────┘ │ Bind Mount │ ▼ ~/.hermes-docker │ ┌───────────────┴──────────────┐ │ Config • Memory • Sessions │ │ Skills • Profiles • Logs │ └──────────────────────────────┘ Rest of host filesystem → NOT MOUNTED SSH keys → NOT EXPOSED Docker socket → NOT EXPOSED
Hermes 还是有工作所需的环境。
但我们对什么东西能穿过边界要更加慎重。
自主 AI Agent 能做的事已经远超生成文本了。
它们越来越能：
⚡ 执行命令
🗂️ 操作文件
🌍 与外部系统交互
🧰 使用专用工具
🔄 自主运行多步骤工作流
这很令人兴奋。
但 Agent 越强大，它的运行环境就越重要。
在 Docker 里跑 Hermes Agent 解决不了所有安全问题。
但它确实给了我们一个实用的方式：控制 Agent 能访问什么，在出问题的时候减少潜在的爆炸半径。
我的原则很简单：
只给 AI Agent 实际需要的东西。
其他的都留在边界外面。