Union Alpha 能不能在一次请求里同时送图片和文字，不取决于名字里的“多模态”，而取决于它当前接口的请求体约定。建议先发一条不接业务的最小请求：先用纯文本确认鉴权、入口和请求体结构正常，再在同一请求体里追加图片字段，看返回是正常回包还是明确的参数错误。两种结果分别对应“同一请求混送”和“需要拆成单独接口或单独模型”，确认之后再决定怎么接业务，可以少返工。

判断 Union Alpha 是否支持图文同送，可以用一条最小请求做二分验证：纯文本请求跑通后，在 messages 的 content 数组里追加图片字段。若返回正常且含多模态痕迹，说明当前模型和入口接受混送；若返回 400/422 并提示未知字段或内容类型不支持，则更可能是单独接口或独立模型。验证前需确认账号有对应额度，图片大小和格式符合页面限制，否则失败原因会被鉴权或体积问题掩盖。

在控制台确认鉴权字段与请求入口的位置

先不要写业务代码。打开控制台或接口文档页，记录页面上实际显示的三个名称：密钥、接口入口、模型标识。不同页面叫法可能不同，比如 API Key、Access Token、Base URL、Endpoint、model、model_name。只抄页面显示的字段名和值，不要自行拼地址，也不要在代码里硬编码成猜测的路径。

建议记录成一份短清单：

• 密钥：页面显示的名称，用于 Authorization 或 header 字段。
• 接口入口：页面显示的请求根地址，用于拼接具体路径。
• 模型标识：页面显示的可选模型名，决定走文本还是多模态能力。

如果页面只给了模型名没给完整路径，通常会在文档示例里给出一段可复制的请求样例；以那一段为准，不要用记忆中的其他平台路径替换。

先发一条只有文本的最小请求

用最小文本请求先验证链路。下面是一个通用骨架，字段名需要替换为控制台或文档中实际显示的名称，放在你自己的终端或脚本文件里执行。

curl -X POST "$BASE_URL/你的文本接口路径" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "页面显示的模型标识",
    "messages": [
      {"role": "user", "content": "只回复 ok"}
    ]
  }'

替换 $BASE_URL、$API_KEY 和接口路径。如果平台用其他鉴权头，比如 x-api-key，就按页面显示的字段改。运行后看返回：通常有请求 id、模型名、choices 或 message 字段，并且 HTTP 状态码为 2xx，就说明鉴权、网络和请求体结构已经通了。如果返回 401 或 403，先回到控制台确认密钥是否复制完整、是否带上了 Bearer 前缀。

在同一次请求里追加一张图片字段

纯文本跑通后，在同一次请求里追加一张图片。不要新建第二个请求，也不要先上传再替换，先确认它是不是同一请求混送。追加位置通常在 messages 数组里，把 user 的 content 从字符串改成数组，按平台要求加一个图片对象。字段名以实际文档为准，下面是常见形态之一：

{
  "model": "页面显示的模型标识",
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "描述这张图片"},
        {"type": "image_url", "image_url": {"url": "data:image/png;base64,你的base64"}}
      ]
    }
  ]
}

如果文档用 image、input_image 或 file_id，就换成对应字段。运行后有两种结果：被接受时，返回仍然是正常结构，可能出现 multimodal、image_tokens 或类似的 usage 字段；被拒绝时，通常返回 400 或 422，错误信息会指出 content 类型不支持、未知字段或图片格式问题。看到“未知字段”或“不支持的参数类型”，基本可以判断当前接口不接受这种混送方式，下一步应该查是否有单独的图片上传接口或独立的视觉模型标识，而不是继续改业务代码。

对比纯文本与图文混合两种返回结构

纯文本和图文混合各跑一次，把返回并排记录。不要凭感觉判断“差不多”，要按维度对比：

• 返回字段集合：纯文本有 id、model、choices/message、usage；图文混合是否多出图片相关计数或内容块标记。
• 耗时量级：记录从发起请求到收到完整响应的秒级或毫秒级区间，只做同环境下的相对比较，不写成性能结论。
• 错误码形态：纯文本若正常返回 2xx，图文混合返回 400/422，错误信息指向哪个字段。

建议记录成三列表格：请求类型、返回字段（抄字段名）、HTTP 状态码与错误信息。连续跑几次纯文本和图文混合，观察字段集合是否稳定；只在图文混合时出现的字段，往往就是多模态能力的入口或消耗标识。耗时只记量级，比如“明显更长”或“同一数量级”，不要写成具体提升比例。

把失败返回按状态码分类

失败返回不要一律重试。先按状态码分流，每一类只做一个最小改动，改完用同一请求复跑。

分流顺序建议从 401/403 和 404 开始，因为它们会让后续所有判断都不可信；确认鉴权和入口没问题后，再看 400/422 的字段级报错。如果 400/422 在纯文本正常、加图后稳定出现，且错误信息明确指向图片字段，就可以按“当前接口不支持图文同送”做下一步排查，而不是在业务代码里加兜底。