模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第10章 — Oh-My-OpenCode的创新
Token用量: 约 4,000 input + 1,050 output
10.2 语义类别系统
OMO 很聪明的一点在于：Category 描述的是任务意图，而不是模型名称。 这件事看似简单，实际上解决了 agent 系统里一个很常见、但经常被忽视的问题——任务语义和后端模型耦合得太死。
在很多系统里，调用方会直接说“这个任务用 GPT-X”“这个任务切到模型 Y”。这种方式短期有效，但长期会带来两个问题：其一，prompt 和工作流里到处塞满具体模型名，导致配置膨胀；其二，任务本质被模型品牌绑架，一旦模型替换、价格变化、可用性波动，整套策略都要重写。OMO 通过 category-resolver.ts、subagent-resolver.ts、categories.ts、model-requirements.ts 等文件引入了一个中间抽象层：先说这是什么类型的工作，再由系统决定背后该落到哪个模型和 fallback chain。
具体映射非常有代表性。visual-engineering 会优先走 Gemini 3 Pro 一类视觉/界面能力强的模型；ultrabrain 倾向 GPT-5.3 Codex 高推理档；quick 偏向 Haiku 4.5 或其他低延迟低成本模型；deep 也围绕 GPT-5.3 Codex，但约束更严格；writing 则偏向 K2P5 以及写作友好型备选。也就是说，类别背后其实编码了一套关于任务结构的理解：什么任务更看重速度，什么任务更看重视觉感知，什么任务更看重深度推理，什么任务更看重语言生成质量。
这种设计的直接好处是解耦。用户和上层 agent 说的是“这是视觉工程任务”“这是快修任务”“这是深度工作”，而不是“请使用某某模型”。底层若要换模型、加 fallback、调 variant，调用接口都不用变。从软件设计的角度看，这就是典型的稳定接口包住不稳定实现。
但 OMO 的论点不止于此。它还试图减少一种可以称为模型自我感知偏差的问题。这个词需要稍作解释。很多大模型在 prompt 中会被赋予强角色叙事，比如“你是最擅长创意的模型”“你是最快的搜索模型”。模型有时会根据这种身份叙事改变风格、信心、解释方式，甚至影响错误模式。也就是说，模型不是单纯在执行能力路由，它还在“相信自己被描述成什么”。OMO 试图减少这种依赖。通过 category 解析器和 resolver 代码，它把更多决策放进系统结构，而不是放进模型的自我想象里。
category-resolver.ts 正体现了这一点。它会检查用户自定义 category、默认 category、可用模型集合、硬性要求、override 优先级、prompt append 片段、unstable-agent 标记等。某些 category 甚至可以要求某个模型必须可用，否则直接报错；另一些则会在缺失首选模型时沿 fallback chain 回退。换言之，category 不是装饰性的 tag，而是一组策略打包。
subagent-resolver.ts 则补充了另一个维度：命名 agent 与语义 category 的区分。比如 Oracle、Explore 这种是“谁来做”的问题，而 quick、deep 这种是“这类任务本质上属于什么”的问题。前者是角色路由，后者是工作语义路由。把这两个维度分开，本身就是一个很成熟的设计。
语义类别还有一个很现实的价值：prompt 可移植性更强。高层编排器可以写出很稳定的策略模板，比如：
- UI 改造一律优先
visual-engineering； - 小而明确的编辑优先
quick； - 文档与说明优先
writing； - 复杂推理型编码优先
ultrabrain或deep。
这样的模板未来依然有效，即便模型生态已经发生了很大变化。因为真正稳定的是任务语义，而不是模型 SKU。
这套设计比“完全自动黑箱路由”和“完全手动指定模型”都更平衡。完全自动的系统往往太魔法化，用户不容易理解为什么它做了某种选择；完全手动的系统则把太多基础设施细节暴露给用户。OMO 的语义类别系统处在两者中间：既保留了用户可理解、可表达的控制面，又保留了底层模型调度的灵活性。
它还有一个经济学层面的意义。所有任务都默认上最强模型，质量也许高，但成本往往不合理；所有任务都默认上最便宜模型，成本低，但失败率会升高。Category 恰好提供了中间道路：低价值或低复杂度任务走轻模型，高价值高复杂度任务走重模型。这样，模型分配不再是拍脑袋，而更像资源调度。
从长远看，这可能是 OMO 最值得复制的模式之一。真正持久的抽象不是模型名，而是任务意图。模型会不断变，类别描述的工作本质却相对稳定。OMO 把这一点变成了代码层面的 resolver 机制，而不仅仅是文档里的建议。这正是它高明的地方。