Conduit：把 Open WebUI 搬上手機之後，還剩下什麼問題
Native iOS and Android client for Open WebUI, direct OpenAI-compatible, Ollama, and Hermes agents.
秒懂
- 它是什麼？
- Conduit 是一個以 Flutter 寫成的 iOS 與 Android 原生客戶端，目標是補上 Open WebUI 在行動裝置上的破口，4.0 之後也能完全不連 Open WebUI 伺服器。它的價值取決於你是否已經有一台自架伺服器，以及你能不能接受 GPL-3.0。
- 適合誰用？
- 如果你已經自架 Open WebUI，而且痛點正好是反向代理後面的登入、切到背景就斷掉的行動端串流，Conduit 是目前少見針對這些細節處理的原生客戶端，值得先裝商店版本試用；如果你完全沒有自架服務、只想找一個通用 LLM 聊天 App，Direct 模式雖然可用，但你就用不到它的 Workspace、頻道、筆記這些需要伺服器的部分，改用其他客戶端成本更低。導入前請先確認三件事：你的伺服器版本是否在 README 所列的相容範圍內、你的 Open WebUI 是否開啟了頻道與工具權限、以及你的部署情境能不能接受 GPL-3.0 對二次散布的要求。
- 可以商用嗎？
- 可以，但有條件。GPL-3.0 是 copyleft 授權：如果你散布包含它的軟體，就必須以同一授權公開該軟體的原始碼。只在內部執行、不對外散布，則不會觸發這項義務。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Dart（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要補的是行動端那幾個一直沒被補上的洞
README 對問題的描述相當具體：Open WebUI 在桌機上很好，到了手機就從邊緣開始崩。它列出的情境包括反向代理後面的認證、App 進入背景後中斷的串流、把截圖丟進提示詞的流程、以及從主畫面直接開一段對話。這四件事都不是模型能力問題，而是行動作業系統與瀏覽器環境造成的摩擦。Conduit 的定位就是針對這些摩擦寫一個真正的 Flutter App，而不是把網頁包一層殼。
目標讀者因此相當明確：已經自己架了 Open WebUI、平常在桌機用得很順、但外出時只能開瀏覽器忍受上述問題的人。README 也提到 4.0 之後即使沒有 Open WebUI 伺服器也能運作，這讓它的適用範圍擴大到只用 Direct 連線的人，但那批使用者能拿到的功能明顯較少，後面會談。
五種連線方式，對應五種完全不同的能力邊界
首次啟動時 Conduit 會問你要怎麼連線，之後可以再補上其他方式。README 列出五種：Open WebUI 自架伺服器、Direct、Apple On-Device、Apple PCC、以及 Hermes。這五種不是同一件事的不同包裝，各自對應的能力差距很大。
Open WebUI 模式是功能最完整的一條路，README 明列聊天、資料夾、筆記、頻道、workspace、工具、網頁搜尋、圖片生成。Direct 模式則繞過 Open WebUI，直接對 OpenAI 相容端點（Chat Completions 或 Responses）、LM Studio、Azure 風格的 API 版本、原生 Ollama、以及 OpenRouter 說話。你在 Open WebUI 裡已經設定過的 Direct 連線會自動帶過來。Apple On-Device 走的是 Apple 的 SystemLanguageModel，需要 iOS 26 與 Apple Intelligence，可離線執行，支援串流、取樣控制與 JSON schema 回應，context window 為 4K，但不支援圖片輸入、推理控制與工具呼叫。Apple PCC 走 Foundation Models 框架，需要 iOS 27、Apple Intelligence 可用性與 Apple 管理的 PCC entitlement，支援圖片輸入、推理等級、取樣與輸出上限、JSON schema、即時配額與 context 狀態，以及 PCC 網路失敗時可選的裝置端退回，但工具呼叫同樣未啟用。Hermes 連的是你自己的 Hermes 伺服器，可以即時看到工具運作、在敏感步驟前核准，並讓排程代理在你睡覺時執行。
值得注意的是 Apple 這兩條路徑都標示為 iOS only，Android 使用者實際上只有三種選擇。README 沒有說明 Apple 這兩種模式在 Android 上是否有任何替代方案。
串流走 WebSocket，資料留在裝置上
README 對機制的描述集中在兩處。第一是傳輸層：token-by-token 的串流走 WebSocket，宣稱的好處是回應成長時逐字稿位置不會跳動、釘選的提示詞不會被推走、長對話載入不會卡住 UI。這是行動端最實際的差異，因為瀏覽器版的 Open WebUI 在背景切換與長對話上的問題正是它想解決的。
第二是資料路徑：README 明確寫「Your chats live on your device first. Nothing routes through a backend the maintainer operates.」也就是沒有維護者營運的中介後端。API key 與自訂 header 存在平台的 secure storage。這對自架使用者是關鍵，因為你連的是自己的伺服器，中間不該再多一跳。
渲染層則是另一組機制。README 說它用的是原生 Flutter surface，不是包一層 web view，並列出語法高亮程式碼區塊（可複製與預覽）、原生渲染的 Mermaid 圖、LaTeX 與數學、可展開的推理／工具呼叫／程式執行區塊、行內引用與來源卡片與後續建議、以及 Chart.js 嵌入。這份清單裡最難在行動端做好的是 Mermaid 與 Chart.js，因為兩者在網頁上都是靠 JavaScript 函式庫，原生重寫的成本不低。README 沒有說明這些渲染是純 Dart 實作還是嵌入其他引擎。
從原始碼建置與實際設定
如果你只是要試用，README 直接給了 Google Play 與 App Store 的連結，套件識別碼是 app.cogwheel.conduit，iOS 端的 App Store 頁面標題為 Conduit Open WebUI Client。這兩條路徑不需要碰任何建置設定。
要從原始碼建置的話，README 把細節指向 docs/BUILDING.md，本文手上沒有那份文件的內容，因此無法在這裡給出確切的 flutter build 指令或簽章設定步驟。可以確定的是專案以 Dart 撰寫、使用 Flutter，所以建置流程會落在 Flutter 工具鏈上，但具體的 flavor、簽章與 CI 設定必須以該文件為準。
設定層面，README 提到的可調項目包括：連線方式在首次啟動時選擇、之後可追加；Direct 連線可帶 API key，本機端點則可省略；自訂 header 與 key 存放於平台 secure storage。Workspace 底下的 models、knowledge、prompts、tools、skills 都是原生畫面，README 說沒有權限的區塊就不會出現，這表示顯示內容由伺服器回報的權限決定，而不是客戶端硬編。Hermes 模式同樣只暴露你的伺服器實際回報的能力。
GPL-3.0 與你沒想到的維護成本
授權是 GPL-3.0，這對個人自用沒有影響，但對想把 Conduit 包進內部流程再散布出去的團隊有實質意義：GPL-3.0 是 copyleft，二次散布通常需要提供對應原始碼。這不是法律建議，具體情境請詢問你自己的法務。
維護成本方面，從發布紀錄可以看出節奏：v4.1.4 在 2026-09-01、v4.1.3 在 2026-08-28、v4.1.2 在 2026-08-26，三週內三個修補版本。這代表專案處於活躍修正期，好處是問題修得快，代價是你如果自己 fork 或改動，得持續跟上游合併。行動客戶端的另一個固定成本是商店審核與平台版本跟進，README 提到的 Apple On-Device 需要 iOS 26、Apple PCC 需要 iOS 27，這類門檻會隨著 Apple 每年更新而變動，你無法把某一版當成永久穩定的基準。
還有一個容易被忽略的相依：功能完整度取決於你的 Open WebUI 伺服器版本與權限設定。頻道功能在 README 中的描述是「when your server enables them」，這意味著客戶端升級不代表功能就會出現。
什麼情況下它會是錯的工具
第一種情況是你沒有自架任何東西，也不打算自架。Direct 模式確實可以只帶一組 API key 就開始用，但你會失去 Workspace、筆記、頻道、工具、網頁搜尋與圖片生成，這些在 README 裡都掛在 Open WebUI 連線底下。此時 Conduit 對你而言就只是一個介面較講究的 LLM 客戶端，和它想解決的問題無關。
第二種情況是你需要工具呼叫，而且打算靠 Apple 的裝置端或私有雲模型。README 明確寫 Apple On-Device 與 Apple PCC 都不支援 tool calling，On-Device 另外不支援圖片輸入與推理控制。如果你的工作流程依賴模型呼叫工具，這兩條路徑直接出局，得走 Open WebUI 或 Hermes。
第三種情況是 Android 使用者想用 Apple 的兩條路徑。它們都是 iOS only，README 沒有提供 Android 的對應方案。
第四種是 context 需求較高的情境。Apple On-Device 的 context window 是 4K，README 沒有給出其他模式的數值，因此無法在這裡比較。若你的對話經常夾帶長文件，這條路徑會先撞到上限。
替代方案：行動瀏覽器版 Open WebUI，以及 Hermes 的差異
最直接的替代方案不是另一個 App，而是你手機瀏覽器裡的 Open WebUI 本身。兩者的差別在架構層次：瀏覽器版是伺服器渲染的網頁介面，認證走反向代理的既有機制，串流依賴瀏覽器與網路連線的持續性，App 進背景後的行為由瀏覽器決定；Conduit 是原生 Flutter 應用，串流走 WebSocket，憑證放在平台 secure storage，並針對背景切換與長對話載入做了處理。README 描述的正是這段落差。反過來說，瀏覽器版不需要安裝任何東西、不需要處理 GPL-3.0、也不會因為商店審核而延遲更新，如果你的痛點沒有嚴重到需要原生客戶端，維持現狀是合理的。
另一個容易混淆的是 Hermes 模式。它不是 Conduit 的競爭者，而是 Conduit 支援的一種後端，連的是你自己的 Hermes 伺服器。它與其他模式在互動模型上不同：你會即時看到工具運作、在敏感步驟執行前被要求核准、並讓排程代理在特定時間執行。README 說對話與排程各有自己的分頁，且 Conduit 只暴露你的伺服器實際回報的能力。也就是說 Hermes 模式把「人在迴圈裡」當成預設，而不是把工具呼叫藏在使用者看不到的地方。這與 Direct 模式那種單純的請求回應迴圈是兩種不同的產品。
編輯結論
如果你已經自架 Open WebUI，而且痛點正好是反向代理後面的登入、切到背景就斷掉的行動端串流，Conduit 是目前少見針對這些細節處理的原生客戶端，值得先裝商店版本試用；如果你完全沒有自架服務、只想找一個通用 LLM 聊天 App，Direct 模式雖然可用，但你就用不到它的 Workspace、頻道、筆記這些需要伺服器的部分，改用其他客戶端成本更低。導入前請先確認三件事：你的伺服器版本是否在 README 所列的相容範圍內、你的 Open WebUI 是否開啟了頻道與工具權限、以及你的部署情境能不能接受 GPL-3.0 對二次散布的要求。最後一項要問的是你自己的法務，不是這篇文章。
社群筆記