这是一篇补档文章。
如果你还不了解 Sdcb Chats：简单说，这是一个支持 20+ 主流模型服务商的 AI 网关。它不只能让你在一个统一界面里聚合管理所有模型，同时也兼容标准 API 协议，支持 Docker 一键部署。
现在回头看，Sdcb Chats 最新版本已经到了 1.10，后续又融合了交错思考、Code Interpreter、多模态和企业级权限等“看起来更酷”的能力。但如果要问我：哪个版本是我个人开发节奏的分水岭？答案大概率还是 1.7.0。
因为 1.7.0 不只是“加了个功能”，而是有三件事同时发生：
距离上次 1.6 正式发布过去了 3 个多月。这期间，和我搭档做 Chats 前端的朋友因为有事没办法继续参与开发。没有前端开发，我一个后端在 Next.js / React 这套体系里，生产力几乎直接归零——项目一度陷入停滞。
于是我第一次认真尝试把 AI 当作“副驾驶”：从页面布局、状态管理、组件拆分，到各种奇怪的 UI 边角行为（尤其是流式输出和工具调用展示），都让 AI 一起参与。
可以这样说：
所以这篇文章标题里写“感谢 AI”，不是客套，是事实。
如果你把 Chats 只当成一个“统一模型网关 + 漂亮 UI”的聊天前端，那它的上限就只是“把模型回答展示出来”。但 MCP 的出现，让“模型能做事”有了更统一、更可组合的方式。
在 1.7.0 里，MCP 的落地不是停留在“能连上”，而是把整条链路打通了：
后端有完整的 MCP 实体与权限关系（Server、Tool、User 授权、Chat 绑定）；
前端设置页新增 MCP 管理：新增/编辑 Server、抓取工具、分配用户；
会话侧可绑定多个 MCP Server，并在会话前校验当前用户权限；
工具调用全程走流式输出，参数与结果能以结构化方式进入消息内容，前端也能更好地可视化展示。
对我而言，这意味着 Chats 从“聊天 UI”升级成了“工具编排平台”的雏形：你可以给不同的 Chat Span 配置不同的工具集合，让它们在同一套对话体验里发挥作用。
做过工具调用的人都知道：能调用是一回事，让用户看懂发生了什么是另一回事。
1.7.0 在工具调用的事件与消息结构上做了比较大的增强：SSE 事件更丰富、消息内容里新增了工具请求/响应的类型，前端能把“调用了什么工具、传了什么参数、拿到了什么结果”以更清晰的方式展示出来。
这件事看起来偏“体验”，但它会直接影响你是否愿意在真实业务里用工具调用：当工具一多、调用链一长，如果 UI 只是一坨 Markdown 混在一起，那基本等于不可用。
1.7.0 还有一个绕不开的关键词：破坏性变更。
为了提升可维护性与可观测性，我在这个版本里对消息存储层做了重构（比如把 Message 拆分为 ChatTurn/Step 的分层结构），同时还伴随了用量关联、默认值约束、排序字段等一系列调整。
这种重构的特点是：你短期会痛一次，但长期会省很多命。尤其是当你后面要持续叠加“推理/工具/多模态/审计/性能统计”这些能力时，底层结构是否清晰，决定了你是在“继续写功能”，还是在“每加一个功能都要拆一次墙”。
除了 MCP 和数据库重构，1.7.0 还把不少“用起来会爽一点”的点补齐了，比如：
Sdcb Chats的数据库变更 不支持自动数据迁移。升级时你需要手动执行 SQL 迁移脚本，并且目前只提供了 SQL Server 的迁移脚本：
src/scripts/db-migration/1.7/20250516-mcp.sql基本步骤也很朴素：
如果你用的是 SQLite 或 Postgres……我建议你像我一样：把 SQL 甩给 AI，让它帮你改成 SQLite/Postgres 版本，然后你再一边跑一边修，或者如果你能接受，先删库，Chats 会在第一次启动时自动创建新表结构。
1.7.0 的发布说明里，我特别感谢过社区贡献（比如修复登录页面运行时错误的 PR #96）。而在这篇补档里，我还想加一个更个人的致谢：感谢 AI。
感谢阅读！喜欢的朋友请给我的Github项目一个star：https://github.com/sdcb/chats
有什么想法也欢迎在评论区留言交流，也欢迎加入我的 Chats QQ群：498452653，我们一起探索更多AI技术硬核玩法。
微信群：
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。