给 DeepSeek Harness 接一个自定义模型服务商

harness 在构造上就是模型无关的：模型适配器只是 dsh-base 里插件提供的配置行，和工具、存储没有区别。 接一个模型，等于声明它在哪、以及怎么跟它说话。

这里有两条路径，选错是绝大多数摩擦的来源。

路径一：目录里已有的服务商

如果你的厂商在目录里——DeepSeek、Anthropic、OpenAI 等——直接在界面里做：

Settings → Add provider → 选服务商 → 粘贴 API key → 保存。

key 会写进 $DSH_HOME/.credentials.yaml。这个文件刻意和 $DSH_HOME/settings.yaml 分开，好让设置可以 共享或纳入版本控制，而凭证不会。

流程就这些。如果这条路径覆盖了你，到此为止。

路径二：自定义服务商

用于 OpenAI 兼容网关、自建推理服务、或任何不在目录里的端点。自定义服务商需要五样东西：小写的 provider ID、base URL、API 协议、凭证引用、模型列表。

llm-pi-ai:
  providers:
    my-gateway:
      apiKeyEnv: GATEWAY_API_KEY
      api: openai-completions
      baseURL: https://gateway.example/v1
      models:
        - id: vision-preview
          input: [text, image]

逐字段说：

my-gateway——provider ID。小写，而且永久。没有改名这回事；要换就得新建一个再删旧的，然后 修好每一处指向旧 ID 的模型引用。当成「你要一直和它共处」来取名，因为你确实会。

apiKeyEnv——一个环境变量的名字，不是 key。这是自定义服务商配置里最常见的错误。把真密钥粘在 这里，既通不过认证，又把一份凭证写进了一个本该可共享的文件。

api——线上协议。面对那一大类暴露 OpenAI 兼容接口的网关和服务，openai-completions 是对的选择。

baseURL——请求发到哪。要不要带 /v1 后缀取决于你的端点，而这一项写错的表现是 404 而不是认证 错误——排查时这是个有用的信号。

models——这个服务商提供什么。每条需要 id 和输入模态：input: [text, image] 声明一个具备视觉 能力的模型，纯文本模型写 [text]。

导出凭证

export GATEWAY_API_KEY="sk-..."
dsh --profile web

这里有两个坑。运行中的 dsh 进程持有它启动时那份环境——把 export 写进 ~/.zshrc 在你重启它之前毫无 作用。另外，从图形界面启动的终端可能根本没 source 过登录 shell。在你实际启动的那个 shell 里查：

printenv GATEWAY_API_KEY

信它之前先验它

先脱离 harness，确认端点和 key 本身能用：

curl -sS https://gateway.example/v1/models \
  -H "Authorization: Bearer $GATEWAY_API_KEY" | head -20

401 是 key 不对，404 通常是 baseURL 不对，连接错误是网络问题而不是配置问题。然后确认服务商在组装后 还活着：

dsh --profile web --dump-config

记住 patch 顺序——bundle、profile 的 cordis.patch.yml、home 级的 $DSH_HOME/cordis.patch.yml、 最后 --patch。home 级的层盖掉你的改动，是「文件里明明有这个服务商、组装后却没有」的常见成因。

一个 harness 挂多个服务商

没有规定只能挂一个。注册好几个是常态——便宜的模型干机械活、强的模型做推理、视觉模型看截图——而在它们 之间路由，正是标准模式里子 agent 存在的意义。

实用建议：provider ID 尽量按角色命名而不是按厂商（fast-bulk、deep-review）。既然 ID 是永久的， 描述用途的名字能挺过一次换厂商，描述厂商的名字挺不过。