另一条路：基于多 Agent 协作的 AI 影视制作管线深度解析

「另一条路」（项目代号 another-road）是一个基于 OpenCode AI Agent 框架构建的影视/动画制作管线工作区。它的核心思路是：将影视制作的全流程——从剧本解析、角色/场景/道具设定提取、视觉资产生成，到分镜拆解、AI 视频生成——拆解为多个专业化的 Agent 协作节点，通过一个统一的 Orchestrator（路由调度员）进行任务分发与结果汇总。

这套系统的独特之处在于：它不是简单的”一个 Prompt 出视频”，而是一套严格分阶段、职责边界清晰、元数据驱动的工程化管线。每个 Agent 只做自己分内的事，不越权；所有产物通过 Coordinator 统一归档；阶段流转通过不可逆状态机管理；图像生成通过 MCP 服务器标准化接入。

系统全景架构

整个系统由四个层次构成：Agent 编排层、技能能力层、MCP 工具层、元数据管理层。各层职责分离，通过 JSON Schema 和文件系统协议进行通信。

系统采用严格的分层架构：Agent 编排层负责意图识别和任务分发，技能能力层提供具体操作指南，MCP 工具层封装外部 API 调用，元数据管理层追踪项目状态和产物。Agent 之间不直接通信，全部通过 Orchestrator 中转。

配置入口：opencode.json

系统的核心配置文件 opencode.json 定义了所有 Agent 的角色、模型、权限和工具访问策略。不同 Agent 使用不同的大语言模型：

Orchestrator 路由调度机制

Orchestrator 是整个系统的”大脑入口”，但其设计哲学极为克制：它只做一件事——理解意图、分发任务、汇总结果。

Orchestrator 的行为规则被定义为六条”铁律”，核心思想是零调研、3 秒决策、绝不亲自动手。这意味着 Orchestrator 收到用户消息后，不会先去读文件、搜索代码或了解项目状态，而是直接根据意图匹配表 spawn 对应的子 Agent。

意图匹配表

Orchestrator 通过一张预定义的意图匹配表将用户自然语言映射到具体的子 Agent：

六阶段制作管线

从原始剧本到 AI 视频成片，系统定义了六个标准化制作阶段，每个阶段有明确的执行 Agent、前置条件和产出物。

阶段 1：项目初始化

由 Coordinator 执行。生成项目 UUID，创建 .meta/projects/{id}/ 元数据目录，初始化四个核心文件：project.json（项目信息）、stages.json（16 阶段状态机）、manifest.json（产物清单）、events.jsonl（事件日志）。同时创建项目业务目录骨架，逐项询问用户填写画幅、分辨率、模型等全局配置，写入 project_config.json。

阶段 2：监制提取设定

由 Producer 执行，是整个管线最上游的内容处理节点。Producer 实现了”三重信息融合”：剧本文本 + 联网历史检索 + 多模态视觉采样。它会扫描前期采样图用 Vision 能力提取视觉信息，识别历史真实内容并联网检索官职服饰、建筑形制等权威资料，最终输出全局设定、角色设定、场景设定、道具设定和分集剧本。

阶段 3：全局视觉资产生成

由 Character Director + Prop Maker + Set Designer 生成任务表 JSON，再交由 Art Director 执行 AI 生图。角色资产分两步生成：Tier 1 选角资产（白 T 恤七视图，排除服装干扰聚焦角色本体）→ Tier 2 默认定妆（基于角色设定的造型设计）。这种分层设计巧妙地解耦了”角色本体”与”服装造型”。

阶段 4：拆解分镜

由 Storyboard Director 执行，将分集剧本拆解为场→组→镜三级结构化 JSON。每个镜头包含 17 个字段（景别、摄影机角度/运动、焦距景深、光线、氛围、台词、音效等）。关键设计是”Agent 智能创作 + 脚本机械拆分分离”——LLM 负责理解剧本和创作分镜内容，Python 脚本仅做最后一步机械拆分为独立组 JSON。

阶段 5：剧集级参考图 + 资产同步

基于分镜脚本中的出场信息，各 Director 生成剧集级参考图任务表，Art Director 执行生图后，由 Coordinator 将所需妆造资产从全局依赖目录复制到 temp/分组素材/{剧集号}/，供 Video Director 使用。这里引入了妆造衣橱机制：global 模式初始化衣橱，episode 模式只读匹配，发现新妆造时向 Orchestrator 报告。

阶段 6：视频生成

由 Video Director 执行，通过 LibTV CLI 将分镜组 JSON 转化为画布上的 video 节点并触发 AI 视频生成。核心流程：绑定画布项目 → 上传参考素材 → 创建 video 节点 → 批量分组运行 → 轮询等待完成。如有下一集，回到阶段 4 循环执行。

Agent 角色矩阵

系统定义了 10 个 Agent，分为三类：路由层（1 个）、制作层（8 个）、工程层（1 个）。每个 Agent 有严格的职责边界和权限控制。

职责边界的”三不原则”

技能体系：17 个能力模块

技能（Skill）是 Agent 的”操作手册”。每个 Skill 定义了特定领域的详细工作流、约束规则和输出规范。Agent 在执行时按需加载对应 Skill。

系统的 17 个技能可分为四大类：制作核心技能（8 个）、文档处理技能（2 个）、工程辅助技能（5 个）、创作辅助技能（2 个）。

制作核心技能

角色资产的三模式架构

roles-ref-generator 技能定义了三种定位模式来覆盖角色资产的生命周期：

MCP 服务器架构：GRSAI 图像生成

系统通过 MCP（Model Context Protocol）标准将外部 API 能力封装为工具，供 Agent 安全调用。GRSAI Server 是唯一的生产级 MCP 服务器，提供 5 个工具。

GRSAI Server 基于 FastMCP 标准范式构建，采用异步架构，核心流程为”提交→轮询→下载”三段式。它将图像生成 API、腾讯云 COS 存储和配置管理整合为一个自包含服务。

图像生成三段式流程

模型自适应参数处理

不同模型族对参数格式的要求不同：

# gpt-image 系列：需要像素格式
aspectRatio = resolve_aspect_ratio("16:9", "4K")  # → "3840x2160"

# nano-banana 系列：直接传比例格式
aspectRatio = "16:9"  # 原样传递
imageSize = "4K"      # 原样传递

系统通过 _is_nano_banana_model(model) 判断模型族，自动选择参数格式。同时维护了一张 ASPECT_RATIO_PIXEL_MAP 常量表，将 13 种比例 x 3 档分辨率映射到具体像素值。

批量生成策略

数据流转与 Schema 设计

多 Agent 协作的核心挑战是数据格式一致性。系统通过共享 JSON Schema 和标准化产物路径映射，确保 Agent 间的数据交接无歧义。

核心 Schema：image-generation.json

所有图像生成任务遵循统一的 JSON Schema，它是上游 Director Agent 和下游 Art Director 之间的”合同”：

{
  "tasks": [
    {
      "prompt": "提示词（必填，原样透传 API）",
      "model": "gpt-image-2",
      "aspectRatio": "16:9",
      "imageSize": "1K",
      "filename": "output.png",
      "images": ["参考图URL或本地路径"]
    }
  ],
  "model": "gpt-image-2",
  "output_path": "./output",
  "oss_path": "project/xxx/reference/"
}

Schema 的设计有几个关键约束：additionalProperties: false 防止字段注入；prompt 是唯一必填字段；模型优先级为 task.model > 顶层.model > 配置文件 GRSAI_MODEL；本地路径会自动触发 COS 上传。

元数据管理：事件溯源模式

Coordinator 通过 events.jsonl 实现事件溯源，所有操作都记录为不可变事件：

通过回放事件日志，可以重建任意时刻的项目状态快照。这是一种典型的 CQRS/Event Sourcing 模式在 Agent 系统中的应用。

16 阶段状态机

stages.json 定义了 16 个生产阶段的精细状态机，比 6 阶段管线更细粒度——它将阶段 3 的”角色/道具/场景”任务表和美术产出拆分为独立的 6 个子阶段：

核心设计模式总结

透过代码和配置，可以提炼出这套系统最值得借鉴的六个工程设计模式。

重构演进：从散装脚本到统一 MCP

系统的工具层经历了一次完整的 7 阶段重构（Phase 0-6），将分散的 CLI 脚本收拢为统一的 MCP 服务器。

重构前 vs 重构后

重构的核心收益是凭证收口、代码去重、接口标准化。重构后 MCP Server 提供 5 个工具：grsai_health_check、grsai_call_llm、grsai_generate_image、grsai_batch_generate、grsai_upload_cos，覆盖了图像生成和 LLM 调用的全部需求。

总结与思考

「另一条路」展示了一种工程化的 AI Agent 协作范式——不是追求”一个 Prompt 解决一切”，而是将复杂任务拆解为严格分阶段、职责清晰的专业节点。

这套系统的价值不在于它使用了多先进的模型，而在于它解决了一个核心工程问题：如何让多个 AI Agent 在长流程任务中可靠协作。它的答案是一套完整的”协议栈”——意图匹配表定义路由规则、共享 Schema 定义数据契约、事件溯源定义状态追踪、最小权限定义安全边界、不可逆状态机定义流程纪律。

值得借鉴的设计

• Orchestrator 的克制：路由器就是路由器，不做调研、不加载技能、3 秒决策。这种克制避免了”上帝 Agent”的反模式。
• Coordinator 的元数据隔离：只管路径和哈希，不读内容。这是控制 token 开销的关键。
• 妆造衣橱机制：通过 global/episode/group 三模式 + 衣橱索引，解决了系列片中角色造型一致性的难题。
• 智能创作与机械执行分离：LLM 做创作，脚本做拆分和校验，各司其职。

改进空间

• 当前 Agent 间通信完全依赖文件系统，缺乏内存级的数据传递机制，大量文件 I/O 可能成为性能瓶颈。
• events.jsonl 的单文件追加模式在高并发场景下可能存在写入竞争。
• 缺少自动化的失败恢复机制——如果某个 Agent 执行失败，需要人工介入重新 spawn。
• COS 上传整文件读入内存，大文件场景需要流式上传优化。