Locally Uncensored：把 Ollama 與 ComfyUI 收進一個桌面視窗的整合取捨
The all-in-one local AI studio for your desktop: chat, image and video generation and a coding agent in one free, open source app. Windows and Linux. No Docker, no terminal, no cloud required.
秒懂
- 它是什麼？
- 這個專案把聊天、圖像與影片生成、coding agent 和 agent 工具鏈塞進同一個 Tauri 桌面應用，用安裝精靈取代 Docker 與終端機。整合本身是它最大的賣點，也是它最需要被檢視的地方。
- 適合誰用？
- 如果你要的是一台不連雲端的 Windows 或 Linux 工作站，讓非工程背景的同事也能跑本機模型與出圖，這個專案值得先裝來試；它的價值在於把 Ollama 與 ComfyUI 的啟動、修復與更新都收進應用內，而不是模型本身。若你的環境是 macOS、或你已經有一套自管的 ComfyUI 工作流與節點圖，這個封裝層只會擋在中間，應該留在原本的堆疊。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它想解決的不是模型問題，是啟動摩擦
本機 AI 的門檻很少卡在模型品質，多半卡在環境。你得先裝 Ollama 或 LM Studio，再另外處理 ComfyUI 的 Python 環境與節點相依，出圖失敗時還要判斷是模型沒下載、顯存不夠，還是自訂節點版本衝突。Locally Uncensored 把這些步驟收進一個安裝檔：首次啟動的精靈會尋找機器上已在執行的推論引擎，找不到就用單擊安裝一個，ComfyUI 也走同一套流程。README 的說法是「No Docker, no terminal, no config files」，而它的目標讀者寫得很清楚，是 Windows 10、11 與 Linux 上不想碰終端機的人。
值得注意的是它沒有自己的推論引擎。README 明說模型管理員「works with the engine you already have (Ollama, LM Studio and others)」，也能連結這些工具已經存好的模型而不複製一份。所以它本質上是協調層與介面層，不是執行層。這個定位決定了後面所有的優點與限制：引擎出事時，它能修復的範圍有限。
機制：安裝精靈、ComfyUI 生命週期與四個分頁共用模型
從 README 與倉庫結構能看出的資料流大致如此。應用是 Tauri 桌面程式，前端為 TypeScript，開發時 npm run dev 走瀏覽器模式，npm run tauri build 產生桌面二進位。啟動後由精靈偵測本機推論引擎，並接管 ComfyUI 的安裝、啟動、修復與更新，使用者在 Create 分頁看到的是文字轉圖像、編輯、以遮罩做 inpainting 的圖生圖、去背、影片、圖片動畫化、延長片段、動作控制、說話角色、音樂與 Character Studio 這些「lane」，而不是節點圖。
模型層面有兩條路徑。一是接上既有的 Ollama 或 LM Studio；二是由模型管理員標示哪些模型符合你的硬體並一鍵下載。LoRA 的部分，README 說選擇器會即時讀取本機 LoRA 資料夾，Character Studio 訓練出的角色會直接放進該資料夾，附堆疊與強度滑桿。
Agent 分頁則把工具呼叫集中管理：網頁搜尋與抓取、檔案讀寫、shell、程式碼執行、截圖、圖像與影片生成，以及自帶的 MCP server。長工作交給背景 agent，面板顯示執行中的項目。README 強調「Every tool call passes a permission gate you control, and a read only run stays read only」，這是它對 agent 安全性的主要設計主張。Code 分頁的 agent 會先建立 repo 地圖，只改被指名的行，套用前先顯示 diff，跑測試並讀取失敗訊息，並以 .lurules 檔案放每個專案的規則。
安裝與開發路徑：三個指令與一個精靈
終端使用者不需要指令。從 Releases 取最新建置即可：Windows 是 .exe（NSIS，README 標為建議）或 .msi，Linux 是 .deb、.rpm 或 .AppImage。macOS 目前沒有發行檔，README 只說可以用 npm run tauri build 從原始碼建置。
開發者的路徑寫在 README 的折疊區塊裡：
git clone https://github.com/PurpleDoubleD/locally-uncensored.git cd locally-uncensored npm install npm run dev # browser dev mode npm run tauri build # desktop binary
Windows 上另有 setup.bat，Linux 與 macOS 上是 setup.sh，用途是為開發模式準備 Node、Git 與 Ollama。設定層面，README 明確提到的鍵只有一個：Settings 裡的 Local API，它把每個本機模型放到同一個 OpenAI 相容位址後面，並以 token 保護，讓其他 coding 工具能共用同一台機器。遠端存取則是在設定中開啟，透過 LAN 或 Cloudflare tunnel，以 QR code 加 passcode 配對，預設關閉，並列出已連線裝置。
關於安裝檔有一個實務細節值得轉述：README 說部分防毒引擎會標記未簽章、且會下載其他二進位的 NSIS 安裝檔，專案稱這是誤報，並指向 SECURITY.md 的說明，同時指出安裝檔由 GitHub Actions 從 master 的公開原始碼建置，更新通道以公開 minisign 金鑰簽章，兩者都可自行驗證。這段話是專案方的說法，我沒有實際驗證過簽章。
雲端開關與兩個只能上雲的 lane
這個專案並非全本機。README 說明 Upscale 與 Erase Object 這兩個 lane「run in the cloud only」，另外可選的 LU Labs Cloud 是為了跑桌面顯卡放不下的大型模型，同一個帳號也能在瀏覽器上的 lu-labs.ai 使用，採方案制或不過期的點數包。專案強調本機應用在兩種情況下都維持免費。
這裡的界線要分清楚：本機路徑依賴你已有的 Ollama 或 LM Studio 與自動安裝的 ComfyUI，雲端路徑依賴廠商帳號。對把「不連雲端」當成硬性條件的人來說，Upscale 與 Erase Object 是明確的例外，使用前必須先確認這兩個功能是否在你的可接受範圍內。README 沒有說明這兩個 lane 上傳的內容範圍與保存政策，這是文件目前的空白。
限制：macOS 缺席、硬體天花板與薄弱的可觀測性
第一個限制寫在 README 的下載表裡：macOS 沒有發行檔，只能自行建置。第二個限制是硬體。模型管理員會標示哪些模型符合你的硬體，這件事本身就承認了顯存是硬邊界；而雲端開關的存在，等於專案方承認有些模型任何桌面卡都跑不動。你若打算用 70B 級別的模型做日常推理，這個應用不會讓硬體變快。
第三個限制關於可觀測性。當 ComfyUI 由應用代管，出圖失敗時你面對的是應用給的訊息，而不是 ComfyUI 的 console 與節點圖。README 說應用會「repairs」ComfyUI，但沒有描述修復的判定邏輯與失敗後的降級行為。對已經熟悉 ComfyUI 的人來說，這是把可除錯的表面積換成了便利性。
第四個限制是 agent 的權限模型。README 說每次工具呼叫都經過可控制的權限閘門，唯讀執行維持唯讀，這是正確的方向，但文件沒有說明閘門的粒度（依工具、依路徑、依 session？），也沒有說明背景 agent 在無人看管時如何套用同一套規則。要讓 agent 執行 shell 與程式碼，這部分的細節比功能清單重要。
替代方案：LM Studio 加自管 ComfyUI 的差別在誰負責整合
最直接的替代不是另一個整合應用，而是拆開來用：LM Studio 或 Ollama 負責文字模型，ComfyUI 自己裝、自己維護工作流，圖像與影片的節點圖由你掌握。差別在責任歸屬。自管方案裡，模型下載、顯存配置、自訂節點衝突、更新時機都由你決定，代價是每次環境變動都要自己處理；Locally Uncensored 把這些收進應用，代價是你接受它的封裝邊界，包含它在 macOS 上的缺席與兩個必須上雲的 lane。
有趣的是這個專案並不排斥替代方案，它明確支援接上既有的 Ollama 與 LM Studio，也能連結那些工具已存好的模型而不複製。所以對已經有 LM Studio 的人來說，它更像是補上圖像、影片與 agent 這幾塊，而不是取代原本的引擎。真正要換掉的，只有你原本手動維護的 ComfyUI 啟動流程。
另一個方向是純雲端服務。README 自己給出的對比是，本機路徑的優勢在於模型選擇不受供應商政策限制，以及資料不出機器。如果你的工作內容不涉及敏感資料，也不在意審查邊界，雲端服務在硬體與模型規模上沒有天花板，這個專案反而多了一層安裝與驅動的維護成本。
維護成本與 AGPL-3.0 的實際含義
發佈節奏可以從版本號看出來：v2.6.7 在 2026 年 8 月 31 日，v2.6.8 在 9 月 6 日，v2.6.9 在 9 月 8 日。這種密度意味著更新通道會頻繁推送，README 說更新走簽章通道，Windows 是簽章自動更新。對個人使用者這是優點，對需要變更控管的團隊則要考慮是否關閉自動更新並改為手動驗證版本。
授權是 AGPL-3.0。這不是可以隨手放進閉源產品再散布的授權：AGPL 的網路條款通常被理解為，若你修改後以網路服務形式提供給他人使用，需要向使用者提供對應原始碼。若你只是在自己機器上跑，或把本機的 Local API 接給自己的工具用，情況與對外提供服務不同。實際影響取決於你的散布與服務方式，請依條文與你的律師確認，本文不提供法律意見。
還有一項維護成本容易被忽略：這個應用同時管轄推論引擎、ComfyUI 與模型檔案三層。任何一層的版本變動都可能讓整合層需要跟著調整，這也是它發版如此頻繁的可能原因。若你的環境不允許頻繁更新，就要想清楚如何凍結版本。
誰該採用，誰該先等
適合的情況相當明確：Windows 或 Linux 的個人工作站或小型團隊，想要一個入口就能聊天、出圖、跑影片與使用 coding agent，而且不想為此維護 Python 環境與節點圖。對這群人，安裝精靈與模型管理員省下的時間是實打實的，Local API 也讓既有工具能共用同一台機器的模型。
不適合的情況同樣明確。macOS 使用者目前沒有發行檔。已經有成熟自管 ComfyUI 工作流的人，把控制權交給代管層沒有好處。把「完全不出機器」當成硬性要求的人，要先確認 Upscale 與 Erase Object 這兩個雲端 lane 是否能停用。需要審查 agent 權限細節再放行的團隊，則應該先讀原始碼中權限閘門的實作，因為 README 對這部分的描述停在原則層次。
驗證順序建議照這個走：先用模型管理員確認你的顯卡能跑哪一級模型，再開 Settings 的 Local API 確認外部工具能連上，最後才把 agent 的 shell 與檔案寫入權限打開。這三步的順序反過來，出問題時你會分不清是模型、網路還是權限設定造成的。
編輯結論
如果你要的是一台不連雲端的 Windows 或 Linux 工作站，讓非工程背景的同事也能跑本機模型與出圖，這個專案值得先裝來試；它的價值在於把 Ollama 與 ComfyUI 的啟動、修復與更新都收進應用內，而不是模型本身。若你的環境是 macOS、或你已經有一套自管的 ComfyUI 工作流與節點圖，這個封裝層只會擋在中間，應該留在原本的堆疊。採用前先確認三件事：你的 GPU 記憶體對應的模型等級、設定裡的 Local API 是否能被現有工具鏈接受、以及 AGPL-3.0 對你散布方式的影響。最後一項若涉及對外提供服務，請找律師看條文，這裡不構成法律意見。
社群筆記