手里同时有三四家模型服务商的 Key，想加一个团队共用的对话入口，很快就会碰上一堆琐碎问题：每家协议细节不同、模型名和参数对不上、谁用了多少 Token 说不清、文件上传和知识库各做一套、账号权限与审计再补一遍。多数开源聊天前端只解决第一层「把对话框做漂亮」，剩下的路由、计量、身份和运维仍然散着。DEEIX Chat 想做的，是把这些环节收进同一个可自托管的产品里，而不是再提供一个需要自己拼装的外壳。
项目由 DEEIX AI 组织在 2026 年 5 月开源，Apache-2.0 协议，主语言 Go，仓库默认分支是 dev，最近一次推送在 10 月底；截至本文整理时约 1.6k star、249 fork。它规模不算小——接近 30MB 的源码、2777 个文件、前后端加桌面端三套工作区，但部署形态反而收得很紧：前端构建成静态文件，由同一个 Go 进程连 API 一起托管，重型的文档提取与 OCR 做成可选服务，基础部署只需要一个容器。
一、不是聊天前端，是「平台模型」这一层
README 里最值得先读的不是功能表，而是「模型与路由」这一项。它引入了一层平台模型：管理员在后台分别登记上游渠道、真实模型、路由绑定、优先级、权重、熔断规则和厂商能力映射，用户侧看到的只是一个统一的模型选择列表。 上游渠道换了、单价调了、某家接口临时不可用，改的是后台绑定，不用改客户端，也不用给每个人重新发 Key。
协议适配覆盖 OpenAI、Anthropic、Google/Gemini、xAI、OpenRouter 以及 OpenAI 兼容接口，文本、图片、工具调用与各厂商的原生能力差异都在适配层抹平。围绕它铺开的是一条完整的能力链：
| 模块 | 具体做了什么 |
|---|---|
| 对话 | 多模态、流式响应、分支与重试、编辑与反馈、分享链接、富文本渲染、可追溯的模型执行信息 |
| 文件与检索 | 上传、预览、提取、OCR、存储配额、全文注入、分片、向量嵌入、语义检索与 RAG 证据记录 |
| 工具生态 | MCP Server 与厂商原生工具的发现、启停、用户选择、执行限制、结果渲染、调用链路追踪 |
| 上下文与记忆 | 消息窗口、Token 预算、压缩摘要、会话记忆、长期记忆，在可控成本下维持连续性 |
| 计费 | 模型定价、工具按次定价、订阅、充值、余额、用量账本、计费快照与 Webhook 校验 |
| 身份与审计 | 本地账号、会话、2FA/TOTP、可信设备、SSO/OIDC/OAuth，以及用户、角色、调用日志、认证事件、系统事件的集中管理 |
把这些放在一张表里，才看得出它和「一个好看的 WebUI」的差别：计费快照、审计日志、工具调用追踪这类东西，都是给多人共用的场景准备的。个人单机用不上，团队一旦超过三五个人就绕不开。
二、单运行时架构：前端是构建产物，后端是唯一入口
开发时前后端分离，部署时合体。前端用 Next.js 16 / React 19 / TypeScript，配 Tailwind、Shadcn/UI、KaTeX、Mermaid、Recharts 等，pnpm build 把浏览器产物导出到 apps/web/out；生产镜像里的 Go 服务直接托管这个目录，同源对外只暴露 8080 端口。后端是 Go 1.26 + Gin + Gorm，目录边界划得很清楚：cmd/server 是可执行入口，internal/app 负责装配与生命周期，application 放用例编排，transport/http 守住 HTTP 边界，再往下经由 ports / repository 接口落到 infra 实现。
| 层 | 可选实现 |
|---|---|
| 对话与管理前端 | Next.js 16 静态导出，可由 Go 服务、CDN、对象存储或任意静态服务托管 |
| 数据 | PostgreSQL + pgvector，或 SQLite + sqlite-vec |
| 缓存 | Redis，或进程内 memory（仅单进程） |
| 文件 | 本地目录，或 S3 兼容对象存储 |
| 文档处理（可选） | 内置提取器、Apache Tika、Docling、Tesseract OCR、RapidOCR 等，以独立容器接入同一网络 |
数据层用域名前缀分表，财务记录、审计轨迹、系统事件和增长最快的向量数据各自独立，不混在一张表里。可选服务是这套设计里比较克制的一笔：Tika 负责文本提取、Tesseract 与 Docling 负责 OCR，默认不启动；只有后台真的打开了对应文件处理能力，才需要把容器拉起来。基础镜像因此不用背着一整套 Python 文档处理栈跑。
三、三种 Docker 装法，从 SQLite 起步
部署资源全在 deploy/ 目录，可以只把这一个目录拷到服务器，不需要源码。三套方案共用同一个应用镜像，都把配置模板复制成 config.yaml 后挂进容器的 /app/config.yaml，默认对外是 8080：
| 方案 | 适用场景 | 配置模板 / Compose 文件 | 内置依赖 |
|---|---|---|---|
| 轻量 | 本地试用、个人部署、小型单节点 | config.sqlite.example.yaml / docker-compose.sqlite.yml | 仅应用容器，SQLite + sqlite-vec + 内存缓存 |
| 默认 | 已有外部数据库与缓存 | config.example.yaml / docker-compose.yml | 仅应用容器 |
| 全量 | 单机同时跑应用、PostgreSQL、Redis | config.full.example.yaml / docker-compose.full.yml | 三个容器一起起 |
流程都是「复制对应模板为配置，再以后台方式启动对应的 Compose 文件」。轻量方案是官方推荐的起点：一个容器、一个 SQLite 文件、一份进程内缓存，数据和本地向量索引落在容器内的 /app/data，上传与生成文件落在 /app/storage。默认镜像名是 ghcr.io/deeix-ai/deeix-chat:latest，想用本地构建的镜像，通过镜像名环境变量切换即可。
几个容易踩的坑值得单独记：SQLite + 内存缓存只支持单进程，多节点或高并发必须换 PostgreSQL + Redis；全量 Compose 会在容器环境里写入数据库连接变量，这些变量优先级高于配置文件，改 config.yaml 不生效；把 PostgreSQL 迁到另一台机器时应当用逻辑导出导入，别在不同 C 库或 locale 的镜像之间直接拷数据目录——文本索引按建立时的排序规则排列，迁移后唯一索引会查不到已有行，进而产生重复数据，README 连重建索引与刷新排序规则版本的处置都写清楚了。
启动后用存活探针 /healthz、就绪探针 /readyz 和版本接口确认状态；Swagger 只在开发模式下注册，公网生产不会暴露。数据库里没有超级管理员时，后端首次启动会创建一个 admin，并且只在当次日志里输出一次初始密码，首次登录会引导改用户名密码、可选开启两步验证、选主题与时区。已经存在管理员的实例不会再次生成或输出密码。
四、静态配置与运行时配置是两回事
这套系统把配置拆成两半，理解了这个分层，才不会在后台里翻找半天找不到数据库地址。静态运行配置由 config.yaml 与环境变量提供，管的是品牌资源、服务地址、数据库、缓存、存储、GeoIP、Trace、JWT 与加密密钥；运行时业务配置写入数据库的 system_settings，管认证、会话、模型参数策略、文件处理、RAG、Embedding、MCP、计费、支付和公告，全部在后台管理里改。生效优先级是环境变量高于配置文件，配置文件高于代码默认值。
品牌也是静态配置的一部分：改完 config.yaml 的 branding 重启就生效，不需要重新构建前端或镜像。前后端分离部署时，则要对齐前端构建期的 API 地址变量，以及后端的公开 API 地址、公开 Web 地址与 CORS 来源；官方还给了 CDN 缓存规则——/_next/static/* 可以缓存一年并标记 immutable，图片字体按天到月缓存，HTML 路由不长期缓存，API 与探针路径必须绕过缓存并完整转发请求头、方法、查询和请求体。
五、安全设计：把「团队共用」当成默认前提
身份侧用 bcrypt 存密码，Access Token 是短期令牌且只放在前端内存，Refresh Token 写入 HttpOnly Cookie 且服务端只存哈希。上游 Key、用户自带的服务商 Key、SSO Secret、MCP Token、敏感设置和 TOTP Secret 都用 AES-256-GCM 加密落库；更换主密钥时有明确的轮转流程——新密钥生效、旧密钥暂存供后台重加密，日志出现完成标记后再移除旧值，直接替换会让所有已存密文解不开。README 也直白说明了边界：服务器调用服务商时必须解密，因此同时拿到数据库与主密钥的人仍能读出这些数据。
生产模式会拒绝不安全的默认密钥、过短的加密密钥、通配 CORS 和非 HTTPS 的公开地址；用户提交的模型参数在请求上游前经过白名单与黑名单过滤，模型名、消息、工具、系统提示词等系统链路字段不允许被覆盖。出站请求还有一层 SSRF 防护：后台保存的模型、MCP、Embedding 与身份源按精确 origin 局部授权，跨 origin 的私网目标必须命中部署级白名单，链路本地、组播与云元数据地址一律禁止；模型生成的图片或视频由后端下载校验后再转存。这些不是「加个开关」级别的装饰，而是把多人、多上游的环境当默认威胁模型来设计的。
六、多端：桌面端能内置一整个后端
仓库里除了 Web 和 Go 服务，还有基于 Tauri 2 的桌面端，以及规划中的移动端。桌面端有两种形态：连接远程服务器，或者「在本机使用」——后者直接把 Go 后端内置进来，用 SQLite 与本地文件，自动登录，凭据交给系统 keychain。平台矩阵里把差异列得很细，比如公开分享链接在桌面本地模式不适用（服务器仅本机可达）、语音输入依赖浏览器 Web Speech API 所以只是部分支持、移动端目前仍是规划中。
架构上有一条规定挺有意思：packages/core 放各端必须一致的业务逻辑，禁止导入任何 UI 或平台框架；packages/api-contract 由 Go 的 Swagger 契约生成 TypeScript 类型，是前端唯一的类型来源，改契约要先动 Go 的 transport 层再重新生成。客户端不靠「判断自己在哪个平台」来决定功能差异，而是读服务器的能力声明（capabilities）——同一份前端代码在 Web、远程桌面和内置本地服务上自然呈现不同的可用项。桌面发版则由一组 workflow 编排，macOS 签名公证、Linux 的 deb/AppImage、Windows 的 NSIS/MSI 并行产出，最后汇总成更新清单与校验和，先落成 Release 草稿再由人工发布。
界面这一侧也不只是文字流：代码、Markdown、数学公式、Mermaid 图、HTML 预览都能在会话里渲染，图片生成结果会连同本次耗时与费用一起展示。这几张官方截图里的用量数字、生成图和网页预览都是产品自身的功能示例，恰好把「对话 → 工具 → 计量」这条链路串了起来。
七、适合谁，以及先看清哪些前提
它适合需要给团队或小范围用户提供一个统一模型入口、又希望账号、配额、账单和审计都留在自己服务器上的场景；也适合想研究「前后端分离开发 + 单运行时部署」这套工程组织方式的人——目录边界、API 契约生成、能力声明驱动多端差异，都是可以直接借鉴的做法。
前提也得说清：项目很年轻，2026 年 5 月才建仓，默认分支是 dev，版本与文档仍在快速变动，官方文档站的依赖说明（Node 20.9+、Go 1.26.8）就比仓库 README（Node 22.23.4 / 24.22.1 / 26.12.1、pnpm 10.17.0、Go 1.26.10）旧一截，动手前以仓库里的 engines 和 .nvmrc 为准；上游模型服务商的接入条件要自己具备并合规使用，项目只负责把已授权的渠道统一管起来；计费与支付、SSO、对象存储、GeoIP、Trace 这些能力都需要自行配置后才有意义；移动端尚未实现，桌面本地模式也不提供面向公网的分享能力；公开部署前务必换掉模板里的两个安全密钥、切到生产模式并设置正确的公开地址与 CORS。
一句话总结：DEEIX Chat 的重点不在对话界面，而在把「多上游、多用户、要算账、要留痕」这四件事做成一套可以自己部署的默认能力。轻量方案一台机器就能跑通，真要面向真实用户，再按官方建议换到 PostgreSQL + Redis 的完整栈。
本文整理自公开资料并重写：项目仓库中英文 README、docs/ARCHITECTURE.md 与 docs/platform-matrix.md、deploy/ 下的三套 Compose 与配置模板、package.json，以及官方文档站的快速开始页。数据截至 2026 年 11 月，功能与版本以官方仓库为准。配图取自仓库官方截图，仅做格式统一、去元数据与尺寸压缩，未改动任何像素；原项目中的徽章、社群与推广入口均未收录，含品牌邀请落地页的一张示例截图已主动弃用。
本文整理自公开资料并做重写，原始出处：https://github.com/DEEIX-AI/DEEIX-Chat。文中配图已去除站点叠加水印与推广信息；版权归原作者所有。