背景
当前管理端支持从供应商发现远程模型，但发现结果和本地 AiModel 之间的同步关系还比较轻。对于 Ollama、OpenAI-like、SiliconFlow 等模型数量较多或变化较频繁的供应商，管理员需要更清楚地知道哪些模型是新增、已存在、已变化或远端已消失。
如果同步策略不明确，后续很容易出现两个问题：远端模型变化后本地列表过期，或者同步操作覆盖管理员手动维护的显示名、分组、启用状态等配置。
目标
增强模型发现后的同步策略，让远程模型发现不只是“创建模型”，而是一个可控、可追踪、不会误覆盖本地配置的同步流程。
建议能力
- 发现结果区分新增模型、已存在模型、本地已禁用模型、远端已消失模型
- 支持批量创建、批量启用、批量禁用或忽略模型
- 对已存在模型展示差异，例如显示名、能力、endpointType、流式支持等
- 支持保留管理员手动修改的字段，避免同步覆盖本地配置
- 对远端已消失但本地仍存在的模型给出提示，而不是直接删除
建议交互
- 在发现模型弹窗中按同步状态分组
- 每个模型展示本地状态和建议动作
- 批量操作前给出影响范围确认
- 同步完成后刷新供应商下的模型列表
- 对会覆盖本地字段的操作提供明确提示
后端/API 建议
非目标
- 不要求自动定时同步远程模型
- 不要求远端消失时自动删除本地模型
- 不要求支持跨供应商迁移模型配置
验收标准
- 管理员可以清楚区分发现结果中的新增、已存在和远端消失模型
- 管理员可以批量创建或更新发现到的模型
- 同步不会静默覆盖管理员维护的本地字段
- 远端消失的模型不会被静默删除，管理端会明确提示
背景
当前管理端支持从供应商发现远程模型，但发现结果和本地 AiModel 之间的同步关系还比较轻。对于 Ollama、OpenAI-like、SiliconFlow 等模型数量较多或变化较频繁的供应商，管理员需要更清楚地知道哪些模型是新增、已存在、已变化或远端已消失。
如果同步策略不明确，后续很容易出现两个问题：远端模型变化后本地列表过期，或者同步操作覆盖管理员手动维护的显示名、分组、启用状态等配置。
目标
增强模型发现后的同步策略，让远程模型发现不只是“创建模型”，而是一个可控、可追踪、不会误覆盖本地配置的同步流程。
建议能力
建议交互
后端/API 建议
非目标
验收标准