说实话翻过年以后我朋友圈里做内容的、做技术的几乎都在聊AI短剧。门槛确实被大模型打下来了文生图、图生视频、数字人配音单拎出哪一个都不稀奇。可真到自己下场做会发现一个特别拧巴的事单集视频谁都能憋出来但一整部剧、一个账号稳定的日更、一个能接商单的内容盘子靠人肉盯是盯不出来的。我所在的项目组从2024年下半年开始折腾AI短剧一开始也是典型的散户玩法——本地电脑开三个网页Midjourney抽卡、剪映拼素材、ChatGPT写词一天肝一集质量还不能稳定。后来我们把整条生产链路拆开重新想了想最终沉淀出一套命名为“羽山数智”的方案第一版是画布Agent人坐在工作台前指挥多个智能体干活第二版直接重构为API编排的流水线Agent变成独立服务环节之间通过接口自动衔接。这篇文章就是把这两次迭代完整复盘一遍讲清楚为什么画布模式跑不通、API编排解决了什么、以及中途踩过的那些谁都绕不开的坑。如果你是个人创作者、小团队技术负责人或者正在评估AI短剧工具链的从业者这篇东西应该能帮你少走至少两个月的弯路。我不打算讲太多虚的架构图尽量用我们自己真实跑的配置、数据和翻车记录说话。1. AI短剧生产的本质问题不是缺创意是缺流程聊流水线之前得先把AI短剧的生产特性和传统视频制作摆在一起看。只有理解了差异才能理解为什么画布Agent和API编排这两种完全不同的东西会先后出现在我们的方案里。1.1 散户式生产的产能天花板先说个有点反直觉的结论AI短剧的内容瓶颈从来不在“生成”这一步而在“衔接”这一步。单个AI工具现在很强DeepSeek写剧本、可灵生成镜头、TTS配音每个环节单拿出来都能干活。但剧本写到第8集要回头改第3集埋的伏笔分镜拆完之后提示词和角色设定要保持全剧一致视频素材抽卡十几次挑出来的镜头剪辑时还得手动对齐台词时间轴。这些事情消耗的时间和精力远远大于AI生成本身。我们团队在散户模式下的真实数据是一个熟练操作者一天8小时最多完成1集3分钟短剧的全部物料准备。注意还只是“物料准备”配音、字幕、粗剪都还没算。这个产能别说日更周更都勉强。更麻烦的是质量波动。人注意力集中时提示词写得好、角色保持一致状态差一点主角的脸就从第2集开始飘了。这种“手工作坊”式的生产问题不在于慢而在于不可控。不可控就没法做计划没法做计划就没法接商业合作。1.2 工业化拆解一条AI短剧流水线到底要过几道工序后来我们用了最笨的方法——把从“一句话灵感”到“可发布成片”的完整链路逐个步骤写在白板上。写完之后自己也吓了一跳至少有10道核心工序剧情大纲生成与确认分场剧本写作每场的场景、角色、台词、动作镜头级分镜拆解景别、运镜、时长角色外观设定与一致性维护画面提示词生成文生图/图生视频用视频素材生成调用第三方视频API配音与音色角色分配字幕时间轴生成背景音乐选择与混音建议剪辑指令输出给剪辑师或剪辑程序执行顺着这个清单看所谓“工业化”不是让某一个AI模型变强而是把上面10道工序变成10个可以独立替换、独立调优、独立计费的环节并且让它们之间自动衔接。每个环节的输出必须是下一个环节能直接消费的输入而不是一坨需要人再解释一遍的自然语言。1.3 为什么先从“画布Agent”而不是直接上API编排按理说既然我们最终目标是要做API编排为什么不一步到位直接写代码调接口因为现实很骨感。我们团队最初的成员全是内容出身编剧、后期、运营没有一个能第一天就写Agent服务。而且对“流水线应该长什么样”最初的认知是模糊的——哪个环节需要人去定夺、哪个环节可以全自动不实际跑一轮根本不知道。这时候画布Agent给了我们一个特别好的缓冲把Agent当作画布上的卡片人和卡片交互卡片和卡片连线。本质上还是“人指挥、AI执行”但所有AI能力已经被拆成节点了。我们从一开始就不必写一行代码就能模拟未来的流水线结构。事实证明这个选择还算明智。我们在画布阶段踩出了流程里所有模糊地带也为后面API编排提供了清晰的蓝图。不然直接上代码大概率会写出一个“把一个错误流程自动化跑得飞快”的尴尬系统。2. 第一版画布Agent把编剧思维塞进可视化工作台先说明一点我们第一版并没有从零开发画布而是基于现成的Coze扣子工作流和Dify知识库流水线做的原型验证。后来发现约束太多才基于React Flow自己搭了轻量级画布。这个演进路径也推荐给各位参考——先抄现成的抄明白再自研。2.1 画布上挂着的五个Agent角色我们在第一版画布上挂了五个Agent职责分得非常清楚Agent名称核心职责输入输出剧本Agent生成/改写出分场剧本一句话梗概、人物设定分场剧本JSON分镜Agent把一场戏拆成镜头序列分场剧本镜头列表景别/运镜/时长/描述画面Agent将镜头描述转为文生图/图生视频的提示词镜头列表、角色外观库标准提示词包角色一致性Agent维护全剧角色外观参考库角色设定、历史生成图角色参考图与特征描述质检Agent检查前序节点的输出格式、内容一致性任意中间产物通过/驳回修改建议这五个Agent在画布上的连线方式和实际生产流程是一致的剧本Agent先跑产出分集剧本后连到分镜Agent分镜Agent的每一行镜头再连到画面Agent同时角色一致性Agent全程在线给画面Agent提供角色外观参考。质检Agent则挂在所有关键节点旁边没人敢把未经质检的产物往后丢。2.2 节点连接规则与中间产物协议画布模式跑了一个多月以后我们吃到最大的红利不是“AI很智能”而是强制大家定义了中间产物协议。具体来说每个Agent的输入输出都必须是结构化的JSON而不是自由文本。比如剧本Agent的输出格式长这样{ 集数: 3, 场次: [ { 场号: 3-1, 场景: 废弃仓库, 时间: 夜, 主要角色: [林深, 小满], 剧情摘要: 林深发现小满被绑架的线索, 台词与动作: [ { 角色: 林深, 类型: 台词, 内容: 他们连小满都敢动这事没完。, 动作提示: 攥紧手里的追踪器 } ] } ] }一开始团队觉得这样写很啰嗦不如直接扔一大段自然语言给下一个Agent。但很快发现没有JSON结构的话分镜Agent经常把两场的台词搞混质检Agent也没法自动判断输出是否合格。结构化协议不是为机器写的是为“人能读懂机器的状态”写的。画布上每个节点跑完团队成员点开节点就能看到结构化的产物流哪里断了、哪里格式错了一眼就清楚。2.3 画布模式的真实收益与隐藏成本画布阶段折腾了大概两个半月产出了大约40集短剧的物料。客观评价一下这个模式收益很明确。第一内容团队不用写代码也能理解AI生产流程协作成本大幅降低。第二中间产物可追溯。第12集画面崩了能顺着画布找回去是分镜描述问题还是提示词生成问题定位效率比散户模式高太多。第三Agent可以逐步优化——每个Agent都是独立卡片换掉其中一张比如把剧本Agent从DeepSeek换成GLM不影响其他节点。但隐藏成本也相当惊人。最核心的问题是画布的交互本质是“人找活”不是“活找人”。一个节点跑完需要人点一下确认再触发下一个节点。白天人可以坐那儿点晚上呢跑批量长剧的时候你还得定个闹钟半夜起来点这完全违背了“工业化”的初衷。另外画布节点的并发能力也堪忧。一个节点被多个上游触发时经常出现排队卡死Agent跑挂了重试逻辑得人肉干预。这些都成了我们后来下决心迁移到API编排的导火索。3. 什么逼着我从画布重构到API编排说实在的如果不是被逼到墙角我们是不太愿意重构的。画布模式好歹能用重新搭一套API编排体系意味着把已经跑通的逻辑全部服务化前后花了将近三周。但现在回头看这笔账算得太值了。3.1 人工确认节点成了产能瓶颈先算一笔账画布模式下一集短剧的中间产物要经过大约13次人机交互确认。假设每次确认需要30秒扫一眼JSON、判断没有明显错误、点击通过一集就是6.5分钟。如果一天生产10集光“确认”这件事就吃掉了一个小时以上的纯人工时间。更崩溃的是夜间的批量任务。我们把已完结小说的改编剧本丢进去一晚上本来应该跑完20集的分镜和提示词结果半夜某个分镜Agent返回了一个格式错误整个链路停在那儿。第二天到公司一看流水线死了6个小时人不在画布前流水线就“转不动”。这种体验让人非常沮丧AI都在干活了但整条线还是离不开人。我们尝试过在画布上做简单的自动跳转填写默认值、自动通过质检。结果更灾难——模型输出不稳定自动通过之后错误产物一路传到视频生成环节浪费了大量API额度。那段时间账户里烧掉的钱基本都是在为“自动通过”买单。3.2 从“画布交互”到“服务化Agent”的架构迁移痛定思痛我们做了一个决定把每个Agent封装成独立服务所有交互全部走API画布只保留监控和人工干预功能。这就是“羽山数智”方案的核心转折点。具体的架构今天回头梳理大概是这么几层Agent服务层每个Agent变成一个FastAPI进程暴露统一风格的process(input_json) - output_json接口。内部封装了对应的大模型调用、提示词模板、后处理逻辑。消息队列层用Redis Stream作为环节之间的缓冲。上游Agent的产出JSON直接推送到Stream下游Agent消费并处理互不阻塞。编排调度层核心是一个配置化的Pipeline Orchestrator。流程定义写在一个YAML文件里指定每一步调用哪个Agent、输入来自哪个Stream、输出推到哪个Stream。状态管理层每个短剧项目的每集生成任务都维护一个状态机。状态包括待执行、执行中、已完成、失败、重试中、人工介入中。状态存在Redis里界面能实时看到整条流水线在哪个环节卡住了。这套架构对开发人员来说没什么新鲜的标准的任务队列工作流引擎思路。但对内容团队来说变化是巨大的他们不再需要盯着画布手动触发节点了而是变成“监控者”。每天早上看一眼仪表盘昨夜20集跑到哪一步、有没有失败的、需要人工纠正的有几处一目了然。3.3 编排层与状态机设计流水线要能断点续跑给准备抄作业的朋友一个核心建议状态机设计是API编排方案的灵魂比Agent本身的能力还重要。我们的状态机一开始设计得太简单就是“成功/失败”两个状态。结果视频生成API偶尔超时、返回空结果Agent执行到一半进程被杀整个任务就永久卡在“执行中”。改了几轮之后最终状态集是下面这些状态含义触发条件PENDING等待执行上游已完成消息已入队RUNNING执行中消费者拉取到消息SUCCEEDED成功Agent返回合法JSONFAILED失败可重试网络异常、API超时、JSON解析失败DEAD死信需人工介入重试3次仍失败、输出语义不符MANUAL_REVIEW人工介入中质检Agent判定需人工确认这里有个特别值得说的设计重试要有退避策略但不能无限重试。我们让每个任务最多重试3次间隔分别是30秒、2分钟、5分钟。超过3次直接进DEAD死信队列由值班的人手工处理。因为这个策略流水线从“一错就全线瘫痪”变成了“局部失败不影响整体”其他集数照跑坏的那集单独修。人工介入这件事也没被完全取消但性质变了画布阶段是人必须守在生产线上API编排阶段是人只在异常时出现。从“人肉保障流程”变成了“人对异常兜底”这才是工业化流水线和自动化流水线的本质区别。4. 羽山数智的Agent分工表每个环节该用谁、产出什么架构迁移完成后我们把Agent从最初的5个扩展到了7个。这里把每个Agent的角色分工、模型选型、产出格式完整列出来。这套分工不是拍脑袋定的是跑了几十集之后沉淀的稳定形态。4.1 从剧本到成片的七个Agent节点序号Agent职责范围模型/服务选型实测产出1分集大纲Agent把整部剧的梗概拆成分集大纲DeepSeek APIdeepseek-v4系列每集的大纲JSON2剧本Agent按分集大纲写/改分场剧本DeepSeek API分场剧本JSON3分镜Agent将一场戏拆成镜头级描述智谱GLM长上下文表现好镜头列表JSON4画面提示词Agent把镜头描述角色参考图转成提示词包自研模板多模型回退标准提示词包5角色一致性Agent维护角色外观特征、生成参考图文生图API人脸特征相似度校验角色参考图库6视频生成Agent调用第三方文生视频API生成素材可灵/即梦或同类API视频片段文件列表7后期打包Agent字幕时间轴、配音段落、剪辑指令TTS API 自研时间轴逻辑剪辑工程文件/指令这里面的关键认知是没有一个模型是万能的每个Agent选择不同的基座模型是常态。比如剧本写作DeepSeek在长文本剧情连贯性上表现明显更好但分镜拆解时面对很长的场次描写GLM的超长上下文窗口更稳。这就是为什么必须做API编排而不是绑死在一个平台内——每家模型的差异化优势只有通过统一接口才能组合成最优流水线。4.2 Agent间消息协议JSON Schema是救命稻草画布阶段我们定义了JSON字段但字段的含义经常变导致下游Agent解析出错。API编排阶段我们把这件事彻底规范了给每类中间产物写JSON SchemaAgent启动时直接加载Schema输出必须通过校验才算成功。一个简化版的分镜产物Schema大概是{ $schema: http://json-schema.org/draft-07/schema#, type: object, required: [镜头ID, 景别, 运镜, 时长秒, 画面描述, 台词], properties: { 镜头ID: { type: string }, 景别: { enum: [远景, 全景, 中景, 近景, 特写] }, 运镜: { enum: [固定, 推, 拉, 摇, 移, 跟] }, 时长秒: { type: number, minimum: 2, maximum: 8 }, 画面描述: { type: string }, 台词: { type: array, items: { type: string } } } }别小看这个约束。有了Schema质检Agent的活儿从“让大模型判断内容好坏”变成了“先校验格式再抽检语义”。格式校验是机器做的100%覆盖语义判断才交给大模型抽样做。这种“程序校验模型抽检”的双层质检策略是流水线稳定运行到现在最关键的机制之一。Schema带来的另一个好处是Agent之间的耦合彻底解除了。只要遵守Schema你甚至可以临时替换掉视频生成Agent接入另一家新发布的视频API流水线本身一行都不用改。4.3 能耗与成本跑一集到底花多少钱很多人关心AI短剧的成本这里把我们在API编排稳定运行后的实测数据列一下。以一部15集的付费短剧为参考每集约2分钟实际成片镜头约14-18个成本项目单集实测成本人民币说明LLM调用剧本分镜提示词3-6元包含多次修改重试的token文生图角色一致性参考1-2元一次性成本摊薄到每集文生视频素材6-15元厂商按生成时长计费抽卡会抬高成本TTS配音1-2元按字符数计费API网关/队列/存储约1元服务器和消息队列摊薄合计约12-26元/集不含人工后期调优相比纯人工作坊成本没有数量级下降甚至某些环节更贵因为抽卡和重试。但时间成本下降是数量级的散户模式一集大约1人天流水线模式下一集全自动跑约15-25分钟。省下来的时间投入到剧本打磨和运营分发上这才是工业化的真实价值。5. 落地半年踩过的坑每一个都是真金白银这部分本来想写得简单点但想着很多朋友可能是看了标题进来的就是想知道实际跑的时候哪里会炸。我挑五个最典型的问题复盘当时的完整排查链路。5.1 上下文爆炸长剧本切片切出断裂剧情第一次出问题是在跑一部40集长剧时单集剧本的实际token长度超过模型上下文窗口。我们的第一反应很朴素把剧本切成两半分两次送给分镜Agent。结果分镜结果一出来发现第13场的镜头和第12场完全接不上角色在同一地点前一场还在说台词后一场突然换了个场景。排查链路是这样的对比完整剧本和切片后的两段确认切片点正好落在第12场和第13场之间。查看分镜Agent的日志发现它处理第二段时确实没有第12场的上下文。临时止损方案加大切片重叠长度确保每个切片包含前一场和后一场的描述。这个坑的根因不是切片本身而是没有理解“剧情场景的上下文边界不等于文本切片的边界”。切片必须尊重语义单元最稳妥的切法是以“场”为单位切而不是按字符数硬切。后来我们把分镜Agent的输入设计成“当前场前后各一场”彻底解决了断裂问题。5.2 格式漂移模型不听话时不只靠prompt即便要求“只输出JSON”模型还是偶尔夹杂解释文字或者把JSON字段名改成近义词。一开始我们的质检Agent会尝试用大模型“修复”格式结果越修越偏甚至把原本正确的内容改没了。后来改成了三层兜底第一层用response_format{type: json_object}强制JSON输出。第二层解析失败时从模型返回的文本里正则提取JSON块提取到就继续。第三层前两层都失败任务进DEAD死信不自动重试。这套兜底上线后格式漂移导致的任务失败率从大约7%降到了不到1%。一个特别重要的经验不要相信prompt能100%约束模型行为要用程序和协议来兜底。模型输出本质上是概率性的但流水线不能是概率性的。5.3 角色一致性画布阶段最头疼的问题第一版画布阶段角色外观全靠在提示词里写“黑色长发、冷峻眼神、黑色皮衣”。结果不同集数里角色脸型经常突变。质检Agent用CLIP算相似度很多场景下相似度只有0.6出头人眼看着都别扭。排查下来根因有两个方面一是文字描述本身有歧义不同模型对“冷峻眼神”的理解差异很大二是我们图生视频时参考图用的不是最新生成的角色图导致漂移累计。解决路径分两条走一是建角色特征库每个主角生成5张不同角度的“基准面部图”所有生成任务统一携带基准图二是接入人脸特征相似度算法新生成的正脸镜头必须和角色基准图相似度达到阈值才进入素材库。这套机制跑下来角色一致性算是在工程上被按住了。5.4 第三方API的限流、scope和超时做API编排绕不开第三方接口。我们先后接入过至少5家文生图、文生视频API每一家都有自己的脾气有的限流策略是QPS有的是并发数还有的按账号总调用量阶梯限制。印象最深的一次故障新增一个视频生成供应商后全平台报错“API scope is not declared”。排查发现该供应商的接口文档里默认不含文生视频的scope需要在控制台显式申请开通而我们的代码已经按文档把全量能力都注册了。这种问题在文档上根本看不出来只有真实调用才会暴露。给所有做AI应用的同学一个忠告集成第三方API时一定要写一个独立的API健康检查模块按固定频率探活所有依赖服务。否则一个上游API悄悄改了策略你的流水线会莫名其妙死一整夜。5.5 断点续跑的坑状态机设计不当时整条线变废线状态机如果没设计好最痛的场景是“任务完成了但状态没推进”。我们出现过一次事故视频生成Agent已经调用Kling生成完素材但回调时进程重启任务状态仍停在RUNNING重试逻辑又触发了一次新生成多花了一笔钱。排查过程让我们重新设计了回调幂等性每个生成任务生成唯一的client_request_id。回调到达时先查这个ID对应的任务状态是否为SUCCEEDED。如果是直接丢弃。任务状态更新必须在同一事务里绑定“业务数据落库”和“状态流转”。这之后类似问题基本绝迹。在做任何自动化的机器系统时“幂等”两个字值得写进编码规范的第一页。6. 这条流水线现在的运行实况与后续演进写到这给正在评估要不要投入做AI短剧流水线的朋友一个客观的画面说说这套“羽山数智”方案目前到底跑成什么样。6.1 产能与成本数据目前的稳定产能是一条流水线算上夜间无人值守日均产出15-18集2分钟短剧的全部中间物料。人工介入率大约是15%也就是说100集里大概有15集需要人来修正角色设定或分镜逻辑。修正之后整集物料可以重新注入流水线继续跑不需要全部重来。单集综合成本含LLM、视频生成、TTS、存储稳定在20元上下。对比一个简单的数字如果请人实拍一集短剧不算演员和场地光是摄影和灯光器材的日均成本就不止这个数。这就是AI短剧工业化最残酷也最迷人的地方——规模化的边际成本被压到了接近于零剩下拼的就是内容判断力和运营能力。6.2 Agent从“执行者”走向“调度者”API编排稳定后我们开始做下一个实验把调度权也交给Agent。具体来说不再用写死的YAML流程定义而是让一个“总控Agent”根据当前项目类型甜宠、悬疑、逆袭动态选择流程分支。比如悬疑剧需要额外的“伏笔管理Agent”在剧本阶段做线索追踪甜宠剧则不启用。这个方向还在验证中但初步判断是Agent动态编排适合流程有分叉的场景但在单一路径的批量生产里写死的编排反而更稳。工业化的第一要义是确定性创新反而应该放在画布环境里做试验。我们的定位是“画布用来跑实验API编排用来跑生产”两者并存而不是替代。6.3 给准备入局的人一句实在话最后说点掏心窝子的。如果你只是想低成本验证AI短剧这件事不要一上来就整流水线——先用现成的画布工具和免费API做出第一集亲手跑通再谈复制。如果你已经确定单集生产模式跑通了、遇到了产能和稳定性的瓶颈那么API编排这套路几乎是你必走的下一步。但有一点务必想清楚流水线解决的是“稳定产出”的问题解决不了“内容能不能火”的问题。AI短剧赛道现在不缺产能缺的是能抓住观众情绪的剧本、有记忆点的角色、以及持续稳定的运营。工具链只是给了你把好想法快速变成成品的能力它不会替你想出好想法。我个人现在最深的体会是别把精力耗在“让AI生成得更快”上——这一层已经被API厂商解决了。真正的护城河在于你怎么设计流程的衔接点怎么定义质量的标准以及怎么在人工介入最少的情况下保证每一集都不会背叛整个系列的世界观和角色人设。这套“流程设计”的能力才是AI短剧工业化这半年教会我们最值钱的东西。
AI短剧工业化：从画布Agent到API编排的流水线演进
说实话翻过年以后我朋友圈里做内容的、做技术的几乎都在聊AI短剧。门槛确实被大模型打下来了文生图、图生视频、数字人配音单拎出哪一个都不稀奇。可真到自己下场做会发现一个特别拧巴的事单集视频谁都能憋出来但一整部剧、一个账号稳定的日更、一个能接商单的内容盘子靠人肉盯是盯不出来的。我所在的项目组从2024年下半年开始折腾AI短剧一开始也是典型的散户玩法——本地电脑开三个网页Midjourney抽卡、剪映拼素材、ChatGPT写词一天肝一集质量还不能稳定。后来我们把整条生产链路拆开重新想了想最终沉淀出一套命名为“羽山数智”的方案第一版是画布Agent人坐在工作台前指挥多个智能体干活第二版直接重构为API编排的流水线Agent变成独立服务环节之间通过接口自动衔接。这篇文章就是把这两次迭代完整复盘一遍讲清楚为什么画布模式跑不通、API编排解决了什么、以及中途踩过的那些谁都绕不开的坑。如果你是个人创作者、小团队技术负责人或者正在评估AI短剧工具链的从业者这篇东西应该能帮你少走至少两个月的弯路。我不打算讲太多虚的架构图尽量用我们自己真实跑的配置、数据和翻车记录说话。1. AI短剧生产的本质问题不是缺创意是缺流程聊流水线之前得先把AI短剧的生产特性和传统视频制作摆在一起看。只有理解了差异才能理解为什么画布Agent和API编排这两种完全不同的东西会先后出现在我们的方案里。1.1 散户式生产的产能天花板先说个有点反直觉的结论AI短剧的内容瓶颈从来不在“生成”这一步而在“衔接”这一步。单个AI工具现在很强DeepSeek写剧本、可灵生成镜头、TTS配音每个环节单拿出来都能干活。但剧本写到第8集要回头改第3集埋的伏笔分镜拆完之后提示词和角色设定要保持全剧一致视频素材抽卡十几次挑出来的镜头剪辑时还得手动对齐台词时间轴。这些事情消耗的时间和精力远远大于AI生成本身。我们团队在散户模式下的真实数据是一个熟练操作者一天8小时最多完成1集3分钟短剧的全部物料准备。注意还只是“物料准备”配音、字幕、粗剪都还没算。这个产能别说日更周更都勉强。更麻烦的是质量波动。人注意力集中时提示词写得好、角色保持一致状态差一点主角的脸就从第2集开始飘了。这种“手工作坊”式的生产问题不在于慢而在于不可控。不可控就没法做计划没法做计划就没法接商业合作。1.2 工业化拆解一条AI短剧流水线到底要过几道工序后来我们用了最笨的方法——把从“一句话灵感”到“可发布成片”的完整链路逐个步骤写在白板上。写完之后自己也吓了一跳至少有10道核心工序剧情大纲生成与确认分场剧本写作每场的场景、角色、台词、动作镜头级分镜拆解景别、运镜、时长角色外观设定与一致性维护画面提示词生成文生图/图生视频用视频素材生成调用第三方视频API配音与音色角色分配字幕时间轴生成背景音乐选择与混音建议剪辑指令输出给剪辑师或剪辑程序执行顺着这个清单看所谓“工业化”不是让某一个AI模型变强而是把上面10道工序变成10个可以独立替换、独立调优、独立计费的环节并且让它们之间自动衔接。每个环节的输出必须是下一个环节能直接消费的输入而不是一坨需要人再解释一遍的自然语言。1.3 为什么先从“画布Agent”而不是直接上API编排按理说既然我们最终目标是要做API编排为什么不一步到位直接写代码调接口因为现实很骨感。我们团队最初的成员全是内容出身编剧、后期、运营没有一个能第一天就写Agent服务。而且对“流水线应该长什么样”最初的认知是模糊的——哪个环节需要人去定夺、哪个环节可以全自动不实际跑一轮根本不知道。这时候画布Agent给了我们一个特别好的缓冲把Agent当作画布上的卡片人和卡片交互卡片和卡片连线。本质上还是“人指挥、AI执行”但所有AI能力已经被拆成节点了。我们从一开始就不必写一行代码就能模拟未来的流水线结构。事实证明这个选择还算明智。我们在画布阶段踩出了流程里所有模糊地带也为后面API编排提供了清晰的蓝图。不然直接上代码大概率会写出一个“把一个错误流程自动化跑得飞快”的尴尬系统。2. 第一版画布Agent把编剧思维塞进可视化工作台先说明一点我们第一版并没有从零开发画布而是基于现成的Coze扣子工作流和Dify知识库流水线做的原型验证。后来发现约束太多才基于React Flow自己搭了轻量级画布。这个演进路径也推荐给各位参考——先抄现成的抄明白再自研。2.1 画布上挂着的五个Agent角色我们在第一版画布上挂了五个Agent职责分得非常清楚Agent名称核心职责输入输出剧本Agent生成/改写出分场剧本一句话梗概、人物设定分场剧本JSON分镜Agent把一场戏拆成镜头序列分场剧本镜头列表景别/运镜/时长/描述画面Agent将镜头描述转为文生图/图生视频的提示词镜头列表、角色外观库标准提示词包角色一致性Agent维护全剧角色外观参考库角色设定、历史生成图角色参考图与特征描述质检Agent检查前序节点的输出格式、内容一致性任意中间产物通过/驳回修改建议这五个Agent在画布上的连线方式和实际生产流程是一致的剧本Agent先跑产出分集剧本后连到分镜Agent分镜Agent的每一行镜头再连到画面Agent同时角色一致性Agent全程在线给画面Agent提供角色外观参考。质检Agent则挂在所有关键节点旁边没人敢把未经质检的产物往后丢。2.2 节点连接规则与中间产物协议画布模式跑了一个多月以后我们吃到最大的红利不是“AI很智能”而是强制大家定义了中间产物协议。具体来说每个Agent的输入输出都必须是结构化的JSON而不是自由文本。比如剧本Agent的输出格式长这样{ 集数: 3, 场次: [ { 场号: 3-1, 场景: 废弃仓库, 时间: 夜, 主要角色: [林深, 小满], 剧情摘要: 林深发现小满被绑架的线索, 台词与动作: [ { 角色: 林深, 类型: 台词, 内容: 他们连小满都敢动这事没完。, 动作提示: 攥紧手里的追踪器 } ] } ] }一开始团队觉得这样写很啰嗦不如直接扔一大段自然语言给下一个Agent。但很快发现没有JSON结构的话分镜Agent经常把两场的台词搞混质检Agent也没法自动判断输出是否合格。结构化协议不是为机器写的是为“人能读懂机器的状态”写的。画布上每个节点跑完团队成员点开节点就能看到结构化的产物流哪里断了、哪里格式错了一眼就清楚。2.3 画布模式的真实收益与隐藏成本画布阶段折腾了大概两个半月产出了大约40集短剧的物料。客观评价一下这个模式收益很明确。第一内容团队不用写代码也能理解AI生产流程协作成本大幅降低。第二中间产物可追溯。第12集画面崩了能顺着画布找回去是分镜描述问题还是提示词生成问题定位效率比散户模式高太多。第三Agent可以逐步优化——每个Agent都是独立卡片换掉其中一张比如把剧本Agent从DeepSeek换成GLM不影响其他节点。但隐藏成本也相当惊人。最核心的问题是画布的交互本质是“人找活”不是“活找人”。一个节点跑完需要人点一下确认再触发下一个节点。白天人可以坐那儿点晚上呢跑批量长剧的时候你还得定个闹钟半夜起来点这完全违背了“工业化”的初衷。另外画布节点的并发能力也堪忧。一个节点被多个上游触发时经常出现排队卡死Agent跑挂了重试逻辑得人肉干预。这些都成了我们后来下决心迁移到API编排的导火索。3. 什么逼着我从画布重构到API编排说实在的如果不是被逼到墙角我们是不太愿意重构的。画布模式好歹能用重新搭一套API编排体系意味着把已经跑通的逻辑全部服务化前后花了将近三周。但现在回头看这笔账算得太值了。3.1 人工确认节点成了产能瓶颈先算一笔账画布模式下一集短剧的中间产物要经过大约13次人机交互确认。假设每次确认需要30秒扫一眼JSON、判断没有明显错误、点击通过一集就是6.5分钟。如果一天生产10集光“确认”这件事就吃掉了一个小时以上的纯人工时间。更崩溃的是夜间的批量任务。我们把已完结小说的改编剧本丢进去一晚上本来应该跑完20集的分镜和提示词结果半夜某个分镜Agent返回了一个格式错误整个链路停在那儿。第二天到公司一看流水线死了6个小时人不在画布前流水线就“转不动”。这种体验让人非常沮丧AI都在干活了但整条线还是离不开人。我们尝试过在画布上做简单的自动跳转填写默认值、自动通过质检。结果更灾难——模型输出不稳定自动通过之后错误产物一路传到视频生成环节浪费了大量API额度。那段时间账户里烧掉的钱基本都是在为“自动通过”买单。3.2 从“画布交互”到“服务化Agent”的架构迁移痛定思痛我们做了一个决定把每个Agent封装成独立服务所有交互全部走API画布只保留监控和人工干预功能。这就是“羽山数智”方案的核心转折点。具体的架构今天回头梳理大概是这么几层Agent服务层每个Agent变成一个FastAPI进程暴露统一风格的process(input_json) - output_json接口。内部封装了对应的大模型调用、提示词模板、后处理逻辑。消息队列层用Redis Stream作为环节之间的缓冲。上游Agent的产出JSON直接推送到Stream下游Agent消费并处理互不阻塞。编排调度层核心是一个配置化的Pipeline Orchestrator。流程定义写在一个YAML文件里指定每一步调用哪个Agent、输入来自哪个Stream、输出推到哪个Stream。状态管理层每个短剧项目的每集生成任务都维护一个状态机。状态包括待执行、执行中、已完成、失败、重试中、人工介入中。状态存在Redis里界面能实时看到整条流水线在哪个环节卡住了。这套架构对开发人员来说没什么新鲜的标准的任务队列工作流引擎思路。但对内容团队来说变化是巨大的他们不再需要盯着画布手动触发节点了而是变成“监控者”。每天早上看一眼仪表盘昨夜20集跑到哪一步、有没有失败的、需要人工纠正的有几处一目了然。3.3 编排层与状态机设计流水线要能断点续跑给准备抄作业的朋友一个核心建议状态机设计是API编排方案的灵魂比Agent本身的能力还重要。我们的状态机一开始设计得太简单就是“成功/失败”两个状态。结果视频生成API偶尔超时、返回空结果Agent执行到一半进程被杀整个任务就永久卡在“执行中”。改了几轮之后最终状态集是下面这些状态含义触发条件PENDING等待执行上游已完成消息已入队RUNNING执行中消费者拉取到消息SUCCEEDED成功Agent返回合法JSONFAILED失败可重试网络异常、API超时、JSON解析失败DEAD死信需人工介入重试3次仍失败、输出语义不符MANUAL_REVIEW人工介入中质检Agent判定需人工确认这里有个特别值得说的设计重试要有退避策略但不能无限重试。我们让每个任务最多重试3次间隔分别是30秒、2分钟、5分钟。超过3次直接进DEAD死信队列由值班的人手工处理。因为这个策略流水线从“一错就全线瘫痪”变成了“局部失败不影响整体”其他集数照跑坏的那集单独修。人工介入这件事也没被完全取消但性质变了画布阶段是人必须守在生产线上API编排阶段是人只在异常时出现。从“人肉保障流程”变成了“人对异常兜底”这才是工业化流水线和自动化流水线的本质区别。4. 羽山数智的Agent分工表每个环节该用谁、产出什么架构迁移完成后我们把Agent从最初的5个扩展到了7个。这里把每个Agent的角色分工、模型选型、产出格式完整列出来。这套分工不是拍脑袋定的是跑了几十集之后沉淀的稳定形态。4.1 从剧本到成片的七个Agent节点序号Agent职责范围模型/服务选型实测产出1分集大纲Agent把整部剧的梗概拆成分集大纲DeepSeek APIdeepseek-v4系列每集的大纲JSON2剧本Agent按分集大纲写/改分场剧本DeepSeek API分场剧本JSON3分镜Agent将一场戏拆成镜头级描述智谱GLM长上下文表现好镜头列表JSON4画面提示词Agent把镜头描述角色参考图转成提示词包自研模板多模型回退标准提示词包5角色一致性Agent维护角色外观特征、生成参考图文生图API人脸特征相似度校验角色参考图库6视频生成Agent调用第三方文生视频API生成素材可灵/即梦或同类API视频片段文件列表7后期打包Agent字幕时间轴、配音段落、剪辑指令TTS API 自研时间轴逻辑剪辑工程文件/指令这里面的关键认知是没有一个模型是万能的每个Agent选择不同的基座模型是常态。比如剧本写作DeepSeek在长文本剧情连贯性上表现明显更好但分镜拆解时面对很长的场次描写GLM的超长上下文窗口更稳。这就是为什么必须做API编排而不是绑死在一个平台内——每家模型的差异化优势只有通过统一接口才能组合成最优流水线。4.2 Agent间消息协议JSON Schema是救命稻草画布阶段我们定义了JSON字段但字段的含义经常变导致下游Agent解析出错。API编排阶段我们把这件事彻底规范了给每类中间产物写JSON SchemaAgent启动时直接加载Schema输出必须通过校验才算成功。一个简化版的分镜产物Schema大概是{ $schema: http://json-schema.org/draft-07/schema#, type: object, required: [镜头ID, 景别, 运镜, 时长秒, 画面描述, 台词], properties: { 镜头ID: { type: string }, 景别: { enum: [远景, 全景, 中景, 近景, 特写] }, 运镜: { enum: [固定, 推, 拉, 摇, 移, 跟] }, 时长秒: { type: number, minimum: 2, maximum: 8 }, 画面描述: { type: string }, 台词: { type: array, items: { type: string } } } }别小看这个约束。有了Schema质检Agent的活儿从“让大模型判断内容好坏”变成了“先校验格式再抽检语义”。格式校验是机器做的100%覆盖语义判断才交给大模型抽样做。这种“程序校验模型抽检”的双层质检策略是流水线稳定运行到现在最关键的机制之一。Schema带来的另一个好处是Agent之间的耦合彻底解除了。只要遵守Schema你甚至可以临时替换掉视频生成Agent接入另一家新发布的视频API流水线本身一行都不用改。4.3 能耗与成本跑一集到底花多少钱很多人关心AI短剧的成本这里把我们在API编排稳定运行后的实测数据列一下。以一部15集的付费短剧为参考每集约2分钟实际成片镜头约14-18个成本项目单集实测成本人民币说明LLM调用剧本分镜提示词3-6元包含多次修改重试的token文生图角色一致性参考1-2元一次性成本摊薄到每集文生视频素材6-15元厂商按生成时长计费抽卡会抬高成本TTS配音1-2元按字符数计费API网关/队列/存储约1元服务器和消息队列摊薄合计约12-26元/集不含人工后期调优相比纯人工作坊成本没有数量级下降甚至某些环节更贵因为抽卡和重试。但时间成本下降是数量级的散户模式一集大约1人天流水线模式下一集全自动跑约15-25分钟。省下来的时间投入到剧本打磨和运营分发上这才是工业化的真实价值。5. 落地半年踩过的坑每一个都是真金白银这部分本来想写得简单点但想着很多朋友可能是看了标题进来的就是想知道实际跑的时候哪里会炸。我挑五个最典型的问题复盘当时的完整排查链路。5.1 上下文爆炸长剧本切片切出断裂剧情第一次出问题是在跑一部40集长剧时单集剧本的实际token长度超过模型上下文窗口。我们的第一反应很朴素把剧本切成两半分两次送给分镜Agent。结果分镜结果一出来发现第13场的镜头和第12场完全接不上角色在同一地点前一场还在说台词后一场突然换了个场景。排查链路是这样的对比完整剧本和切片后的两段确认切片点正好落在第12场和第13场之间。查看分镜Agent的日志发现它处理第二段时确实没有第12场的上下文。临时止损方案加大切片重叠长度确保每个切片包含前一场和后一场的描述。这个坑的根因不是切片本身而是没有理解“剧情场景的上下文边界不等于文本切片的边界”。切片必须尊重语义单元最稳妥的切法是以“场”为单位切而不是按字符数硬切。后来我们把分镜Agent的输入设计成“当前场前后各一场”彻底解决了断裂问题。5.2 格式漂移模型不听话时不只靠prompt即便要求“只输出JSON”模型还是偶尔夹杂解释文字或者把JSON字段名改成近义词。一开始我们的质检Agent会尝试用大模型“修复”格式结果越修越偏甚至把原本正确的内容改没了。后来改成了三层兜底第一层用response_format{type: json_object}强制JSON输出。第二层解析失败时从模型返回的文本里正则提取JSON块提取到就继续。第三层前两层都失败任务进DEAD死信不自动重试。这套兜底上线后格式漂移导致的任务失败率从大约7%降到了不到1%。一个特别重要的经验不要相信prompt能100%约束模型行为要用程序和协议来兜底。模型输出本质上是概率性的但流水线不能是概率性的。5.3 角色一致性画布阶段最头疼的问题第一版画布阶段角色外观全靠在提示词里写“黑色长发、冷峻眼神、黑色皮衣”。结果不同集数里角色脸型经常突变。质检Agent用CLIP算相似度很多场景下相似度只有0.6出头人眼看着都别扭。排查下来根因有两个方面一是文字描述本身有歧义不同模型对“冷峻眼神”的理解差异很大二是我们图生视频时参考图用的不是最新生成的角色图导致漂移累计。解决路径分两条走一是建角色特征库每个主角生成5张不同角度的“基准面部图”所有生成任务统一携带基准图二是接入人脸特征相似度算法新生成的正脸镜头必须和角色基准图相似度达到阈值才进入素材库。这套机制跑下来角色一致性算是在工程上被按住了。5.4 第三方API的限流、scope和超时做API编排绕不开第三方接口。我们先后接入过至少5家文生图、文生视频API每一家都有自己的脾气有的限流策略是QPS有的是并发数还有的按账号总调用量阶梯限制。印象最深的一次故障新增一个视频生成供应商后全平台报错“API scope is not declared”。排查发现该供应商的接口文档里默认不含文生视频的scope需要在控制台显式申请开通而我们的代码已经按文档把全量能力都注册了。这种问题在文档上根本看不出来只有真实调用才会暴露。给所有做AI应用的同学一个忠告集成第三方API时一定要写一个独立的API健康检查模块按固定频率探活所有依赖服务。否则一个上游API悄悄改了策略你的流水线会莫名其妙死一整夜。5.5 断点续跑的坑状态机设计不当时整条线变废线状态机如果没设计好最痛的场景是“任务完成了但状态没推进”。我们出现过一次事故视频生成Agent已经调用Kling生成完素材但回调时进程重启任务状态仍停在RUNNING重试逻辑又触发了一次新生成多花了一笔钱。排查过程让我们重新设计了回调幂等性每个生成任务生成唯一的client_request_id。回调到达时先查这个ID对应的任务状态是否为SUCCEEDED。如果是直接丢弃。任务状态更新必须在同一事务里绑定“业务数据落库”和“状态流转”。这之后类似问题基本绝迹。在做任何自动化的机器系统时“幂等”两个字值得写进编码规范的第一页。6. 这条流水线现在的运行实况与后续演进写到这给正在评估要不要投入做AI短剧流水线的朋友一个客观的画面说说这套“羽山数智”方案目前到底跑成什么样。6.1 产能与成本数据目前的稳定产能是一条流水线算上夜间无人值守日均产出15-18集2分钟短剧的全部中间物料。人工介入率大约是15%也就是说100集里大概有15集需要人来修正角色设定或分镜逻辑。修正之后整集物料可以重新注入流水线继续跑不需要全部重来。单集综合成本含LLM、视频生成、TTS、存储稳定在20元上下。对比一个简单的数字如果请人实拍一集短剧不算演员和场地光是摄影和灯光器材的日均成本就不止这个数。这就是AI短剧工业化最残酷也最迷人的地方——规模化的边际成本被压到了接近于零剩下拼的就是内容判断力和运营能力。6.2 Agent从“执行者”走向“调度者”API编排稳定后我们开始做下一个实验把调度权也交给Agent。具体来说不再用写死的YAML流程定义而是让一个“总控Agent”根据当前项目类型甜宠、悬疑、逆袭动态选择流程分支。比如悬疑剧需要额外的“伏笔管理Agent”在剧本阶段做线索追踪甜宠剧则不启用。这个方向还在验证中但初步判断是Agent动态编排适合流程有分叉的场景但在单一路径的批量生产里写死的编排反而更稳。工业化的第一要义是确定性创新反而应该放在画布环境里做试验。我们的定位是“画布用来跑实验API编排用来跑生产”两者并存而不是替代。6.3 给准备入局的人一句实在话最后说点掏心窝子的。如果你只是想低成本验证AI短剧这件事不要一上来就整流水线——先用现成的画布工具和免费API做出第一集亲手跑通再谈复制。如果你已经确定单集生产模式跑通了、遇到了产能和稳定性的瓶颈那么API编排这套路几乎是你必走的下一步。但有一点务必想清楚流水线解决的是“稳定产出”的问题解决不了“内容能不能火”的问题。AI短剧赛道现在不缺产能缺的是能抓住观众情绪的剧本、有记忆点的角色、以及持续稳定的运营。工具链只是给了你把好想法快速变成成品的能力它不会替你想出好想法。我个人现在最深的体会是别把精力耗在“让AI生成得更快”上——这一层已经被API厂商解决了。真正的护城河在于你怎么设计流程的衔接点怎么定义质量的标准以及怎么在人工介入最少的情况下保证每一集都不会背叛整个系列的世界观和角色人设。这套“流程设计”的能力才是AI短剧工业化这半年教会我们最值钱的东西。