毓惶博客

前面 12 篇 Hermes 教程，重点都在「个人如何把 agent 用起来」：安装、CLI、消息平台、记忆、skills、MCP、定时任务、子 agent、部署与调试。

但很多人真正装完以后，会冒出第二个问题：我能不能把它放进一个更熟悉的聊天界面里？比如 Open WebUI。

可以。更准确地说：Open WebUI 可以把 Hermes 当成一个 OpenAI-compatible provider 来用。用户在网页里发消息，Open WebUI 把请求转给 Hermes API Server，Hermes 再调用模型和本地工具，最后把结果返回给网页。

为什么要接 Open WebUI

Hermes 自带 CLI，也能接 Telegram、Discord、Slack、微信、邮件等平台。那为什么还要接 Open WebUI？核心原因不是「多一个界面」，而是「多一个团队入口」。

它对普通用户更友好。很多人不想碰终端，也不想知道什么是 toolset、profile、MCP，只想打开网页问问题。

它方便做模型入口统一。Open WebUI 本来就适合集中管理多个模型/provider，Hermes 可以作为其中一个「会动手的模型」。

它适合内部知识库和工作流入口。团队可以把「查资料、改文档、跑脚本、生成周报」都收进同一个网页。

它降低多人试用门槛。你不需要给每个人都装一套 Hermes，只要把入口开放出来。

一句话：CLI 适合重度使用者，消息平台适合个人助手，Open WebUI 适合把 Hermes 包装成一个团队可访问的 AI 工作台。

整体架构

最简单的架构是这样：

Open WebUI 并不知道 Hermes 内部有多少工具。它只知道自己连到了一个兼容 OpenAI Chat Completions 的接口。真正的 agent 能力仍然在 Hermes 这一侧：工具调用、skills 加载、记忆检索、MCP server、定时任务、终端执行等。

第一步:打开 Hermes API Server

先确认 Hermes 可用：

然后找到环境变量文件位置：

通常会是：

在这个文件里加入以下配置：

API_SERVER_KEY 不要随手写 123456。可以用下面这个命令生成：

这里最容易踩坑的是 API_SERVER_HOST。如果 Open WebUI 跑在宿主机本机，127.0.0.1 通常可以。但如果 Open WebUI 跑在 Docker 里，容器访问宿主机服务时，Hermes 只绑定 127.0.0.1 往往会连不上。为了省事，Docker 场景建议直接绑定 0.0.0.0，然后用防火墙和反向代理控制外部访问。

第二步:启动 gateway

API Server 是 Hermes gateway 的一部分，所以要启动 gateway：

如果你已经把 Hermes 装成后台服务，也可以：

看到类似下面的日志就说明 API Server 已经起来了：

本机验证：

如果 /health 正常，但 /v1/models 报 401，优先检查 API_SERVER_KEY 是否一致。不要把 OpenRouter、OpenAI、Codex 的 key 填到这里；这里要填的是你给 Hermes API Server 设置的那一个密钥。

第三步:在 Open WebUI 里添加连接

进入 Open WebUI 后台：

Admin Settings

Connections

OpenAI

Add Connection

如果 Open WebUI 直接跑在宿主机：

如果 Open WebUI 跑在 Docker 里：

注意 URL 末尾必须带 /v1。有时候不带 /v1 的连接测试看起来也能过，但模型列表或聊天请求会出问题。

Docker / WSL 最常见的网络坑

如果你是在 WSL 里跑 Hermes，又用 Docker 跑 Open WebUI，最常见的问题是容器不知道 host.docker.internal 指向哪里。可以先检查：

如果没有结果，启动容器时加：

docker compose 里写法是：

然后从容器内部测试 Hermes：

如果宿主机 curl 正常、容器 curl 不通，问题基本就在 Docker 网络或 Hermes 绑定地址；如果容器 curl 正常、Open WebUI 里模型不出现，问题多半是 URL 缺 /v1 或 API Key 填错。

模型、token 与成本:谁在真正付钱

Open WebUI 接上 Hermes 以后，Open WebUI 自己不负责模型调用。真正调用模型的是 Hermes。

所以成本取决于 Hermes 当前使用的 provider：OpenRouter、Anthropic、OpenAI、Codex OAuth、Nous、Gemini、本地模型，或者你配置的其他 provider。

这有一个好处：如果你已经在 Hermes 里登录了 Codex OAuth 或配置好了现有 provider，就不需要为了 Open WebUI 再单独接一套付费 API。Open WebUI 只是前端入口，Hermes 才是执行层。

但也有一个风险：多人共用时，所有人的请求都会消耗 Hermes 那一侧的模型额度。建议至少做三件事：

给 Open WebUI 做账号权限，不要公开裸奔。

给 Hermes API Server 设置强密钥，并且不要提交到 Git。

定期看 Hermes insights 或 provider 账单，确认谁在高频使用。

并发:多人同时用会怎样

Open WebUI 是多人界面，但 Hermes 的并发要分层看。

第一层是 HTTP 入口并发：API Server 能不能同时接多个请求。

第二层是 agent 执行并发：多个请求是否会抢同一份会话、同一个工作目录、同一个工具资源。

第三层是模型 provider 限制：上游模型有没有速率限制、并发限制、额度限制。

第四层是本地系统资源：文件写入、git 仓库、Docker、端口、终端命令都可能互相影响。

所以不要简单理解成「能打开网页 = 可以给全公司随便用」。普通聊天和资料总结一般没问题；涉及文件修改、代码仓库、服务器命令、生产账号时，必须做隔离。

比较稳的做法是：

每个重度用户一个 Hermes profile。

危险工具默认需要确认。

生产环境写操作只走专门的审批流程。

会话隔离:不要让所有人共用一个脑子

Hermes 的强项是记忆和 skills，但多人场景里，这也会变成风险。

个人助手记住「我喜欢中文回答」「我的 Windows 用户名是 vempe」是好事；团队入口记住「小张的偏好」「小李的账号」「某个客户的内部信息」就不一定是好事。

所以 Open WebUI + Hermes 的正确姿势不是无脑共享一个长期会话，而是根据使用场景决定隔离粒度：

演示/试用：可以共用一个低权限 Hermes。

小团队内部工具：至少按团队或项目拆 profile。

涉及私人资料：按用户隔离 profile、memory、workspace。

涉及公司生产系统：单独部署，单独权限，单独审计。

安全边界:把它当成会动手的同事，而不是普通 chatbot

接入 Open WebUI 后，Hermes 看起来像一个聊天模型，但本质上它仍然是 agent。它可能读文件、写文件、跑命令、访问 Notion、查 Gmail、改 GitHub issue。

因此上线前至少检查这几项：

工具权限：哪些 toolset 是开的？terminal、file、browser、notion、github、email 是否真的需要？

密钥权限：Notion/GitHub/Gmail token 是个人 token 还是团队 token？权限范围是否过大？

网络暴露：8642 端口是否只在内网或反代后可见？有没有 HTTPS？

日志审计：出了问题能不能追到是哪次请求做了什么？

危险动作确认：删除文件、发邮件、部署、付款、改生产配置，不能默认静默执行。

一个判断标准：如果你不敢把某个终端命令开放给普通用户，那就不要把能执行它的 agent 无限制接到公共网页上。

一个推荐的本地实验配置

如果你只是想在自己电脑上先跑通，可以这样搭：

跑通以后再逐步加：

HTTPS / 反向代理

Open WebUI 用户权限

Menu