企业官网建设流程全解析

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

我平时写代码、查资料、做技术方案，最烦的一件事就是来回切换工具。DeepSeek 用来做代码补全和逻辑推理，Qwen 处理中文长文本和图像理解，GLM 在结构化输出和工具调用上表现稳定。三个模型各有各的脾气，但每次用不同的客户端去调，光是配置 API Key、切换模型、调整参数就够让人抓狂了。

后来我琢磨着，能不能用一个统一的工作台把它们全接进来。试了几种方案之后，发现最省事的路径其实就藏在配置文件里——改两行，三个模型就能在同一个界面里自由切换。这篇文章就是把我踩过的坑、试过的配置、以及最终跑通的方案完整记录下来。

如果你手头有 DeepSeek、Qwen、GLM 的 API Key，又不想装一堆客户端，那这套方案基本可以照抄。哪怕你只用过其中一个模型，看完也能明白怎么把它们串起来用。

2. 工作台选型与整体架构设计

2.1 为什么选这个方案而不是自己写前端

市面上能同时接多个模型的工作台不少，有开源的、有商业的、也有自己拿 Gradio 或 Streamlit 搭的。我一开始也想自己写一个，毕竟前端框架现在很成熟，接几个 API 看起来不难。但实际动手之后发现，真正麻烦的不是界面，而是这几件事：

• 流式输出的统一处理：DeepSeek、Qwen、GLM 的流式返回格式不完全一样，有的用 SSE，有的用 chunked JSON，自己写要处理各种边界情况。
• 对话历史的上下文管理：不同模型的上下文窗口大小不同，Qwen 有 128K 的版本，GLM 有 32K 的，DeepSeek 也有自己的限制。手动裁剪历史很容易把关键信息切掉。
• 工具调用和结构化输出的兼容：GLM 在 function calling 上比较规范，DeepSeek 和 Qwen 各有各的格式，统一起来要写适配层。

所以我最后选了一个支持多模型接入的开源工作台方案，它的核心思路是用统一的 OpenAI 兼容接口去对接不同厂商。只要模型提供 OpenAI 兼容的 API 端点，就能接进来。DeepSeek、Qwen、GLM 目前都提供了兼容接口，这就省掉了大量适配工作。

2.2 整体架构长什么样

整个工作台的结构可以拆成三层：

• 前端交互层：负责聊天界面、模型切换、参数调整、历史记录展示。
• 路由转发层：根据当前选中的模型，把请求转发到对应的 API 端点，同时处理鉴权和格式转换。
• 模型服务层：DeepSeek、Qwen、GLM 各自的 API 服务，通过 HTTPS 接收请求并返回结果。

关键就在于路由转发层的配置。大多数工作台会把模型配置写在一个 YAML 或 JSON 文件里，每个模型一个条目，包含 API Base URL、API Key、模型名称、上下文长度等字段。我要改的那两行，就是在这个配置文件里增加模型条目。

2.3 三个模型的定位差异

在动手配置之前，有必要先搞清楚这三个模型各自擅长什么，这样在工作台里切换的时候才知道什么时候该用谁。

这个表格不是绝对的，每个模型都在快速迭代，但大致定位可以帮助你在工作台里快速决策。比如写 Python 脚本的时候切 DeepSeek，读一篇中文论文的时候切 Qwen，需要模型返回严格 JSON 的时候切 GLM。

3. 配置文件里那两行到底改了什么

3.1 找到配置文件的位置

不同工作台的配置文件路径不一样，常见的位置有：

• 项目根目录下的config.yaml或config.json
• ~/.config/工作台名称/目录下的配置文件
• 环境变量文件.env或.env.local

如果你用的是 Docker 部署，配置文件通常挂载在容器内的/app/config或/data目录。我建议先用find命令搜一下：

find / -name "config*.yaml" -o -name "config*.json" 2>/dev/null | grep -v node_modules

找到之后，用编辑器打开，你会看到类似这样的结构：

models: - name: gpt-4 provider: openai api_base: https://api.openai.com/v1 api_key: sk-xxxx model: gpt-4

这就是模型列表。我要做的就是在models下面追加三个条目。

3.2 第一行：DeepSeek 的接入配置

DeepSeek 的 API 兼容 OpenAI 格式，所以配置起来很直接：

- name: deepseek-chat provider: openai api_base: https://api.deepseek.com/v1 api_key: ${DEEPSEEK_API_KEY} model: deepseek-chat max_tokens: 8192 context_window: 65536

这里有几个点需要注意：

• api_base一定要带/v1，否则会 404。我一开始漏了，排查了半天。
• api_key建议用环境变量引用，不要硬编码在配置文件里。工作台一般支持${VAR_NAME}的语法。
• model字段填deepseek-chat或deepseek-reasoner，后者是推理增强版本，适合复杂逻辑题。
• context_window根据你用的版本填，DeepSeek V3 是 64K，R1 系列可能不同。

3.3 第二行：Qwen 和 GLM 的接入配置

Qwen 和 GLM 的配置逻辑一样，只是端点不同：

- name: qwen-max provider: openai api_base: https://dashscope.aliyuncs.com/compatible-mode/v1 api_key: ${QWEN_API_KEY} model: qwen-max max_tokens: 8192 context_window: 32768 - name: glm-4 provider: openai api_base: https://open.bigmodel.cn/api/paas/v4 api_key: ${GLM_API_KEY} model: glm-4 max_tokens: 4096 context_window: 32768

Qwen 的兼容端点走的是 DashScope 的 compatible-mode，GLM 走的是智谱的 v4 接口。两个都支持 OpenAI 格式的请求体，所以provider都填openai就行。

注意：GLM 的 API Base 末尾不要加/v1，它用的是/api/paas/v4，加了反而会出错。这个和 DeepSeek 正好相反，我在这上面栽过跟头。

3.4 环境变量怎么设

把 API Key 放在环境变量里，既安全又方便切换。在.env文件里写：

DEEPSEEK_API_KEY=sk-your-deepseek-key QWEN_API_KEY=sk-your-qwen-key GLM_API_KEY=your-glm-key

如果你用 Docker Compose，可以在environment段里引用：

environment: - DEEPSEEK_API_KEY=${DEEPSEEK_API_KEY} - QWEN_API_KEY=${QWEN_API_KEY} - GLM_API_KEY=${GLM_API_KEY}

这样配置文件里只写变量名，不会泄露密钥。团队协作的时候，每个人用自己的.env文件，配置文件可以提交到 Git 仓库。

4. 实操过程与核心环节实现

4.1 从零开始搭建的完整步骤

假设你从一台干净的机器开始，下面是完整的操作流程。

第一步：安装基础运行环境

工作台通常需要 Node.js 或 Python 运行时。以 Node.js 为例：

# 安装 Node.js 20 LTS curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt-get install -y nodejs # 验证版本 node -v npm -v

如果你用的是 Python 方案，那就装 Python 3.10 以上：

sudo apt-get install -y python3.10 python3.10-venv python3-pip python3 --version

第二步：拉取工作台代码

git clone https://github.com/your-workbench-repo.git cd your-workbench-repo

第三步：安装依赖

npm install # 或者 pip install -r requirements.txt

第四步：配置模型

按照上一节的格式，编辑config.yaml，加入 DeepSeek、Qwen、GLM 三个条目。

第五步：设置环境变量

cp .env.example .env # 编辑 .env，填入三个 API Key

第六步：启动服务

npm run start # 或者 python app.py

启动之后，浏览器打开http://localhost:3000，应该就能看到工作台界面，模型下拉框里会出现三个选项。

4.2 参数调优：让每个模型发挥最佳状态

配置能跑通只是第一步，真正影响体验的是参数。不同模型对温度、top_p、max_tokens 的敏感度不一样。

DeepSeek 的参数建议

DeepSeek 在代码任务上表现好，但温度太高容易生成不严谨的代码。我一般这样设：

temperature: 0.3 top_p: 0.9 frequency_penalty: 0.1 presence_penalty: 0.1

写算法题的时候温度可以降到 0.1，让输出更确定。做头脑风暴的时候可以升到 0.7，但代码质量会下降。

Qwen 的参数建议

Qwen 在中文长文本上优势明显，但上下文窗口大不代表可以无限塞。我实测下来，超过 20K token 之后，模型对中间部分的注意力会下降。所以：

temperature: 0.5 top_p: 0.8 max_tokens: 4096

如果做文档摘要，温度设 0.3 更稳。如果做创意写作，可以到 0.8。

GLM 的参数建议

GLM 在结构化输出上很稳，但需要明确告诉它输出格式。温度建议：

temperature: 0.2 top_p: 0.7

做 JSON 提取的时候，温度一定要低，否则字段名可能变来变去。我试过温度 0.8 的时候，同一个请求返回的 JSON 键名居然不一样，排查了好久才发现是温度的问题。

4.3 模型切换的实际体验

配置好之后，工作台界面上一般会有一个下拉框或者快捷键来切换模型。我的使用习惯是：

• 写代码、调 bug：切 DeepSeek
• 读中文文档、分析长文：切 Qwen
• 提取结构化数据、生成 JSON：切 GLM
• 需要多轮工具调用：切 GLM
• 需要深度推理：切 DeepSeek 的 reasoner 版本

切换的时候，对话历史会保留，但不同模型的上下文窗口不同，工作台一般会自动裁剪。如果你发现切换后模型"忘"了之前的内容，那就是历史被裁掉了。解决办法是在切换前把关键信息复制到新的对话里。

4.4 流式输出的统一处理

三个模型都支持流式输出，但返回格式有细微差别。工作台的路由层会做统一转换，把不同格式的 chunk 转成标准的 SSE 事件。如果你自己写适配层，需要注意：

• DeepSeek 的流式返回里，delta字段可能包含reasoning_content，这是推理过程，不是最终答案。
• Qwen 的流式返回有时会在最后一个 chunk 里带usage信息。
• GLM 的流式返回格式最接近 OpenAI 标准，基本不用改。

工作台如果处理不好这些差异，可能会出现输出中断、重复、或者推理内容混入正文的情况。我遇到过 DeepSeek 的推理内容被当成正文显示出来，后来在配置里加了一个strip_reasoning: true才解决。

5. 常见问题与排查技巧实录

5.1 API 返回 401 或 403

这是最常见的问题，原因通常有三个：

• API Key 填错了，或者复制的时候带了空格。
• 环境变量没有正确加载，工作台读到的还是空值。
• API Key 对应的账户余额不足或者权限不够。

排查步骤：

# 先确认环境变量是否生效 echo $DEEPSEEK_API_KEY # 直接用 curl 测试 API 是否通 curl -X POST https://api.deepseek.com/v1/chat/completions \ -H "Authorization: Bearer $DEEPSEEK_API_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"deepseek-chat","messages":[{"role":"user","content":"hi"}]}'

如果 curl 能通但工作台不通，那就是工作台配置的问题。检查配置文件里的api_key字段是否用了正确的变量名。

5.2 模型返回内容被截断

原因通常是max_tokens设得太小，或者上下文窗口超了。DeepSeek 的max_tokens上限是 8192，Qwen 和 GLM 各有不同。如果你发现回答到一半突然停了，先检查这两个参数。

另一个可能是工作台的历史裁剪策略太激进。有些工作台默认只保留最近 10 轮对话，超过就丢。你可以在配置里调整max_history或者context_window的值。

5.3 切换模型后响应变慢

不同模型的响应速度差异很大。DeepSeek 在高峰期可能排队，Qwen 的长文本处理本身耗时，GLM 在工具调用时会有额外开销。如果你觉得某个模型特别慢，可以先测一下网络延迟：

ping api.deepseek.com ping dashscope.aliyuncs.com ping open.bigmodel.cn

如果延迟正常但响应慢，那就是模型服务端的问题，只能等或者换时间段。

5.4 常见问题速查表

5.5 几个我踩过的坑

第一个坑是 GLM 的 API Base 末尾加了/v1，结果一直 404。后来查文档才发现智谱的端点路径不一样。这个和 DeepSeek 的习惯相反，很容易搞混。

第二个坑是环境变量在 Docker 里没传进去。我在.env里写了，但docker-compose.yml里忘了加environment段，容器里读不到。后来加了env_file才解决。

第三个坑是 Qwen 的兼容模式端点有时候会返回非标准格式的错误信息，工作台解析不了就直接崩了。后来在路由层加了一个 try-catch，把错误信息统一转成标准格式才好。

6. 进阶玩法：让工作台更顺手

6.1 给每个模型配不同的系统提示词

工作台一般支持为每个模型单独设置系统提示词。我给 DeepSeek 设的是"你是一个严谨的编程助手，回答要简洁准确"，给 Qwen 设的是"你是一个中文文档分析专家，注重细节和逻辑"，给 GLM 设的是"你是一个结构化数据提取助手，输出必须是合法 JSON"。

这样切换模型的时候，不用每次都手动输入提示词，模型会自动进入对应的角色。

6.2 用快捷键快速切换

如果你经常在三个模型之间切换，可以给工作台配快捷键。大多数工作台支持自定义键盘映射，比如：

• Ctrl+1切 DeepSeek
• Ctrl+2切 Qwen
• Ctrl+3切 GLM

具体配置方法看工作台的文档，一般在设置里有"快捷键"或"键盘映射"的选项。

6.3 对话记录导出与复用

工作台通常支持导出对话记录为 Markdown 或 JSON。我习惯把重要的对话导出，按项目分类存档。下次遇到类似问题，直接搜索历史记录，比重新问一遍快得多。

导出的时候注意，不同模型的对话格式可能不一样。DeepSeek 的推理内容会单独标记，Qwen 的图片理解结果会带图片引用，GLM 的工具调用会带函数名和参数。导出后最好统一整理一下。

6.4 成本控制的小技巧

三个模型的计费方式不同，DeepSeek 按 token 计费，Qwen 有免费额度，GLM 也有自己的套餐。如果你用量大，可以：

• 简单任务用便宜的小模型，复杂任务再切大模型。
• 设置每日 token 上限，避免意外超支。
• 定期检查各平台的用量统计，看看哪个模型花得最多。

我在工作台里加了一个简单的用量统计脚本，每次请求后记录 token 数，月底汇总一下，心里有数。

7. 这套方案还能怎么扩展

现在工作台里只有三个模型，但同样的配置逻辑可以继续加。比如你想加一个本地的 Ollama 模型，只要它提供 OpenAI 兼容接口，就能用同样的方式接进来。或者你想加一个专门做嵌入的模型，也可以单独配一个条目。

配置文件的扩展性很好，每加一个模型就是加几行 YAML。关键是搞清楚每个模型的 API Base、鉴权方式和参数限制。只要这三点对了，剩下的就是复制粘贴的事。

我接下来打算把常用的几个模型都接进来，再配一套自动路由规则——根据问题类型自动选择最合适的模型。比如检测到代码就路由到 DeepSeek，检测到中文长文就路由到 Qwen，检测到 JSON 需求就路由到 GLM。这样连手动切换都省了。

不过自动路由需要写一些判断逻辑，而且不同模型的响应格式要统一处理，工作量不小。等我把这套跑通了，再写一篇分享。