多个模型服务接入后，请求是否走到正确的地址，取决于配置文件中 provider 区块是否完整、路由规则是否按模型名把请求分配到对应 provider。与其同时修改多个变量，不如先把 provider 定义和路由规则拆开看，否则一次改动出问题时很难判断是地址写错、密钥失效还是匹配规则没生效。

多模型路由配置的核心是：每个 provider 都有独立名称、base_url、api_key，路由规则负责把模型名映射到 provider。操作步骤是：先补齐 provider 定义，再配置路由规则，然后用带模型名的测试请求查看日志确认实际命中。密钥轮换时只修改对应 api_key 并重载配置。注意：不要把 provider 名称当作模型名使用，也不要在路由规则未验证前批量替换密钥。

拆解配置文件中的 provider 区块

一个 provider 区块通常需要三个必备字段：name、base_url、api_key。name 是路由规则中用来指定目标 provider 的标识；base_url 是接收 API 请求的服务地址；api_key 是对应服务商分配给本服务的密钥。有些版本还支持自定义认证头、超时时间、额外请求头，但先把这三个字段写对，再扩展其他参数。

以下是一个 provider 区块的最小骨架；替换其中的占位符并保存到配置文件的 providers 目录或相应位置：

providers:
  - name: "provider-sample"
    base_url: "https://api.example.com/v1"
    api_key: "YOUR_KEY_1"

name 不建议包含空格或斜杠，因为后续路由规则需要用这个值做精确匹配。

为不同模型设置独立的 base URL 和密钥

如果所有 provider 都指向同一个 base_url，那么即使 api_key 不同，请求也只会发到同一个服务地址。要按模型分发，需要给不同模型分配独立地址和密钥。

providers:
  - name: "provider-alpha"
    base_url: "https://llm-alpha.example.com/v1"
    api_key: "ALPHA_API_KEY"
  - name: "provider-beta"
    base_url: "https://llm-beta.example.com/v1"
    api_key: "BETA_API_KEY"

两个 provider 的 name 不同，base_url 指向各自服务，api_key 也独立保存。修改其中一个 provider 的 api_key 不会影响另一个 provider 的路由配置。如果两个模型需要走同一个服务但使用不同密钥，可以保留同一个 base_url、不同 api_key，此时路由规则只负责选择密钥。

按模型名或请求头指定路由的规则

Desktop 判断请求走哪个 provider，常见方式是读取请求体中的 model 字段，与路由规则做匹配；部分版本也支持根据请求头指定 provider。

routes:
  - match:
      model: "alpha-*"
    provider: "provider-alpha"
  - match:
      model: "beta-*"
    provider: "provider-beta"
  - match:
      model: "*"
    provider: "provider-default"

匹配优先级建议按以下顺序处理：先判断是否有精确匹配，再按通配符或前缀匹配，最后落入默认 provider。优先级通常与配置顺序有关，因此建议把最具体的规则写在前面，默认规则写在最后。需要确认当前版本是否兼容这种写法；如果不支持通配符，改用前缀字符串匹配规则也可以。

请求头方式一般用于多客户端共享同一模型名的场景：客户端在请求中带入 X-Provider 头，路由规则按该值选择 provider。这种方式适合桌面端调用多个本地服务时，避免模型名冲突。若请求头值与 provider 名称不一致，需要先建立显式映射，即 header 值映射到哪个 provider name，而不是默认使用同名 provider。

用测试请求确认路由是否正确

配置完成后，向 Desktop 暴露的请求入口发送一条带模型名的测试请求，确认路由结果。请求入口的路径因部署方式不同，通常是一个 OpenAI 兼容的 /v1/chat/completions 地址。下面命令中的模型名 alpha-demo-1 应触发 provider-alpha 路由：

curl http://127.0.0.1:8000/v1/chat/completions -H "Content-Type: application/json" -d '{"model":"alpha-demo-1","messages":[{"role":"user","content":"hello"}]}'

执行后查看 Desktop 运行日志中与本次请求相关的记录。日志默认输出位置通常安装目录下的 logs 文件夹或用户目录下的 ~/.deepseek-harness/logs，具体路径可以在配置文件的 log_path 字段中指定。建议在配置中临时开启 debug 级别的日志，便于看到路由规则命中了哪个 provider。

判断是否正确：日志中记录的 base_url 地址应与 provider-alpha 的 base_url 一致；如果记录的是其他地址，说明模型名没有匹配到预期规则，需要调整路由规则或模型名写法。若返回 401 或 403，先核对对应 provider 的 api_key 是否有效；若返回模型不存在，则说明路由已经按规则转发到了其他 provider。

密钥轮换时的修改步骤

密钥轮换时，只修改配置文件中对应 provider 的 api_key 字段，不要修改 name 和 base_url，否则路由规则会失配。修改完成后需要让进程重新读取配置：支持热重载的版本可以执行 harness config reload 或发送 SIGHUP 信号；不确定时直接重启进程最安全。

kill -HUP $(pgrep -f deepseek-harness)

或重启进程：停止进程后，重新执行与首次启动相同的命令。重启后再次发送测试请求，确认新密钥生效并检查日志。需要注意：如果多个 provider 使用同一个密钥文件，轮换时建议先修改一个 provider 并验证成功，再继续处理其余 provider，避免大量请求在密钥更新期间出现凭证错误。

配置文件的 api_key 字段建议使用独立环境变量或密钥文件引用，减少在文本配置中暴露明文密钥的范围。轮换密钥后，旧的 api_key 可能仍保留在客户端缓存中，需要清理对应凭证缓存或重启相关连接池。