[Feature Request] memos-local-plugin 完整模式（自进化）支持「闲时批量执行」与 LLM 并发隔离
背景
使用环境：memos-local-plugin 2.0.18 + Hermes Agent，本地模式，LLM provider 配置为 OpenAI 兼容的付费 API（智谱 glm-5.3-flash），与主对话共用同一个 API key。
开启完整模式（algorithm.lightweightMemory.enabled: false）后，主对话频繁收到 provider 的 429 限流错误：
HTTP 429: 您的账户已达到速率限制，请您控制请求频率
原因很容易理解：完整模式下，每次 episode 关闭都会立即触发 reflect → reward → L2 → L3 → skill 全链路 LLM 调用；失败的任务还有一个 10 分钟周期的补偿重试定时器反复补打。这些后台调用与用户的前台对话共用同一把 key，并发额度被打满后，主对话本身反而被限流——用户最直观的体感是「开了记忆插件之后聊天开始报错」。
目前的规避方式是退回轻量模式，但代价是自进化能力完全不可用。轻量模式下产生的会话带 lightweightMemory 标记，之后即使切回完整模式也不会被补处理——也就是说这套能力对「白天高频使用、无法牺牲对话质量」的个人用户基本处于「要么全开、要么全关」的状态。
相关 issue
建议
希望增加两类能力（任一都能解决我们的困境）：
1. 闲时批量执行窗口（更期望）
- 增加类似
algorithm.deepProcessing.window 的配置，例如 02:00-06:00：
- 窗口内：正常执行 reflect / L2 / L3 / skill 及补偿重试
- 窗口外：只做轻量捕获与入库，把「待进化」的 episode 排队，攒到窗口批量处理
- 完整模式的进化本来就是离线性质的后处理，没有实时性要求，非常适合延迟到闲时执行
- 对用户的实际收益：白天对话零并发争抢，夜里 API 空闲时段额度充足，同样的 key 两头都不耽误
2. 速率限制感知与隔离（兜底）
- 至少做到：收到 429 后按
Retry-After / 指数退避，并暂停新的后台 LLM 调用，而不是 10 分钟定时器继续补打（限流时越重试越挤）
- 支持为进化管线单独配置 LLM provider/key（与捕获等轻量调用分离），让用户可以给后台任务单独一把低优先级的 key
补充
- 本机环境为「单 key 共用」的典型个人配置，相信也是自进化功能最主流的目标用户形态
- 如果方案 1 实现成本高，方案 2 的退避部分改动很小，收益也立竿见影
[Feature Request] memos-local-plugin 完整模式（自进化）支持「闲时批量执行」与 LLM 并发隔离
背景
使用环境：memos-local-plugin 2.0.18 + Hermes Agent，本地模式，LLM provider 配置为 OpenAI 兼容的付费 API（智谱 glm-5.3-flash），与主对话共用同一个 API key。
开启完整模式（
algorithm.lightweightMemory.enabled: false）后，主对话频繁收到 provider 的 429 限流错误：原因很容易理解：完整模式下，每次 episode 关闭都会立即触发 reflect → reward → L2 → L3 → skill 全链路 LLM 调用；失败的任务还有一个 10 分钟周期的补偿重试定时器反复补打。这些后台调用与用户的前台对话共用同一把 key，并发额度被打满后，主对话本身反而被限流——用户最直观的体感是「开了记忆插件之后聊天开始报错」。
目前的规避方式是退回轻量模式，但代价是自进化能力完全不可用。轻量模式下产生的会话带
lightweightMemory标记，之后即使切回完整模式也不会被补处理——也就是说这套能力对「白天高频使用、无法牺牲对话质量」的个人用户基本处于「要么全开、要么全关」的状态。相关 issue
lightweightMemory.enabled: true不彻底跳过进化管线——已在后续版本修复建议
希望增加两类能力（任一都能解决我们的困境）：
1. 闲时批量执行窗口（更期望）
algorithm.deepProcessing.window的配置，例如02:00-06:00：2. 速率限制感知与隔离（兜底）
Retry-After/ 指数退避，并暂停新的后台 LLM 调用，而不是 10 分钟定时器继续补打（限流时越重试越挤）补充