Featured image of post 高低模型分工:用最少的 token 做最难的任务

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

我最初的做法是高模型出计划、低模型执行,跑了几轮发现这不是最佳实践。这篇复盘坑在哪,并给出按难度分级的完整分工框架。

我最初的做法:高模型出计划,低模型执行

在炼丹炉(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 只花在"决定"上,不花在"执行"上。

几个真实管用的杠杆:

  1. 计划是高模型性价比最高的投资。计划阶段多花的高模型 token,换来的是执行阶段任务边界清晰、可降级给便宜模型。这是"1 单位的贵,换 100 单位的省"。不是精确数字,是量级感受。

  2. 低模型任务必须满足三个条件,缺一不可:

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

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

  1. 升级路径要显式。低模型失败不是终点:带着"红测试 + 尝试过程 + 卡点描述"升级给高模型。高模型拿到的是完整上下文,一次到位给解法或改计划,而不是重新摸底。

  2. 评审和验证分开降级。跑回归(机械)可以低模型;安全核对、代码评审(判断)留给高模型。炼丹炉的验收任务里,回归和"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

Built with Hugo
Theme Stack designed by Jimmy