AIGC 平台为什么不能只做“模型聚合”：从上下文包、执行图到可观测生产线

以创源AIGC的灵感广场、图像生成、视频生成、多模型对话、无限画布与导演台为例，讨论一个多模态内容平台从“功能可用”走向“生产可复现”时，真正需要补齐的工程能力。

核心观点 接入更多模型只能扩大能力上限。 要让电商素材、短视频、PPT、短剧分镜和音频进入稳定生产，还必须解决上下文版本、任务依赖、模型路由、资产血缘、质量闸门和故障恢复。

很多 AIGC 产品的第一阶段都很相似。

接入几个文本模型，再接入图像、视频和音频模型，然后为每个模型做一个输入框、参数面板和生成按钮。

在演示环境中，这套方案已经足够。

但当用户开始处理真实任务，问题会迅速从“模型能不能生成”变成“整条链路能不能复现”。

同一张商品图为什么第二次生成时结构变了？

同一个角色为什么进入视频后服装发生漂移？

某个视频任务失败后，为什么必须重新生成脚本、分镜和参考图？

这些问题并不完全属于模型能力，而属于平台工程。

图 1：多模型入口解决“能力在哪里”，生产系统还需要解决“任务如何连续运行”

一、先区分“模型聚合”与“生产编排”

模型聚合的核心对象是模型。

它关心模型名称、渠道、参数、价格、并发和响应格式。

生产编排的核心对象则是任务。

它关心任务输入、上下游依赖、版本、状态、输出、质量和恢复路径。

比较项	模型聚合	生产编排
中心对象	模型调用	业务任务
成功标准	接口返回结果	结果通过业务验收
失败处理	重新请求	局部重试、降级、回退
数据保存	最终文件	输入快照、版本、血缘、指标
复用方式	复制提示词	复用模板、节点和工作流

如果平台只保存最终文件，那么每次生成都是一次性行为。

只有保存“这份结果是如何产生的”，才能形成可复用生产线。

二、用“上下文包”代替一段不断膨胀的提示词

多模态项目最常见的错误，是把所有要求都塞进一段长提示词。

角色外观、商品结构、品牌规范、镜头语言、尺寸、禁止项和历史修改混在一起后，很难判断哪条约束真正生效。

更稳妥的做法，是建立版本化上下文包。

{
  "context_id": "ctx_product_video_001",
  "version": 4,
  "project": {
    "name": "夏季新品短视频",
    "target": "生成 3 条 9:16 商品视频"
  },
  "identity": {
    "product_asset_ids": ["asset_front", "asset_side"],
    "must_keep": [
      "商品外形比例",
      "按键数量",
      "接口位置",
      "包装主色"
    ]
  },
  "creative": {
    "scene": "夏日自然光桌面",
    "camera": "中景缓慢推进到细节特写",
    "motion": "商品轻微旋转"
  },
  "constraints": {
    "duration_seconds": 10,
    "ratio": "9:16",
    "negative": [
      "部件漂移",
      "品牌文字变形",
      "镜头瞬移",
      "背景闪烁"
    ]
  }
}

上下文包应当是不可变版本。

用户修改商品约束或视觉风格时，系统创建新版本，而不是覆盖旧数据。

这样才能回答一个关键问题：某份结果究竟对应哪一版需求。

三、灵感广场不只是作品墙，而是模板注册中心

图 2：热门案例可以作为模板入口，但模板内部需要保留结构化变量

从产品体验看，灵感广场解决“不知道从哪里开始”。

从系统设计看，它更接近模板注册中心。

一个高质量模板至少应该包含四部分：

1. 适用任务，例如文生图、图生视频、商品海报或人物分镜；
2. 固定结构，例如镜头、构图、光线和材质语言；
3. 可替换变量，例如主体、场景、品牌色和尺寸；
4. 兼容矩阵，记录哪些模型和参数组合已经验证。

{
  "template_id": "tpl_cinematic_character_07",
  "schema_version": "1.2",
  "task_type": "image_to_video",
  "variables": [
    {"name": "character_asset", "type": "image_asset", "required": true},
    {"name": "environment", "type": "text", "required": true},
    {"name": "duration", "type": "integer", "default": 10}
  ],
  "verified_profiles": [
    {
      "model": "video_model_a",
      "ratio": "9:16",
      "quality_score": 0.87
    }
  ]
}

模板复用的关键不是“一键复制”，而是保证用户替换变量后，结构仍然有效。

四、执行图：把长链路拆成可以单独恢复的节点

以一条短视频生产链为例。

它可能包含选题分析、脚本生成、分镜拆分、角色图生成、视频生成、配音、配乐和质量检查。

如果把这些步骤写成一个长函数，任意一步失败都会让整个任务重新开始。

topic_analysis
      ↓
script_generation
      ↓
storyboard_split
      ↓
character_image ──────┐
      ↓               │
scene_image ──────────┤
      ↓               │
video_generation ◀────┘
      ↓
voice_generation
      ↓
quality_gate
      ↓
publish_assets

每个节点都应当具备独立状态。

PENDING
  → READY
  → RUNNING
  → SUCCEEDED

异常分支：
  → RETRY_WAIT
  → FAILED
  → SKIPPED
  → CANCELED

当视频节点失败时，系统只重跑视频节点。

已经确认的脚本、分镜和参考图继续复用。

这也是无限画布和导演台真正有价值的地方：它们把隐性的任务依赖变成显性的执行图。

五、模型适配器：屏蔽供应商差异，但不要抹平能力差异

不同模型的请求参数和返回格式往往不一致。

平台需要建立适配器层，将底层接口转换为统一协议。

class VideoModelAdapter:
    def submit(self, request: dict) -> str:
        raise NotImplementedError

    def get_status(self, provider_task_id: str) -> dict:
        raise NotImplementedError

    def cancel(self, provider_task_id: str) -> bool:
        raise NotImplementedError

    def normalize_result(self, raw_result: dict) -> dict:
        raise NotImplementedError

统一协议并不意味着所有模型被假设成完全相同。

平台还需要维护能力描述。

{
  "model": "video_model_a",
  "capabilities": {
    "text_to_video": true,
    "image_to_video": true,
    "first_last_frame": false,
    "max_duration_seconds": 15,
    "ratios": ["16:9", "9:16", "1:1"],
    "reference_image_limit": 4
  }
}

路由器只能在满足任务约束的候选模型中进行选择。

六、模型路由不是“最便宜优先”，而是约束过滤后的多目标决策

在生产环境中，模型路由至少包含两步。

第一步是硬约束过滤。

不支持目标比例、参考图数量或时长的模型必须直接排除。

第二步才是候选排序。

def route_score(candidate, task):
    return (
        candidate.quality_score * task.weights.quality
        + candidate.success_rate * task.weights.reliability
        + candidate.latency_score * task.weights.latency
        + candidate.cost_score * task.weights.cost
    )

探索任务可以提高速度和成本权重。

正式交付应提高质量和成功率权重。

同一个模型在不同任务阶段可以得到完全不同的路由优先级。

七、图像和视频页面的历史记录，本质上是实验追踪

图 3：视频历史记录应保存输入快照，而不仅是结果缩略图

图 4：图像版本需要与提示词、参考素材、模型和参数建立一一对应关系

只展示历史缩略图，无法支持工程复现。

一个完整生成记录至少要保存：

generation_runs
- run_id
- project_id
- context_version
- node_id
- model
- channel
- prompt_snapshot
- parameter_snapshot
- input_asset_versions
- provider_task_id
- output_asset_versions
- latency_ms
- retry_count
- quality_score
- error_code
- created_at

这套记录既是用户的版本历史，也是平台的实验数据。

模型路由、模板推荐和质量评估都依赖这些数据。

八、多模型对话的关键不是并发，而是答案契约

图 5：多个模型可以承担不同角色，再由汇总模型生成最终方案

多个模型同时回答，并不自动产生更好的结果。

如果每个模型都输出自由文本，汇总阶段仍然需要重新理解所有答案。

更可靠的方式，是为不同角色定义输出契约。

{
  "role": "risk_reviewer",
  "output_schema": {
    "issues": [
      {
        "severity": "high | medium | low",
        "location": "string",
        "reason": "string",
        "suggestion": "string"
      }
    ],
    "pass": "boolean"
  }
}

汇总模型接收结构化结果后，才能稳定完成冲突消解、优先级排序和最终合并。

九、资产血缘：任何结果都应该能够追溯到上游

多模态生产中，图片会成为视频输入，脚本会成为配音输入，分镜会成为场景图输入。

平台必须建立资产血缘，否则上游变化后无法判断哪些下游结果已经过期。

{
  "asset_id": "video_scene_03_v2",
  "asset_type": "video",
  "derived_from": [
    "storyboard_scene_03_v4",
    "character_image_v7",
    "background_image_v3",
    "voice_track_v2"
  ],
  "generated_by": {
    "node_id": "node_video_scene_03",
    "run_id": "run_8821"
  }
}

当 character_image_v7 被替换为 v8 时，系统可以自动标记依赖它的视频为 stale。

用户再决定是否重新生成，而不是让系统静默使用过期素材。

十、质量闸门：接口成功只是技术成功，不是业务成功

模型返回 200，文件也能下载，并不代表任务完成。

生产系统需要质量闸门。

内容类型	自动检查	人工检查
图像	分辨率、比例、主体检测、重复图	商品结构、文字、审美
视频	时长、黑帧、闪烁、音画完整性	动作连续、角色一致、镜头逻辑
文本	结构、长度、敏感规则、重复度	事实、表达、业务准确性
PPT	页数、文件完整性、元素越界	逻辑、视觉层级、可编辑性

def pass_quality_gate(result):
    if result.technical_score < 0.95:
        return False, "TECHNICAL_CHECK_FAILED"

    if result.consistency_score < 0.80:
        return False, "CONSISTENCY_BELOW_THRESHOLD"

    if result.policy_flags:
        return False, "POLICY_REVIEW_REQUIRED"

    return True, None

十一、可观测性：必须知道慢在哪里、错在哪里、贵在哪里

长链路如果没有可观测性，出现失败时只能依赖用户截图。

每个项目应当有统一 trace_id，每个节点有 span_id。

{
  "trace_id": "trace_project_1024",
  "span_id": "span_video_scene_03",
  "node_id": "node_video_scene_03",
  "model": "video_model_a",
  "channel": "channel_b",
  "queue_wait_ms": 820,
  "provider_latency_ms": 68400,
  "postprocess_ms": 2700,
  "retry_count": 1,
  "result": "succeeded"
}

至少要持续观察以下指标：

• 不同模型和渠道的成功率；
• 队列等待时间与实际生成时间；
• 重试率、超时率和降级率；
• 每种任务的平均质量分；
• 模板复用后的成功率变化；
• 节点级资源消耗与重复生成比例。

十二、故障演练：三个常见异常如何局部恢复

CASE-01：视频渠道超时 保留 provider_task_id，进入延迟轮询。 超过阈值后切换兼容渠道，但复用同一上下文版本和输入资产。

CASE-02：参考图临时地址失效 根据 asset_id 重新签发访问地址。 不重新生成参考图，也不创建新的业务版本。

CASE-03：结果通过技术检查，但一致性不足 标记为 QUALITY_REJECTED。 保留失败结果用于对比，只重跑当前节点并提高一致性约束。

def recovery_action(error_code: str):
    mapping = {
        "PROVIDER_TIMEOUT": "POLL_OR_FAILOVER",
        "ASSET_URL_EXPIRED": "REFRESH_SIGNED_URL",
        "QUALITY_REJECTED": "RETRY_CURRENT_NODE",
        "INVALID_CONTEXT": "STOP_AND_REQUIRE_EDIT"
    }
    return mapping.get(error_code, "MANUAL_REVIEW")

十三、落地案例：从热门模板到一组可追溯短视频

假设运营团队需要为一款新品制作三条短视频。

一个可复现流程可以这样设计：

1. 从灵感广场选择已验证的短视频模板；
2. 创建项目上下文包，锁定商品结构和品牌规范；
3. 多模型并行完成用户分析、脚本和风险检查；
4. 图像节点生成三套静态样片，由人工确认主体一致性；
5. 视频节点引用已确认样片，分别生成三条镜头；
6. 质量闸门检查时长、闪烁、结构和角色一致性；
7. 通过的结果进入资产库，不通过的节点单独重试；
8. 保存工作流快照，下次只替换商品资产和文案变量。

最终交付的不只是三条视频，还包括一套可以重复使用的生成方法。

十四、结论

AIGC 平台从演示走向生产，关键转折点不是再接入一个新模型。

真正重要的是把一次性生成改造成可复现任务。

灵感广场负责提供结构化起点。

多模型对话负责角色分工。

图像和视频页面负责单节点执行。

无限画布与导演台负责表达依赖关系。

上下文包、资产血缘、质量闸门与可观测性，则决定这条生产线能否稳定运行。

当平台能够回答“谁生成了什么、使用了哪版输入、为什么失败、如何恢复、结果是否可用”时，多模型聚合才真正升级为内容生产系统。

实际验证时，建议从一个最小任务开始。 平台当前为新用户保留测试活动，完成注册后可通过私信提交用户 ID 补充 2 积分。 测试时应同时记录输入版本、模型、参数和结果，避免只比较最终画面。