06 · 模型与供应商策略

OpenCode 的一个核心优势是模型可换。这个优势只有在你建立模型策略后才有意义；如果每次只是选“听起来最强”的模型，成本、速度和稳定性都会失控。

先按任务分层

不要用同一个模型处理所有任务。更合理的是按任务风险分层：

L1 低风险任务
    文档整理、简单解释、命名建议、README 修改

L2 中风险任务
    小 bug 修复、局部重构、测试补充、配置调整

L3 高风险任务
    架构改动、跨模块迁移、安全相关、发布部署、数据处理

L1 任务可以优先考虑速度和成本。L3 任务优先考虑推理质量、工具调用稳定性和可解释性。

Provider 不是只看模型名

同一个模型在不同 provider 上的效果可能不同。差异通常来自：

• 上下文长度。
• 工具调用格式。
• 限流和并发。
• 价格。
• 响应延迟。
• 是否支持缓存或流式输出。
• 是否对 coding agent 场景做过适配。

OpenCode Zen 的定位就是提供一组经过 OpenCode 团队测试的模型和供应商组合。它不是必须使用，但适合不想自己踩 provider 差异的人。

默认模型怎么设

默认模型不要设成最贵模型。默认模型应该是你最常用、稳定、成本可接受的模型。

更好的做法是：

默认模型      日常解释、轻量编辑、文档任务
高推理模型    跨文件 bug、架构判断、复杂重构
快速模型      搜索、分类、格式整理、简单批处理
备用模型      主 provider 限流或异常时切换

在 OpenCode 中，可以通过配置和命令显式选择模型，也可以在 TUI 中切换。

Agent 与模型绑定

某些 agent 可以绑定更合适的模型。例如：

• docs agent 使用便宜快速模型。
• review agent 使用更强的推理模型。
• test agent 使用工具调用稳定的模型。
• planner agent 使用上下文能力更强的模型。

这样做比每次手动切模型更稳。

什么时候不要切模型

模型切换不是越多越好。下面几种情况不建议频繁切：

• 任务已经进行到一半，上下文和判断链很长。
• 当前模型已经理解了项目约束。
• 任务依赖之前的工具输出和修复假设。
• 你只是因为输出慢而焦虑。

长任务中途切模型，可能会丢掉隐含上下文和判断风格。更稳的做法是先让当前模型产出状态摘要，再切换。

实用策略

一个可执行的起点：

普通阅读和文档：快速模型
局部代码编辑：默认 coding 模型
跨模块问题：高推理模型
安全/发布/数据：高推理模型 + 人工确认
批量重复任务：低成本模型 + 明确命令模板

OpenCode 的多模型能力不是为了炫技，而是让不同任务使用不同成本结构。