夜雨聆风大家好，我是爱玩AI的Ray
AI工程师｜产品经理
最近在为剧本质量提升寻找思路，在 github 中，很多短剧制作工具，剧本制作基本上作为其中一个环节嵌套在其中，正好从产品形态上，对他们做一个框架测评。
单就短剧的剧本生成方向来说，确实是一个很典型的 Agent 项目。Agent 的角色是编剧，用户的输入是剧本主题或者参考的剧本、小说，执行的 SOP 也相对清晰，世界观-故事大纲-角色小传-试稿-完稿，最后的输出也很明确，就是剧本全稿。
一、短剧制作工具分析
这次一起分析了 6 个口碑不错的开源项目。
1. Toonflow
Star 数：14.1k。开源一站式 AI 短剧创作工具，将小说、剧本快速转化为动画短剧。集成 AI 编剧、智能分镜、角色与视频生成，跨平台桌面端轻量部署，助力创作者低成本批量产出视觉内容。
Agent-first 的制作工具，简单试用了一下，整体功能确实很强大。 他背后的 Agent 流程设计，使用TS脚本作为 Agent 的编排层，再用markdown 定义的 skill 作为大模型的执行提示词补充，会包括：1 个意图识别 Skill、N 个执行 Skill、1 个监督 Skill。 整体而言，TS 是 Agent 编排层，Skill Markdown 是执行规范；Socket 提供交互和流式通信，SQLite 保存跨轮状态。主 Agent 通过 Tool Calling 调度改写、拆分、审查等子 Agent，工具结果回到决策模型继续推理。
继承 Agent-first 的优势，天然适合开放式创作，不过底层是自主实现的，如果我要解析一部 50 万字往上的网文的话，上下文管理、协同等优化，就要针对场景进行专门调优。
2. huobao
Star 数：14.0k。基于AI的一站式短剧生成平台 《一句话生成完整短剧，从剧本到成片全自动化》
更加传统的程序化工具，将 Agent 应用嵌入代码生产流水线，相当于把 Agent 就当执行黑盒接口。 里面有 4 个核心的 Agent：script_rewriter、extractor、storyboard_breaker、prompt_generator，每个 Agent 由Prompt、Skills、Tools组成。由前台工具触发 Agent 的执行，程序获取返回后进行界面呈现。 他有个亮点， 在于 Agent 的 Prompt 是可以在线编辑的，一定程度上增加了执行的灵活度。
Agent 和程序的边界很清晰，对于 Agent 的返回也会进行强校验，生产链路更加稳定。不过没有决策 Agent、监督 Agent 或长期会话记忆，代码的逻辑编排决定了 AI 的应用。
3. LumenX
Star 数：1.1k。阿里开源的 AI 漫剧与视频生产平台，重点是“剧本 -> 资产 -> 分镜 -> 视频 -> 合成 -> 导出”的专业制作链。
Code-first，把 LLM 只能当原子工具来使用，固定编排生产步骤，LLM 主要承担实体提取、分镜与提示词润色。 不能被它目录下面原本的.claude/和Agents.md干扰，那只是它的创建过程工具。
代码爱好者狂喜，大模型什么的只是项目 play 中的一环，不过在足够的程序功底积累之下，也象征着极致的掌握力，各类功能的应用也是最为成熟的。
4. LocalMiniDrama
Star 数：1.3k。本地优先的 AI 短剧创作工具，重点是剧本生成、可视化编辑和本地化部署。
这是六个项目中最代码主导的实现。前端发起生成请求，Node 服务创建进程内任务，单次调用 OpenAI 兼容模型生成多集 JSON，解析后写入 SQLite，前端轮询任务状态。没有 Agent 之间的决策、工具调用回环或跨轮 LLM 会话。
调用链最短，容易调试，生成成本和响应时间都较可预测，适合做一个本地单功能产品。在强代码约束下， 创作流程弹性也相应的极低了，没有长期上下文、角色事实追踪、断点续跑或多阶段审查，像长篇改编之类的，就不用想了。
5. Drama Skills
Star 数：794。面向 Claude Code、Codex 等宿主 Agent 的十个短剧制作 Skill，覆盖原著分析、开发、写作、资产、分镜、提示词、生产与审查。
顾名思义，这是一个技能包，需要依托 claude code 或者 codex 这类工具执行，short-drama 负责路由，其他 Skill 分别拥有各自的产物路径和职责；宿主 Agent 负责推理与执行，文件、hash、索引、创作者确认和审查记录承担跨会话状态。 里面的 skill 是最适合学习的，以长篇小说改编为例，章节索引、抽样快评、逐章提取、章节批处理、覆盖率校验、产物合并，和之前我实现的小说改编场景思路基本上是一样的。
Skill is all，直接依靠外部的工具实现上下文管理等 dirty work，上下文也都落地为文件，进行长期记忆管理。在知识内容打磨的足够优秀的前提下，非常值得借鉴了。
6. short-writing-skill
无Star，这是一个基于仓颉 Skill，将大量的剧本素材进行提炼成的一个短剧编剧 Agent。
里面的内容很神奇，超出了我对 Skill 的认知，这应该算是一个大模型外挂，它蒸馏出了：题材方法论、案例卡、完整剧本索引。 整个项目由 Skill.md、references、library组成。
- Skill.md：规定了支持的场景、场景对应的 md 文件、检索案例卡的工具调用方式，以及输出要求。
- references：场景的 md 文件，每个里面包含有原则、知识、执行步骤、Agent 定义，一个 md 文件就能代表一个Skill；
- library：基于大量剧本蒸馏出来的剧本库，包含一个检索工具； 他没有约束任何 SOP，把一切都交给了大模型，反正上下文都加载进去了，大模型你就自己玩吧。但是测试出来生成的效果真的还可以，核心来自他基于剧本蒸馏出的 3 层信息。
- 原则层：创作公式以及实现原则，直接整合成了 references的内容，大模型需要了解的第一性原理，指导模型应该怎么创作；
- 案例层：在 library 中，将每个剧本整理成了一个案例卡，基于题材进行复用 library 中的素材，比如一个女频+宫廷本，可以复刻那些案例，在这里返回之后，让大模型进行复刻；
- 原始剧本层：针对一些特殊的剧情，如果需要对标创作，可以从案例卡找到对应的原始剧本，然后直接进行结构的深度复刻；
没有任何人工痕迹的 AI 原生态内容，完全是由大模型自己创建的 Skill 包，在由足够优秀的模型、工具作为支撑的前提下，效果偶尔会超出预期。可以和 Drama-skill 一起，提炼到工程化的应用产品中。并且其中剧本库的概念很好，如果和写剧本的平台一起，好的剧本直接进入剧本库闭环，就可以构建自成长的飞轮了。
二、3 种 Agent 应用的形式
按照执行权的划分，可以将 Agent 应用划分为 3 种形式。
1. 执行以大模型为主
整个任务的执行，以大模型的自主规划为核心。Skill 主要提供专业知识、案例和工具，代码脚本也只起到辅助作用。short-writing-skill就属于这种形式，确实是一开始就在从 SOP 思考时，从来没有考虑过的形式。
这种方式的优点是快，开发成本低，也能很大程度地发挥优秀模型的能力。对于写作这种开放式任务，模型偶尔真会跑出超出预期的效果。
但缺点也很明显——不稳定，比如在测试时，本来应该先调用工具拿到案例卡，再根据案例卡从 library 中提取原始剧本进行参考仿写，结果大模型拿到案例卡就直接开干了。同时他非常依赖模型能力，不同的模型跑出来的东西完全不同。 模型有更大的自主权，也同时意味着它的产出和过程都不一定如你所想。
2. 以 Agent 编排为主
项目会预先定义好 Agent 的工作边界、业务 SOP 和可用工具，Agent 会根据当前任务、中间产物和工具返回结果，决定下一步执行哪个 Skill、调用哪个工具，以及是否需要返工。
这类项目的编排并不一定由Agents.md、Skill.md的自然语言方式实现，也可以由代码、Agent 定义、Prompt 和 Skill 共同完成。比如Toonflow使用 TS 脚本定义 Agent 的调用循环和状态，Drama-Skills在 Skill 中放入 SOP 流程约束。之前我所构建的 Agent 项目，大多也是这个思路：不一定以 Skill 为主，而是通过 Skill 和 Agent 定义，让大模型在指定的轨道上自主执行。
这种方式在稳定性和灵活性之间取得了一个平衡。相较于完全交给大模型，它有更明确的流程、状态和质量约束；相较于固定的程序流水线，它又保留了大模型处理异常、调整路径和反复迭代的能力。 并且他在落地时可以取巧，直接套用 Claude Code CLI、Codex CLI 作为底层，解决各类处理工具权限、状态管理、上下文、断点续跑等 dirty work。
不过它的难点在于，非常考验业务功底，以及对系统 prompt 的编写能力，skill.md和 references 的定义的好坏，直接影响着应用是否可用。
3. 以程序为主
核心特征是，主流程由代码固定编排，大模型只是嵌在执行过程中的一环。下一步调用哪个能力、传入什么数据、返回结果如何校验，都由程序决定，LLM 更像是一个不确定性比较高的函数。
huobao、LumenX、LocalMiniDrama 都属于这种形式。huobao 虽然将四个大模型能力命名为 Agent，每个 Agent 也由 Prompt、Skills 和 Tools 组成，但是没有一个决策 Agent 根据返回结果调整路径，整体仍然是程序在调用几个 AI 黑盒。
这种方式的优点很明显，就是极致的掌控力（如果你有代码背景的话）。每一步的输入输出都能被校验，成本、响应时间和异常处理也更可预测，很适合封装成面向普通用户的稳定产品。
在这种框架下，让大模型干啥就干啥，但也只干你让他干的活。开发者需要自己处理大量代码层面的逻辑，同时也会丢失大模型的灵活性。当任务从“生成几集剧本”扩展到“改编 50 万字小说”时，原本清晰的代码流程，很快就会变成一个需要不断打补丁的复杂系统。
三、不同的应用场景小节
这 3 种 Agent 应用形式，并没有绝对的优劣，而是分别适合不同的场景。
以大模型为主的形式，适合流程还不确定、创造性要求高，或者需要快速验证想法的场景，以及很适合像在 workbuddy、openclaw 里面构建的个人 Agent 场景，它适合开放性的探索和试错，但不适合直接承载稳定的生产任务。
以 Agent 编排为主的形式，适合有明确专业 SOP，但执行过程又无法被完全穷举的复杂任务。比如写作、研究、咨询、代码开发，专业人士虽然有一套稳定的工作方法，但每个任务面对的素材、问题和中间结果都不一样，仍然需要 Agent 在执行中不断判断和调整。
以程序为主的形式，更适合流程固定、执行频率高，并且对成本、速度和稳定性有明确要求的环节。比如资产管理、格式转换、任务调度、视频合成等，这些事情并不需要大模型自由发挥，代码能够完成的部分，交给代码反而更可靠。
四、我的编剧系统落地
我自己在做内部编剧系统时，选择的是以 Agent 编排为主，前期和很多专业编剧也进行业务流程调研，希望可以尽量复刻一个专业高级主编的能力，在保证剧本质量的前提下，提升短剧剧本的生产效率。
所以，我以 Claude Code 作为底层框架，构建了一个 Human in the Loop 的交互式编剧工具。分业务阶段划分 Skill，按照预先定义的编剧流程，阶段间使用文件的形式进行长期记忆存储。人负责关键节点的选择和确认，Agent 负责推进流程、执行任务和处理返工。到目前为止，这套系统已经能够稳定地跑出 B+ 以上评级的本。
这次调研之后，我又从 short-writing-skill 中找到了下一步优化的思路：构建一个可以持续生长的剧本库。 参考 short-writing-skill 的剧本库的理念，将剧本整理成可以被 Agent 理解和调用的知识：从优秀剧本中提炼可复用的创作原则，将题材、人设、冲突、钩子和剧情结构整理成案例卡，同时保留原始剧本，在需要时能够进一步检索和参考。
在结合外部剧本实现案例卡初始化后，将后续内部团队创作的 A 级以上剧本会自动进入剧本库，再经过标签化、结构化和蒸馏，成为下一次创作可以检索的参考素材。伴随着系统的使用，我们的剧本库会不断扩充，我们整个系统的知识内核也会不断进化。