# 后Fable5的协作思考：应该把难度当常数 > 不少模型分派器把模型能力写死进规则，模型一改版就悄悄过期。这篇提出把难度当常数、能力当变数的两层设计：稳定的难度分类，加一张带日期的绑定表，再配一个重校心跳，让分派系统撑得过模型换代。 - Author: Paul Kuo（郭曜郎） - Date: 2026-07-06 - Pillar: 智能与秩序 / Intelligence & Order - Tags: 多模型调度, 模型路由, 韧性工程, AI 协作, 政策绑定分离, 个人知识系统 - Canonical: https://paulkuo.tw/zh-cn/articles/difficulty-as-constant/ - Language: Simplified Chinese (简体中文) - Translation: AI-translated from the zh-Hant (Traditional Chinese) original - Original (zh-Hant): https://paulkuo.tw/articles/difficulty-as-constant.md - Site index for LLMs: https://paulkuo.tw/llms.txt --- > **TL;DR**：常见的模型分派器，会把「哪种任务交给哪个模型」写进规则。但模型能力是整套系统里最会变的东西，今天要大模型才能做的事，明年可能小模型就能完成。我的做法是：任务难度先用错误成本、推理深度、判断空间来分类，这层尽量不动；真正会变的，是「这一类任务现在交给哪个模型最划算」。所以模型名称不要写进规则，而是放进一张带日期的绑定表。
▶ 听摘要
AI 合成语音・作者本人声线克隆
前几天，我用Claude 帮我把手上的工作分派给不同模型。它很快整理出一张表：难的交给 Opus，中等的给 Sonnet，量大又规律的交给 Haiku。这套分法看起来很合理。它把模型当成不同等级的工具，依照任务难度分配资源。难题用强模型，例行工作用轻模型，成本和品质都能兼顾。 但我接着问：如果模型一直在进步，我们的工作流会有什么变化？ 今年需要 Opus 才能做稳的任务，明年可能 Sonnet 就能处理。今天适合丢给 Sonnet 的工作，过一阵子也可能变成 Haiku 的基本题。那原本那张分派表，要怎么办？ 这时候问题就浮出来了。多模型调度不能只做成一张固定表，因为表里会改变的，不只是任务本身，还有模型能力。 一旦把会变的能力，写进不常更新的规则里，系统就会开始失准。它不会立刻坏掉，但会慢慢折旧：有些任务还在用过强的模型，有些任务其实已经可以下放，有些判断则停在上一代模型的能力边界。 所以，多模型调度麻烦的地方，可能不在第一张分派表怎么画。那件事已经很多人讲得很清楚了。 关键的问题是：这个规划设定好后，谁负责看它是不是已经过期？ ## 为什么模型分派器一上线就开始腐化？ 因为那张表的默认是：模型的能力不会变。而模型能力，偏偏是整套系统里你唯一能确定「一定会变」的部分。 把「难的给 Opus、简单的给 Haiku」写进规则，等于把最会移动的东西，钉在最不该动的地方。半年后换了新模型，本来要 Opus 才扛得住的任务，换成便宜一阶的模型就做得到了，可是规则还停在旧世界。接下来不是继续花大钱请贵模型做已经变简单的事，就是根本没发现有更省的走法。分派器没有坏，它只是悄悄过期了。 ## 一个耐用的分派器，该把什么写死？ 先说明一下，分派任务本身不是新把戏。规划、路由、分派、验收、整合这套骨架，Anthropic 官方在 [agent 设计指南](https://www.anthropic.com/engineering/building-effective-agents) 里早就讲得很细，连「简单的问题丢便宜模型、难的丢强模型」这种路由都写进去了。我想补的是它比较少着墨的下一层：怎么让这套分派撑过模型换代。 我的做法是，把难度写死，让「用哪个模型」那栏保持弹性替换。 一个任务的难度，是任务自己的性质，不是模型的性质。 例如，帮一篇文章改标点，错了顶多再修；但帮一份合约判断风险，错了可能影响决策。模型变强，确实会让很多工作变得更容易完成，但不会让「错了的代价」自动变低。它要推几层逻辑、错了要付多大代价、有没有标准答案，这些才是任务本身的难度。模型再进步，也不会让一个高风险的决策变成低风险。会变的只有一件事：这个难度，现在交给谁最划算。 所以我把系统拆成两层。一层是难度分类法，稳定、几乎不动，用「角色」来描述工作，例如深推理、标准生成、高吞吐，而不写死某个模型的名字。另一层是一张绑定表，把角色对到当期的模型，这张表会动，而且明白标上日期。 工程师的习惯会想把那张绑定表写死，过去叫「内在设置」。但在这套设计里，它应该愈显眼愈好。 因为它是整个系统里唯一被授权去改的地方。模型改版时，你只动这张表，标上新日期，分类规则一行都不用碰。 「今年的山，会成为明年的路。」模型进步太快，我们能做的，不是阻止变化，而是让会变的东西集中在一个小小的、带日期的查找表里。 ![同一颗任务，两种设计对比：常见做法把难度判断和模型名字焊在同一条规则里（难的任务固定丢给 Opus、简单的固定丢给 Haiku），半年后模型换代，规则没感觉，继续多花钱或错过更省的路；这篇的做法把难度分类（稳定层，只描述角色、不写模型名）和绑定表（挥发层，带校准日期）分成两层，模型换代时只改绑定表这一格的日期，难度分类一行都不用碰。](/images/articles/difficulty-as-constant-comparison.svg) 还有一点要提醒：换模型层级不是唯一的按钮。同一个模型里，也可以用 effort 这类参数调整「它要花多少力气思考」：开高一点，答案可能更稳，但比较慢、也比较贵；开低一点，速度和成本漂亮，但适合风险较低的任务。Anthropic 官方在[选型指南](https://platform.claude.com/docs/en/about-claude/models/choosing-a-model)里也提醒，调 effort 常常比换模型更划算。所以那张表要填的其实有两格：用哪个模型，以及开多少力气。两个都属于会变的那一层。 ## 难度要用哪一把尺来量？ 用错误成本这把尺，而不是「模型够不够聪明」。 我给难度三个评分面向：推理深度、判断空间，还有错误成本，其中错误成本权重最高。这是刻意的。推理深度和判断空间，会随模型变强而相对缩水，今天烧脑的推理，明年的模型可能一口气就吞了。可是「这件事错了会多贵」是商业性质，它跟模型多聪明无关，是这三把尺里最不会移动的一把。把权重压在最稳的轴上，分类法才不会每次模型改版就作废。 ## 模型进步了，你怎么知道该重绑了？ 这是整套设计里我最花心思的一块，因为它要防的东西不会报错。 我以前吃过这种亏。有个排程本来每天自己跑，某天上游断了，它就无声地停在那，整条链子熄火，我隔了好一阵子才发现。同样的风险在这里是：模型进步了、绑定该更新了，可是没有任何东西会跳出来提醒你。表不会报错，它只是不再是最划算的选择，而这种退化不会触发任何警报。 所以我给那张表配了一个心跳。留一组大概十题、我实际会交付的代表任务，每题先标好理想的角色跟「怎样算做得好」。新模型一出，就把这组题丢给它跑一遍，看它现在稳定守得住哪一层，再据此把某个角色往更便宜的模型移，顺手更新日期、记一行原因。这就是我一直在用的一条韧性原则落地：任何你依赖的自动化，都要能回答「它还活着吗」。 这不是我第一次拆多模型怎么分工（[多模型认知协作](/zh-cn/articles/multi-model-cognitive-collaboration/)、[Fable 5 的工作系统](/zh-cn/articles/claude-fable-5-work-system/) 都写过），但这次的重点不在谁做什么，在怎么让这套分工撑过模型换代。顺带一提，这套规则上线当天，我就拿它验了一次自己的设计。手上一个任务，可能是要写一个工具、整理好几份文件、或修改网站的某个功能，我常常一时说不准该交给哪个模型。原本得自己问一句「这题难度多高」或「帮我分派」才会触发判断；原本运作模式是被动，我后来改成主动，更新一版新的skill，不必再等我问。现在只要我在窗口里交付任务，开场就会先看到一行：难度、角色、当期该用哪个模型、一句理由。这个翻转只动了三行，分类逻辑一个字都没碰，因为运作模式跟分类逻辑，本来就被切干净了。 它没自动跳出来的时候，我会用触发语把它叫出来，比如「这该用哪个模型」「帮我分派这个任务」，或者直接打斜杠指令 `/model-orchestrator`。判断完是一回事，真的要它跨模型执行又是另一回事：想让它照分派结果实际去跑，我得再说一句「照这个分派实际跑」或「开子代理做」，它才会启动验收整合那套流程，通过子代理的 model 参数路由到 Opus、Sonnet、Haiku、或 Fable。主对话串用哪个模型，是我在 app 里自己选的，Claude 换不了；跨模型只能靠子代理去跑，不是把主串整个换掉。这套机制目前在我平常写代码的窗口（Code）已经完全生效，在另外两个常驻窗口（Cowork、Chat）上传过 capabilities 之后也能用。 ![难度常数的完整流程：一个任务进来，先由稳定层的难度分类法（错误成本权重最高、推理深度、判断空间）评出角色；角色交给挥发层的绑定表（带校准日期）对应到当期模型执行；新模型发布或每季一次，重校心跳会拿代表任务重跑，把角色移到更便宜的模型并更新表的日期。](/images/articles/difficulty-as-constant-flow.svg) ## 为未来的层级收敛而设计 还有一件事要提早准备：这三层总有一天会塌成两层。 模型的能力地板一直往上抬，便宜的模型会从下面把中间层一口一口吃掉。今天分深推理、标准生成、高吞吐三层，明年也许标准生成整层被便宜模型收编，后年可能除了最难的一小撮，其余全丢同一个模型最省事。所以我让那张绑定表打从一开始就允许多个角色指向同一个模型，某一层被清空的时候，系统不会跟着垮掉。 再往远看，决策的轴会整个换掉。今天问的是「哪个模型够聪明做这件事」，最后会变成「能守住这个错误成本门槛的最便宜一层是哪个」。这也是为什么一开始就要用错误成本当主轴：它是唯一撑得到那一天的尺。这也是我在 [AI 这条线](/zh-cn/topics/ai/) 一直在想的事：能力快速变动的时候，怎么还设计得出撑得住的秩序。 这个问题不只发生在模型分派，也会发生在人自己的工作流里。 其实这件事比模型分派大得多。前阵子一场读书会后，我跟一位朋友聊到这半年用 AI Agent 的共同感受：多工变成常态，可是多窗口、多任务、多条脉络同时展开，人要同时追的东西也多到一个新的上限，于是我们都回头用起手写笔记本整理思路。有意思的是，最近工具本身也出了一个总控台，让你在一个仪表板里看哪些窗口在跑、哪些闲置、哪些要重读。当 AI 便宜又快，真正卡住你的就换成另一件事：人有没有办法管住这么多条脉络。这跟那张分派表是同一个道理，让工具在底下加速，自己牢牢握住判断和方向感，手写笔记本保住的就是这个。 ## 出生就先盖好逃生门 我从一开始，就没有假设这套分派规则会永远存在。哪天模型供应商自己在后台把分派做掉了，一个端点内部就帮你路由好，这套人工调度就该退休；哪天层级塌到只剩一层，全部丢同一个模型比什么分派都省心，它也该退休。 这背后是有账可算的。Anthropic 自己的数据摆着：一个 agent 大约吃掉单次对话 4 倍的 token，多代理系统更是约 15 倍，只有当任务价值撑得起这笔开销才划算；他们也直说，多数 coding 任务可并行的部分少，并不适合套用多代理。分派和调度不是愈多愈好，能简单解决的就别硬上。 我之前有个自动优化的系统，养到后来信号太稀疏、价值撑不起维护成本，最后我把它收了。那次教会我一件事：怎么让一个工具好好退场，是设计的一部分，不是事后才想的事。这张表会被丢掉，这套角色分法也会被改。真正留下来的，是一个习惯：把会变的东西关进带日期的小盒子，再给它一个心跳。工具会被下一代模型淘汰，这个习惯不会。 盖房子的时候，顺手把逃生门也盖了。不是为了逃跑，而是为了知道，自己还有选择。 如果只带走一件事，就是这句：不要把模型名称写进你的判断规则。把判断规则留下来，把模型名称放到一张可以重绑、可以更新、也可以被淘汰的表里。 ## 附：拿去改成你自己的 这套设计不绑我的工作流，你可以直接搬。给你两个东西：一个看得懂结构的骨架，一段生成你自己版本的 prompt。 先是骨架，照着填就有雏形： ``` # 任务调度规则（骨架） ## 难度分类（稳定层，几乎不动） 三个面向评分，错误成本权重最高： - 错误成本：这件事错了多贵。影响整体结论或品牌属高，只影响局部属低。 - 推理深度：要多层推论或创意属高，套既定规则属低。 - 判断空间：要主观取舍属高，有标准答案属低。 多数落高交给深推理层，多数落低交给高吞吐层，中间交给标准生成层。 ## 绑定表（挥发层，会动，带日期） 校准日期：______（换模型时只动这张表和这个日期） - 深推理层 → 你当期最强的那颗模型 - 标准生成层 → 中间那颗 - 高吞吐层 → 最便宜、最快那颗 ## 重校心跳 新模型发布或每季一次，拿约十题你真实工作的代表任务（各标好理想层级和成功标准）丢给它跑，看它稳定守得住哪一层，把对应层往更便宜的模型移，更新上面的日期。 ## 退场条款 出现任一个就收掉：供应商在端内自动路由、层级塌到剩一层、判断的麻烦大于省下的成本。 ``` 懒得自己填，把下面这段贴给你惯用的 AI，让它访谈你、生出贴合你工作流的版本： ``` 你是我的模型调度设计助手。帮我做一套能撑过模型换代的任务分派规则，原则是把任务难度当常数、把模型能力当变数，两层分开。 1. 难度分类（稳定层）：用三个面向帮我的任务评分，错误成本权重最高，其次推理深度，再来判断空间。先问我三到五种我最常做的工作，各评出高、中、低。 2. 绑定表（挥发层）：用角色描述层级（例如深推理、标准生成、高吞吐），先别写死模型名。问我现在有哪些模型、各自的成本与强项，再把角色对到当期模型，产出一张带今天日期的表。 3. 重校心跳：帮我列约十题、取自我真实工作的评测任务，标好理想角色与成功标准，当作新模型出来时重跑、重绑的依据。 4. 退场条款：帮我写三个该收掉这套调度的信号。 输出一份我能存成 skill 或系统提示词的文件：难度分类摆稳定层，绑定表独立成带日期的一节，附重校步骤与退场条款。 ``` ## 出处 本文提到的机制与数据，出自 Anthropic 官方文件： - Anthropic，[Building Effective Agents](https://www.anthropic.com/engineering/building-effective-agents)：orchestrator-workers、routing 等 workflow patterns，以及「先从最简单解做起、别过度工程化」的原则。 - Anthropic，[How we built our multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system)：多代理 token 成本（约 4 倍／15 倍）、Opus 领军加 Sonnet 子代理的分层实证、多代理的适用与退场边界。 - Anthropic，[Choosing the right model](https://platform.claude.com/docs/en/about-claude/models/choosing-a-model)：能力／速度／成本三轴的选型原则，以及在同一模型内调整力气的 effort 参数。