Cherry Studio 实测评估：多模型桌面客户端的便利与 AGPL 许可的代价
Cherry Studio 是一款支持多家 LLM 服务商的桌面客户端，运行于 Windows、macOS 与 Linux，集智能对话、自主智能体和 300 多个内置助手于一体。
秒懂
- 它是什么？
- Cherry Studio 是一个面向 Windows、macOS 和 Linux 的桌面 AI 客户端，支持多家云端与本地模型提供商，内置 300 多个预设助手。本文从架构、上手方式、局限性和替代方案四个角度评估它是否值得进入你的工具链。
- 适合谁用？
- Cherry Studio 适合需要在一个界面里切换多家模型提供商、又不想写代码的个人用户，尤其是经常处理文档、需要 Mermaid 图表和代码高亮的写作者或研究者。它不适合把客户端当作内部工具分发给同事的企业团队，AGPL-3.0 会强制要求你公开修改后的源码，这对闭源商业项目是硬性障碍。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是桌面端的多模型碎片化问题
大多数 AI 用户会在浏览器里开五六个标签页，分别对应 ChatGPT、Gemini、Claude 和 Perplexity。Cherry Studio 把这些人聚到一个桌面应用里，让你在一个窗口内切换不同提供商。它支持 OpenAI、Gemini、Anthropic 等云端服务，也支持通过 Ollama 和 LM Studio 连接本地模型。对同时使用云端与本地模型的人来说，这省去了来回切换上下文的麻烦。它的目标用户很明确：不愿意写代码、但需要多个模型协作的个人用户。它不是给开发者的 API 聚合层，而是一个图形化的生产力工具。
数据流与架构：本地客户端加远程 API，没有中间服务器
从仓库布局和 README 描述看，Cherry Studio 是一个 Electron 风格的桌面应用，TypeScript 编写，直接在你的机器上运行。它不依赖自建的云端代理，你的请求从客户端直接发往各模型提供商的 API。这意味着你的 API 密钥保存在本地，不会经过第三方服务器。文档提到支持 WebDAV 文件管理和备份，说明用户的数据可以同步到自己的 WebDAV 服务，而不是强制上传到项目方的云。这种设计对隐私敏感的用户有吸引力，但也意味着你失去了云端同步的便利，所有历史会话和文件都得自己管理备份。
从下载到启动：无需配置环境，但需要自带 API 密钥
README 强调“Ready to Use, No Environment Setup Required”，这意味着你从 releases 页面下载对应平台的安装包即可运行，不需要安装 Node.js 或 Python。首次启动后，你需要手动填入各家模型的 API 密钥。对于 OpenAI、Gemini 这类服务，直接粘贴密钥就能用。对于 Ollama 本地模型，你需要先在本机运行 Ollama 服务，然后在 Cherry Studio 里配置本地端点。如果你用的是 Claude 或 Perplexity 这类通过网页服务提供的模型，客户端可能走的是非官方接口，这需要你自己承担账号风险。配置过程不涉及命令行，所有操作都在图形界面里完成。
300 多个预设助手是亮点，但也是维护负担
项目宣称内置 300 多个预配置的 AI 助手，覆盖翻译、写作、编程等场景。这些助手本质上是预设的系统提示词，你选中一个助手，对话就按那个提示词进行。这个数量对普通用户来说是即开即用的便利，但对维护者来说是持续的负担。每个助手都需要跟随模型能力变化而更新，否则提示词会过时。你可以创建自定义助手，这意味着你不必依赖预设，但自定义助手需要你自己设计提示词，这又回到了写提示词的老路上。预设助手解决的是“不知道该怎么问”的问题，而不是“问得更好”的问题。
MCP 支持是亮点，但插件系统还没有落地
README 在功能列表里明确写了 MCP (Model Context Protocol) Server 支持。这意味着你可以把外部工具通过 MCP 协议接入对话，让模型调用你的本地工具或数据源。这是目前 AI 客户端里比较前沿的能力，值得肯定。但路线图里列出的插件系统、ASR 语音识别、OCR 等功能都还在规划中，没有实现。如果你需要的是可扩展的插件生态，Cherry Studio 目前给不了，你需要等它把路线图走完。MCP 支持的实际体验取决于你配置的服务器质量，官方文档没有给出详细的配置示例，这意味着你需要自己去查 MCP 的规范。
AGPL-3.0 许可：个人免费，企业分发要谨慎
项目使用 AGPL-3.0 许可证。这个许可对个人用户没有实际影响，你下载使用、甚至修改后自己用都没问题。但如果你是一家公司，想把 Cherry Studio 修改后分发给内部员工或客户，AGPL-3.0 要求你公开修改后的完整源码。这对大多数商业公司来说是不可接受的，尤其是那些不想暴露内部提示词或集成逻辑的团队。仓库里还有一个 commercial 徽章链接，说明项目方提供商业授权选项，但具体条款需要单独联系。在评估时，不要把 AGPL-3.0 当成 MIT 那样宽松，它对你的分发方式有实质性约束。
替代方案：直接使用 API 或选择更轻量的客户端
如果你只需要一两个模型，直接使用提供商官方网页版是最简单的路径，零安装、零配置、零许可风险。如果你需要编程接口，直接用 OpenAI SDK 或 Anthropic SDK 写脚本调用，比任何客户端都灵活。如果你需要一个图形客户端且不介意闭源，可以考虑 Chatbox 或 Jan，它们在多模型支持上类似，但许可策略不同。如果你偏好开源且许可宽松，可以看看 NextChat，它采用 MIT 许可，部署在 Vercel 上，但它是 Web 应用而非桌面客户端。Cherry Studio 的差异化在于它同时支持本地模型和 MCP，这是其他大多数客户端没有的。选择的关键在于你多看重 MCP 集成，以及你是否接受 AGPL 的约束。
编辑结论
Cherry Studio 适合需要在一个界面里切换多家模型提供商、又不想写代码的个人用户，尤其是经常处理文档、需要 Mermaid 图表和代码高亮的写作者或研究者。它不适合把客户端当作内部工具分发给同事的企业团队，AGPL-3.0 会强制要求你公开修改后的源码，这对闭源商业项目是硬性障碍。不适合需要深度定制界面或插件生态的用户，目前插件系统还在路线图上，没有落地。在采用前，先确认两件事：你常用的模型提供商是否在支持的列表中，以及你是否接受每次启动时客户端会连接其官方域名检查更新或加载主题。如果你只是偶尔用一两个模型，直接使用提供商官方网页版或命令行工具可能更轻量。
社区笔记