Coze 工作流调用异步 HTTP API 完整教程：任务 ID、循环轮询、状态判断与结果 URL 提取

摘要

在 Coze 工作流中调用外部 AI 接口时，很多任务并不会在一次 HTTP 请求中直接返回最终结果。尤其是 AI 视频生成、大图渲染、音频合成、批量文件处理等长耗时任务，接口通常先通过 HTTP POST 创建任务，再返回一个任务标识，例如 id、taskId 或 jobId。工作流需要保存这个标识，通过 HTTP 节点反复查询任务状态，并使用代码节点解析 JSON 响应，再由循环节点、条件节点和定时器节点共同决定继续等待、进入成功分支，还是返回失败和超时信息。本文以通用接口为例，完整说明 Coze 工作流如何设计输入变量、提交异步任务、提取 taskId、执行任务状态查询、控制轮询退出，并最终输出结果 URL。文中所有接口地址、密钥和模型名称均为占位符，实际字段必须以目标 API 文档为准。

一、先理解同步调用与异步任务

在设计 Coze API 对接流程前，首先要判断目标接口属于同步 API 还是异步 API。两者最大的区别，是第一次请求结束时，业务结果是否已经生成。

接口类型	第一次请求返回内容	是否需要轮询	常见用途
同步 API	直接返回最终文本、数据或文件信息	通常不需要	短文本生成、分类、轻量查询
异步 API	返回任务 ID、提交状态或队列信息	通常需要	视频生成、大图渲染、音频合成、批量处理
回调 API	提交任务后，服务端通过回调通知结果	通常不需要	已具备 Webhook 接收能力的系统

同步接口的工作流比较直接：发送请求、解析响应、返回结果。异步接口则至少包含两个阶段：

1. 创建任务；
2. 查询任务。

异步接口的第一次 HTTP 请求通常只完成"创建任务"，而不是"获得结果"。如果工作流把"创建接口返回 HTTP 200"直接当作业务成功，就可能出现任务尚未执行、结果 URL 为空，甚至任务已经在服务端失败的情况。

一个典型的异步任务状态机可以抽象为：

created
  │
  ▼
queued
  │
  ▼
running
  ├──► succeeded ───► result_url
  ├──► failed
  ├──► cancelled
  └──► expired

实际接口的状态名称可能不同，例如：

• 进行中：created、queued、processing、running；
• 成功：succeeded、completed、success；
• 失败：failed、error；
• 取消：cancelled、canceled；
• 过期：expired。

因此，Coze 工作流不能只判断"有没有 URL"，也不能只判断某一个固定字符串。应根据接口文档建立自己的状态映射，并至少区分进行中、成功、失败、取消、过期和未知状态。

完整工作流逻辑可以先画成下面这样：

开始
  │
  ├─ 输入：prompt、images
  │
  ├─ HTTP POST：创建异步任务
  │
  ├─ 代码节点：解析 taskId、错误信息
  │
  ├─ taskId 是否有效？
  │    ├─ 否 → 创建任务失败分支
  │    └─ 是 → 进入轮询循环
  │
  └─ 循环：
       ├─ HTTP GET：查询任务状态
       ├─ 代码节点：解析 status、url、error
       ├─ 条件节点：
       │    ├─ 结果有效 → 成功分支
       │    ├─ 失败终态 → 失败分支
       │    ├─ 超过次数或总时长 → 超时分支
       │    ├─ 状态未知 → 异常分支
       │    └─ 仍在处理 → 定时器等待 → 继续循环
       │
       └─ 处理循环结果数组，输出最终结果

二、设计开始节点的输入与输出

1. 定义输入变量

在 Coze 中创建项目、智能体和工作流后，先在开始节点定义输入变量。一个常见的多模态任务可以使用以下结构：

变量名	类型	用途
prompt	String	文本描述、生成指令或任务提示词
images	Array<File/Image>	用户上传的图片列表或图像输入
request_id	String	可选的业务请求标识，用于日志追踪
max_wait_seconds	Integer	可选的总等待时间上限

截图中常见的变量类型还可能包括 Integer、Number、Boolean、Time、Object、Array、File、Image、Svg、Audio、Video 和 Doc。不同 Coze 版本的编辑器界面、变量选择器和文件子类型可能存在差异，应以当前工作流编辑器显示的选项为准。

images 的实际传递形式尤其需要确认。有些接口要求：

• 文件 ID；
• 已上传文件的地址；
• Base64 字符串；
• 单个对象数组；
• 仅接受一张图片；
• 完全不支持图片输入。

因此，开始节点的变量类型并不等于目标接口的请求格式。必要时，可以增加一个代码节点，把 Coze 文件变量整理成 API 所需的数组结构。

2. 规划输出变量

建议在开始搭建节点前，先确定最终工作流需要输出哪些字段：

success       Boolean
url           String
status        String
error_code    String
error_message String
task_id       String
trace_id      String

即使业务暂时只需要一个结果 URL，也建议保留状态和错误字段。这样在任务失败、链接过期或接口结构变化时，调用方能够获得可诊断信息，而不是只看到一个空字符串。

3. 变量传递关系

整个异步工作流的核心变量关系如下：

开始节点.prompt
        │
        ├──────────────► POST 请求体.prompt
        │
开始节点.images
        │
        └──────────────► POST 请求体.images

POST.body
        │
        ▼
代码节点：parse_create_response
        │
        └──────────────► taskId
                              │
                              ▼
                    循环中间变量 var_taskId
                              │
                              ▼
                    GET 查询请求的 id 参数

GET.body
        │
        ▼
代码节点：parse_status_response
        │
        ├──────────────► status
        ├──────────────► url
        └──────────────► error

变量名最好体现来源和用途，例如 create_body、task_id、query_status、result_url，不要在多个节点中重复使用含义不同的 data 或 result。

三、使用 HTTP 节点创建异步任务

1. 配置 POST 请求

在开始节点之后添加 HTTP 请求节点，用于调用外部异步任务创建接口。常见配置包括：

• 请求方法：POST；
• API 地址：YOUR_CREATE_API_ENDPOINT；
• 请求头：
  • Content-Type: application/json
  • Accept: application/json
  • Authorization: Bearer YOUR_API_KEY
• 请求体：JSON；
• 超时时间：根据接口文档和任务提交耗时设置；
• 重试次数：只对适合重试的网络错误启用；
• 输出：body、statusCode、headers。

示例请求体如下：

{
  "prompt": "{{prompt}}",
  "images": "{{images}}",
  "model": "YOUR_MODEL_NAME",
  "size": "YOUR_SIZE",
  "duration": 15,
  "watermark": false
}

这里的 {``{prompt}} 和 {``{images}} 只是变量引用的概念化写法。实际 Coze 编辑器可能要求通过变量选择器插入字段，不能假定所有版本都支持手写模板表达式。

同样，这个 JSON 也不是所有 AI 视频或图片接口的通用协议。以下内容都可能不同：

• 字段名是 prompt 还是 text；
• 图片字段是 images、image_url 还是 input;
• 时长是数字、字符串还是毫秒；
• 尺寸是 width、height，还是预设值；
• 模型字段是否必填；
• 是否支持水印参数；
• 是否需要额外的回调地址或幂等键。

2. 检查 HTTP 层与业务层

HTTP 节点返回成功状态码，只能说明请求在 HTTP 层面被服务端接受，不能保证任务已经生成成功。至少要分别检查：

HTTP 状态码是否表示请求被接受
响应 body 是否可以解析
是否存在任务 ID
业务状态是否表示创建成功
是否存在业务错误码或错误消息

例如，某些接口在任务提交后返回 202，表示已接受但仍在排队；另一些接口可能返回 200，但 body 中包含业务错误字段。Coze 工作流中的条件判断应同时使用 statusCode 和解析后的业务字段。

3. Authorization 的安全边界

Authorization: Bearer YOUR_API_KEY 只是示意。生产环境不要把真实密钥直接写入代码节点，也不要在日志、截图、测试输出或最终回复中打印完整密钥。

优先使用平台提供的密钥管理、环境变量或凭据引用能力。对于调试日志，可以只保留前后少量字符，例如：

key_prefix=ab12... key_length=32

实际密钥是否能被工作流节点直接引用，取决于当前 Coze 环境的凭据配置方式。不要假设所有工作流都具备相同的密钥管理能力。

四、用代码节点解析创建响应并提取 taskId

HTTP 节点的 body 可能是 JSON 字符串，也可能已经是对象。第二种情况下再次执行 JSON.parse() 会抛出异常，因此代码节点首先要判断类型。

下面是一个可以作为起点的通用示例：

async function main({ params }) {
  const raw = params.input;
  let taskId = "";
  let error = "";

  try {
    const body = typeof raw === "string" ? JSON.parse(raw) : raw;

    if (!body || typeof body !== "object") {
      throw new Error("创建任务响应不是有效对象");
    }

    taskId =
      body.id ||
      body.taskId ||
      body.task_id ||
      body.jobId ||
      body.data?.id ||
      body.data?.taskId ||
      "";

    if (!taskId) {
      error = "响应中未找到任务 ID";
    }
  } catch (e) {
    error = `无法解析创建任务响应: ${String(e)}`;
  }

  return {
    taskId: String(taskId || ""),
    error
  };
}

其中 params.input 应绑定到上一个 HTTP 节点的 body 输出。代码中的多个字段路径只是为了展示适配思路，生产环境应根据真实响应结构收紧范围。

例如，接口可能返回：

{
  "id": "TASK_ID_PLACEHOLDER",
  "status": "queued"
}

也可能返回：

{
  "data": {
    "task_id": "TASK_ID_PLACEHOLDER",
    "state": "created"
  }
}

还可能返回：

{
  "job": {
    "jobId": "TASK_ID_PLACEHOLDER"
  }
}

不能因为代码同时兼容多个字段，就忽略接口结构异常。如果创建响应缺少任务 ID，后续 GET 查询没有可靠参数，工作流应该立即进入"创建任务失败"分支，而不是让空字符串进入循环。

建议在此处增加一个条件节点：

taskId 非空 且 error 为空
  ├── 是 → 进入任务轮询
  └── 否 → 输出创建任务失败

失败分支可以返回：

{
  "success": false,
  "status": "create_failed",
  "error_message": "未能从创建任务响应中提取任务 ID"
}

不要直接将完整上游响应返回给最终用户，因为响应中可能包含请求头、内部字段或敏感信息。调试时只记录经过脱敏和截断的响应片段。

五、在循环节点中查询任务状态

**

**

1. 循环节点的职责

得到 taskId 后，将它保存为循环节点的中间变量，例如：

var_taskId = parse_create_response.taskId

循环内部放置一个 HTTP GET 节点，用于查询任务状态。通用形式可以表示为：

GET /v1/tasks/query?id={{var_taskId}}

这个路径仅表示接口结构示意，不代表 Coze 固定接口，也不代表任何第三方平台的真实地址。

查询节点通常需要配置：

• 请求方法：GET；
• 查询参数：id = var_taskId；
• 请求体：none；
• 请求头：
  • Accept: application/json
  • Authorization: Bearer YOUR_API_KEY
• 单次请求超时；
• 可控的重试次数；
• 输出：body、statusCode、headers。

GET 查询接口可能把任务 ID 放在路径参数中，例如：

/tasks/{{var_taskId}}

也可能放在查询参数中，或者要求 POST 请求体。具体形式必须以目标 API 文档为准。

2. 查询响应解析

第二个代码节点负责把查询响应转换成稳定的工作流输出：

async function main({ params }) {
  const raw = params.input;
  let url = "";
  let status = "";
  let error = "";
  let errorCode = "";

  try {
    const body = typeof raw === "string" ? JSON.parse(raw) : raw;

    if (!body || typeof body !== "object") {
      throw new Error("查询响应不是有效对象");
    }

    status =
      body.status ||
      body.state ||
      body.data?.status ||
      body.data?.state ||
      "";

    url =
      body.url ||
      body.result_url ||
      body.data?.url ||
      body.data?.result_url ||
      body.result?.url ||
      body.output?.url ||
      "";

    errorCode =
      body.error_code ||
      body.code ||
      body.data?.error_code ||
      "";

    error =
      body.message ||
      body.error?.message ||
      body.data?.message ||
      "";
  } catch (e) {
    status = "parse_error";
    error = `无法解析查询响应: ${String(e)}`;
  }

  return {
    url: typeof url === "string" ? url : "",
    status: String(status || ""),
    error: String(error || ""),
    errorCode: String(errorCode || "")
  };
}

这里的 url 字段可能是临时签名地址，也可能只是一个资源标识。URL 非空并不必然代表资源可以永久访问，仍需考虑：

• 链接是否会过期；
• 是否要求额外权限；
• 工作流运行环境能否访问；
• 用户是否有权限打开；
• 资源是否需要转存到自己的存储；
• URL 是否指向预览页而不是最终文件。

代码节点的重点是数据适配，不应把所有业务逻辑都塞进脚本中。状态判断、等待和分支控制应该尽量保留在 Coze 的条件节点和循环节点中，便于后期维护。

六、用条件节点和定时器控制轮询

1. 判断顺序必须明确

每次查询后，建议按照以下优先级判断：

优先级	条件	处理方式
1	结果 URL 经过验证且状态属于成功终态	退出循环，进入成功分支
2	状态属于失败、取消或过期终态	退出循环，进入失败分支
3	已达到最大轮询次数或总等待时间	退出循环，进入超时分支
4	响应解析失败或状态未知	进入异常或保护性失败分支
5	状态仍为排队或处理中	定时器等待后继续查询

可以将条件逻辑表达为：

if validUrl && isSuccessStatus(status):
    finish_success

else if isFailureStatus(status):
    finish_failed

else if isTimeout():
    finish_timeout

else if status == "parse_error" || isUnknownStatus(status):
    finish_exception

else:
    wait_and_continue

不能只写成"URL 为空就继续"，因为任务失败、响应字段错误、接口返回 HTML 错误页时，URL 同样可能为空。也不能只判断 status == "failed"，因为实际接口还可能使用 error、cancelled、expired 等状态。

2. 定时器节点控制请求频率

当任务仍在处理中时，在"继续循环"之前增加定时器节点。例如等待 1500ms：

查询状态
  │
  └─ 仍在处理中 → 定时器 1500ms → 继续循环

1500ms 只是示例，不是所有接口的最佳值。轮询间隔应综合考虑：

• 任务平均执行时间；
• 接口频率限制；
• 单次请求成本；
• 工作流并发量；
• 允许的最大响应延迟；
• 服务端状态更新频率。

对于耗时数分钟的 AI 视频生成任务，每隔几百毫秒查询一次通常没有必要。可以使用简单退避策略：

第 1 次：等待 1 秒
第 2 次：等待 2 秒
第 3 次：等待 4 秒
第 4 次：等待 8 秒
后续：最多等待 20 秒

概念公式为：

delay = min(initialDelay × 2^attempt, maxDelay)

为了避免多个工作流同时在固定时间发起请求，也可以在可用的情况下加入少量随机抖动。若目标服务提供 Webhook 回调，且当前系统具备可靠的回调接收和鉴权能力，应评估回调方案是否更适合长耗时任务。

3. 不要把无限循环当作生产配置

Coze 画布中的"无限循环"只是一种流程表达形式。生产工作流必须增加退出保护，至少包括：

最大轮询次数：40 次
初始间隔：2 秒
最大间隔：20 秒
总等待上限：10 分钟

这些数值仅为示例，实际应根据接口文档和业务时效调整。

可以维护以下循环变量：

attempt       当前轮询次数
started_at    首次提交时间
last_status   最近一次任务状态
last_error    最近一次错误信息

每一轮查询后更新 attempt，并判断：

attempt >= max_attempts

或者：

当前时间 - started_at >= max_wait_seconds

如果 Coze 当前循环节点不方便直接维护时间戳，可以在代码节点中输出 should_timeout，或使用固定次数与固定间隔近似实现总时长控制。但无论采用哪种方式，都要保证异常状态可以离开循环。

七、处理循环数组并输出最终结果

循环节点结束后，输出变量可能是数组，而不是单个值。例如：

url = ["", "", "https://placeholder/result"]
status = ["queued", "running", "succeeded"]

此时不能直接把 url 当成字符串使用，需要增加代码节点取出最后一项，或者筛选最后一个有效结果。

兼容性较好的写法如下：

async function main({ params }) {
  const urls = Array.isArray(params.urls) ? params.urls : [];
  const statuses = Array.isArray(params.statuses) ? params.statuses : [];

  const lastUrl =
    urls.length > 0 ? urls[urls.length - 1] : "";

  const lastStatus =
    statuses.length > 0 ? statuses[statuses.length - 1] : "";

  return {
    url: lastUrl || "",
    status: lastStatus || ""
  };
}

如果运行环境支持 Array.prototype.at()，也可以写成：

const lastUrl = urls.at(-1) || "";
const lastStatus = statuses.at(-1) || "";

但在不确定 JavaScript 运行时版本时，使用 array[array.length - 1] 更稳妥。

更完善的做法是同时保留最终错误信息和任务 ID：

async function main({ params }) {
  const urls = Array.isArray(params.urls) ? params.urls : [];
  const statuses = Array.isArray(params.statuses) ? params.statuses : [];
  const errors = Array.isArray(params.errors) ? params.errors : [];

  return {
    task_id: params.task_id || "",
    url: urls.length ? urls[urls.length - 1] || "" : "",
    status: statuses.length ? statuses[statuses.length - 1] || "" : "",
    error_message: errors.length ? errors[errors.length - 1] || "" : ""
  };
}

最终成功分支不要只检查 URL 是否为非空字符串，还应做基本验证：

url 非空
AND
status 属于成功状态
AND
url 格式符合预期

可以在代码节点中使用简单的协议检查：

function looksLikeUrl(value) {
  return typeof value === "string" &&
    /^https?:\/\//i.test(value);
}

这不是完整的 URL 安全验证，只能避免把普通文本误当作地址。对于敏感业务，还应限制允许的域名、协议和资源类型。

成功输出示例：

{
  "success": true,
  "status": "succeeded",
  "url": "RESULT_URL_PLACEHOLDER",
  "task_id": "TASK_ID_PLACEHOLDER"
}

失败输出示例：

{
  "success": false,
  "status": "failed",
  "url": "",
  "task_id": "TASK_ID_PLACEHOLDER",
  "error_message": "任务处理失败"
}

超时输出示例：

{
  "success": false,
  "status": "timeout",
  "url": "",
  "task_id": "TASK_ID_PLACEHOLDER",
  "error_message": "任务在允许的等待时间内未完成"
}

八、工程化设计：重试、超时、幂等与安全

1. 区分请求重试和任务重试

HTTP 节点的重试主要用于处理短暂的网络错误，例如连接重置或临时网关异常。它不等同于重新创建业务任务。

如果 POST 创建任务已经被服务端接受，但 Coze 因网络超时没有收到响应，直接再次 POST 可能产生两个任务。对于支持幂等键的接口，应为每次业务请求生成稳定的幂等标识：

idempotency_key = request_id

如果接口不支持幂等键，需要根据业务判断是否允许重复提交，或者在后端增加去重层。

2. 单次超时与总超时

需要区分两个概念：

• 单次请求超时：限制一次 HTTP 请求最多等待多久；
• 总任务超时：限制整个异步任务从创建到结束的最长时间。

例如，单次查询超时可以设置为几十秒，但总等待时间可能是几分钟。单次超时过长会阻塞循环，单次超时过短又可能误判网络异常，两个参数不能混为一谈。

3. 未知状态必须有出口

接口升级后可能出现工作流未识别的新状态。如果代码把所有未知状态都当作"处理中"，就有无限循环风险。

建议维护状态集合：

const successStatuses = new Set([
  "succeeded",
  "completed",
  "success"
]);

const failureStatuses = new Set([
  "failed",
  "error",
  "cancelled",
  "canceled",
  "expired"
]);

const runningStatuses = new Set([
  "created",
  "queued",
  "processing",
  "running"
]);

当状态不属于这些集合时，进入异常分支并记录必要信息，等待人工确认或后续规则更新。

4. 用户上传图片的安全性

在 AI 视频生成工作流或图像处理工作流中，images 往往来自用户上传。至少需要考虑：

• 文件大小限制；
• 文件类型和扩展名校验；
• 实际 MIME 类型校验；
• 图片数量限制；
• 是否包含个人信息；
• 是否具有版权或使用授权；
• 是否需要在发送前压缩或转换；
• 外部接口是否会长期保存文件；
• 结果文件是否包含敏感内容。

不要仅根据文件扩展名判断类型，也不要把用户上传内容原样写入日志。对于失败日志，记录文件数量、大小和内部请求标识通常已经足够。

5. 日志与可观测性

每次异步任务至少建议关联以下信息：

request_id
task_id
trace_id
attempt
status
elapsed_ms
http_status
error_code

日志中不要记录：

• Authorization 完整内容；
• 用户上传文件原文；
• 完整的签名 URL；
• 未脱敏的完整响应；
• 可能包含个人信息的 prompt。

调试时可以保存经过截断的字段路径和状态变化，例如：

task_id=TASK_ID_PLACEHOLDER
attempt=4
status=running
http_status=200
elapsed_ms=8700

九、常见问题排查清单

现象	常见原因	排查建议
POST 返回 401	API Key 错误、Bearer 格式错误、权限不足	检查鉴权前缀、凭据引用和权限配置
POST 返回 400	请求体字段、类型或必填项不符合要求	对照接口文档检查字段名、数组结构和数据类型
创建任务成功但没有 taskId	代码读取了错误字段路径	查看脱敏后的响应结构，确认是 id、task_id、jobId 还是嵌套字段
JSON.parse 报错	body 已经是对象，或响应不是 JSON	先判断 typeof raw，再检查 Content-Type 和错误页响应
查询一直返回处理中	任务尚未完成、轮询过快或状态映射错误	增加等待间隔，核对状态枚举，设置总超时
循环无法退出	没有成功、失败、超时和未知状态分支	增加最大次数、时间上限和保护性异常分支
URL 一直为空	结果字段被嵌套，或任务实际失败	检查 data.url、result.url、output.url 和错误字段
循环结果取错	循环输出是数组	判断是否为数组，处理空数组并取最后一项
查询请求过于频繁	没有定时器或间隔太短	增加延迟，采用递增退避并遵守接口频率限制
最终 URL 无法访问	链接过期、权限限制、资源尚未可用	检查 URL 有效期、访问权限和任务终态
任务重复创建	POST 超时后盲目重试	使用幂等键，或在业务侧增加任务去重
日志泄露密钥	节点或代码打印了完整请求头	删除敏感日志，使用脱敏后的标识
成功状态但 URL 无效	接口返回的是资源 ID 或预览地址	根据接口定义转换资源字段，并进行可访问性验证

排查时建议按照调用链顺序进行，而不是一开始就修改循环逻辑：

开始变量
  → POST 请求是否正确
  → HTTP 状态码是否正常
  → body 类型是否正确
  → taskId 是否提取成功
  → GET 查询参数是否正确
  → status 是否符合接口枚举
  → url 字段路径是否正确
  → 条件节点是否能退出
  → 最终数组是否取值正确

这样可以快速判断问题发生在请求、解析、变量传递还是流程控制阶段。

十、何时使用轮询，何时改用 Webhook 或后端服务

Coze 任务轮询适合以下场景：

• 外部接口只提供任务查询能力；
• 任务持续时间较短；
• 工作流并发量可控；
• 接口允许一定频率的查询；
• 结果可以在当前工作流中直接返回；
• 不需要复杂的任务持久化和队列管理。

轮询并不适合所有异步任务。以下情况可以评估 Webhook：

• 任务可能运行数分钟甚至更久；
• 查询频率限制较严格；
• 工作流并发量较大；
• 服务端提供可靠的完成回调；
• 系统已经具备回调鉴权、签名验证和重复通知处理能力。

当任务量、重试策略、幂等控制、文件转存、权限校验或审计要求明显增加时，可以考虑把复杂逻辑迁移到后端服务。此时 Coze 工作流负责接收输入、编排步骤和返回结果，后端服务负责：

• 保存任务状态；
• 管理任务队列；
• 执行指数退避；
• 处理幂等与去重；
• 接收和验证 Webhook；
• 转存临时结果 URL；
• 统一记录 trace ID；
• 提供稳定的内部接口。

这并不意味着低代码工作流无法处理异步任务，而是需要根据任务规模和可靠性要求划分职责。简单任务可以在 Coze 中完成 POST、GET、循环和条件判断；复杂任务则适合由专门的服务承接状态管理。

结语

在 Coze 工作流中调用异步 HTTP API，关键不是把一个 HTTP 节点连到另一个 HTTP 节点，而是正确处理"创建任务"和"获取结果"之间的状态变化。

一个可维护的异步工作流通常包含以下环节：

定义输入
  → POST 创建任务
  → 解析 taskId
  → 校验 taskId
  → 保存循环变量
  → GET 查询状态
  → 解析 status、url、error
  → 判断成功、失败、超时或未知状态
  → 定时器等待并继续轮询
  → 处理循环数组
  → 输出结果或诊断信息

其中，taskId 是创建阶段与查询阶段之间的桥梁，status 是状态机的核心，url 是成功分支的重要结果字段，而最大轮询次数、总超时、重试、未知状态处理和日志脱敏则决定了工作流能否稳定运行。

实际接入任何视频、图片、音频或文档处理 API 时，都应以该接口的返回结构、状态枚举、鉴权方式、频率限制和 URL 有效期为准。示例中的字段、路径和参数只能用于说明编排方法，不能直接视为所有服务的通用配置。