当一个游戏里的虚拟角色开始自主设计动作AI 就不再只是“画图工具”而是一个能理解剧情、编排打斗、甚至控制镜头语言的导演。最近看到有人把类似 ai-town 的多智能体模拟项目与视频生成模型串起来尝试让 AI 自动重现经典动漫打斗名场面这个方向很有工程挑战性。本文会完整拆解这套链路如何让多个 LLM Agent 扮演不同角色生成冲突剧情如何把文字动作翻译成结构化分镜再交给视频扩散模型产出画面最后合成可播放的镜头片段。无论你是做 AI 应用开发、多智能体系统还是对可控视频生成感兴趣这套流程都能直接复用。1. 背景与核心概念1.1 “重现动漫打斗名场面”到底难在哪很多人以为想让 AI 重现一段经典打斗只要输入“两人激烈对打”这种提示词再丢给视频生成模型就行。但真实效果通常很不可控角色长相会漂移、动作姿态不稳定、镜头切换生硬、关键一击完全没有冲击力。原因是动漫打斗名场面本身包含多个维度角色维度谁在打双方的外形、服装、武器、表情是否稳定。动作维度出拳、格挡、闪避、追击每一步是否有先后顺序。镜头维度全景展示环境中景拍拆招特写给情绪升格表现冲击。节奏维度什么时候蓄力什么时候爆发什么时候静止。剧情维度为什么打起来打到什么程度停谁赢谁输。这些信息很难靠一句提示词描述清楚。更合理的做法是把“重现名场面”当成一个工程问题来拆解先用 AI 理解剧情并生成结构化分镜再用可控图像生成技术保证角色一致最后用视频生成模型把分镜变成画面。1.2 从“文本生成视频”到“可控视频生成”近几年视频生成模型进步很快但单纯依赖“文生视频”做复杂叙事仍然不稳定。于是出现了一个更工程化的思路把视频生成拆成“内容策划 视觉生成”两个阶段。动漫剧情文本/台词 ↓ LLM Agent 设计分镜结构化 JSON ↓ 角色一致性控制LoRA / IP-Adapter / 参考图 ↓ 视频扩散模型生成短镜头1~3秒片段 ↓ 补帧、裁剪、字幕、音效合成 ↓ 最终可播放的打斗名场面这个流程的核心价值在于LLM 负责“想清楚”视频模型负责“画出来”两者各司其职。每一段视频只负责 1~3 秒的画面降低生成难度同时通过分镜设计保证整体叙事连贯。1.3 多智能体与 AI 小镇的关联输入中提到的“ai小镇”my_ai_town属于多智能体模拟项目可以理解为让多个 AI 角色在虚拟小镇里生活、对话、制定计划。这类项目通常基于大语言模型记忆与规划机制角色会根据当前状态和长期记忆决定下一步行动。把这个能力迁移到重现动漫打斗上会带来一个非常自然的组合每个动漫角色是一个独立 Agent有性格、目标、记忆。两个 Agent 会因为剧情冲突进入战斗状态。Agent 把战斗意图翻译成动作序列。动作序列再交给视觉生成模型渲染。也就是说打斗不再是“程序写死的一连串动画”而是由 Agent 根据剧情动态生成的“舞台表演”。这也是多智能体方向最让人兴奋的一点AI 不只生成画面而是开始生成行为本身。2. 整体系统设计与技术选型2.1 系统模块划分整个系统按照职责可以拆成四个模块。模块职责技术建议剧情引擎根据角色背景生成冲突动机和台词LLM 记忆管理分镜规划把剧情转化为镜头、动作、运镜LLM 结构化输出角色与场景控制器固定角色外观、动作姿态、场景风格LoRA / IP-Adapter / ControlNet视频合成引擎生成镜头片段并合成完整视频视频扩散模型 FFmpeg实际落地时不需要每一步都做到“全自动”。工程上更稳妥的方式是“AI 生成 人工审核”剧情引擎先给出几版打斗动机。分镜规划生成初步分镜表。人工挑选并修正分镜。视频引擎批量生成镜头。人工筛选可用帧合成最终视频。2.2 为什么选择“短镜头拼接”视频扩散模型在处理超长视频时容易出现角色遗忘、运动漂移、画面闪烁等问题。与其让模型一口气生成十几秒打斗不如用短镜头拼接单镜头时长控制在 1~3 秒。每个镜头只表达一个明确动作。镜头之间通过画面构图、动作连贯性衔接。必要时用补帧模型提高流畅度。这种方式有两个好处第一降低单次生成的显存压力第二某个镜头生成失败时只需要重出该镜头不需要整段重来。2.3 开源模型与商业 API 的取舍视频生成部分目前有两条路线本地部署开源视频扩散模型可控性强、隐私好但对显卡要求高部署成本大。调用商业视频生成 API生成质量高、上手快但精细控制能力有限按量计费。路线本身没有优劣关键看你的目标。如果是个人实验和学习建议先从商业 API 或本地小模型开始如果是把完整流程做成产品通常要本地部署可控模型再结合 LoRA 和 ControlNet 做精细干预。3. 环境准备与版本说明3.1 基础运行环境本文示例以 Python 3.10 及以上版本为例操作系统可以是 Windows 或 Linux。视频生成部分如果本地运行建议使用 NVIDIA GPU显存越大越好至少 12GB 以上更顺手。版本方面的原则是不要盲目追求最新保持依赖稳定。PyTorch、diffusers、transformers 等库更新很快很多 API 在新版本中会有调整。本文给出的代码以常见版本为参考实际运行时请根据你本地的版本微调。# 建议使用虚拟环境 python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate pip install --upgrade pip3.2 Python 依赖创建requirements.txt内容如下langchain0.2.0 pydantic2.0.0 openai1.30.0 requests2.31.0 python-dotenv1.0.0说明一下langchain用于串联 LLM 调用和结构化输出。pydantic用于校验 LLM 返回的分镜 JSON。openai客户端用于调用 OpenAI 兼容接口也可以接本地 Ollama 或 vLLM 服务。requests用于调用 ComfyUI 的 API 提交工作流。python-dotenv用于管理环境变量。如果你打算在 Java 项目里做多智能体编排可以考虑 Spring AI它提供了类似 LangChain 的抽象能力。本文以 Python 为主但整体设计思路在 Java 端同样适用。3.3 LLM 服务准备分镜规划需要一个 LLM。方案有两种在线 API配置OPENAI_API_KEY。本地推理服务使用 Ollama、vLLM 或 LM Studio 等工具暴露一个 OpenAI 兼容的/v1/chat/completions接口。本地服务的优点是数据不出内网适合企业项目。缺点是小参数模型在复杂分镜规划上效果偏弱。个人实验时可以先从在线 API 开始验证流程。3.4 视频生成引擎准备视频生成部分本文使用 ComfyUI 作为引擎主要原因有几点可视化搭建图像/视频生成工作流。支持 AnimateDiff、ControlNet、LoRA 等关键组件。提供 API 接口方便 Python 远程提交任务。第一步是安装 ComfyUI并导入一个可用的视频生成工作流。工作流中通常包含模型加载节点、ControlNet 控制节点、采样器节点、视频保存节点。安装完成后在浏览器中打开工作流并确认能手动生成视频再进入自动化阶段。4. 核心原理与关键实现4.1 用 LLM Agent 生成“战斗剧情”打斗不是凭空产生的两个角色必须有冲突动机。这一步由剧情引擎完成。以经典动漫打斗为例两个角色可以是师徒反目、宿敌再遇、守护同伴等经典桥段。我们可以给每个 Agent 设定基本信息character_hero { name: 剑客·凛, personality: 冷静克制剑术凌厉, goal: 阻止对方伤害村庄, memory: 曾经败给对方心存执念, } character_foe { name: 浪人·隼, personality: 狂傲自负追求极限, goal: 挑战强者证明自己, memory: 曾在雪地决斗中险胜对方, }LLM Agent 会基于这些信息生成冲突动机、台词和情绪变化。为了让输出结构稳定我们可以让模型输出固定 JSON。4.2 结构化分镜 JSON打斗分镜是整个流程中最关键的数据结构。它需要同时表达动作、镜头、角色状态和效果。下面是一个示例{ scene_id: fight_001, title: 雪地对决·第一次交锋, shots: [ { shot_id: 1, shot_type: wide_shot, duration: 2, camera: 低角度仰拍, characters: [ {character_id: hero, action: 拔剑静立, expression: 冷静}, {character_id: foe, action: 狂奔冲锋, expression: 兴奋} ], effects: [风雪, 脚步溅雪], voiceover: 多年之后两人再次站在同样的雪地中。, dialogue: }, { shot_id: 2, shot_type: close_up, duration: 1, camera: 特写镜头聚焦剑锋, characters: [ {character_id: hero, action: 侧身闪避, expression: 专注}, {character_id: foe, action: 横斩落空, expression: 意外} ], effects: [刀光, 风声], voiceover: , dialogue: 你还是慢了一步。 } ] }这个 JSON 看起来简单但它定义了后面所有视觉生成的基础shot_type决定画面构图。camera影响 ControlNet 的深度控制。characters[].action决定动作姿态参考图。effects决定画面元素。duration决定视频帧数。核心原则是分镜信息越详细后面生成越可控。4.3 角色一致性与动作姿态控制动漫角色最容易翻车的是“同一个人在不同镜头里长得不一样”。要解决这个问题通常有几种手段LoRA预先训练角色的 LoRA 模型把角色特征固化。IP-Adapter通过参考图约束生成角色的 ID。固定种子与提示词在相同场景下保持角色描述一致。姿势参考图从动漫片段中提取动作姿态作为 ControlNet 输入。实际案例中先用 OpenPose 类模型提取希望模仿的经典打斗姿势生成骨架图再交给 ControlNet 控制生成。这样即便画面风格不同动作结构也能忠实还原。动漫参考片段 ↓ 抽帧 关键动作帧 ↓ OpenPose 提取 骨骼姿态图 ↓ ControlNet 生成带有相同动作的角色画面4.4 视频生成与合成拿到每个镜头的关键帧之后使用视频扩散模型生成 1~3 秒镜头片段。生成时需要注意分辨率不要一开始就拉太高先做 512 或 768确认效果再放大。帧数不宜过多12~24 帧即可。同一个镜头内尽量使用相同的提示词后缀避免画面风格跳动。镜头全部生成后用 FFmpeg 把片段拼接起来。ffmpeg -f concat -safe 0 -i filelist.txt -c copy output.mp4如果需要做慢动作或升格效果可以在关键帧之间用补帧模型插帧再通过 FFmpeg 调整播放速度。5. 完整实战案例从脚本到成片下面用一个简化案例走通流程。假设我们要重现一段“剑客与浪人在雪地中对决”的名场面式打斗。5.1 创建项目结构ai_fight_reproduction/ ├── requirements.txt ├── .env ├── config.py ├── storyboard_agent.py ├── generate_shot.py ├── compose_video.py ├── workflows/ │ └── fight_workflow.json └── outputs/ ├── shots/ └── final/5.2 配置环境变量与 LLM 客户端在.env文件中配置OPENAI_API_KEY你的密钥 OPENAI_BASE_URLhttps://api.openai.com/v1 LLM_MODELgpt-4o-mini如果你使用本地推理服务把OPENAI_BASE_URL改成本地地址即可例如http://localhost:11434/v1。config.py代码如下import os from dotenv import load_dotenv load_dotenv() LLM_MODEL os.getenv(LLM_MODEL, gpt-4o-mini) OPENAI_API_KEY os.getenv(OPENAI_API_KEY, ) OPENAI_BASE_URL os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) COMFYUI_URL os.getenv(COMFYUI_URL, http://127.0.0.1:8188)5.3 编写分镜生成 Agentstoryboard_agent.py的核心功能是接收战斗剧情描述返回结构化的分镜 JSON。import json from typing import List from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI from pydantic import BaseModel, Field from config import LLM_MODEL, OPENAI_API_KEY, OPENAI_BASE_URL class CharacterAction(BaseModel): character_id: str action: str expression: str class Shot(BaseModel): shot_id: int shot_type: str duration: float camera: str characters: List[CharacterAction] effects: List[str] voiceover: str dialogue: str class Storyboard(BaseModel): scene_id: str title: str shots: List[Shot] PROMPT ChatPromptTemplate.from_messages([ ( system, 你是一位专业的动漫分镜师。根据用户的战斗剧情描述 生成清晰、可执行的分镜 JSON。要求每个镜头包含完整动作、镜头语言和情绪表达。 ), (user, {input_description}), ]) def build_storyboard_chain(): llm ChatOpenAI( modelLLM_MODEL, api_keyOPENAI_API_KEY, base_urlOPENAI_BASE_URL, temperature0.7, ) return PROMPT | llm.with_structured_output(Storyboard) def main(user_input: str): chain build_storyboard_chain() storyboard chain.invoke({input_description: user_input}) data storyboard.model_dump() print(json.dumps(data, ensure_asciiFalse, indent2)) return data if __name__ __main__: demo_input ( 剑客·凛和浪人·隼在暴雪中对峙。两人曾有过一次未分胜负的决斗。 凛率先拔剑隼狂笑着发起冲锋。第一个回合两人互相试探 剑锋擦过空气画面要有速度感和张力。 ) main(demo_input)代码中使用了with_structured_output(Storyboard)LangChain 会根据 Pydantic 类自动约束模型输出格式避免手动解析 JSON 时遇到缺字段、格式错乱等麻烦。运行命令python storyboard_agent.py预期输出是一组带shot_id的镜头列表每个镜头包含动作、镜头类型、镜头语言和台词。这部分是可独立运行验证的。5.4 导入视频生成工作流到 ComfyUI分镜产出后下一步是镜头画面生成。这里以 ComfyUI 为例具体流程是打开 ComfyUI导入一个包含 AnimateDiff ControlNet 的文本生成视频工作流。在工作流中配置好角色 LoRA、动作骨架图输入节点和场景提示词。通过 ComfyUI 的 API 接口提交任务。工作流需要你根据自己安装的插件和模型自行搭建因为不同版本的插件节点名称可能不同。搭建完成后在 ComfyUI 中“启用开发者模式”通过Save (API Format)导出 API 格式的工作流 JSON保存为workflows/fight_workflow.json。5.5 使用 Python 提交生成任务generate_shot.py负责读取分镜 JSON替换工作流中的提示词节点、角色描述和动作参考图再提交给 ComfyUI。import json import random import requests from config import COMFYUI_URL def load_workflow(workflow_path: str) - dict: with open(workflow_path, r, encodingutf-8) as f: return json.load(f) def set_prompt(workflow: dict, prompt_text: str): # 不同工作流的节点 ID 不同需要根据实际导出的 JSON 调整 for node_id, node in workflow.items(): if node.get(class_type) in (CLIPTextEncode, PositivePrompt): node[inputs][text] prompt_text def submit_prompt(workflow: dict) - dict: response requests.post( f{COMFYUI_URL}/prompt, json{prompt: workflow, client_id: ai_fight_demo} ) response.raise_for_status() return response.json() def build_shot_prompt(shot: dict) - str: hero_action shot[characters][0][action] foe_action shot[characters][1][action] return ( fanime style, snowy battlefield, {hero_action}, f{foe_action}, {shot[camera]}, dynamic composition, fhigh speed motion, cinematic lighting ) if __name__ __main__: with open(outputs/storyboard.json, r, encodingutf-8) as f: storyboard json.load(f) for shot in storyboard[shots]: workflow load_workflow(workflows/fight_workflow.json) prompt_text build_shot_prompt(shot) set_prompt(workflow, prompt_text) result submit_prompt(workflow) print(fshot {shot[shot_id]} submitted: {result}) # 实际项目中建议在两个镜头提交之间做适当延时这段代码的关键在于每个镜头都用独立工作流生成互不干扰。如果某个镜头效果不好可以只重生成该镜头。5.6 合成完整视频镜头生成完成后把镜头文件按顺序写入filelist.txt然后用 FFmpeg 合成。# filelist.txt 内容示例 file outputs/shots/shot_001.mp4 file outputs/shots/shot_002.mp4 file outputs/shots/shot_003.mp4执行合成命令ffmpeg -f concat -safe 0 -i filelist.txt -c copy outputs/final/fight_scene.mp4如果你想在镜头之间加入淡入淡出效果需要重新编码ffmpeg -f concat -safe 0 -i filelist.txt -vf fadetin:st0:d0.3,fadetout:st5:d0.3 outputs/final/fight_scene_fade.mp46. 常见问题与排查思路问题现象常见原因解决思路LLM 返回的分镜缺字段模型输出不稳定使用 Pydantic 校验失败后自动重试同一个角色在不同镜头里长相不一致缺少角色 LoRA 或参考图约束训练角色 LoRA搭配 IP-Adapter 参考图打斗动作僵硬、不连贯直接生成整段长视频拆成 1~3 秒短镜头用姿态图控制手部或武器区域崩坏视频扩散模型对细节保持能力有限分镜中减少长时间手部特写或用 ControlNet 强约束显存不足导致生成失败分辨率或帧数设置过高降低分辨率开启模型 offload分批生成生成视频画面闪烁严重多镜头拼接时风格差异大固定提示词后缀、采样器和种子提交 ComfyUI 任务后报错工作流节点和版本不匹配检查节点名称、依赖插件、模型路径输出内容涉及侵权风险直接使用未授权动漫原画面使用原创角色或已授权素材避免直接复刻受版权保护画面的形式其中 LLM 分镜校验可以这样处理如果 Pydantic 校验失败把错误信息反馈给模型重新生成。这个重试机制在大规模生成时能明显提高成功率。from pydantic import ValidationError MAX_RETRY 3 def generate_with_retry(chain, user_input: str): for attempt in range(MAX_RETRY): try: return chain.invoke({input_description: user_input}) except ValidationError as e: print(fretry {attempt 1}, validation error: {e}) raise RuntimeError(分镜生成失败请调整提示词或模型)7. 最佳实践与工程建议7.1 分镜信息越结构化越好不要只给模型一句“打斗激烈”。建议把镜头类型、动作、表情、运镜、特效、台词全部拆成字段。这样一方面能提升输出稳定性另一方面方便后续把数据接入视频生成引擎。7.2 建立素材与角色资产库这是整个工程最容易低估的部分。建议按角色建立资产库assets/ ├── characters/ │ ├── hero/ │ │ ├── lora/ │ │ ├── reference_images/ │ │ └── poses/ │ └── foe/ │ ├── lora/ │ ├── reference_images/ │ └── poses/ └── scenes/ └── snowy_field/每个角色的参考图最好在多角度、多表情、不同光照下采集。角色 LoRA 的训练数据也要均匀避免只覆盖某个角度导致生成时“只会正面”。7.3 人工审核是不可缺少的一环全自动生成在娱乐场景可行但到了内容创作或商业项目一定要增加人工审核节点。推荐流程先让 AI 生成 3~5 版分镜。人工挑选或合并。先生成关键帧静态图确认角色和构图。再生成视频。最后统一合成。7.4 避免直接复刻受版权保护的画面经典动漫名场面往往受版权保护。在技术演示中可以模仿“打斗叙事结构”和“镜头语言”但不要直接使用未经授权的原画面素材。更稳妥的做法是使用原创角色、自建场景或者使用明确开放的创意素材。这也是 AI 内容创作的基本底线。7.5 版本与配置管理LLM 模型、视频扩散模型、ComfyUI 插件都在快速迭代。建议把以下内容纳入版本管理requirements.txt锁定 Python 依赖。ComfyUI 工作流 JSON 保存到仓库。每个生成任务的模型版本、提示词、种子写入日志。最终成片与分镜 JSON 一一对应方便回溯复现。这种“可复现”能力在团队协作中尤其重要。否则一段时间后你会发现同样的提示词生成的结果完全对不上排查起来非常痛苦。8. 总结与学习路线到这里完整链路已经走通多智能体剧情引擎生成冲突LLM 分镜规划输出结构化 JSON视频生成引擎产出短镜头FFmpeg 合成完整画面。你可以把这段流程理解为“给 AI 装了一个导演脑”让它在动手画之前先把每一镜想清楚。如果继续深入建议按这个顺序学习LLM 结构化输出与 Prompt 工程使用 Pydantic 强制校验。多智能体框架理解记忆、规划与角色一致性。可控图像生成熟悉 ControlNet、LoRA、IP-Adapter 的配合方式。视频扩散模型原理与工程部署。视频后期处理包括补帧、调色、合成音频。实际项目中最优先关注的不是模型有多强而是“信息在不同模块之间如何无损传递”。只要分镜数据结构设计得够好就算以后换更强的视频模型整套流程也能平滑迁移。如果你也在尝试类似的 AI 内容生成工程欢迎在评论区聊聊你遇到的问题尤其是角色一致性和可控动作方面这些坑往往是共通的。