背景
当前供应商详情页已有连通性检查和基础状态展示,但诊断信息偏少。用户看到“异常”后,仍然需要自行判断问题来自 API Key、Base URL、代理、模型列表接口、具体模型调用,还是供应商返回错误。
AI Foundation 作为底座插件,一旦供应商异常,下游功能也会受影响。管理端需要把“异常”进一步拆成可行动的信息。
目标
增强供应商健康诊断,让管理端能清楚展示检查结果、失败原因和建议动作。
建议能力
- 展示最近一次检查的结果、时间和错误摘要
- 区分基础网络连通性、认证、模型发现接口、聊天接口、Embedding 接口等检查项
- 对常见错误给出可操作提示,例如 API Key 无效、Base URL 不可达、代理不可用、接口不支持
- 在供应商列表和详情中都能快速看出异常来源
- 保留原始错误摘要,便于开发者排查
建议交互
- 供应商列表展示健康状态和简短错误摘要
- 供应商详情展示分项诊断结果
- 连通性检查完成后直接刷新状态,并展示本次检查结果
- 状态异常时,在关联模型列表上方提示可能影响模型调用
后端/API 建议
- 扩展 AiProvider.status 或新增诊断响应结构,避免只依赖单个 phase/message
- 连通性检查接口返回结构化结果,同时更新资源状态
- 与 AiModel 状态/健康检查设计保持一致,避免重复字段和概念漂移
- 错误信息需要脱敏,不能泄漏 Secret 或 API Key
非目标
- 不要求实现后台定时健康检查
- 不要求覆盖每个供应商的全部专有错误码
- 不要求做告警通知
验收标准
- 连通性检查失败时,详情页能展示明确失败原因
- 管理员可以区分配置错误、认证错误、网络错误和接口能力不支持
- 供应商列表能提示存在异常供应商,并可进入详情查看诊断信息
- 错误信息不会泄漏敏感凭据
背景
当前供应商详情页已有连通性检查和基础状态展示,但诊断信息偏少。用户看到“异常”后,仍然需要自行判断问题来自 API Key、Base URL、代理、模型列表接口、具体模型调用,还是供应商返回错误。
AI Foundation 作为底座插件,一旦供应商异常,下游功能也会受影响。管理端需要把“异常”进一步拆成可行动的信息。
目标
增强供应商健康诊断,让管理端能清楚展示检查结果、失败原因和建议动作。
建议能力
建议交互
后端/API 建议
非目标
验收标准