Other

技术解读

以下内容由 GitRead 中文社区 编辑团队基于项目 README 与官方资料整理, 结合中文开发者的常见使用场景补充技术选型建议。具体以项目官方文档为准。

99AI 深度拆解:把“能用的聊天框”做成“能收钱的 AI 服务平台”

项目背景与痛点

过去两年,开源社区里“AI 聊天前端”已经多到泛滥。从 ChatGPT-Next-Web 到 LobeChat,随便拉一个下来,改个 Logo 就能上线。但只要你真的想拿它做点生意,就会很快撞到同一堵墙:前端解决了“体验”,却没解决“经营”。

一个可对外售卖的 AI 平台,真正棘手的部分藏在聊天框背后——多用户与租户隔离、额度扣减与账单一致性、上游渠道的密钥管理与故障转移、卡密与支付回调、内容合规审核。OneAPI / NewAPI 这类项目把“协议统一与渠道分发”这一层做好了,但它本质是给开发者用的 API 中转站,缺乏面向终端用户的产品形态;而各类 Chat UI 又都假定“只有一个用户”,完全没有计费与运营的概念。

vastxie/99AI 的定位恰恰卡在这条缝里:它不做单点极致,而是把 Chat UI + API 网关 + 商业化运营后台缝成一套可直接交付的成品。对想私有化部署、又不想从零写计费系统的团队来说,这才是真正的省事。

核心技术揭秘

从仓库的技术栈选择可以清楚看出它的取舍:前端是 React 体系(Vite 构建),后端采用 NestJS 的分层架构。选 NestJS 而不是 Express 裸写,说明作者一开始就把它当成“要长期维护、要多人协作的服务端”来做——模块化、依赖注入、拦截器与守卫这套东西,天然适合“鉴权 → 限流 → 计量 → 计费”这种横切逻辑密集的业务。

整个数据流大致如下:

graph TD A[用户端 Web 应用] --> B[API 网关层] M[运营管理后台] --> B B --> C{"鉴权与额度校验"} C -->|"通过"| D[渠道路由与权重选择] C -->|"拒绝"| E[返回余额不足或封禁] D --> F[上游模型供应商] D --> G[本地推理服务] F --> H[SSE 流式响应透传] G --> H H --> I[用量计量与结算] I --> J[用户额度与账单落库]

这里最值得看的是三个设计决策:

第一,把“统一协议”当作内部契约。 平台内部只认一种 OpenAI 兼容格式,无论上游是 GPT、Claude、Gemini 还是国产模型,都要在这层被翻译成同一个形状。好处是前端只有一套调用逻辑,新增模型供应商几乎不需要动用户端代码;代价是那些非 OpenAI 风格的能力(比如某些多模态参数、思维链字段)在翻译中会丢失,需要靠扩展字段打补丁。

第二,流式场景下的计费一致性。 这是这类项目最容易出事故的地方。SSE 一旦开始推送,HTTP 状态码已经返回 200,此时再想“拒绝”已经来不及。合理做法是预扣 + 结算两段式:请求进入时按最大可能消耗冻结额度,流结束后依据 usage 字段(或本地 tokenizer 估算)回填实际值,差额退回。如果没有这套机制,一个恶意用户并发几百条长上下文请求,能把账打穿。

第三,渠道层的权重与降级。 渠道不是简单的 if-else,而是带优先级、权重、超时重试的路由表,配合“故障自动熔断、恢复后按权重回切”。这一层直接决定了平台在某个上游服务商突发故障时,是用户感知不到的抖动,还是一片红色报错。

功能亮点与差异

开箱即用的商业化闭环。 卡密兑换、在线支付、分销返佣、套餐与分组倍率——这些在别的项目里往往要你自己写三张表,99AI 直接内置了。计费模型沿用了业界成熟的“用户组倍率 × 模型倍率”思路,理解成本低。

绘画与对话共用一套积分体系。 MJ / SD 这类异步任务的计费方式与对话完全不同(按张、按步数),能把它和文本额度统一到同一账户体系下,说明作者在账务模型抽象上花过心思。

私有化友好。 不强制云依赖,模型密钥、支付通道、存储都能本地化配置,这对政企和内部团队来说是硬门槛。

应用场景与落地建议

适合:中小团队做 AI 增值服务、企业内部 AI 中台、面向 C 端的垂类 AI 应用底座。

生产部署有几条必须注意:

  • Redis 不要省。 限流、会话、额度冻结都依赖它,缺失会让并发场景立刻失控。
  • 支付回调必须做幂等,同时校验签名,并单独隔离回调域名,避免公网暴露。
  • 上游密钥加密存储,不要明文放数据库;一旦泄露,损失是直接的现金。
  • 给流式接口设并发上限与单用户速率闸门,这是防刷的第一道防线。
  • 渠道建议分批灰度接入,保留一个“兜底渠道”并关闭其熔断,否则全渠道故障时平台直接失联。
  • 面向公众运营时,敏感词与内容审核不能省,合规风险远高于技术风险。

综合评价

优点:整合度高,把“能用的产品”和“能赚钱的系统”一次性给全;技术选型克制(React + NestJS + 关系型数据库)而务实;商业化组件成熟度超出一般开源项目,看得出是在真实业务里磨过的。

缺点:业务逻辑集中在单体 NestJS 服务中,用户、额度、订单、渠道耦合在一个工程里,规模上去后拆分成本不低;对流式计费的依赖仍建立在 usage 字段的可靠性上,遇到不返回 usage 的上游就必须回退到估算,账目会有偏差;前端定制自由度不如纯 UI 项目,想深度改版需要读懂它整套状态管理;此外社区版的文档与自动化测试覆盖相对薄弱,二次开发的门槛主要在“读源码”而非“看文档”。

一句话结论:如果你要的是一个能直接上线收钱、并且能装进自己机房的 AI 平台,99AI 是当前开源选项里为数不多把账算清楚的项目;但如果你只需要一个漂亮的对话界面,它偏重了。

简要分析

热度分
1614
价值分
707
活跃状态
活跃

语言占比

CSS
Dockerfile
HTML
JavaScript
SCSS
Shell
TypeScript
Vue

Release

README

99AI — 开源、可私有化部署的 Web Agent 底座

99Agent

开源、可私有化部署的 Web Agent 底座。

从浏览器里的任务对话,到沙箱执行和文件交付。自带用户端与管理后台,接入你的模型,用 Skills 与 MCP 扩展能力。

简体中文 · English

安装部署 · 后台配置 · 二次开发 · 更新日志 · 交流群

演示视频

https://github.com/user-attachments/assets/4d549fb0-c25f-4a67-a3a8-1babee8f411a

85 秒能力演示,包含界面与流程示意。具体能力取决于模型与扩展配置。下载视频

核心能力

  • 任务对话 — 多用户、流式回复、附件上传,工具过程与成果文件直接呈现在对话中。
  • 隔离沙箱 — Docker + gVisor 执行命令与处理文件,支持 Python、Node 及文档、图像、音视频工具。
  • 持久工作区 — 登录用户拥有独立磁盘,多个对话共用;访客使用临时沙箱。
  • 多模型接入 — 支持 OpenAI 兼容接口、Responses、Anthropic、Gemini、OpenCode Go。
  • Skills 与 MCP — 用技能组织方法和脚本,通过 MCP 连接外部工具与业务系统。
  • 按需扩展 — 模型协议、登录、存储、商业等能力按包装配,保留你需要的部分。

开始使用

推荐 Node.js 24 LTS、pnpm 11,配合 MySQL 8 与 Redis 6+。生产沙箱需要 Linux、Docker 28+、gVisor 及用户磁盘助手。主应用运行在 Node.js 宿主机上。

git clone https://github.com/vastxie/99AI.git
cd 99AI
  1. 按沙箱指南准备运行环境。
  2. 按部署指南完成配置、构建与空库初始化。
  3. 打开用户端 http://localhost:9520 和管理端 /admin,在模型管理中添加模型。

当前为 0.1.0 测试版,请全新部署,与旧版 99AI 的数据库和配置不兼容。1.0 前接口与数据结构可能调整。

开发与贡献

后端使用 NestJS,用户端与管理端使用 Vue 3。你可以通过 Skills、MCP、沙箱镜像和可裁剪的扩展包构建自己的 Agent 产品。

贡献指南 · 扩展包指南 · Issues · 安全策略

交流群

微信扫码,备注 99 进群交流。进群后请先阅读群公告;作者不提供私聊技术咨询。

微信扫码备注 99 加入交流群

Apache-2.0

评论

暂无评论