一开始定位是正确的，后面就变成既要又要，变得极度臃肿
1 个赞
已经好久没打开过了，chat又不像chat，agent又不像agent，蛮尴尬的定位。纯chat又简洁的话，目前安卓手机用rikkahub 很满意
2 个赞
好奇怪，同一个key，我的kelivo就是用不了。。不过我是win端。
下载体验下，看看V2的优点，期待是个好产品
又大又卡，搞不明白作者，加什么agent功能
看到了大家很多讨论，有认可，也有批评，有点百感交集。
很多问题其实也是我们自己一直在思考的问题。
Cherry Studio 目标想做一个始终可以最大化 AI 模型能力的产品，在 2025 年之前，chat 就是 AI 最主要的交互方式。如果停留在 chat 层面，是没有办法达成这样的长期愿景的。
事实上，很多同期的 chat 项目已经废弃，Cherry Studio 有幸延伸到了大量非技术群体的工作场景。
Cherry Studio 尝试性做了很多功能，比如知识库，MCP，联网搜索，翻译，绘图，包括 agent （我们把入口命名为工作），这是围绕着 AI 做更多事情的演化链展开的。（但 1.X 整合不佳，的确摆脱不了堆砌的诟病）
目前没做的，比如视频生成，情感陪伴，群聊，社区，酒馆…从这一点上来看，我认为 Cherry Studio 的定位是清晰的。
“让程序只做一件事”这是 Unix 的经典哲学，相信也是很多技术用户所信奉的理念，从这一点上看，Cherry Studio 又是臃肿的。
我对这件事有三点思考：
- 非技术背景的东西，每个软件处理单一任务，对普通用户来讲，挑选和辨别的压力太大了，他们希望在一个软件中解决所有问题；
- “让程序只做一件事”这个理念内化到了 agent 中，一个工具只解决一个问题，agent 解决所有问题。
- 未来软件大概都会消失，只剩 agent。Cherry Studio 的界面也会消失，但是 AI 驱动的通用任务完成的范式会无处不在，这是为什么要做 agent。
通用 agent 才是 agent，我们今天也都只是在路上而已。
关于 Cherry Studio 的接下来的发展，我们依然遵循 build in public 的原则，所有的 roadmap 都在 GitHub 上管理并展示：Milestone kanban · GitHub
几点大家提到比较关注，或者吐槽的问题，我尝试统一回答一下：
- 臃肿问题一，视觉与交互复杂：尝试引入“模块禁用”的功能，禁用功能后可以释放相关的资源占用，做到模块隔离，按需加载。目标做到可以只剩一下 chat 窗口，回归到最轻量化的状态，自由交给用户；
- 臃肿问题二，软件沉重卡顿：2.0 版本重构已经完成，接下来会重点，持续地进行性能优化，内存，CPU，存储的占用，流畅度，都是优化的重点目标，性能上不会妥协，而且在 ai coding 的帮助下，这个目标达成容易了一些。但值得一提的是，agent 涉及大量工具调用，第三方工具性能不可控，但也许会引入类似于任务管理器的模块，来监测性能消耗；
- 臃肿问题三，安装包体积大： electron 的软件确实挺难避免，小团队也很难有余力开发不同平台的原生版本（事实上，codex 也从原生软件换到了 electron ）。如果需要用户打各种补丁，会给非技术用户带来很高的门槛。提供开箱可用的体验，必然意味着更高的集成度，这也是为什么飞书微信今天的安装包都 500M 朝上了。但我们集成的所有的组件，都在开源仓库可以看到，大家可以审阅。以及 2.0 的设置中，也独立了一个依赖的模块，可以动态管理依赖的安装。
- agent 功能：agent 这条路我们确实会继续走下去，不是因为它是热点，而是因为我们认为这是 Cherry Studio 长期价值所在——最大化模型的能力。2.0 版本中解决了 Windows 依赖 Git bash 的问题，非视觉模型读取图片的问题，非 Anthropic 端点兼容的问题。接下来很快会看到 Pi agent 底层兼容，可以获得更轻量，更灵活的 agent 体验。会持续降低 agent 的使用门槛，和运行效果。（别劝了，铁了心了）
- Bug 多，解决慢：之前 Cherry Studio 的迭代依赖开源社区，这带来了开放和创新的氛围，但是代码质量一致性，开发者投入的持续性，都不容易保证，这也是开源社区快速发展的两面性。好在现在 Cherry Studio 全职开发人员的资源在确定性提高，会体系化，快节奏地解决这些 Bug。而且之前的功能模块，在这次重构中，几乎从头写了一遍。
- 演进原则：Codex 的迭代方式有很好的参考价值，看起来越来越简单，但是内在的核心越来越强大，这是值得学习的哲学。Cherry Studio 的目标亦是如此，迭代不是在界面上增加越来越多的入口，交互，按钮，而是希望拿掉一个可见的按钮，降低用户的一个交互负担，但给用户带来两倍的功能价值。Cherry Studio 在这方面做得还不好，复杂度必须得隐藏起来。
在 Cherry Studio 的 roadmap 中还有 200 多项功能待开发，我们希望能做出高质量，有功能价值的产品，带给大家。这个不容易，我们还在努力。
Cherry Studio 从开源到现在，得快两年了，AI 行业发展很快，恍如隔世。
希望 Cherry Studio 能不辜负这个伟大的时代，也不辜负关注，曾经关注，支持，提出真切批评，宝贵建议，以及未来继续用 Cherry Studio 的朋友们。
（全文手打）
70 个赞
对了，移动端会在 2.0 版本稳定之后，投入全职的研发人员。
5 个赞
确实很长时间都没有打开过这个软件了，前期agent工具不多的时候，还是经常用的
认真看完了，比较感兴趣的是“大量非技术群体的工作场景” 会是什么？
pc端 2.0上线了么 怎么更新了还是1.9.13呢
1 个赞
我觉得还是要思考一下和 codex 这类工作台 agent 软件的差异点在哪里
1 个赞
就是白领办公的场景，不是 coding，但也不是纯 chat
1 个赞
在灰度推送，官网和 GitHub 已经上了下载链接
我使用的场景主要是问一些问题，然后经常会问多个模型，然后来确定一些东西，或者说获取比较准确的结果，后续希望能够增加一个双列的显示提问，一次同时向2个模型发送
这个有的呀，有多模型同时问答的功能
感谢回答。那我其实有点想问的是，对于非技术背景的使用群体，比如你说到的白领办公的场景，他们会不会更倾向于使用比如wb这些更加成熟的大厂产品？
找到了，居然是在一个 @ 符号上。
不要往移动端加奇奇怪怪的 agent 了，你加一点点 mcp 我就觉得很好了。agent 不需要太多了。