平台持续运行的三个循环
预测、评估与执行刷新有不同节奏。模块运行间隔控制何时重新生成预测，实测回填需要等待目标时间到达，Operator 则持续询问平台当前应如何调整副本。
采样步长决定一条指标每个点代表多久；历史窗口决定模型看多远的过去；预测范围决定向前看多久；冷却时间限制动作频率。这四项不应当作同一个周期。仅观察模式停留在采集与预测，不生成用于执行的推荐。
一次预测周期做什么
- 选择到期模块。任务中心按计划检查已启用模块，并尊重模块自己的运行间隔。
- 准备历史。按工作负载渲染指标模板，查询 Prometheus，处理单位与时间网格，记录缺样和新鲜度。
- 运行预测。关闭预测或选择“不预测”时使用默认配置；固定算法只运行指定方法，动态算法运行平台已启用的方法。历史不足或运行失败的候选记录原因。
- 形成建议。合格预测进入资源与副本计算，结合固定周期、边界、前瞻共识和保护规则。
- 保存结果。记录预测、运行信息和带版本与有效期的推荐，供页面、准入与 Operator 分别读取；仅观察模式不执行资源变更。
基线始终具有参与资格；候选需要通过相应版本的回测晋升。调整模型参数可能改变版本，旧晋升结果不能直接当作新配置的资格。
为什么会提前要求副本
新增 Pod 从发起扩容到接收负载需要时间。平台以实测或配置的容量就绪时间为基础，结合决策等待和近期偏晚余量，计算提前量窗口，再汇总各可用算法在该窗口要求的副本数。
扩容关注提前量内的需求，缩容需要整个预测范围更一致地支持下降，且当前实测负载放得进更少的副本。实测负载已超过预测与现有容量时，可触发专门的紧急扩容路径；它仍受副本上限约束。
两次预测之间怎样跟随负载
Operator 轮询读取决策时，平台会按配置的新鲜度判断是否需要刷新。刷新优先复用仍然新鲜的已存预测，采集最新实测样本后重新求决策；预测本身也过期时才重新运行算法。
同一模块的刷新串行进行，避免重复重算。请求只等待配置的时间，后台刷新可继续完成，后续轮询读取新版本。有独立运行间隔的模块仍按自己的节奏运行。
推荐数不一定立即成为实际副本
例如，当前 4 个副本，建议 10 个；假设扩容冷却为 2 分钟、单次最多增加 1 个，那么冷却期内可保持不变，满足执行条件后先到 5 个。这里是规则示例，不代表所有模块的默认值。
Operator 还会检查目标、权限、冲突、就绪状态和上下界。紧急扩容可以跳过普通扩容的冷却与步长，缩容不使用这条路径。执行成功只表示配置已提交，容量就绪仍要看后续 Ready 状态。
OOM、堆压力与降级分别在哪一层生效
| 机制 | 影响什么 |
|---|---|
| OOM 评分加权 | 启用后，在内存低配的评估窗口降低相关内存得分，影响比较与采用，不直接减小预测内存值。 |
| OOM 内存地板 | 利用近期 OOM 与相关内存观测设置保护下限，阻止建议过低。 |
| JVM 堆压力 | 有对应堆指标且规则启用时，作为副本求解的一项约束。 |
| 预测或数据降级 | 没有合格预测时，按固定周期、兜底与保持原值等规则处理，说明实际采用来源。 |
| 平台失联 | Operator 按缓存、保持、降级与稳定恢复状态机处理，不等同于某个算法失败。 |
实际结果怎样影响下一轮
预测目标时间到达后，平台对齐实测样本，计算资源误差、峰值低估与覆盖情况，更新评分和排名。滚动回测使用历史起点比较候选与基线，负责采用资格；实测回填解释已经发生的预测表现。
扩容动作还结合 Ready 副本与后续负载评估是否及时，已评估的就绪和偏晚时长反馈到提前量。效果报告汇总准确度、稳定性、Pod·小时与容量 SLO，帮助判断资源变化带来了什么。