S13：Artifact 缺失、Hash 不一致与恢复思路

内容类型：预习教材（不代表已完成）
日期：2026-12-05
阶段：P2 · AI Systems Engineering 90
总路线：Day 103 / 360
周次 / 节奏：W2 · 周六可选探索 / 补学
状态：教材已备；学习未完成
主题：artifact integrity、failure classification、recovery

一句话定义

Artifact 完整性处理是在 bundle 被采用前识别缺失、内容不符、依赖不可达或元数据不一致，并选择阻止、降级或恢复，而不是运行到中途才产生含糊结果。

学习目标

1. 能区分 missing、digest mismatch、unreadable、incompatible 和 provenance unknown。
2. 能设计 fail closed、fallback 与 quarantine 的适用边界。
3. 能从 S09 manifest 进行一次可选故障观察。
4. 能明确本地校验不是生产供应链安全认证。

核心知识

Artifact 不可用有多种状态。路径不存在是 missing；字节与 digest 不同是 mismatch；权限或格式错误是 unreadable；文件完整但 schema/运行时不匹配是 incompatible；内容可用但来源无法确认则是 provenance unknown。把这些统一报为“load failed”会丢失恢复线索。

高风险组件通常应 fail closed：策略、权限或 tool schema 缺失时不应悄悄放宽。低风险展示组件可 fallback 到已知旧版，但必须记录实际采用的版本。Quarantine 适合隔离尚未验证的新 artifact，避免污染 active alias。恢复源应是 immutable registry/cache 或重新构建流程，而不是从聊天记录手工复制内容。

校验时点包括注册、组装 bundle、promotion 和启动/加载。每次请求都重算大模型 hash 成本高，因此真实系统会在可信下载后校验、缓存结果，并通过只读/内容寻址存储维持不变性。学习实现只需在加载前对三个小文件检查。

机制与推导

Bundle 可用条件可写为：

[ ready(B)=\bigwedge_{a\in B}(exists(a)\land hash(a)=digest_a\land compatible(a,runtime)) ]

Provenance 与许可并不包含在这个布尔式中，说明 integrity ready 仍不等于 governance approved。恢复决策可按 criticality × availability × trusted fallback 思考：关键且无可信 fallback 时停止；非关键且有已知旧版时可降级；来源不明时隔离。

故障事件应关联 bundle id、artifact name、expected/actual digest、检查时点与采取动作，但避免把敏感正文写入日志。

最小练习或观察步骤

1. 若已完成 S09，可复制 manifest 到临时学习目录；未完成则只做纸面推演。
2. 分别模拟删除文件、修改一字节和改错 schema version。
3. 观察验证器是否能区分 missing、mismatch 与 incompatible；只写真实结果。
4. 为 prompt、policy、tool schema 各选 fail/fallback/quarantine 策略，并说明风险。
5. 恢复时创建新版本或从可信旧版还原，不覆盖证据。

常见误区与边界

• 所有失败都自动 fallback，可能绕过安全策略。
• 从未校验的缓存恢复，错误被复制到更多节点。
• 只检查文件 hash，不检查运行时和 schema 兼容性。
• 把 actual 内容写进故障日志，泄露 prompt 或敏感配置。
• 将本地 hash 练习描述为签名、SLSA 或生产供应链保障。

系统场景连接

如果 AML Agent 的权限策略 artifact 缺失，继续运行默认 allow 会扩大风险；若只是帮助文本缺失，使用旧版可能可接受。检索索引 digest 不符则可能造成答案与 release bundle 证据不一致。对外部模型 provider，还要记录不可控版本和服务端漂移，不能假装本地 hash 能覆盖全部依赖。

自检问题

1. Digest 正确但 artifact 仍不可用的原因有哪些？
2. 哪些组件更适合 fail closed，为什么？
3. fallback 本身需要哪些身份与完整性证据？
4. 为什么 integrity 与 provenance 是不同判断？

专业课程对齐

• 阅读 MLflow 官方文档 的 artifact store、model registry 与 model loading 内容，观察平台在产物定位和加载时保留什么元数据。
• 阅读 Full Stack Deep Learning 2022 的 deployment 与 infrastructure 主题，关注依赖缺失或不兼容怎样在服务启动和发布阶段暴露。
• 阅读 OpenLineage 官方文档 的 run facets 与 dataset version 思路，理解恢复或重建应形成新运行证据，而不是无痕修补。

深入学习提示

把故障分类做得比恢复代码更清楚。对每类状态写“能否信任内容、能否执行、能否解释来源、是否有旧版”。再构造一个 hash 完全正确但 policy 语义过期的反例，提醒完整性只是一个层面。周六只需一次小观察；若 S09 尚未完成，纸面状态表已足够，不必追赶编码。

学后填写区

• 实际模拟或推演的故障：
• 验证器区分出的状态：
• 三类组件的恢复策略：
• integrity 之外的未知项：
• 今日是否选择休息：