企业官网建设流程全解析

1. 为什么要把三个模型塞进同一个工作台

我平时写代码、查资料、做技术方案，手头同时开着好几个AI对话窗口是常态。DeepSeek用来啃长文档和推理链，Qwen处理中文语境和代码补全特别顺手，GLM在结构化输出和工具调用上又稳得一批。问题是，每换一个模型就要切一次网页、重新贴一遍上下文，一天下来光复制粘贴就能耗掉半小时。

后来我琢磨着，能不能搞一个统一的工作台，把这三个模型的API都接进来，用同一套界面调用，配置只改两行就能切换？试了大概一个周末，方案跑通了。核心思路其实特别简单：找一个支持多模型接入的开源工作台框架，然后在配置文件里把三个模型的API地址和密钥填进去，剩下的交给框架自己路由。

这篇文章就是把我踩过的坑、调通的配置、以及实际用下来的感受完整记录下来。适合那些手头有多个模型API、想统一管理但不想折腾太多代码的人。如果你只会用网页版对话，看完也能照着搭起来，不需要太深的编程基础。

提示：本文涉及的所有配置均基于公开可用的API接口，不涉及任何特殊网络环境。你只需要有对应平台的API Key即可。

2. 选型：为什么我最终用了LobeChat而不是自己写

2.1 自建工作台的三个现实问题

一开始我是想自己写一个简单的Web界面，用Python的FastAPI做后端，前端随便糊一个聊天框。想法很美好，实际动手才发现问题一堆。

第一个问题是流式输出的处理。三个模型的API返回格式虽然大体相似，但在流式传输的细节上各有各的脾气。DeepSeek的流式返回里有时候会夹杂空的delta，Qwen在某些情况下会把reasoning content和正式回答混在一起推过来，GLM的工具调用结果又是单独一个字段。自己写解析逻辑，光处理这些边界情况就够喝一壶的。

第二个问题是会话管理。我想让同一个对话里能随时切换模型，比如前半段用DeepSeek推理，后半段切Qwen润色。这就意味着对话历史要统一存储，而且切换模型时要把历史消息转换成对应API能接受的格式。自己实现的话，光是消息格式的转换映射就得好几百行代码。

第三个问题是界面。我虽然能写前端，但写出来的东西跟“好用”之间差了十万八千里。流式打字效果、代码高亮、Markdown渲染、对话列表管理，这些细节自己从头做，没个两周根本下不来。

2.2 LobeChat吸引我的几个点

后来在GitHub上翻到了LobeChat，试了一下发现它几乎覆盖了我所有需求。它本身是一个开源的多模型聊天框架，支持OpenAI兼容的API接口，而DeepSeek、Qwen、GLM恰好都提供了OpenAI兼容的端点。这意味着我不需要为每个模型写适配器，只要在配置里声明模型名称和API地址就行。

更关键的是，LobeChat的配置文件结构非常清晰。模型列表、API端点、密钥管理是分开的，改起来不会牵一发动全身。我实际测试下来，从零到跑通三个模型，真正需要改的只有两行核心配置——一行是模型列表的声明，一行是API端点的指向。

另外它的会话管理做得很好，同一个对话窗口里可以随时切换模型，历史消息会自动保留。代码高亮用的是Shiki，渲染效果比我之前用的highlight.js好不少。Markdown表格、数学公式、Mermaid图表都能正常显示，虽然我平时用不到Mermaid，但有总比没有强。

2.3 部署方式的选择

LobeChat支持两种部署方式：Vercel一键部署和Docker本地部署。我选了Docker本地部署，原因有两个。

一是数据隐私。虽然API调用本身是走各家的服务，但对话历史存在本地总归安心一些。二是网络稳定性。本地部署不依赖外部托管平台，响应速度更可控。Docker部署的命令很简单：

docker run -d -p 3210:3210 \ -e OPENAI_API_KEY=sk-xxxx \ -e OPENAI_PROXY_URL=https://api.deepseek.com/v1 \ -e ACCESS_CODE=your_password \ lobehub/lobe-chat

这里OPENAI_API_KEY填你第一个模型的密钥，OPENAI_PROXY_URL填对应的API地址。后面要加其他模型，改环境变量或者直接改配置文件都行。

注意：ACCESS_CODE一定要设，不然任何人访问你的3210端口都能白嫖你的API额度。我一开始没设，第二天发现额度少了一大截。

3. 两行核心配置到底改了什么

3.1 第一行：模型列表的声明

LobeChat的模型列表配置在src/config/modelProviders目录下，每个模型提供商对应一个配置文件。但如果你不想动源码，更简单的方式是通过环境变量或者config文件来声明。

我实际改的第一行是在.env文件里加了这么一句：

OPENAI_MODEL_LIST=deepseek-chat,deepseek-reasoner,qwen-max,qwen-plus,glm-4-plus,glm-4-flash

这行配置的作用是告诉LobeChat：我这个OpenAI兼容端点下有哪些模型可用。LobeChat会根据这个列表在界面上生成模型选择菜单。每个模型名称必须和API提供商那边的模型ID完全一致，大小写敏感。

这里有个坑：DeepSeek的推理模型叫deepseek-reasoner，不是deepseek-r1。我一开始填了deepseek-r1，界面上能选，但调用就报404。后来查了官方文档才发现模型ID是deepseek-reasoner。Qwen的模型ID也分得很细，qwen-max、qwen-plus、qwen-turbo是不同的端点，价格和能力都不一样。

3.2 第二行：API端点的指向

第二行配置是API端点的指向。因为三个模型的API地址不同，我需要让LobeChat知道每个模型该往哪里发请求。

LobeChat支持在模型级别覆盖API端点。在config文件或者环境变量里，可以这样写：

OPENAI_PROXY_URL=https://api.deepseek.com/v1

但这只能设一个全局端点。要让不同模型走不同端点，需要在模型提供商配置里做文章。我采用的方式是在modelProviders配置中为每个提供商单独声明：

{ "deepseek": { "id": "deepseek", "name": "DeepSeek", "type": "openai", "openai": { "apiKey": "sk-deepseek-xxxx", "baseURL": "https://api.deepseek.com/v1" } }, "qwen": { "id": "qwen", "name": "Qwen", "type": "openai", "openai": { "apiKey": "sk-qwen-xxxx", "baseURL": "https://dashscope.aliyuncs.com/compatible-mode/v1" } }, "glm": { "id": "glm", "name": "GLM", "type": "openai", "openai": { "apiKey": "sk-glm-xxxx", "baseURL": "https://open.bigmodel.cn/api/paas/v4" } } }

这段配置的核心就是三个baseURL。DeepSeek的兼容端点、Qwen的DashScope兼容模式、GLM的开放平台v4端点，都是官方提供的OpenAI兼容接口。只要把这三个地址填对，LobeChat就能自动路由到对应的服务。

提示：Qwen的兼容模式端点地址是https://dashscope.aliyuncs.com/compatible-mode/v1，注意末尾的/v1不能少。GLM的端点末尾是/v4，也不是/v1，这个容易搞混。

3.3 为什么只需要改这两行

你可能会问，为什么别的框架要改一堆东西，这里两行就够了？核心原因是LobeChat把“模型提供商”和“模型”两个概念解耦了。

模型提供商负责定义API端点、密钥、请求头这些连接层面的东西。模型负责定义具体的模型ID、上下文窗口、能力标签这些业务层面的东西。两者通过provider字段关联。所以新增一个模型提供商，只需要在提供商列表里加一条记录，然后在模型列表里声明它下面有哪些模型。剩下的路由、格式转换、流式解析，框架都帮你处理了。

这也是我选LobeChat而不是自己写的主要原因。自己写的话，每接一个新模型都要重复处理一遍流式解析、错误重试、超时控制这些脏活。用框架的话，这些逻辑是复用的，新增模型只是加配置的事。

4. 三个模型的实际分工与调用体验

4.1 DeepSeek：长文档推理的主力

DeepSeek在我的工作流里主要承担两类任务：一是长文档的摘要和问答，二是需要多步推理的技术方案设计。

deepseek-chat的上下文窗口是64K，deepseek-reasoner是64K并且带思维链。我实测下来，丢一篇两万字的论文进去做摘要，deepseek-chat的响应速度很快，大概十几秒就能出结果。deepseek-reasoner会慢一些，因为它会先输出一段思考过程，但推理质量确实更高，尤其是在需要逻辑推导的场景下。

价格方面，DeepSeek的定价在三个模型里是最低的。deepseek-chat的输入价格大概是每百万token一块钱出头，输出价格是每百万token两块钱左右。这个价格让我可以放心地把大量文档丢进去处理，不用太心疼成本。

有一个细节需要注意：deepseek-reasoner的思考过程也会计入输出token。如果你只是要最终答案，可以在调用时设置max_tokens来限制思考过程的长度，避免不必要的消耗。

4.2 Qwen：中文语境和代码补全的顺手选择

Qwen我用得最多的是qwen-max和qwen-plus。qwen-max的能力最强，适合处理复杂的中文理解和生成任务。qwen-plus性价比更高，日常的代码补全、文案润色用它就够了。

Qwen在中文语境下的表现确实比另外两个模型更自然。比如我让它写一段中文技术文档，Qwen的输出读起来更像人话，不会出现那种翻译腔。代码补全方面，Qwen对Python和JavaScript的支持很好，尤其是对国内常用的框架和库比较熟悉。

Qwen的API端点走的是DashScope的兼容模式。这里有个小坑：DashScope的兼容模式对请求频率有限制，免费额度下QPS比较低。如果你并发调用比较多，可能会遇到429错误。解决办法是加一个简单的重试逻辑，或者在LobeChat里把并发数调低。

价格上，qwen-plus的输入价格大概是每百万token八毛钱，输出价格是每百万token两块钱。qwen-max贵一些，输入每百万token二十块，输出每百万token六十块。所以我一般用qwen-plus做日常任务，只在需要高质量输出时才切到qwen-max。

4.3 GLM：结构化输出和工具调用的稳定选手

GLM我用的是glm-4-plus和glm-4-flash。glm-4-plus的能力最强，glm-4-flash是轻量版，速度快、价格低，适合做简单的分类和提取任务。

GLM最大的优势是结构化输出。我经常需要让模型返回JSON格式的数据，GLM在这方面的稳定性明显好于另外两个。它支持response_format参数，可以强制模型输出合法的JSON。DeepSeek和Qwen虽然也支持类似功能，但在复杂schema下偶尔会出格式错误，GLM则很少翻车。

工具调用方面，GLM的function calling实现得比较完善。我试过让它调用一个查询天气的模拟函数，参数提取和结果整合都很准确。Qwen也支持function calling，但在多轮工具调用场景下，GLM的稳定性更好一些。

价格上，glm-4-flash非常便宜，输入每百万token一毛钱，输出每百万token一毛钱。glm-4-plus贵一些，输入每百万token五十块，输出每百万token五十块。所以我一般用glm-4-flash做批量处理，用glm-4-plus做需要高质量输出的任务。

4.4 三个模型的切换体验

在LobeChat里切换模型非常顺滑。对话窗口顶部有一个模型选择下拉框，点一下就能换。切换后，之前的对话历史会自动保留，新模型能直接看到上下文。

我实测下来，同一个对话里先用DeepSeek做推理，再切Qwen润色，最后用GLM做结构化提取，整个流程没有任何障碍。唯一需要注意的是，不同模型的上下文窗口大小不同。如果对话历史很长，切到上下文窗口较小的模型时可能会被截断。LobeChat会在界面上提示token使用量，方便你判断。

5. 配置过程中踩过的坑和排查思路

5.1 API Key的权限问题

第一个坑是API Key的权限。我一开始用的是一个只开了部分模型权限的Key，结果在LobeChat里选某些模型时一直报403。排查了半天才发现是Key的权限不够。

DeepSeek的Key默认开通所有模型，但Qwen的DashScope Key需要在控制台手动开通对应模型的权限。GLM的Key也类似，需要在开放平台里勾选要使用的模型。所以如果你遇到403错误，第一件事就是去对应平台检查Key的权限设置。

5.2 流式输出的中断问题

第二个坑是流式输出偶尔会中断。表现是回答打到一半突然停了，界面上显示一个错误提示。我查了日志，发现是某个模型的流式返回里包含了一个不合法的JSON片段，导致解析失败。

解决办法是在LobeChat的配置里开启“容错模式”。这个模式会跳过解析失败的片段，继续处理后续内容。开启方式是在环境变量里加：

OPENAI_STREAM_ERROR_HANDLING=skip

这个配置对三个模型都适用。开启后，偶尔的流式解析错误不会再中断整个回答。

5.3 模型ID大小写敏感

第三个坑是模型ID的大小写。DeepSeek的模型ID是全小写加连字符，比如deepseek-chat。Qwen的模型ID是qwen-max这种格式，也是全小写。GLM的模型ID是glm-4-plus，同样全小写。

我一开始把glm-4-plus写成了GLM-4-Plus，结果一直报模型不存在。后来改成全小写就好了。这个坑虽然小，但排查起来挺费时间的，因为错误信息不会直接告诉你大小写问题。

5.4 上下文窗口的token计算

第四个坑是token计算。不同模型的tokenizer不一样，同样的文本在不同模型下的token数可能差不少。LobeChat默认用的是OpenAI的tokenizer来估算，对DeepSeek和GLM还算准确，但对Qwen的估算偏差比较大。

如果你发现Qwen经常提示上下文超限，但实际文本并不长，那可能是token估算的问题。解决办法是在模型配置里手动设置contextWindow和maxTokens参数，覆盖默认的估算值。Qwen-max的上下文窗口是32K，qwen-plus是128K，glm-4-plus是128K，deepseek-chat是64K。把这些值填对，LobeChat就能更准确地判断是否超限。

6. 进阶玩法：用同一个工作台做模型对比

6.1 并排对比三个模型的回答

LobeChat有一个“多模型对话”功能，可以同时向多个模型发同一个问题，然后把回答并排展示。这个功能用来做模型对比特别方便。

我经常用它来测试同一个prompt在不同模型下的表现。比如让三个模型同时写一段快速排序的代码，然后对比代码质量、注释详细程度、边界条件处理。实测下来，DeepSeek的代码最简洁，Qwen的注释最详细，GLM的边界条件处理最完善。这种对比让我能根据具体任务选择最合适的模型。

6.2 用助手预设固定每个模型的角色

LobeChat支持创建“助手”，每个助手可以绑定一个特定的模型和一段系统提示词。我给三个模型分别创建了不同的助手：

• DeepSeek助手：系统提示词是“你是一个擅长逻辑推理和技术方案设计的助手，回答时先给出推理过程再给结论。”
• Qwen助手：系统提示词是“你是一个中文技术写作助手，回答要自然流畅，避免翻译腔，代码注释用中文。”
• GLM助手：系统提示词是“你是一个结构化数据提取助手，所有回答必须用JSON格式，字段名用英文，值用中文。”

这样我切换助手就等于切换了模型加提示词，不用每次手动调整。对于重复性的任务，效率提升很明显。

6.3 成本监控的小技巧

三个模型的定价不同，混用的时候很容易超预算。我养成了一个习惯：每周导出一次LobeChat的对话记录，用脚本统计每个模型的token消耗和估算成本。

LobeChat的对话记录存在本地数据库里，用SQLite就能读。我写了一个简单的Python脚本，按模型分组统计token数，然后乘以对应的单价。这样每周花五分钟就能知道钱花在哪里了。如果某个模型的成本超预期，就调整使用策略，把一些任务迁移到更便宜的模型上。

7. 一些实际使用中的经验体会

配置跑通到现在大概用了两个月，最大的感受是“统一入口”这件事本身带来的效率提升，比单个模型能力提升要明显得多。以前切换模型要开三个浏览器标签页，现在一个窗口全搞定。以前对话历史散落在各处，现在统一存储、随时回溯。

另一个体会是，不要迷信某一个模型。DeepSeek推理强但中文表达偶尔生硬，Qwen中文顺但复杂推理稍弱，GLM结构化好但创意写作一般。三个模型配合使用，取长补短，整体效果比单用一个顶级模型要好。

还有一个实际的小技巧：如果你也在用LobeChat，建议把常用的几个模型固定在模型选择列表的顶部。LobeChat支持拖拽排序，把最常用的拖到前面，切换时能省不少点击。另外，ACCESS_CODE一定要设复杂一点，我后来换了一个16位的随机字符串，再也没出现过额度异常的情况。

最后说一个我最近发现的玩法：用DeepSeek做初步方案设计，然后把方案丢给Qwen做中文润色，最后用GLM把润色后的内容转成结构化的JSON配置。三个模型串起来用，相当于一条小型的自动化流水线。虽然每次都要手动切换，但比起在一个模型里反复调prompt，这种分工方式的效果反而更好。