毓惶博客

Hermes Agent 番外 02 | 多人共享 Hermes：profile、workspace 与权限隔离方案

上一篇番外里，我们把 Hermes Agent 接进了 Open WebUI：Open WebUI 负责提供网页入口，Hermes 负责真正执行 agent 任务。

这一步解决的是「怎么让更多人用得上」。但它立刻带来第二个问题：

**多人共享 Hermes，到底应该怎么隔离？**

如果只是把同一个 Open WebUI 地址、同一个 Hermes API Server、同一个 Codex 登录、同一个终端环境开放给一群人，看起来很省事，实际上很快会遇到四类风险：

会话互相污染：A 的需求、上下文、文件路径被 B 看见或误用。

文件互相覆盖：不同人让 agent 改同一个目录、同一个 git 仓库、同一个配置文件。

凭据互相暴露：一个人的 token、cookie、API key 被另一个人的任务读到。

权限边界失控：某个用户只是想问答，结果拿到了 terminal、file、Docker、GitHub 等高权限能力。

所以，多人共享 Hermes 的核心不是「能不能让大家同时访问」，而是：

**每个人能访问哪个入口、使用哪个身份、进入哪个 workspace、调用哪些工具、承担哪部分成本。**

这篇文章尝试把这个问题拆清楚，并给出几种可落地的方案。

先定义几个层次

讨论隔离之前，先把几个容易混在一起的概念拆开。

1. 入口层：Open WebUI / 消息平台 / API Server

入口层解决的是「用户从哪里进来」。常见入口包括：

Open WebUI：适合多人网页聊天、团队内部入口。

Telegram / Discord / Slack / WeChat 等 gateway：适合消息平台。

Hermes API Server：给 Open WebUI 或其他 OpenAI-compatible 客户端调用。

入口层可以做账号登录、页面权限、用户分组，但它不等于执行隔离。

也就是说，Open WebUI 里两个用户有两个账号，不代表 Hermes 在底层就自动给他们用了两个不同的文件系统、两个不同的 token、两个不同的 profile。

2. 身份层：谁在承担模型调用与授权

身份层解决的是「这次 agent 调用到底使用谁的凭据」。

在 Hermes 场景里，可能包括：

OpenAI Codex OAuth 登录。

OpenRouter / Anthropic / Gemini / DeepSeek 等 API key。

GitHub、Notion、Gmail、飞书等集成 token。

本机 shell、Docker、SSH、云服务器权限。

很多人最关心的是：能不能复用 Hermes 已登录的 Codex token，不额外接付费 API？

答案是：**可以作为本地实验或小范围可信共享的方案，但它不是天然适合多人生产使用的权限模型。**

因为只要底层共享同一个 provider 登录，成本、限流、滥用风险、账号风控都可能集中到一个人身上。

3. Profile 层：Hermes 的人格、配置、记忆与会话

Hermes 的 profile 可以理解成一套独立的 agent 家目录。

它可以承载：

独立 config。

独立 .env。

独立 sessions。

独立 memory。

独立 skills。

独立 provider / tool 配置。

常见命令是：

Profile 解决的是「这个 agent 实例是谁」。

如果多人长期使用同一个默认 profile，那么他们共享的不只是模型入口，还包括 agent 的记忆、技能、会话历史、默认工作目录、工具策略和部分凭据。

4. Workspace 层：agent 实际操作的目录

Workspace 解决的是「agent 能碰哪些文件」。这通常比 profile 更容易被低估。

哪怕每个人使用不同 profile，如果他们的 terminal cwd 都指向同一个目录，比如：

那他们依然可能互相覆盖文件、抢 git 分支、修改同一份 .env、启动冲突端口。

更安全的方式是：

或者每个项目使用独立目录 / 独立 git worktree / 独立容器。

5. 工具层：能不能读文件、跑命令、访问外部服务

工具层决定了 agent 的实际能力边界。

一个只有 web/search 的 Hermes，风险接近「搜索与问答」。

一个开启 terminal、file、browser、GitHub、Notion、Docker、SSH 的 Hermes，就已经接近一个远程执行系统。

多人共享时，最危险的不是模型回答错，而是：

因此，权限隔离必须落到工具层，而不能只停留在「大家有不同聊天窗口」。

三种共享方案

下面给出三个从简单到严格的方案。不是所有团队一上来都需要最复杂的，但至少要知道自己处在哪个风险等级。

方案 A：单 Hermes + 单 Open WebUI，本地可信实验版

这是最简单的方案。

结构大概是：

适合场景：

自己一个人多设备使用。

家庭或极小范围可信用户。

只是测试 Open WebUI + Hermes 是否能跑通。

主要做问答，不让别人执行高风险工具。

优点：

配置最少。

能快速验证体验。

可以直接复用当前 Hermes 已登录的 Codex 或其他 provider。

缺点：

基本没有真正隔离。

多人共享同一份记忆、session、skills、workspace。

成本和限流都集中到同一套 provider 凭据。

任何工具能力都相当于暴露给所有入口用户。

这个方案的底线建议是：

只给可信用户。

不开放到公网。

不给陌生人使用。

默认关闭高权限工具，尤其是 terminal、file、Docker、SSH。

如果要开 terminal/file，只在临时测试目录里操作。

可以把它当作「个人实验室」，不要把它当作「团队权限系统」。

方案 B：多 profile + 多 gateway，轻量团队版

第二种方案是给不同用户或不同用途配置独立 Hermes profile，并为它们启动不同 API Server 端口。

结构大概是：

Open WebUI 仍然是统一入口，但后端有多个 Hermes 连接。

每个连接可以有：

不同 API_SERVER_PORT。

不同 API_SERVER_KEY。

不同 API_SERVER_MODEL_NAME。

不同 HERMES_HOME 或 profile。

不同 config / .env。

不同 workspace。

创建独立 profile

示例：

Menu