Dramar 技术架构一览：AI Agent 如何驱动影视制作

技术栈概览

Dramar 是一个全栈 TypeScript 应用，运行在 Node.js 22+ 上。以下是核心选型：

为什么选择 Next.js 16？

Next.js 16 带来的几个关键能力正好匹配 Dramar 的需求：

• Server Components 让我们把数据获取放在服务端，减少客户端 JS 体积。像项目列表、剧本面板这些数据密集的页面，加载速度明显提升。
• Streaming SSR 让 AI 生成的内容可以流式返回——用户不用盯着加载动画等 30 秒。
• App Router 的路由组 (dashboard) 让我们可以按业务边界组织代码，同时保持干净的 URL 结构。

AI Agent 编排：Dramar 的大脑

Dramar 不是简单地在某个环节调用一次 AI——它是多个专业 AI Agent 在协作。

Agent 分工

• 剧本 Agent：解析剧本结构，提取角色和场景，分析情绪弧线
• 视觉 Agent：根据角色描述生成概念图，保持视觉一致性
• 分镜 Agent：将剧本场景转化为分镜帧，给出镜头建议
• 协作 Agent：总结讨论线程，跟踪反馈状态

编排模型

每个 Agent 独立运行，通过共享的项目上下文（Project Context）协调：

用户请求 → 编排器（分析意图）
              ├── 剧本 Agent（解析剧本）
              ├── 视觉 Agent（生成图像）
              └── 分镜 Agent（生成分镜板）
              ↓
         所有结果回写项目上下文 → 前端实时更新

这种设计的好处：

• Agent 可以独立迭代，互不阻塞
• 用户可以在任意环节介入，调整后重新触发
• 项目上下文是单一事实来源，所有 Agent 共享同一份角色/场景/分镜数据

持久化层的设计考量

Prisma 7 的 schema-first 方式让我们在设计阶段就把数据关系理清楚：

• Project → Episode → Script → StoryboardFrame → Image/Video：核心创作链
• Character / Scene / Prop：资产库，在项目级别复用
• Thread / Message：协作讨论，与具体资产关联
• AITask：异步 AI 任务的状态追踪

BullMQ 处理耗时的 AI 任务（生成视频、批量导出），避免阻塞用户交互。

Redis 除了队列，还缓存 AI 生成结果——同样的 Prompt，不用生成两次。

实时协作的实现

协作层基于 TipTap 的协作扩展，但 Dramar 做了额外的工作：

• 资产级别的评论锚点：在分镜帧或视频片段上直接标注，类似 Figma 的评论系统
• 线程化的讨论：每个项目可以有多个讨论线程（剧本讨论、分镜审查、视频反馈）
• 邀请制的外部协作：通过链接邀请协作者，控制权限

部署架构

用户浏览器
    ↓
CloudFront CDN
    ↓
Next.js Standalone (ECS Fargate)
    ↓
PostgreSQL (RDS)  ←→  Redis (ElastiCache)
    ↓
S3 (媒体存储)    ←→  BullMQ Workers

output: "standalone" 模式让 Docker 镜像从 ~500MB 降到了 ~120MB，冷启动时间减少 60%。

接下来的技术方向

1. 视频处理管线：FFmpeg + AI 的混合处理，支持片段拼接、转场、调色
2. 边缘渲染：把 AI 推理推到 Edge GPU，降低延迟
3. 实时协作增强：类似 Figma 的多光标协作体验
4. 开放 API：允许社区开发者创建自定义 Agent 和插件

---

如果你是开发者，对以上任何方向感兴趣，或想深入了解某个技术细节——欢迎通过 联系我们 告诉我们。我们会针对具体话题写更深入的技术文章。