memect/kc/auto-model-selection

Auto Model Selection

模型选择并不是经常调用的 skill —— 对大部分用户来说，工作区 .env 里的分层已经设定得很合理，4 层 + 成本敏感的精细选型其实是过度设计。本 skill 存在的两个时刻：conductor 在从零启动时配 tier 分配（少见）；在 skill-to-workflow 内部某个 workflow 需要挑选合适的 worker LLM。

下面的内容是经验性的 —— 是作者在这个领域里摸出来什么有效。当作起点启发式即可，保质期大概 3–6 个月，毕竟模型家族迭代很快。

Worker LLM 家族 —— 实战启发式

• Qwen 家族 —— 通用 worker 工作的健壮、便宜首选。任何时候该家族的旗舰 MoE 通常都是常规抽取/分类的最佳劳力之一。小尺寸（3B–70B）数量多且稳定。默认选它没错。
• DeepSeek —— 复杂任务表现优秀。当规则涉及多步推理、嵌套判断、或者 Qwen 在长上下文里开始吃力的场景，伸手去拿它。
• GLM 和 Kimi —— 在和 DeepSeek 相同的"复杂任务"档位也很强。代价：通常不出小尺寸变体（3B–70B），所以只能做 tier1/tier2，做不了 tier3/tier4。

旗舰 MoE 形状与 tier1 基准

当前这一代旗舰 MoE LLM 有一个可识别的形状：总参数 200-400B，每个 token 激活 ~20B 专家。例子（几个月后就会过期）：Qwen 在 200-400B-A20B 区间的旗舰 MoE、DeepSeek-V4-Flash 等。

这个形状是不错的 worker LLM 首选 —— 不一定是 tier1 绝对最强，但作为基准起点很合理。挑 tier1 模型时，先从这一类开始，除非有特定理由再往别处走。

30B 以下的小 LLM —— 基本免费

参数量降到 ~30B 以下后，大部分服务商上这些模型都极便宜。Qwen 在这个区间提供了一大堆选择，质量都不错。

这个区间挑模型有两条规则：

• 避开 coder 变体（名字里带 coder / code 的）—— 小尺寸的 coder 模型在通用 worker 任务上多半不可靠。只在任务确实是代码相关时再用。
• 优先选无 thinking 模式的变体（如果有得选）。分配给小 worker 的任务都是简单固定的，多余的思考只会浪费时间和 token。

VLM / OCR 选型

第一个问题：视觉任务是什么类型？

• 扫描件字符、印章、手写体 —— 用专门的 OCR 模型。当前的强选项（随时间会变）：Paddle-OCR 家族、GLM-OCR、DeepSeek-OCR。旧版本仍能用。纯字符识别不需要上更大的通用 VLM。
• 图表、复杂表格、奇怪边框或无边框的结构 —— 试更大、更贵的通用 VLM。在这类场景里，OCR 专用模型和通用 VLM 之间的结构理解差距迅速拉大。

不确定时先跑最便宜的 OCR，只在它漏掉了结构信息时再升级。

Context7 —— 按需查模型事实

上面的启发式回答的是"挑哪种模型"。具体事实（当前模型名、确切上下文窗口、定价、API 格式）用 Context7 查：

c7 library <服务商名>
c7 docs <libraryId> "available models"

两条命令：先用前者找到服务商的 library ID，再用后者拿到最新文档和代码示例。适用场景：

• 工作区 model-tiers.json 看起来过期了（KC 自上次模型发布后没更新）
• 用户切换服务商，需要发现可用模型
• 某个新服务商的 /models 端点返回空或无帮助
• 检查 .env 里的模型名是不是还在线

安装：npm i -g context7。验证：c7 library openai 应返回结果。

tier1/tier2 选型最终落地

tier 分配最后决定的是成本。能满足准确率要求的最便宜模型胜出。正则是隐含的 "tier 0"，规则只靠模式匹配就能完成时，应该先伸手去拿正则 —— 关于何时从正则升级到 worker LLM，见 skill-to-workflow。

不需要填满所有 tier。如果服务商没有合适的小模型，tier3/tier4 留空完全可以。把生效的选择写到 AGENT.md，下次会话就能继承。

复看节奏

本 skill 的启发式会过期。作者打算每 3–6 个月在新模型代际落地之后回来更新一次。如果你发现这里的建议和 Context7 今天显示的事实矛盾了，信 Context7 —— 事实已经走在前面了。