AI王炸项目实战：12个智能体与20个大模型打造爆款抖音

AI全链路短剧生成平台，可不是那种“演示很酷，一上生产就趴窝”的玩具项目。它的设计初衷，就是奔着企业级的生产标准去的：水平扩展、多租户隔离、断点续跑、智能重试……这些硬核指标一个不少。这意味着，你今天用它一天跑10部短剧，明天业务量上来了，简单加几台服务器，产能就能轻松翻十倍，达到一天100部。整个过程，无需重构代码，更不用苦苦哀求研发团队加班。

一、项目背景

这个项目的诞生，背景其实很清晰。随着AI技术席卷全球，AI短剧也迅速成为内容创作领域的新风口。无论是抖音、快手这类短视频平台，还是优酷、红果视频等中长视频网站，AI生成的短剧内容正以肉眼可见的速度增长。

然而，如果完全依赖人工，借助AI工具来制作短剧，流程依然相当繁琐。从构思故事线、设定人物、撰写大纲，到编写剧本、设计分镜、生成配音，再到最终合成视频、输出成片……这一整套流程下来，不仅费神费力，更需要一个具备专业背景的团队才能支撑。

于是，一个想法自然浮现：能不能打造一个平台，只需输入一句简单的提示，就能全自动走完从小说创作、故事线梳理、大纲拟定、剧本生成，到分镜设计、图片绘制、配音合成，直至视频剪辑、最终成片的完整流水线？

想象一下，输入一个创意，然后你可以转身去喝杯咖啡、处理其他工作，回来时，一部完整的短剧已经静静躺在那里，随时可以发布到各大平台。这不仅让个人创作者也能轻松涉足短剧领域，更在效率和自动化程度上，实现了对传统制作流程的超越。

正是基于这样的构想，经过前期充分的调研、缜密的设计、持续的开发、反复的测试与效果验证，这个AI全链路短剧生成平台最终得以成型，实现了从“一句话”到“一部片”的自动化飞跃。

二、情景再现

还在为空白文档和复杂的制作流程发愁吗？这个平台能把你脑海中“外卖小哥大战外星人”或是“霸道总裁爱上退休机甲师”的天马行空，一步步转化为小说、剧本、分镜图、配音，最终导出一部自带背景音乐和字幕的成片。你只需要提供最初的灵感，剩下的繁琐工作，完全可以交给系统。

不妨设想这样一个场景：深夜刷手机时，一个绝妙的点子突然闪现——“如果唐僧是个脱口秀演员，西天取经的每站都开一场专场，效果会不会炸裂？”

在过去，这个想法可能止步于：打开文档，写个开头，遭遇创作瓶颈，转而刷起视频，最终无奈放弃。

而现在，流程变成了：打开AI短剧生成平台，输入这个脑洞，点击“开始”按钮，然后安心去睡觉。第二天清晨，一部时长约15分钟、质量在线的短剧成品，已经准备就绪。

这并非科幻。该平台真正实现了从零到成片每一个环节的贯通。其背后并非简单调用某个AI接口写写画画，而是一套精密的多智能体协作系统。这相当于你同时雇佣了一个编剧团队、一个分镜师团队和一个后期制作团队，它们能够自主协商、分工协作、交叉审核，甚至在遇到问题时自动重试。

三、核心流水线

用户无需手动干预每一个步骤。整个生产链条像工厂的自动化传送带一样全速运转：

在这个过程中，你可以完全放手。当然，如果需要进行干预，平台也支持随时暂停流程、跳过特定环节，或者从中断处重新开始运行。

四、核心模块布局

4.1 小说生成

这里的小说生成，可不是让单个AI机械写作。它模拟了一个由7个不同职位AI组成的“编剧工作室”，通过开会、争论、修改，最终协同产出稿件。这七个角色分工明确：

• 世界架构师：负责构建故事的基础框架，比如世界观、大陆分布、超能力规则、货币体系等。
• 角色设计师：为每个主要角色撰写小传，细化到口头禅、恐惧的事物、手机里的歌单等个性细节。
• 情节架构师：规划从第一章到最终章的故事主线，并划分好卷次。
• 章节规划师：将主线细化到每一章的具体内容，在哪里设置悬念（钩子），又在哪一章进行回收。
• 小说写手：负责具体的章节正文撰写，并且支持实时推送到前端，模拟真人打字的效果。
• 总编审：通读稿件，如果质量不达标，有权直接打回重写。
• 质检官：从七个维度进行打分审核，包括角色行为一致性、伏笔遗漏检查、爽点密度、文笔仿真度等。

为了防止长篇故事在生成过程中间出现逻辑崩坏，系统维护了四层记忆机制：

• 固定记忆：核心的世界观和基础设定，不可更改。
• 角色记忆：每个角色的个性化设定，如张三爱喝冰美式，李四讨厌榴莲。
• 短期记忆：上一章节刚刚发生的关键情节。
• 中长期记忆：为数十章之前埋下的伏笔提供记忆支持，确保在适当时机被唤起。

此外，系统还具备伏笔追踪功能，能够自动记录“第3章埋下的某个梗，计划在第27章揭晓”，并在临近时提醒相关Agent注意回收。

角色状态快照则记录得更为细致：每个角色当前的位置、生命值、情绪状态、背包物品、知晓的秘密等，全部实时更新。

最精妙的设计在于对话风格分化：系统会强制要求大模型在输出时，为不同角色注入独特的语言风格。例如，A角色每句话带“咱就是说”，B角色句尾喜欢加“嗷”，C角色说话前习惯先“咳”一声。这能有效防止角色对话“串味”，提升真实感。

顺带一提，平台还采用了自研的通信压缩格式，在与大模型交互时能节省30%-60%的Token消耗。省下的成本，无论用于扩大生产还是其他方面，都颇具价值。

4.2 全自动流水线：一次启动，挂机等收片

• 状态持久化：流水线11个步骤的状态全部存入Redis。即使Ja va服务重启，恢复后也能从Redis读取进度，实现断点续跑，不丢失任何进度。
• 灵活干预：用户可以随时暂停任务、跳过特定环节（例如跳过AI写小说，直接导入已有小说文本）、或强制重跑某一步骤。
• 批量生产：支持一次性提交数十个项目，后台通过信号量（Semaphore）控制并发，充分利用计算资源和API额度。

4.3 视频生成：三次重试，比甲方还有耐心

视频生成API的稳定性时常是个挑战，同样的提示词，可能十次里有一两次生成效果不理想（比如画的外星人像土豆）。

为此，平台设计了三层自动重试机制：

1. 参数重试：使用相同参数再试一次，应对可能的网络波动或服务瞬时问题。
2. 提示词优化重试：让AI自行改写提示词描述后再次尝试（相当于“换个说法试试看”）。
3. 降级重试：降低分辨率要求后重试（例如从1080p降至720p），确保总能有产出，优于完全失败。

此外，平台支持首尾帧衔接技术：将前一个片段的最后一帧，作为下一个片段的第一帧，这样镜头切换时能避免生硬的“跳跃”感，过渡更自然。

最终合成阶段，由FFmpeg引擎完成所有后期工作：添加转场特效、烧录硬字幕、混合背景音乐、叠加AI配音音轨、添加水印、片头片尾等，全部自动化处理。

五、核心架构：产能无上限

5.1 技术架构

5.2 部署架构

看了下面的部署架构图，其高扩展性的原因就一目了然：

为什么能做到水平无限扩展？关键在于以下几点：

• 无状态Ja va服务：所有流水线进度状态存储在Redis中，服务节点本身无状态。任何一台新节点都可以从Redis认领任务继续执行。增加100台服务器，它们就会自动竞争任务，产能线性增长。
• JDK 21虚拟线程：传统线程池开到几千个就可能达到瓶颈，而虚拟线程可以轻松创建数十万个。这使得单台服务器同时运行上千条流水线成为可能。
• Redis分布式锁：确保多节点在抢任务、扣减API额度等操作时不会发生冲突。
• 独立的Python合成节点：将视频合成这类消耗CPU/GPU的重任务独立部署，可以单独进行扩缩容，不影响前端的AI生成任务。
• 分镜级并发：一部剧的30个分镜，可以同时调用30路API生成图片，无需等待上一个完成，极大提升效率。

平台的产能公式可以简化为一个乘法：

产出速度 = 节点数量 × 单节点并发流水线数 × 模型API并发上限

这意味着，只要云服务商不进行限流，理论上可以通过不断增加机器来无限提升产能。

实际扩容操作极其简单，无需修改任何业务代码，通常只需一行命令，如 docker compose scale 或 kubectl scale 即可完成。

六、技术栈选型

（此部分原文未提供具体内容，保留章节标题。）

七、支持20+AI大模型

平台在管理后台支持为每个功能模块独立绑定和切换AI模型，且支持运行时热切换，无需重启服务。

7.1 文本类（写小说、写剧本、Agent对话）

（此部分原文未提供具体内容，保留章节标题。）

7.2 图片类

（此部分原文未提供具体内容，保留章节标题。）

7.3 视频类

（此部分原文未提供具体内容，保留章节标题。）

7.4 TTS配音

例如集成火山引擎TTS，支持多音色选择和情感控制，甚至能让反派角色的配音带有阴险的笑声。

八、多智能体系统

8.1 第一组：小说生成（7个Agent）

NovelMainAgent（制片主任）
├── WorldArchitect（搭世界观）
├── CharacterDesigner（捏人设）
├── PlotArchitect（拉大纲）
├── ChapterPlanner（拆章概）
├── NovelWriter（写正文）
├── Editor（审稿）
└── QualityInspector（七维质检）

8.2 第二组：大纲故事线（3个Agent）

MainAgent（组长）
├── StorylineExtractor（故事线生成器）
├── OutlineGenerator（分集大纲生成器）
└── DirectorProxy（AI导演，负责审核）

8.3 第三组：分镜（2个Agent）

MainAgent（组长）
├── SegmentSplitter（片段拆分）
└── ShotPromptGenerator（镜头提示词生成）

所有智能体共享同一套底层框架，包括WebSocket实时通信、工具调用、消息队列、断点恢复和日志追踪。在调试模式下，你甚至可以查看它们在后台“讨论工作”的完整记录。

九、22个功能模块

（此部分原文未提供具体内容，保留章节标题。）

十、企业级功能：别人有的它有，别人没有的它也有

（此部分原文未提供具体内容，保留章节标题。）

十一、代码布局

story-video/
├── story-video-server/              # Spring Boot 3 主服务 — 核心业务承载
│   └── src/main/ja va/io/binghe/ai/video/
│       ├── config/                 # 配置中心：安全、跨域、异步、WebSocket等配置
│       ├── controller/             # 21个REST接口，对应前端功能
│       ├── entity/                 # 对应30张数据库表的实体类
│       ├── mapper/                 # MyBatis-Plus数据访问层
│       ├── service/                # 核心业务逻辑与流水线引擎
│       │   └── pipeline/           # 流水线状态机与Redis持久化逻辑
│       ├── agent/                  # 多智能体系统核心
│       │   ├── core/               # Agent基础框架
│       │   ├── novel/              # 小说生成7人组
│       │   ├── outline/            # 大纲故事线3人组
│       │   └── storyboard/         # 分镜2人组
│       ├── ai/                     # AI服务抽象层
│       │   ├── provider/           # 各厂商API具体实现
│       │   ├── model/              # 请求响应标准封装
│       │   └── retry/              # 智能重试策略
│       ├── security/               # JWT与RBAC权限控制
│       └── common/                 # 通用返回、异常、错误码定义
├── python-service/                 # Python FastAPI微服务 — 处理重计算任务
│   ├── main.py                     # 服务入口
│   ├── routers/                    # 图片/视频处理路由
│   ├── services/                   # 图片超分、视频合成服务
│   └── utils/                      # FFmpeg工具封装
├── frontend/                       # Vue 3 前端项目
│   └── src/
│       ├── views/                  # 页面视图组件
│       ├── components/             # 可复用UI组件
│       ├── api/                    # 后端API封装
│       ├── stores/                 # Pinia状态管理
│       ├── composables/            # WebSocket STOMP实时通信
│       └── types/                  # TypeScript类型定义
└── doc/                            # 项目文档

十二、本节总结

最后再次强调，AI全链路短剧生成平台从设计之初，目标就是成为能够支撑实际生产的企业级工具，而非仅停留在演示阶段。水平扩展、多租户隔离、断点续跑、智能重试等能力是其基石。它允许用户随着业务增长，通过简单地增加硬件资源来线性提升产能，无需面对痛苦的系统重构或核心代码修改。