随着目前大媒体视频/图片生成模型（如 Wan2.7, Cling 3.0 等）的普及，官方原生 API (如 DashScope 等) 的算力与测试成本较高。Modellix.ai 作为高性价比的多媒体大模型中转平台，整合了海量低廉的多媒体 API 资源。为了能够让 VideoClaw 支持通过类似 Modellix.ai 这样的平台降低整体测试与生产成本，在此希望能官方适配。
经过本地的开发试验，我们已经成功搭建了一套可行的二开集成验证，希望官方可以参考并融入到主干代码中。
🛠️ 需要适配的核心技术痛点
视频与图片生成“异步任务（Asynchronous Pipeline）”机制的适配
VideoClaw 原有的图片与视频生成逻辑大多更偏向于同步阻塞。而 Modellix 全面采用了异步取餐小票机制，即 POST 请求只能立刻拿到 task_id。
建议方案：后端在 backend/models/ 下独立抽象出诸如 video_modellix.py 和 ModellixImageClient 的独立客户端，专门用来向接口发送请求并执行后台任务的非阻塞轮询机制（由 PROCESSING 轮询检查至 SUCCESS），直到成片后全自动拉取。
LLM/VLM 与多媒体模型的架构解耦（核心路由修正）
Modellix 官方模型池中不提供 chat 或 text-generation 类型（无文本大脑）。因此需要系统底层支持将 文本大模型（继续走原有的 DeepSeek/Qwen/OpenAI 等） 与 多媒体模型（走 Modellix 服务） 进行真正的逻辑分离与并行跨提供商（Provider）混调。
同时，需要对路由进行精细化分流。例如原有的代码可能会把含有 alibaba/... 命名的模型默认硬塞给 DashScope，需要支持根据具体的 Provider 建立分流判断。
文生图 (t2i) 与图生图 (edit) 的模型规则隔离
在第二阶段冷启动角色设计时，部分多媒体服务需要明确区分 text-to-image（文生图）与 image-to-image（图生图编辑模型），例如 alibaba/wan2.7-image-pro 与 -edit 模型的调用逻辑。避免前端由于默认规则误选 edit 类型的模型，导致请求缺少 images 字段而直接报错。
针对高延迟多媒体模型的并发与评审流调优
鉴于这类多媒体模型有明显的排队和轮询高延迟，建议在调用此类供应商时，可以考虑放开单并发限制（锁死为1会引起严重的多场景更串行等待）。
同时建议针对此类模型可以提供跳过 VLM 多轮交叉复评审判以及将默认 3 个参考图版数降低为 1 的轻量级性能/重试策略。
🚀 预期改进建议
后端在 models/config_model.py 中，能动态或硬编码的方式，将 Modellix 发现的多媒体模型（如 happyhorse 等）塞进整个系统的生产模型池（api/models 接口）中，并贴上对应的 image 或 video 标签，让前端下拉菜单正式建立 Modellix 的独立分组。
修复和理顺各提供商在多通道转发中的 api_key 覆写及 JSON 编解码（避免带 BOM 后重启无法加载）等边缘体验 Bug。
随着目前大媒体视频/图片生成模型（如 Wan2.7, Cling 3.0 等）的普及，官方原生 API (如 DashScope 等) 的算力与测试成本较高。Modellix.ai 作为高性价比的多媒体大模型中转平台，整合了海量低廉的多媒体 API 资源。为了能够让 VideoClaw 支持通过类似 Modellix.ai 这样的平台降低整体测试与生产成本，在此希望能官方适配。
经过本地的开发试验，我们已经成功搭建了一套可行的二开集成验证，希望官方可以参考并融入到主干代码中。
🛠️ 需要适配的核心技术痛点
视频与图片生成“异步任务（Asynchronous Pipeline）”机制的适配
VideoClaw 原有的图片与视频生成逻辑大多更偏向于同步阻塞。而 Modellix 全面采用了异步取餐小票机制，即 POST 请求只能立刻拿到 task_id。
建议方案：后端在 backend/models/ 下独立抽象出诸如 video_modellix.py 和 ModellixImageClient 的独立客户端，专门用来向接口发送请求并执行后台任务的非阻塞轮询机制（由 PROCESSING 轮询检查至 SUCCESS），直到成片后全自动拉取。
LLM/VLM 与多媒体模型的架构解耦（核心路由修正）
Modellix 官方模型池中不提供 chat 或 text-generation 类型（无文本大脑）。因此需要系统底层支持将 文本大模型（继续走原有的 DeepSeek/Qwen/OpenAI 等） 与 多媒体模型（走 Modellix 服务） 进行真正的逻辑分离与并行跨提供商（Provider）混调。
同时，需要对路由进行精细化分流。例如原有的代码可能会把含有 alibaba/... 命名的模型默认硬塞给 DashScope，需要支持根据具体的 Provider 建立分流判断。
文生图 (t2i) 与图生图 (edit) 的模型规则隔离
在第二阶段冷启动角色设计时，部分多媒体服务需要明确区分 text-to-image（文生图）与 image-to-image（图生图编辑模型），例如 alibaba/wan2.7-image-pro 与 -edit 模型的调用逻辑。避免前端由于默认规则误选 edit 类型的模型，导致请求缺少 images 字段而直接报错。
针对高延迟多媒体模型的并发与评审流调优
鉴于这类多媒体模型有明显的排队和轮询高延迟，建议在调用此类供应商时，可以考虑放开单并发限制（锁死为1会引起严重的多场景更串行等待）。
同时建议针对此类模型可以提供跳过 VLM 多轮交叉复评审判以及将默认 3 个参考图版数降低为 1 的轻量级性能/重试策略。
🚀 预期改进建议
后端在 models/config_model.py 中，能动态或硬编码的方式，将 Modellix 发现的多媒体模型（如 happyhorse 等）塞进整个系统的生产模型池（api/models 接口）中，并贴上对应的 image 或 video 标签，让前端下拉菜单正式建立 Modellix 的独立分组。
修复和理顺各提供商在多通道转发中的 api_key 覆写及 JSON 编解码（避免带 BOM 后重启无法加载）等边缘体验 Bug。