# 後Fable5的協作思考：應該把難度當常數 > 不少模型分派器把模型能力寫死進規則，模型一改版就悄悄過期。這篇提出把難度當常數、能力當變數的兩層設計：穩定的難度分類，加一張帶日期的綁定表，再配一個重校心跳，讓分派系統撐得過模型換代。 - Author: Paul Kuo（郭曜郎） - Date: 2026-07-06 - Pillar: 智能與秩序 / Intelligence & Order - Tags: 多模型調度, 模型路由, 韌性工程, AI 協作, 政策綁定分離, 個人知識系統 - Canonical: https://paulkuo.tw/articles/difficulty-as-constant/ - 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 常常比換模型更划算。所以那張表要填的其實有兩格：用哪個模型，以及開多少力氣。兩個都屬於會變的那一層。 ## 難度要用哪一把尺來量？ 用錯誤成本這把尺，而不是「模型夠不夠聰明」。 我給難度三個評分面向：推理深度、判斷空間，還有錯誤成本，其中錯誤成本權重最高。這是刻意的。推理深度和判斷空間，會隨模型變強而相對縮水，今天燒腦的推理，明年的模型可能一口氣就吞了。可是「這件事錯了會多貴」是商業性質，它跟模型多聰明無關，是這三把尺裡最不會移動的一把。把權重壓在最穩的軸上，分類法才不會每次模型改版就作廢。 ## 模型進步了，你怎麼知道該重綁了？ 這是整套設計裡我最花心思的一塊，因為它要防的東西不會報錯。 我以前吃過這種虧。有個排程本來每天自己跑，某天上游斷了，它就無聲地停在那，整條鏈子熄火，我隔了好一陣子才發現。同樣的風險在這裡是：模型進步了、綁定該更新了，可是沒有任何東西會跳出來提醒你。表不會報錯，它只是不再是最划算的選擇，而這種退化不會觸發任何警報。 所以我給那張表配了一個心跳。留一組大概十題、我實際會交付的代表任務，每題先標好理想的角色跟「怎樣算做得好」。新模型一出，就把這組題丟給它跑一遍，看它現在穩定守得住哪一層，再據此把某個角色往更便宜的模型移，順手更新日期、記一行原因。這就是我一直在用的一條韌性原則落地：任何你依賴的自動化，都要能回答「它還活著嗎」。 這不是我第一次拆多模型怎麼分工（[多模型認知協作](/articles/multi-model-cognitive-collaboration/)、[Fable 5 的工作系統](/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 這條線](/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 參數。