Lazy loaded image
Agent
Agent丨在项目中如何进行 LLM 模型选择：统一一家、多模型切换，还是自研模型？
字数 6540阅读时长≈ 17 分钟
2026-5-6
type
Post
status
Published
date
May 6, 2026
slug
agent31
summary
tags
Agent
category
icon
password
结论先说：生产级 LLM / RAG / Agent 项目，不应该把“模型选择”写死成某一个模型名，而应该设计成“模型能力路由系统”。
早期 MVP 可以统一使用一家模型；一旦进入真实业务，就要支持多模型切换、fallback、灰度评测、成本治理和私有模型接入。自研或自托管模型通常不是第一步，而是当数据合规、成本规模、稳定任务蒸馏收益足够明确时，作为统一模型网关下的一个 Provider 接入。

1. 为什么模型选择不是简单的“选 GPT 还是 Claude”

在 LLM 项目里，模型选择至少涉及 8 个维度：
  1. 能力：推理、代码、工具调用、结构化输出、长上下文、视觉、多语言。
  1. 稳定性：限流、超时、服务可用性、返回格式稳定性。
  1. 成本：输入 token、输出 token、缓存、长上下文成本。
  1. 延迟：首 token 延迟、完整响应延迟、并发吞吐。
  1. 上下文窗口：RAG 长文档、Agent 历史轨迹、代码仓库上下文。
  1. 工具调用可靠性：Function Calling / Tool Use 是否稳定。
  1. 合规与数据边界：数据是否能出域，是否必须走企业网关或私有化。
  1. 可观测性：是否能记录 token、成本、fallback、错误类型、评测指标。
OpenAI 的官方模型选择文档也强调：先达到准确率目标，再在保持准确率的前提下优化成本和延迟；并建议建立评测数据集来衡量模型表现。(OpenAI开发者) Anthropic 的模型选择文档同样把能力、速度、成本列为核心权衡项。(Claude Platform)
所以项目里的模型选择，本质上不是：
“我们用哪个模型？”
而是：
“不同任务、不同风险、不同成本约束下，如何自动选择合适模型，并能在失败时安全切换？”

2. 调研：成熟项目是怎么做模型选择的？

2.1 Claude Code：同一家模型族内的“能力别名 + 场景切换”

Claude Code 的模型配置不是只暴露一个固定模型，而是支持模型别名和完整模型名。官方文档中，sonnet、opus、haiku 分别对应不同能力档位，opusplan 还会在 Plan Mode 使用 Opus，在执行阶段切到 Sonnet。(Claude Code)
它还支持多种设置优先级：会话内 /model、启动参数 --model、环境变量 ANTHROPIC_MODEL、配置文件中的 model 字段。(Claude Code) 这说明 Claude Code 的设计重点不是“让业务代码直接依赖某个模型 ID”，而是通过别名和优先级体系，把模型选择变成可配置策略。
可以抽象成下面的模型选择层级：
工程启发：
Claude Code 更像是“单模型厂商优先”的模式，但它没有把模型固定死，而是通过 alias、session override、环境变量、settings、gateway discovery 等机制保留了切换能力。

2.2 OpenCode：多 Provider、多模型、本地模型、small_model

OpenCode 的公开文档显示，它使用 AI SDK 和 Models.dev 支持 75+ LLM Provider，并支持本地模型。(OpenCode) 它的模型引用采用 provider_id/model_id 格式，例如 anthropic/claude-sonnet-4-20250514，并支持通过 /models 选择模型。(OpenCode)
OpenCode 还有一个很有工程价值的设计：small_model。配置里可以同时设置主模型和轻量模型：
small_model 用于标题生成等轻量任务；如果可用，OpenCode 会尽量使用更便宜的模型，否则回退到主模型。(OpenCode)
OpenCode 还支持按 Agent 配置模型，例如 code-reviewer Agent 可以使用指定模型，并禁用写文件工具。(OpenCode) 这说明成熟 Agent 项目通常不是“全局一个模型”，而是：
主 Agent 一个模型，轻量任务一个小模型，特殊 Agent 可以单独绑定模型。
OpenCode 的官方仓库 README 还明确把 LLM 核心设计为“provider-neutral”，即调用侧使用统一 request / response / event / tool schema，Provider 差异放到 adapter 里。(GitHub) 这正是生产项目应该学习的地方。

2.3 OpenClaw：provider/model 引用、fallback、auth rotation、严格用户选择

OpenClaw 的公开文档把模型引用定义为 provider/model，例如 openai/gpt-5.5、moonshot/kimi-k2.6、ollama/llama3.3。它支持内置 Provider，也支持通过 models.providers 添加自定义 Provider 或 OpenAI / Anthropic 兼容代理。(GitHub)
OpenClaw 的模型失败处理很值得参考。它把失败处理分成两层：
  1. 当前 Provider 内部的认证 profile 轮换。
  1. 如果 Provider 失败，再切到 agents.defaults.model.fallbacks 中的下一个模型。(OpenClaw)
它的模型 failover 流程大致如下：
更关键的是，OpenClaw 区分了模型选择来源：
  • 配置默认模型可以使用 fallback。
  • Agent primary 如果没有显式 fallbacks，则严格失败。
  • 用户通过 /model 手动选择的模型是精确选择，失败时不应悄悄切到无关 fallback。
  • 自动 fallback 会写入 session override，并在主模型恢复后清理。(OpenClaw)
这点非常重要：
自动 fallback 不能破坏用户意图。用户显式选了某个模型，系统不应该偷偷换模型，除非用户或配置明确允许。

2.4 LangChain / LlamaIndex：模型抽象层

LangChain 的文档明确说，标准模型接口可以访问多个 Provider 集成，使实验和切换模型更容易；模型是 Agent 决策的推理引擎，模型能力会直接影响 Agent 的可靠性和性能。(LangChain 文档)
LlamaIndex 也把 LLM 作为可插拔抽象，可以在 indexes、retrievers、query engines、agents 中替换底层 LLM；它还支持全局默认 LLM 和局部 query_engine override。(Developer Documentation)
这说明 RAG 框架的主流做法是：
不把 LLM 写死在业务流程里，而是通过统一接口注入。

2.5 LiteLLM：统一网关、路由、负载均衡、fallback

LiteLLM 的 Router 支持多个部署的路由策略，包括 weighted pick、rate-limit aware、latency-based、least-busy、cost-based 等。官方文档也建议生产中使用默认的 simple-shuffle 以减少性能开销。(LiteLLM)
LiteLLM 还支持 fallback，例如一个模型调用失败后，按顺序 fallback 到另一个模型组。(LiteLLM)
这类网关思想非常适合企业级 LLM 项目：

2.6 自托管模型：vLLM / Ollama / SGLang

如果要接入自研或开源模型，最好不要让业务代码直接适配一套新 API，而是把它包装成 OpenAI-compatible endpoint。
vLLM 官方文档说明，它可以作为实现 OpenAI API 协议的 server 部署，从而作为使用 OpenAI API 应用的 drop-in replacement。(vLLM) Ollama 也提供 OpenAI compatibility，支持 OpenAI Responses API 的部分非状态化能力。(Ollama 文档)
这意味着自研模型在工程里最好被视为：
一个新的 Provider，而不是一套新的业务调用方式。

3. 项目中推荐的模型选择策略

3.1 不推荐：业务代码直接写死某家模型

例如：
这种写法在 Demo 阶段没问题，但生产中有明显缺陷：
  • 模型退役或升级时，要改业务代码。
  • 无法按任务选择模型。
  • 无法做 fallback。
  • 无法统一成本统计。
  • 无法接私有模型。
  • 无法在合规场景切到企业网关。
  • 无法做灰度和 A/B test。
更好的做法是让业务只关心逻辑模型名：
至于 agent.coding.primary 最终路由到 Claude、GPT、Gemini、Kimi、vLLM 还是 Ollama，由模型注册表和路由策略决定。

4. 推荐架构：模型注册表 + 能力路由 + 统一网关

核心组件：
模块
作用
Model Registry
记录模型能力、上下文长度、价格、延迟、支持工具调用与否
Policy Engine
根据业务风险、数据合规、租户策略过滤模型
Model Selector
根据任务类型、上下文长度、评测分、成本、延迟选择模型
LLM Gateway
屏蔽 Provider 差异，统一鉴权、限流、重试、fallback
Eval System
记录每个任务在不同模型上的质量、成本、延迟
Observability
监控 token、p95 latency、错误、fallback、JSON 成功率、工具调用成功率

5. 一套可落地的模型配置设计

下面是一份推荐配置。它综合了 Claude Code 的 alias 思路、OpenCode 的 provider/model 和 small_model 思路、OpenClaw 的 fallback 思路，以及 LiteLLM 的网关路由思想。
设计要点：
  • 业务只使用 logical model，不直接依赖真实模型 ID。
  • Provider 可以换，业务代码不变。
  • 同一任务有 primary 和 fallbacks。
  • 轻量任务使用 small model，降低成本。
  • 敏感数据走 private model。
  • 用户显式选择模型时默认 strict，避免偷偷 fallback 到其他模型。

6. 模型能力注册表：不要只存模型名

一个生产系统里的模型注册表至少应该长这样：
不要只记录：
因为模型选择真正依赖的是：
当前任务需要什么能力，这个模型是否具备，成本和延迟是否可接受，当前是否健康。

7. 模型路由器源码示例

下面是一段 TypeScript 伪源码，展示生产中如何选择模型。重点不是语法，而是策略结构。
这段代码体现了几个关键原则：
  1. 用户手动选模型时，默认严格执行。
  1. 系统自动选模型时，可以 fallback。
  1. 先做能力过滤，再做成本和延迟优化。
  1. 低风险任务可以用小模型。
  1. 高风险任务优先质量。
  1. 私有数据不能路由到不合规 Provider。
  1. 模型是否健康是动态状态，不是静态配置。

8. RAG 项目中的模型选择

RAG 里不要所有步骤都用同一个大模型。一个典型 RAG 流程可以拆成：
推荐模型分配：
RAG 阶段
推荐模型策略
原因
Query Rewrite
小模型
输入短、任务稳定、成本敏感
Query Decomposition
中等模型
需要一定推理，但不需要最强模型
Context Compression
小模型 + 规则
目标是压缩，不是创造
Final Answer
强模型
影响最终质量和幻觉率
Citation Check
中等模型 / 规则
检查答案是否被证据支持
Long-context fallback
长上下文模型
检索结果过长时使用
示例代码：
RAG 模型选择的核心不是“哪个模型最聪明”，而是：
每个阶段用刚好够用的模型，把最强模型留给最终高价值输出。

9. Agent 项目中的模型选择

Agent 比 RAG 更依赖模型的工具调用、规划能力、长上下文能力和错误恢复能力。
一个 Coding Agent 可以这样分层：
Agent 子任务
推荐模型
需求理解 / 计划
强推理模型
搜索代码 / 总结文件
小模型或中等模型
修改核心代码
代码能力强、工具调用稳定的模型
Review / 安全检查
强模型或专用 reviewer 模型
标题生成 / commit message
小模型
长任务 fallback
长上下文模型
本地敏感代码
企业网关或私有模型
OpenCode 内置 build / plan 两类 Agent，plan 是只读分析，build 是开发执行；这说明成熟 Coding Agent 通常会把“计划”和“执行”分开。(GitHub) Claude Code 的 opusplan 也体现了类似思想：规划阶段用更强模型，执行阶段切到日常编码模型。(Claude Code)
Agent 模型选择架构：

10. 什么时候统一使用某家模型？

可以统一使用某家模型的场景：
  1. MVP 阶段：先验证业务闭环。
  1. 团队经验不足：先减少 Provider 差异。
  1. 合规已经绑定某家云：例如只能用 Azure OpenAI 或 Bedrock。
  1. 任务单一：例如只做客服分类、摘要、简单问答。
  1. 预算不是主要矛盾：质量优先，成本可接受。
但即使统一使用某家模型，也建议保留抽象层：
背后可以暂时只配置一个 Provider，但未来能平滑扩展。
也就是说：
可以暂时只用一家模型，但不要让业务代码知道你只用一家。

11. 什么时候必须支持多模型切换？

以下情况建议一开始就设计多模型能力：
  1. 有 RAG + Agent 多种任务。
  1. 有高并发和成本压力。
  1. 有国内外多区域部署。
  1. 有不同租户、不同数据合规要求。
  1. 有长上下文、视觉、结构化输出、工具调用等多能力组合。
  1. 对稳定性要求高，不能因为单 Provider 限流导致业务不可用。
  1. 需要对模型持续评测、灰度升级、回滚。
成熟项目的共同趋势也是多模型抽象。OpenCode 支持 75+ Provider 和本地模型，企业版还可以通过集中配置和内部 AI Gateway 限制所有请求走组织批准的基础设施。(OpenCode) OpenClaw 则进一步把 fallback、auth rotation、cooldown、用户可见 fallback notice 纳入运行时策略。(OpenClaw)

12. 什么时候考虑自研模型或自托管模型？

自研或自托管模型适合这些场景：
场景
是否适合自研 / 自托管
数据不能出内网
适合
每天调用量巨大，成本压不住
适合
任务高度稳定，可蒸馏
适合
需要领域术语和内部知识
可以考虑微调
需要最强通用推理
不一定适合
团队没有模型工程能力
不建议一开始做
只是为了“看起来技术先进”
不建议
推荐路径：
vLLM、Ollama 这类系统支持 OpenAI-compatible API，因此可以作为统一网关下的一个 Provider 接入，而不是改造业务代码。(vLLM)

13. 生产级模型选择的评测体系

模型选择不能靠感觉，必须有评测集。

13.1 离线评测指标

任务
指标
RAG 问答
Faithfulness、引用准确率、答案完整性、拒答准确率
Query Rewrite
Recall@k 提升、无关扩展率
JSON 抽取
JSON parse success、字段准确率
Agent 工具调用
Tool call success、参数正确率、任务完成率
Coding Agent
测试通过率、diff 正确率、回归 bug 数
总结
事实一致性、压缩率
多语言
语言保持率、术语一致性
安全
越权调用率、敏感信息泄露率

13.2 线上指标

指标
说明
p50 / p95 latency
用户体验
cost per successful task
成本效率
fallback rate
主模型稳定性
retry rate
Provider 质量
context overflow rate
上下文策略是否合理
tool call failure rate
Agent 模型是否适合
structured output failure rate
JSON / schema 能力
hallucination report rate
RAG 质量
user override rate
默认模型是否满足用户预期

13.3 灰度流程

14. 最佳实践：不要“切模型”，要“切策略”

很多团队的问题是：
“我们要不要从 Claude 切到 GPT？”
更成熟的问题应该是：
“哪些任务应该从 Claude 切到 GPT？哪些任务应该继续用 Claude？哪些任务可以用小模型？哪些任务必须走私有模型？失败时怎么 fallback？如何评估切换收益？”
推荐策略如下：
项目阶段
模型策略
Demo / PoC
单 Provider + 单强模型
MVP
单 Provider + strong / small 两档
早期生产
多模型配置 + 手动切换 + 评测
稳定生产
统一 Gateway + 自动路由 + fallback
企业级
内部 AI Gateway + 权限/成本/审计
高规模
商业模型 + 自托管模型混合
高合规
私有模型优先，商业模型只处理脱敏任务

15. 最终推荐方案

我的推荐是：
默认采用“多模型切换 + 统一 LLM Gateway + 能力路由”的方案。
不建议业务层统一写死某家模型；也不建议一开始就自研模型。最稳妥的路径是先用商业强模型建立质量上限，再用评测集、日志和成本数据逐步引入小模型、私有模型、自托管模型。

推荐架构一句话总结

最终落地原则

  1. 业务代码只调用逻辑模型名，不写真实模型 ID。
  1. 所有模型都进入 Model Registry，记录能力、价格、延迟、评测分。
  1. 简单任务用小模型，高风险任务用强模型。
  1. RAG 最终回答优先质量，Query Rewrite / Summary 优先成本。
  1. Agent 的计划、执行、Review、标题生成应拆模型。
  1. 用户显式选择模型时默认 strict，不偷偷 fallback。
  1. 系统默认模型可以配置 fallback。
  1. fallback 必须可观测，最好给用户或运维侧明确提示。
  1. 私有模型通过 OpenAI-compatible API 接入统一网关。
  1. 模型升级必须经过离线评测、Shadow、灰度、回滚。

16. 面试式回答

如果面试官问：
“你们项目中是如何进行 LLM 模型选择的？是支持多模型切换、统一使用某家模型，还是自研模型？”
可以这样回答：
我们不会把模型直接写死在业务代码里，而是做了一层统一的模型路由。早期 PoC 可以先使用一家主流模型保证质量，但生产环境会抽象出 logical model，例如 rag.answer.primary、agent.plan.primary、system.small。
路由层会根据任务类型、上下文长度、是否需要工具调用、是否需要结构化输出、数据合规等级、成本和延迟目标来选择模型。主链路有 primary 和 fallback，小任务会走 small model，高风险任务走强模型，敏感数据走私有化或企业网关。
我们参考了 Claude Code 的模型别名和 plan/execution 分层、OpenCode 的 provider/model 与 small_model 设计、OpenClaw 的 fallback 和 auth rotation 机制，以及 LiteLLM 这类统一网关的路由思想。
自研模型不是一开始就做，而是在业务稳定后，用线上日志和评测集找到高频、稳定、成本敏感的任务，再考虑微调、蒸馏或通过 vLLM / Ollama 接入私有模型。这样既能保证早期效果，也能在生产阶段控制成本、稳定性和合规风险。
回到首页
目录