起因:我想做 AI 漫剧,但不想从零写平台
我手上有一套现成的模型后端:一个 OpenAI-compatible 的图片/视频网关,加上阿里云百炼(万相图片、wan2.x 视频)。缺的是上层——一个能管"剧本→角色→分镜→出图→出视频→合成"的导演工作台。
从零写一个这样的平台至少要几个月,而 GitHub 上 2026 年上半年恰好冒出来一批开源 AI 漫剧/短剧项目。所以问题变成:哪一个值得 Fork?
我花了两天做了一次源码级尽调。结论先放这儿:Fork alibaba/lumenx;工程完成度最高的 dramaclaw 因为 Elastic License 2.0 禁 SaaS 只能当第二选择;而所有头部项目宣称的"多模型可插拔",在源码面前全部被证伪。
方法:不看 README,直接读码
流程分四步:
- 扫描:中英文关键词 + 社区盘点文章五路并行,去重后得到 29 个候选,GitHub API 逐个核实,28 个真实存活。
- 深读:挑 12 个浅克隆,读 provider 层、生成管线、数据结构、任务队列、FFmpeg 调用、LICENSE 原文,15 个维度打分,每条结论都要求给出源码文件路径。
- 对抗核验:对总分前三的项目,各派两个"推翻者",任务是读源码找反例,设法推翻深读结论。
- 修正:核验结果直接改写最终排名。
第 3 步是这次尽调最值钱的设计——后面会看到。
格局:真正全链路的只有五家
28 个候选里,具备"小说/剧本→分镜→图片→视频→成片"完整链路的只有五个:
| 项目 | Stars | 定位 | License |
|---|---|---|---|
| Toonflow-app | 13939 | 小说→短剧一站式,Electron | Apache-2.0+补充协议 |
| dramaclaw | 3690 | 通用 AIGC 视频引擎 | Elastic-2.0 |
| printfilm | 3488 | 短剧 SaaS,DramaForge 流水线 | 无 LICENSE |
| lingguo-drama | 1377 | Go 短剧后台工作台 | 无文件(自称 MIT) |
| lumenx | 1074 | 阿里开源漫剧/视频创作平台 | MIT |
其余的要么是 ComfyUI 插件、纯前端玩具、模型训练管线,要么已经闭源(比如 1753★ 的 bigbanana-ai-director,现在只发 Docker 镜像,CC BY-NC-SA 还禁商用)。
发现一:“可插拔 Provider"全是话术
我的核心需求是把自己的两个后端接进去,所以每个项目我都重点查了 provider 层。深读阶段三个头部项目都宣称"架构清晰、可插拔”,然后对抗核验把它们全推翻:
- dramaclaw:视频生成器直接硬编码了火山引擎的 API 端点、模型名和轮询逻辑。LLM 走网关还算灵活,但想换一个视频厂商,得改好几个模块,不是加个配置的事。有意思的是它内置了一个 Grok 视频生成器,说明作者也走过我这条路。
- lumenx:provider 层是"类级抽象"——工厂类里按厂商名 if/else,每个厂商一个 Model 类,图片模块直接 import 厂商 SDK。接新厂商要动大约 4 个模块,有界但绝不是配置级。
- Toonflow-app:宣传的"可编程供应商系统"只对文本模型成立,图片/视频照样要按厂商逐一定制。
结论很残酷:图片/视频生成这一层,换任何底座都要写代码,区别只是写 4 个模块还是重写一半。 全场只有 LLM 层存在真正的配置级接入。
真正写得标准的 OpenAI-compatible 适配器,反而来自一个没什么星的企业级 Agent 平台(buildingai)的 createOpenAICompatible 实现——它没有视频管线,但那段适配器代码值得直接抄。
发现二:License 比架构更致命
这是筛选里杀伤力最大的一关,高星项目成片倒下:
- dramaclaw(3690★):Elastic License 2.0,原文写得明明白白——禁止向第三方提供托管/管理服务。自托管、改代码、给客户交付作品都行,对外 SaaS 必须买商业授权。
- Toonflow-app(13939★):Apache-2.0 加补充协议,向两个以上独立第三方分发产品要书面授权。
- printfilm(3488★):架构是遗珠级(小说自动分集、FFmpeg 截尾帧衔接镜头、带幂等键的任务系统全都有),但仓库里没有 LICENSE 文件——法律上你连 fork 都不该 fork。
- moyin-creator(4363★):AGPL-3.0;类似的 openframe 也是 AGPL。
- director_ai(1705★)、ai_story(1345★):同样无 LICENSE。
算下来,28 个候选里 License 干净(MIT/Apache-2.0 无附加条款)且具备全链路的,只剩 lumenx 一个。
发现三:漫剧生产要的是流水线,不是自主 Agent
顺带看了各家的编排架构:有 LangGraph 九 agent 的(open-director,结果视频生成代码被注释掉了,根本没做完)、有三层自研 agent 的(Toonflow,决策层+执行层+监督层,设计很漂亮)、有 PydanticAI 的(dramaclaw)。
我的判断:漫剧生产是长流程、高单价、必须断点续跑的批处理——一集九个镜头,每镜一两块钱,跑到第七镜崩了,你要的是从第七镜续跑,不是让 agent 重新思考人生。所以 pipeline + 持久化任务表优于多 agent 自主决策。dramaclaw 的任务系统(状态机/取消/重试/恢复/审计)是全场标杆,这个设计比它的 provider 层值钱得多。
最终选择:Fork lumenx
决策链很短:
- 目标是商用 → 排除 Elastic-2.0、AGPL、无 LICENSE、已闭源;
- 剩下的 MIT/Apache 阵营里有全链路的只有 lumenx、Toonflow、localminidrama;
- Toonflow 有多客户分发限制,且图/视频 provider 仍要逐厂商写,配音模块还是个空壳;localminidrama 是个优秀的 Electron 桌面应用(它的 provider 配置层是全场的另一个范本),但"数据不出本机"的定位跟平台化路线冲突;
- lumenx:MIT 零风险、全链路、百炼是它的原生路径、provider 改造面有界(约 4 个模块)。
它也有短板:任务系统偏弱、没有小说自动分集、没有"上一镜尾帧→下一镜首帧"的衔接。但这三块都有现成的设计可以借鉴——任务系统学 dramaclaw,小说分集学 printfilm 的三段式导入,尾帧衔接学 lingguo-drama 的首尾帧参数。思路是借设计,不抄代码(dramaclaw 的 EL-2.0 也不让你抄)。
第二选择是 dramaclaw:如果你能接受商业授权,或者把产品定位改成自托管生产工具+为客户交付成片(Elastic-2.0 明确允许),它是开箱即用程度最高的。
三条方法论教训
- README 的"支持多模型"要打折,宣称"可插拔"的直接打对折——去 grep 厂商的端点 URL 和硬编码模型名,五分钟见真章。
- 先查 License 再看架构。架构再好,EL-2.0/AGPL/无 LICENSE 都能让你的商业计划原地报废。这次 28 个候选里 License 干净的不到一半。
- 对抗核验比正面评估可靠。让一个 agent 夸项目,它能找出二十个优点;让另一个 agent 设法推翻它,才能挖出 LICENSE 第 18 行那种决定生死的细节。
完整报告(15 维度评分表、逐项目源码证据、适配器接口设计、13 阶段改造计划)存在我的私库里,这篇是公开浓缩版。如果你也在选漫剧/短剧的开源底座,希望这篇能帮你省下两天。