aidea-server：用 Go 把多家大模型和绘图能力收进一个自托管后端
AIdea 是一款支持 GPT 以及国产大语言模型通义千问、文心一言等，支持 Stable Diffusion 文生图、图生图、 SDXL1.0、超分辨率、图片上色的全能型 APP。
秒懂
- 它是什么？
- AIdea 的客户端是开源的，服务端也是。这个仓库用 Go 写了一个聚合层，把 GPT、通义千问、文心一言和 Stable Diffusion 系列能力包装成统一接口，再对外提供一套兼容 OpenAI 协议的 API。判断它是否适合你，关键不在模型数量，而在你是否愿意接手一套注释稀少、命名几经改动的 Go 代码。
- 适合谁用？
- 适合已经接受自托管成本、并且需要一套现成 OpenAI 兼容网关来统一多家模型渠道的团队，尤其是同时要处理聊天和文生图的场景。不适合只想调一个模型 API 的个人开发者，也不适合把服务端当作长期稳定基础设施来依赖的团队，因为 README 明确写着注释和文档仍然有限。
- 能商用吗？
- 未经许可不能。GitHub 在这个仓库里没有找到许可证文件；没有许可证，默认即「保留所有权利」：你可以阅读代码，但不能复用。使用前请看看 README，或先征得作者同意。
- 还在维护吗？
- 活跃度在下降。仓库最近一次提交在 6 个月前。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的不是模型接入，而是渠道碎片化
自己做一个 AI 应用，最难的部分往往不是调用某个模型，而是同时对接好几家。GPT 一套鉴权，通义千问一套，文心一言又一套，图像生成还要再叠一层 Stable Diffusion 的接口差异。每家返回结构不同，流式输出的分片格式也不同，客户端要为每一家写一份适配代码。
aidea-server 把这件事收拢到服务端。README 的代码结构表里，pkg/ai 是各家模型接口的实现，pkg/ai/chat 则是抽象聊天模型接口，描述原文是「所有聊天模型都在这里被包装成兼容 OpenAI Chat Stream 协议」。也就是说，客户端只需要按 OpenAI 的流式协议解析一次，后面换模型、加渠道都不用改客户端。
目标读者很明确：要自建 AI 应用后端的人，或者想拿一套现成服务端配自己客户端的人。仓库首页同时指向客户端 aidea 和 Docker 部署仓库 aidea-docker，说明这套东西是按完整产品来组织的，不是单纯的 SDK。
分层方式：api 与 server 是两条并行的入口
这个仓库在入口层做了拆分，这一点值得单独说。api 目录提供的是 OpenAI 兼容 API，README 的表述是「这里的接口可以被任何支持 OpenAI API 协议的第三方软件直接使用」。server 目录提供的则是给 AIdea 客户端用的接口。两条路径共用底下的 pkg 层，但面向的调用方完全不同。
如果你只是想要一个能塞进现有工具链的兼容端点，api 这条线是重点。如果你想复刻 AIdea 客户端的完整体验，包括数字人、创作岛这些产品化功能，那要看的是 server 这条线。
往下是 pkg/repo 数据模型层和 pkg/service 服务层，README 对 service 的定位是「不属于 Controller 也不属于 Repo 的逻辑」。异步任务单独放在 internal/queue 和 internal/queue/consumer，README 说「所有异步处理的任务都定义在这里」。计费策略在 internal/coins，支付实现放在 internal/payment，支付宝和 Apple 都在其中。
框架选择上有明显的自研倾向。项目用了作者自己的 Glacier 框架和 Eloquent ORM，后者是受 Laravel 启发的代码生成式 ORM。好处是模块化和依赖注入的处理方式统一，代价是你排查问题时需要同时理解这两套非主流框架的行为。
自托管要碰的文件和命令入口
仓库根目录直接放了几个示例文件：config.yaml 是示例配置文件，coins-table.yaml 是示例定价表配置，nginx.conf 是示例 Nginx 配置，systemd.service 是示例 Systemd 服务配置。部署文档在 docs/deploy.md，Docker 部署被拆到了独立仓库 aidea-docker。
数据库结构不在代码里，而在 migrate 目录，README 标注为「数据库迁移文件（SQL）」。这意味着初始化不是自动的，你需要按顺序执行这些 SQL。应用入口在 cmd 目录。
配置项的具体键名，README 没有列出，唯一能确认的是根目录的 config.yaml 是示例文件，定价相关的键在 coins-table.yaml。要确认某个模型渠道怎么配，只能打开这两个文件对照 pkg/ai 下对应的实现。这一点在评估阶段就应该纳入时间预算。
README 还提到，如果不想自己搭，可以走 docs/deploy-vip.md 里的协助部署。这是一个商业服务入口，不是技术文档。
代码命名有过三轮演进，读代码前必须先看这段
README 里有一段专门写给读代码的人，语气相当直白：代码注释和技术文档目前有限，会逐步补充，并列出了两个容易造成困惑的点。
第一个是命名。代码里的 Room 和 Advisory Group 指的其实是同一个东西，也就是 Digital Persona。演进路径是 Room 到 Advisory Group 再到 Digital Persona，多次改版留下的历史命名没有清理。
第二个是版本断层。创作岛 v1 和 v2 完全不同，v1 服务的是 1.0.1 及更早的 App 版本，从 1.0.2 开始就不再使用。也就是说，仓库里可能同时存在两套创作岛相关代码，其中一套是死代码。
这两点合起来说明一件事：这个项目的可读性成本高于它的代码量所暗示的水平。作者自己把这段写在 README 靠前的位置，态度是诚实的，但对准备接手的人来说，这是实打实的上手门槛。
依赖链里有相当一部分不是通用组件
Glacier 框架和 go-ioc 容器、mylxsw/eloquent ORM，这三个都是同一作者的仓库。它们解决了 Go 应用的依赖传递和模块化问题，但代价是社区规模小，遇到框架层面的问题时，能搜到的资料远少于主流方案。
更实际的问题是升级路径。如果 Glacier 或 eloquent 出现破坏性变更，你需要跟着改，而这两个框架的维护节奏由作者个人决定。仓库最近一次 push 是 2026 年 3 月，最近三个 release 集中在 2024 年上半年，分别是 202404071800、202402201630 和 202401311800。release 说明里提到的内容跨度很大，从 Stripe、微信登录到艺术字支持，说明这是一个持续迭代的产品型仓库，而不是稳定冻结的基础库。
对使用者的含义是：把它当作一个跟随上游演进的服务端来用，而不是当作一个装好就不动的依赖。
几个明确写着「当前不可用」的地方
README 的代码结构表里有两处标注值得注意。pkg/voice 是「基于七牛云的文本转语音，当前已禁用」。pkg/tencent 里包含腾讯的语音转文字和短信实现。语音这条线在服务端是不完整状态。
另一处是 pkg/uploader，文件上传下载依赖七牛云存储。这不是可选项，是硬绑定。如果你的部署环境不能用七牛，文件相关的功能就需要自己替换实现。
还有一点，pkg/aliyun 里包含阿里云短信和内容安全服务的实现，pkg/dingding 是钉钉通知机器人，pkg/mail 负责邮件发送，pkg/youdao 封装了有道翻译 API。这些外围能力把服务端和多家国内云服务绑在一起。自托管的自由度，在这里是被云厂商依赖稀释过的。
如果你需要的只是「一个能转发多家大模型的网关」，这些附件都是负担。
和直接用 OpenAI 兼容网关的差别在哪
市面上有更轻的选择，比如 one-api 这类项目，定位就是纯粹的 API 聚合与转发，把多家模型的密钥统一管理，对外暴露一个 OpenAI 兼容端点。它的代码量和依赖面都小得多，部署通常就是一个二进制加一个数据库。
aidea-server 走的是另一条路。它不只是转发，还包含用户体系（pkg/token 里的 JWT）、计费策略（internal/coins）、支付接入（internal/payment）、任务队列（internal/queue）、内容安全（pkg/aliyun）和限流（pkg/rate）。这些是做一个能收费的 AI 应用所必需的东西，而纯网关不会提供。
所以选择的判断标准不是哪个更好，而是你要的是网关还是应用后端。如果你的客户端已经有自己的用户和计费系统，aidea-server 里的这套会和你重复甚至冲突。反过来，如果你要从零做一个带付费的 AI 应用，这些模块能省掉不少从零设计的工作。
需要说明的是，我没有运行过这两个项目，上面的对比基于各自仓库的目录结构和 README 描述。
License 字段为空，这是评估的第一步
仓库元数据里的 License 显示为 unknown，README 里也没有提到许可证。首页写的是「完全开源」，但「开源」和「有明确许可证」不是一回事。没有许可证文本，使用、修改和再分发的法律边界就是不清晰的。
这不是技术问题，但会直接影响能否商用。在投入部署之前，应该先去仓库确认是否存在 LICENSE 文件，如果没有，直接联系作者确认授权方式。我不提供法律意见，只指出这个事实。
维护成本方面，能确认的是：代码注释和文档有限且作者说会逐步补充，框架依赖是作者自研的两套库，release 节奏在过去两年里并不密集。升级时需要关注的不是单个模型接口的变化，而是 Glacier 和 eloquent 这两个底层框架的兼容性。
验证顺序建议是：先读 config.yaml 和 coins-table.yaml 确认配置模型，再检查 migrate 下的 SQL 能否在你的数据库上执行，然后确认 LICENSE 状态，最后再决定是否把生产流量导进来。最后一步之前，至少要让 api 目录下的 OpenAI 兼容端点在测试环境跑通一次完整的流式对话。
编辑结论
适合已经接受自托管成本、并且需要一套现成 OpenAI 兼容网关来统一多家模型渠道的团队，尤其是同时要处理聊天和文生图的场景。不适合只想调一个模型 API 的个人开发者，也不适合把服务端当作长期稳定基础设施来依赖的团队，因为 README 明确写着注释和文档仍然有限。动手前先确认三件事：config.yaml 里你需要的模型渠道是否都有对应配置项，migrate 目录下的 SQL 迁移能否在你的数据库版本上跑通，以及 LICENSE 文件是否存在。最后一件尤其重要，仓库元数据里的 License 字段是空的。
社区笔记