一個爐口接了所有鍋，但你的菜單本來就沒那麼簡單

回顧 2026 年 10 月 23 日，APPI News 刊出了一篇關於 Comfy Router 的完整指南。這是 ComfyUI 推出的服務：用單一 API 入口、一組金鑰，呼叫目前受支援的合作夥伴模型，涵蓋生圖、影片、音訊等媒體任務。聽起來有點抽象？把它搬進廚房，你馬上就懂了。

想像你家廚房裡，過去每煮一道菜就得換一套爐具。煎魚用這家的爐，燉湝用那家的爐，每口爐的火力旋鈕位置不同、點火方式不同，連鍋蓋的口徑都各自為政。久了，廚房檯面上堆滿說明書，你光是想煮一頓飯，就得先在腦子裡排一遍每口爐的操作順序。

Comfy Router 做的事，像是在檯面上開了一個統一的爐口。你不必再分別記每家供應商的網址、認證方式與參數格式，透過同一個入口送出請求。對需要同時接觸好幾種模型的開發者來說，少了一些重複接線的雜事。

統一的是爐口，不是整張菜單

不過，別急著把整套廚房設備都丟了。來源指南裡有一個很關鍵的區分：Comfy Router 負責的是模型 API 的呼叫路徑，ComfyUI 的節點工作流才是從頭到尾串起載入素材、影像控制、後製與輸出的那一整條動線。

用廚房的話說，一個爐口解決的是「開火」這件事。但如果你的菜還要醃、要裹粉、要油炸後瀝油、要擺盤前試味道，這些步驟不會因為你換了爐口就自動消失。文章提醒，如果你的工作流還包含遮罩、控制圖、放大、合成或人工檢查，這些環節仍然要留在原本的流程裡處理。呼叫一個合作夥伴模型的 API，並不會自動把整張節點圖搬進去執行。

這跟我們之前聊過的一鍋到底走遍三個爐有點像又不太一樣：那一回是把鍋做到哪裡都能用，這一回是把爐口統一成同一個。方向相反，但都想解決同一種煩，工具之間的格格不入。

每家模型的脾氣，還是要各自摸清

統一入口聽起來省事，實際掌勺的人知道，食材的脾氣不會因為換了鍋就變乖。生圖模型可能喫文字提示和參考圖片，影片模型還要你設定長度與影格條件；有的服務同步等你，有的先回給你一個任務識別碼讓你稍後再來問。回傳的結果，可能是圖片網址，也可能是影片任務資料。

官方 quickstart 說得直白：Router 回傳的是「模型原生結果」。也就是說，爐口統一了，但每道菜起鍋時的長相不同，你端菜的盤子還是得自己準備好幾種。如果產品要讓不同模型的成果擺上同一張桌，團隊得自己定義內部格式，統一儲存媒體網址、任務狀態、生成參數與來源模型，再讓各模型的解析層去轉換。

開火前，先畫一遍你的動線

導入之前，文章給的建議很務實：先畫出從素材進入到結果交付的每個步驟，標出哪些是模型呼叫、哪些是節點控制。這就像辦一桌菜前，先把備料順序攤開來看：哪幾道可以交給同一口爐，哪幾道必須留著自己顧火。

還有幾件事得自己查清楚：模型與供應商的支援清單、輸入格式、費用、執行位置，以及素材送出去之後的資料政策。特別是執行位置這一項，指南提醒別預設請求會在本機跑。這道理跟廚房一樣，你把食材交給別人的中央廚房，就得先問清楚，他們怎麼處理你的料，會留多久，這在導入前的評估裡從來不是小事。

說到底，工具再方便，替你省下的只是開火的力氣。菜好不好喫，還是回到你對每個步驟的掌握：什麼時候下料、什麼時候起鍋、什麼時候該停下來試一口味道。爐口統一了，掌勺的人還是你。