配置模型供应商

基于官方 OpenCode Providers 教程，面向新手讲清 provider、凭据、模型选择、本地模型和自定义 endpoint 的边界。

OpenCode 可以接很多 LLM provider。官方 providers 页说明，OpenCode 使用 AI SDK 和 Models.dev，支持 75+ LLM providers，也支持本地模型。

但新手不需要先把每个 provider 的配置都学一遍。你真正要理解的是：provider 负责“模型从哪里来”，credential 负责“怎么认证”，model 负责“具体用哪一个能力”，base URL 负责“请求打到哪里”。

先理解：provider 解决什么问题

Provider 是模型供应商入口。OpenAI、Anthropic、OpenRouter、Bedrock、Ollama、本地 OpenAI-compatible 服务，都属于 provider 层。

添加 provider 通常分两步：先用 /connect 添加 API key，再在 OpenCode 配置里设置 provider 选项。官方说明 /connect 保存的凭据会进入 ~/.local/share/opencode/auth.json。

这意味着凭据和项目配置不是一回事。项目里可以写 provider 选择、baseURL、模型映射；真实 key 不应该提交到仓库。

新手优先选官方推荐的 OpenCode Zen 或你已经有账号的主流 provider。先让 OpenCode 稳定跑起来，再比较价格、速度和模型质量。

如果你只是学习和日常开发，选一个稳定 provider 就够。不要一开始就配置五六个 provider，否则问题会变成“到底是哪家模型/网络/凭据出了错”。

如果你需要国内网络、统一账单或多模型聚合，可以考虑 OpenRouter、302.AI、Vercel AI Gateway、Cloudflare AI Gateway 这类中间层。

如果你需要企业云权限、VPC 或内部合规，才考虑 Bedrock、Azure、Vertex 等企业 provider。

如果你需要隐私或离线实验，可以考虑 Ollama、LM Studio、llama.cpp、Atomic Chat 等本地模型入口。但本地模型的 tool calling 能力和上下文能力要单独验证。

/connect 更适合管理凭据。你在 TUI 中选择 provider、粘贴 key，然后用 /models 看可用模型。

opencode.json 更适合管理项目级偏好。比如指定默认模型、自定义 provider baseURL、设置 provider options 或模型 alias。

新手不要把 API key 写进 opencode.json。配置文件会进仓库、会被复制、会被发给别人；凭据应该留在本机 auth store 或环境变量里。

多数人不需要改 baseURL。只有这些情况才需要：

baseURL 改错时，常见表现是模型列表为空、认证失败、请求 404、工具调用异常。排查时先回到官方默认 provider，确认 OpenCode 本身没问题，再改自定义 endpoint。

第一步，用 /connect 接入一个 provider。

第二步，用 /models 选择官方推荐或你明确知道能力边界的模型。

第三步，跑一个只读任务：让 OpenCode 总结当前项目结构。

第四步，跑一个小改动任务：修改一个无风险文件并查看 diff。

第五步，如果需要，再把 provider 选择写进项目配置，避免团队成员各用各的模型。

你能说清当前默认 provider 和默认 model 是什么。

你能确认 key 没有出现在 opencode.json、git diff、日志和截图里。

你能通过 /models 看到可用模型，并能解释为什么选这个模型。

你能让模型完成一次读代码、一次改文件、一次工具调用。

你能在 provider 出错时区分是凭据问题、模型权限问题、baseURL 问题、网络问题，还是模型能力问题。