互动影游与长视频创作 Agent：一条流水线上的七道一致性关卡

两类产物形态 · 六角色 DAG · 四类长程一致性 · 分支爆炸与镜头并行 · 无 golden answer 的评测

名词速查

首次阅读可跳过本表，直接看「场景问题」，遇到生词再回查。

本篇是创作类产物生成与评测子域的名词归属页。它解决的是一类后台工程师最陌生的问题：产物没有正确答案，但仍然有明确的"坏"——人物前后不一致、镜头接不上、分支组合爆炸。类比过来最接近的是"没有断言的验收，只能靠一致性约束和抽样评审"。

篇幅较长，按 spec 拆两张表。

本篇自有名词

本篇引用的其他上下文名词

场景问题

一个 12 集的互动短剧项目，用 Agent 流水线生产。前 3 集顺利，第 4 集开始出问题：

• 第 4 集主角的眼睛颜色从琥珀色变成了灰蓝色。查下去发现：第 3 集末尾做了一次上下文压缩，角色外观描述被摘进了摘要，摘要里写的是"主角有一双引人注目的眼睛"——颜色丢了。
• 第 6 集出现一个已经死掉的配角在说话。分镜 Agent 拿到的剧本片段没有前情，它不知道这个人死了。
• 第 7 集有条分支引用了从未发生的事件（"就像上次在码头那样"）——那条码头剧情在另一条玩家没走的分支里。
• 到第 9 集，总分支数已经 340 条，团队发现没有人看过其中的 200 多条。而其中 30 条包含上面那类事故。
• 最贵的一次事故：一个 8 分钟片段全部渲染完成后才发现主角服装和前一集不接，重做花掉的成本是当初做一次一致性校验的两百多倍。

五个问题，没有一个是"生成质量不好"。它们全部是一致性问题，而且全部发生在跨镜头、跨集、跨分支的"长程"上。

这就是创作 Agent 的真实难点：单个镜头的生成质量已经够用了，难的是让第 40 个镜头还记得第 1 个镜头的设定。而这恰好是 LLM 结构上最不擅长的事——它的记忆是有限窗口 + 有损压缩。

实现方案

第 0 步：先分清两类产物的形态

在动手编排之前必须先分清做的是哪一类，因为结构差异直接决定编排差异：

共享的部分（两类都要，可以复用同一套实现）：设定管理（Story Bible）、素材生成与校验、四类一致性护栏、成本闸门、rubric 评测。

不可共享的部分：互动影游需要分支状态机与路径覆盖，长视频完全不需要；长视频需要镜头间的视觉接续（首帧续接），互动影游因为分支跳转本身就是不连续的，反而弱化了这个需求。

第 1 步：设定层 —— Story Bible 作为共享黑板

打个比方：Story Bible 就是这条流水线的配置中心——所有下游服务启动时都从它读同一份配置，谁都不许把参数写死在自己代码里。它必须先存在、必须唯一、改了要能通知到所有消费方。类比失效边界：配置中心下发的是结构化键值，各服务解析结果完全一致；这里的消费方是模型，它读的是文本，会按自己的理解补全没写的部分——你没写主角眼睛颜色，它就自己编一个，而且每次编的不一样。所以硬约束必须落成可校验的结构化字段（{性格锚点, 称呼表, 能力清单}），而不是一段散文设定：散文会被压缩掉、会被注意力忽略，且没有字段可比对就只能靠人看。

流水线的第一个产物不是剧本，是设定。这是全篇最重要的一个顺序决定：Story Bible 必须先于剧本存在，因为它是后续所有 Agent 的共同真相源。

Story Bible 就是 Multi-Agent 系统 里那个黑板在创作场景的实例：结构化、带版本号、所有 Agent 读，只有少数 Agent 能写。

关键设计：结构化，不是散文。

# ✗ 错：自由文本的 Story Bible
bible = """
主角林清，28 岁女性，琥珀色眼睛，左眉有一道疤。性格外冷内热。
她父亲在她 10 岁时失踪。故事发生在 2087 年的新港市……
"""
# 问题：每个 Agent 拿到这段话都要自己做一次信息抽取，
# 抽取偏差会累积。分镜 Agent 可能压根没注意到"左眉有疤"。
# 更致命的是：这段话进了上下文就会被压缩，压缩必丢细节。

# ✓ 对：结构化条目，可断言、可 diff、可选择性注入
bible = {
    "characters": {
        "lin_qing": {
            "name": "林清", "age": 28, "gender": "female",
            "appearance": {           # 视觉一致性的唯一真相源
                "eyes": "琥珀色",
                "distinguishing": ["左眉一道疤"],
                "ref_images": ["asset://char/lin_qing/front_v3.png"],
                "seed": 8814023,      # 固定种子 —— 见下文视觉一致性
            },
            "voice": {"ref_audio": "asset://voice/lin_qing_v2.wav"},
            "status": "alive",        # 时间线一致性靠它
            "knows": ["father_missing"],  # 该角色已知信息，防"她怎么知道的"
        },
    },
    "world": {"year": 2087, "city": "新港市", "tech_level": "近未来"},
    "timeline": [                     # 显式事件表，不靠模型记
        {"id": "father_missing", "when": "2069", "involves": ["lin_qing"]},
    ],
    "version": 7,
}

结构化买到的四样东西，都是散文给不了的：

1. 可断言：能写 assert bible["characters"]["lin_qing"]["appearance"]["eyes"] == shot.character_eyes。散文只能靠模型判断"是否一致"，那就是用一个会犯错的东西检查另一个会犯错的东西。
2. 可 diff：版本 6→7 改了什么，一目了然。散文改一句话你看不出影响面。
3. 可选择性注入：分镜 Agent 只需要 appearance 与 world，不需要整本 Bible——这是省 token 的唯一正确方式（不是压缩，是不注入无关字段）。
4. 不参与压缩：结构化条目按需注入 system 段，物理上不进 messages——机制与 运行时 · pin 的实现 完全一致。

Story Bible 的写权限必须收紧：只有编剧 Agent 与人类可以写 characters / world，其余 Agent 只读。原因是 MAS · 黑板并发写 那个坑——如果分镜 Agent 也能改角色外观，两个 Agent 并发改同一个字段会静默丢写，而这类丢写在创作场景要到成片才被发现。

第 2 步：剧本层 —— 六角色 DAG 与真假依赖

设定就位后进入生产。六类角色 Agent 及其契约：

评审必须独立，这一条来自 MAS · 结果聚合 的通用规则：让产出方评自己的产物等于没有评审，模型对自己输出的评价系统性偏高。创作场景里这条更严重，因为"好不好"本来就模糊，自评的偏差没有客观锚点纠正。

依赖编排——关键是分清真依赖（下游需要上游的确定性产物）与假依赖（只是书写顺序）：

图里三处值得注意：

• 配音与分镜是假依赖。台词在剧本定稿时就确定了，配音不需要等镜头表——这条边拆开能省掉整个分镜阶段的等待时间。假依赖是并行度的主要来源，而它们通常只是因为"代码是顺着写的"才串行。
• 镜头之间是假依赖（虚线框内）：镜 1 和镜 2 的生成互不依赖，可并行。但这个并行会引出长视频最核心的矛盾，见第 4 步。
• 打回边有两条且去向不同：画面问题打回素材 Agent（重生成一个镜头），剧情/设定冲突打回编剧（改剧本，且可能要改 Bible）。不分开会导致设定冲突被当画面问题处理——重生成一百次也修不好一个剧本层面的矛盾。

判定真假依赖的方法很朴素：问「上游产物的内容变化，会不会改变下游的输入」。会 → 真依赖；不会 → 假依赖，拆开。这个判定必须在编排期做，不能交给运行时的模型——模型倾向保守串行，会白白丢掉并行度。

拓扑选择：这条流水线用的是 Pipeline + Blackboard 组合（MAS 矩阵 里 Pipeline × 黑板 那一格）。理由：阶段固定且单向（Pipeline 天然匹配），但所有阶段都要读同一份设定（需要黑板）。矩阵里标注了这个组合的条件——黑板对 Pipeline 各级只读不写，正好对应上面"只有编剧能写 Bible"的权限设计。

第 3 步：一致性层 —— 四类关卡，四种手段

打个比方：这四类关卡就像你在系统里同时守的四种一致性——数据一致性（字段别自相矛盾）、配置一致性（各服务读到同一份）、版本一致性（别新旧混用）、时序一致性（因果顺序不能倒）。每一种都有专属机制：约束、配置中心、版本号、时间戳。拿约束去治时序问题是无效的，这里也一样。类比失效边界：系统里这四类都能靠机器判定——违反约束就报错，读到旧版本能比对版本号；而角色性格漂移、设定自相矛盾不产生任何错误信号，产物照样生成出来、格式合法、读起来通顺。所以这一层的关键不是"选对机制"，而是先把每类一致性变成可断言的离散事实——不可断言的部分，再多机制也守不住。

这是全篇的核心。四类一致性，手段互不通用——用错手段等于没做：

四类里最需要展开的是视觉一致性——因为它是唯一"手段与直觉相反"的一类。

直觉做法是把外貌写得越来越详细塞进 prompt。这不管用，原因是文本→图像的映射不是函数：同一段描述在不同种子下产出完全不同的脸，而描述的详细程度只能收窄分布、不能收敛到一点。正确做法是把图像本身作为条件（参考图 / 角色 LoRA / 图像条件控制），并固定种子——即把随机性从"每次不同"改成"每次相同"。prompt 只负责描述这个镜头特有的东西（动作、表情、构图），不负责描述跨镜头不变的东西（长相），后者交给参考图。

一句话：变的东西写 prompt，不变的东西给参考图。

连续性断言：把场记本变成代码

时间线与角色一致性都可以自动化校验，因为它们的判据是离散事实而非审美。这是创作评测里唯一能做到确定性的部分，必须吃干：

class ContinuityError(Exception):
    """连续性断言失败。区别于生成失败 —— 它不该重试，该修剧本。"""

class StoryBible:
    """结构化设定黑板。版本号防并发丢写（见 MAS 篇），
    只有编剧 Agent 与人类持有写权限。"""

    def __init__(self, data: dict):
        self._data = data
        self._version = data.get("version", 0)

    def inject(self, *fields: str) -> dict:
        """按需注入：只给这个 Agent 需要的字段。
        省 token 的正确方式是不注入无关字段，而不是把整本压缩。"""
        return {f: self._data[f] for f in fields if f in self._data}

    def write(self, path: str, value, expect_version: int, author: str):
        """CAS 写入。版本不匹配即拒绝 —— 让静默丢写变成显式报错。"""
        if expect_version != self._version:
            raise ContinuityError(
                f"stale write by {author}: want v{expect_version}, now v{self._version}"
            )
        node, *rest = path.split(".")
        cur = self._data[node]
        for k in rest[:-1]:
            cur = cur[k]
        cur[rest[-1]] = value
        self._version += 1


def assert_continuity(bible: StoryBible, scene: dict, path_history: list[str]):
    """生成前校验。三条断言各对应开篇的一次真实事故。

    path_history 是互动影游必需的参数：同一场戏在不同分支路径上
    的合法性不同 —— 这是线性长视频没有的维度。
    """
    b = bible._data

    # 断言 1：出场角色必须活着（开篇事故：死掉的配角在说话）
    for cid in scene["characters"]:
        status = b["characters"][cid]["status"]
        if status != "alive":
            raise ContinuityError(
                f"场 {scene['id']}：角色 {cid} 状态为 {status}，不应出场"
            )

    # 断言 2：引用的事件必须已在【本路径上】发生
    #         （开篇事故：引用了另一条分支里的"码头剧情"）
    for ev in scene.get("references", []):
        if ev not in path_history:
            raise ContinuityError(
                f"场 {scene['id']}：引用事件 {ev!r} 在当前路径上未发生。"
                f"本路径已发生：{path_history}"
            )

    # 断言 3：角色不能知道自己没被告知的事
    #         （防"她怎么知道的" —— 最难被人眼发现的一类穿帮）
    for cid, said in scene.get("reveals", {}).items():
        known = set(b["characters"][cid]["knows"])
        if leaked := set(said) - known:
            raise ContinuityError(
                f"场 {scene['id']}：{cid} 说出了未知信息 {leaked}"
            )


def assert_visual_lock(bible: StoryBible, shot: dict):
    """生成后校验：素材 Agent 是否真的用了锁定的参考图与种子。
    这条断言防的是"参数在传递链路上被悄悄丢掉" ——
    比模型出错更常见，也更容易被忽略。"""
    want = bible._data["characters"][shot["character"]]["appearance"]
    if shot["used_seed"] != want["seed"]:
        raise ContinuityError(
            f"镜 {shot['id']}：种子 {shot['used_seed']} ≠ 锁定值 {want['seed']}"
        )
    if not set(want["ref_images"]) & set(shot["used_refs"]):
        raise ContinuityError(f"镜 {shot['id']}：未使用任何锁定参考图")

两个实现要点：

• ContinuityError 不该触发重试。 这是创作流水线里最容易写错的地方：通用的 Agent 重试逻辑会把它当成一次偶发失败，重跑一遍——但剧本层的矛盾重跑一万次也还在。断言失败必须打回编剧（改剧本或改 Bible），不是重生成。这对应 DAG 图里那两条不同去向的打回边。
• path_history 是互动影游独有的参数。 线性长视频里"事件是否已发生"只看时间先后；分支叙事里同一场戏在路径 A 上合法、在路径 B 上就是穿帮。断言必须按路径求值，不能按全局求值——这是分支叙事一致性校验的根本难点，也是下一步分支爆炸的成本来源。

第 4 步：两处特有难点

打个比方：分支爆炸就是笛卡尔积炸测试用例那件事——每加一个二值开关，要覆盖的组合数就翻倍，10 个开关就是 1024 种。你的应对不是"把每种组合都测一遍"，而是收敛状态空间：合并等价类、设约束排掉不可能的组合。这里的收束节点是同一招。类比失效边界：测试用例的每种组合只占测试时间，跑完就没了；这里每条分支的内容都得真的生成出来并长期存着——所以爆炸的是生成成本 + 存储 + 测试面积三样同时。而且组合之间不是独立的：同一场戏在路径 A 上合法、在路径 B 上就是穿帮，断言必须按路径求值，不能按全局求值。

互动影游：分支爆炸与收束节点

分支自由生长的代价是双重指数：

设每个决策点 2 个选项，深度 d 层，则叶子路径数 2^d。10 层就是 1024 条。而成本和测试面积同时按这个数增长：

• 生成成本 ∝ 需要生成的独立内容量（如果每条路径内容都不同）
• 测试面积 ∝ 可达路径数（要保证"所有可达路径都通"）
• 一致性校验成本 ∝ 路径数 × 每条路径上的断言数（因为断言要按路径求值，见上文）

开篇那 340 条分支里 200 条没人看过——不是团队懒，是规模上已经不可能看完。而没被看过的分支里藏着事故，这是必然而非偶然。

唯一有效的手段是收束节点：强制若干条分支在某处汇合回同一状态，把 2^d 压回线性量级。

代一遍数字（还是 10 层决策，每层 2 选项）：自由生长是 2^10 = 1024 条叶子路径；每 2 层设一个收束点，则每段内部只有 2^2 = 4 条局部路径、共 5 段，要生成与校验的独立内容单元降到 4 × 5 = 20 个——1024 → 20，压掉 98%。代价是玩家在收束点之后感知不到前面选过什么，除非用标记位把差异带过去。

所以工程上意味着什么：收束点的间隔就是内容量与自由度的兑换比，且它是在写剧本之前就要定死的结构参数——一旦分支已经长出来再回头合并，等于重写。定间隔时按"这一段能承受多少独立内容"倒推，而不是按"故事想怎么分叉"顺推。

收束节点的实现关键是状态压缩：进入收束点时，把"走了哪条路"这个完整历史压成少量标记位（chose_A=true、trust_level=2），而不是保留完整路径。下游内容只依赖标记位，不依赖具体路径——这样下游只需要为标记位的组合数生成内容，而标记位组合数是可控的。

代价要说清：收束会削弱"我的选择真的有影响"这个体验，因为不同路径最终汇合了。所以收束节点的位置是叙事设计决策，不是技术决策——技术上你只能告诉策划"每多一层自由分支，成本和风险翻倍"，在哪收束由内容侧定。工程侧要做的是把这笔账算清楚给他们看。

玩家状态与叙事状态必须分离，这是另一个容易搞混的地方：

同步规则：叙事状态永远从玩家状态推导，不反向写。 回档时只需回滚玩家状态，叙事状态自动跟着变。如果叙事状态独立持久化，回档就必须同时回滚两份，漏一份就是"回档后剧情还记得没发生的事"这类诡异 bug。

Agent 上下文里应该放的是推导出的叙事状态（当前路径的 path_history + 角色 status），不是玩家的完整存档——存档里大量字段与生成无关，塞进去只是烧 token。

长视频：镜头并行 vs 整片连贯

这是长视频的核心矛盾，且它是真矛盾，没有两全的解：

• 要吞吐就要并行：200 个镜头串行生成，按单镜若干分钟算，总时长以天计。并行是唯一能压缩交付周期的手段。
• 要连贯就要串行：镜 N 的首帧最好接续镜 N−1 的末帧（同一场景内的连续动作），这要求镜 N−1 先完成。

三种折中，代价各不相同：

默认选分段并行，理由是它对齐了内容的自然结构——场是叙事的最小连贯单元，跨场不接的容忍度本来就高。这是个"让技术边界与内容边界重合"的选择，比纯技术折中更稳。

成本护栏：校验必须在生成前

这条是长视频最贵的教训，也是最容易被跳过的一条。

数量级问题（以下为按公开定价与常见档位推算的量级，基准日 2026-09，不是实测数字）：视频生成按秒计费，一个 8 分钟片段的一次完整生成成本，相对于「一次结构化断言校验」（几次字典查询 + 可能一次小模型调用）的成本，差距在两到三个数量级。加上时间成本（渲染以小时计 vs 校验以毫秒计），实际差距更大。

推论是刚性的：任何能在生成前校验的东西，绝不允许放到生成后。

具体落地成三道闸：

1. 生成前（最便宜）：跑 assert_continuity —— 角色状态、事件引用、已知信息。这些全部是离散事实，不需要看到画面就能判。开篇那三个事故（死人说话、引用未发生事件、设定冲突）全部属于这一类，全部本可以在生成前拦住。
2. 生成中（较便宜）：低分辨率/短时长预览先出，校验构图与角色外观，通过后再出正式素材。这一步专门防"参数在链路上丢了"（assert_visual_lock 那类）。
3. 生成后（最贵）：只留真正必须看到成片才能判的东西——节奏、观感、情绪曲线。这些是审美判断，本来就必须人评。

三道闸的划分判据很清楚：判据是离散事实的 → 生成前；判据是可视但不需要成片的 → 生成中；判据是审美的 → 生成后 + 人评。 把审美判断以外的任何东西留到生成后，就是在为一次本可避免的重渲染买单。

人在环：介入点越靠后，单次返工越贵

判据一句话：介入点越靠后，单次返工代价越高，所以越早的闸门越不能省。 成片后的评审必然存在，但它的作用应该是"确认好不好"，而不是"发现对不对"。后者一旦在成片阶段发生，前面的流程就已经失效了——开篇那次 200 多倍的成本，就是一个"对不对"的问题被拖到了"好不好"的关口。

第 5 步：评审层 —— 没有 golden answer 怎么评

创作类任务的根本特殊性：一段剧本不存在唯一正确版本。 不能套精确匹配，不能算单一成功率——「成功率 87%」对一部短剧毫无意义。

这不是"评测更难一点"，是评测的数学基础不同：有 golden answer 时评测是分类问题（对/错），没有时它是排序与打分问题（好/更好），而后者的一致性本身就需要被评测。

三层替代，覆盖面从确定到模糊：

划分判据：判据能否写成不依赖审美的检查？ 能 → 第①层，必须自动化且必须 100% 覆盖（它便宜）。不能但可以拆成有明确分档定义的维度 → 第②层。连分档都无法客观定义 → 第③层，只能抽样人评。

rubric 的关键是分档定义必须可判定。 反例：「台词自然度：1~5 分」——这是伪 rubric，两个人打分能差 2 分。正例：

台词自然度

• 4 分：无书面语残留，符合角色身份与教育背景，无解释性台词（不为了让观众懂而让角色说不该说的话）
• 3 分：偶有一处书面语或解释性台词
• 2 分：多处解释性台词，或出现与角色身份不符的用词
• 1 分：通篇像旁白

每档挂的是可观察的特征而非程度副词。这样 LLM judge 和人评才可能对齐，也才可能算标注一致性。

人评抽样的比例是这套体系里最先被规模压垮的环节。抽样比例必须与"事故的分布"匹配——如果事故集中在长尾分支（开篇那 200 条），均匀随机抽样会系统性漏掉它们。可行做法是按风险分层抽样：一致性断言失败过的路径、分支深度最深的路径、收束节点附近的路径，提高抽样权重。

为什么这么做

为什么设定必须是数据而不是提示词

这是全篇最反直觉的一条，也是最有价值的一条。

直觉上，"让模型记住设定"是个 prompt 工程问题——写得更详细、强调得更用力。但只要接受两个事实，结论就反了：上下文会被压缩，而压缩器不知道哪个词是硬约束；注意力对长 prompt 中段的利用率显著更低。这两条决定了任何"放在对话流里的设定"都会随任务变长而衰减。

把设定改成结构化数据，换到的不只是"不会丢"，更关键的是获得了可校验性：字段可以被断言，而散文只能被"感觉"。这一步把一致性问题从「模型能力问题」转化成了「工程校验问题」——前者你只能祈祷模型变强，后者你可以写测试。

这也是 AI 与游戏研发周期 那句失效边界（"AI 写不出与既有世界观一致的内容"）的推开方式：不要求模型记住世界观，而是让它每次都被喂到需要的那几个字段，并在输出后校验它有没有违反。

为什么校验前置的收益是数量级而非百分比

一般的性能优化谈的是百分比。校验前置谈的是数量级，因为它改变的不是单次成本，而是发现错误的位置。

同一个错误（"死掉的角色出现了"），在生成前发现的成本是一次字典查询；在成片后发现的成本是一整段重渲染 + 重剪辑 + 可能的连带修改。这两个数字之间差两三个数量级，而错误率并不会因为流程靠后而下降。所以这笔账永远划算，且规模越大越划算。

更深一层：校验前置还改变了错误的可发现性。生成后发现错误依赖有人看到，而人看不完所有分支；生成前的断言是全量执行的，不依赖抽样。开篇那 200 条没人看过的分支之所以危险，不是因为它们质量差，是因为它们没有被任何自动化手段覆盖过。

为什么评审 Agent 必须独立于产出方

通用规则来自 MAS · 结果聚合：模型对自己输出的评价系统性偏高。

创作场景里这条更严重，原因是缺少客观锚点。代码审查里自评偏高至少还会被测试用例纠正；创作里"这段台词好不好"没有测试用例，自评偏差没有任何东西能纠正它，只会一路累积。所以评审的独立性在创作场景不是最佳实践，是必要条件。

配套的一条：评审 Agent 应该拿到 Bible + rubric，但不该拿到产出过程。给它看编剧的推理过程，它会被"作者意图"影响（"哦原来他是想表达 X"），从而对实际产出打高分。评审只看产物，这与 MAS · 第三方仲裁隐去身份 是同一个道理。

为什么别的选择不行

「用一个大 Agent 端到端生成，不要拆六个」

听起来更省事，也确实省掉了编排复杂度。三个理由否掉它：

1. 上下文根本装不下。 一集的设定 + 剧本 + 200 个镜头描述 + 生成参数，早就超出任何窗口。拆分不是为了并行，首先是为了让每个 Agent 的上下文只装它需要的。
2. 打回粒度会坏掉。 端到端 Agent 的产物是一整集，评审说"第 6 个镜头不对"，你只能整集重来。拆开之后打回一个镜头就是重做一个镜头。拆分的真正收益是最小返工单元变小，这在生成成本高的场景直接等于省钱。
3. 不同阶段需要不同能力与不同权限。 编剧要长文本能力与 Bible 写权限，素材要图像生成工具与配额，评审要独立性。这正好符合 MAS 的三条上马判据：需要并行、需要 prompt 隔离、需要权限隔离——三条全中，所以这里该上 MAS（对照那篇里"代码审查三条全否所以不该上"的反例）。

「让分支自由生长，反正生成很便宜」

两个错：生成不便宜（上面的数量级），而且成本不是主要问题——测试面积是。

1024 条路径里，你能保证每条都跑过一致性断言（自动化，可行），但没有任何团队能人评 1024 条路径。而 rubric 与人评是唯一能发现审美与节奏问题的手段。于是自由生长的真实后果是：大部分内容从未被任何审美判断覆盖过——它们的质量是未知的，不是好的也不是坏的，是未测量的。

这比"成本高"严重得多：成本高你能算出来并决定要不要付，质量未知你连风险大小都不知道。

「靠 prompt 复述外貌保证视觉一致」

这是最常见的做法，也是最无效的一条，因为它误解了失效原因。人们以为视觉不一致是"描述得不够详细"，实际是文本到图像的映射本身是多对多的：同一段描述在不同种子下产出完全不同的脸，描述再详细也只能收窄分布，不能收敛到一点。

把外貌交给参考图 + 固定种子，prompt 只写这个镜头特有的动作与构图——"变的写 prompt，不变的给参考图"。判断自己有没有踩这个坑很简单：如果 prompt 里出现了跨镜头不变的信息，那部分就该搬进参考图。

「成片后统一评审，前面不设闸」

流程上最简单，成本上最贵。它把三类完全不同的问题（离散事实错误、可视参数错误、审美问题）压到同一个关口，而前两类本来可以用几个数量级更便宜的手段在更早发现。

更隐蔽的代价：成片后的评审注意力是有限的。评审人一边要判"设定对不对"一边要判"好不好看"，两种判断会互相干扰——发现一个明显的设定错误之后，后面的审美判断会被这个错误带偏。让每道闸只判一类问题，评审质量本身也会更高。

三种一致性手段的适用对照

三者是互补而非替代关系：断言覆盖广度、Bible 提供断言的依据、参考图管住断言管不了的视觉维度。任一缺失都会留下一整类事故的敞口。

沉淀结论

面试常见问题清单

形态与编排

• Q：互动影游和长视频的创作 Agent，架构上最大区别是什么？ A：产物结构不同决定编排不同。互动影游是分支叙事图 + 状态机，一致性挑战是横向的（不同分支不能互相引用未发生的事），完整性判据是"所有可达路径都通"，需要图遍历 + 路径覆盖；长视频是线性时间轴 + 镜头序列，挑战是纵向的（相邻镜头视觉与时序连贯），需要镜头并行 + 整片一致性。共享设定管理、素材生成、一致性护栏、评测；不共享的是分支状态机（长视频不需要）与首帧接续（互动影游因分支跳转本就不连续而弱化）。
• Q：怎么划分创作流水线的 Agent？为什么不用一个大 Agent？ A：六角色——编剧/分镜/素材/配音/剪辑/评审，评审必须独立于产出方。不用单 Agent 三个理由：上下文装不下一集的设定+剧本+200 镜头描述；打回粒度会坏掉（端到端产物是一整集，改一个镜头要整集重来，拆开后最小返工单元变小 = 直接省钱）；各阶段需要不同能力与权限。对照 MAS 三条上马判据（需并行/需 prompt 隔离/需权限隔离）——这里三条全中，所以该上。
• Q：哪些环节可以并行？ A：判据是"上游产物内容变化会不会改变下游输入"。会 → 真依赖（剧本→分镜、分镜→素材、配音时长→剪辑）；不会 → 假依赖，拆开并行（配音与分镜是假依赖，台词剧本定稿就有；镜头之间是假依赖）。判定必须在编排期做——交给运行时的模型它会保守串行，白丢并行度。

一致性（高频）

• Q：长视频/长剧集怎么保证角色前后一致？ A：四类一致性手段互不通用。角色靠结构化角色卡 pin 常驻（性格锚点/称呼表/能力清单/knows，注入 system 段，物理上不进 messages）；世界观靠 Story Bible 当黑板（结构化不是散文）；视觉靠参考图 + 固定种子；时间线靠显式事件表 + 连续性断言。核心是：设定是数据不是提示词。
• Q：为什么不能把设定写进 prompt 里反复强调？ A：三条。① 它会被压缩掉——压缩器不知道哪个词是硬约束，摘要会保留"引人注目的眼睛"而丢掉"琥珀色"。② 注意力不均匀——长 prompt 中段利用率显著更低，写得越详细中间越可能被忽略。③ 不可校验——散文没有可比对字段，只能靠人看，而人看不过来。正确做法：设定存结构化黑板，按需注入字段，生成后断言校验。prompt 里只留"冲突时以 <bible> 为准"。
• Q：视觉一致性为什么不能靠 prompt 描述外貌？ A：因为文本到图像的映射是多对多的——同一段描述换个种子就是另一张脸，描述详细只能收窄分布不能收敛到一点。必须把图像本身作为条件（参考图/角色 LoRA）+ 固定种子，把随机性从"每次不同"变成"每次相同"。一句话：变的东西写 prompt，不变的东西给参考图；prompt 里出现跨镜头不变的信息，就该搬进参考图。

特有难点

• Q：互动剧分支爆炸怎么办？ A：代价是双重指数——生成成本、测试面积、一致性校验成本（断言必须按路径求值）三者同时按 2^d 增长。唯一有效手段是收束节点：强制分支在某处汇合，进入时把"走了哪条路"压成少量标记位（chose_A/trust_lv），下游只依赖标记位不依赖完整路径，路径数从指数降回线性。代价是削弱"选择有影响"的体验——所以收束位置是叙事设计决策，工程侧只负责把账算清给策划看。另外深度超 15 层时标记位组合本身会爆，需限制单个标记的影响范围（只影响之后 2~3 场）。
• Q：玩家状态和叙事状态怎么管？ A：必须分离且单向推导。玩家状态（选择/进度/好感度）持久化进存档，需支持回档与多周目；叙事状态（已发生事件/角色状态/可用剧情池）从玩家状态推导，不独立持久化、不反向写。理由：独立存会导致回档时两份状态不同步，漏一份就是"回档后剧情还记得没发生的事"。Agent 上下文里放的是推导出的叙事状态（path_history + 角色 status），不是完整存档。
• Q：长视频镜头级并行和整片一致性怎么权衡？ A：真矛盾没有两全。三种折中：分段并行（按场切段、段内串行段间并行——保住场内连贯，跨场本有转场容忍度高，默认选它，因为它让技术边界与内容边界重合）；共享参考锚点（全并行 + 同场共享参考图与种子，保住角色与风格，丢相邻动作接续）；两阶段关键帧+补间（一致性校验前置，返工只废关键帧，代价是多一个阶段）。

成本与评测

• Q：创作 Agent 的成本护栏怎么设？ A：铁律——任何能在生成前校验的东西绝不放到生成后，因为同一错误在生成前发现是一次字典查询，成片后发现是整段重渲染，差两三个数量级（按公开定价推算），且错误率不因流程靠后而下降。三道闸按判据性质划分：判据是离散事实 → 生成前（角色状态/事件引用/已知信息，全量自动化）；可视但不需成片 → 生成中（低分辨率预览校验构图与参数是否被丢）；判据是审美 → 生成后 + 人评。校验前置还改变了可发现性——断言全量执行，不依赖抽样。
• Q：人在环该在哪介入？ A：介入点越靠后单次返工越贵，所以越早的闸越不能省。剧本定稿后（改文本，最便宜，所有项目必须有）→ 分镜定稿后（改镜头表 + 少量重生成）→ 成片后（重渲染，最贵，必须有但只应发现审美问题）。如果在成片阶段发现设定错误，说明前两道闸漏了。
• Q：创作类任务没有标准答案，怎么评测？ A：评测的数学基础变了——有 golden answer 时是分类问题（对/错），没有时是打分排序问题（好/更好），后者的一致性本身需要被评测。三层替代：① 一致性断言（离散事实，完全自动化，必须 100% 覆盖，最便宜）② rubric 打分（可拆解维度，半自动 LLM-judge，分档必须挂可观察特征而非程度副词——"1~5 分"是伪 rubric）③ 人评抽样（整体审美，不可自动化，按风险分层抽样：断言失败过的路径/最深分支/收束点附近提高权重，因为均匀随机会系统性漏掉长尾分支的事故）。划分判据：判据能否写成不依赖审美的检查。

记忆口诀

• 两类产物：互动影游 = 分支图 + 状态机（挑战横向，判据"所有可达路径都通"）/ 长视频 = 时间轴 + 镜头序列（挑战纵向，要整片连贯）
• 六角色：编剧 → 分镜 → 素材 / 配音 → 剪辑 → 评审（评审不能是产出方）
• 拓扑选择：Pipeline + 黑板，且黑板对各级只读不写（只有编剧能写 Bible）
• 真假依赖：问"上游内容变化会否改变下游输入"；配音与分镜是假依赖
• 四类一致性：角色→角色卡 pin / 世界观→Bible 黑板 / 视觉→参考图+固定种子 / 时间线→事件表+断言
• 设定铁律：设定是数据不是提示词——可断言、可 diff、可选择性注入、不参与压缩
• 视觉铁律：变的写 prompt，不变的给参考图
• 断言铁律：ContinuityError 不重试，打回编剧（重跑一万次也修不好剧本矛盾）；断言按路径求值不按全局
• 分支铁律：收束节点把 2^d 压回线性，进入时把路径压成少量标记位；收束位置是叙事决策不是技术决策
• 状态铁律：叙事状态从玩家状态推导，不反向写（否则回档必出鬼）
• 成本铁律：校验在生成前——离散事实→生成前 / 可视→生成中 / 审美→生成后，差两三个数量级
• 评测三层：一致性断言（全量自动化）→ rubric（分档挂可观察特征）→ 人评（按风险分层抽样，不能均匀随机）

内容来源

综合整理：影视工业既有的连续性管理（场记 / continuity supervisor）实践向 Agent 流水线的迁移、Story Bible 概念在编剧行业的既有定义、图像生成的条件控制与种子固定的通用做法、以及站内 Multi-Agent 系统（黑板与并发写）、Agent 运行时深水区（pin 与压缩机制）的既有结论。

成本相关数字为按公开定价与常见档位推算的量级（基准日 2026-09），不是实测结果，各家视频生成定价差异可达一个数量级，请按实际所用服务重新核算。文中阈值（单集 20 分钟、分支数 50、镜头数 200、深度 15 层）为规模锚点的经验取值，需按自身项目重新标定。生成模型能力变化快，「哪些必须人评」这条边界会随模型进步向后移动，但"离散事实前置校验"这条与模型能力无关。

自测：合上资料能说清楚吗？

1. 一部 12 集互动短剧，第 4 集主角眼睛颜色变了。定位根因，并说出根治方案与它为什么有效。

2. 为什么"校验必须在生成前"的收益是数量级而不是百分比？哪些校验能前置、哪些不能，判据是什么？

3. 对比 分段并行 与 共享参考锚点 两种长视频折中方案：各自保住什么、丢掉什么、为什么默认选前者？

4. 分支从 6 层加到 12 层，成本翻多少？为什么"测试面积"比"生成成本"更值得担心？

5. rubric 里写「台词自然度 1~5 分」有什么问题？怎么改？人评抽样为什么不能均匀随机？