找回密码
立即注册
搜索
热搜: Java Python Linux Go
发回帖 发新帖

2318

积分

0

好友

328

主题
发表于 7 小时前 | 查看: 1| 回复: 0

这是一篇补档文章。

如果你还不了解 Sdcb Chats:简单来说,它是一个支持超过20家主流模型服务商的AI网关。它不仅能让你在一个统一的界面里聚合管理所有模型,同时兼容OpenAI标准API协议,并支持Docker一键部署。

现在回头看,Sdcb Chats的最新版本已经到了1.10,后续又融合了交错思考、代码解释器、多模态以及企业级权限等看起来更酷的能力。但如果要问我:哪个版本是我个人开发节奏的分水岭? 答案大概率还是1.7.0。

因为1.7.0不只是“增加了一个功能”,而是有三件关键的事情同时发生:

  • MCP (Model Context Protocol) 在 Chats 中真正落地,使其终于从“能聊”走向“能调用工具”,理论上可以支持任何符合 MCP 规范的模型服务商和工具服务商,例如知识库、搜索引擎或计算引擎;
  • 数据模型与数据库经历了重大改动(这是一次破坏性变更),为后续的功能演进奠定了更牢固的地基;
  • 更关键的是:从这个版本开始,Chats 基本变成了我一个人维护的项目——而我第一次深度尝试了所谓的“氛围编程(Vibe Coding)”。

三个月空窗期:没有前端搭档,首次将AI视为开发同事

距离上次1.6版本正式发布已经过去了三个多月。在这期间,与我搭档开发 Chats 前端的朋友因故无法继续参与。失去了前端开发者,我一个后端开发者在 Next.js / React 这套技术栈里,生产力几乎直接归零——项目一度陷入停滞。

于是,我第一次认真尝试将 AI 当作“副驾驶”:从页面布局、状态管理、组件拆分,到各种复杂的 UI 边界情况处理(尤其是流式输出和工具调用的展示逻辑),都让 AI 一起参与决策和实现。

可以这样说:

  • Chats 1.7 之前:代码基本还是人类开发者一行一行手写出来的;
  • Chats 1.7.0 起:我开始“系统性”地进行 Vibe Coding,尤其是在我并不熟悉的 React 领域,生产力提升非常显著
  • 也是从这时起,Chats 的(几乎)唯一维护者变成了我一个人。

所以,这篇文章标题里提到的“感谢 AI”,并非客套,而是事实。

1.7.0 的核心:MCP 协议的全面落地与集成

如果你只把 Chats 看作一个“统一模型网关 + 美观 UI”的聊天前端,那么它的上限就仅仅是“把模型的回答展示出来”。但 MCP 协议的出现,让“模型能真正做事”有了更统一、更具可组合性的实现方式。

在 1.7.0 版本中,MCP 的落地并非停留在“能够连接”的层面,而是打通了整个调用链路:

  • 后端建立了完整的 MCP 实体与权限关系(Server、Tool、User 授权、Chat 绑定);
  • 前端设置页面新增了 MCP 管理模块:支持新增/编辑 MCP 服务器、抓取可用工具、为用户分配权限;
    MCP服务器管理界面截图,显示服务器列表、URL、工具数量及分配用户
    MCP服务器编辑界面,包含标签、URL、请求头及工具参数配置
    MCP服务器用户分配界面,可管理可用用户与已分配用户
  • 会话侧,可以绑定多个 MCP 服务器,并在会话开始前校验当前用户的权限;
  • 工具调用全程采用流式输出,参数与结果能以结构化的方式嵌入消息内容,前端也能进行更清晰的可视化展示。
    聊天界面中调用C#工具进行数学计算的演示截图

对我而言,这意味着 Chats 从“聊天 UI”升级成为了“工具编排平台”的雏形:你可以为不同的 Chat 会话或 Span 配置不同的工具集合,让它们在统一的对话体验中协同发挥作用。这种对工具的深度集成,正是现代 人工智能 应用开发中 Agent 工作流的关键一环。

工具调用体验优化:不只是能用,更要“看得懂”

做过工具调用开发的同行都知道:能成功调用是一回事,让终端用户清晰地理解调用过程是另一回事。

1.7.0 版本在工具调用的事件与消息结构上做了较大增强:SSE (Server-Sent Events) 事件类型更加丰富,消息内容中新增了工具请求与响应的结构化类型。这使得前端能够将“调用了什么工具、传递了什么参数、得到了什么结果”以更直观的方式展示给用户。

C#代码中用于SSE响应多态序列化的JsonPolymorphic特性示例

这件事看起来偏向“用户体验”,但它会直接影响开发者是否愿意在真实业务场景中使用工具调用功能:当工具数量增多、调用链条变长时,如果 UI 只是将所有信息混为一团 Markdown 文本输出,那基本上等同于不可用。

破坏性变更:数据库与数据模型的大规模重构

1.7.0 版本还有一个绕不开的关键词:破坏性变更

为了提升系统的可维护性与可观测性,我在这个版本中对消息存储层进行了重构(例如,将原先的 Message 实体拆分为 ChatTurnStep 的分层结构)。同时还伴随着用量关联、默认值约束、排序字段等一系列调整。

数据库模型变更示意图,展示从旧结构(Chat-Message-Content)到新结构(Chat-Turn-Step-Content)的演变

这种重构的特点是:短期内你需要承受一次升级的“阵痛”,但长期来看会节省大量的开发和维护成本。尤其是当你后续需要持续叠加“推理/工具/多模态/审计/性能统计”等复杂能力时,底层数据结构是否清晰合理,决定了你是在“继续编写新功能”,还是在“每增加一个功能都需要拆掉重来”。

一些关注用户体验的细节改进

除了 MCP 集成和数据库重构,1.7.0 版本还补齐了许多能提升使用体验的细节功能,例如:

  • 模型、密钥、预设提示词支持拖拽排序(Provider/Key/Model 的组织方式更加清晰直观);
  • 聊天内容再生成能力增强:支持单条消息重新生成,以及从某条用户消息开始重新生成后续整段对话;
  • Markdown 中的 Mermaid 图表渲染功能升级:支持暗色/亮色主题适配、全屏查看,并对流式输出更加友好;
  • 图片生成支持尺寸控制:可以在会话中直接指定常用的图片生成尺寸;
    图片生成设置界面,展示尺寸、质量及生成数量等选项
  • OpenAI 兼容性与第三方服务联调增强(包括工具调用适配性修复、登录兼容性优化等)。

这些改进点看起来比较零碎,但它们共同指向同一个目标:将 Chats 从简单的“功能堆叠”推向更具“可长期使用的产品质感”

升级与数据迁移指南:需手动执行 SQL 脚本

Sdcb Chats 的数据库变更 不支持自动数据迁移。升级时,你需要 手动执行 SQL 迁移脚本,并且目前官方仅提供了 SQL Server 版本的迁移脚本:

  • 1.7.0 迁移脚本位于:src/scripts/db-migration/1.7/20250516-mcp.sql

基本升级步骤非常直接:

  1. 首先,务必备份你的数据库
  2. 在 SQL Server 上执行上述迁移脚本。

如果你使用的是 SQLite 或 PostgreSQL……我的建议是:你可以将提供的 SQL Server 脚本交给 AI,让它帮你转换或适配成 SQLite/PostgreSQL 的语法版本,然后一边执行一边调试修复。或者,如果你能接受数据丢失,也可以选择删除旧数据库,Chats 在首次启动时会自动创建全新的表结构。

总结与致谢

在 1.7.0 版本的官方发布说明中,我特别感谢了社区的贡献(例如修复登录页面运行时错误的 PR #96)。而在这篇补档文章里,我还想加入一份更个人化的致谢:感谢 AI。

正是在前端开发伙伴离开、项目面临停滞的困境下,我通过 前端框架/工程化 领域的“氛围编程”,借助 AI 的辅助,才得以独立完成包括复杂 React 交互在内的诸多开发工作,最终让 MCP 协议成功落地,推动了 Chats 项目的关键进化。这段经历让我深刻体会到,在当今的软件开发中,善于利用 AI 工具已成为提升效能的重要途径。如果你对类似的 AI 应用开发、工具集成或全栈实践感兴趣,欢迎到 云栈社区 与更多开发者交流探讨。




上一篇:ARP协议详解:从广播请求到Proxy、Gratuitous等四种类型全解析
下一篇:麦肯锡报告:半导体市场规模被低估,2030年或达1.6万亿美元
您需要登录后才可以回帖 登录 | 立即注册

手机版|小黑屋|网站地图|云栈社区 ( 苏ICP备2022046150号-2 )

GMT+8, 2026-1-18 18:14 , Processed in 0.516424 second(s), 40 queries , Gzip On.

Powered by Discuz! X3.5

© 2025-2026 云栈社区.

快速回复 返回顶部 返回列表