Kelivo：一个把 LLM 客户端塞进 Flutter 的跨端尝试
A Flutter LLM Chat Client. Support Mobile & Desktop.
秒懂
- 它是什么？
- Kelivo 是一个用 Flutter 写的 LLM 聊天客户端，覆盖 Android、iOS、Harmony 和桌面端。它功能列表很长，但 AGPL-3.0 许可和快速迭代的节奏决定了它更适合个人用户和愿意跟进上游的开发者。
- 适合谁用？
- Kelivo 适合那些想要一个免费、跨平台、且能连接 OpenAI、Gemini、Anthropic 等多个提供商的聊天界面的个人用户，尤其是同时使用手机和桌面设备的人。Harmony 用户也能通过 kelivo-ohos 仓库找到对应版本，这是它相对其他 Flutter 客户端的独特之处。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Dart（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，以及为谁而写
Kelivo 解决的问题很直接：现在市面上的 LLM 聊天客户端要么只支持单一平台，要么只支持单一模型提供商。一个同时用 Android 手机和 Windows 桌面的人，想在不同设备上跟同一个 AI 助手对话，通常得装两套不同的软件，而且每套软件支持的模型还不一样。Kelivo 用 Flutter 把这件事统一了，一套代码跑在 Android、iOS、Windows、macOS、Linux，甚至 Harmony 上。它的目标用户是那些不想被某个厂商锁定的个人用户，尤其是愿意自己配置 API Key 而不是用现成订阅服务的开发者。这类用户通常熟悉 OpenAI、Gemini 这些名字，也清楚自己每个月消耗多少 token。Kelivo 不是给完全不懂技术的普通消费者准备的，因为它需要你填入自己的提供商 API 地址和密钥，而不是开箱即用。
架构上的关键选择：Flutter 与多平台策略
Kelivo 的核心是 Flutter，这是一个用 Dart 语言写的 UI 框架，它的卖点是一套代码可以编译到多个平台。从仓库结构看，主要代码都在一个代码库中，桌面和移动端共享大部分逻辑，只是针对不同平台做少量适配。这种做法的好处是维护成本低，新功能只需要写一次。但代价是某些平台特有的能力，比如 Android 的后台生成功能，需要单独用平台通道去实现。README 里提到 Android 支持后台生成，这是一个可选的设置，说明 Flutter 本身不提供这个能力，必须依赖 Android 原生的服务。这提醒我们，跨平台框架不是银弹，凡是涉及系统级行为的功能，都得逐个平台去写原生代码。Kelivo 的 Harmony 支持甚至不在主仓库里，而是单独放在 kelivo-ohos 仓库中，这意味着 Harmony 版本可能落后于主版本，或者需要额外的维护工作。
功能清单背后的实际机制
Kelivo 的功能列表很长，但我们可以挑几个关键机制来看。MCP 支持，也就是 Model Context Protocol，是一种让 AI 模型调用外部工具的标准协议。Kelivo 内置了一个 MCP Fetch 工具，这表示它不只是被动地接收文本，还能主动去抓取网页内容，把结果喂给模型。Web 搜索是另一个亮点，它集成了超过 15 个搜索引擎，包括 Bing、DuckDuckGo、Exa、Tavily 这些，还有一个叫 SearXNG 的自托管选项。这意味着用户可以选择用哪个搜索后端，而不是被强制绑定到某一个。多模态输入支持图片、PDF、Word 文档，这通常是通过把文件转换成文本或图片然后附加到请求中实现的，具体机制 README 没有细说，但从支持格式来看，它应该是在客户端做了预处理。语音和 TTS 支持也值得注意，它内置了系统 TTS，同时支持 OpenAI、Gemini、ElevenLabs 的语音服务，这说明它把语音输出也抽象成了可插拔的提供商。
运行与配置：从源码到聊天界面
要运行 Kelivo，你需要先克隆仓库，然后确保本机装有 Flutter SDK。README 没有给出具体的安装命令，但根据 Flutter 项目的通用流程，你需要在项目根目录执行 flutter pub get 来拉取依赖，然后用 flutter run -d <device-id> 在目标设备上启动。如果你想在 Android 上跑，还需要配置好 Android SDK 和模拟器。配置提供商时，Kelivo 提供了 QR 码分享功能，可以把你的提供商配置导出成二维码，然后在另一台设备上导入，这避免了手动输入 API 地址的麻烦。数据备份和恢复功能意味着聊天记录可以导出成文件，方便迁移。对于自定义请求，它支持设置 HTTP 头和 body，这为接入那些不标准或需要特殊认证的 API 提供了灵活性。如果你想尝试 TestFlight 版本，需要先加入 Discord 或 QQ 群获取邀请，因为 TestFlight 的链接是公开的，但 beta 名额可能有限。
许可证与维护成本：AGPL-3.0 的双刃剑
Kelivo 使用 AGPL-3.0 许可证，这是一个很强的 copyleft 许可。它的核心要求是，如果你修改了代码并把它作为网络服务提供，你必须把修改后的源码也开源。这对个人用户没有影响，你甚至可以 fork 一份自己改着玩。但如果你是一家公司，想基于 Kelivo 做内部工具，或者把它集成到你的商业产品里，那么 AGPL 会迫使你公开你的修改。这一点必须在采用前就想清楚。从维护角度看，Kelivo 的发布节奏很快，v1.2.4 在 2026 年 8 月 25 日发布，v1.2.5 在 8 月 31 日，v1.2.6 在 9 月 6 日，几乎每周都有新版本。这意味着上游在活跃开发，但也意味着你会不断收到更新提示。如果你自己打了补丁，每次合并上游都会是一场冲突的噩梦。所以，除非你只是使用官方版本，否则维护成本会相当高。
局限性与不适用的场景
Kelivo 的第一个明显局限是，它不是一个开箱即用的应用。你需要自己准备 API Key，而且不同提供商的 API 格式和计费方式都不一样，配置过程对新手来说有门槛。第二个局限是 Flutter 在桌面端的体验，虽然它能跑，但相比原生应用，某些交互细节可能不够顺滑，尤其是长列表滚动和文本选择。第三个局限是 MCP 和 Web 搜索这些功能依赖外部服务，如果某个搜索引擎改了 API 或者某个 MCP 工具不再维护，Kelivo 的对应功能就会失效。另外，README 里没有提到隐私政策，你的聊天记录和 API 请求都直接发给提供商，如果你用的是第三方中转服务，那么数据会经过他们的服务器。对于需要严格数据隔离的企业环境，Kelivo 并不合适，因为它的设计假设是用户信任自己配置的提供商。
同类项目的比较：RikkaHub 与自建方案
Kelivo 的 README 明确感谢了 RikkaHub 项目，说它的 UI 设计深受 RikkaHub 的启发。RikkaHub 是另一个开源的 LLM 聊天客户端，但它的定位更偏向于桌面优先，而且许可证可能不同。Kelivo 与 RikkaHub 的关键差异在于平台覆盖，Kelivo 强调移动端和 Harmony 支持，而 RikkaHub 可能更专注于桌面。如果你只需要一个桌面客户端，RikkaHub 或许更轻量，但如果你想在手机上用同一个界面，Kelivo 的多平台优势就显现出来了。另一个替代方案是直接使用各家提供商自己的客户端，比如 OpenAI 的官方应用或者 Gemini 的网页版，这些工具通常优化得更好，但它们只支持自家的模型。Kelivo 的价值在于聚合，它让你在一个界面里切换 GPT-4、Claude 和 Gemini，而不是开三个不同的应用。如果你有编程能力，也可以自己用 Python 或 Node.js 写一个简单的 API 调用脚本，但那只能处理纯文本，无法获得 Kelivo 提供的 Markdown 渲染、工具调用和语音交互这些完整体验。
编辑结论
Kelivo 适合那些想要一个免费、跨平台、且能连接 OpenAI、Gemini、Anthropic 等多个提供商的聊天界面的个人用户，尤其是同时使用手机和桌面设备的人。Harmony 用户也能通过 kelivo-ohos 仓库找到对应版本，这是它相对其他 Flutter 客户端的独特之处。但如果你所在的组织需要把聊天客户端嵌入商业产品，AGPL-3.0 会让代码开源义务成为障碍，这时候更合适的选择是直接调用各家的 API 或使用 MIT 许可的客户端。在采用之前，你应当先验证两件事：一是你需要的模型提供商是否在支持列表内，因为 README 只列出了 OpenAI、Google Gemini、Anthropic 等几个名字，没有给出完整清单；二是确认 MCP 工具和内置的 Fetch 工具能否满足你的实际调用场景，因为这部分功能往往依赖特定协议版本，迭代快，可能需要频繁更新。Kelivo 的更新频率很高，v1.2.4 到 v1.2.6 之间只隔了不到两周，这意味着你换来的新功能同时也带来了持续跟进上游的维护成本。
社区笔记