在验证候选模型后再切换，并保留回滚路径

直接回答

安全的模型更新不是覆盖唯一可用文件，而是先验证候选、再提交切换的事务。下载候选时让原模型仍可寻址，并将两个文件绑定到明确身份。客户端应使用当前真正具备的证据检查候选，再让目标运行时尝试加载，并执行预先定义的代表性任务。只有所有发布验收都通过，才切换活动引用；失败时保留旧版本，并把重试或回滚作为明确操作。传输完成不足以提交更新：文件存在、摘要校验、运行时初始化和任务验收分别回答不同问题。 当前仓库的 ModelDownloader 会写临时文件，并在可选 SHA-256 检查后尝试改名到配置的目标路径。E2B 的 SHA-256 目前为空，E4B 的文件大小与摘要被代码注释标为占位值。ModelManager 也维护变体和引擎释放相关路径。这些源码事实不能证明每个文件系统上都具备崩溃安全的原子替换，不能证明当前制品摘要已验证，更不能证明存在公开更新渠道。本文因此描述的是工程发布流程，不是声称 Cove 已经发布更新器。 一次更新涉及多个身份：源仓库及其不可变修订、转换后的制品、运行时依赖、应用构建、提示模板或分词器资源，以及派生用户数据。必须记录实际变化的是哪一项。如果只更新运行时或提示，而模型字节没有变化，就不要误标成模型文件更新。如果候选与缓存的派生数据不兼容，应按派生数据自己的版本规则重建或作废，并保护会话、笔记和用户媒体；除非用户另行明确选择，不得删除这些内容。回滚应恢复可验证的一组版本组合，不能只移动一个文件指针，却让不兼容的元数据继续生效。 提交边界需要明确。如果运行时可以安全保留旧模型，新候选验证期间可继续使用旧模型；如果不能，应说明维护过程并暂时阻止新任务。切换步骤必须由单一所有者串行化，并持久保存进程死亡后恢复所需的阶段：活动身份、候选身份、当前阶段和最近一次已持久验证结果。应用重启时，要把记录与磁盘上的真实文件重新核对，不能只相信旧的 ready 标志。临时文件存在本身也不能证明候选完整或已准备好。 回滚触发条件应基于可观察结果，例如候选缺失、元数据不匹配、运行时加载失败、代表性任务不合格或提交过程中断。还要定义旧版本是否保留、双文件更新需要怎样的空间，以及空间不足时采取何种做法。不得自动删除用户数据或最后一个可用模型来腾空间。如果旧制品无法恢复，应展示修复状态，提供有依据的重下或支持路径，而非无限重复加载。 发布前要在每个提交边界注入故障：下载中断、候选完成但校验前中断、运行时加载时中断、更新活动指针之前中断、指针更新后状态写入之前中断，以及清理旧文件时中断。重启后只能恢复到旧制品或完成已验证的新制品，绝不能靠猜测。先用确定性的测试文件和故障注入验证，再测目标运行时。测试记录需注明准确应用、制品及运行时修订，以便复现成功回滚。 ### 操作步骤 1. 定义版本化更新清单，记录活动和候选身份、格式、来源修订、已知元数据、运行时要求和派生数据迁移规则。未知大小或摘要保持未知，不填入看似合理的值。 2. 下载到独立且绑定修订的临时路径。校验响应身份和所有可用可信数据；此阶段不修改活动制品。 3. 在隔离验证步骤中加载候选。执行包与运行时检查，再用一个固定、无敏感内容的任务核对预先写明的验收属性。所有检查结束前旧模型保持活动状态。 4. 通过单一串行所有者提交。持久化可恢复阶段，仅在验证通过后切换原子清单或活动指针，然后重新打开所选制品确认状态。 5. 在每个边界注入中断。验证重启核对、用户数据保留、清理同意与精确旧身份回滚后，再删除旧文件。 ### 验收标准 - 候选通过身份、可用完整性、运行时加载和任务验收前，活动制品始终可恢复。 - 每个提交阶段遭遇进程中断后，重启都能选择旧制品或完整验证的新制品，不出现模糊半状态。 - 回滚恢复有记录的制品与运行时组合，并保留会话和无关用户文件。 - 空间不足或回滚失败时有明确恢复路径；不会自动删除用户内容或最后一个可用模型。 ### 对照 | 更新设计 | 优点 | 风险或边界 | |---|---|---| | 原地覆盖 | 临时空间较少 | 传输或加载失败可能毁掉唯一工作副本 | | 候选与活动文件并存 | 验证时保留回滚能力 | 需要容量规划与明确清理策略 | | 清单/指针提交 | 将“选用哪份文件”与文件本身分开 | 仍需持久状态和重启核对 | ### 常见问题 **下载进度到百分之百后可以立即激活模型吗？**不可以。传输完成不证明来源身份、完整性、运行时接受或代表性任务合格。必须等这些检查分别给出明确结果，候选才可成为活动版本。 **改名是否能让更新具备崩溃安全性？**单独改名不能保证。重命名行为取决于路径和文件系统，应用仍需记录活动身份并处理进程中断。要在实际使用的存储路径上测试恢复。 **何时可以删除旧模型？**只有候选通过验收且回滚保留策略允许清理时。如果空间无法同时容纳新旧模型，应说明权衡并提供恢复方案，不要为了空间默默删除用户数据。 **模型回滚时是否应该重写聊天记录？**应把用户创建的历史与模型文件分开。只按明确迁移规则处理有版本号的派生状态，不应仅为恢复模型删除会话。

候选模型下载完成，但运行时加载失败

用户已有一份可用的本地模型并发起更新。候选文件已经到达，但运行时初始化或固定验收任务可能失败。应用不能让一个看起来已安装的文件取代旧模型，却删除唯一有效副本。

决策

保持活动与候选文件分离，使用目标运行时验证确切候选，并只在可恢复的提交边界更新活动引用。

预期结果

失败后旧身份仍被选中，用户数据不受影响；界面提供有限的修复步骤，而非自动循环重试。

需要收集的证据

只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：

• 活动与候选制品身份
• 每个提交阶段的持久状态
• 进程中断、验证失败和回滚结果

收到完整字节流还不够；最终落盘、完整性、运行时加载和恢复路径也必须验证。

实施流程

1. 记录两个制品身份. 持久记录活动与候选的来源修订、格式、运行时要求、完整性元数据和更新阶段。模型家族名称或文件名不能替代完整身份。
2. 下载期间不改活动文件. 将候选写入独立且绑定修订的路径，校验响应元数据并保留当前模型。空间不足时先停止并说明选项，不先删除已有文件。
3. 检查候选和任务行为. 核对文件身份及可用完整性数据，用目标运行时加载，并运行预先定义的固定任务。测试记录不得包含用户内容。
4. 由串行状态所有者提交. 阻止并发更新或变体切换。持久化提交阶段，并仅在候选验收通过后修改活动清单；重新打开选定身份确认状态。
5. 覆盖中断与回滚. 在验证前后、指针切换前后和清理阶段注入进程中断，确保重启后恢复旧身份或完整验收的新身份。

让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。

验收标准

• 候选未通过身份、可用完整性、运行时加载和任务检查时不会激活。
• 每个中断点重启后都能恢复到明确的活动身份。
• 回滚保留用户记录并能指出精确的旧模型与运行时组合。
• 空间不足及回滚失败有明确恢复文案，不触发破坏性清理。

决策对照表

需要避免的失败模式

• 下载完就覆盖活动模型
• 仅凭目标文件存在认定更新成功
• 为释放空间自动删除对话和用户文件

还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。

最小复现记录

发布检查表

• ☐ 主要搜索问题已回答，且没有未经支持的数字。
• ☐ 所有模型文件和运行时版本均已固定。
• ☐ 代表性任务和失败处理策略均有说明。
• ☐ 生命周期、取消、清理和回退均已测试。
• ☐ 用户内容与网络边界均有说明。
• ☐ 结论只适用于被记录的配置。
• ☐ 新增测试结果时链接到原始方法或证据。

来源与相关证据

• AndroidX AtomicFile API 参考
• LiteRT-LM Kotlin API 生命周期指南
• Android Activity 生命周期

中文部署与排错专题见。奇连 AI 端侧专题。

常见问题