Chevey339/kelivo 是什麼？

Kelivo 是一個以 Flutter 寫成的 LLM 聊天客戶端，宣稱支援 Android、iOS、Harmony、Windows、macOS 與 Linux。本文從其架構、設定方式、授權與限制出發，判斷它適合誰、不適合誰。

Chevey339/kelivo 可以商用嗎？

可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。

Chevey339/kelivo 還在維護嗎？

有在維護。儲存庫最近一次提交在 1 天前。

Chevey339/kelivo 是用什麼程式語言寫的？

主要是 Dart（依據 GitHub 的語言統計）。

Kelivo Flutter LLM 聊天客戶端評測：多平台、MCP 與 AGPL 授權解析

秒懂

它是什麼？: Kelivo 是一個以 Flutter 寫成的 LLM 聊天客戶端，宣稱支援 Android、iOS、Harmony、Windows、macOS 與 Linux。本文從其架構、設定方式、授權與限制出發，判斷它適合誰、不適合誰。
適合誰用？: Kelivo 適合需要一個跨 Android、iOS、Windows、macOS 與 Linux 的聊天介面，且願意自行設定 API 金鑰或中繼服務的個人使用者與小型團隊。它不適合需要商用閉源整合的產品，因為 AGPL-3.0 會要求衍生作品開源。
可以商用嗎？: 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
還在維護嗎？: 有在維護。儲存庫最近一次提交在 1 天前。
用什麼語言寫的？: 主要是 Dart（依據 GitHub 的語言統計）。

以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。

開源專案深度解析

Hysen Labs 編輯部 · 2026年9月10日 · Chevey339/kelivo

它解決什麼問題，誰會需要它

Kelivo 的核心機制是「自帶 API 端點」的架構。它不像 ChatGPT 那樣由官方伺服器處理模型請求，而是讓使用者在 App 內填入供應商的 API 金鑰與端點。README 提到支援 OpenAI、Gemini、Anthropic 等，但沒有列出實際的設定欄位，只能從「Custom Requests」支援自訂 HTTP headers 與 body 推測，它走的是標準 REST 呼叫。多模態輸入支援圖片、PDF、Word 文件，這表示客戶端會把檔案編碼後送給模型，而不是先在本地做 OCR。MCP 整合是另一個關鍵點，README 說支援 Model Context Protocol 工具，還內建一個 MCP Fetch 工具，這代表 Kelivo 不只是被動收文字，它能主動呼叫外部工具來取得網頁或執行搜尋。資料流大概是：使用者輸入文字或檔案，Kelivo 包成 API 請求，送到模型供應商，回應以串流方式回來，介面即時渲染 Markdown。

實際機制：從 API 呼叫到工具整合的資料流

關於工具呼叫，README 的截圖標題有「Tool Calling」與「Web Search」，但沒有描述實作細節。從 MCP 支援來看，Kelivo 可能把 MCP 工具當作函式呼叫的一種形式，模型決定何時呼叫，Kelivo 執行後把結果回傳給模型。內建的 MCP Fetch 工具應該是用來抓取 URL 內容，這與 Web Search 是兩回事：搜尋引擎清單有 Bing、DuckDuckGo、Exa、Tavily 等十五種，而 Fetch 是針對單一網址。這種設計讓 Kelivo 能應付需要即時資料的對話，例如「查一下今天的新聞」會觸發搜尋，「把這篇文章摘要給我」則可能觸發 Fetch。但要注意，搜尋引擎與供應商的 API 都需要各自的金鑰，設定成本隨之增加。文件沒有提到請求是否經過代理或加密，只說支援自訂 headers，這對進階使用者是優點，但對一般使用者是負擔。

取得與執行：從原始碼到六個平台的實際步驟

要跑起 Kelivo，最直接的方法是從 GitHub Releases 下載最新版，README 有提供連結。若想從原始碼建置，你需要 Flutter SDK，因為專案主要語言是 Dart。步驟大概是：先 `git clone https://github.com/Chevey339/kelivo`，然後 `flutter pub get` 安裝依賴，接著 `flutter run -d windows` 或對應的平台參數。但 README 沒有提供這些指令，這是文件的一個缺口。平台支援方面，Android 與 iOS 直接從原始碼建置即可，Harmony 則需要另一個獨立倉庫 `kelivo-ohos`，表示 Harmony 版本不是共用同一份 Dart 程式碼，而是分叉專案。Windows、macOS、Linux 的桌面支援仰賴 Flutter 桌面版，但 README 沒有提到最小系統需求或已知問題。設定模型供應商時，你需要找出 API 金鑰輸入介面，可能藏在設定頁，但文件沒截圖說明。QR Code 匯出功能讓你可以把供應商設定打包成 QR Code，然後在另一台裝置掃描匯入，這對多裝置使用者很實用，但前提是你能找到那個 QR 按鈕。

限制與失敗模式：文件沒說清楚的地方

Kelivo 最大的限制是文件極度簡略。README 洋洋灑灑列了二十多個功能，但沒有任何一個有使用說明。例如「Android Background Generation」說可以讓聊天在背景繼續生成，但沒有解釋它如何繞過 Android 的省電限制，也沒有提到是否會消耗大量電池。自訂字型功能支援下載 Google Fonts，但沒有說是否會影響效能或隱私。多語言只支援英文與中文，這對非這兩種語系的使用者是硬傷。更實際的失敗模式是 API 金鑰管理：Kelivo 把金鑰存在本機，若你使用 QR Code 匯出，那張 QR Code 本身就是敏感資料，掃描的人就能取得你的供應商憑證。另外，贊助商中繼服務的可用性聲稱「99.9%」，但那是贊助商的宣傳，不是 Kelivo 的保證。若你依賴這些中繼服務，一旦它們倒閉，你的設定就失效。最後，MCP 工具可能引入安全風險，因為它允許模型觸發外部動作，Kelivo 沒有提到任何權限控管機制。

替代方案比較：RikkaHub 與其他客戶端的差異

Kelivo 自己承認 UI 設計深受 RikkaHub 啟發，README 的致謝段落直接寫著「Kelivo's interface design is heavily inspired by RikkaHub」。RikkaHub 是另一個開源 LLM 客戶端，但它主要聚焦在手機平台，而且專案名稱與開發者不同。兩者的關鍵差異在於平台覆蓋：Kelivo 明確列出六個平台，包含 Harmony 與桌面系統，RikkaHub 則沒有這種承諾。另一個差異是授權，Kelivo 用 AGPL-3.0，RikkaHub 的授權需要查證，但若你打算商用，AGPL 的傳染性會讓整合變複雜。功能面上，Kelivo 的 Web Search 支援十五種引擎，這比多數客戶端只綁一兩種搜尋 API 要廣。但廣不代表深，Kelivo 沒有提到搜尋結果如何排序或過濾，而 RikkaHub 若提供類似的工具，其文件可能更詳細。若你只需要單純的 ChatGPT 介面，其實用官方 App 或網頁版更省事，Kelivo 的價值只在於多供應商與多平台。

維護與升級成本：AGPL 與更新節奏

從 Releases 記錄看，Kelivo 在 2026 年 8 月底到 9 月初有三次更新，v1.2.4 到 v1.2.6 間隔約一週，顯示開發者維持活躍的釋出節奏。最後一次 push 是 2026 年 9 月 9 日，代表專案目前沒有被棄置。但維護成本對採用者來說有兩層：第一層是跟著上游更新，每次釋出都要重新下載或重新建置，若你修改了原始碼，合併衝突會是常態。第二層是授權成本，AGPL-3.0 要求任何衍生作品必須以相同授權釋出，且若你透過網路提供服務，必須開放原始碼。這對內部工具影響較小，但若你把 Kelivo 整合進商業產品，例如包成白牌 App 賣給客戶，那你的整個產品可能被迫開源。README 沒有提供貢獻指南以外的維護文件，例如如何寫測試或如何回報錯誤，這對想長期維護的人是個風險。升級時，你需要自己追蹤 changelog，因為 README 沒有列出各版本的新增功能或破壞性變更。

編輯結論

Kelivo 適合需要一個跨 Android、iOS、Windows、macOS 與 Linux 的聊天介面，且願意自行設定 API 金鑰或中繼服務的個人使用者與小型團隊。它不適合需要商用閉源整合的產品，因為 AGPL-3.0 會要求衍生作品開源。也不適合期待開箱即用、內建官方模型帳號的人，因為所有供應商都需要你自備憑證。採用前應先確認兩件事：其一，你使用的模型供應商是否在支援清單內，例如 OpenAI、Gemini、Anthropic 或清單列出的搜尋引擎；其二，你的部署環境是否接受 AGPL 的傳染性條款。若你只是想要一個能連到自有 OpenAI 相容端點的輕量客戶端，Kelivo 的 QR Code 匯出與自訂請求功能值得一試。但若你依賴某個冷門供應商或需要企業級支援，這個專案的文件仍不足以支撐決定。

官方來源

社群筆記