本地服务器用 OpenClaw + Open WebUI 搭建企业多部门 AI 平台(附 Docker 避坑指南)

本地服务器用 OpenClaw + Open WebUI 搭建企业多部门 AI 平台(附 Docker 避坑指南)

引言:

最近在尝试使用 OpenClaw,发现这个 AI 个人助理框架非常有意思。于是团队里就有人提出:能不能为公司的多个部门,分别搭建专属的 OpenClaw 服务器?

诚然,现在有钉钉、飞书等成熟的办公软件可以接入 AI,但对于一些尚未全面普及此类协作软件的企业(或者需要绝对私有化部署的团队)来说,独立搭建一套内部 AI 门户依然是刚需。

起初,我们考虑直接让大家通过 OpenClaw 自带的 Web 界面进行跨电脑访问。但实操后发现这存在致命缺陷:

  1. 权限越界:自带的 Web 端拥有底层的配置编辑权限,暴露给普通员工极其不安全。
  2. 无法溯源:多终端共用一个 Web 界面,根本无法追溯对话是由谁发起的。
  3. 缺乏隔离:无法按部门精细化分配 API 额度或限制特定部门只能访问特定的 OpenClaw 节点,无法实现业务隔离。

为了解决这些痛点,我们最终确定了这套架构方案:前端使用 Open WebUI 统一接管用户登录与权限分发,后端通过 API 挂载多个互不干扰的 OpenClaw 容器。

部署环境: Ubuntu 系统

核心工具: Docker, Docker Compose

第一步:搭建 Open WebUI 统一前端 (用户控制台)

在这一步,我们需要先拉起 Open WebUI 容器。它将作为整个企业 AI 平台的“门面”,负责员工账号注册、鉴权以及对话界面的展示。

(由于该工具的搭建非常成熟,此处不过多赘述。具体安装步骤与 Docker 运行指令,请参考官方文档:https://docs.openwebui.com/

搭建完成后,你将获得一个支持多用户管理的 ChatGPT 风格界面。接下来,我们为它注入“灵魂”。

第二步:初始化并部署 OpenClaw 多节点网关 (核心后端)

我们需要从官方 GitHub 拉取源码,并使用其提供的 docker-setup.sh 脚本来进行初始化。

但在直接执行脚本前,有几个极易踩坑的细节需要提前优化(特别是国内网络环境和多节点共存问题):

细节 1:解决 Docker 构建时的网络超时 (Connect Timeout)

由于 Docker 构建时处于隔离网络,经常会卡死在 pnpm install 阶段。 在拉取源码后,先打开文件夹内的 Dockerfile,在 USER node 这一行的下方,手动注入淘宝镜像源:

Dockerfile

USER node # 注入国内镜像源加速依赖下载 ENV COREPACK_NPM_REGISTRY=https://registry.npmmirror.com ENV npm_config_registry=https://registry.npmmirror.com RUN pnpm install --frozen-lockfile

同时,打开 docker-setup.sh 脚本,在底部的 docker build \ 后面,加上 --network host \ 参数,让容器构建时借用宿主机网络。

细节 2:物理机目录权限交接 (防止 EACCES 报错)

为了实现部门隔离,我们需要把不同部门的配置挂载到不同的文件夹中。但在挂载前,必须将宿主机文件夹的权限移交给容器内的 node 用户(UID 1000):

Bash

# 假设我们先为研发部 (rd-dept) 创建专属目录 mkdir -p ~/openclaw-cluster/rd-dept sudo chown -R 1000:1000 ~/openclaw-cluster/rd-dept
细节 3:执行终极多节点部署指令 (防冲突防覆盖)

官方默认脚本容易导致网关 (Gateway) 和桥接 (Bridge) 端口冲突,且二次运行会覆盖旧容器。我们需要通过环境变量赋予它独立的“身份证”。

在 OpenClaw 源码目录下,执行以下长命令启动【研发部专属节点】:

Bash

sudo OPENCLAW_GATEWAY_PORT=18776 \ OPENCLAW_BRIDGE_PORT=18777 \ OPENCLAW_CONFIG_DIR=$HOME/openclaw-cluster/rd-dept \ OPENCLAW_WORKSPACE_DIR=$HOME/openclaw-cluster/rd-dept/workspace \ COMPOSE_PROJECT_NAME=openclaw-rd \ ./docker-setup.sh

避坑指南:

  • 交互引导中,遇到 Gateway bind 选项时,务必选择 LAN,否则后续 Open WebUI 无法跨容器连接。
  • 如果需要再给【运营部】建一个节点,只需把上面命令中的端口(例如改为 18770/18771)、目录和 PROJECT_NAME 改掉,再运行一次即可,完美实现物理隔离!

第三步:修改网关配置,开启 OpenAI 兼容接口 (Chat Completions)

部署完节点后,默认情况下 OpenClaw 的网关服务可能并没有显式开启标准的 HTTP API 通道。为了让 Open WebUI 能够顺畅地与它对话,我们需要让 OpenClaw 充当一个“OpenAI 兼容服务器”。

我们需要手动修改各个部门节点下的配置文件(例如我们刚才为研发部创建的 ~/openclaw-cluster/rd-dept/config.json)。

使用文本编辑器(如 nanovim)打开该配置文件,向下滚动找到 "gateway" 属性块。 避坑细节: 在很多默认生成的配置中,gateway 下方是没有 http 这个属性的。我们需要手动把这块代码补进去,开启对话补全端点:

JSON

{ "gateway": { "http": { "endpoints": { "chatCompletions": { "enabled": true } } } // 注意:不要漏掉 json 的逗号和括号层级 } }

(保存并退出后,切记使用 sudo docker compose -p openclaw-rd restart 重启一下该节点的容器,让新配置生效。)

提取部门专属“钥匙” (Token)

配置改完后,我们要把该节点的 API Token 提取出来,这相当于 Open WebUI 敲开该部门大门的“通行证”。

第四步:在 Open WebUI 中接入网关并分配权限 (终极联调)

当我们把各个部门的 OpenClaw 节点都跑起来,并拿到对应的 API Token 后,就到了“万剑归宗”的最后一步:将它们统一接入前端面板。

1. 进入外部连接设置 使用管理员账户登录 Open WebUI,点击右上角头像进入 管理员面板 (Admin Panel),在左侧菜单选择 设置 (Settings),然后点击 外部连接 (Connections)

2. 添加并配置 OpenAI 接口 在“OpenAI 接口”模块,点击“添加连接”(或编辑现有连接),严格按照以下格式进行填写(参考配图):

  • URL (API 地址):填入 http://host.docker.internal:你的端口号/v1
    • 避坑提醒: 这里的端口号必须是你刚才为该部门分配的 Gateway 端口(例如研发部是 18776,配图中演示的是默认的 18789)。切记,URL 结尾只需要到 /v1,绝对不要画蛇添足加上 /chat/completions
  • 认证方式 (密钥/Bearer):将你在第三步中 gateway.json 里提取出的超长 Token 粘贴到这里。
  • HTTP 标头 (可选但极度推荐):填入 {"x-openclaw-agent-id": "main"}。这行代码的作用是精准唤醒 OpenClaw 中名为 "main" 的主智能体。

3. 测试并保存 填写完毕后,点击右下角的保存。如果配置无误,URL 右侧的刷新按钮旁会亮起一个绿色的开关标志,代表打通成功!

4. 部门级隔离与权限分发 (RBAC) 重复上述步骤,你可以把【研发部】、【运营部】等多个节点的 API 全部添加进来。 接着,进入 WebUI 的 工作区 (Workspace) -> 模型 (Models),利用刚接入的不同 API 接口,创建对应的专署大模型。最后,通过系统自带的用户组(Groups)权限管理,设定“研发部模型仅研发员工账号可见”。

至此,一个数据物理隔离、权限精准管控、对话可查可溯源的企业级多部门 AI 平台,就在你的服务器上彻底落成了!

Read more

前端与 Spring Boot 后端无感 Token 刷新 - 从原理到全栈实践

前端与 Spring Boot 后端无感 Token 刷新 - 从原理到全栈实践

🌷 古之立大事者,不惟有超世之才,亦必有坚忍不拔之志 🎐 个人CSND主页——Micro麦可乐的博客 🐥《Docker实操教程》专栏以最新的Centos版本为基础进行Docker实操教程,入门到实战 🌺《RabbitMQ》专栏19年编写主要介绍使用JAVA开发RabbitMQ的系列教程,从基础知识到项目实战 🌸《设计模式》专栏以实际的生活场景为案例进行讲解,让大家对设计模式有一个更清晰的理解 🌛《开源项目》本专栏主要介绍目前热门的开源项目,带大家快速了解并轻松上手使用 🍎 《前端技术》专栏以实战为主介绍日常开发中前端应用的一些功能以及技巧,均附有完整的代码示例 ✨《开发技巧》本专栏包含了各种系统的设计原理以及注意事项,并分享一些日常开发的功能小技巧 💕《Jenkins实战》专栏主要介绍Jenkins+Docker的实战教程,让你快速掌握项目CI/CD,是2024年最新的实战教程 🌞《Spring Boot》专栏主要介绍我们日常工作项目中经常应用到的功能以及技巧,代码样例完整 👍《Spring Security》专栏中我们将逐步深入Spring Security的各个

YOLO12检测结果导出功能:WebUI支持PNG下载+JSON结果保存

YOLO12检测结果导出功能:WebUI支持PNG下载+JSON结果保存 1. 引言:从“看得到”到“用得上” 你刚用YOLO12跑完一张图片,屏幕上花花绿绿的检测框确实挺酷——人、车、狗都标出来了,置信度也显示得清清楚楚。但接下来呢?你想把这张带标注的结果图保存下来发给同事看,或者想把检测到的所有目标信息(比如坐标、类别)导出来做进一步分析,是不是突然发现有点无从下手? 这就是很多目标检测工具的一个小痛点:检测过程很流畅,结果展示很直观,但到了“把结果拿出来用”这一步,往往就卡住了。要么只能截图保存,丢失了原始数据;要么得自己写代码去解析后台返回的信息,麻烦得很。 今天要聊的,就是YOLO12镜像里一个特别实用的功能升级:检测结果导出。现在,你不仅能在WebUI上实时看到检测效果,还能一键下载带标注的PNG图片,同时自动保存包含所有检测细节的JSON文件。简单说,就是从“只能看”变成了“既能看又能用”。 这个功能听起来简单,但在实际工作里能省不少事。比如做安防监控的演示,你需要把检测结果存档;比如做数据分析,

前端多版本零404部署实践:为什么会404,以及怎么彻底解决

这是一篇给“小白也能看懂”的实践文:讲清现象、根因、方案选择与我们的落地实现。 1. 现象:为什么发布新版本后会出现 404? 一个真实场景: * 10:00 用户打开了你的网页(加载的是 v1.0.4 的 HTML) * 10:10 你发布了 v1.0.5 * 用户没有刷新页面,继续点击某个功能 * 页面尝试按旧 HTML 里的地址加载某个 chunk:/assets/pages-about-about.DK5VADjQ.js * 服务器上只剩 v1.0.5 的文件,旧的被删了 → 直接 404 关键点: * HTML 决定了要加载哪些 JS/CSS(包含具体

2026实测|DeepSeek-R1-Distill-Qwen-1.5B部署全攻略(vLLM+Open WebUI,0.8GB显存就能跑,告别服务器瓶颈)

2026实测|DeepSeek-R1-Distill-Qwen-1.5B部署全攻略(vLLM+Open WebUI,0.8GB显存就能跑,告别服务器瓶颈)

前言:2026年,轻量级大模型部署已成为开发者核心需求——专业GPU服务器成本高昂、边缘设备算力有限,多数1.5B级模型仍需3GB以上显存,让个人开发者与中小企业望而却步。而DeepSeek-R1-Distill-Qwen-1.5B(下称“DQ-1.5B”)的出现打破僵局,通过知识蒸馏技术在1.5B参数体量下实现接近7B级模型的推理能力,配合vLLM推理加速与Open WebUI可视化交互,实测0.8GB显存即可稳定运行,无需高端服务器,个人PC、边缘设备均可轻松落地。本文结合2026年最新实测数据,从核心原理、分步实操、实测验证、应用场景、落地案例到问题排查,打造零冗余、高可用的部署全攻略,兼顾专业性与实用性,助力开发者快速上手,轻松实现轻量级大模型本地化部署。 一、核心技术解析 部署前先理清三大核心组件的核心逻辑,无需深入底层源码,聚焦“为什么能用、为什么高效”,贴合开发者落地需求。 1.1 模型核心:DeepSeek-R1-Distill-Qwen-1.5B 优势解析 DQ-1.5B是DeepSeek团队基于Qwen-1.