状态：推荐评估 · 适合团队统一模型入口和运营控制
速读#
DEEIX Chat 表面是一套多模型聊天界面，实际定位更接近 AI 服务控制平面。它同时处理上游模型渠道、路由与熔断、文件和 RAG、MCP 工具、账号与 SSO、余额计费、使用记录、审计日志和后台运营。
如果需求只是「填一个 API Key，自己聊几句」，这套系统大概率太重；如果问题已经变成「多家模型怎么统一接入、用户怎么分权、调用怎么计费、故障怎么切换、操作怎么追踪」，它才进入自己的主场。
它把哪些东西收在一起#
| 区域 | 能力 |
|---|---|
| 对话 | 多模态、流式输出、分支、重试、编辑、分享和执行元数据 |
| 模型路由 | 多上游协议、优先级、权重、映射、熔断和能力配置 |
| 文件知识 | 上传、解析、OCR、分块、向量检索和证据记录 |
| 工具 | MCP 服务和供应商原生工具的发现、授权、执行与回显 |
| 运营 | 用户、角色、价格、订阅、余额、账单和使用流水 |
| 安全审计 | 2FA、可信设备、OAuth/OIDC、认证事件和系统审计 |
真正稀缺的不是聊天 UI，而是这些能力共享同一套身份、模型目录和调用记录。单独拼一个聊天前端、一个 API 中转、一个 RAG 服务和一个计费后台并不难，难的是让它们长期对得上账。
架构为什么值得看#
前端使用 Next.js 与 React，构建后由 Go 服务统一提供静态资源和 API；后端承担认证、路由、文件、计费和审计。轻量部署可以使用 SQLite、sqlite-vec 和进程内缓存，生产环境再切 PostgreSQL、pgvector、Redis 与 S3 兼容存储。
这个分层比较务实：试用时不用先拉起一整套基础设施，真正进入多人和高可用阶段又有明确升级路径。可选的 OCR、Tika、Docling 等文档处理服务也没有强塞进最小运行时。
最轻的官方 Docker 方案是：
cp config.sqlite.example.yaml config.yamldocker compose -f docker-compose.sqlite.yml up -dSQLite 配置适合评估、个人使用和小型单机部署，不该直接推导成「生产也永远只要一个容器」。用户、账单和审计一旦变成真实责任，数据库备份、密钥轮换、对象存储和监控都要补齐。
为什么推荐#
我推荐它，不是因为功能表长，而是因为它把多模型系统最容易被忽略的运营面做成了一等能力：路由失败怎么办、不同供应商模型如何映射、工具调用如何留痕、余额扣减如何回查、管理员改过什么配置。
这些问题在个人 Demo 里不存在，一旦服务别人就会同时出现。与其后期在四五个独立项目之间补胶水，不如先评估一套边界已经画好的平台。
不适合什么情况#
- 只给自己使用一个模型：简单聊天前端或供应商官方客户端更省维护。
- 没有计费、角色和审计需求：大量后台能力会成为认知负担。
- 不准备长期运维身份系统：OAuth、2FA、支付回调和敏感配置都属于高风险边界。
- 追求极简 API 代理：如果只需要协议转换与负载均衡，专门的网关会更直接。
项目当前默认分支是 dev，迭代速度快。正式部署更应该跟随明确版本和升级说明，而不是长期直接追默认分支。
DEEIX Chat 值得推荐给「要运营 AI 服务」的人，不是推荐给所有想聊天的人。需求只有一个输入框时别上平台；当模型、用户、工具和账单开始互相牵连，它才真正省事。