OpenCode 提供商：模型、密钥与配置的 7 项检查

搜索 OpenCode 提供商 的人，可能想知道支持哪些服务、怎样添加第三方 provider、OpenAI 兼容接口能否使用，或者为什么 provider 出现了却找不到模型。提供一张会快速过时的厂商清单并不能解决这些问题；更有用的是一套不依赖单一厂商的判断顺序。

OpenCode 官方 Providers 文档当前把 Credentials、Config、OpenCode 的 Zen、OpenCode 的 Go 和 provider directory 放在同一页。本指南在官方资料之外补充决策层：先分辨配置层级，再选择最小可用连接，核对模型 ID，最后留下验证证据，之后才把它用于有写入风险的编程任务。

Provider 是通往模型服务的路线；model 是该服务实际提供的具体能力；credentials 则证明当前请求被允许。把三者当成一个设置，排错就会失真：有效的 key 修不好错误的模型 ID，能看到模型也不能证明凭据没有过期。

配置作用域是第四个问题。Provider 可能在项目文件里有效，在全局文件里却没有加载；更高优先级的托管设置也可能覆盖你刚刚修改的值。记录文件、作用域、provider 名称、模型 ID 和验证日期，通常比把可能含有路径和策略信息的完整配置文件发到工单里更安全。

常见路径有四种。OpenCode 的 Go 和 OpenCode 的 Zen 是带有各自套餐和模型假设的第一方服务；托管第三方 provider 适合团队已有账单、区域控制或固定模型目录的场景；OpenAI 兼容或本地端点更灵活，但你需要自己负责 URL、模型发现、运行时和排错。

不要只看目录里的名称。先问清楚真正的约束是固定月费、按量控制、数据位置、离线使用、模型能力、延迟，还是团队已经在运维的服务。价格看似低的 provider，如果模型清单不稳定或运行 OpenCode 的环境无法验证端点，也可能不是好选择。

官方配置结构把自定义 provider 放在 provider 字段下。具体的 npm adapter、options、鉴权变量和模型映射取决于服务商。应先读 provider 所有者的官方文档，只复制理解的字段，并在团队说明里写清楚为什么选择这个端点和 adapter。

把 secret 留在仓库之外，使用服务商支持的登录流程、环境变量或平台凭据存储。不要把有效 API Key 写进 opencode.json、截图、shell 历史或共享 session。如果密钥曾出现在日志中，应先轮换，再继续排错；只从文件删除并不会抹掉日志历史。

测试时一次只增加一个 provider。最小变更能把 schema 问题和服务故障分开，也能让回滚变得明确：删除新增 provider block，恢复之前的模型选择，再重复已知可用的请求。

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "my-provider": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "provider-demo",
      "options": {
        "baseURL": "https://api.provider.test/v1"
      },
      "models": {
        "model-id": { "name": "Model name" }
      }
    }
  }
}

Provider 条目只有在 OpenCode 能发现真实模型并完成小请求后才算结束。依据当前 provider 文档核对 model ID 和鉴权方式，再用 /models 看 OpenCode 能选择什么。如果 provider 暴露多个变体，先选一个与任务的上下文、工具、延迟和成本相符的模型，不要一次把整个目录都打开。

第一次请求应当只读且容易比较：让模型解释一个小型本地文件，或只列出下一条验证命令而不执行。记录响应是否完整、工具是否可用、耗时，以及是否确实使用预期模型。有证据后再测试编辑或外部写入。

1. 检查作用域确认设置属于全局、项目、自定义路径还是托管配置。
2. 保护密钥使用 OAuth、环境变量或 provider 的凭据存储。
3. 确认 provider核对 provider ID、adapter、端点和官方说明。
4. 确认模型使用 provider 暴露的精确模型 ID，不要只填展示名称。
5. 列出模型打开模型选择器或运行官方记录的 `/models` 流程。
6. 只读测试使用小提示词，并将回答与已知预期进行比较。
7. 留下回滚记录保存有效配置、测试结果和最小撤销步骤。

只要保留鉴权、发现、模型选择和传输之间的边界，provider 错误就更容易修复。401 或 OAuth 循环通常指向凭据或 scope；provider 完全不出现通常是配置作用域、schema 或加载顺序；模型选择器能打开但缺少目标模型，通常是目录或 model ID 问题；发现成功后才超时，则要查网络、代理、区域或服务健康度。

每次只改一个变量。先按官方说明验证端点或 provider 流程，再确认 OpenCode 读的是目标配置文件，然后列出模型，最后才测试提示词。不要通过继续添加 provider 来诊断一个坏 provider，这只会让模型列表和错误日志更难读。

如果日常用量适合第一方订阅和可预测额度，可以考虑 OpenCode 的 Go；如果更看重精选目录和按量控制，可以考虑 Zen；如果团队已有合规、账单、区域或模型需求，托管第三方 provider 更合适；如果必须离线或使用兼容网关，则可以接受本地或 OpenAI 兼容端点，同时承担运行时和模型服务的责任。这些是匹配决策，不是永久排名。

Provider 也会改变隐私假设。CLI 可以在本地运行，但请求仍可能发送到选中的模型服务。应阅读 provider policy，避免发送密钥和不必要的客户数据，第一次测试使用非生产仓库。本站的 models 页讲能力取舍，JSONC 页讲配置作用域，Ollama 页讲本地运行时，Go vs Zen 页讲两个第一方路径；本页通过内链连接它们，不重复整篇内容。

对于宽泛的 OpenCode 提供商 查询，真正有用的结果是可复现的连接，而不是一张会过时的赢家名单。目录、模型、价格、额度和登录要求都可能变化。配置当天重新核对官方页面，并在团队记录里写下日期。