---
title: "06 · 模型與供應商策略"
description: "在 OpenCode 中按任務風險、成本、速度和資料邊界選擇 provider、model、variant 與預設模型。"
verifiedAt: "2026-05-09"
---

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

> [!NOTE]
> **這一篇用 12 分鐘換什麼**：你會知道 provider、model、credential 怎麼分層，第一次只該接幾個 provider，預設模型為什麼不要選最貴的，什麼時候用高推理 variant，以及團隊長期使用時怎麼降低排障成本。

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

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

```mermaid
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。

| 層級 | 負責什麼 | 常見入口 |
| --- | --- | --- |
| Provider | 模型從哪裡來，例如 OpenAI、Anthropic、Zen、OpenRouter、本地模型或企業閘道器 | `/connect`、`provider` 配置 |
| Model | 具體用哪個模型，是否使用 variant | `/models`、`model`、`--model` |
| Credential | 怎麼證明你有許可權呼叫它 | `/connect`、環境變數、本機 auth store |

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

> [!WARNING]
> 憑據洩露不是“以後再修”的問題。只要 key 出現在配置、diff、CI 日誌、分享會話或教學截圖裡，就應該立即輪換。

## 2. 第一次只接一個 provider

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

```text
/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，模型要在真實專案裡驗證。

| 維度 | 要驗證什麼 |
| --- | --- |
| 程式碼能力 | 能不能讀懂專案結構、寫出可執行改動 |
| 工具呼叫 | 能不能穩定呼叫檔案、shell、MCP、LSP 等工具 |
| 上下文能力 | 能不能處理多檔案、多輪任務和長輸出 |
| 延遲和限流 | 會不會頻繁卡住、超時、被 rate limit |
| 成本 | 能不能支撐日常高頻使用 |

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

> [!IMPORTANT]
> 模型名、價格、上下文、免費期和可用性變化很快。寫配置前用 `/models` 和 Models.dev 複核，不要從舊教程複製模型 ID。

## 4. 按任務風險分層

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

| 層級 | 任務 | 模型策略 |
| --- | --- | --- |
| L1 低風險 | 文件整理、摘要、命名建議、簡單解釋 | 快速低成本模型 |
| L2 中風險 | 小 bug、區域性重構、測試補充、配置調整 | 穩定 coding 主力模型 |
| L3 高風險 | 架構遷移、安全、資料、釋出、跨模組改動 | 高推理模型 + 人工確認 |
| L4 批處理 | 批次分類、格式修正、生成報告 | 低成本模型 + command 模板 |

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

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

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

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

```jsonc title="opencode.json"
{
  "$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 通常是：

```text
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。
- 你只是因为输出慢而临时焦虑。

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

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

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

## 9. Provider 出錯先按層級排

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

| 現象 | 優先檢查 |
| --- | --- |
| `/models` 看不到模型 | `/connect` 是否成功、key 是否有效、provider 是否可用 |
| 認證失敗 | API key、企業許可權、環境變數、auth store |
| 請求 404 | `baseURL`、provider ID、model ID |
| 頻繁超時 | provider 網路、限流、`timeout` / `chunkTimeout` |
| 能聊天但不會改程式碼 | 工具呼叫能力、模型是否適合 coding agent |
| 本地模型失敗 | OpenAI-compatible endpoint、上下文和 tool calling 支援 |

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

## 10. 一個可執行起點

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

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

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

## 接下來去哪

<Cards>
  <Card title="選擇模型" description="確認 `/models`、`provider_id/model_id`、variant 和預設模型的官方配置邊界。" href="/zh-Hant/docs/opencode/official/03-models/models" />
  <Card title="配置模型供應商" description="理解 provider、credential、baseURL、本地模型和自定義 endpoint 的分工。" href="/zh-Hant/docs/opencode/official/03-models/providers" />
  <Card title="OpenCode Zen" description="判斷是否使用官方精選模型入口，以及如何核對價格、隱私和團隊限額。" href="/zh-Hant/docs/opencode/official/08-platform/zen" />
  <Card title="Agents、Skills、Plugins" description="當模型策略需要落到角色和許可權時，繼續看 agent 分工。" href="/zh-Hant/docs/opencode/understanding/05-agents-skills-plugins" />
</Cards>

## 官方資料

- OpenCode Models：[https://opencode.ai/docs/models](https://opencode.ai/docs/models)
- OpenCode Providers：[https://opencode.ai/docs/providers](https://opencode.ai/docs/providers)
- OpenCode Zen：[https://opencode.ai/docs/zen](https://opencode.ai/docs/zen)
- Models.dev：[https://models.dev](https://models.dev)
