它不只是套在大模型外面的一层聊天页面，更像一个可以自托管的 AI 使用入口：向下连接模型和工具，向上提供用户、会话与交互体验。
Open WebUI 入门：在公司内网搭建自己的 AI Chat
当模型和 AI 工具越来越多，我更需要一个统一、可自托管的聊天入口。这篇记录 Open WebUI 的定位、基本用法，以及我为什么会在不希望员工直接访问外网的场景下，用它搭建公司内部的 AI Chat。
在前面两篇 RAGFlow 学习笔记里，我已经搭建了一套可以解析文档、检索知识并给出引用的问答服务。RAGFlow 自带的页面足够完成知识库配置和效果验证，但公司内部真正需要的并不只是一个“知识库测试页面”。
有人想直接和通用模型聊天，有人需要查询专业资料，后面还可能接入内部工具、联网搜索或者工作流。员工更希望进入同一个页面，选择不同的 AI 能力，而不是记住多个系统地址。
我们当时选择了 Open WebUI 作为统一入口。这篇先不接 RAGFlow，我想单独记录一下 Open WebUI 的定位、基本使用，以及它为什么适合搭建一套运行在公司内部的 AI Chat。
为什么不是自己写一个聊天页面
如果需求只有一个输入框和一段流式回答，自己开发并不困难。真正投入使用以后，需求很快会从“能聊天”扩展出去：
- 登录以后要保留自己的聊天记录；
- 不同用户能看到的模型不完全一样；
- 对话需要重命名、搜索、归档和导出；
- 管理员要维护 Prompt、模型和工具；
- 需要上传文件、语音输入或生成图片；
- 后端可能同时存在 Ollama、OpenAI-compatible API 和内部服务；
- 模型回答时间较长，需要处理流式输出和中断。
这些能力单独看都不神秘，但从头开发、打磨再长期维护，成本并不低。Open WebUI 已经把它们组织成了一个相对完整的平台，我更愿意把开发精力放在公司自己的知识和业务能力上。
Open WebUI 负责什么
Open WebUI 的官方定位是可扩展、可自托管，并且可以完全离线运行的 AI 平台。它能够连接 Ollama 和 OpenAI-compatible API，也提供 Knowledge、Tools、Functions、Web Search、语音和图片等扩展能力。
我把这些能力分成了四层：
交互层
负责员工真正看到和使用的部分，包括多轮对话、Markdown、代码块、文件上传、消息操作和引用展示。
平台层
负责用户、群组、模型列表和聊天记录。对于公司内部使用，这一层比“页面好不好看”更重要，因为它决定了谁能使用哪些能力。
扩展层
Open WebUI 可以通过 Knowledge 做内置 RAG，也能通过 Tool、Pipe Function、Filter Function 等方式接入外部系统。我们的专业文档检索已经交给 RAGFlow，因此不会再让 Open WebUI 重复维护同一套知识库。
能力层
Open WebUI 自己不等于大模型。它把请求转发给 Ollama、vLLM、内部模型网关或者其他兼容接口，再把响应呈现在聊天界面中。
协议比供应商更重要
Open WebUI 当前强调基于标准协议接入模型。只要后端实现了 OpenAI Chat Completions 等兼容接口，就可以作为模型供应方；不兼容的内部 API，则可以通过 Pipe Function 或中间网关适配。
这也是它适合做统一入口的原因之一。
先用 Docker 跑起来
Open WebUI 的 Docker 部署比 RAGFlow 简单很多。为了保留聊天记录和配置，最关键的是持久化 /app/backend/data。
步骤 1：拉取镜像
本地学习可以先使用官方的滚动镜像：
docker pull ghcr.io/open-webui/open-webui:mainmain会持续变化。正式环境我会换成当时验证过的vX.Y.Z稳定标签，并记录镜像摘要。步骤 2：启动容器
docker run -d \ -p 3000:8080 \ -v open-webui:/app/backend/data \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main步骤 3：创建管理员
浏览器访问
http://localhost:3000。默认情况下，第一个注册用户会成为管理员。完成初始化后，我会根据实际使用方式关闭公开注册，避免内部服务出现无人管理的账号。步骤 4：连接模型
在管理员设置中添加 Ollama 或 OpenAI-compatible Connection，再限制真正需要展示的 Model ID。
如果准备长期运行，我更习惯把配置整理成 Compose：
services:
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
restart: always
ports:
- "3000:8080"
environment:
WEBUI_SECRET_KEY: ${OPEN_WEBUI_SECRET_KEY}
WEBUI_URL: https://chat.internal.example
volumes:
- open-webui-data:/app/backend/data
volumes:
open-webui-data:这里的 WEBUI_SECRET_KEY 应该使用固定的随机值并安全保存。容器重建后如果 Secret 变化，现有登录状态和加密数据可能受到影响。
数据卷不能省略
聊天、用户和大量管理配置都保存在后端数据目录。容器删掉可以重建，数据卷丢了就是另一回事。
升级前除了固定镜像版本，我还会先备份数据卷。
连接本地或内部模型
Open WebUI 可以直接连接 Ollama，也可以连接实现 OpenAI-compatible API 的模型网关。
模型服务如果和 Open WebUI 位于同一个 Compose Network，可以直接使用服务名。如果模型运行在宿主机，本地 Docker 环境通常使用 host.docker.internal，而不是在容器中填写 localhost。
对于 OpenAI-compatible 服务，Open WebUI 会尝试请求 /models 获取模型列表。如果内部网关没有实现这个接口，也可以在 Connection 的 Model IDs Filter 中手工登记模型。
公司内部 AI Chat 的两种网络边界
“内部部署”并不只有一种形式。根据数据和网络要求，我会把它分成两类。
完全不允许访问外网
模型、Embedding、语音模型和业务工具全部部署在内部网络，服务器层面也没有公网出口。
这类环境需要在有网络的准备区提前下载镜像和模型，再通过内部镜像仓库或离线介质转入目标环境。
Open WebUI 的 Offline Mode 还需要显式设置：
environment:
OFFLINE_MODE: "true"
HF_HUB_OFFLINE: "1"
RAG_EMBEDDING_MODEL_AUTO_UPDATE: "false"
RAG_RERANKING_MODEL_AUTO_UPDATE: "false"
WHISPER_MODEL_AUTO_UPDATE: "false"如果提前没有准备 Embedding 或 Whisper 模型，开启离线模式以后，相关功能不会自动帮我下载缺失资源。
不希望业务直接访问外网
另一种更常见的方案，是员工浏览器和 Open WebUI 都不直接请求公网模型，而是统一经过公司内部模型网关。
这样做并不代表数据一定安全，但至少把模型密钥、访问策略、脱敏、审计和限流集中到了服务端。浏览器不需要保存云模型 Key，也不会绕开公司的调用边界。
离线模式不等于物理隔离
OFFLINE_MODE=true 会关闭版本检查和自动模型下载，但官方也明确说明，完全 air-gapped 仍然需要在基础设施层隔离实例。
真正不允许访问外网时，我还会使用防火墙、Kubernetes NetworkPolicy 或出口代理白名单限制网络，而不是只依赖应用配置。
一套内部 AI Chat 还要补哪些设置
页面打开、模型能回答，只能算完成了第一步。内部使用至少还要明确这些事情：
| 事项 | 我的处理原则 |
|---|---|
| 注册 | 初始化后关闭无控制的公开注册 |
| 访问入口 | 使用内部域名和 HTTPS |
| 模型密钥 | 只保存在服务端或模型网关 |
| 模型范围 | 按用户或群组控制可见模型 |
| 数据 | 持久化并制定备份、保留与删除策略 |
| 联网能力 | 默认关闭，按场景单独开放 |
| Functions | 只安装经过代码审查的内部 Function |
| 版本 | 测试环境验证后再升级生产 |
Open WebUI 的 Function 会直接在服务端执行 Python 代码。它很强大，但也意味着从社区导入一个 Function，性质上接近把一段外部代码放进公司服务器运行。官方文档同样建议只安装可信来源并先做代码审查。
为什么我们把它选作外部入口
经过这一轮梳理，我觉得 Open WebUI 对内部平台最实际的价值有三个：
- 统一入口：普通模型、专业知识助手和内部工具可以出现在同一套会话体验里；
- 自托管：用户、聊天和配置可以留在自己的基础设施中；
- 扩展边界清楚：标准模型走兼容协议，特殊能力通过 Pipe、Tool 或内部网关接入。
它自身也带有 Knowledge 和 RAG，但我们没有因此放弃 RAGFlow。Open WebUI 的内置知识库适合快速、轻量的文件问答；复杂文档解析和需要精细检索控制的专业资料，仍然交给 RAGFlow 更合适。
下一篇，我会把两者真正连接起来：让 RAGFlow 继续负责知识处理，让 Open WebUI 把它当成一个可以选择的“专业知识模型”。