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

6.2 模型能力检测

如果说提供者抽象解决的是“能不能连上模型”，那么模型能力检测解决的就是“连上以后，究竟能安全地让它做什么”。这可以视为一种运行时能力协商：系统在真正发请求前，先判断当前模型支持哪些输入模态、哪些采样参数、是否有推理模式、上下文窗口有多大、工具调用是否稳定。它像机场塔台分配跑道——不是所有飞机都能在同一条跑道上、用同一套程序起降。

OpenCode在这方面做得相当系统。models.ts 从 models.dev 读取模型元数据，字段里直接包含 reasoning、temperature、tool_call、modalities、limit.context、limit.output 等信息；transform.ts 再把这些能力落实到消息归一化与参数转换上。比如，若模型不支持图片或 PDF 输入，系统不会盲目发送二进制内容，而会把它改写成错误提示文本；若模型是 Anthropic、Mistral 或 Copilot，还会针对消息格式、toolCallId、reasoning 字段做专门变换。这说明“能力检测”并不是一个布尔判断，而是“元数据 + 转换器 + 防错规则”的组合体。

Claude Code则采取“专属模型知识 + 动态刷新”的策略。modelCapabilities.ts 会从 Anthropic 的模型列表拉取 max_input_tokens、max_tokens 并缓存到本地；model.ts、configs.ts、providers.ts 再结合 first-party、Bedrock、Vertex 的差异，决定默认模型、1M 上下文、不同提供者下的 canonical model id。这里的重点不是支持尽可能多的外部模型，而是精确理解 Claude 家族在不同承载环境中的行为差别。比如同样是 Sonnet，新版在第一方可能已是默认，但在第三方云上可能尚未完全可用，于是默认策略必须回退到较早稳定版本。

参数协商是这一节最容易被低估的部分。温度（temperature）可以理解为“输出随机度旋钮”；TopP 则像“只从概率最高的一小团候选词里抽样”；MaxTokens 则是“本轮回答可用的最大字数预算”。这些概念在教材里常见，但一旦落到多提供者场景，就会出现命名、默认值、支持范围都不一致的问题。有的模型支持 temperature 但不支持 top_p；有的支持 reasoning effort，但以 reasoning_details、reasoning_content 或别的私有字段表达；有的模型虽能接收参数，却会静默忽略。于是 Agent 侧必须做“提供者特定参数转换”，把上层统一意图翻译成下层可接受格式。

OMO 把能力检测继续向上推了一层：它不仅问“模型能不能做”，还问“这个任务值不值得让该模型做”。visual-engineering 走 Gemini，deep 偏向 GPT-5.3-codex，quick 则选 Claude Haiku，本质上是一种“任务-能力匹配表”。这种语义级协商能减少用户手工调参负担，但前提是底层已经有稳定的模型元信息和回退链。

上下文窗口差异也必须被严肃对待。上下文窗口可以衍生解释为“模型当前短期记忆的容量上限”；不同模型从几十K到一百万token不等，超限后要么报错，要么截断，要么触发压缩。Agent 设计里，窗口大小不是性能细节，而是架构约束：它决定系统是否需要激进压缩、是否能携带大仓库摘要、是否允许多轮工具输出原样回灌。优秀的提供者抽象，不只是把 API 打平，更要把能力边界显式化，让上层调度器知道哪里能冲，哪里必须收。