五层 AI 生产蓝图

2026-10-03。对 blueprint-review-full.md 的完整修订。本文是目标设计与分期实施依据，不是已上线清单。只读核对本机仓库与运维记录；未在本轮提交收费生成、修改服务或验证所有线上 API。实施前按文末 P0 核对现场和接口。

后续迭代定位（用户 2026-10-03 补充）：用户认可当前落盘材料与框图形式，业务细节将由用户逐项校正；本文的业务规则和组件边界仍是讨论基线。总体范围将扩展到业务架构、技术架构、路线图及与 KDW 并列的本地 Agent 入口，并派生投资人/合伙人 BP 和技术合作说明。入口与交接见 总体规划工作台，确认情况见 决策记录，实现依据见 研究索引。

目标是让 3 人团队从 KDW 的剧本、资产、分镜出发，批量生成候选，逐镜采用，合成带字幕的整集，再按渠道发布；支持夜间串行或受控并发运行、失败后恢复、可审计费用。保留 KDW、MediaFlow、MediaSync、酷视频、酷剧场各自已有的数据和产品边界，通过增量接口集成。

原 v2 的五层方向可保留，但有六项会直接误导实施：

1. 生成网关不能再造一套 KDW 任务/采用状态。 KDW 已有稳定任务 ID、输入快照、调用记录、候选采用及“结果未知禁止自动重试”规则；新服务只持有执行状态、供应商映射和投递账本。KDW 仍是业务状态主本。
2. “MVP 先只接 API、算力节点以后再说”不符合已表达的目标。 用户规划的主扩容路径是自有 GPU 首机验证、再用优云智算 API 启停多节点跑 H3。MVP 可以用现成 API 验证契约，但调度器从第一版即保留节点适配接口；云节点作为下一验收里程碑，不作为模糊远期愿景。
3. “MediaFlow + ZFS 一份物理文件，两个视频站只写一条发布记录”不是现状，也不能当通用保证。 截至当前注册表，MediaFlow 正式媒体在 share/mediaflow-data；酷视频和酷剧场使用另一共享媒体区，各有数据库与索引。跨存储/站点发布可能需要一次受控复制、硬链接或转码衍生物。目标是每种原始交付版本有一个明确主本，副本和衍生版有账可查。
4. MediaSync 不能直接当通用生成结果网关。 目前 /api/mediaflow 针对 LibTV 本地归档项目，MF_FIELDS 仍为 libtv.*；其 M3.5 双向画布合并有测试记录但标为待验收，M2.5 文档与源码口径存在差异。不能把 POST /api/mediaflow {project,assets} 当已存在接口，也不能把“字段改名 10 分钟”当迁移计划。
5. “MediaFlow 审批回调 → KDW”尚无已核实的通用审批事件契约。 MediaFlow 有元数据、评论、版本栈能力；能否承载与 KDW 一致的逐镜正式采用、审片事件、服务账号权限须实测。暂由 KDW 控制采用/定稿，MediaFlow 存候选、预览、评论和版本文件；回流用增量对账适配器，事件接口验收后再增回调。
6. 字幕和合成不是一个 subtitles 滤镜。 阿语对白、说话人、时间轴、译审、音轨、镜头边界和权利校验都有来源与人工闸口；自动识别/翻译不能默认成为对外成片字幕。

1.1 已核对的现有能力与限制

上表中的跨仓相对链接供本机阅读；若目录迁移，以各仓 AGENTS.md 和服务注册表定位。2026-10-03 本轮只读现场已核 pct status 140/142、qm status 101、CT140/142 的 systemd 状态和 PVE2 zfs list/get。share/mediaflow-data 现场 quota=none、available≈20.9T，与当前未提交注册表写的“16T 可用”口径不一致，不能据注册表数字做容量承诺；VM 内 NFS 挂载和容器路径仍待验。 2026-09-28 恢复手册 是历史快照，不能覆盖 10-03 的存储变更。

五层系统关系见前面的「图 1」。各层的数据主本、回流方向和已有系统的接入位置均已标在图中。

接口传递稳定 ID 和不可变版本，不通过文件名、剧名或“最新版本”推断身份。KDW、调度服务、MediaFlow 各保有自己的状态；用映射表与周期对账连接，不双向覆盖。核心关系：project_id、episode_id、shot_id、entity_id、source_revision_id、job_id、item_id、attempt_id、provider_task_id、mediaflow_asset_id、mediaflow_version_id、delivery_id。分镜展示号如 E01-S02-003 可变，稳定 ID 不变。

2.1 五层职责

三处主本之间用 outbox/inbox + 定期对账：业务提交后先持久化 KDW 事件，再发调度；调度完成先提交自身结果和媒体映射，再通知 KDW；回调仅作提速信号，KDW 可按游标拉取缺失事件。双边均保存对方 ID、版本与最后对账时间。

3.1 工单粒度

batch 是用户批准的收费范围与进度聚合；item 是单镜/单图可独立恢复的工作；attempt 是一次实际远端提交。每个 item 冻结：对象 ID、源修订、提示词、参考具体版本 ID、模型/工作流/步数/画幅/时长、输出规格、用户授权与费用上限。改变任何内容须产生新 item 或新 revision，不复用同一幂等键。

首期推荐一个持久执行服务：FastAPI + SQLite WAL（独立 SSD 卷、本机单写进程）或现有 db-1 PostgreSQL 的独立 schema。选型闸口：若只一台执行服务、有限并发、夜间批量，SQLite 足够；若多实例调度、高写并发或需要跨主机故障接管，直接用 PostgreSQL。即使使用 PostgreSQL，暂不需要 Redis/Celery。asyncio 只是并发机制，不是任务可靠性来源；重启后从数据库恢复定时扫描。容量按实测 API 配额和 GPU 工作流决定，不能把“120 镜”当作同时运行 120 条 H3。

状态至少为：draft → awaiting_authorization → queued → provisioning/staging → submitting → running → retrieving → ingesting → ready_for_review；异常为 retryable_failure、final_failure、unknown_submission、cancel_requested/cancelled。服务重启后仅对已知 provider_task_id 继续查询；提交超时且无远端 ID 时进入 unknown_submission，不自动再次提交或假定未扣费，由远端订单查询/人工核对后解锁。ready_for_review 只是候选已归档，不等于 adopted/final。

实施数据表：batch、item、attempt、worker_instance、media_ingest、delivery_event、cost_ledger、outbox、inbox。唯一约束至少覆盖 (source_system,source_item_id,source_revision_id,operation)、provider_task_id、(item_id,attempt_no)、(target_system,event_id)。有 lease_owner/lease_until 与心跳；过期租约回收前先核对远端任务。启动扫描和周期对账均可重复运行。所有状态变迁记时间、原因、执行者和追踪 ID。

3.2 接口草案（由集成验收后定版）

POST /v1/batches
Idempotency-Key: kdw:<project-id>:<batch-id>:<revision>
Authorization: Bearer <service-secret>

{
  "schema_version": 1,
  "batch_id": "uuid",
  "project_id": "uuid",
  "mode": "preview",
  "authorization": {"approved_by": "user-id", "approved_at": "ISO-8601", "currency": "CNY", "max_amount": "200.00"},
  "items": [{
    "item_id": "uuid", "target": {"type": "shot", "id": "uuid", "source_revision_id": "uuid"},
    "operation": "video.generate", "variant": "fl2va", "prompt": "...",
    "references": [{"asset_id": "uuid", "version_id": "uuid", "sha256": "hex"}],
    "parameters": {"duration_s": 5, "aspect_ratio": "9:16", "profile_id": "h3-fl2va-v1"},
    "depends_on": ["image-item-id"]
  }]
}

应答为 202 {batch_id,status_url,items:[{item_id,status}]}；相同幂等键且内容 hash 相同返回原批次，内容不同返回 409。GET /v1/batches/{id} 返回逐项状态、失败/未知原因、尝试、候选 MediaFlow ID、预计与实际费用；POST /v1/items/{id}/retry 仅对明确失败且经费用授权可用，重新尝试前再次查远端。POST /v1/items/{id}/cancel 返回取消请求状态，不能承诺远端一定停算或退款。KDW 消费 GET /v1/events?after=<cursor>；签名回调是可选加速，不是唯一成功通道。

KDW 当前已有内部 /generation-tasks/submit/status 和 Gateway 连接，接入时先做小适配层：保留其任务、记录、收费确认和候选归档行为；新增批量提交与结果映射，不把新网关伪装为另一个业务数据库。另需核对其 /submission/fail 在网络超时场景是否会将“结果未知”误记为明确失败，按 KDW 既有规则修正。

4.1 两种模式

精品模式：设定图候选生成 → KDW 人工核对/固定设定版本 → 逐镜确认分镜与引用 → 生成视频候选 → KDW 逐镜采用 → 冻结整集交付清单 → 加工 → 终审。个别失败只重试该 item；个别镜头重做不改其他镜头已采用版本。剧本、提示词、设定版本变更时，受影响镜头显示失效与范围，由人决定继续旧版或重新生成。

打样模式：KDW 在提交前生成完整依赖 DAG、冻结预期参考与费用上限，用户一次确认本批次收费；调度器只执行依赖，不能替人正式定稿。图片成功后选择“本批次首个通过技术校验的候选”作为临时输入，视频后自动出 preview，页面明显标明未审片/未译审。某图失败时只阻塞依赖该图的视频，其余可继续；整批结束为 partial_success 也可交付可用的局部结果。正式发布仍经过人审。

图像适配器与视频适配器分开：能力矩阵记录模型是否生图、支持几张参考图、条件类型、画幅、时长、同步/异步、价格取得方式。不能把 MiniMax H3 直接列为生图服务，也不能把 Seedance 的视频接口当生图接口；每个渠道先以当前合同/API 实测，再启用。H3 的 t2va/fl2va/ref2va 变体与工作流参数必须固定版本；SGLang 官方 H3 文档写明 FL2VA 与 Ref2VA 分区不同，不能假设一个加载实例包办全部。

4.2 节点调度（用户计划的扩容路径）

首机与云机实现同一 Worker 契约：/health（权重/工作流版本、能力、空闲槽位）、POST /jobs、GET /jobs/{id}、GET /jobs/{id}/result、可选取消。ComfyUI 后端可由受控封装调用 /prompt 与 /history/{prompt_id}；官方 ComfyUI 路由文档可作为端点依据。SGLang 后端用独立适配器。节点可以本地排队多项，但第一轮以每个已验证实例一个运行槽位和中心队列为基线；只有拿到真实并发吞吐与显存曲线才调高。每节点可批量预分配 10 项，但这只是排队与长租约，不表示 10 条同时算。

优云智算控制面按“容量确认→创建/启动→实例就绪→Worker 健康/模型版本核对→租约发放→执行/回收→空闲宽限→停机”设计。云主机独立盘/镜像费用与启动耗时计入决策；不把停机当零成本。扩缩容输入为队列等待时间、已就绪槽位、预计单条 P50/P95、预算剩额、任务截止时间与云平台实际可用容量；设最大节点数、每晚预算和空闲停机阈值。首期单调度器单写者即可，不引入 Kubernetes、GPUStack、SwarmUI 作为控制面前置条件。未来如需复杂 GPU 资源编排再评估。

云节点网络只允许控制服务访问管理口；参考素材通过短期受控下载或主动拉取，不让云节点直接挂公司 NFS。输出先在云侧临时区生成，上传/拉取到受控暂存区，经 hash、ffprobe、音轨和时长校验后入 MediaFlow；确认入库再清理云侧副本。公网连接用 TLS、最小权限令牌、有效期与访问日志，不能暴露裸 ComfyUI。镜像、权重许可、依赖和工作流都钉版本，启动前后记录 image digest 与健康检查。

4.3 参考图传递

KDW 传 asset_id + version_id + sha256，调度器经 MediaFlow 授权下载接口或受控媒体读取器流式取得指定版本，缓存于 SSD 暂存区并校验 hash、大小、MIME。适配器按实际 API 能力选择 multipart/可访问的短期对象 URL/必要时 base64；base64 只用于供应商要求的小图，避免塞数据库或大 JSON。视频与参考音频不经 base64。任何本地路径都不得出现在云侧请求中。缓存以 hash 命名、限额与 TTL 清理；原资产版本不因新图上传而变更。

MediaFlow 保存候选文件及其版本栈，KDW 保存“某镜此刻采用哪个文件版本”和历史采用事件。latest 仅用于界面浏览，不能用于生成引用或交付。新尝试产生新文件版本；拒绝/撤销不删除历史；同一镜多候选可在一个栈内比较，但需实测入栈后返回的 stack ID 与子版本 ID，并把两者都记账。MediaFlow 内评论可供审片；正式采用按钮先留 KDW。未来若希望在 MediaFlow 直接批准，先定义映射和权限，再建可重放的事件适配器，不能仅根据元数据字段 approved 推定 KDW 已采用。

入库采用“暂存→流式上传→服务端确认→读取回验→写账本→发 KDW 事件”；在任何一步失败都保留原 attempt 与暂存校验值。若上传确认响应丢失，先以供应商任务 ID、文件 hash 与目标项目查重；无法确认则标 ingest_unknown 等人工/对账，不盲目再造版本。MediaSync 既有四步上传可提取为共享客户端库或新适配模块，旧 LibTV 逻辑保持原样。gen.prompt/gen.refs/gen.model/src.origin 可作为新增通用字段，但现有 libtv.* 保留兼容并制定迁移对照；MediaFlow 字段底层 key 可能由服务端生成，不假定请求中的字符串可直接写。长提示词存不可变运行清单/附件，元数据只存摘要、hash 和检索字段，避免现有 fit_btree(2500) 截断丢证据。

物理存储分为：MediaFlow 正式资产主本、加工暂存、两个站点的发布媒体区、备份/快照。相同文件在同一 ZFS 数据集、相同文件系统且应用允许时可硬链接；跨数据集/NFS/格式则接受可追踪复制或衍生文件。所有复制记录源 ID、目标路径/对象 ID、hash、生成规则和引用方。对账发现目标缺失、hash 不符或孤儿文件时报警并人工处理，不自动删除。恢复 MediaFlow 数据库与媒体、站点数据库与发布目录时分别核对；现有媒体快照不能替代调度账本和 KDW 业务数据备份。

字幕源分三级：①已确认剧本对白及人工阿语译稿；②已发布原片的已验 SRT/ASS；③ASR/机器翻译草稿。每句记录 dialogue_id、说话人、原文/译文修订、语言、目标集/镜、原音轨区间、起止时间、审核人。KDW 管对白/译稿修订与选择，加工服务管时间轴与渲染；MediaFlow 保存字幕文件版本。ASR 只辅助对齐和查漏，不能自动替换专家译稿；已做的《弃子称王》第 1–5 集测试显示 Whisper 可用作初稿、机器中阿翻译仍有实质错义，见 字幕样本记录。无对白镜头允许空字幕，但要在清单声明。

加工输入是不可变 delivery_manifest：按集排序的 shot_id、已采用 mediaflow_version_id、源 hash、入出点、画幅/FPS/音频策略、字幕文件版本及时间基准、目标规格。前置校验：引用均存在、源修订未失效、音视频流可读、时长覆盖入出点、字幕时间不越界，所有需审批项已签认。支持可切换的软字幕轨和烧录版；阿语方向、字形/字体、双语排版和不同渠道播放器要用真机验收。

FFmpeg 按镜头或约定小段生成确定性中间片段，输入 hash + 参数 hash 作为缓存键；每段完成后原子改名并写 manifest。崩溃在第 80 镜时，重新扫描有效段，只补坏段/未完成段，再做整集拼接、音量/响度、画幅与字幕处理。若用无重编码 concat，必须先确保编码、像素格式、帧率、音频参数一致，否则逐段标准化后再拼。整集最终文件先写 .part，验证 ffprobe、时长、音轨、黑帧/静音抽检、字幕抽查和 hash 后才发布正式名称。480p/720p/1080p、FCP XML/剪映草稿/Premiere XML 分别立项验收；首期只承诺一种打样 MP4 + 字幕，工程导出不假设 1 天内兼容全部 NLE。

交付版本通过人工终审后形成 release_id 与冻结清单。渠道适配器逐一执行：确认目标授权/可见范围→上传或索引媒体→写标题/海报/字幕→检查站点 API 与播放器真实播放→记录远端 ID、URL、hash、版本与状态。渠道失败只重试该渠道，不能把交付整体重新合成。撤回需操作渠道并保留审计记录；公共站点默认不因内部终审自动对外发布。酷视频已存在外网通道，故蓝图“全部内网、暂无公网部署计划”必须改为“生产调度与素材控制面仅内网，发布站点已有外网入口”。

服务间独立账号/密钥、项目范围授权、输入路径白名单、下载 URL 期限、日志脱敏。KDW CT142 当前无登录认证，增加员工身份/权限或限访问网段是批量收费与交付入口的上线前闸口；不因 Office Portal 有导航就视作已鉴权。审批人身份保留稳定人员 ID，不只存显示名。执行服务新增后按 注册表 登记，域名、DNS、门户展示各自决策；云 Worker 管理口不进门户。

费用账本由执行层记录每个 attempt 的报价版本、预估/实际、供应商任务 ID、云节点开机分钟、存储与出入流量；KDW 聚合到项目、集、镜并展示剩余预算。实际扣费未知时显示“待对账”，不拿估算当实扣。提交前给用户展示批次上限、单项上限、预计重做余量；达到上限暂停新付费任务，运行中的远端任务继续对账。不要沿用蓝图中“H3 约 0.3–1 元/次”作为预算事实，实际以当前渠道与规格报价核验。吞吐公式：所需节点≈总待生成片段数 × 实测 P95 单条耗时 ÷ 可用生产窗口 ÷ 每节点已验证并行槽位，再乘重做率与可用率；首机/云机分别做 5/10/15 秒、T2VA/FL2VA/Ref2VA 端到端样本后填具体数。

最小监控：队列长度/最老等待、各状态数量与卡住时间、远端未知提交、节点启动失败、每节点吞吐/P95、入库失败、MediaFlow 可用性、ZFS 可用空间与 NFS、每日报价/实扣偏差、字幕/合成/发布失败。告警只在需要人处理时发出。备份覆盖 KDW data/、调度数据库与 outbox、MediaFlow 数据库及媒体、加工清单和站点发布账本；每季度在隔离环境演练“执行服务重启、回调丢失、云节点消失、版本误删、片段合成中断”。

不采用原案“4.5 天完成全链路”的估算：它未计 KDW/MediaFlow 接口差异、字幕译审、云节点镜像与故障恢复。每阶段以验收结果而非日历天数推进。

具体实施仓位：跨服务调度与可复用节点适配先在 OPS office/apps/ 维护，若出现独立发布节奏/多人并行再拆独立仓并保留历史；KDW 业务适配在 KDW 仓；MediaFlow 必要的通用事件/API 在其独立仓；MediaSync 的 LibTV 同步继续留原目录；H3 权重与工作流实验仍以 Cowork H3 lab 为实验主本，部署证据记 OPS。所有真实部署前遵守 OPS 的资源锁、备份与 work-log，涉及 VPS 还需先执行 Cowork 漂移检查。

1. share/mediaflow-data dataset 已在 PVE2 现场确认，但 VM 内 NFS/容器路径、容量口径（现场可用约 20.9T，注册表写 16T）、快照与数据库备份是否已同步改造仍待查；服务注册表更新尚未提交，不能用旧恢复手册直接执行恢复。
2. CT140 运行且 MediaSync service active；当前运行代码与本机源码的 hash、M2.5 上传版本的真实幂等性、是否有服务间认证仍待查；现有源码队列在内存中，不承担新生产调度。
3. KDW CT142 部署分支相对仓库最新功能的差异，批量任务是否有现成 API、Gateway 接入是否完成、数据备份是否具备；无认证入口在收费前需要治理。
4. MediaFlow 是否有可用审片事件/审批对象及其权限；若无，首期采用只在 KDW，不伪造双向审批。
5. 具体供应商当前的 API 能力、合同价格、并发限制、任务查询/取消、版权及 H3 模型/工作流商业许可；云镜像大小、启机时间和节点实际吞吐须用一台样机验证。
6. 第一个项目的字幕主稿、镜头时长、目标渠道和发布受众由业务负责人确认。系统可先用非付费样本和内部预览验证，正式批量和对外发布各有独立审批。

这些项目作为 P0/P1 的检查表，核实后在本文记录修订号及证据链接；不以猜测填入“已完成”。