Cherry Studio 知识库索引崩溃自愈机制解析重启后自动恢复未完成任务【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio知识库索引任务已从内存态演进为持久化 启动恢复模型任何时刻正在进行的索引任务都会被写入磁盘作业表应用在优雅退出、崩溃或系统关机后重新启动时约 60 秒内自动完成恢复用户无需任何操作。本文以 Cherry Studio 的变更说明文档v2-refactor-temp/docs/breaking-changes/2026-05-20-knowledge-job-auto-recovery.md为主线结合JobManager、知识库任务处理器与摄取服务的真实源码拆解断点续跑的完整实现链路并说明并发、重试、超时等新语义对使用者的实际影响。一、变更背景从永久卡死到自动收敛在引入自动恢复之前知识库索引存在一个长期痛点凡是在退出/崩溃瞬间尚未完成的索引任务会永久停留在processing状态用户必须手动重新触发 reindex 才能让它结束。原因在于任务状态仅存在于内存中进程一结束既没有可靠的半途状态落盘也没有启动时的清算环节。本次变更的核心是两点持久化每一个 in-flight进行中任务都以作业行的形式持久化到磁盘数据库启动恢复应用重启后作业系统对上一进程遗留的非终止作业统一执行恢复策略知识库条目侧再做一次状态兜底清扫。其效果正如变更说明所描述退出时仍在运行的索引任务会在下次启动后约 1 分钟被恢复流程接住——不再需要用户手动介入去解卡。二、恢复的触发时机JobManager.onAllReady与 60 秒静默窗口恢复流程不是进程一启动就立刻执行的而是由作业编排器JobManager在生命周期阶段onAllReady触发。源码位于 src/main/core/job/JobManager.ts// src/main/core/job/JobManager.ts const JOB_MANAGER_STARTUP_DELAY_MS 60_000 protected override onAllReady(): void { const handle setTimeout(() { if (this._isShuttingDown) { /* 静默窗口内收到关闭信号则跳过 */ return } this._recoveryDone this.runStartupRecoveryFlow() }, JOB_MANAGER_STARTUP_DELAY_MS) this.registerDisposable(() clearTimeout(handle)) }几个关键设计对应 JobManager.ts 的注释onAllReady而非onReadyonReady只启动 GC 清扫与延迟任务晋升等不依赖业务 handler 的维护逻辑凡是需要 handler 注册表就绪的恢复/调度工作统一推迟到onAllReady此时所有业务服务的onInit/onReady已执行完毕registerHandler必然已完成。60 秒静默窗口JOB_MANAGER_STARTUP_DELAY_MS 60_000让冷启动 IO数据库预热、窗口绘制、前端 bootstrap先安定下来再叠加调度工作避免启动瞬间资源争抢。这就是变更说明中冷启动约 60 秒后才恢复索引的直接来源。静默窗口内可被关闭打断若恢复定时器触发前应用已开始关闭_isShuttingDown恢复流程直接跳过onStop会await已启动的_recoveryDone保证关闭与恢复不会互相踩踏。写静默pause支持断点续跑恢复流程被划分为多个步骤任何一步遇到写静默都会记录游标RecoveryResumePoint待最后一个 pause hold 释放后从断点重放保证恰好一次的补跑语义。三、五步恢复流水线reset → resurrect → catch-up → arm → dispatch启动恢复并非简单地把所有挂起任务重新入队而是一套有严格顺序的五步流水线JobManager.tsconst RECOVERY_STEPS [reset, resurrect, catch-up, arm, dispatch] as const步骤作用说明reset按 handler 策略清算非终止行调用runStartupRecovery处理 cancelRequested 覆盖、abandon/retry/singleton 三种策略与孤儿作业resurrect复活队列为遗留的非终止作业按(queue, type)重建内存队列保证 pending 行能在下一 tick 被派发延迟行也能随promoteDelayedDue晋升catch-up补跑错过的调度detectAndDispatchOverdue读取 DB 中的lastRun/nextRun把关机期间错过的计划任务补入队arm重新武装调度重建 cron/interval/once 调度条目必须先补跑再武装避免 cron 首次自然触发与补跑入队产生竞态dispatch踢动各队列dispatchAll让被 reset 的 pending 行立即开始执行而不是等下一次入队其中reset是断点续跑的枢纽单独拆解如下。四、声明式恢复策略abandon / retry / singletonrunStartupRecovery的实现位于 src/main/core/job/runtime/recovery.ts它对每个已注册 handler 的非终止作业依次执行cancelRequestedtrue优先于一切策略凡是被用户请求取消但仍残留的 running/delayed/pending 行一律以Cancelled by startup recovery收尾防止取消事务与崩溃之间的竞态让行被悄悄复活按 handler 声明的recovery策略处理其余行abandon直接取消所有非终止行用户退出时明确不继续的任务不重新执行retry把running重置为pending保留delayed重启后自动重跑singleton只保留createdAt最新的那一个重置为 pending其余全部取消保证同类型任务单例语义孤儿作业兜底handler 已不再注册的非终止作业running/delayed/pending全部取消避免行无限泄漏。一个容易被忽略的细节是in-flight 排除恢复只清算上一进程的遗留物。如果某个作业是在 60 秒静默窗口内由本进程新入队且仍在执行isJobInFlight谓词会把它从恢复扫描中剔除防止 retry/singleton 把它二次派发同一任务跑两遍或 abandon/cancelRequested 与存活执行产生竞态写。见 recovery.ts。五、知识库任务的恢复语义为什么是收敛而非续跑回到知识库模块本身。知识库共注册五种作业类型见 src/main/features/knowledge/tasks/jobTypes.tsknowledge.prepare-root目录/sitemap 扫描展开knowledge.index-documents单个文件/URL/笔记的切片与嵌入knowledge.check-file-processing-result轮询文件处理任务结果knowledge.delete-subtree删除子树knowledge.reindex-subtree重建子树索引。有意思的是知识库的索引类 handler 全部声明recovery: abandon例如 prepareRootJobHandler.ts 与 indexDocumentsJobHandler.ts 中都写着同一段注释// Dont auto-resume on restart — a deliberate app quit must not re-spend the // embedding API; the item is parked at failed and reindexed on demand. recovery: abandon,这意味着变更说明中自动恢复的准确语义是作业层面重启后遗留的非终止作业不会再卡死而是被恢复流程确定性地收尾取消并记录cancelled终态条目层面KnowledgeService.onAllReady调用ingestionService.recoverInterruptedItems()KnowledgeService.ts把残留的processing/preparing条目通过failInterruptedItems统一标记为failed错误码为KNOWLEDGE_ITEM_ERROR_INDEXING_INTERRUPTED见 KnowledgeIngestionService.ts 的实现注释。这样设计是刻意为之一次被中断的索引任务若在重启后自动重跑会无谓地再次消耗可能付费的embedding API。因此系统选择收敛到可再次操作的状态——条目停在failed用户可从右键菜单手动 Reindex 完成。这也正好解释了变更说明中的两句话强制退出后processing状态可能短暂残留下次启动后恢复流程跑完即自愈。 若启动后约 1 分钟某个条目仍卡住按以往方式从右键菜单执行 Reindex 即可。与此配合的还有两层自愈保障作业执行期间的onSettled回调会把失败的条目翻转成failed见 settled.ts 的markKnowledgeItemFailedOnSettledrecoverInterruptedItems只是进程先于 onSettled 退出场景下的启动期安全网。六、并发与重试的新语义变更说明列出了两个对使用者可见的行为变化均能在源码中得到印证1. 并发从全局共享 5 槽 → 每库 5 槽 全局 50 槽上限知识库的 handler 都设置了defaultConcurrency: 5prepareRootJobHandler.ts、indexDocumentsJobHandler.ts而队列名是按知识库隔离的defaultQueue: (input) knowledgeQueueName(toKnowledgeBaseId(input.baseId)),也就是说每个知识库拥有独立的 5 并发槽位多个库并行导入时互不挤占而JobManager全局并发上限固定为DEFAULT_GLOBAL_MAX_CONCURRENCY 50JobManager.ts作为跨库的总闸门。这正是变更说明5 slots per base with a 50-slot global cap的实现多个库同时导入时总体吞吐因此更快。需要说明的是从当前源码结构看全局并发上限是写死的常量未暴露为可配置项。2. 重试瞬时嵌入失败指数退避重试最多 3 次知识库 handler 统一声明了重试策略但两个核心 handler 的节奏略有差异HandlermaxAttemptsbackoffbaseDelayMsmaxDelayMsknowledge.prepare-rootprepareRootJobHandler.ts3exponential200060 000knowledge.index-documentsindexDocumentsJobHandler.ts3exponential100030 000JobManager的默认重试策略未显式声明时的兜底为maxAttempts: 3, backoff: exponential, baseDelayMs: 1000, maxDelayMs: 60_000JobManager.ts。因此瞬时嵌入失败会以指数退避自动重试最多 3 次之后才把条目标记为failed。七、超时上限prepare-root 10 分钟、index-leaf 的演进变更说明记录prepare-root目录/sitemap 扫描作业有 10 分钟墙钟上限index-leaf单文件/URL/笔记嵌入作业有 5 分钟墙钟上限。当前仓库源码中prepareRootJobHandlerdefaultTimeoutMs: 10 * 60 * 100010 分钟——与说明一致indexDocumentsJobHandlerdefaultTimeoutMs: 30 * 60 * 100030 分钟——与说明记录的 5 分钟存在差异。从变更说明如果遥测显示大文档用户频繁命中超时应提高defaultTimeoutMs而不是回退该机制的演进指引来看可以推断 index-leaf 的超时上限在发布后已被上调从 5 分钟放宽到 30 分钟以缓解慢速 embedding 端点下大文件的超时问题。JobManager对该超时以JobHandlerTimeoutError哨兵异常中断 handlerJobManager.ts而不是依赖对错误消息字符串的匹配避免误判。需要提醒的是超时是墙钟时间wall-clock涵盖读取、切片、嵌入全流程。对超大单文件 慢速 embedding 端点这一组合即使放宽到 30 分钟超时风险依然存在而这正是设计上宁可失败、不可无限挂起的取舍——失败后可重试挂起则无法自愈。八、边界情况与升级路径强制退出后的短暂残留processing状态在强杀进程后可能短暂保留下次启动恢复流程完成后即被清为failed属预期行为。v1 → v2 升级例外升级时正处于 in-flight 状态的已迁移知识库由KnowledgeMigrator映射为idle/failed保持 v2 既有行为不变自动恢复仅覆盖 v2 → v2 的重启。升级场景下的条目仍需用户手动 reindex。关闭瞬间的排空JobManager.onStop会等待 in-flight 作业排空上限SERVICE_STOP_TIMEOUT_MS - 500超时则记录警告pending jobs will be recovered on next start——这句日志正是整个机制闭环的注脚优雅退出没来得及干完的活下次启动交给恢复流程。九、开发者视角如何验证与调整测试覆盖作业层的恢复逻辑有独立的单测/集成测试见 src/main/core/job/testsJobManager.integration.test.ts、JobManager.schedule.test.ts、JobManager.smoke.test.ts知识库 handler 侧的恢复与收尾行为见 src/main/features/knowledge/tasks/tests如prepareRootJobHandler.test.ts、indexDocumentsJobHandler.test.ts、reindexSubtreeJobHandler.test.ts以及 src/main/features/knowledge/ingestion/tests/statusCleanup.integration.test.ts。调参入口若需要调整某个任务类型的超时或重试策略改对应 handler 的defaultTimeoutMs/defaultRetryPolicy即可并发调整则改defaultConcurrency注意不要超过全局 50 槽上限。架构背景完整作业系统架构四层锁模型、handler 编写契约可查阅 docs/references/job-and-scheduler/overview.md 与 docs/references/job-and-scheduler/handler-authoring.md。十、小结Cherry Studio 的这项变更把知识库索引从内存态 人工解卡推进到持久化 启动自动收敛JobManager在onAllReady后约 60 秒执行五步恢复流水线按 handler 声明的 abandon/retry/singleton 策略清算遗留作业知识库条目侧以recoverInterruptedItems兜底清除永久 spinner并发从全局共享池演化为每库 5 槽 全局 50 槽嵌入失败以指数退避重试 3 次所有任务都有墙钟超时上限。对普通用户而言结果是退出前在跑的索引重启后不再卡死对开发者而言这是一套把半途状态显式建模、可恢复、可测试的作业编排范式。【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cherry Studio 知识库索引崩溃自愈机制解析：重启后自动恢复未完成任务
Cherry Studio 知识库索引崩溃自愈机制解析重启后自动恢复未完成任务【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio知识库索引任务已从内存态演进为持久化 启动恢复模型任何时刻正在进行的索引任务都会被写入磁盘作业表应用在优雅退出、崩溃或系统关机后重新启动时约 60 秒内自动完成恢复用户无需任何操作。本文以 Cherry Studio 的变更说明文档v2-refactor-temp/docs/breaking-changes/2026-05-20-knowledge-job-auto-recovery.md为主线结合JobManager、知识库任务处理器与摄取服务的真实源码拆解断点续跑的完整实现链路并说明并发、重试、超时等新语义对使用者的实际影响。一、变更背景从永久卡死到自动收敛在引入自动恢复之前知识库索引存在一个长期痛点凡是在退出/崩溃瞬间尚未完成的索引任务会永久停留在processing状态用户必须手动重新触发 reindex 才能让它结束。原因在于任务状态仅存在于内存中进程一结束既没有可靠的半途状态落盘也没有启动时的清算环节。本次变更的核心是两点持久化每一个 in-flight进行中任务都以作业行的形式持久化到磁盘数据库启动恢复应用重启后作业系统对上一进程遗留的非终止作业统一执行恢复策略知识库条目侧再做一次状态兜底清扫。其效果正如变更说明所描述退出时仍在运行的索引任务会在下次启动后约 1 分钟被恢复流程接住——不再需要用户手动介入去解卡。二、恢复的触发时机JobManager.onAllReady与 60 秒静默窗口恢复流程不是进程一启动就立刻执行的而是由作业编排器JobManager在生命周期阶段onAllReady触发。源码位于 src/main/core/job/JobManager.ts// src/main/core/job/JobManager.ts const JOB_MANAGER_STARTUP_DELAY_MS 60_000 protected override onAllReady(): void { const handle setTimeout(() { if (this._isShuttingDown) { /* 静默窗口内收到关闭信号则跳过 */ return } this._recoveryDone this.runStartupRecoveryFlow() }, JOB_MANAGER_STARTUP_DELAY_MS) this.registerDisposable(() clearTimeout(handle)) }几个关键设计对应 JobManager.ts 的注释onAllReady而非onReadyonReady只启动 GC 清扫与延迟任务晋升等不依赖业务 handler 的维护逻辑凡是需要 handler 注册表就绪的恢复/调度工作统一推迟到onAllReady此时所有业务服务的onInit/onReady已执行完毕registerHandler必然已完成。60 秒静默窗口JOB_MANAGER_STARTUP_DELAY_MS 60_000让冷启动 IO数据库预热、窗口绘制、前端 bootstrap先安定下来再叠加调度工作避免启动瞬间资源争抢。这就是变更说明中冷启动约 60 秒后才恢复索引的直接来源。静默窗口内可被关闭打断若恢复定时器触发前应用已开始关闭_isShuttingDown恢复流程直接跳过onStop会await已启动的_recoveryDone保证关闭与恢复不会互相踩踏。写静默pause支持断点续跑恢复流程被划分为多个步骤任何一步遇到写静默都会记录游标RecoveryResumePoint待最后一个 pause hold 释放后从断点重放保证恰好一次的补跑语义。三、五步恢复流水线reset → resurrect → catch-up → arm → dispatch启动恢复并非简单地把所有挂起任务重新入队而是一套有严格顺序的五步流水线JobManager.tsconst RECOVERY_STEPS [reset, resurrect, catch-up, arm, dispatch] as const步骤作用说明reset按 handler 策略清算非终止行调用runStartupRecovery处理 cancelRequested 覆盖、abandon/retry/singleton 三种策略与孤儿作业resurrect复活队列为遗留的非终止作业按(queue, type)重建内存队列保证 pending 行能在下一 tick 被派发延迟行也能随promoteDelayedDue晋升catch-up补跑错过的调度detectAndDispatchOverdue读取 DB 中的lastRun/nextRun把关机期间错过的计划任务补入队arm重新武装调度重建 cron/interval/once 调度条目必须先补跑再武装避免 cron 首次自然触发与补跑入队产生竞态dispatch踢动各队列dispatchAll让被 reset 的 pending 行立即开始执行而不是等下一次入队其中reset是断点续跑的枢纽单独拆解如下。四、声明式恢复策略abandon / retry / singletonrunStartupRecovery的实现位于 src/main/core/job/runtime/recovery.ts它对每个已注册 handler 的非终止作业依次执行cancelRequestedtrue优先于一切策略凡是被用户请求取消但仍残留的 running/delayed/pending 行一律以Cancelled by startup recovery收尾防止取消事务与崩溃之间的竞态让行被悄悄复活按 handler 声明的recovery策略处理其余行abandon直接取消所有非终止行用户退出时明确不继续的任务不重新执行retry把running重置为pending保留delayed重启后自动重跑singleton只保留createdAt最新的那一个重置为 pending其余全部取消保证同类型任务单例语义孤儿作业兜底handler 已不再注册的非终止作业running/delayed/pending全部取消避免行无限泄漏。一个容易被忽略的细节是in-flight 排除恢复只清算上一进程的遗留物。如果某个作业是在 60 秒静默窗口内由本进程新入队且仍在执行isJobInFlight谓词会把它从恢复扫描中剔除防止 retry/singleton 把它二次派发同一任务跑两遍或 abandon/cancelRequested 与存活执行产生竞态写。见 recovery.ts。五、知识库任务的恢复语义为什么是收敛而非续跑回到知识库模块本身。知识库共注册五种作业类型见 src/main/features/knowledge/tasks/jobTypes.tsknowledge.prepare-root目录/sitemap 扫描展开knowledge.index-documents单个文件/URL/笔记的切片与嵌入knowledge.check-file-processing-result轮询文件处理任务结果knowledge.delete-subtree删除子树knowledge.reindex-subtree重建子树索引。有意思的是知识库的索引类 handler 全部声明recovery: abandon例如 prepareRootJobHandler.ts 与 indexDocumentsJobHandler.ts 中都写着同一段注释// Dont auto-resume on restart — a deliberate app quit must not re-spend the // embedding API; the item is parked at failed and reindexed on demand. recovery: abandon,这意味着变更说明中自动恢复的准确语义是作业层面重启后遗留的非终止作业不会再卡死而是被恢复流程确定性地收尾取消并记录cancelled终态条目层面KnowledgeService.onAllReady调用ingestionService.recoverInterruptedItems()KnowledgeService.ts把残留的processing/preparing条目通过failInterruptedItems统一标记为failed错误码为KNOWLEDGE_ITEM_ERROR_INDEXING_INTERRUPTED见 KnowledgeIngestionService.ts 的实现注释。这样设计是刻意为之一次被中断的索引任务若在重启后自动重跑会无谓地再次消耗可能付费的embedding API。因此系统选择收敛到可再次操作的状态——条目停在failed用户可从右键菜单手动 Reindex 完成。这也正好解释了变更说明中的两句话强制退出后processing状态可能短暂残留下次启动后恢复流程跑完即自愈。 若启动后约 1 分钟某个条目仍卡住按以往方式从右键菜单执行 Reindex 即可。与此配合的还有两层自愈保障作业执行期间的onSettled回调会把失败的条目翻转成failed见 settled.ts 的markKnowledgeItemFailedOnSettledrecoverInterruptedItems只是进程先于 onSettled 退出场景下的启动期安全网。六、并发与重试的新语义变更说明列出了两个对使用者可见的行为变化均能在源码中得到印证1. 并发从全局共享 5 槽 → 每库 5 槽 全局 50 槽上限知识库的 handler 都设置了defaultConcurrency: 5prepareRootJobHandler.ts、indexDocumentsJobHandler.ts而队列名是按知识库隔离的defaultQueue: (input) knowledgeQueueName(toKnowledgeBaseId(input.baseId)),也就是说每个知识库拥有独立的 5 并发槽位多个库并行导入时互不挤占而JobManager全局并发上限固定为DEFAULT_GLOBAL_MAX_CONCURRENCY 50JobManager.ts作为跨库的总闸门。这正是变更说明5 slots per base with a 50-slot global cap的实现多个库同时导入时总体吞吐因此更快。需要说明的是从当前源码结构看全局并发上限是写死的常量未暴露为可配置项。2. 重试瞬时嵌入失败指数退避重试最多 3 次知识库 handler 统一声明了重试策略但两个核心 handler 的节奏略有差异HandlermaxAttemptsbackoffbaseDelayMsmaxDelayMsknowledge.prepare-rootprepareRootJobHandler.ts3exponential200060 000knowledge.index-documentsindexDocumentsJobHandler.ts3exponential100030 000JobManager的默认重试策略未显式声明时的兜底为maxAttempts: 3, backoff: exponential, baseDelayMs: 1000, maxDelayMs: 60_000JobManager.ts。因此瞬时嵌入失败会以指数退避自动重试最多 3 次之后才把条目标记为failed。七、超时上限prepare-root 10 分钟、index-leaf 的演进变更说明记录prepare-root目录/sitemap 扫描作业有 10 分钟墙钟上限index-leaf单文件/URL/笔记嵌入作业有 5 分钟墙钟上限。当前仓库源码中prepareRootJobHandlerdefaultTimeoutMs: 10 * 60 * 100010 分钟——与说明一致indexDocumentsJobHandlerdefaultTimeoutMs: 30 * 60 * 100030 分钟——与说明记录的 5 分钟存在差异。从变更说明如果遥测显示大文档用户频繁命中超时应提高defaultTimeoutMs而不是回退该机制的演进指引来看可以推断 index-leaf 的超时上限在发布后已被上调从 5 分钟放宽到 30 分钟以缓解慢速 embedding 端点下大文件的超时问题。JobManager对该超时以JobHandlerTimeoutError哨兵异常中断 handlerJobManager.ts而不是依赖对错误消息字符串的匹配避免误判。需要提醒的是超时是墙钟时间wall-clock涵盖读取、切片、嵌入全流程。对超大单文件 慢速 embedding 端点这一组合即使放宽到 30 分钟超时风险依然存在而这正是设计上宁可失败、不可无限挂起的取舍——失败后可重试挂起则无法自愈。八、边界情况与升级路径强制退出后的短暂残留processing状态在强杀进程后可能短暂保留下次启动恢复流程完成后即被清为failed属预期行为。v1 → v2 升级例外升级时正处于 in-flight 状态的已迁移知识库由KnowledgeMigrator映射为idle/failed保持 v2 既有行为不变自动恢复仅覆盖 v2 → v2 的重启。升级场景下的条目仍需用户手动 reindex。关闭瞬间的排空JobManager.onStop会等待 in-flight 作业排空上限SERVICE_STOP_TIMEOUT_MS - 500超时则记录警告pending jobs will be recovered on next start——这句日志正是整个机制闭环的注脚优雅退出没来得及干完的活下次启动交给恢复流程。九、开发者视角如何验证与调整测试覆盖作业层的恢复逻辑有独立的单测/集成测试见 src/main/core/job/testsJobManager.integration.test.ts、JobManager.schedule.test.ts、JobManager.smoke.test.ts知识库 handler 侧的恢复与收尾行为见 src/main/features/knowledge/tasks/tests如prepareRootJobHandler.test.ts、indexDocumentsJobHandler.test.ts、reindexSubtreeJobHandler.test.ts以及 src/main/features/knowledge/ingestion/tests/statusCleanup.integration.test.ts。调参入口若需要调整某个任务类型的超时或重试策略改对应 handler 的defaultTimeoutMs/defaultRetryPolicy即可并发调整则改defaultConcurrency注意不要超过全局 50 槽上限。架构背景完整作业系统架构四层锁模型、handler 编写契约可查阅 docs/references/job-and-scheduler/overview.md 与 docs/references/job-and-scheduler/handler-authoring.md。十、小结Cherry Studio 的这项变更把知识库索引从内存态 人工解卡推进到持久化 启动自动收敛JobManager在onAllReady后约 60 秒执行五步恢复流水线按 handler 声明的 abandon/retry/singleton 策略清算遗留作业知识库条目侧以recoverInterruptedItems兜底清除永久 spinner并发从全局共享池演化为每库 5 槽 全局 50 槽嵌入失败以指数退避重试 3 次所有任务都有墙钟超时上限。对普通用户而言结果是退出前在跑的索引重启后不再卡死对开发者而言这是一套把半途状态显式建模、可恢复、可测试的作业编排范式。【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考