这是又一篇补档文章，Chats已经发布了1.10，但2025年11月5日发布的1.8版本对我个人来说意义非凡，因为它彻底改变了项目对“模型提供商”的支持方式，从“写死在代码里”变成了“完全配置化”，为后续的可维护性和扩展性打下了坚实基础。
如果你还不了解 Sdcb Chats：简单说，这是一个支持多家主流模型服务商的 AI 网关。它不只能让你在一个统一界面里聚合管理所有模型，同时也兼容标准 API 协议，支持 Docker 一键部署。
这篇文章聊聊 Chats 1.8 系列（1.8.0 + 1.8.1）。它不像“加一个新按钮”那样轻松，而是做了大量“地基工程”：把“模型提供商支持”从静态参考表迁移到了模型实例本身，并且补上了大量用户能直接感知到的体验升级。
1.8 的核心：从“静态参考表”到“模型实例级配置”
到 chats 1.7.2 发布以来，已经支持有 18 个模型提供商，我当时为这 18 家模型提供商每一个模型都做了信息和数据跟踪，放到了 ModelReference 表，这个表有 297 条记录了，各大模型提供商卷大模型的速度越来越快，模型更新换代也越来越频繁，要可持续地维护这个表是非常困难的。
除此之外，代码中还有大量根据模型名称写死的逻辑，这导致越来越难以维护。我和项目的合作维护者讨论过许多次，有许多不同的意见，有的说可以继续沿用这种写死的方式，有的说应该做成配置化的方式，但我觉得可持续的维护能力才是我对 chats 项目最重要的承诺，所以我决定在 1.8 版本里彻底重构模型提供商的支持方式，做成完全配置化的方式，这样未来无论是新增模型提供商，还是调整已有模型的支持逻辑，都可以通过配置来完成，而不需要动代码。这个改动虽然在短期内增加了不少工作量，但我相信从长远来看，这会大大提升项目的可维护性和扩展性。
更技术一点地说：1.8.0 把“模型能力配置”从 ModelReference 这种静态参考表，迁移到了 Model（模型实例）本身——模型不再依赖“引用一条固定模板”，而是每个模型实例都拥有完整、可编辑、可验证的能力配置。
18 个“模型能力字段”落到 Model：终于能真正“按实例定制”
这次迁移不是口头上的“配置化”，而是实打实的数据库变更：在 src/scripts/db-migration/1.8/1.8.0.sql 里，Model 表新增了一批能力字段（AllowSearch/AllowVision/AllowToolCall/温度范围/上下文窗口/最大输出 token/推理选项/图片尺寸/API 类型等），并且清理了多张静态参考表（ModelReference、ModelProvider、Tokenizer、CurrencyRate、ReasoningResponseKind ……）。
第三种 API 类型：ImageGeneration（图像模型终于“名正言顺”）
1.8.0 新增了 ApiType.ImageGeneration，把图像生成从“勉强兼容”的逻辑里拎了出来：ChatCompletion / Response / ImageGeneration 三分天下，ChatFactory 也按 ApiType 分派到不同实现。
模型验证框架：把“填错配置”的坑提前堵住
当能力配置变成“每个模型实例 18 个字段都可编辑”之后，靠用户自觉显然不现实。所以 1.8.0 加了 UpdateModelRequest 的验证框架（包含自定义验证特性和单测），把温度范围、token 上限、字段组合合法性都系统化了。
快速添加模型：把“配置很多字段”的摩擦降下来
为了对冲“字段变多导致的配置成本”，1.8.0 在后台做了 Quick Add/批量添加模型的流程优化，并补上了默认配置（src/FE/constants/modelDefaults.ts 里能看到一些默认能力/范围策略）。
图像链路重构：从“手写解析器”到 ImageSharp + 全屏预览
1.8.0 还把图像处理这条链路整体重构了一遍：后端用 ImageSharp 替代了手写解析/嗅探逻辑（代码量直接少了一大截），前端新增了全屏 ImagePreview 组件，支持缩放动画、键盘导航和更顺滑的浏览体验。
骨架屏与按需加载：把“等待”变成“可预期”
1.8.0 在聊天消息加载、管理后台的模型管理等页面补了骨架屏，并做了按需加载/渐进式渲染：这不是性能“变快了多少 ms”的问题，而是用户感知上从“卡住了”变成“正在加载”。
1.8.1：在“架构变好”之后，把“体验也抠到位”
如果说 1.8.0 是地基，那么 1.8.1 更像是把常用路径都重新打磨了一遍：权限、推理内容展示、文件预览、聊天列表性能……这些都是你每天用 Chats 时能立刻感知到的变化。
全新的“用户-模型权限”管理：终于能规模化授权了
1.8.1 新增了 /admin/user-models（按用户维度管理），同时在模型管理页也增加了“按模型维度管理用户”的入口。更关键的是它的交互设计：URL 作为状态唯一数据源，筛选/搜索/展开状态都能分享、刷新不丢。
推理内容“生命周期追踪 + 自动折叠”：屏幕终于不被思考占满
推理模型越来越多，推理内容越来越长，UI 不能只“展示”——还得帮用户“管理注意力”。1.8.1 给 ReasoningContent 增加了 finished 语义：推理进行中自动展开、结束后自动折叠；工具调用区块也做了自动折叠与动画，且尊重用户手动操作优先级。
FilePreview 组件重构：附件展示不再“各写一套”
1.8.1 引入了统一的 FilePreview 组件：图片/视频/音频直接预览，文档类显示图标+文件名+下载按钮；同时后端把文件处理从 Controller 下沉到了 Service 层，类型检查也更集中。
聊天列表缓存：打开就快一点，刷新也稳一点
聊天列表不是什么“酷功能”，但它决定了你每天打开 Chats 的第一感受。1.8.1 里新增了 chatCache.ts：以用户名绑定缓存键、24 小时过期、登出自动清理，并配合并行 API 加载，让首屏更“有感”。
提供商侧：TokenPony 加入，Azure OpenAI 更名为 Azure AI Foundry
1.8.1 新增了 TokenPony（ID=19），同时把 Azure OpenAI 的命名更新为 Azure AI Foundry（枚举值不变，属于代码层重命名），并补了一个小迁移脚本清理 Azure Host 里的 api-version 参数：src/scripts/db-migration/1.8/1.8.1.sql。
兼容性与稳定性：OpenAI 2.6 升级后推理内容解析修复
1.8.1 还处理了一个很“现实”的问题：OpenAI 客户端升级到 2.6.0 后，推理内容的解析/解码出现兼容性问题，导致部分推理段无法正确读取。这个点不显眼，但它直接影响你对推理模型的信任感，所以也被纳入 1.8.1 里修掉了。
升级提醒：1.8 系列需要手动跑 SQL Server 迁移脚本
和 1.7 一样：Sdcb Chats 的数据库变更 不支持自动数据迁移。升级到 1.8 时请务必先备份数据库，并手动执行迁移脚本：
- 1.8.0：
src/scripts/db-migration/1.8/1.8.0.sql - 1.8.1：
src/scripts/db-migration/1.8/1.8.1.sql（清理 Azure AI Foundry 的 Host 参数）
如果你用的是 SQLite/Postgres……老规矩：把脚本丢给 AI 先改，再边跑边修；或者能接受删库的话，让 Chats 启动时自动建新表结构也行。
感谢大家的阅读！喜欢的朋友请给我的Github项目一个star：https://github.com/sdcb/chats
如果你好奇的话，这是完整的更新日志：https://github.com/sdcb/chats/blob/main/doc/zh-CN/release-notes/README.md
有什么想法也欢迎在评论区留言交流，也欢迎加入我的 Chats微信群：
（如果你更喜欢用QQ，可以用QQ群：498452653）我们一起探索更多AI技术硬核玩法。
