未知模型供应商配置不应拖垮桌面应用

设置文件里多了一个旧版不认识的 provider，桌面 AI 助手 Ankita AI 就无法启动，连修复配置的 Settings 都进不去。作者的修复思路是：先让应用打开，保住用户已有的连接信息，同时避免偷偷切到另一个服务。

这件事值得读，不在于代码多复杂，而在于它把配置兼容拆成了几个不同问题：旧版本怎样读取新字段，未知服务怎样恢复连接，哪些错误可以容忍，哪些选择必须拒绝。对维护 Electron 应用和多模型客户端的程序员，这些边界很实用。

先让应用打开，但不能随便换个服务

故障发生在 DesktopSettingsStore.load。新版曾保存一个当前构建不认识的 provider，旧版加载时抛出 SAVED_PROFILE_LOAD_FAILED: Choose a supported provider，应用随即退出。

删除配置能绕过问题，却会丢掉用户已经填好的 endpoint、key 和 model。作者因此把兼容处理放进 desktop/electron/settings.mjs 的 load()：遇到未知 provider，尝试通过现有的 OpenAI-compatible 路由读取连接。

这段代码解决的是「未知名称挡住启动」的问题：

const compatible = typeof saved.provider === 'string'
  && !providers.has(saved.provider);
this.data = validatePatch(
  compatible ? { ...saved, provider: COMPATIBLE_PROVIDER } : saved
);

要看的是传给 validatePatch 的那一行：它只在内存里替换 provider。COMPATIBLE_PROVIDER 的值是 'custom'，加载过程不会写文件，磁盘上的原始 provider 名称仍然保留。

如果配置包含 customApiBase 和 customApiKey，应用通过 Custom 复用它们，并在 Settings 提示：保存的 provider 比当前构建更新，正在借用 Custom 连接。

没有保存 endpoint，就打开设置引导用户连接，不选择替代服务。applyDesktopSettings 还会在发现已保存的 provider 后，清掉继承自环境变量的 endpoint、key 和 model，避免缺失配置时借用另一套凭据。

恢复启动和选择服务，是两个需要分别处理的决定。

不认识的字段，可以保留而不参与运行

另一个问题发生在保存阶段：较新的窗口把旧主进程不认识的字段传过来，每次保存都会收到 Unknown desktop setting。

直接忽略这些字段虽然能让保存成功，却可能把新版配置擦掉。作者采用两份数据：当前版本认识的字段进入校验后的运行配置，未知字段单独保存。

这段代码负责从原始文件中取出未知字段：

this.preserved = Object.fromEntries(
  Object.entries(saved).filter(([key]) => !keys.has(key))
);

要注意 !keys.has(key)：筛出来的是当前构建不认识的字段。后续保存用 { ...this.preserved, ...next } 合并回磁盘，已知字段的新值在后面，避免被旧数据覆盖。

这些未知字段不展示、不校验，也不参与当前版本运行。它们只是被原样带过一次读写，等待未来认识它们的构建处理。这不是配置迁移，更不能保证新版字段在旧版里有效。

作者仍然保留了写入边界：用户显式更新为不受支持的 provider，照样抛出 Choose a supported provider。读取历史文件可以宽容，接受当前操作仍然严格。

文件保存采用临时文件加 rename，权限为 0o600，以降低写到一半留下损坏配置的风险。

40 项测试证明了什么，又没证明什么

作者先用实际故障配置复现：设置文件相关测试中，16 项通过、2 项失败。修复后，覆盖五个文件的定向测试得到 40 tests、40 pass、0 fail、0 skipped，耗时 14.583 秒。

验证还包括用故障配置的精确私有副本启动原生开发模式和构建后的 renderer，确认模型发现成功，Settings 能显示提示。这比仅验证「不抛异常」更接近用户实际的恢复路径。

同一文件还加了两道保护：

• 保存的上下文窗口或最大 token 值上限为 10,000,000，避免手误填出十亿 token；显式保存值始终优先于默认值，因为兼容端点经常不提供上下文窗口信息。
• testCustomProvider 在用户确认自定义端点前探测 {base}/models，超时为 8 秒；遇到 HTTP 401，会提示检查组合令牌 wk-<id>.ws-<secret> 的格式。

不过，未知 provider 并不等于支持 OpenAI-compatible。协议不兼容时，仍可能在 /models 探测或首次模型调用中失败。作者明确承认，这次修复保证的是能启动，不是连接必然可用。

我的判断

我认同把加载容错、字段保留和主动更新校验拆开。它比「未知字段一律报错」更适合存在版本交错的桌面应用，也比「删掉配置重新来」更尊重用户已经完成的设置。

需要打问号的是自动复用连接。它没有改投另一个 endpoint，却让用户在未主动选择 Custom 的情况下，通过这个标签继续访问原来的服务。设置页提示是否足够，取决于用户会不会看到它，以及恢复后何时开始发请求。

另一种做法是允许启动、保留 endpoint 和 key，但等用户确认后再恢复调用。它多一次操作，却让连接状态更清楚。作者没有提供两种方案的对照数据，因此自动复用更顺手，只能算经验判断。

40 项测试支撑了已验证的恢复流程，不能替代未知 provider 的协议兼容性验证；未知字段完整保留，也不能替代未来版本真正需要的数据迁移。

能拿来做什么

• 维护 Electron 设置模块时，可以把「读取旧文件」与「接受用户更新」分成不同校验入口，让应用有机会打开修复界面。
• 给多模型客户端补一条缺失 endpoint 的恢复用例，检查它是否会继承环境变量中的 key、model 或服务地址。
• 需要支持版本回退时，可以单独保留未知字段，并验证一次读取、修改已知字段、保存之后，未知内容仍然存在。
• 使用 AI 修改配置代码时，把故障配置和恢复行为一起交给它，要求验证能启动、能看到提示、加载不改写文件，以及实际模型发现是否成功。