企业官网建设流程全解析

1. 本地模型网关为什么越搭越乱

DB-gpt 是个挺有意思的东西，它能把自然语言直接翻译成 SQL，再顺手把结果画成图表。但真到自己搭的时候，问题就来了：DB-gpt 本身不产模型，它得靠一个 OpenAI 兼容的接口去调后端。于是很多人第一反应是接 one-api，one-api 再去接 kimi-free-api，链路变成 DB-gpt → one-api → kimi-free-api → 模型。三层套下来，任何一个环节的 Base URL 或 Key 写错，报错信息都含糊得让人抓狂。

我见过最常见的翻车现场是这样的：one-api 里渠道配好了，令牌也建了，DB-gpt 的环境变量PROXY_API_KEY填的却是令牌的名称而不是复制出来的sk-开头那串，结果请求直接 401。还有人把PROXY_SERVER_URL写成http://ip:3333，少了/v1/chat/completions，DB-gpt 发出去的请求路径对不上，返回一堆看不懂的 JSON 解析错误。

这套组合本身没问题，kimi-free-api 负责把网页端的额度转成标准接口，one-api 负责统一路由和令牌管理，DB-gpt 负责应用层。问题出在配置分散：三个容器、三套环境变量、两个 Base URL，改一处忘一处。所以这篇的重点不是教你从零装一遍，而是把这条链路里所有需要填 URL 和 Key 的地方，统一收敛到 TaoToken 这一层，让 one-api 只做一件事——把请求转发出去。

TaoToken 在这里扮演的角色，就是一个 OpenAI 兼容的模型网关。它对外暴露标准的/v1/chat/completions，你拿一个 Key 就能调多种模型，不用自己维护 kimi-free-api 的 refresh_token 轮换，也不用担心某个账号 3 小时 30 轮的限额。对 DB-gpt 来说，它看到的还是一个普通的 OpenAI 接口，只是这个接口背后换成了更稳的出口。

适合谁看：已经在跑 DB-gpt、one-api、kimi-free-api 这套组合，但被 401、连接失败、模型路由错乱折腾过的人；或者准备搭一套本地数据分析助手，想少踩点坑的人。下面按“先理链路、再改配置、最后验证”的顺序来，每一步都给可复制的片段。

2. TaoToken 前置准备与 one-api 渠道改造

在动 DB-gpt 之前，先把 one-api 这一层理顺。原来的架构里，one-api 的渠道指向 kimi-free-api 的地址（比如http://192.168.0.3:3334），密钥是 refresh_token 拼接。现在我们要把渠道的 Base URL 换成 TaoToken 的 API 地址，Key 换成 TaoToken 生成的 Key。

先去 TaoToken 控制台拿 Key。打开 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite ，登录后新建一个 API Key，复制那串sk-开头的字符串。这个 Key 就是后面 one-api 渠道里要填的密钥，也是 DB-gpt 最终会间接用到的凭证。

TaoToken 的 API 根地址是https://taotoken.net/api，注意这里不带 UTM 参数，配置里要写干净。one-api 的渠道配置里，Base URL 填这个根地址即可，one-api 会自动拼接/v1/chat/completions。如果你用的是新版 one-api，渠道类型选“OpenAI”，模型名填你要用的，比如kimi、gpt-4o-mini之类，具体看 TaoToken 文档里支持的模型列表：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 。

这里有个容易忽略的点：one-api 的渠道“密钥”字段，填的是 TaoToken 的 Key，不是 kimi 的 refresh_token。原来的 kimi-free-api 那套 refresh_token 拼接逻辑，现在可以整个跳过。如果你还想保留 kimi-free-api 作为备用渠道，可以在 one-api 里建两个渠道，一个指向 TaoToken，一个指向本地 kimi-free-api，然后在令牌里做模型映射。但为了链路干净，建议先把主渠道切到 TaoToken。

改完渠道后，进 one-api 的“令牌”页面，新建一个令牌。关键操作：点“复制”，拿到那串sk-开头的完整字符串。很多人在这里犯错，以为令牌名称就是 Key，结果 DB-gpt 里填了名称，请求发出去就是 401。令牌名称只是给你自己看的备注，真正用于鉴权的是复制出来的那串。

把这两个东西记下来：

• TaoToken Key：sk-开头，填在 one-api 渠道里
• one-api 令牌：sk-开头，填在 DB-gpt 的PROXY_API_KEY里

两者不是同一个东西，别搞混。one-api 的访问地址假设还是http://192.168.0.3:3333，那么 DB-gpt 要连的就是这个地址的/v1/chat/completions。

如果你之前用 kimi-free-api 时遇到过“每 3 小时 30 轮”的限制，切到 TaoToken 后这个限制就不在你这边了，路由和额度由网关侧处理。你只需要保证 one-api 到 TaoToken 这一段网络通就行。

3. 可复制的 one-api 渠道与 DB-gpt 环境变量配置

这一节给可直接粘贴的配置片段。先看 one-api 渠道，如果你用 Docker 跑 one-api，渠道配置是在 Web 界面里填的，但也可以用环境变量或数据库方式预置。最直接的是进 one-api 后台，在“渠道”里新建，填这几个字段：

保存后点“测试”，如果返回绿色成功，说明 one-api 到 TaoToken 这一段通了。如果报错，先看 one-api 日志，常见的是 Key 填错或 Base URL 多了斜杠。

接下来是 DB-gpt 的环境变量。原来的启动命令里，PROXY_SERVER_URL指向的是 one-api 的/v1/chat/completions，PROXY_API_KEY填的是 one-api 令牌。这两个保持不变，只是 one-api 背后的出口换成了 TaoToken。所以 DB-gpt 这边其实不用大改，只要确认这两个值对就行。

一个可复制的 DB-gpt 启动片段（路径按你实际改）：

docker run -d \ --restart unless-stopped \ --name dbgpt \ -p 5670:5670 \ -v /home/admin/models/text2vec-large-chinese:/app/models/text2vec-large-chinese \ -e LOCAL_DB_TYPE=sqlite \ -e LOCAL_DB_PATH=data/default_sqlite.db \ -e LLM_MODEL=proxyllm \ -e PROXY_API_KEY=sk-你的one-api令牌 \ -e PROXY_SERVER_URL=http://192.168.0.3:3333/v1/chat/completions \ -e EMBEDDING_MODEL=text2vec \ -e LANGUAGE=zh \ eosphorosai/dbgpt:latest

注意PROXY_SERVER_URL结尾必须是/v1/chat/completions，不能只写到端口。PROXY_API_KEY是 one-api 令牌，不是 TaoToken Key。这两个值写反了，DB-gpt 启动时不会报错，但一对话就 401。

如果你用 docker-compose，可以写成这样：

services: dbgpt: image: eosphorosai/dbgpt:latest container_name: dbgpt restart: unless-stopped ports: - "5670:5670" volumes: - /home/admin/models/text2vec-large-chinese:/app/models/text2vec-large-chinese environment: - LOCAL_DB_TYPE=sqlite - LOCAL_DB_PATH=data/default_sqlite.db - LLM_MODEL=proxyllm - PROXY_API_KEY=sk-你的one-api令牌 - PROXY_SERVER_URL=http://192.168.0.3:3333/v1/chat/completions - EMBEDDING_MODEL=text2vec - LANGUAGE=zh

one-api 那边如果也想用 compose 管理，渠道配置没法直接写在 compose 里，还是得进后台点。但你可以把 one-api 的数据库挂出来，配置一次后就不用再动。

这里再强调一次三件套的对应关系，因为后面排障全靠它：

• Base URL：one-api 渠道里填https://taotoken.net/api；DB-gpt 里填http://one-api地址:3333/v1/chat/completions
• Key：one-api 渠道里填 TaoToken Key；DB-gpt 里填 one-api 令牌
• Model ID：one-api 渠道里填 TaoToken 支持的模型名；DB-gpt 里通过LLM_MODEL=proxyllm走代理，具体模型由 one-api 路由决定

把这三组值对齐，链路就通了。

4. 一次对话验证请求与多模型路由确认

配置改完，别急着开 DB-gpt 的 Web 界面，先用 curl 从命令行验证一遍。这样出问题能快速定位是哪一层。

第一步，直接测 TaoToken 的接口，确认 Key 有效：

curl -X POST https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer sk-你的TaoTokenKey" \ -H "Content-Type: application/json" \ -d '{ "model": "kimi", "messages": [{"role": "user", "content": "用一句话说明什么是数据库索引"}] }'

如果返回里有choices字段和正常内容，说明 TaoToken 这一层没问题。如果返回 401，检查 Key 是不是复制全了，有没有多余空格。

第二步，测 one-api 的接口，确认令牌和路由正常：

curl -X POST http://192.168.0.3:3333/v1/chat/completions \ -H "Authorization: Bearer sk-你的one-api令牌" \ -H "Content-Type: application/json" \ -d '{ "model": "kimi", "messages": [{"role": "user", "content": "用一句话说明什么是数据库索引"}] }'

这一步如果报 401，大概率是令牌填错，或者 one-api 渠道没启用。如果报“无可用渠道”，去 one-api 后台看渠道状态是不是被禁用了。

第三步，进 DB-gpt 的 Web 界面（默认http://192.168.0.3:5670），在对话窗口里输入一句自然语言，比如“帮我查一下最近 30 天商品价格的变化趋势”。DB-gpt 会先调 LLM 生成 SQL，再执行查询，最后画图。如果前面两步都通了，这一步一般不会卡在模型调用上。

想确认多模型路由，可以在 one-api 里建多个渠道，分别指向 TaoToken 的不同模型，然后在令牌里设置模型重定向。比如把kimi映射到 TaoToken 的 kimi，把gpt-4o-mini映射到另一个。DB-gpt 里通过LLM_MODEL指定用哪个，或者用 DB-gpt 的模型管理界面切换。实测下来，只要 one-api 的渠道测试通过，DB-gpt 这边切换模型基本是即时的。

验证成功后，你会在 DB-gpt 界面看到类似这样的结果：一段生成的 SQL、一个表格、一张折线图。这说明整条链路 DB-gpt → one-api → TaoToken → 模型 已经跑通。

5. 常见报错排查：401、local proxy failed、reading choices

这一节按真实报错来对。我把踩过的坑列出来，你对照着看。

401 Unauthorized：出现频率最高。三个地方会报 401，要分清是哪一层。如果是 curl 直接测 TaoToken 报 401，那是 TaoToken Key 错了。如果是测 one-api 报 401，那是 one-api 令牌错了，注意别把令牌名称当 Key。如果是 DB-gpt 对话时报 401，那是PROXY_API_KEY填错了，回去检查是不是填了 one-api 令牌的复制值。还有一种情况：one-api 渠道里的 TaoToken Key 过期或被删了，这时候 one-api 日志里会显示上游 401，但 DB-gpt 看到的可能是 500。

local proxy failed：这个报错通常出现在 DB-gpt 启动或首次调用时，意思是它连不上PROXY_SERVER_URL。检查三件事：one-api 容器是不是在跑（docker ps看一下）、地址端口对不对、/v1/chat/completions路径有没有漏。如果 one-api 和 DB-gpt 不在同一台机器，确认防火墙放行了 3333 端口。另外，PROXY_SERVER_URL里不要用localhost，容器里访问宿主机要用实际 IP。

reading choices 相关报错：类似KeyError: 'choices'或list index out of range。这说明请求发出去了，但返回的 JSON 里没有choices字段。常见原因是 one-api 返回了错误信息而不是正常响应，比如上游限流、模型名不对。去 one-api 日志里看实际返回体，如果是{"error": ...}，那就是上游问题。还有一种可能是 DB-gpt 期望的响应格式和 one-api 返回的不完全一致，这时候确认 one-api 版本和 DB-gpt 版本是否匹配。

OAuth 或 refresh_token 报错：如果你还保留着 kimi-free-api 渠道，可能会遇到 refresh_token 失效。这类报错的特征是日志里出现refresh token或OAuth。解决办法要么重新抓 refresh_token，要么直接把渠道切到 TaoToken，绕开这套机制。切过去之后，这类报错就不会再出现了。

模型路由错乱：表现是明明选了 kimi，返回的却是别的模型，或者报“模型不存在”。检查 one-api 渠道里的模型名和令牌里的模型映射是否一致。DB-gpt 的LLM_MODEL=proxyllm只是告诉它走代理，具体用哪个模型由 one-api 决定。如果你在 one-api 里配了模型重定向，确认重定向规则没写反。

排查顺序建议：先 curl 测 TaoToken，再 curl 测 one-api，最后看 DB-gpt 日志。一层一层往下，别跳步。

6. 把网关收敛到一层之后

这套组合跑通之后，最大的感受是配置点少了。原来要维护 kimi-free-api 的 refresh_token、one-api 的渠道、DB-gpt 的环境变量，现在 refresh_token 那层被 TaoToken 接管了，你只需要管好两个 Key 和一个 Base URL。

如果你后面要加新模型，比如换个更强的推理模型，不用动 DB-gpt，直接在 one-api 里加个渠道指向 TaoToken 的对应模型，然后在令牌里放开就行。DB-gpt 那边完全无感，它始终认为自己连的是同一个 OpenAI 接口。

长期跑编码或 Agent 类任务的话，可以考虑用 Coding Plan，额度和路由策略会更适合高频调用：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite 。如果只是想先验证模型效果，用模型对话页面直接试就行：https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite 。

最后留一个实用技巧：把 one-api 的渠道测试和 DB-gpt 的启动日志都开成持久化，出问题的时候直接翻日志，比猜快得多。DB-gpt 的日志里会打印实际请求的 URL 和返回码，one-api 的日志里能看到上游响应，两边一对，问题基本就定位了。