Cherry Studio 中的依赖式并行化用 better-all 消除 Promise 瀑布流【免费下载链接】cherry-studioAI productivity studio with smart chat, autonomous agents, and 300 assistants. Unified access to frontier LLMs项目地址: https://gitcode.com/GitHub_Trending/ch/cherry-studio导读在 React / Next.js 应用以及基于 Electron 主进程的 Cherry Studio 这类 AI 生产力应用中多个异步操作之间往往存在部分依赖关系fetchConfig()完全不依赖fetchUser()而fetchProfile(user.id)必须等用户数据就绪后才能发起。如果使用朴素的await顺序编码或不当的Promise.all分组就会形成请求瀑布流waterfall白白浪费大量等待时间。本文基于 .agents/skills/vercel-react-best-practices/rules/async-dependencies.md 展开讲解依赖式并行化的标准做法——better-all库的all()用法、不引入额外依赖的原生替代方案并结合 Cherry Studio 仓库中的真实源码说明这些模式在主进程、Agent 会话等场景中的落地方式。读完你将掌握识别部分依赖型异步链、用最小改动把串行等待改写为最大并行、以及在复杂依赖图中保持代码可读性的具体技巧。一、规则背景它在整个最佳实践体系中的位置该规则来自仓库内置的 Vercel React 最佳实践 skill.agents/skills/vercel-react-best-practices/SKILL.md。整个 skill 共含 62 条规则、8 大类别按影响力排序其中第一优先级类别就是消除瀑布流Eliminating Waterfallsimpact 标记为CRITICAL预期可带来 2–10 倍的性能提升。该类别的 5 条规则分别是规则文件主题定位async-parallel.md无依赖操作用Promise.all()并行最基础的并行async-dependencies.md本文主题部分依赖操作用better-all最大化并行部分依赖场景async-defer-await.md把await推迟到真正使用它的分支避免阻塞无用路径async-api-routes.mdAPI 路由中先启动 Promise后 await服务端路由场景async-suspense-boundaries.md用 Suspense 边界流式渲染渲染层场景本文讨论的async-dependencies.md正是其中专门解决**部分依赖**partial dependencies这一中间态问题的规则位于已编译总文档 .agents/skills/vercel-react-best-practices/AGENTS.md 的 1.2 节### 1.2 Dependency-Based Parallelization。判断标准两个操作相互独立、可同时发出→ 用Promise.all()一个操作强依赖另一个的结果、且无其他可并行项→ 只能串行 await操作之间存在部分依赖有一部分可并行有一部分必须等待→ 本文的依赖式并行化模式。二、问题演示profile 在等待 config 时被白白阻塞先看原始规则给出的错误示例const [user, config] await Promise.all([ fetchUser(), fetchConfig() ]) const profile await fetchProfile(user.id)这段代码的时间线是这样的fetchUser()与fetchConfig()同时发起彼此没有依赖关系这部分已经做到了并行Promise.all会同时等待两者全部完成也就是说profile请求必须等到config也返回之后才能开始但实际上fetchProfile(user.id)只依赖user与config毫无关系。于是产生了一个非必要串行窗口即使config响应很慢例如配置服务抖动、网络分区profile的发出时间也会被拖后整个页面的关键数据用户资料因此延迟。这就是典型的部分依赖型瀑布流——数据链上多一个无关的阻塞节点端到端耗时就被拉长一段。三、解决方案一用 better-all 的all()自动最大化并行原规则给出的正确做法是引入better-allimport { all } from better-all const { user, config, profile } await all({ async user() { return fetchUser() }, async config() { return fetchConfig() }, async profile() { return fetchProfile((await this.$.user).id) } })better-all的核心设计理念是让每个任务在最早可能的时刻自动启动It automatically starts each task at the earliest possible momentuser、config两个任务没有任何前置依赖因此all()调用一进入就同时启动profile声明了对user的依赖通过this.$.user读取依赖任务的产物——注意这里的读取是按需 awaituser一旦完成profile立即开始执行不必等config最终解构出{ user, config, profile }三个结果调用方拿到的是全部完成后的对象但内部已经完成了最大程度的并行调度。this.$.xxx依赖声明语义all()接收一个对象其中每个属性是一个异步任务函数。任务函数内部通过this.$.key访问其他任务的返回值。$可以理解为任务结果注册表访问一个尚未完成的依赖时函数会被挂起直到该依赖完成访问已经完成的依赖则立即返回。这样开发者用同步式的属性读取语法就描述了异步依赖图调度器据此自动推导执行顺序把谁等谁的编排工作交给库来完成。四、解决方案二零依赖原生替代——先建 Promise后统一Promise.all()如果项目不想引入额外依赖或者团队希望保持依赖面最小原规则同时给出了不需要任何库的替代写法const userPromise fetchUser() const profilePromise userPromise.then(user fetchProfile(user.id)) const [user, config, profile] await Promise.all([ userPromise, fetchConfig(), profilePromise ])原理拆解第 1 行fetchUser()被调用时 Promise 立即进入 pending 状态网络请求马上发出不是等await才开始第 2 行在userPromise上链式.then()得到profilePromise。.then()是惰性回调注册fetchProfile会在user完成那一刻自动被调用——config是否完成、何时完成完全不影响这条链第 4–8 行最后用一次Promise.all()收口等待全部结果。这一模式的本质是先启动所有能启动的 Promise最后再 await 收口与原规则中create all the promises first, and doPromise.all()at the end的表述完全一致。它与better-all的差异在于维度better-all 的all()原生 Promise 链 Promise.all额外依赖需要安装better-all无依赖表达声明式this.$.user天然支持复杂依赖图命令式.then逐条链适合浅层依赖复杂依赖图A 依赖 B/CD 依赖 A…自动调度代码扁平手写链式代码易嵌套结果聚合解构对象解构数组注意顺序适用建议依赖关系多、链路复杂依赖层数 1–2 层、追求零依赖五、把规则放到更大的上下文两种并行工具的分工依赖式并行化并不是孤立的一条规则它是消除瀑布流类别中与Promise.all()并列互补的策略完全独立无任何交叉依赖的操作直接用 async-parallel.md 中的Promise.all()一行搞定const [user, posts, comments] await Promise.all([ fetchUser(), fetchPosts(), fetchComments() ])部分依赖本文独立部分立即并行、依赖部分尽早启动、按需等待即better-all或先 Promise 后收口模式API 路由 / Server Actions同样的思想也适用于服务端——async-api-routes.md 明确要求先启动独立的操作即使暂时不需要 await 它们。它的错误示例auth → config → data 三级串行与本文的 profile 示例如出一辙正确写法同样是提前把sessionPromise、configPromise创建出来再在需要时Promise.all收口并明确提及更复杂的依赖链请使用better-all见 Dependency-Based Parallelization。也就是说本文的规则正是 API 路由场景下复杂依赖链的终极解法推迟 await对于某些分支根本不需要该数据的场景如提前返回、权限检查失败还可以配合 async-defer-await.md把await移进真正使用它的分支避免阻塞本可立即返回的代码路径。三者组合使用就能把请求瀑布流压缩到依赖图的最长路径而不是所有操作的串行求和。六、仓库源码印证这些模式在 Cherry Studio 中的真实落地规则文档讲的是通用范式而 Cherry Studio 仓库Electron React/Next.js 技术栈的源码中能找到大量对应实现可以作为这部分依赖并行化、部分独立并行化在真实生产代码中的佐证。6.1 主进程 AI 服务独立操作的批量并行在 src/main/ai/AiService.ts 的图片生成流程中多个彼此独立的操作被并行化第 950 行experimental_download回调中对多个下载任务使用Promise.all(downloads.map(...))同时下载所有图片并转 base64第 998–1002 行生成结果落盘时const files await Promise.all(dataUrls.map((data) fileManager.createInternalEntry(...)))多个文件条目创建完全并行。这些都是完全独立操作 → Promise.all的直接应用与 async-parallel.md 的规则一一对应。6.2 Agent 提示词构建先并行解析路径再并行读取文件在 src/main/ai/agents/prompt.ts 的buildMemoriesSection方法第 230–254 行中出现了教科书式的两阶段并行const [soulPath, userPath, factPath] await Promise.all([ resolveFile(agentDataPath, SOUL.md), resolveFile(agentDataPath, USER.md), hasRealMemoryDirectory ? resolveFile(memoryDir, FACT.md) : Promise.resolve(undefined) ]) const [soulContent, userContent, factContent] await Promise.all([ soulPath ? this.readCachedFile(soulPath, agentDataPath) : Promise.resolve(undefined), userPath ? this.readCachedFile(userPath, agentDataPath) : Promise.resolve(undefined), factPath ? this.readCachedFile(factPath, agentDataPath) : Promise.resolve(undefined) ])第一阶段三个路径解析互不依赖一次Promise.all并行完成第二阶段三个文件读取基于第一阶段产物又互不依赖再次并行。这里factPath的读取有条件地依赖第一阶段是否解析出路径hasRealMemoryDirectory为假时直接Promise.resolve(undefined)但三个读文件任务之间仍是并行的——这正是独立部分尽量并行、依赖只作用于必要处思想的体现。6.3 Agent 会话运行时并发收口与容错在 src/main/ai/agentSession/AgentSessionRuntimeService.ts 中第 2201 行const flush Promise.all(accumulators.map((accumulator) accumulator.done)).then(...)多个后台流的累加器accumulator完成后统一收口再统一替换消息 parts——独立任务的并行等待 收口后处理第 704 行await Promise.all(reconciles)、第 963/1258/3138 行等多处使用Promise.allSettled做容错式并发收口不因单个失败而中断整体。对应测试 src/main/ai/agentSession/tests/AgentSessionRuntimeService.test.ts第 3419、3464 行也验证了并发关闭close行为的确定性。这些源码印证了并行化不是能用Promise.all就用还要根据失败语义选择all还是allSettled——这正是把规则落到生产代码时的重要补充。说明以上为对仓库源码的观察结果可作为规则模式的实现佐证Cherry Studio 的实际业务代码中是否直接引入better-all库从源码中未检索到依赖引用因此依赖式并行化在仓库内的形态以原生 Promise 链 Promise.all 收口为主——这恰好验证了原文档第四条Alternative without extra dependencies在真实项目中的可行性。七、适用边界与注意事项依赖式并行化并非无脑套用需要结合场景判断分清依赖关系只有真正部分依赖的操作才适合本模式。全部独立 →Promise.all严格串行且无其他可并行项 → 顺序await即可引入调度反而增加复杂度。失败语义Promise.all是快速失败——任一 Promise reject 立即 reject 整个结果。如果希望部分失败不阻断整体如批量落盘、批量关闭应改用Promise.allSettledCherry Studio 源码中多处如此使用。滥用Promise.all的风险当并行任务共享同一有限资源如同一个连接池、同一个 API 速率限制、同一条带宽时盲目并行可能引发资源争抢或限流。此时需要配合并发上限如分批Promise.all或信号量控制并行度。可读性权衡依赖链只有一层时先建 Promise 再收口很清晰依赖层数加深后手写.then链会迅速膨胀此时better-all的声明式写法更值得引入。与推迟await的组合如果某个分支根本不消费数据提前返回、权限校验失败应先应用 async-defer-await.md 把await移入分支避免为用不到的数据付出等待代价——两种优化方向可叠加。八、实践自查清单在提交代码前对照以下清单检查你的异步路径是否存在本可并行却被串行 await的操作对着时间线画一遍每个请求的发出时刻Promise.all分组的成员是否真的彼此独立本例中config就不该和profile绑在一起部分依赖场景是否采用了尽早启动 按需等待better-all或 Promise 先建后收口服务的失败语义是快速失败还是部分容忍选对all/allSettled了吗共享资源的并行度是否有上限控制相关资源规则原文.agents/skills/vercel-react-best-practices/rules/async-dependencies.md已编译总文档1.2 节.agents/skills/vercel-react-best-practices/AGENTS.mdSkill 总览.agents/skills/vercel-react-best-practices/SKILL.md相关规则async-parallel.md / async-api-routes.md / async-defer-await.md仓库实现佐证src/main/ai/AiService.ts图片并行下载/落盘、src/main/ai/agents/prompt.ts两阶段并行构建提示词、src/main/ai/agentSession/AgentSessionRuntimeService.ts并发收口与容错、src/main/ai/agentSession/tests/AgentSessionRuntimeService.test.ts并发行为测试【免费下载链接】cherry-studioAI productivity studio with smart chat, autonomous agents, and 300 assistants. Unified access to frontier LLMs项目地址: https://gitcode.com/GitHub_Trending/ch/cherry-studio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/12 16:54:57 · 阅读 1.2k Cherry Studio 中的依赖式并行化：用 better-all 消除 Promise 瀑布流
Cherry Studio 中的依赖式并行化用 better-all 消除 Promise 瀑布流【免费下载链接】cherry-studioAI productivity studio with smart chat, autonomous agents, and 300 assistants. Unified access to frontier LLMs项目地址: https://gitcode.com/GitHub_Trending/ch/cherry-studio导读在 React / Next.js 应用以及基于 Electron 主进程的 Cherry Studio 这类 AI 生产力应用中多个异步操作之间往往存在部分依赖关系fetchConfig()完全不依赖fetchUser()而fetchProfile(user.id)必须等用户数据就绪后才能发起。如果使用朴素的await顺序编码或不当的Promise.all分组就会形成请求瀑布流waterfall白白浪费大量等待时间。本文基于 .agents/skills/vercel-react-best-practices/rules/async-dependencies.md 展开讲解依赖式并行化的标准做法——better-all库的all()用法、不引入额外依赖的原生替代方案并结合 Cherry Studio 仓库中的真实源码说明这些模式在主进程、Agent 会话等场景中的落地方式。读完你将掌握识别部分依赖型异步链、用最小改动把串行等待改写为最大并行、以及在复杂依赖图中保持代码可读性的具体技巧。一、规则背景它在整个最佳实践体系中的位置该规则来自仓库内置的 Vercel React 最佳实践 skill.agents/skills/vercel-react-best-practices/SKILL.md。整个 skill 共含 62 条规则、8 大类别按影响力排序其中第一优先级类别就是消除瀑布流Eliminating Waterfallsimpact 标记为CRITICAL预期可带来 2–10 倍的性能提升。该类别的 5 条规则分别是规则文件主题定位async-parallel.md无依赖操作用Promise.all()并行最基础的并行async-dependencies.md本文主题部分依赖操作用better-all最大化并行部分依赖场景async-defer-await.md把await推迟到真正使用它的分支避免阻塞无用路径async-api-routes.mdAPI 路由中先启动 Promise后 await服务端路由场景async-suspense-boundaries.md用 Suspense 边界流式渲染渲染层场景本文讨论的async-dependencies.md正是其中专门解决**部分依赖**partial dependencies这一中间态问题的规则位于已编译总文档 .agents/skills/vercel-react-best-practices/AGENTS.md 的 1.2 节### 1.2 Dependency-Based Parallelization。判断标准两个操作相互独立、可同时发出→ 用Promise.all()一个操作强依赖另一个的结果、且无其他可并行项→ 只能串行 await操作之间存在部分依赖有一部分可并行有一部分必须等待→ 本文的依赖式并行化模式。二、问题演示profile 在等待 config 时被白白阻塞先看原始规则给出的错误示例const [user, config] await Promise.all([ fetchUser(), fetchConfig() ]) const profile await fetchProfile(user.id)这段代码的时间线是这样的fetchUser()与fetchConfig()同时发起彼此没有依赖关系这部分已经做到了并行Promise.all会同时等待两者全部完成也就是说profile请求必须等到config也返回之后才能开始但实际上fetchProfile(user.id)只依赖user与config毫无关系。于是产生了一个非必要串行窗口即使config响应很慢例如配置服务抖动、网络分区profile的发出时间也会被拖后整个页面的关键数据用户资料因此延迟。这就是典型的部分依赖型瀑布流——数据链上多一个无关的阻塞节点端到端耗时就被拉长一段。三、解决方案一用 better-all 的all()自动最大化并行原规则给出的正确做法是引入better-allimport { all } from better-all const { user, config, profile } await all({ async user() { return fetchUser() }, async config() { return fetchConfig() }, async profile() { return fetchProfile((await this.$.user).id) } })better-all的核心设计理念是让每个任务在最早可能的时刻自动启动It automatically starts each task at the earliest possible momentuser、config两个任务没有任何前置依赖因此all()调用一进入就同时启动profile声明了对user的依赖通过this.$.user读取依赖任务的产物——注意这里的读取是按需 awaituser一旦完成profile立即开始执行不必等config最终解构出{ user, config, profile }三个结果调用方拿到的是全部完成后的对象但内部已经完成了最大程度的并行调度。this.$.xxx依赖声明语义all()接收一个对象其中每个属性是一个异步任务函数。任务函数内部通过this.$.key访问其他任务的返回值。$可以理解为任务结果注册表访问一个尚未完成的依赖时函数会被挂起直到该依赖完成访问已经完成的依赖则立即返回。这样开发者用同步式的属性读取语法就描述了异步依赖图调度器据此自动推导执行顺序把谁等谁的编排工作交给库来完成。四、解决方案二零依赖原生替代——先建 Promise后统一Promise.all()如果项目不想引入额外依赖或者团队希望保持依赖面最小原规则同时给出了不需要任何库的替代写法const userPromise fetchUser() const profilePromise userPromise.then(user fetchProfile(user.id)) const [user, config, profile] await Promise.all([ userPromise, fetchConfig(), profilePromise ])原理拆解第 1 行fetchUser()被调用时 Promise 立即进入 pending 状态网络请求马上发出不是等await才开始第 2 行在userPromise上链式.then()得到profilePromise。.then()是惰性回调注册fetchProfile会在user完成那一刻自动被调用——config是否完成、何时完成完全不影响这条链第 4–8 行最后用一次Promise.all()收口等待全部结果。这一模式的本质是先启动所有能启动的 Promise最后再 await 收口与原规则中create all the promises first, and doPromise.all()at the end的表述完全一致。它与better-all的差异在于维度better-all 的all()原生 Promise 链 Promise.all额外依赖需要安装better-all无依赖表达声明式this.$.user天然支持复杂依赖图命令式.then逐条链适合浅层依赖复杂依赖图A 依赖 B/CD 依赖 A…自动调度代码扁平手写链式代码易嵌套结果聚合解构对象解构数组注意顺序适用建议依赖关系多、链路复杂依赖层数 1–2 层、追求零依赖五、把规则放到更大的上下文两种并行工具的分工依赖式并行化并不是孤立的一条规则它是消除瀑布流类别中与Promise.all()并列互补的策略完全独立无任何交叉依赖的操作直接用 async-parallel.md 中的Promise.all()一行搞定const [user, posts, comments] await Promise.all([ fetchUser(), fetchPosts(), fetchComments() ])部分依赖本文独立部分立即并行、依赖部分尽早启动、按需等待即better-all或先 Promise 后收口模式API 路由 / Server Actions同样的思想也适用于服务端——async-api-routes.md 明确要求先启动独立的操作即使暂时不需要 await 它们。它的错误示例auth → config → data 三级串行与本文的 profile 示例如出一辙正确写法同样是提前把sessionPromise、configPromise创建出来再在需要时Promise.all收口并明确提及更复杂的依赖链请使用better-all见 Dependency-Based Parallelization。也就是说本文的规则正是 API 路由场景下复杂依赖链的终极解法推迟 await对于某些分支根本不需要该数据的场景如提前返回、权限检查失败还可以配合 async-defer-await.md把await移进真正使用它的分支避免阻塞本可立即返回的代码路径。三者组合使用就能把请求瀑布流压缩到依赖图的最长路径而不是所有操作的串行求和。六、仓库源码印证这些模式在 Cherry Studio 中的真实落地规则文档讲的是通用范式而 Cherry Studio 仓库Electron React/Next.js 技术栈的源码中能找到大量对应实现可以作为这部分依赖并行化、部分独立并行化在真实生产代码中的佐证。6.1 主进程 AI 服务独立操作的批量并行在 src/main/ai/AiService.ts 的图片生成流程中多个彼此独立的操作被并行化第 950 行experimental_download回调中对多个下载任务使用Promise.all(downloads.map(...))同时下载所有图片并转 base64第 998–1002 行生成结果落盘时const files await Promise.all(dataUrls.map((data) fileManager.createInternalEntry(...)))多个文件条目创建完全并行。这些都是完全独立操作 → Promise.all的直接应用与 async-parallel.md 的规则一一对应。6.2 Agent 提示词构建先并行解析路径再并行读取文件在 src/main/ai/agents/prompt.ts 的buildMemoriesSection方法第 230–254 行中出现了教科书式的两阶段并行const [soulPath, userPath, factPath] await Promise.all([ resolveFile(agentDataPath, SOUL.md), resolveFile(agentDataPath, USER.md), hasRealMemoryDirectory ? resolveFile(memoryDir, FACT.md) : Promise.resolve(undefined) ]) const [soulContent, userContent, factContent] await Promise.all([ soulPath ? this.readCachedFile(soulPath, agentDataPath) : Promise.resolve(undefined), userPath ? this.readCachedFile(userPath, agentDataPath) : Promise.resolve(undefined), factPath ? this.readCachedFile(factPath, agentDataPath) : Promise.resolve(undefined) ])第一阶段三个路径解析互不依赖一次Promise.all并行完成第二阶段三个文件读取基于第一阶段产物又互不依赖再次并行。这里factPath的读取有条件地依赖第一阶段是否解析出路径hasRealMemoryDirectory为假时直接Promise.resolve(undefined)但三个读文件任务之间仍是并行的——这正是独立部分尽量并行、依赖只作用于必要处思想的体现。6.3 Agent 会话运行时并发收口与容错在 src/main/ai/agentSession/AgentSessionRuntimeService.ts 中第 2201 行const flush Promise.all(accumulators.map((accumulator) accumulator.done)).then(...)多个后台流的累加器accumulator完成后统一收口再统一替换消息 parts——独立任务的并行等待 收口后处理第 704 行await Promise.all(reconciles)、第 963/1258/3138 行等多处使用Promise.allSettled做容错式并发收口不因单个失败而中断整体。对应测试 src/main/ai/agentSession/tests/AgentSessionRuntimeService.test.ts第 3419、3464 行也验证了并发关闭close行为的确定性。这些源码印证了并行化不是能用Promise.all就用还要根据失败语义选择all还是allSettled——这正是把规则落到生产代码时的重要补充。说明以上为对仓库源码的观察结果可作为规则模式的实现佐证Cherry Studio 的实际业务代码中是否直接引入better-all库从源码中未检索到依赖引用因此依赖式并行化在仓库内的形态以原生 Promise 链 Promise.all 收口为主——这恰好验证了原文档第四条Alternative without extra dependencies在真实项目中的可行性。七、适用边界与注意事项依赖式并行化并非无脑套用需要结合场景判断分清依赖关系只有真正部分依赖的操作才适合本模式。全部独立 →Promise.all严格串行且无其他可并行项 → 顺序await即可引入调度反而增加复杂度。失败语义Promise.all是快速失败——任一 Promise reject 立即 reject 整个结果。如果希望部分失败不阻断整体如批量落盘、批量关闭应改用Promise.allSettledCherry Studio 源码中多处如此使用。滥用Promise.all的风险当并行任务共享同一有限资源如同一个连接池、同一个 API 速率限制、同一条带宽时盲目并行可能引发资源争抢或限流。此时需要配合并发上限如分批Promise.all或信号量控制并行度。可读性权衡依赖链只有一层时先建 Promise 再收口很清晰依赖层数加深后手写.then链会迅速膨胀此时better-all的声明式写法更值得引入。与推迟await的组合如果某个分支根本不消费数据提前返回、权限校验失败应先应用 async-defer-await.md 把await移入分支避免为用不到的数据付出等待代价——两种优化方向可叠加。八、实践自查清单在提交代码前对照以下清单检查你的异步路径是否存在本可并行却被串行 await的操作对着时间线画一遍每个请求的发出时刻Promise.all分组的成员是否真的彼此独立本例中config就不该和profile绑在一起部分依赖场景是否采用了尽早启动 按需等待better-all或 Promise 先建后收口服务的失败语义是快速失败还是部分容忍选对all/allSettled了吗共享资源的并行度是否有上限控制相关资源规则原文.agents/skills/vercel-react-best-practices/rules/async-dependencies.md已编译总文档1.2 节.agents/skills/vercel-react-best-practices/AGENTS.mdSkill 总览.agents/skills/vercel-react-best-practices/SKILL.md相关规则async-parallel.md / async-api-routes.md / async-defer-await.md仓库实现佐证src/main/ai/AiService.ts图片并行下载/落盘、src/main/ai/agents/prompt.ts两阶段并行构建提示词、src/main/ai/agentSession/AgentSessionRuntimeService.ts并发收口与容错、src/main/ai/agentSession/tests/AgentSessionRuntimeService.test.ts并发行为测试【免费下载链接】cherry-studioAI productivity studio with smart chat, autonomous agents, and 300 assistants. Unified access to frontier LLMs项目地址: https://gitcode.com/GitHub_Trending/ch/cherry-studio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考