技术解读

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

Midjourney Proxy:把 Discord 里的画师拆成可编程的 API

项目背景与痛点

Midjourney 至今没有开放官方 API。所有能力都被锁在 Discord 的频道交互里:你需要一个真人账号、一个机器人 Token、一个频道,靠打字和点按钮来出图。这套交互对个人创作者友好,对工程系统则是灾难——你没法批量提交、没法回调结果、没法做配额计费,更没法让前端应用优雅地等待一张图生成 60 秒。

trueai-org/midjourney-proxy 干的事情,本质是把这套「人机交互」抽象成「任务编排」:客户端只面对 REST 接口和回调,Discord 侧的连接、排队、按钮点击、消息解析、图片转存,全部由代理层吞掉。项目描述里「日均百万级出图」不是营销话术,它对应的是一套必须扛住并发、超时、风控与状态漂移的调度系统。

而它真正降低门槛的地方在于多上游支持——Discord、悠船(Youchuan)等渠道都被收进同一个 API 语义下。国内团队不必再为一个 Bot Token 折腾网络与实名,这是它区别于早期同类项目的关键分水岭。

核心技术揭秘

从代码组织看,这是一个典型的 Spring Boot 单体应用,核心链路可以拆成四块:接入层(REST + SSE/Webhook)→ 任务队列 → 账号池与调度器 → Discord Gateway 监听与消息解析。它没有强依赖 Redis 或 MQ,默认用内存队列即可跑起来,这让「一键 Docker 部署」成为可能;代价是水平扩展时需要自己做会话与队列的分离。

任务的生命周期是一条显式状态机:NOT_START → SUBMITTED → IN_PROGRESS → SUCCESS/FAILURE。调度器周期性扫描未完成任务,挑一个健康账号把 /imagine 指令发进频道,随后等待 Gateway 推送的 MESSAGE_CREATE 事件。真正的技术难点在解析层:Midjourney 返回的是图文混排的富文本,进度百分比、图片 URL、四个 U/V 按钮的 custom_id 都藏在组件结构里,代理必须从中还原出「这张图属于哪个任务」。放大(Upscale)、变体(Variation)、重绘(Reroll)本质上是对按钮 custom_id 的二次点击,项目把这些动作也封装成独立接口,等于把 Discord 的交互协议完整翻译了一遍。

graph TD A[客户端提交任务] --> B{"参数校验"} B -->|"不通过"| C[返回错误码] B -->|"通过"| D[写入任务队列] D --> E[调度器轮询出队] E --> F{"账号池有可用实例"} F -->|"无"| G[回队等待并退避] F -->|"有"| H[绑定 Bot 与频道] H --> I[发送 Discord 指令] I --> J[Gateway 监听消息事件] J --> K[解析进度与图片地址] K --> L{"是否到达终态"} L -->|"否"| J L -->|"是"| M[状态机落库] M --> N[Webhook 与 SSE 通知] N --> O[图片转存至对象存储]

账号池是另一处设计重心。多个 Bot Token 被抽象成可调度资源,配合并发上限与冷却时间做负载均衡,避免单个 Token 触发 Discord 的频率限制或风控。图片侧则普遍采用「代理下载 + 转存 CDN」的策略,因为 Discord 的附件链接带签名且会过期,直接透传给业务方迟早出事。

功能亮点与差异

与同类代理相比,它的杀手锏有三个。其一是多上游统一语义:同一个 /mj/submit/imagine 请求,可以落到 Discord,也可以落到悠船等国内渠道,业务代码无需感知差异,这对需要做渠道容灾的团队价值极高。其二是完整的动作面覆盖:文生图、图生图、混图、垫图、放大、变体、局部重绘、换脸、描述(describe)、融合(blend)几乎全齐,并且提供任务查询、队列查询、账号管理等运维接口,而不是只做一个 submit 转发。其三是通知机制的双通道:Webhook 回调适合服务端,SSE 适合浏览器端实时刷进度,两者共用同一套状态机,避免客户端反复轮询。

应用场景与落地建议

适合的场景很明确:SaaS 化的 AI 绘图平台、电商批量出图、设计工具内嵌、以及需要给多租户分配配额的中台系统。不适合的场景也很明确:对出图时延有硬性 SLA 要求、或需要完全合规授权的商业链路——毕竟上游依然依赖第三方渠道。

生产落地有几条必须注意。第一,把内存队列换成 Redis 或 MQ,否则进程重启即丢失排队任务,多副本也无法共享队列。第二,账号池至少准备 3~5 个健康实例,并监控冷却与失败率,单 Token 是典型单点。第三,回调必须幂等,Discord 事件偶发重复推送,业务侧要按 taskId 去重。第四,图片务必转存,别把 Discord 的临时 URL 存进数据库。第五,给提交接口加限流与租户配额,否则一个脚本就能把账号池打爆。

综合评价

优点:接口设计贴近真实业务、状态机与回调机制完整、部署轻量、多上游适配让它在国内环境里显著优于「只接 Discord」的方案。缺点同样明显:调度与队列的默认实现偏单机,规模化时需要改造;对 Discord 的协议解析属于逆向维护,上游一改按钮结构就得跟进;账号风控与平台条款始终是悬在头顶的风险,项目本身无法替你消除。

一句话总结:它不是「Midjourney 的官方 SDK」,而是社区在灰色地带里搭出来的一套相当工程化的中间件——用得好是加速器,用之前先想清楚你的合规边界和扩容路径。

关于

GitHub 原始描述(英文)

🦄 The world's largest Midjourney drawing API, generating over 1 million drawings daily, supporting Discord Youchuan Midjourney 🐂!

描述取自 GitHub 官方 API,保持仓库作者书写的原文。

简要分析

热度分
1105
价值分
539
活跃状态
活跃

语言占比

Batchfile
C#
CSS
Dockerfile
HTML
JavaScript
Shell

Release