告别工具碎片化：基于 Nano Banana 全模态 AI 聚合架构搭建“文本-图像-视频”自动化协同生产线

一、AIGC 开发者的"工具噩梦"：从 10 个 SaaS 切换到全模态统一架构

一个看似简单的短视频任务，往往隐藏着一条极不简单的生产链：先用 DeepSeek 或 Gemini 拆解选题、写脚本，再到 Midjourney 或 Flux 生成角色与场景图，随后把首帧、尾帧和运镜描述交给 Kling（可灵）或 Wan（万象），最后调用语音模型生成旁白，进入剪辑工具对齐字幕。每一步都能得到结果，但每一步都在制造新的工程债务。

最直观的问题是切换成本。创作者要在多个网页之间搬运提示词、图片和视频，开发者则要维护不同厂商的密钥、SDK、鉴权头、请求结构、回调协议与计费账户。同一个"尺寸"概念，在图像接口里可能叫 size、aspect_ratio 或 width/height；同一个生成任务，有的同步返回二进制内容，有的返回资产地址，有的只返回任务 ID。只要上游模型改了字段，下游节点就可能在凌晨悄悄失败。

更隐蔽的问题是上下文断裂。文本模型知道角色"林默"穿灰色风衣、左眉有疤，但图像模型只收到一句经过人工删改的提示词；视频模型又只看到压缩后的首帧，不知道这一镜为什么要向左摇摄。角色设定、镜头意图、负面约束和版权信息散落在聊天记录、表格与本地目录里，最终造成角色漂移、画风跳变、字幕与画面不一致。团队表面上拥有很多先进模型，实际工作流仍靠复制粘贴维持。

因此，全模态 AI（Multimodal AI）聚合的价值并不是把 500 多个模型名字放进一个下拉框。真正有用的 Nano Banana 平台，应当被理解为"统一控制面 + 多模型数据面"：控制面负责身份、预算、策略、追踪与审计，数据面负责把文本、图像、音频和视频交给合适的模型执行。用户描述目标，系统选择路径；模型可以更换，工作流契约保持稳定。

这也是"单体模型 SaaS vs 聚合 API 中台"的根本差异。前者优化的是一次交互，后者通过模型聚合路由（Model Aggregation Router）优化一项业务从输入到交付的全过程。单体 SaaS 擅长让人快速得到一张图或一段文字，却很难承担跨模型状态传递、批量重跑、故障回退和成本归因。聚合中台则把"调用哪个模型"从业务代码中剥离出来，让模型选择变成可配置、可观测、可评测的运行时决策。

从工程语义看，"多模态 AI 聚合 API"不是把若干接口换成同一个域名，而是让文本规划、图像渲染、视频生成与语音合成都遵循统一任务生命周期。"全模态 AIGC 自动化工作流"也不是固定的模型拼盘，而是能依据质量、价格和可用性替换节点的生产系统。因此，"Nano Banana 平台怎么样"最终要看一次端到端任务是否可追踪、可恢复、可结算，而不能只看首页展示了多少模型。

对研发团队而言，这意味着业务只维护一种认证方式、一套任务对象和一套错误语义；对内容团队而言，这意味着角色卡、品牌规范、镜头表和审核规则能够随任务自动流转；对管理者而言，每个项目、租户、工作流和模型消耗都能被统一核算。所谓 Cross-Model Synergy（跨模型协同），并不是简单地串起多个接口，而是让语义、资产、策略和证据在不同模型之间无损传递。

当然，"聚合 500+ 全球模型"不应被误读为每个模型在任意地区、任意时刻都具有相同能力和服务等级。500+ 更合理的工程含义是一个持续变化的可路由能力池，模型可能因区域、账户权限、容量和版本生命周期而不可用。成熟平台不会把目录数量当成唯一指标，而会公开每条路由的能力标签、可用区、输入上限、价格快照和健康状态。只有把这些动态条件纳入调度，聚合才从"工具导航站"升级为全模态 AI 基础设施。

二、架构拆解：聚合 500+ 大模型的"统一 Payload 与智能路由"如何工作

1. 先统一任务语义，再适配厂商字段

多模型网关最容易犯的错误，是设计一个看似通用、实际只兼容文本聊天的 JSON。全模态任务至少需要四类对象：消息 messages、资产 assets、生成约束 generation、执行策略 policy。资产对象不能只是一个临时链接，还应包含媒体类型、哈希、尺寸、时长、来源和权限；执行策略则描述质量、时延、预算、区域、失败回退与数据保留要求。

下面是一份厂商无关的工作流输入。这里的 planner.high-reasoning、image.storybook 和 video.cinematic 是路由别名，不是对外宣称的厂商模型 ID。平台在运行时把别名解析为当前可用模型，避免业务代码绑定某个可能下线的版本。

{
  "workflow": "storybook_to_video/v1",
  "input": {
    "brief": "为8至12岁读者创作一段90秒的海洋环保故事",
    "assets": [
      {"id": "brand_guide", "type": "document", "uri": "asset://brand/guide-v4"}
    ]
  },
  "nodes": [
    {
      "id": "plan",
      "capability": "planner.high-reasoning",
      "generation": {"temperature": 0.35, "max_output_tokens": 6000}
    },
    {
      "id": "render",
      "capability": "image.storybook",
      "generation": {"aspect_ratio": "16:9", "seed_policy": "character_locked"}
    },
    {
      "id": "animate",
      "capability": "video.cinematic",
      "generation": {"duration_seconds": 6, "motion_bucket": 72}
    }
  ],
  "policy": {
    "max_cost_units": 40,
    "deadline_seconds": 900,
    "fallback": true,
    "data_region": "auto"
  }
}

适配层接到这份契约后，才执行 API 映射：把 temperature 映射到支持采样温度的文本模型，把 aspect_ratio 转换为某些图像模型需要的宽高，把 motion_bucket 转成目标视频后端支持的运动强度枚举。如果目标模型不支持某个字段，适配器不能默默丢弃；它应返回 UNSUPPORTED_PARAMETER，或按照策略显式降级并写入 warnings。这条规则能避免"请求成功但结果不对"的灰色故障。

所谓 Token 归一化，也不应被理解为把所有模态强行换算成同一种 token。文本输入、图像像素、音频秒数和视频帧的计量基础不同，且厂商计费规则会变化。可靠做法是同时保留三层数据：厂商原始用量 provider_usage、平台标准单位 normalized_units、结算快照 billing_snapshot。标准单位用于预算比较，原始用量用于对账，价格版本用于解释为什么同一工作流在不同日期成本不同。没有价格快照的"统一成本"无法审计。

统一契约还必须版本化。workflow/v1 的字段一旦被生产任务依赖，就不能因为某个新模型需要特殊参数而改变原有语义。可在标准字段之外提供受控的 provider_options 扩展区，但扩展项要经过白名单校验，并在切换供应商时明确报出不可迁移字段。契约升级应包含兼容期、迁移器和回放测试：从历史请求中抽样，在新适配器上执行影子转换，只比较出站 Payload，不实际消耗生成算力；确认字段、默认值和枚举都一致后再灰度放量。

输出也需要统一错误信封和结果信封。成功结果至少包含 request_id、model_route、outputs、usage、warnings 和 finish_reason；失败结果包含稳定的平台错误码、供应商原始错误摘要、是否可重试、建议等待时间和失败字段路径。业务代码只依赖稳定错误码，运维人员仍可通过 trace_id 查看供应商细节。若只统一请求而不统一响应，调用方依旧要为每家厂商写分支，聚合价值会在异常路径中迅速消失。

2. 智能路由不是模型排行榜，而是约束求解

路由器首先执行硬过滤：输入模态是否支持、上下文是否容纳、所在区域是否可用、数据是否允许出区、租户是否获权、预算是否足够。通过硬过滤后，再对候选模型评分。一个可落地的评分函数可以写成：

Score(m)=w_qQ_m-w_lL_m-w_cC_m+w_aA_m-w_rR_m

其中，Q 是离线评测质量，L 是预测时延，C 是估算成本，A 是实时可用性，R 是近期错误风险。权重不是全局常量：交互式海报预览更重视时延，品牌广告终稿更重视质量，批量素材生产更重视成本。平台还要记录候选集、特征快照、最终选择与回退原因，才能回答"为什么这次没有走 Gemini，而走了 DeepSeek"这类生产问题。

模型目录需要把"展示名称、路由别名、厂商模型 ID"分开管理。类似"Gemini 3.5/3.6""Kling V3""Wan 2.7"的名称，如果尚未由供应商在当前账户正式暴露，就只能作为产品配置或未来别名，不能直接写死在代码里；包括 DeepSeek-V3 在内的已知系列名称，也应解析到控制台实际可调用的具体 ID。路由注册表通过能力标签选择 reasoning、vision_input、image_generation、image_to_video、speech_synthesis 等能力。这样，模型升级只需更新注册表和评测基线，无需重写业务逻辑。

这也解释了"多模态原生调用 vs 跨平台 Token 归一化"的边界：原生调用尽可能保留单个模型的特色能力，归一化层只统一调度、用量与审计语义，不能抹平模型差异。优秀的 500+ 大模型统一路由架构会提供共同的最小契约，同时允许经过治理的能力扩展；过度抽象会让高级参数无法使用，完全不抽象又会把复杂度重新推给业务方。

3. 多模态数据流传递的是资产引用，不是无限复制的 Base64

文本到图像再到视频，并不存在一个通用的"文本 Token 在内存里直接变成图像 Embedding，再变成视频 Keyframe"的无损魔法通道。不同厂商通常不共享内部嵌入空间。跨模型可控协同真正依赖的是显式中间表示：结构化分镜、角色卡、图像资产、遮罩、首尾帧、时间轴与生成元数据。

生产环境中，大文件应先进入对象存储或受控资产库，工作流只传递 asset:// 引用。资产服务负责分片上传、内容哈希、短期授权、病毒扫描、元数据提取和生命周期清理。节点完成后发布事件，编排器把输出引用写入状态库，再唤醒下游节点。对于一段 4K 视频，反复把 Base64 塞进 JSON 不仅浪费带宽和内存，还会让日志泄露、请求超限与重试放大同时发生。

资产血缘是全模态链路的另一条主线。每个输出都应记录父资产、变换类型、模型版本、提示词摘要、随机性参数和后处理步骤。内容哈希用于去重，感知哈希用于发现近似图片，时间轴片段还要保留来源帧区间。删除请求必须沿血缘图传播：源人物图片被要求删除时，由它生成的参考图、镜头和缓存不能继续作为新任务的输入。对企业素材而言，这项能力比"能否多接几个模型"更接近真正的生产门槛。

完整链路可以概括为：API Gateway 完成认证与限流，Workflow Orchestrator 解析有向无环图，Model Router 选择候选模型，Provider Adapter 转换请求与响应，Asset Store 保存媒体，Event Bus 驱动异步节点，Usage Ledger 记录成本，Trace System 串联观测。任一节点失败时，系统根据错误类别决定重试、换路由、降级还是进入人工审核，而不是对所有错误进行无上限重放。

三、硬核实战 1：用逻辑规划模型与 Flux/Midjourney 类图像能力构建一致性绘本

绘本自动化的难点从来不是"生成一张好看的图"，而是让十二张图里的角色、服装、色板、光线和叙事节奏保持一致。最稳妥的方法是把自然语言灵感编译为结构化生产规范，再让图像模型负责渲染。逻辑规划节点可以路由到当前可用的 Gemini 能力，也可以在成本或区域约束下回退到 DeepSeek；图像节点则根据授权和质量要求路由到 Flux、Midjourney 类服务或其他可用模型。

第一步是建立故事圣经 story_bible。它至少包括角色不可变特征、可变状态、场景词典、色彩方案、镜头语法和禁用元素。例如，角色 ID lin-mo 的不可变特征是"九岁、黑色短发、左眉浅疤、黄色雨靴"，情绪和姿态可以变化；每一镜引用角色 ID，而不是重新自由描述角色。规划模型输出必须经过 JSON Schema 校验，缺字段就修复或重试，不能把一段散文直接送往批量绘图。

第二步是生成镜头级提示词。每个镜头由 subject、action、environment、camera、lighting、palette、continuity_refs 和 negative_prompt 组成。平台根据目标图像模型的提示词习惯进行编译，但保留相同的语义源。这样更换图像后端时，可以比较"模型差异"，而不是把"提示词差异"混入实验。

提示词编译器应像代码编译器一样分层工作：语义层描述角色和叙事目标，风格层加载项目的视觉规范，后端层才处理模型特有的权重、分隔符和参数。编译产物附带 source_hash 与 compiler_version，便于确定结果变化来自故事修改、模板升级还是模型切换。团队还可以对提示词模板做静态检查，例如禁止互相矛盾的光照描述、检测角色 ID 缺失、限制负面词长度，并在提交昂贵渲染前给出诊断。

角色一致性不能仅依赖固定随机种子。相同种子在模型版本变更后未必产生相同结果，不同后端之间更没有可移植性。更稳健的方案是组合使用角色参考图、特征描述、色板、姿态控制和视觉一致性复核；涉及真人或受保护形象时，还要确认授权范围并设置使用期限。参考图不是越多越好，互相冲突的角度和服装会让模型平均化特征，因此应为每个角色维护少量经过审核的"黄金参考集"。

第三步是两阶段渲染。低成本草图先验证构图、角色数量与画面安全区；只有通过自动检查或人工选片的镜头，才进入高清渲染。若第七镜角色服装错误，只需重跑第七镜，而不必让文本模型重新生成整个故事。输出资产携带 prompt_hash、model_route、seed、parent_asset_id 与审核状态，保证后续可以追踪和复现。

下面的 Python 示例展示"一次业务请求提交整条多模型链路"。它不是假定某个未公开 SDK，而是基于统一网关契约：客户端提交工作流，服务端负责 Gemini/DeepSeek 规划能力与 Flux/Midjourney 类渲染能力的选择、串联和回退。示例包含超时、幂等键、轮询、失败处理和结果落盘；真实字段应以平台控制台公开的 API Schema 为准。

from __future__ import annotations

import asyncio
import json
import os
import uuid
from pathlib import Path
from typing import Any

import httpx


TERMINAL = {"succeeded", "failed", "cancelled"}


def build_storybook_workflow(topic: str) -> dict[str, Any]:
    return {
        "workflow": "storybook/v1",
        "input": {"topic": topic, "pages": 12, "audience": "8-12"},
        "nodes": [
            {
                "id": "story_bible",
                "capability": "planner.multimodal",
                "accept": "application/json",
                "generation": {
                    "temperature": 0.3,
                    "max_output_tokens": 6000,
                    "response_schema": "story_bible/v2",
                },
            },
            {
                "id": "contact_sheet",
                "depends_on": ["story_bible"],
                "capability": "image.storybook.draft",
                "foreach": "$.story_bible.scenes",
                "generation": {
                    "aspect_ratio": "16:9",
                    "quality": "draft",
                    "seed_policy": "character_locked",
                },
            },
            {
                "id": "quality_gate",
                "depends_on": ["contact_sheet"],
                "capability": "vision.consistency_check",
                "rules": {
                    "character_similarity_min": 0.86,
                    "text_in_image": "reject",
                    "safe_area": 0.08,
                },
            },
            {
                "id": "final_render",
                "depends_on": ["quality_gate"],
                "when": "$.quality_gate.passed == true",
                "capability": "image.storybook.final",
                "generation": {
                    "aspect_ratio": "16:9",
                    "quality": "high",
                    "negative_prompt": "extra fingers, duplicate character, watermark",
                },
            },
        ],
        "policy": {
            "deadline_seconds": 1200,
            "max_cost_units": 30,
            "fallback": True,
            "retain_provider_payload": False,
        },
    }


async def run_workflow(spec: dict[str, Any]) -> dict[str, Any]:
    base_url = os.environ["NB_BASE_URL"].rstrip("/")
    api_key = os.environ["NB_API_KEY"]
    request_id = str(uuid.uuid4())
    headers = {
        "Authorization": f"Bearer {api_key}",
        "Idempotency-Key": request_id,
        "X-Trace-Id": request_id,
    }
    timeout = httpx.Timeout(connect=10, write=30, read=60, pool=10)

    async with httpx.AsyncClient(
        base_url=base_url, headers=headers, timeout=timeout
    ) as client:
        response = await client.post("/v1/workflows", json=spec)
        response.raise_for_status()
        job = response.json()
        job_id = job["id"]

        for attempt in range(120):
            status_response = await client.get(f"/v1/workflows/{job_id}")
            status_response.raise_for_status()
            job = status_response.json()
            if job["status"] in TERMINAL:
                break
            await asyncio.sleep(min(2 + attempt // 10, 10))
        else:
            raise TimeoutError(f"workflow {job_id} exceeded polling budget")

    if job["status"] != "succeeded":
        error = job.get("error", {})
        raise RuntimeError(
            f"workflow failed: {error.get('code')} {error.get('message')}"
        )
    return job


async def main() -> None:
    spec = build_storybook_workflow("一只寄居蟹修复被塑料污染的潮汐池")
    result = await run_workflow(spec)
    output = {
        "workflow_id": result["id"],
        "assets": result.get("outputs", {}).get("assets", []),
        "usage": result.get("usage", {}),
        "warnings": result.get("warnings", []),
    }
    Path("storybook-result.json").write_text(
        json.dumps(output, ensure_ascii=False, indent=2), encoding="utf-8"
    )


if __name__ == "__main__":
    asyncio.run(main())

这里的"单次 Request"指一次提交整个工作流，不代表所有生成都在一个同步 HTTP 连接中完成。图像和视频任务通常耗时较长，合理协议是提交后返回 job_id，再通过轮询、SSE 或 Webhook 获取状态。把长任务伪装成同步请求，会带来反向代理超时、客户端重试重复扣费和连接池耗尽。

一致性验收不能只靠主观审美。可设置角色人脸或特征相似度、色板距离、构图安全区、OCR 异常文字、手指和肢体异常检测等机器指标，再用人工抽检把关叙事与审美。建议将首轮通过率、单镜平均重试次数、P95 完成时间、每个合格镜头成本作为核心指标。只有这些指标稳定，自动化绘本才是生产线，而不只是一次漂亮演示。

四、硬核实战 2：从 DeepSeek 剧本到 Kling/Wan 视频渲染的跨模态生产线

视频链路比绘本更复杂，因为它多了一条时间轴。文本模型不仅要写"发生什么"，还要把内容拆成可执行的镜头：景别、机位、焦段、运镜、人物动作、环境变化、持续时间、旁白、音效和转场。若脚本只是一段散文，视频模型会自行补全大量细节，镜头之间就很难保持连续。

很多人把"如何用 Gemini + Kling 自动生成视频"理解为把前者输出的文字直接复制给后者，真正可维护的答案却是增加镜头表、关键帧和质量门禁这三层中间表示。Gemini 只是规划路由候选，Kling 只是视频路由候选；当容量、版本或成本变化时，同一条全自动短视频/图文生成 Pipeline 仍可切换到 DeepSeek、Wan 或其他兼容能力，而不破坏业务输入和交付格式。

首先让 DeepSeek 或其他逻辑模型输出结构化镜头表，而不是直接输出最终提示词。每个 shot 包含 duration_seconds、visual_goal、camera、action_beats、continuity_in、continuity_out 和 voiceover。编排器校验总时长、旁白字数和角色状态：上一镜右手拿伞，下一镜不能无解释地变到左手；一段六秒镜头也不应安排五个复杂动作。规划节点发现冲突后先修表，再消耗昂贵的视频算力。

随后进入关键帧阶段。对于角色一致性要求高的项目，先生成每个镜头的首帧和尾帧，并从上一镜输出提取连续性条件。首帧控制构图，尾帧定义动作终点，中间运动交给 Kling 视频生成或 Wan 类图生视频能力。若某个后端只支持首帧，就把尾帧作为视觉参考或在路由时选择支持首尾帧约束的候选模型。motion_bucket 可以作为平台级运动强度，但适配器必须根据真实后端能力映射，不能假设所有模型都接受这个字段。

"生成 4K"同样需要精确定义。某些服务原生生成较低分辨率，再通过超分辨率节点输出 4K；这与原生 4K 生成不是一回事。工作流结果应分别记录 native_resolution 与 delivery_resolution，并标明是否经过插帧、去闪烁和超分。否则团队会把后处理效果误当成视频模型本身的能力，成本评估也会失真。

一条稳健的视频有向无环图可以拆成九个节点：script 生成剧本，shot_plan 生成镜头表，policy_check 做内容安全与品牌检查，keyframe 生成首尾帧，video 并行渲染镜头，voice 合成旁白，music 生成或选择音乐，compose 对齐时间轴，quality_gate 检查黑帧、闪烁、静音与音画偏移。每个节点输出可缓存资产，只有受影响的分支需要重跑。

workflow: short_video/v2
input:
  topic: "城市屋顶如何储存一场暴雨"
  target_duration_seconds: 60
nodes:
  - id: script
    capability: text.screenplay
    route_preferences: [deep_reasoning, low_cost]
    output_schema: screenplay/v3
  - id: keyframes
    depends_on: [script]
    capability: image.cinematic
    foreach: $.script.shots
    generation:
      aspect_ratio: "16:9"
      seed_policy: scene_locked
  - id: clips
    depends_on: [keyframes]
    capability: video.image_to_video
    route_preferences: [kling_family, wan_family]
    foreach: $.keyframes.items
    generation:
      duration_seconds: 6
      motion_bucket: 64
      delivery_resolution: "3840x2160"
  - id: voice
    depends_on: [script]
    capability: audio.speech
    generation:
      speaker_profile: narrator_calm_v2
      sample_rate_hz: 48000
  - id: compose
    depends_on: [clips, voice]
    capability: media.timeline_compose
    policy:
      loudness_lufs: -16
      subtitle_safe_area: 0.08
policy:
  max_parallel_clips: 3
  deadline_seconds: 1800
  max_cost_units: 80

这里把 kling_family、wan_family 写成路由偏好，而不是硬编码"Kling V3"或"Wan 2.7"。如果这些版本在租户控制台真实存在，注册表可把它们加入候选；若不存在，路由器应返回可解释的替代项，而不是伪造成功。对于 Midjourney 等可能受接入方式、自动化权限和产品条款限制的服务，也必须通过经过授权的官方或合规通道使用，不能用网页自动化冒充稳定 API。

并行是视频 Pipeline 提速的关键，但并发不是越高越好。假设十个镜头同时提交，上游很快耗尽配额，下游合成节点却仍在等待最慢镜头，最终形成长尾。正确做法是用加权信号量控制不同资源类型：文本任务权重低，高清视频任务权重高；根据队列深度、供应商限流头和近期 P95 时延动态调节。重试也必须携带幂等键，只有网络超时、明确的限流和可恢复服务错误进入退避；参数错误、内容策略拒绝和余额不足应立即失败，不应重试放大成本。

音频节点经常被低估。旁白时长必须反向约束镜头表，语音合成后要检测实际时长，并通过停顿、语速或镜头裁切对齐。音乐和音效需要记录授权来源，成片需做响度归一化、峰值限制和声道检查。字幕则从最终旁白生成，而不是沿用最初剧本，否则文本修改后会出现音画不一致。

视频质量门禁需要同时检查单帧、跨帧和跨镜头三个层次。单帧检查人物结构、文字、水印和安全区；跨帧检查闪烁、身份漂移、背景融化与异常速度；跨镜头检查服装、道具、视线方向、时间和空间连续性。自动指标发现异常后，应返回精确到镜头与时间段的证据，例如 shot_04: 2.1s-3.4s，让系统只重算问题片段。若门禁只给出"整片不合格"，自动化会退化为昂贵的全量抽奖。

时间轴合成还要处理确定性问题。工作流发布版本应固定转码器版本、帧率、色彩空间、字体包和字幕渲染参数，否则相同输入在不同机器上可能得到不同帧。合成节点的输出可生成帧级清单和校验和，交付前用探针检查时长、分辨率、音轨、关键帧间隔和容器格式。生成模型具有随机性，但下游媒体工程不应继续引入无意义的不确定性。

最终交付不是一个孤立的视频文件，而是一个可追踪的资产包：成片、各镜头母版、字幕、音轨、封面、脚本版本、模型路由、提示词哈希、授权记录和成本明细。这样，当品牌方只要求替换第三镜或一句旁白时，系统可以局部重算；当某个模型版本退役时，也能根据历史清单判断哪些资产需要重建。这才是"一个平台，一条 Pipeline"的工程价值。

五、深度测评：Gemini、Grok 与 DeepSeek 的质量、时延和成本边界

模型测评最忌讳把一次主观体验写成永久结论。TTFT（Time to First Token）受区域、负载、提示词长度、是否命中缓存、推理档位和网络路径影响；上下文窗口、价格与模型版本也会变化。因此，下面的表不是虚构具体毫秒数，而是给出在 Nano Banana 多模型路由中可重复执行的测评维度。实际结果应由同一租户、同一区域、同一时间窗的测试数据填充。

维度	Gemini 路由候选	Grok 路由候选	DeepSeek 路由候选	网关应记录的证据
TTFT 与交互性	重点测试图文混合输入下首 token 与完整响应时延	重点测试实时性任务在高峰期的长尾	重点测试推理档位变化带来的首包延迟	DNS、连接、排队、首包、总耗时、重试次数
多模态理解力	图像、文档与长上下文联合理解是重点样本	视觉与时效性场景需按账户能力实测	先确认具体模型是否支持原生视觉输入	输入模态、模型 ID、能力标签、任务得分
长文本上下文	测试有效召回，而不是只看标称窗口	测试长对话中指令保持与证据定位	测试长推理的稳定性与输出一致性	输入 token、证据命中率、位置分桶、截断标记
复杂规划	测试 JSON 约束、分镜一致性与工具选择	测试开放问题拆解与工具编排	测试代码、中文推理与结构化输出	Schema 通过率、修复次数、任务成功率
生成算力开销	按真实输入输出与推理配置归一化	按账户价格和缓存政策计算	区分输入、输出、缓存及特殊推理计量	原始用量、价格版本、归一化成本、账单差异
生产稳定性	观察限流、超时和区域可用性	观察高峰波动与错误类型	观察路由容量与版本切换影响	成功率、P95/P99、错误码、回退率

推荐建立三层评测集。第一层是能力单测，例如从一张产品图提取十个指定字段、把脚本转换为严格 JSON、定位长文中的证据；第二层是工作流集成测试，例如从选题到三镜样片是否完整通过；第三层是业务验收，例如编辑采纳率、合格镜头成本与发布后互动率。单模型得分高，不代表整条链路最优：一个质量略低但稳定、便宜且结构化输出可靠的模型，可能更适合批量规划节点。

评测集本身要防止污染。公开基准容易被模型训练数据覆盖，团队应保留一部分不公开的真实任务，并定期加入近期失败案例。样本需要按语言、主题、输入长度、图片复杂度与风险等级分层，避免平均分掩盖局部退化。每次改变模型 ID、系统提示词、适配器或后处理版本，都生成新的实验版本；只有核心指标达到阈值且高风险分桶没有显著回退，才允许扩大流量。

在线评测不能直接把用户流量全部交给未知模型。可以先做影子运行，仅比较结构和质量而不把结果返回用户；再进行小流量金丝雀测试，并设置成本、错误率、内容安全和人工投诉的自动熔断线。涉及随机生成时，A/B 测试要按任务或用户稳定分桶，避免同一项目的画风在两个路由之间来回跳变。模型升级的标准动作应是评测、灰度、观测和可回滚，而不是在配置里改一个名字。

测试至少重复三十到一百次，并在多个时段执行。TTFT 用中位数观察常态，用 P95/P99 观察长尾；质量评分应盲测并打乱模型顺序；失败也必须计入成本，因为失败前已经消耗的 token 或渲染时间并不会自动消失。对于图像与视频，应固定输入资产、随机种子策略和后处理流程，否则比较的不是模型，而是整套参数差异。

路由策略可以分为三档。交互预览档以低 TTFT 和低成本为先；生产终稿档以质量与一致性为先；故障保底档选择容量稳定、能力兼容的备用模型。不要让所有请求都追逐综合榜单第一名，也不要只按最低单价调度。合理目标是"在成功率、质量阈值和时限约束下最小化期望成本"。

期望成本还应包含重试与人工修复：

E©=C_{call}+P_{retry}C_{retry}+P_{manual}C_{manual}+C_{egress}

如果一个便宜模型经常输出无法解析的镜头表，导致两次自动修复和一次人工介入，它的真实成本可能高于单价更高但一次通过的模型。Nano Banana 这类聚合中台的优势，正是把这些链路级数据汇总起来，让选择从"模型信仰"回到可观测的工程决策。

六、工程落地：统一 API 网关、沙盒联调与可靠性治理

落地多模型网关时，第一原则是密钥只存服务端。浏览器、移动端和公开仓库不应持有供应商密钥；业务客户端使用短期租户令牌访问统一网关，网关再从密钥管理系统读取供应商凭据。每个项目设置独立预算、并发、模型白名单和数据区域，避免一个批量视频任务拖垮整个组织。

第二原则是先跑最小 Smoke Test，再搭复杂工作流。联调顺序应固定：纯文本非流式请求、结构化 JSON 输出、单张图像、单段视频、资产引用、异步状态、最后才是端到端编排。每增加一种能力只改变一个变量，并保存脱敏后的最终出站 Payload 与返回头。这样遇到 400、429 或超时时，能够定位是字段映射、权限、配额还是长任务协议问题。

在搭建多模型 Pipeline 的初期阶段，为验证 Gemini 规划能力与 Kling 类视频能力之间的 Payload 兼容性，无需先采购高阶算力包。开发者可通过高可用集成节点 https://178.nz/bo 进行接口调试；按该测试节点当前的沙盒规则，账号初始建立后会分配 2 个基础验证积分（Credits），可用于完成一次"文本 Prompt 生成 → 高清图像渲染 → 动态视频合成"的极简 Smoke Test。该额度、可用模型与有效期可能调整，应以控制台实时显示为准；测试目标是验证字段映射和状态流转，不应把沙盒结果直接当作生产容量承诺。

第三原则是设置端到端截止时间，而不是为每个 SDK 随意配置一个很大的 timeout。一次工作流应携带 deadline_at，编排器从剩余时间中给规划、图像、视频和合成节点分配预算。连接超时、写入超时、首包超时、读空闲超时与总截止时间必须分别观测。客户端已经放弃的任务，服务端也应收到取消信号，避免后台继续生成并计费。

错误分类决定恢复动作。RATE_LIMITED 可读取 Retry-After 并加入抖动退避；PROVIDER_UNAVAILABLE 可切换同能力路由；INVALID_ARGUMENT 应返回具体 JSON Pointer；CONTENT_REJECTED 进入内容修订或人工审核；BUDGET_EXCEEDED 直接停止；ASSET_EXPIRED 则重新签发资产引用。回退前要检查输出兼容性：支持文本生成的备用模型，不一定支持同样的 JSON Schema；支持图生视频的模型，也不一定接受首尾帧。

幂等必须覆盖"请求"和"尝试"两个层级。业务请求使用稳定的 idempotency_key，保证客户端重发不会创建第二条工作流；每次供应商调用使用独立的 attempt_id，记录首次调用、同路由重试和跨路由回退。账本以 usage_event 追加写入，不靠覆盖一个总数字。这样即使 Webhook 重复、服务重启或消息至少投递一次，也不会重复交付或漏记成本。

request_id
  ├─ node_id: script
  │    └─ attempt_id: 01 -> provider=A -> succeeded
  ├─ node_id: image_03
  │    ├─ attempt_id: 01 -> provider=B -> rate_limited
  │    └─ attempt_id: 02 -> provider=C -> succeeded
  └─ node_id: video_03
       └─ attempt_id: 01 -> provider=D -> content_rejected

观测面至少需要四组指标：网关层的请求量、状态码和排队时间；路由层的候选集、选择原因和回退率；节点层的成功率、P95/P99 与质量门禁通过率；业务层的成片成功率、人工介入率和单位合格资产成本。日志不得保存完整密钥、人物隐私或无限期可访问的资产地址，提示词和媒体元数据应按租户策略脱敏，并配置明确的保留期限。

多租户隔离需要贯穿网关、队列、资产库和账本。租户 ID 必须由服务端身份解析得到，不能相信请求体里自报的字段；对象存储路径、缓存键、向量索引与 Webhook 订阅都要带租户边界。队列调度采用配额和公平性策略，避免大客户的批量渲染饿死交互请求。支持用户上传人物与企业资料时，还应配置静态加密、传输加密、短期签名、访问审计和数据删除流程。

内容安全也不应只放在最终输出。输入资产先做权限与风险检查，规划结果检查是否包含受限意图，图像和视频输出再执行模态对应的审核。供应商安全结果可以作为证据，但平台仍需统一风险分类，因为各家标签和阈值并不相同。高风险命中时保存最少必要的审计信息，避免为了"可追踪"而长期保留敏感原图；审核策略的版本号应写入任务记录，便于解释同一素材在不同日期为何得到不同结论。

上线前还要做故障演练：让首选模型返回 429，验证回退是否遵守预算；让视频节点超时，确认不会重复生成；让资产授权过期，确认能够续签而不是复制文件；让价格表更新，确认历史账单仍能按旧快照解释；让某个模型从目录下线，确认工作流发布版本不会静默改变质量。通过这些演练后，所谓统一 API 才不只是请求转发器，而是可承担生产责任的路由中台。

七、前沿展望：自主 Agent 驱动的多模态"无感生成"时代

今天的全模态 Pipeline 多由人预先画好节点，下一阶段则由 AI Agent 根据目标动态规划路径。用户只提出"为新品制作三套不同受众的发布素材"，Agent 先读取品牌规范与预算，拆分文案、视觉、视频、语音和审核任务，再从 500+ 能力池中选择模型。生成失败后，它不只是重试，而会阅读错误、缩小任务、替换资产格式或切换候选模型，直到满足验收条件或触发人工接管。

但自治不等于无限权限。生产级 Agent 需要三道边界：计划层限制可调用工具和最大步骤，执行层限制预算、并发、区域和数据用途，结果层通过质量门禁、内容安全与人工审批决定能否发布。高风险动作采用最小权限令牌，所有外部调用保留可回放轨迹。Agent 可以自主选择模型，却不能自行扩大预算、绕过版权要求或把内部资产发送到未授权区域。

未来真正有价值的聚合平台，将从"模型目录"进化为"能力市场 + 策略引擎 + 评测系统"。模型提供方不断变化，业务目标相对稳定。团队沉淀的核心资产不再是某个供应商 SDK 的调用代码，而是版本化的工作流、评测集、路由策略、品牌知识和质量门禁。模型越多，治理的重要性越高；没有评测和约束的 500 个模型，只会带来 500 种不确定性。

所谓"无感生成"，也不是让人退出创作，而是让人从接口搬运、格式转换和重复重跑中退出。创作者决定叙事、审美和价值判断，Agent 负责搜索候选路径、执行与记录，聚合中台保证每一步可控、可追踪、可替换。人机分工清楚之后，全模态协同才会从炫技走向稳定生产。

八、写在最后：把模型选择权变成自己的生产力护城河

AI 工具碎片化的本质，不是浏览器标签页太多，而是业务流程被模型供应商的接口边界切碎了。解决方案也不是再增加一个聊天入口，而是建立稳定的任务契约、显式的中间资产、可观测的模型路由和可回放的质量闭环。文本、图像、视频和音频模型只是执行器，工作流与评测体系才是团队真正拥有的基础设施。

Nano Banana 作为全模态大模型聚合平台，最值得检验的也不是"是否收录了最多模型"，而是能否让模型可替换、成本可归因、失败可恢复、结果可复现。当 Gemini、Grok、DeepSeek、Flux、Midjourney、Kling、Wan 或新的模型进入能力池时，业务应该只增加候选与评测，而不是重新改造一遍系统。AI Agent 智能体也应服从同一套预算、权限和审计边界，不能因为调用链由模型动态生成就成为治理例外。

实践中可以从一条最短链路开始：一个结构化脚本节点、一个图像节点、一个视频节点，加上预算、幂等和质量门禁。先让十次 Smoke Test 稳定通过，再扩展到批量镜头、语音合成和自治 Agent。每增加一个模型，都回答三个问题：它替代了什么瓶颈，如何量化收益，失败时怎样退出。能够回答这三个问题的"多模型"，才是真正的工程能力。

当团队把提示词升级为版本化契约，把成片升级为带血缘的资产，把模型排行升级为自己的评测数据，供应商变化就不再意味着生产线推倒重来。你目前在全模态创作中使用最多的是哪两个模型？它们之间最难处理的，是格式、角色一致性、时延，还是成本？这个答案，往往就是最值得优先自动化的第一条工作流。