你用 Hermes 开了三个 Profile：一个管工作、一个管个人项目、一个专门跑实验。每个 Profile 都配了 Docker 终端后端，于是每次干活，机器上就立起好几个容器——磁盘多占、启动变慢、装好的依赖各自为政，改个环境变量还得挨个容器同步。8 月 25 日合并的 PR #94633 给了一个优雅的解法：让受信任的 Profile 共用同一个持久化 Docker 容器，只需设置一个配置键。

之前：每个 Profile 一个容器

先看默认行为。Hermes 的 Docker 后端（terminal.backend: docker）默认给每个 Profile 各开各的容器——这是 8 月 25 日同天合并的 PR #94560 刚确立的隔离规则：容器按 Profile 作用域命名（profile:<名字>），互不串扰。好处是隔离干净，坏处是资源重复：三个 Profile 就是三份依赖、三个缓存、三份环境。

如果你主要用 Docker 跑一次性隔离任务，这种默认就挺好，不用改。但如果你有多个 Profile 是“信得过的自家人”——比如工作 Profile 和实验 Profile 用的其实是同一套开发环境——那重复就是纯浪费。

现在：一个密钥，一个容器

PR #94633 引入了一个新配置键：terminal.docker_shared_container_key。它的规则很简单：

• 不设置（默认空字符串）：保持现状，每个 Profile 用自己独立的容器；
• 多个 Profile 设置成同一个值：它们共用同一个持久化容器，容器身份标记为 shared:<你的密钥>；
• CLI 直接跑（没有 Profile 上下文）且配了同样的密钥，也归入这个共享容器。

配置方式：

hermes config set terminal.docker_shared_container_key team/ws

或者直接编辑配置文件（hermes config path 可以查看文件位置）：

terminal:
  backend: docker
  docker_shared_container_key: "team/ws"

三个 Profile 都配成 team/ws 之后，它们执行的命令都落在同一个容器里：装一次依赖全都能用，缓存热乎的，环境变量改一处就同步。官方测试里，work 和 research 两个 Profile 配上相同密钥后，解析出的容器键是同一个 shared:team/ws。

哪些情况会“无视”共享设置

这个机制不是无脑合并，有三条边界值得知道：

• SSH 后端不参与：terminal.docker_shared_container_key 只对 Docker 后端生效，SSH 环境完全忽略它；
• 非持久化模式保持隔离：如果你用的是非持久化（用完即弃）的 Docker 会话，共享键不会把两个临时会话塞进同一个容器，每次会话仍然隔离；
• 密钥不同 = 不共享：密钥就是隔离的边界，配了不同值的 Profile 各用各的容器，互不影响。

另外，共享容器里产生的文件（比如 MEDIA 附件）也能正常从会话里取回——官方测试专门验证了共享沙箱的媒体投递路径。

什么时候该用、什么时候别用

建议开启的场景：多个 Profile 本质上是同一套开发环境的不同入口；团队里共用的“环境容器”；想省磁盘和启动时间的个人多开用户。

建议保持默认的场景：Profile 之间信任度低（比如接入了不受信任的自动化任务）；需要严格隔离审计的环境；依赖版本可能冲突的实验性 Profile。隔离永远比共享安全——共享键是给“信得过”的 Profile 准备的，这也是 PR 标题里“trusted profiles”的含义。

小结

一个配置键，把“每个 Profile 一个 Docker 容器”变成“一家人共用一个容器”：terminal.docker_shared_container_key 为空时保持默认隔离，多个 Profile 设置相同值则共享同一个持久化容器。想深入了解 Profile 多开的玩法，可以看我们的 Profile 多实例完全指南；配置文件相关操作见 hermes config 命令参考。如果你还在纠结要不要上 Docker 后端，安装指南 里有完整的后端选择说明。