如何在未直接完成 Kling 接入的情況下使用 Kling API：2026 年指南

TL;DR 你可以透過 CometAPI（需要 CometAPI 帳號與 API 金鑰）直接使用支援的 Kling 影片模型，而不必額外完成 Kling 的開發者接入流程。當前的文字轉影片路由為 POST /kling/v1/videos/text2video。它會回傳一個任務 ID，你的後端需輪詢該任務直到其狀態變為 succeed 或 failed。模型可用性、參數、定價與帳號資格可能變動，正式上線前請核對最新的模型目錄與 API 文件。

直接解答

實際可行的路徑是查看 CometAPI 的 Kling 模型目錄。若你的 CometAPI 帳號可用到所需的 Kling 模型，你的伺服器即可使用 CometAPI 的 API 金鑰驗證，並呼叫相應的 Kling 相容端點。採用此路徑時，不需要額外建立獨立的 Kling API 應用作為整合步驟之一。

這個差異對已使用 CometAPI 的團隊很重要：應用僅需維持一個憑證管理面與單一供應商關係，即可新增 Kling 的影片工作流程。你的程式碼仍需使用 Kling 影片專屬的請求結構與非同步任務生命週期；「共用一把 API 金鑰」並不代表所有供應商的請求本文都相同。

本文聚焦於文字轉影片，因為這是最小可用的整合。CometAPI 也有記錄圖像轉影片與其他 Kling 流程，但各自有不同端點與參數限制。請先以一條已驗證的路徑開始，再在查閱最新文件後逐步增加能力。

為何此路徑對開發團隊有用

立即的效益在於營運而非魔法。已使用 CometAPI 的團隊可以在不建立另一個供應商直接整合、不散發另一組憑證、也不新增獨立帳號管理流程的情況下，加入可用的 Kling 工作流程。這可減少你的平台需要維護的機密、帳務關係與供應商專屬客戶端配置數量。

第二個效益在於架構。你的應用可以暴露一個精簡的內部影片生成契約——提示詞、工作流程、模型、選項與工作狀態——再由供應商轉接器將此契約轉譯為已記錄的 Kling 請求。若團隊之後評估另一個影片模型，面向產品的工作模型可以維持穩定，即使端點路徑、參數與輸出中繼資料不同。

同樣重要的限制是：統一的存取層不會讓底層模型可互換。提示行為、可接受的媒材、延遲、定價、安全政策與結果結構都可能不同。請在設定與測試中顯性呈現這些差異，而不是把它們藏在不被支援的假設之下。

此存取路徑會改變什麼——以及不會改變什麼

會改變的部分。 你將建立並管理一把 CometAPI 金鑰、將請求送往 CometAPI 的 Kling 相容 API，並從 CometAPI 端追蹤使用量。這會移除此存取路徑下另行完成 Kling 直接接入步驟的需求。

不會改變的部分。 Kling 仍是底層模型家族。供應商專屬參數、生成行為、可接受的使用規範、模型可用性與輸出特性仍然重要。CometAPI 的文件也指出不同供應商的請求與回應欄位可能不同，因此請以線上端點參考作為你實作的契約。

在投入前應該確認的事項。 確認你的帳號可存取所需的模型 ID、檢視當前價格與速率限制，並執行一個小型的已驗證測試。不要基於舊部落格或快取範例中的模型名稱設計生產流程。

開始之前

你需要一個 CometAPI 帳號、一把儲存在伺服器上的 API 金鑰，以及能執行非同步工作的後端。將金鑰保存在 COMETAPI_KEY 之類的環境變數中；不要在瀏覽器或行動端程式碼中暴露。

1. 開啟 Kling 模型目錄，確認你打算使用的模型目前對你的帳號可見。
2. 檢視當前的 Kling 文字轉影片 API 參考。在核對時，文件範例使用的是 kling-v3。
3. 在 CometAPI 控制台 建立伺服器端 API 金鑰，並將其設入你的執行環境。
4. 決定你的服務要在哪裡儲存任務 ID 與最終影片。生成請求回傳的是任務，而不是完成的影片檔。

在設計請求前先選定 Kling 工作流程

從你的產品已有的素材出發。若使用者只有文字概念，文字轉影片就是直接路徑。若使用者有一張靜態圖片需維持視覺錨點，請使用另行記錄的圖像轉影片路由。不要在文字轉影片請求中加入圖像欄位並假設 API 會自行推斷工作流程。

當前的圖像轉影片參考 接受公開圖片 URL 或 base64 圖像字串，並回傳非同步任務。更專門的 Kling 工作流程各有其頁面與請求限制。僅在產品需求與最新文件支援時，按需逐一加入轉接器。

作為第一個生產驗證，請使用一個工作流程、一個已驗證的模型 ID、短時長，以及少量具代表性的提示詞。這能將帳號存取與任務編排與主觀輸出評估拆開。當管線穩定後，再用固定的評估集比較不同模式或模型，而非在同一次測試中同時改變多個變數。

發送你的第一個 Kling 文字轉影片請求

當前的文字轉影片端點接受 JSON 與 Bearer 驗證。從短提示詞與最小支援時長開始。以下請求僅使用 CometAPI 參考中示範的欄位：

curl https://api.cometapi.com/kling/v1/videos/text2video \
  -H "Authorization: Bearer $COMETAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "一只小小的陶瓷杯放在木桌上，清晨柔光中有蒸汽緩緩上升",
    "model_name": "kling-v3",
    "mode": "std",
    "duration": "5",
    "sound": "off"
  }'

成功提交會回傳一個物件，其中包含 data.task_id 與任務狀態。將該任務 ID 與你應用的工作記錄一併保存。影片渲染期間不要保持 HTTP 連線開啟。

安全地處理非同步任務

Kling 生成屬於非同步流程。對於文字轉影片，請輪詢 GET /kling/v1/videos/text2video/{task_id}。CometAPI 的任務參考指出回應可能直接回傳任務或包在 data 物件中，因此範例會統一處理兩種形態。同時將所有非終態視為「繼續等待」，而不是假設固定的中間狀態清單。

import os
import time
import requests

API_KEY = os.environ["COMETAPI_KEY"]
BASE_URL = "https://api.cometapi.com/kling/v1/videos/text2video"
HEADERS = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json",
}


def submit_video(prompt: str) -> str:
    response = requests.post(
        BASE_URL,
        headers=HEADERS,
        json={
            "prompt": prompt,
            "model_name": "kling-v3",
            "mode": "std",
            "duration": "5",
            "sound": "off",
        },
        timeout=30,
    )
    response.raise_for_status()
    payload = response.json()
    return payload["data"]["task_id"]


def wait_for_video(task_id: str, timeout_seconds: int = 600) -> str:
    deadline = time.monotonic() + timeout_seconds
    poll_url = f"{BASE_URL}/{task_id}"

    while time.monotonic() < deadline:
        response = requests.get(poll_url, headers=HEADERS, timeout=30)
        response.raise_for_status()
        payload = response.json()
        task = payload.get("data") or payload
        status = task.get("task_status")

        if status == "succeed":
            videos = task.get("task_result", {}).get("videos", [])
            if not videos or not videos[0].get("url"):
                raise RuntimeError("任務已成功，但沒有影片 URL")
            return videos[0]["url"]

        if status == "failed":
            detail = task.get("task_status_msg") or task.get("task_result")
            raise RuntimeError(f"Kling 任務失敗：{detail}")

        time.sleep(10)

    raise TimeoutError(f"Kling 任務 {task_id} 超過 {timeout_seconds}s 的逾時限制")


task_id = submit_video(
    "一只小小的陶瓷杯放在木桌上，清晨柔光中有蒸汽緩緩上升"
)
video_url = wait_for_video(task_id)
print(video_url)

終態的成功字串是 succeed，不是 succeeded。當任務完成時，若你的產品需要長期保存，請將生成的資產複製到你可控的儲存中。供應商的交付 URL 不應視為永久的應用儲存。

對於較大的工作量，請使用佇列或工作執行器，而不是在 Web 請求內輪詢。CometAPI 也記錄了 Kling 任務的回呼 URL。若採用 Webhook，請驗證並去重回呼事件，並保留輪詢作為遺漏投遞的後備機制。

在擴張前先設計應用的工作生命周期

將供應商任務視為你自有工作記錄的一部分。儲存應用工作 ID、工作流程、請求的模型、供應商任務 ID、查詢 URL、目前狀態、提交時間戳、最後輪詢時間與輸出位置。這能讓支援與營運團隊在不必搜尋原始請求日誌的情況下調查失敗或緩慢的生成。

不要僅因客戶端未收到回應就重試建立請求。供應商可能已建立任務。請在提交前先持久化本地工作，並立即保存回傳的任務 ID，將建立重試與狀態查詢重試分離。當前的文字轉影片參考也記錄了 external_task_id 可用於應用追蹤；在把它當作去重機制前，請先確認其即時行為。

const TERMINAL = new Set(["succeed", "failed"]);

function normalizeKlingTask(payload) {
  const task = payload?.data ?? payload;
  if (!task?.task_id || !task?.task_status) {
    throw new Error("Kling 回應缺少任務識別或狀態");
  }
  return task;
}

async function refreshVideoJob(job, apiKey) {
  const response = await fetch(job.queryUrl, {
    headers: { Authorization: `Bearer ${apiKey}` },
  });

  if (!response.ok) {
    throw new Error(`任務查詢失敗，HTTP 狀態碼為 ${response.status}`);
  }

  const task = normalizeKlingTask(await response.json());
  const outputUrl = task.task_result?.videos?.[0]?.url ?? null;

  return {
    ...job,
    providerTaskId: task.task_id,
    providerStatus: task.task_status,
    terminal: TERMINAL.has(task.task_status),
    outputUrl,
    failureDetail: task.task_status_msg ?? null,
    checkedAt: new Date().toISOString(),
  };
}

此範例刻意不把每一種可能的中間供應商狀態對映為產品承諾。你的工作器維持非終態為進行中，明確處理 succeed 與 failed，並記錄原始的供應商狀態以便除錯。另行設定應用逾時，避免停滯的任務無限存在。

以輪詢作為基線，因為任務 ID 始終可查詢。當所選端點支援 callback_url 時，Webhook 能降低重複的狀態請求，但不應成為唯一的恢復機制。官方的 輪詢與 Webhook 指南 指出回呼負載可能因供應商而異。請儲存原始事件、以任務 ID 實現冪等處理、快速回應成功的 HTTP 狀態，並透過輪詢核對終態。

開發團隊生產檢查清單

• 驗證執行期模型。檢查當前目錄，並在請求的模型不可用時清楚失敗。若輸出行為重要，不要默默替換為其他模型。
• 將提交與取回分離。儲存 CometAPI 任務 ID、自有工作 ID、所選模型與時間戳，以免重試造成重複工作。
• 限定輪詢。設定逾時、指數退避或合理固定間隔與最大重試次數。增加並行前先閱讀 CometAPI 的 速率限制與並行指引。
• 分類錯誤。不要重試無效參數或驗證失敗。對可重試的速率限制與平台錯誤套用退避，遵循 當前重試指南。
• 保護憑證與輸入。金鑰留在伺服器端，避免記錄機密，並確認使用者對其提交的提示詞、圖片或其他素材擁有權利。
• 度量整個工作。追蹤提交成功、排隊時間、生成時間、終態失敗率、逾時率、輸出取回成功與依模型與模式分列的成本。
• 謹慎持久化輸出。當產品需要長期存取時，下載完成資產到你可控的儲存，再套用你的保存與刪除政策。

常見實務問答

走這條路還需要單獨申請 Kling 開發者帳號嗎？

在 CometAPI 的整合流程中並未出現額外的 Kling 開發者接入步驟。你使用 CometAPI 帳號與 API 金鑰。存取仍取決於模型對你的 CometAPI 帳號與區域的可用性，請在投入生產前確認。

這個 Kling API 是否完全相容 OpenAI？

此處展示的影片工作流程並非如此。它使用 Kling 專屬路由，例如 /kling/v1/videos/text2video，以及 Kling 專屬欄位。你可以透過 CometAPI 管理憑證，但你的轉接器應保留供應商專屬的結構。

我應該使用哪個 Kling 模型 ID？

當前的 CometAPI 文字轉影片參考在首個可運作範例使用 kling-v3，並列出數個較早的系列。請使用線上端點列舉中的模型 ID，並確認你的帳號已啟用。不要假設最新模型在任何地方都可用。

為什麼第一次回應沒有包含影片？

影片生成是非同步任務。初始回應會回傳任務 ID。請輪詢對應的查詢路由，直到 task_status 變為 succeed 或 failed，再讀取結果中繼資料。

我該選擇輪詢還是回呼 URL？

對於首次整合，輪詢較為簡單。回呼在規模化時能減少重複請求，但需要具備驗證、冪等的接收端與恢復邏輯。許多生產系統以回呼為主要路徑、輪詢為後備。

可以透過同一端點使用圖像轉影片嗎？

不行。CometAPI 將圖像轉影片記錄在另一條路由 /kling/v1/videos/image2video。請遵循該端點當前的請求結構，而非在文字轉影片範例中加入圖像欄位。

應該從標準模式還是專業模式開始？

請先用 std 驗證驗證流程、請求結構、任務儲存、輪詢與輸出取回。當前參考描述 pro 具有更高品質與更高成本。待基本流程穩定後，再以具代表性的提示詞評估，並同時比較輸出品質、生成時間與實際成本。

如何在重試時避免重複生成？

在呼叫 API 前先建立應用工作記錄，並立即保存回傳的供應商任務 ID。將狀態查詢重試與建立請求重試分開。不要假設重送相同的 POST 是冪等的。端點目前記錄了 external_task_id 用於追蹤，但在將其當作去重保證前，請確認其當前語意。

結論

對於希望在不另行完成 Kling 直接開發者申請的情況下測試 Kling 影片生成的美國開發團隊，CometAPI 提供了一條已記錄的路徑：確認所需的 Kling 模型對帳號可用、使用 CometAPI 金鑰驗證、呼叫工作流程專屬端點，並追蹤非同步任務直到終態。

實際的工程價值是集中化存取與可重用的應用工作模型——而不是假設每個影片供應商行為相同。為各個工作流程保留精簡的轉接器，謹慎持久化任務識別與輸出，即使啟用了回呼也保留輪詢作為恢復途徑。

安全的漸進上線應小而可量測：驗證一個模型與一個工作流程，提交短時、低成本的工作，記錄終態成功與失敗率，驗證輸出取回，並將實際成本與延遲與你的產品需求對照。僅在檢查當前文件與你的目標帳號之後，再擴展到圖像轉影片或其他 Kling 工作流程。