基于MCP的多智能体视频创作流程设计与实现

视频内容生产正在从“单个大模型写稿”走向“多个智能体协作成片”的阶段。但把脚本、素材、剪辑、字幕、审核这些环节交给不同 Agent 之后，最现实的问题不是模型能力不够，而是每个 Agent 需要访问的工具和数据五花八门：有的要查素材库，有的要写分镜文件，有的要调用视频导出接口。如果每个 Agent 都自己去对接一套 API，项目会迅速变成一堆彼此不通的胶水代码。MCP（Model Context Protocol）正是用来解决这一层问题的开放协议。

本文围绕“基于 MCP 的多智能体视频创作流程”展开，先讲清楚 MCP 为什么适合做 Agent 与工具之间的统一接入层，再给出角色拆解、最小 MCP Server 实现、编排层设计、运行验证和常见排错路径。文章适合正在做 AI 视频工具、内容自动化平台或 Agent 编排系统的开发者，也适合想从单 Agent 演示走向多角色协作项目的工程师。阅读完你可以得到一套可以直接落地的系统骨架：一个可启动的 MCP Server、一组按视频创作阶段划分的 Agent 配置、一个负责路由和质检的编排器，以及一套从日志中定位问题的排查方法。

1. 先理解 MCP 在多智能体系统中扮演什么角色

1.1 MCP 解决的是工具接入碎片化问题

MCP 是 Model Context Protocol 的缩写，是一种用于大模型应用与外部工具、数据源之间通信的开放协议。它的设计目标非常直接：让模型应用不需要为每一个工具写一套专属集成代码，而是通过统一的协议去发现和调用工具。

在视频创作系统里，这个问题的具体表现是：编剧 Agent 需要查询热点词和素材库，导演 Agent 需要读取分镜模板，剪辑 Agent 需要调用 FFmpeg 或剪辑软件的导出接口。如果不用 MCP，每个 Agent 都要单独写 HTTP 请求、处理各自的鉴权、字段映射和错误码。一旦工具从三个增加到十个，代码维护成本会指数级上升。

MCP 采用客户端-服务器架构，底层基于 JSON-RPC 2.0 通信。模型应用侧是 MCP Client，工具和数据提供方是 MCP Server。一个 Client 可以同时连接多个 Server，一个 Server 可以暴露多个能力。这样“Agent 需要什么工具”就变成了“Agent 连接哪些 MCP Server”，而不是“Agent 里写死了哪些 API”。

1.2 工具、资源、提示词：MCP 的三个核心原语

MCP 的能力模型可以理解为三个级别：

• 工具（Tool）：可执行的操作，例如“搜索素材库”“生成字幕”“导出视频”。工具由模型根据用户意图决定是否调用，适合需要动态决策的场景。
• 资源（Resource）：只读的数据，例如“分镜脚本模板”“品牌词库”“视频风格规范”。资源由应用主动读取，适合作为上下文注入给模型。
• 提示词（Prompt）：预置的提示模板，例如“短视频口播稿模板”“产品测评结构模板”。提示词帮助模型快速进入特定任务状态。

三者的区别在实际项目中很重要。工具是“动作”，资源是“数据”，提示词是“指令”。如果你把一份 2 万字的品牌规范当作工具返回，模型可能会把它当作一次调用结果来处理，既浪费 token，也没办法在流程启动前就注入上下文。正确做法是把品牌规范做成资源，在对应阶段的 Agent 启动时主动读取。

1.3 把 MCP 放到视频创作场景里看

在一个多智能体视频创作流程中，MCP 更像是一条“工具总线”。每个 Agent 不直接感知工具的具体实现，它只知道“我可以通过 MCP Client 调用哪些 Server 上的哪些工具”。这种解耦带来的直接收益是：素材库从本地目录换成云端对象存储时，只需要改对应 MCP Server 的实现，不需要改动调用它的 Agent 代码。

系统角色	在 MCP 中的位置	典型能力
剧本 Agent	MCP Client + 调用方	调用热点检索、大纲生成
导演 Agent	MCP Client + 调用方	读取分镜模板、生成分镜脚本
素材 Agent	MCP Client + 调用方	检索视频片段、筛选素材
剪辑 Agent	MCP Client + 调用方	调用转码、字幕、合成工具
素材库系统	MCP Server	提供素材检索和元数据查询
剪辑工具链	MCP Server	提供 FFmpeg 封装、导出任务

这里要注意，MCP 本身不解决“多个 Agent 如何协作”的问题，它只解决“Agent 如何统一地使用工具”的问题。真正把创作流程串起来，还需要一个清晰的编排层。这也是本文后续重点讲的部分：在 MCP 之上，用配置和编排器控制 Agent 的角色、顺序、输入输出和质检规则。

2. 视频创作流程的角色拆解与技术主线

2.1 从选题到成片要经过哪些阶段

一个完整的视频创作流程，即使是最轻量的短视频，也至少包含下面几个阶段：

1. 选题策划：确定主题、目标受众、核心观点、标题方向。
2. 脚本撰写：生成口播稿或旁白稿，划分段落和时长。
3. 分镜设计：把脚本转成镜头列表，确定画面、景别、字幕、转场。
4. 素材准备：检索视频片段、图片、背景音乐，匹配每个镜头。
5. 剪辑合成：按分镜顺序拼接片段，加入字幕、配音、转场和导出。
6. 质检审核：检查时长、字幕错别字、画面匹配度、品牌规范。

在单 Agent 模式下，这六个阶段靠一个超长 prompt 和一次对话完成，结果不稳定，也很难定位是哪个环节出了问题。在多智能体模式下，每个阶段由一个专门 Agent 负责，阶段之间通过结构化数据传递。这种模式对工程的要求更高，但可控制性和可维护性也明显更好。

2.2 四个智能体角色和它们需要的工具

项目正文没有指定具体角色数量，但综合考虑视频创作的最小闭环和 MCP 的最佳实践，建议先设计四个角色：编剧 Agent、导演 Agent、素材 Agent、质检 Agent。剪辑阶段如果已经存在成熟的剪辑工具，可以由素材 Agent 触发，也可以单独拆出一个剪辑 Agent。

Agent 角色	核心职责	依赖的 MCP 工具	输入	输出
编剧 Agent	选题、大纲、口播稿	热点检索、关键词分析	用户输入的选题方向	结构化脚本 JSON
导演 Agent	分镜设计、镜头规划	分镜模板资源、镜头编号工具	脚本 JSON	分镜 JSON
素材 Agent	素材检索、镜头匹配	素材库检索、素材元数据查询	分镜 JSON	镜头-素材映射 JSON
质检 Agent	规范检查、返工建议	质检规则资源、评分工具	最终脚本和分镜	质检报告 JSON

四个角色之间是串行依赖关系，但质检 Agent 的结果会回传给前面的 Agent，形成返工回路。这种“正反博弈 + 裁判”的结构在不少 Agent 项目中被反复使用，它的价值不是让结果更好看，而是让关键错误在进入剪辑阶段之前被发现。

2.3 用阶段化流程代替“一个 prompt 干完所有事”

多智能体系统（MAS）最容易犯的错误是让多个 Agent 同时自由发挥，最后把结果拼在一起。实际工程里更稳定的做法是阶段化：每个阶段只有一个主 Agent 在“干活”，其他 Agent 要么等待输入，要么在质检阶段介入。

阶段化流程的另一个好处是便于定位问题。如果最终视频的字幕和音频对不上，你可以从前一个阶段的输出 JSON 里直接判断是脚本阶段就把时间轴写错了，还是剪辑阶段没有按时间轴执行。如果所有环节都混在一个对话里，排查成本会高得多。

2.4 阶段间的数据契约要提前定义

阶段化协作的前提是定义清晰的数据契约。脚本 JSON、分镜 JSON、素材映射 JSON 都应该有固定字段。不要依赖自然语言文本在两个 Agent 之间传递信息，否则下游 Agent 每次都会以不同的方式理解上游的输出。

后面第 5 节会给出一个最小分镜 JSON 结构。这里先强调：数据契约是编排层的“接口”，它的稳定性决定了整个流程的稳定性。字段可以少，但不能每次推理结果都不一样。

3. 环境准备：先用最小 MCP Server 打通工具调用

3.1 依赖与目录结构

在搭建完整流程前，先把 MCP 的最小链路跑通。这样可以提前排除协议、依赖、传输方式上的问题，避免把环境问题误认为是 Agent 协作问题。

建议使用 Python 3.10 以上版本，项目结构如下：

video-mcp/ ├── servers/ │ ├── material_server.py │ ├── storyboard_server.py │ └── render_server.py ├── agents/ │ ├── orchestrator.py │ ├── script_agent.py │ ├── director_agent.py │ ├── material_agent.py │ └── critic_agent.py ├── config/ │ ├── pipeline.json │ └── mcp_servers.json ├── data/ │ ├── templates/ │ └── outputs/ └── requirements.txt

requirements.txt 至少需要包含 MCP 客户端和服务端 SDK。具体版本以你安装时的官方文档为准，建议锁版本后提交到依赖锁文件，避免不同开发机器之间出现 SDK API 不一致的问题。

注意：MCP 生态迭代很快，示例代码只说明实现思路。实际项目中要结合自己安装的 mcp、fastmcp 或对应语言 SDK 的版本来调整导入路径和方法签名。

3.2 实现一个最小 MCP Server

这里用 Python 实现一个最小的素材检索 MCP Server。它暴露一个 search_material 工具，内部先读取本地素材索引，后续可以替换成真实素材库。

# servers/material_server.py from mcp.server.fastmcp import FastMCP mcp = FastMCP("material-server") @mcp.tool() def search_material(keyword: str, category: str = "video", limit: int = 5) -> dict: """根据关键词检索素材库中的可用片段。""" # 真实项目中这里会查询素材数据库或对象存储索引 items = [ {"id": "clip_001", "url": "s3://assets/city_night.mp4", "duration": 8.5, "tags": ["城市", "夜景"]}, {"id": "clip_002", "url": "s3://assets/office.mp4", "duration": 12.0, "tags": ["办公", "人物"]} ] matched = [i for i in items if keyword in " ".join(i["tags"])] return {"keyword": keyword, "total": len(matched), "items": matched[:limit]} @mcp.resource("template://storyboard") def get_storyboard_template() -> str: """读取分镜脚本模板。""" return "scene, duration, shot_type, description, subtitle, material_id" if __name__ == "__main__": mcp.run()

这段代码的关键点有三个：@mcp.tool 把 Python 函数暴露成 MCP 工具；@mcp.resource 把数据暴露成只读资源；mcp.run() 启动服务监听，等待 Client 连接。

搜索工具在真实项目中不应写死数据。更稳妥的做法是让函数内部调用素材库 API 或数据库查询，并且加上超时和异常捕获，避免素材库单点故障拖垮整个编排流程。

3.3 用 MCP Client 验证工具可用

服务端准备好后，写一个最小 Client 验证连接和调用：

# test_client.py import asyncio from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client async def main(): server_params = StdioServerParameters( command="python", args=["servers/material_server.py"] ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: await session.initialize() tools = await session.list_tools() print("discovered tools:", [t.name for t in tools]) result = await session.call_tool( "search_material", {"keyword": "城市", "limit": 2} ) print("call result:", result) asyncio.run(main())

如果一切正常，控制台会先打印出已发现的工具名称，再打印出素材检索结果。这一步跑通后，说明 MCP 客户端和服务端的传输链路、协议握手、工具发现、工具调用四个环节都没有问题。

3.4 这个阶段最容易踩的坑

第一个坑是版本不匹配。MCP SDK 还在快速迭代，不同小版本的 SDK 可能在客户端初始化参数、工具返回结构上有变化。建议固定版本并保留 requirements 锁文件。

第二个坑是 stdio 传输模式下子进程的日志污染。如果 MCP Server 里用 print 输出调试信息，这些信息会被当成协议数据传输给客户端，导致解析失败。调试时请使用 logging 模块输出到文件，而不是 print 到标准输出。

第三个坑是工具参数类型不匹配。MCP 工具的参数有类型声明，如果 Client 传入的参数类型和服务端声明不一致，可能出现空结果或调用失败。排查时先看服务端日志，再看 Client 实际发送的参数结构。

4. 编排层设计：让多个智能体按流程协作

4.1 用配置定义角色、阶段和工具权限

编排层是连接“MCP 工具总线”和“多个 Agent”的桥梁。不建议把编排逻辑写在 Agent prompt 里，而应该用配置文件显式定义阶段顺序、每个 Agent 可访问的 MCP Server、输入来源和输出路径。

{ "pipeline": "video_creation_v1", "stages": [ { "name": "script", "agent": "script_agent", "prompt_template": "prompts/script.md", "servers": ["topic_server", "material_server"], "input": "user_brief", "output": "data/outputs/script_01.json" }, { "name": "storyboard", "agent": "director_agent", "prompt_template": "prompts/storyboard.md", "servers": ["storyboard_server"], "input": "data/outputs/script_01.json", "output": "data/outputs/storyboard_01.json" }, { "name": "material_match", "agent": "material_agent", "prompt_template": "prompts/material_match.md", "servers": ["material_server"], "input": "data/outputs/storyboard_01.json", "output": "data/outputs/material_map_01.json" }, { "name": "review", "agent": "critic_agent", "prompt_template": "prompts/review.md", "servers": ["review_server"], "input": "data/outputs/material_map_01.json", "output": "data/outputs/review_01.json" } ] }

配置文件的价值在于：调整流程顺序、替换 Agent 提示词、增加新的 MCP Server 时，不需要改代码。运营人员或新同事可以通过修改 JSON 快速调整流程。

这里要强调一个设计原则：每个阶段只有一个 output 文件。这样下一阶段读到的数据是确定的，不会出现上游同时写了两个文件导致下游读到不一致数据的情况。

4.2 编排器实现：阶段路由与结果传递

编排器负责读取配置、启动对应 Agent、传入上阶段输出、收集本阶段结果。下面是一个极简编排器骨架：

# agents/orchestrator.py import json class Orchestrator: def __init__(self, pipeline_config, agent_factory): self.stages = pipeline_config["stages"] self.agent_factory = agent_factory async def run(self, user_brief: str): current_input = user_brief results = {} for stage in self.stages: agent = self.agent_factory.create(stage["agent"]) agent.servers = stage.get("servers", []) output = await agent.process(current_input) self._save(stage["output"], output) results[stage["name"]] = output current_input = output return results

编排器的职责只有三个：按顺序调度、传递数据、保存结果。它不关心 Agent 内部如何推理，也不关心工具如何实现。这种“编排器保持简单”的做法能让整个流程更容易测试：你可以单独喂给某个阶段一个 JSON，验证它的输出格式是否符合预期。

如果项目需要更复杂的流程控制，可以在配置里增加 condition、retry、parallel 字段。但第一版建议只做串行流程，先把稳定性跑出来。

4.3 质检和返工回路

质检 Agent 在流程中起到“裁判”作用。它读取上一阶段的输出，按照配置好的质检规则打分，并输出“通过”或“返工”的决定。

{ "review": { "passed": false, "score": 68, "issues": [ {"level": "error", "position": "script_01.json:scene_3", "message": "分镜时长与脚本段落时长不一致"}, {"level": "warning", "position": "storyboard_01.json:scene_5", "message": "缺少字幕描述字段"} ], "suggestion": "返回 director_agent 重新生成 scene_3 到 scene_5" } }

返工回路实现时要注意两点：一是设置最大返工次数，防止劣质结果无限循环；二是返工时要把质检报告传给上游 Agent，让上游知道错在哪里，而不是简单地让它“重新生成一遍”。

4.4 状态持久化的重要性

每个阶段的输出都应该落盘或写入数据库。这样做有三个目的：一是便于排查问题，你可以查看某个版本的分镜 JSON 到底长什么样；二是支持断点续跑，如果第三个阶段失败，修复后可以从第三个阶段继续，不用从头跑；三是为后续的版本对比和效果评估保留数据基础。

生产环境中建议每个阶段输出带上 pipeline_id、stage_name、timestamp 三个字段，方便按流程实例追踪。只覆盖同一个 output 文件的方式只适合本地实验。

5. 关键实现：把素材检索、分镜脚本和剪辑导出接入 MCP

5.1 素材检索工具

素材检索是视频创作流程里最典型的 MCP 工具。它接收关键词、时长范围、分辨率等条件，返回候选素材列表。真实实现时建议在工具内部加上缓存和超时控制。

# servers/material_server.py（扩展） from mcp.server.fastmcp import FastMCP mcp = FastMCP("material-server") @mcp.tool() def search_material(keyword: str, min_duration: float = 3.0, max_duration: float = 30.0, resolution: str = "1080p") -> dict: """按条件检索素材库片段。""" query = { "keyword": keyword, "min_duration": min_duration, "max_duration": max_duration, "resolution": resolution } # 此处应替换为素材库 API 调用 candidates = _query_asset_db(query) if not candidates: return {"keyword": keyword, "total": 0, "items": []} return { "keyword": keyword, "total": len(candidates), "items": candidates }

素材 Agent 拿到结果后，会根据分镜的镜头时长和画面描述筛选匹配项。这个环节最容易出现的问题是“素材数量太少导致剪辑阶段缺料”，因此素材检索工具的返回结果应该包含候选素材的备用项，而不仅是第一个匹配项。

5.2 分镜脚本结构的标准化

分镜 JSON 是多智能体视频创作流程中最核心的数据契约。建议至少包含 scene_id、shot_type、duration、description、subtitle、material_id 六个字段。

{ "video": { "title": "城市夜景延时摄影教程", "total_duration": 45 }, "scenes": [ { "scene_id": "scene_001", "shot_type": "全景", "duration": 8.0, "description": "城市天际线从黄昏过渡到夜景", "subtitle": "城市最迷人的时刻，是灯光亮起的那一秒", "material_id": "clip_001" }, { "scene_id": "scene_002", "shot_type": "特写", "duration": 6.0, "description": "延时摄影相机参数界面", "subtitle": "先把相机固定在三脚架上", "material_id": "clip_003" } ] }

分镜 JSON 的字段要由导演 Agent 严格生成。为了让输出稳定，可以在导演 Agent 的系统提示词中强调“只输出 JSON，不做解释”，并在编排器里增加一个 JSON Schema 校验步骤。校验失败直接返工，而不是让下游硬着头皮解析。

5.3 剪辑导出与回写

剪辑工具链也可以通过 MCP Server 暴露给 Agent。核心是把 FFmpeg 或剪辑软件的调用封装成工具，并返回任务状态和输出文件路径。

# servers/render_server.py from mcp.server.fastmcp import FastMCP mcp = FastMCP("render-server") @mcp.tool() def export_video(project_json_path: str, output_path: str) -> dict: """根据项目 JSON 拼接视频并导出。""" # 解析 project_json，调用 FFmpeg 完成拼接 # 这里仅为示例，真实项目要处理转码队列、进度上报和失败重试 command = [ "ffmpeg", "-y", "-f", "concat", "-safe", "0", "-i", project_json_path, "-c", "copy", output_path ] # subprocess.run(command, check=True, timeout=300) return { "status": "success", "output": output_path, "duration": 45.0 }

导出工具建议设计成异步模式：先创建导出任务，返回 task_id，由剪辑 Agent 轮询任务状态。同步模式在视频很长时容易触发 MCP 工具超时，导致编排器误判为工具失败。

5.4 工具参数设计参考

工具	参数	说明	错误表现
search_material	keyword, min_duration, max_duration, resolution	关键词必填；时长范围建议设置默认值	参数缺失时返回空结果
generate_storyboard	script_json, template_id	输入为脚本 JSON 路径	脚本格式非法时返回异常
export_video	project_json_path, output_path	异步任务模式更稳定	超时或输出路径无权限时报错
review_video	project_json, brand_rules_path	配合资源读取品牌规范	品牌规范读取失败时跳过检查

参数后面要跟着默认值和边界检查。工具被 Agent 调用时，Agent 可能传错参数类型，因此工具内部要做防御性校验，不能假设上游永远正确。

6. 运行验证：输入一个选题，跑通第一版流程

6.1 最小运行案例

第一版验证不建议直接跑完整剪辑流程。先在本地跑“选题 → 脚本 → 分镜 → 素材匹配 → 质检”的流程，输入一个简单的选题：

python agents/orchestrator.py \ --brief "3 分钟城市夜景延时摄影入门" \ --config config/pipeline.json

正常流程会依次生成：

data/outputs/script_01.json data/outputs/storyboard_01.json data/outputs/material_map_01.json data/outputs/review_01.json

打开 storyboard_01.json，确认场景数量、总时长、每个场景的字幕和素材 ID 都存在。打开 review_01.json，确认质检分数和通过状态符合预期。

6.2 检查点清单

每跑完一个阶段，至少要检查以下内容：

• 脚本 JSON 是否包含标题、总时长、分段列表。
• 分段时长总和是否等于总时长。
• 分镜 JSON 的场景数量是否与脚本分段数量一致。
• 每个分镜是否包含 material_id，并且该素材可以在素材库中查到。
• 质检报告是否覆盖了脚本、分镜、素材匹配三个层面。
• 日志中是否出现 MCP 工具调用的耗时和状态记录。

这里要特别提醒：不要只验证流程能跑通，还要验证输入、输出、异常分支和日志是否符合预期。只看到四个 JSON 文件生成就算成功，往往会漏掉数据质量层面的问题。

6.3 日志与可观测性

编排器在每次阶段切换时应该记录结构化日志，至少包含 pipeline_id、stage、agent、input_path、output_path、tool_calls、duration_ms 六个字段。

{ "timestamp": "2025-01-10T15:30:12Z", "pipeline_id": "pipe_20250110_001", "stage": "material_match", "agent": "material_agent", "tool_calls": [ {"tool": "search_material", "keyword": "夜景", "total": 12} ], "duration_ms": 3450 }

结构化日志是排查“哪个 Agent 调用了哪个工具、花了多久、返回了什么”的唯一依据。一定要在项目一开始就加，不要等出了问题再补。

7. 常见问题排查：从现象倒推原因

7.1 MCP Server 连接失败

现象：Client 启动时抛出初始化失败，或工具列表为空。

排查顺序：

1. 确认 MCP Server 命令和参数是否正确，例如 stdio 模式下的 command、args 是否配错。
2. 确认服务端进程是否正常启动，查看服务端日志中是否有 Python 语法错误或依赖缺失。
3. 确认服务端是否使用了 print 输出调试信息。标准输出被污染会导致协议解析失败。
4. 确认 SDK 版本兼容性。

处理建议：先用独立 Client 脚本连接单个 MCP Server，排除编排层问题，再逐步接入多个 Server。

7.2 工具调用超时或参数不匹配

现象：编排器在某个阶段长时间等待，或工具返回“invalid argument”。

排查顺序：

1. 查看日志中实际传给工具的参数结构，确认字段名和类型。
2. 确认工具是否设计为同步执行。耗时长的大任务建议改成异步任务模式。
3. 确认 Client 侧的工具调用超时参数是否设置得太小。
4. 检查工具内部的异常是否被捕获并转换为 MCP 错误返回。

处理建议：给每个工具设置合理的超时，并为耗时长任务设计 task_id 轮询模式。

7.3 上下文过大与自动总结失效

现象：某 Agent 提示“上下文过大，已进行多次自动总结但上下文大小仍超出限制”。

根因通常是两个：一是把大量素材原文一次性塞给 Agent，二是把上一阶段完整输出重复传给多个下游 Agent。

排查顺序：

1. 确认 Agent 输入中是否包含了完整的素材文件而不是素材元数据。
2. 确认分镜 JSON 是否包含大段 base64 内容或原始文本。
3. 确认上下文压缩策略是否生效，是否在每次工具调用后保留了过多历史消息。

处理建议：只传结构化摘要和必要字段。素材内容放在文件路径或对象存储 URL 中，由工具按需读取。上下文管理要从数据契约层解决，而不是依赖模型自动总结。

问题现象	常见原因	检查方式	处理建议
Server 连接失败	依赖缺失、参数错误、stdout 被污染	查看服务端日志、独立 Client 测试	锁版本、日志写文件、逐项检查参数
工具调用超时	同步执行耗时过长	查看工具耗时日志	改为异步任务 + task_id 轮询
上下文超限	传入了完整素材或大量原始数据	检查 Agent 输入字段	只传元数据和文件路径
多 Agent 结果互相覆盖	多个阶段写同一文件	检查输出路径	每个阶段独立输出文件
素材匹配为空	检索条件过于严格	检查关键词和时长范围	放宽条件，返回候选备用项

7.4 多智能体结果互相覆盖

现象：回放流程时发现某个阶段的输出和预期不一致，或者两个分支结果写到了同一个文件。

排查方法：

1. 检查输出路径是否包含 pipeline_id 和 stage_name。
2. 检查是否多个 Agent 实例并发写同一文件。
3. 检查配置文件中相同 stage 是否被重复执行。

处理建议：所有输出路径必须带上 pipeline_id，禁止固定文件名。返工时建议生成新文件，保留原始版本用于对比。

8. 生产环境落地建议与扩展方向

8.1 学习环境与生产环境的区别

本地实验时，使用 stdio 模式启动 MCP Server 最简单，调试也方便。但生产环境通常有多个 MCP Server 分布在不同的机器上，stdio 模式不适合跨网络通信，建议换成流式传输或 HTTP 传输模式。

维度	学习环境	生产环境
传输方式	stdio	网络传输，统一鉴权
配置	代码内置	配置中心 + 环境变量
工具权限	全量开放	按 Agent 最小授权
日志	控制台	集中日志平台
素材存储	本地目录	对象存储 + CDN
失败处理	直接报错	重试、告警、人工介入
数据版本	覆盖写入	版本化 + 回滚

8.2 MCP 权限、安全与审计

多智能体系统里，每个 Agent 能够调用的工具会直接影响最终结果质量。建议在编排层维护一张“Agent 到 MCP Server 的权限映射表”，不允许 Agent 无限制访问所有工具。

安全方面需要关注三点：

• 工具权限最小化：素材 Agent 不需要调用导出视频工具，就不应该连接 render-server。
• 文件路径校验：导出工具的输出路径不能允许 Agent 任意指定，防止覆盖系统文件。
• 审计日志：每个工具调用都要记录调用方 Agent、调用时间、参数和结果，便于事后追溯。

8.3 可复用交付清单

项目收尾前，建议逐项检查以下清单：

• MCP Server 是否独立于 Agent 代码可单独启动。
• 每个工具的输入输出是否有类型声明和防御性校验。
• 每个阶段的输出是否有固定 JSON Schema。
• 编排器是否支持从任意阶段断点续跑。
• 日志是否包含 pipeline_id、stage、tool_calls、duration_ms。
• 是否有最大返工次数限制。
• 是否区分了模型提示词和工程配置。
• 是否对上下文使用做了裁剪，避免超限。
• 是否定义了素材、脚本、分镜的版本管理策略。
• 是否准备了一组用于回归测试的固定测试用例。

8.4 扩展方向

第一版跑通后，可以从以下方向扩展：

• 引入 Dify、Coze 等可视化编排平台。这类平台很多已经支持添加本地或远程 MCP Server，可以降低配置门槛。
• 接入更多 MCP 生态工具。当前 MCP 的生态在快速扩大，素材、设计、数据查询等领域都有现成 Server 可以复用，例如通过 MCP 直接查询业务数据库、调用设计工具生成封面图等。
• 增加并行分支。例如素材 Agent 可以同时检索视频素材和背景音乐，互不阻塞。
• 把质检 Agent 的结果沉淀为训练数据，持续优化导演 Agent 的分镜生成质量。
• 增加用户反馈回路。视频发布后的完播率、互动数据可以反向输入到选题 Agent，形成“创作 → 发布 → 复盘 → 再创作”的闭环。

多智能体视频创作系统的核心难点不在于让模型“更聪明”，而在于把流程拆得足够清晰，让每个 Agent 使用合适的工具完成确定的任务，并让所有阶段的数据可以追踪、可以回滚、可以评估。MCP 提供了工具接入层的统一标准，编排层则负责把多个 Agent 组织成一条可控制的流水线。从最小 Server 跑通开始，逐步加上角色、质检、版本和观测，是落地这一类系统最稳妥的路线。