技能清單掛在牆上就好，用的時候再翻開：Open WebUI 按需載入的廚房筆記

2026年10月25日，APPI News 刊出一篇關於 Open WebUI 0.12.4 的整理，談的是「代理技能按需載入」這個新設定。看起來是工程師的事，但如果你在家做過一桌菜，這件事其實很好懂：食譜不用整本攤在流理臺上，先把菜名貼在冰箱門，要煮哪道再翻到那一頁。

開關在哪裡，預設是關的

根據該篇報導，管理員可以在 Admin Settings > General 開啟「Load selected skills on demand」，也可以用環境變數 ENABLE_SKILL_LAZY_LOADING 設定。預設是關閉的，而且需要內建的 Skills 工具配合。

開啟之後，流程是這樣的：聊天中選取或綁定到模型的技能，先只以名稱和描述列出來，模型判斷任務需要時，才呼叫內建的 view_skill 工具，去讀取完整的技能內容。

這就像你家廚房牆上貼著一排食譜索引卡：紅燒牛肉、三杯雞、味噌湯，每張卡片只寫菜名和一句話描述。真的要煮三杯雞了，才把整份作法從抽屜拿出來攤開。

報導也提醒得很實在：這個改變的是技能指令進入上下文的時機，不會替技能增加能力，也不代表答案品質或速度必然提高。索引卡貼得再整齊，也不會讓你突然學會做佛跳牆。

明確點名的菜，還是立刻上桌

有一個例外值得記住。使用者在訊息裡用 $ 明確提及的技能，指令仍會直接注入系統提示，不會因為開了按需載入就延後。

廚房裡的對照很直覺：客人指名要喫那碗湯，你就不會只端出一張菜單。指名了，就立刻備料開火。

另外，技能文件如果太長，官方文件列出內容讀取上限預設為 20,000 字元，超過的先回傳預覽，模型再自己去讀需要的段落。這就像一本厚食譜，先影印目錄給你看，要哪一章再去翻原文。

知道怎麼做，跟被允許做，是兩回事

報導裡有一段對自架管理者很實際的提醒。Open WebUI 的技能是純文字指令。技能寫著「讀取內部報表後產出摘要」，它只提供處理步驟，報表能不能被讀到，仍由知識庫、檔案工具或其他整合的權限決定。

放到廚房裡：食譜教你「從冰箱拿出雞蛋」，但冰箱上不上鎖、鑰匙在誰手上，是另一件事。盤點的時候，應該把指令內容、技能讀取權限和工具存取權限分開列清楚，別把「模型知道怎麼做」誤認為「系統已授權它做」。這分寸感，跟廚房裡分清「會做」與「該不該現在做起來放」是同一種功夫，我們先前聊模型照著食譜卡回答的那套做法時，也是同樣的道理。

報導還提到一個排查細節：帶有自己 tools 欄位的請求，即使是空的，也不受這個開關影響。同一個服務、不同的請求入口，管理員開關的作用範圍可能不一樣。要看實際送出的請求，不能只看管理介面上的狀態。

那些效率數字，先別急著歸功

文章裡引了兩個案例。Public Storage 導入 Open WebUI 後，一名區域經理把每週四小時的訂位審查縮短到約 40 分鐘；Samsung Semiconductor 以 100 名分析人員試行 14 天，回報研發週期估計縮短 30%。但報導也明說，這兩個案例都沒有提及技能按需載入，不能拿來當新功能的效能證據。

這就像隔壁攤生意變好，可能是醬料變了，也可能是剛好開在新的通勤路線上。數字是真的，原因是哪個，得另外查。

回到你自己那張餐桌

如果說這個功能對日常使用者有什麼啟發，大概是三件事。每次都得遵守的規則，要確認它真的進入模型的上下文，別被按需載入悄悄延後。低頻的技能，靠描述觸發就好，像季節才用的那鍋薑母鴨食譜。要不要預設綁定，看使用頻率與任務要求。

冰箱門上的索引卡、抽屜裡的完整食譜、手上那串鑰匙，三樣東西各管各的。分清楚了，無論是管一間公司的 AI，還是管一個家的廚房，都少一點混亂。