Claude Code 配 TaoToken，跑通 one-api 本地 ollama+deepseek-r1

1. 手动下载 one-api.exe 之后，卡点变成了“谁来写命令”

one-api 的常规部署路径大家都熟：下载 one-api.exe，运行后打开 localhost:3000，默认账号 root、默认密码 123456，进去改掉初始密码，接着添加渠道、把 Ollama 里的模型填进去，创建令牌，最后用 Apipost 发一条 Chat Completions 请求验证。这套流程本身没问题，但操作密度太高：模型名要从 ollama list 的输出里逐字抄，令牌要复制好几次，请求体得自己拼，报错 404 了还得回头检查模型 ID 是不是少了个冒号。

所以我想让 Claude Code 来干“生成配置命令”这件事。可这里有个先决条件：Claude Code 自己得先有一条稳定的推理通道。官方通道额度紧张，切模型又麻烦，于是我先用 TaoToken 拉通这条路。TaoToken 是一个兼容 Anthropic 协议的接入通道，在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 注册并创建 API Key 后，把 Base URL 填成 https://taotoken.net/api，Claude Code 就能正常对话。接下来分工就很顺了：TaoToken 负责让 Claude Code 开口说话，Claude Code 负责把 one-api 添加渠道、创建令牌的步骤拆成清单，最后由 one-api 自己的令牌在 Apipost 里验证 Ollama 的 deepseek-r1 是否真的通了。

2. 用 env 把 Claude Code 指到 TaoToken，先让它能推理

2.1 Key 从官网拿，但别把它填进 one-api 后台

打开 https://taotoken.net/?utm_source=taotoken_aicg_blog_end ，登录后创建一个 API Key。这一步拿到的 Key 只服务 Claude Code，不要顺手填进 one-api 的渠道里。one-api 的渠道需要的是你自己的大模型服务商 Key，或者 Ollama 这种本地服务的占位密钥。两个 Key 职责不同，混着填会出现“Claude Code 能说话，但 Apipost 测试一直 401”的怪现象。

2.2 三个变量：BASE_URL、TOKEN、MODEL

Claude Code 读取的是 Anthropic 系环境变量。在 ~/.claude/settings.json 的 env 块里写入：

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://taotoken.net/api",
    "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY",
    "ANTHROPIC_MODEL": "<以 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 模型广场为准>"
  }
}

注意三点：第一，ANTHROPIC_BASE_URL 这里填的是 https://taotoken.net/api，末尾没有 /v1，TaoToken 的接口路径里自带版本处理；第二，YOUR_API_KEY 是占位符，你得用官网创建的真实 Key 替换；第三，模型 ID 不要拍脑袋写，登录官网模型广场看一眼当前可用的模型名再填，避免后面出现 model not found。

如果用命令行临时起一次对话，也可以这样导：

export ANTHROPIC_BASE_URL="https://taotoken.net/api"
export ANTHROPIC_AUTH_TOKEN="YOUR_API_KEY"
export ANTHROPIC_MODEL="<模型广场上的模型 ID>"
claude -p "用一句话说明你现在用的模型和接口地址"

2.3 先用 CLI 快速测连通性

如果你习惯用命令行验证，可以先全局装一下 TaoToken 的 CLI：

npm install -g @taotoken/taotoken
taotoken cc -k YOUR_API_KEY -u https://taotoken.net/api -m <模型广场上的模型 ID>

命令能正常返回一段文字，说明 Key、Base URL、模型 ID 三者都对得上。此时 Claude Code 已经具备推理能力，可以进入下一环节：让它帮你拆解 one-api 的部署步骤。

3. 让 Claude Code 拆解 one-api 添加 Ollama 渠道的步骤

3.1 给 Claude 的提示词要带上原文关键信息

不要笼统地说“帮我配置 one-api”，而是把当前状态写清楚。你可以这样发：

“本机 Ollama 已经在跑 deepseek-r1:14b，one-api 的 Windows 版已经启动，后台地址是 localhost:3000，默认账号 root，密码已改。请按 one-api 官方文档给我一份添加 Ollama 渠道的表单填写清单，再给一条 curl 命令，直接向 localhost:3000/v1/chat/completions 发起一次测试请求。命令先列出来，由我在本机执行，执行结果再回贴给你。”

这样 Claude Code 会基于 one-api 的真实接口规范来回答，而不是套用 OpenAI 的模板。它给出的渠道配置一般长这样：

渠道类型：Ollama
渠道名称：ollama-local
代理地址：http://localhost:11434
模型映射：deepseek-r1:14b
密钥：任意占位字符，例如 ollama

Ollama 本地不校验密钥，密钥栏填一个占位字符串即可。代理地址必须指向 Ollama 的默认监听端口 11434，而不是 one-api 自己的 3000。这里容易搞反，Claude Code 生成的清单里也会专门强调这一点。

3.2 测试渠道时的 curl 可以这样发

在 one-api 后台点“测试”按钮之前，你也可以直接用 curl 打一次 one-api 的接口，确认渠道链路是通的：

curl http://localhost:3000/v1/chat/completions \
  -H "Authorization: Bearer <one-api 后台创建的令牌>" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek-r1:14b", "messages": [{"role": "user", "content": "你是谁"}], "stream": false}'

这里用的是 one-api 自己生成的令牌，不是 TaoToken 的 Key。响应里如果能看到 choices 数组和 usage 字段，说明 one-api 到 Ollama 这一段已经打通。Claude Code 生成的命令只管列出来，实际执行在你本地终端完成，再把返回结果贴回去让它分析。

3.3 创建令牌这一步仍然在 one-api 后台完成

Claude Code 能帮你写清令牌的权限范围，但“点击创建令牌”这个动作必须由你手动在 localhost:3000 后台完成。创建后把令牌完整复制一次，后面 Apipost 测试要用。令牌是一串随机字符串，复制时注意别选漏最后几位，问题大多出在这。

4. 在 Apipost 里用 one-api 自己的令牌验收 deepseek-r1

4.1 请求地址和请求体

Apipost 里新建一个 HTTP 请求，方法选 POST，地址填：

http://localhost:3000/v1/chat/completions

Headers 里加一项：

Authorization: Bearer <one-api 令牌>

Body 选 raw JSON，填入：

{
  "model": "deepseek-r1:14b",
  "messages": [
    {
      "role": "user",
      "content": "你是谁"
    }
  ],
  "stream": false
}

这里的 /v1 是 one-api 服务自己提供的路由前缀，和 TaoToken 的 https://taotoken.net/api 是两套地址体系。TaoToken 的 Base URL 不带 /v1，one-api 的聊天补全地址必须带 /v1，两者不要互相套用。

4.2 看返回要重点看 usage

点击发送后，正常响应里 model 字段应返回 deepseek-r1:14b，choices[0].message.content 是模型生成的文本，usage 下会有 prompt_tokens、completion_tokens、total_tokens 三组数字。第一次验证时先别急着看回答内容是否惊艳，先确认这三个数字不是 0，因为如果渠道配置错误，有时候会返回空内容但 HTTP 200，只有 usage 字段暴露了真实情况。

如果返回 404，检查 model 是否和 one-api 渠道里填的模型名完全一致，deepseek-r1:14b 的冒号和 14b 前面的空格都是容易错的地方。如果返回 401，多半是令牌复制不完整，或者 Headers 里 Bearer 后面多了一个空格。

5. 用 winsw 把 one-api 注册成 Windows 服务

5.1 两个 exe 千万别弄混

one-api 手动启动时，双击的是项目编译出来的 one-api.exe。要让它在后台常驻，需要另一个工具 winsw，下载 wws 发布包后把它重命名为 oneapi.exe（注意少了一个杠，但文件名区分明显）。把两个 exe 放在同一个目录，例如 E:\oneapi\ 下。然后新建一个 oneapi.xml，内容如下：

<service>
  <id>oneapi</id>
  <name>oneapi</name>
  <description>one-api local gateway</description>
  <logpath>E:\oneapi\logs</logpath>
  <executable>E:\oneapi\one-api.exe</executable>
  <logmode>rotate</logmode>
</service>

logpath 和 executable 都改成你自己的实际目录。logmode 设为 rotate 可以避免日志文件无限膨胀。注意这里写的是 one-api.exe，代表你要常驻的那个主程序，而不是前面重命名出来的 oneapi.exe。

5.2 管理员的 PowerShell 里执行安装

打开管理员 PowerShell，cd 到 E:\oneapi，执行：

.\oneapi.exe install
.\oneapi.exe start

install 会把服务注册到 Windows 服务管理器里，start 立即启动。之后每次开机都会自动拉起 one-api，不需要再手动双击 exe 了。如果 install 报错，先检查 XML 里 <executable> 路径是否写对，以及当前 PowerShell 是否是管理员权限。

5.3 服务起来之后重新验证一次

服务方式启动后，回 localhost:3000 看一眼后台是否正常。然后用 Apipost 再发一次第 4 节的请求，确认 service 环境下模型调用依然通畅。到这里，one-api 本地部署、Ollama 模型接入、Apipost 验证、Windows 服务常驻四个环节都走完了。

6. 排障对照：model 404、令牌 401、用量看不到

6.1 model 404 时先查 Ollama 侧

如果 Apipost 返回类似 model not found 的提示，先在本机执行：

ollama list

确认 Ollama 里实际的模型名称是 deepseek-r1:14b 还是 deepseek-r1。有些版本用 deepseek-r1:latest 作为默认标签，one-api 渠道里的模型名必须与 ollama list 输出的名字完全一致。改完渠道里的模型名后，在 one-api 后台点一次“测试”，再回 Apipost 重发。

6.2 令牌 401 时不要急着重建令牌，先检查复制是否完整

one-api 创建的令牌只在创建时完整显示一次，如果你当时没有复制完整，后台是没法再次查看的。这种情况下只能新建令牌，并在创建后立刻复制到 Apipost 的 Authorization 字段里。一个容易忽略的细节：one-api 后台的令牌是可以设置过期时间的，如果令牌过期，也会表现为 401。测试期建议先建一个不过期的令牌。

6.3 用量记录要回到控制台里对账

当 Claude Code 和 Apipost 都调通后，打开 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 的控制台，你会看到 TaoToken 这边记录的调用次数和令牌用量；同时登录 one-api 的 localhost:3000，在日志里也能看到每次转发的状态码。两边对一下，就能确认哪一段链路由谁承担：TaoToken 负责 Claude Code 的推理请求，one-api 负责本机 Ollama 模型对外暴露的兼容接口。

我自己的体会是：整个部署最难的不是 one-api 表单怎么填，而是同时维护两套 Key 和两套地址还不搞混。TaoToken 的 https://taotoken.net/api 只写给 Claude Code 用，one-api 的 localhost:3000/v1 只写给 Apipost 用，各管一段，反而比一开始就把所有服务串在一起更利于排查问题。等你把模型 ID、令牌、服务启动这三处都理顺，这个本地推理链路就能稳定跑下去了。