模型: openai/gpt-5.4 生成日期: 2026-04-01 书名: Claude Code VS OpenCode：架构、设计与未来 章节: 第6章 — LLM提供者抽象 Token消耗: 当前运行环境未暴露精确统计值，无法精确填报

6.1 多模型支持架构

LLM提供者抽象，本质上是在“模型世界的碎片化现实”和“工程系统想要稳定接口”之间搭桥。这里的“提供者抽象”不是传统教材中的标准术语，可以把它理解成一层“翻译兼配电中枢”：上游接不同云厂商、不同认证方式、不同参数命名；下游向会话循环、工具系统、流式输出暴露尽量一致的调用面。没有这层，编码智能体会被每家模型厂商的接口细节撕裂。

OpenCode在这一章里最有代表性的设计，是基于 Vercel AI SDK 来统一多家模型。Vercel AI SDK也不是标准CS教材里的经典概念，它更像一个“多厂商LLM适配总线”：在TypeScript里，把 Anthropic、OpenAI、Google、Bedrock、Vertex、Groq、Mistral、OpenRouter、GitHub Copilot 等二十多个提供者包装成相似的模型对象与流式接口。OpenCode 的 provider.ts 直接导入一长串 createXxx 工厂，再结合 models.dev 获取提供者和模型元数据，因此它天然偏向“模型无关”架构：应用层只要描述“我要哪个 provider/model”，而不是为每家SDK单独写分支。这种方式的好处是可移植、可扩展、便于社区接入；代价是最低公分母问题突出，很多厂商特性只能通过附加映射去保留。

Claude Code的取向则更偏“模型专用优化”。从 src/utils/model/providers.ts、model.ts、configs.ts 可以看到，它的主路径明显围绕 Anthropic 第一方接口展开；当环境变量打开时，再切到 Bedrock、Vertex、Foundry 等第三方承载层。也就是说，它不是先追求“任何模型都能平权接入”，而是先确保 Claude 家族在默认路径上获得最好体验，再为企业环境提供落地后备。这种设计更像“主航道+分流渠”：主航道深挖 Anthropic 能力，分流渠解决合规、区域部署和企业采购问题。

OMO 的贡献不在底层SDK统一，而在“语义层选模”。category-resolver.ts 与 model-requirements.ts 显示，它把任务先分到 visual-engineering、ultrabrain、quick、writing 等语义类别，再为每类配置最佳模型与回退链。例如 visual-engineering 默认优先 Gemini 3 Pro，因为系统作者认为它更适合前端、设计、视觉任务。这里出现了另一种抽象：不是“用户自己挑模型”，而是“系统按任务语义挑模型”。这使智能体更像一位技术经理，而不是单纯的API调用器。

因此，三者构成了三种层次：OpenCode 解决“怎么统一接多家模型”，Claude Code 解决“怎么把一家模型用到极致并兼容企业后备”，OMO 解决“什么任务该让什么模型上场”。

这背后对应一个长期张力：模型无关 vs 模型专用。模型无关强调 portability，像插头标准化，换电器方便；模型专用强调 optimization，像为特定发动机单独调校。前者适合开源生态、插件生态、快速扩容；后者适合深度利用 reasoning、长上下文、流式工具调用、专有安全能力。理想设计通常不是二选一，而是分层：底层保持统一调用协议，中层做能力探测与参数映射，上层允许语义路由与模型特化。真正优秀的 Agent，不应只会“接很多模型”，也不应只会“绑死一个模型”，而应在统一骨架上，保留对顶级模型特性的定向利用能力。