RikkaHub：一个把多个 LLM 服务商塞进一台 Android 手机的客户端
RikkaHub是一款支持多个LLM提供商的Android应用程序。
秒懂
- 它是什么？
- RikkaHub 是一个原生 Android LLM 聊天客户端，支持 OpenAI、Google、Anthropic 等兼容 API，并内置 proot 工作区、MCP 与搜索集成。本文基于仓库与 README 梳理其机制、上手方式与边界。
- 适合谁用？
- RikkaHub 适合那些需要在 Android 上切换多个 LLM 服务商、并且愿意折腾配置的开发者或重度用户。它不适合只用一个固定模型、想要开箱即用的人，也不适合需要官方支持或稳定商业保障的团队。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库最近一次提交在 2 天前。
- 用什么语言写的？
- 主要是 Kotlin（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题：Android 上的多服务商聊天客户端
大多数手机上的 LLM 客户端只绑定一个服务商，比如官方 ChatGPT 或 Gemini 应用。RikkaHub 想解决的是另一类需求：你同时订阅了 OpenAI、Google Gemini、Anthropic Claude，或者使用国内中转服务，希望在同一个界面里切换对话，而不必装多个应用。它面向的是愿意自己配置 API 地址和密钥的用户，不是普通消费者。仓库描述明确说它支持所有 OpenAI、Google、Anthropic 兼容的 API，这意味着只要你的服务商提供这类接口，就能接入。它不是一个聚合平台，不替你管理密钥，也不负责模型质量。
工作机制：从 API 适配到 proot 工作区
RikkaHub 的核心机制是协议适配。它不针对每个模型单独写代码，而是统一识别 OpenAI、Google、Anthropic 三种 API 格式，你只需在设置里填入自定义 URL 和模型名。数据层使用 Room 数据库存储对话，DataStore 保存偏好设置，HTTP 请求走 Okhttp，UI 用 Jetpack Compose 实现。比较特别的是它内置了一个基于 proot 的 Linux 工作区，这意味着你可以在聊天中调用一个轻量级 Linux 环境来执行命令或脚本，类似在手机上跑一个沙盒。这个设计让它不只是聊天工具，更像一个移动开发环境。不过 proot 的性能和兼容性受限于 Android 内核，重负载任务可能不适用。
安装与配置：从源码构建的明确步骤
如果你要从源码构建，README 给出了一条硬性要求：必须在 app 文件夹放置 google-services.json 文件，否则无法编译。这个文件来自 Firebase 项目，你需要先在 Firebase 控制台创建应用并下载配置。构建工具是 Android Studio，项目用 Kotlin 和 Gradle 管理依赖。安装后，你需要手动添加服务商：在设置里填写 API 地址、密钥和模型列表。如果你有多个服务商，可以用二维码导出和导入配置，这个功能在多设备间迁移时很实用。官方推荐从 rikka-ai.com 或 Google Play 下载预编译包，避免自己处理签名和 Firebase 配置。
功能边界：哪些能做，哪些做不到
RikkaHub 的功能列表看起来很长，但有几个明显的边界。第一，它不支持图片之外的复杂输入，虽然支持图片、PDF、Docx 和文本，但多模态能力取决于你连接的服务商是否支持视觉模型，客户端本身不负责图像识别。第二，MCP 支持是有的，但需要你自己配置服务器地址，没有内置的 MCP 仓库。第三，搜索功能依赖外部服务，比如 Exa、Tavily、Zhipu 等，你需要为这些服务单独申请 API 密钥。第四，消息分支和记忆功能是客户端层面的，它们只影响本地对话历史，不会改变模型的上下文窗口。如果你想要一个全自动的 AI 助手，RikkaHub 不是，它更像一个可组合的工具箱。
维护与升级：活跃但封闭的贡献策略
仓库最近一次推送是 2026 年 8 月 28 日，版本号 2.4.15，三天内发布了三个小版本，说明维护很活跃。但贡献策略非常明确：不接受新功能 PR，不接受翻译改动，不接受大规模重构或 AI 生成的代码。这意味着如果你想加一个功能，只能自己 fork。这降低了维护者的负担，但也限制了生态扩展。升级成本方面，由于项目依赖 Jetpack Compose 和 Navigation 3 等较新的 Android 库，你可能需要跟随 Google 的更新节奏。另外，构建时需要 google-services.json，如果你不打算用 Firebase 的推送或分析功能，这个依赖会显得多余，但项目没提供绕过的选项。
许可与分发：AGPL-3.0 的实际影响
RikkaHub 使用 AGPL-3.0 许可，这是一个强 copyleft 许可。如果你修改了代码并分发应用，你必须以相同许可开源你的修改版本。对于个人使用或内部工具，影响不大，但如果你想基于它做商业产品，比如提供一个托管服务，那么网络交互也算分发，你需要公开源代码。另外，README 中警告存在大量 fork 版本，并提醒用户注意隐私风险。这暗示社区里有人用 fork 做恶意改造，比如收集 API 密钥或请求过多权限。从维护角度看，AGPL 许可允许任何人 fork，但项目不接受上游新功能，所以 fork 会长期分叉。如果你打算长期使用，建议跟踪官方发布而不是某个 fork。
替代方案对比：与原生应用和通用客户端的差异
与 RikkaHub 最接近的替代品是各家官方应用，比如 ChatGPT、Gemini 和 Claude 的移动端。它们的好处是零配置，打开就能用，但只能连自家模型，无法切换服务商。另一个方向是像 Open WebUI 这样的自托管 Web 客户端，它可以在浏览器里连接多个模型，但没有原生 Android 体验，也没有 proot 工作区。RikkaHub 的独特之处在于把 proot 环境塞进客户端，这让你可以在对话中直接执行代码或命令，而 Web 客户端通常只做纯文本交互。如果你不需要执行环境，那么用官方应用或自托管 Web 界面可能更简单，但如果你想要一个移动端的多模型工作台，RikkaHub 是少数选择之一。
编辑结论
RikkaHub 适合那些需要在 Android 上切换多个 LLM 服务商、并且愿意折腾配置的开发者或重度用户。它不适合只用一个固定模型、想要开箱即用的人，也不适合需要官方支持或稳定商业保障的团队。在采用前，请先确认你的 API 服务商是否兼容 OpenAI、Google 或 Anthropic 的接口格式，并检查 AGPL-3.0 许可对你分发或修改的影响。另外，项目明确拒绝新功能 PR，如果你有定制需求，必须自己 fork 维护。最后，由于存在大量第三方 fork，请只从官网或 Google Play 下载，避免隐私风险。
社区笔记