高低模型分工：用最少的 token 做最难的任务

Sun, 30 Aug 2026 18:00:00 +0800

我最初的做法：高模型出计划，低模型执行

在炼丹炉（Alchemy Furnace，我的开源项目）上开发大功能时，我的模型分工一开始是这样的：高模型出计划，低模型去试执行。逻辑听起来无懈可击：计划是最费脑子的活，给最强模型；执行是照着做，给便宜模型省 token。

跑了几轮之后我意识到，这不是最佳实践：省下的 token 在别的地方加倍还了回去。坑在哪、后来怎么分，一条条说。

三个坑：为什么"计划高、执行低"不够

坑一：计划里的任务难度不均。

一个实施计划拆出来的任务，难度天差地别。同一个计划里，既有"写一个纯函数渲染器"这种机械活，也有"设计 SSRF 校验 + 提供者熔断 + 证据等级判定"这种高难活。一刀切全丢给低模型，难任务在低模型手里反复试错，每次失败都是一轮"试错 + 看错误 + 再试"，token 没省多少，时间翻倍，最后往往还是得升级。

坑二：低模型失败没有出口。

低模型试了，失败了，然后呢？如果升级路径不存在，低模型只有两个选项：硬编一个成功（最危险，测试都可能一起编出来），或者卡死空转。我早期踩过前者，代价是返工整个文件。

坑三：验证被一起降级了。

执行降级了，自测也跟着降级：低模型自己测自己，绿灯也不能全信。判断性工作（“这样测算不算数”）和机械性工作（“跑一遍测试”）不是一回事，不能一起降级。

模型分级的问题不在"分级"本身，而在分级的依据：按角色分（计划/执行）是错的，按难度分（任务）才对。

正确框架：按难度分级 + 三个旋钮

Claude Code 的 Workflow 里每个子 Agent 可以独立指定模型档位和努力度，这就是三个旋钮：

旋钮一：模型档位。高（Opus）/ 中（Sonnet）/ 低（Haiku）。

旋钮二：努力度（effort）。从 low 到 max。很多任务根本不用换模型：同一个模型把 reasoning 预算拧低，就是廉价版本。换模型是换"能力上限"，调 effort 是调"用力程度"，两回事。

旋钮三：任务边界清晰度。这是最便宜的杠杆：spec 拆得越细、验收标准写得越死，任务越接近"机械执行"，能用的模型档位就越低。

我的任务分配表：

难度	模型	例子
判断型	高模型 + 高 effort	需求探索与脑暴、接口契约设计、代码评审、根因定位、安全核对
常规型	中模型 + 中 effort	常规功能实现、测试编写、中等重构、普通调试
机械型	低模型 + low effort	模板化改动、纯函数实现、i18n 文案、跑测试与验证

用最少的 token 做最难的任务

说白了就一条：把大部分任务变简单，让高模型 token 只花在"决定"上，不花在"执行"上。

几个真实管用的杠杆：

计划是高模型性价比最高的投资。计划阶段多花的高模型 token，换来的是执行阶段任务边界清晰、可降级给便宜模型。这是"1 单位的贵，换 100 单位的省"。不是精确数字，是量级感受。
低模型任务必须满足三个条件，缺一不可：

边界明确：任务描述到文件级，依赖关系写清
测试兜底：TDD 红→绿，失败能被测试抓住
终止条件：做不了就停，明确写"连续失败就停止报告，不许编成功"

第三条最重要。我在炼丹炉的 Workflow 脚本里给每个子 Agent 都注入了终止条件段（A3：文件不存在、依赖无法确认、连续 3 次修复失败，立即停止报告）。允许低模型说"我卡住了"，比让它硬编一个成功安全一个量级。

升级路径要显式。低模型失败不是终点：带着"红测试 + 尝试过程 + 卡点描述"升级给高模型。高模型拿到的是完整上下文，一次到位给解法或改计划，而不是重新摸底。
评审和验证分开降级。跑回归（机械）可以低模型；安全核对、代码评审（判断）留给高模型。炼丹炉的验收任务里，回归和"ZIP 解压检查有没有泄露 key"是两件事：前者低模型跑，后者高模型过。

炼丹炉实例：一个计划怎么分

以女娲蒸馏 + Skill 导出的开发为例（6 个任务、4 个波次）：

计划本身（文件级任务清单）：高模型出。这是唯一一个"必须先花"的成本。
Task3 Skill 渲染器：纯函数、格式明确（slug 规则、SKILL.md 结构、ZIP 命名全写死）、测试完备，典型的机械型任务，低模型 + low effort 就能扛。
Task2 Python 蒸馏链路：SSRF 校验、来源熔断、证据等级判定，属于判断与工程混合，配中模型 + 中高 effort，比低模型反复试错便宜得多。
Task6 端到端验收：回归跑测低模型，产物安全核对（解压查 sk-、token、内部日志）高模型。
A3 终止条件：给每个"低模型试"的任务一个明确出口，试不动就停，升级。

收尾

用下来我的感觉是：判断性的活给最贵的模型，机械的活给最便宜的；任务写得清就可以降档，失败超过两次就升级，别耗着。

模型分级省的不是高模型的钱，是浪费在错模型上的钱。最难的活依然要最贵的模型，但反过来也成立：大部分活之所以难，是因为你没把它写清楚。把任务写清楚，是高模型 token 花得最值的地方。

封面图：Krzysztof Golik / Wikimedia Commons · CC BY-SA 4.0