企业官网建设流程全解析

之前我一直是 Open WebUI 的忠实用户，Docker 部署、局域网共享、插件生态，玩了大半年。说实话 Open WebUI 是个好项目，功能多到让我一度觉得除了它不需要别的前端。但上个月我把主力方案整体切换到了 DeepSeek 桌面版——社区里通常叫它 deepseek harness，缩写 dsh 桌面版，甚至在主力机上顺手把 Docker 里的 Open WebUI 容器也清掉了。这篇文章就把我从 WebUI 迁到桌面版的完整过程、配置细节、踩坑记录和选型思路整理出来，给正在 WebUI 和桌面客户端之间纠结的朋友一个参考。

本文适合这几类人看：一是本地或云端部署了 DeepSeek 模型、但现在还在用浏览器网页端做日常交互的；二是觉得 Open WebUI 虽然强大但太重、只想轻量跑个对话界面的；三是想搞清楚 deepseek harness、hermes、dsh 这些桌面版到底什么关系、值不值得换成它的人。我尽量把能落地的操作和能复现的排查过程都写清楚，包括 API 对接、vLLM 本地部署、Codex 接入、上下文续接这些容易出现问题的环节。

1. 为什么我决定告别 WebUI：Open WebUI 的日常痛点

1.1 部署和运维成本被严重低估

Open WebUI 的安装本身不难，一条 Docker 命令就能拉起来：

docker run -d \ --name open-webui \ -p 3000:8080 \ -v open-webui:/app/backend/data \ ghcr.io/open-webui/open-webui:main

但"装起来"和"用着舒服"是两回事。Open WebUI 迭代速度极快，几乎每周都有新版本，而每次升级基本都要重新拉镜像、起容器，数据卷偶尔还会因为 schema 变更出点小问题。我有一次从 0.3.x 升到 0.4.x，整个对话历史全丢了——后来才发现是旧数据卷的目录结构变了，迁移脚本没跑对。那次之后我就对面向上级目录的升级有点心理阴影。

更现实的问题是，Docker 容器常驻意味着内存和 CPU 一直被占着。我的 NAS 兼开发机上同时跑着 vLLM 服务和 Open WebUI，16G 内存经常见底。Open WebUI 后端加前端静态资源服务，常驻内存轻松跑到 500MB 开外，这还没算浏览器标签页的消耗。如果你只是一个人用，这个成本其实是很不划算的。

1.2 浏览器沙箱对本地任务的天然限制

WebUI 跑在浏览器里，看起来是优点——随时随地能访问。但真到重度使用时，问题就来了。

第一个问题是 SSE 流式响应的稳定性。浏览器对长时间保持的连接有自己的策略，标签页一旦被系统挂起（尤其 Mac 上的 Safari、Windows 上的 Edge 后台节能），流式输出就会断开。Open WebUI 有断线重连机制，但实测重连之后上下文经常对不上，会话记录里会出现一段空白。

第二个问题是浏览器标签页的混乱。我习惯同时开着十几个标签页，ChatGPT、Claude、Open WebUI、GitHub、文档，切换成本极高。WebUI 没有独立窗口，没有全局快捷键，每次要跟模型对话都必须先找到那个标签页。这个听起来像小事，但一天几十次下来，效率损耗非常明显。

第三个问题是本地文件操作的割裂感。要在 WebUI 里上传一个本地文件让模型分析，你得先找到文件、再拖拽到网页里；而桌面端可以直接通过系统文件对话框打开，甚至可以配置自动读取某个目录的内容。对于经常让模型分析日志、代码仓库的人来说，这个体验差异是本质性的。

1.3 单人场景下的功能过载

Open WebUI 本质上是一个为多人协作设计的项目：用户注册、角色权限、聊天室共享、模型组管理、RAG 知识库权限隔离……这些功能在团队场景下非常好用，但如果你是个人开发者，90% 的功能都用不上，却要为它们付出常驻服务和浏览器内存的代价。

我并不是说 Open WebUI 不好，而是它的定位决定了它更适合"部署给一拨人用"或者"做一个永远在线的服务"。如果只是自己跟模型对话、写代码、做分析，桌面客户端才是更符合直觉的形态。这就好比你想喝杯手冲咖啡，没必要架一台意式商用机。想明白这一点之后，我就开始认真考察桌面版方案了。

2. 桌面版到底强在哪：它不是"套壳浏览器"，是原生客户端

2.1 从连接到协议：桌面版和 WebUI 的本质区别

很多人以为桌面版就是把网页包了个壳，用 Electron 套一层就完事。但 DeepSeek 桌面版（deepseek harness / dsh）走的路线不太一样：它是一个原生客户端，直接把模型推理引擎的 API 当作后端，自己实现会话管理、上下文拼接、参数配置和流式渲染。

这个区别在协议层面就体现出来了。WebUI 是你和服务器之间的中间层，你的每个请求都先到 WebUI 后端，再由它转发给模型服务；而桌面版是客户端直连模型 API，中间不经过任何 Web 服务。这意味着少了一层转发，也就少了一层出错和延迟的可能，更重要的是——你可以在断网环境下直接连本地 vLLM 或 Ollama，完全离线使用。

我自己的实际使用中还有一个很直观的差别：桌面版对系统代理、环境变量、API Key 的管理是原生应用级别的，调试起来非常直观。比如我同时接了 DeepSeek 官方 API、本地 vLLM、还有第三方兼容接口，在 Open WebUI 里要在管理后台反复切换模型配置，而在桌面版里就是一个简单的配置文件，改完重启即生效。

2.2 资源占用实录：数据会说话

我特意在切换前后做了一组简单的对比，环境是同一台 Windows 11 笔记本，浏览器都是 Chrome，场景都是开着一个对话界面什么都不干，观察常驻内存：

这个数据不一定精确，但量级是可信的。1.2GB 对现在的电脑来说不算什么，但问题是 WebUI 方案里浏览器标签页一旦开多了，这个数字会翻倍甚至翻三倍，而桌面版几乎是一个恒定值。长期开着不关的话，桌面版的能耗优势非常明显。

2.3 和 ChatGPT 桌面版、Claude 桌面版的定位差异

现在各家都出了桌面版，但 DeepSeek 桌面版和它们有一个关键差异：它是面向"自托管模型"设计的。

ChatGPT 桌面版和 Claude 桌面版本质上只是官方 API 的客户端，你没法把它指向本地部署的开源模型，也没法自定义 API 接入点。而 dsh 桌面版的核心能力恰恰是灵活对接各种 OpenAI 兼容接口——无论是 DeepSeek 官方 API、vLLM 部署的本地模型、Ollama 拉下来的量化模型，还是英伟达 NIM 这类第三方托管服务，只要协议兼容，都可以接入。

这一点对我来说至关重要。我在本机部署了一个蒸馏版 DeepSeek 做日常快速问答，同时也会在需要更强推理时调用云端 API。一个客户端能同时管理这两种来源，并且能在一个界面里自由切换模型，这是 ChatGPT 桌面版给不了的。

2.4 关于 deepseek harness 和 hermes 的版本说明

社区里这几个名字很容易把人绕晕。我花了一些时间才理清，整理如下供参考：

• deepseek harness：对 DeepSeek 相关桌面工具链的统称，可以理解为"DeepSeek 生态的客户端工具箱"。
• dsh 桌面版：deepseek harness 的缩写形式，GitHub 和社区里普遍用这个简称指代主流的 DeepSeek 桌面客户端。
• hermes 桌面版：同一个工具链中一个比较稳定的发行分支，社区里很多人直接用 hermes 版本来指代"当前推荐下载的那个桌面版"。你在搜索引擎里看到 "deepseek hermes 下载"、"hermes 桌面版无法更新" 这类词，基本都是围绕这个分支的讨论。

我目前在用的就是 hermes 分支的最新版。后面所有操作记录，都是基于这个版本展开的。

3. 从安装到跑通：DeepSeek 桌面版完整实操记录

3.1 下载安装与初次启动

安装过程没什么特别的，从官方或社区推荐的发布渠道下载对应系统的安装包即可——Windows 有 exe 安装器，macOS 有 dmg，Linux 有 AppImage 或 deb 包。装完第一次启动，界面会比 Open WebUI 简洁得多：左侧是会话列表，中间是对话区，右侧是参数面板。

初次启动要做的事情只有一件：配置一个 API 接入点。点开设置，你会发现它不是那种必须注册账号的云端应用，而是直接让你填 Base URL 和 API Key。这个设计思路贯穿始终——它就是为开发者设计的工具，不是一个面向 C 端的聊天玩具。

3.2 对接不同模型服务：vLLM、Ollama 与官方 API

我同时配了三个接入点，分别应对不同场景。这块是很多人配置时最容易出问题的地方，我把关键参数和坑都列出来。

第一个是 DeepSeek 官方 API。如果你只是想快速跑起来，这是最简单的路径：

Base URL: https://api.deepseek.com API Key: 在 DeepSeek 开放平台创建 Model: deepseek-chat 或 deepseek-reasoner

官方 API 兼容 OpenAI 格式，所以桌面版里几乎不需要额外配置，填上就能用。实测 deepseek-chat 响应速度非常快，首 token 延迟通常在 1 秒以内，适合日常对话。

第二个是本地 vLLM 服务。我在自己的主力机上用 vLLM 部署了一个蒸馏版模型，启动命令大致是：

vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-32B \ --port 8000 \ --tensor-parallel-size 2 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9

然后桌面版接入点填：

Base URL: http://localhost:8000/v1 API Key: 随便填一个占位符即可（vLLM 默认不校验） Model: deepseek-ai/DeepSeek-R1-Distill-Qwen-32B

这里有个坑：vLLM 的/v1路径不能漏。我一开始填的是http://localhost:8000，结果一直报 404，排查了半天才发现 OpenAI 兼容接口的路径前缀是/v1。这个错误非常典型，因为官方 API 不需要这个前缀，让你误以为本地服务也不需要。

第三个是 Ollama。如果你已经有 Ollama 拉好的量化模型，桌面版也可以直接对接：

Base URL: http://localhost:11434/v1 Model: deepseek-r1:7b（或你拉取的具体标签）

Ollama 从某个版本开始也提供了 OpenAI 兼容端点，所以对接同样很顺。Ollama 的好处是零配置、零 Python 环境依赖，适合笔记本上做快速实验；vLLM 的优势是吞吐量大、并发能力强，适合接服务。

3.3 配置文件的几个关键项

桌面版的所有配置最终会落到一个本地配置文件里。这个文件通常在用户目录下，不同系统位置不同，Windows 一般在%APPDATA%\dsh\config.json，macOS 在~/Library/Application Support/dsh/下，Linux 在~/.config/dsh/下。

配置文件的核心结构大致是：

{ "providers": [ { "name": "deepseek-official", "baseUrl": "https://api.deepseek.com", "apiKey": "sk-xxx", "models": ["deepseek-chat", "deepseek-reasoner"] }, { "name": "local-vllm", "baseUrl": "http://localhost:8000/v1", "apiKey": "local", "models": ["deepseek-ai/DeepSeek-R1-Distill-Qwen-32B"] } ], "defaultProvider": "deepseek-official", "defaultModel": "deepseek-chat", "maxContextTokens": 16384, "temperature": 0.7, "stream": true }

如果你不想手动改配置文件，界面里的设置面板也都能操作，只是改完要重启才生效。手动编辑的好处是可以批量配置多个 provider，而且可以精确控制 maxContextTokens 这类高级参数。

3.4 把 Codex 也接到 DeepSeek 上：一套 API 多端复用

既然桌面版支持 OpenAI 兼容协议，那同样协议的工具就都能复用同一个 API。最近我一直在折腾 Codex，这个命令行 AI 编程工具本来是为 OpenAI 官方模型设计的，但通过环境变量也能指向 DeepSeek：

export OPENAI_API_BASE=https://api.deepseek.com/v1 export OPENAI_API_KEY=sk-xxx codex

这里有个细节值得注意：/v1路径在官方 API 上有时可以省略，但在 Codex 这类工具里最好带上，因为它会严格拼接路径。实测 Codex 接入 deepseek-chat 之后，简单代码生成和重构任务能跑通，和官方模型相比速度不差，成本却低很多。

这个思路可以继续向外延伸。任何支持 OpenAI 协议的工具——比如某些开源 IDE 插件、自动化脚本、RAG 框架——理论上都可以把 Base URL 指到 DeepSeek API 或者本地 vLLM。配好一套，到处复用。

4. 日常使用中的真实问题：对话上限、上下文衔接与更新失败

4.1 对话上限之后，怎么让新对话承接上一个对话

这是我在网上看到讨论频率最高的问题之一：DeepSeek 到达对话上限之后，怎么让新对话承接上一个对话的内容？

先说结论：桌面版不会像 Open WebUI 那样自动做上下文压缩，但也不需要你手动复制粘贴全部历史。正确做法是利用会话摘要——在对话到达上下文上限前，先让模型生成一份摘要，然后把这份摘要作为新对话的 System Prompt 或第一条消息。

我自己写了一个小脚本来自动做这件事，核心逻辑是：监测当前会话的 token 用量，超过阈值时自动抽取对话、生成摘要、开启新会话并注入摘要。简化的核心代码是：

from openai import OpenAI client = OpenAI(api_key="sk-xxx", base_url="https://api.deepseek.com") def build_messages(history, new_question, max_tokens=4096): messages = [] total = 0 # 防止无限增长，至少保留最近几条 for item in reversed(history[-20:]): msg = {"role": item["role"], "content": item["content"]} tokens = len(item["content"]) // 2 if total + tokens > max_tokens: break messages.insert(0, msg) total += tokens messages.append({"role": "user", "content": new_question}) return messages

这个方案的核心思路是"最近优先 + 关键信息前置"。模型对新对话的注意力天然集中在开头和结尾，所以把之前的结论和决策放最前面，后面再接当前问题，效果远好于简单地截断历史。如果你不想写脚本，也可以每次手动复制之前的总结放到新对话开头，效果八九不离十。

4.2 桌面版的会话管理机制

和 WebUI 的无限聊天记录不同，桌面版对会话的管理更接近 IDE：一个项目对应一个会话文件夹，每个会话是独立的 Markdown 文件。这个设计的优点是天然的版本管理——你可以直接 diff 两次实验的对话记录，甚至把某次对话追加进代码仓库。

初始使用时多少会不习惯，因为会话列表不会自动膨胀到几百条，它严格按你的手动保存来组织。我现在的习惯是：每个专题建一个会话，比如"vLLM 调优"、"Codex 接入调试"、"RAG 测试"，避免把所有问题混在一个长对话里。混在一个长对话里其实是 WebUI 时代留下的坏习惯，那样上下文窗口很快耗尽，而且查找历史信息非常低效。

4.3 装完新版无法启动的常见原因

社区里能搜到不少"打开闪退"、"启动报错"的问题。我遇到过两次，排查下来基本都是老版本配置文件格式不兼容导致的。新版本启动时会读取旧的 config.json，如果字段结构变了，客户端会直接崩。

解决办法是按顺序试这几个操作：

1. 先备份原配置目录，然后删除配置文件，让客户端生成一个全新的配置。
2. 如果删除后能正常启动，说明就是配置文件兼容问题，手动把之前的 API 配置重新填一遍。
3. 如果删除后仍然闪退，检查是不是下载了不匹配系统架构的安装包——比如在 ARM 版 Windows 上装了 x64 的包，或者 32 位系统装了 64 位应用。

这条排查路径适用于大多数"装完打不开"的桌面软件，不只是 DeepSeek 桌面版。我之前用 ChatGPT 桌面版和 Claude Code 桌面版也遇到过类似问题，基本都是同一个思路解决的。

4.4 工作流保存：桌面版怎么管理预设

WebUI 时代大家习惯保存工作流，比如"代码审查 Prompt"、"日报生成 Prompt"，Open WebUI 把这套做成了可视化流程编辑器。切到桌面版之后，很多人第一个疑惑就是：我的工作流怎么办？

实际体验下来，桌面版的回答方式更直接：把"工作流"拆成"人设预设（System Prompt）+ 参数预设（Temperature、Max Tokens）+ 模型绑定"。你在配置里存好这几样，就等价于一个工作流。它不做可视化连线，但胜在简洁、可版本管理、没有额外心智负担。

我的做法是维护一个预设仓库，每个预设是一个 Markdown 文件，格式大致是：

# 预设：代码审查专家 model: deepseek-reasoner temperature: 0.3 max_tokens: 8192 --- 你是一位资深代码审查专家。请从正确性、性能、安全性、可维护性四个维度 审查用户提供的代码，按严重程度排序输出问题，并给出修改建议。

使用时直接把内容填到预设面板，或者让我自己写了一个小脚本读取仓库自动同步桌面版配置。这样工作流不仅没丢，还比 WebUI 时代更透明、更好维护。

5. 适用边界：哪些场景该留在 WebUI，哪些适合上桌面版

5.1 什么时候我还是会开 Open WebUI

桌面版不是万能的，有些场景它确实替代不了 Open WebUI。

最典型的是多人共享场景。团队里如果有人不太懂技术，你不可能让他去配置 API Key、理解 provider 概念。这时候 Open WebUI 这种网页服务就非常合适：部署好之后，大家只需要浏览器访问一个地址，注册账号就能用，权限和限额在后台统一管理。我团队内部的知识库问答机器人，至今仍跑在 Open WebUI 上。

另一个场景是移动端访问。桌面版目前没有完整的移动端配套，如果你需要在手机上随时找模型对话，WebUI 的响应式页面仍然是不可替代的。我自己的折中方案是：移动端轻量聊天用官方 App，深度工作留在桌面版。

5.2 桌面版目前还不够好的地方

客观说几个让我不太满意的点，省得你们踩同样的坑：

一是插件生态还是太薄。Open WebUI 有丰富的函数插件、工具插件市场，而桌面版目前主要靠配置文件类扩展，面向普通用户的插件系统还在早期。如果你重度依赖 WebUI 的 RAG 知识库、语音对话、多模态附件这类开箱即用功能，桌面版暂时会有点裸奔感。

二是多模态支持仍然有限。DeepSeek 官方 API 本身以文本为主，本地部署的模型很多也是纯文本。图片直接拖进桌面版对话框，目前只能作为引用文件，模型并不能真正"看"图。这个能力 OpenAI 桌面版和 Claude 桌面版已经做得比较完善，DeepSeek 桌面版还需要时间。

三是更新机制略微激进。hermes 分支的更新频率很高，有时候一两周就推送一个新版本。我遇到过两次更新后模型列表里的自定义模型名称变了——因为新版本对模型名的解析规则做了调整。建议每次更新完都检查一下 provider 配置，别等到要用了才发现异常。

5.3 一张表说清选型逻辑

我把自己试过的几个方案放在一起做了一张对比表，你可以根据自己的情况对号入座：

5.4 我个人的最终结论

如果你是一个人用，并且手上已经有了本地推理服务或者 DeepSeek 的 API Key，那桌面版（dsh / hermes 分支）几乎是无脑选择。它省掉了 Docker 那层依赖，省掉了浏览器标签页的管理负担，省掉了很多无意义的配置步骤，换来的是更低的资源占用和更高的操作效率。如果你是要给团队做服务，或者需要随时随地用手机访问，那 Open WebUI 依然有它不可替代的位置。

最后分享一个我在实际使用中养成的习惯：桌面版的所有配置我都在同步到一个 git 仓库里，包括 config.json、预设 Markdown、对接脚本。这样不管换了新电脑还是版本升级出问题，拉一次代码就能完全恢复环境。这个习惯在换机或重装系统时帮我省了大量时间，也让我更愿意深度依赖这个工具。现在我的主力工作流已经完全跑在 DeepSeek 桌面版上，Open WebUI 的容器只在我需要给团队成员开知识库服务时才会启动。