06 · 模型與供應商策略

OpenCode 支援切換 provider 和 model，但“可切換”不是讓你每天追最新模型。真正穩定的策略，是把任務風險、模型能力、呼叫成本、資料邊界和團隊預設值放在一起判斷。

先給結論：先有主力模型，再擴充套件備選

預設模型應該是穩定、成本可接受、能完成真實 coding agent 任務的主力模型。高風險任務再切高推理模型；輕量任務交給 small_model 或低成本模型；provider 數量先少後多，否則排障會變成猜供應商、猜網路、猜憑據、猜模型能力。

flowchart LR
  Task["任務型別"] --> Risk["判斷風險"]
  Risk --> Provider["選擇 provider"]
  Provider --> Model["選擇 model"]
  Model --> Variant["需要時切 variant"]
  Variant --> Verify["只讀 / 小改 / 測試驗證"]
  Verify --> Default["穩定後再寫預設配置"]

  style Risk fill:#fef3c7,stroke:#f59e0b
  style Verify fill:#dcfce7,stroke:#22c55e,stroke-width:2px
  style Default fill:#dbeafe,stroke:#3b82f6

如果一個模型只能聊天，不能穩定讀檔案、改檔案、呼叫 shell、處理長上下文和解釋 diff，它就不適合作為 OpenCode 的主力 coding 模型。

1. 先分清三層

OpenCode 裡最容易混的是 provider、model 和 credential。

/connect 更適合儲存本機憑據，專案級 opencode.json 更適合寫預設模型、provider options 和團隊偏好。真實 API key 不應該進儲存庫、截圖、日誌或教程示例。

2. 第一次只接一個 provider

新手最常見的錯誤，是同時接入多個 provider，然後不知道故障來自哪一層。第一次用 OpenCode，先跑通一條最短閉環：

/connect
  ↓
选择 provider 并完成认证
  ↓
/models
  ↓
选择一个 coding 主力模型
  ↓
只读解释项目结构
  ↓
低风险单文件改动

provider 選擇可以這樣判斷：

• 新手快速跑通：OpenCode Zen 或你已有賬號的主流 provider。
• 統一賬單 / 國內網路：聚合 provider 或團隊內部 gateway。
• 企業許可權 / 合規：Bedrock、Azure、Vertex 或內部 AI gateway。
• 隱私 / 離線實驗：Ollama、LM Studio、llama.cpp 等本地入口。
• 團隊統一體驗：同一 provider + 專案級預設模型。

OpenCode Zen 是官方提供的可選 provider，用來降低模型組合試錯成本。它不是使用 OpenCode 的前提；如果你已經有穩定 provider，可以繼續用自己的 key。

3. 模型先過五項驗證

不要只看模型排行榜。OpenCode 是工具驅動的 coding agent，模型要在真實專案裡驗證。

官方 Models 頁會給推薦模型，但這類列表會隨時間變化。更穩的做法是保留自己的驗證閉環：只讀解釋專案結構、定位一個小 bug、改一個低風險檔案、執行測試或給出可驗證結果，再 review diff。

4. 按任務風險分層

不要用同一個模型處理所有任務。更合理的是按風險和成本分層：

模型越強，不代表越適合所有任務。小 README 修改交給最高推理模型通常只是浪費；跨模組遷移交給便宜小模型，風險會轉移到後續排錯上。

5. 預設模型不要設成最貴模型

預設模型應該是你最常用、最穩定、成本可接受的 coding 主力。它不是賬號裡最貴的模型。

專案配置可以這樣表達分工：

{
  "$schema": "https://opencode.ai/config.json",
  // provider-id/model-id 的實際值用 `/models` 命令列出，或參 https://opencode.ai/docs/models
  "model": "provider-id/main-coding-model",
  "small_model": "provider-id/lightweight-model"
}

model 是主力模型。small_model 用于标题生成等轻量任务；如果没有单独配置，OpenCode 会尝试使用 provider 里的便宜模型，否则回退到主模型。

个人偏好更适合放全局配置。只有当团队确实需要同一默认模型时，才把 model 写进项目级配置。

6. 模型 ID 和加载优先级

OpenCode 的模型 ID 通常是：

provider_id/model_id

排错时先看两件事：provider 是否已经连接并有权限，model ID 是否存在且被当前 provider 支持。

OpenCode 启动时按这个顺序找模型：命令行 --model / -m 优先，其次是 OpenCode config 里的 model，再其次是上次使用的模型，最后才是 OpenCode 内部优先级选出的第一个模型。

这能解释一个常见困惑：你明明改了配置，但当前命令行参数或会话状态仍然覆盖了它。

7. Variant 和 agent 绑定只在必要时用

Variant 是同一模型的不同配置形态，例如更高 reasoning、更低 verbosity 或更大 thinking budget。

适合切 variant 的场景：

• 快速解释、小修小补：低 reasoning / fast。
• 复杂 review、迁移、架构判断：高 reasoning。
• 少数高价值任务：更高预算或最大 thinking。

Agent 也可以绑定模型。比如 docs 用低成本稳定模型，review 用推理强的模型，security 用高推理且权限收紧的模型。这个能力适合角色差异明确的团队，不适合为了“看起来专业”给每个 agent 都配不同模型。

8. 不要在长任务中途随便切模型

这些情况不建议中途切模型：

• 当前模型已经读了很多上下文。
• 任务依赖前面的工具输出和修复假设。
• 工作区已经产生未提交 diff。
• 你只是因为输出慢而临时焦虑。

确实要切时，先让当前模型写交接摘要：

請輸出一份交接摘要：
1. 當前任務目標。
2. 已閱讀和修改的檔案。
3. 已驗證的事實。
4. 尚未完成的步驟。
5. 需要避免誤改的邊界。

新模型接手時，從摘要和當前 diff 開始，不要讓它靠猜繼續。

9. Provider 出錯先按層級排

Provider 出問題時，不要一上來換模型。

先回到官方預設 provider 或一個已知可用模型，確認 OpenCode 本身沒問題，再排自定義 endpoint、代理、企業閘道器和本地模型。

10. 一個可執行起點

如果你不知道怎麼開始，先用這套策略：

• 普通閱讀和文件：快速低成本模型。
• 區域性程式碼編輯：穩定 coding 主力模型。
• 跨模組 bug 和重構：高推理模型。
• 安全、釋出、資料：高推理模型 + 人工確認。
• 批次重複任務：低成本模型 + command 模板。
• 標題和摘要：small_model。

這套策略的目標不是永遠最省錢，也不是永遠最強，而是讓任務風險、模型能力和成本結構匹配。

接下來去哪

官方資料

• OpenCode Models：https://opencode.ai/docs/models
• OpenCode Providers：https://opencode.ai/docs/providers
• OpenCode Zen：https://opencode.ai/docs/zen
• Models.dev：https://models.dev