OpenClaw 接 Groq 做音频转写时，可能报错：request Content-Type isn't multipart/form-data

最新一条 OpenClaw 问题显示：即便整条语音消息链路基本是通的，Groq 这一路的音频转写仍可能单独失败。

报错非常具体：

invalid_request_error: request Content-Type isn't multipart/form-data

这点很关键，因为 Groq 的 Speech-to-Text 接口要求直接上传文件或提供音频 URL；如果走的是文件上传，HTTP 请求本身就必须是正确的 multipart form data。只要上传编码不对，Groq 会在真正转写开始前就先拒绝请求。

来源：

OpenClaw issue： openclaw/openclaw#62605
Groq 官方文档： Groq Docs — Speech to Text

实际坏在什么位置

按 issue 描述，故障路径大致是这样的：

Telegram 正常收到语音消息
OpenClaw 把音频交给 tools.media.audio
转写 provider 配成 Groq
Groq 直接返回 request Content-Type isn't multipart/form-data

最重要的对照信息是：同一批 Telegram 语音消息，切到 Deepgram 可以正常转写。

这会大幅缩小排查范围。它更不像：

Telegram 收消息本身有问题
用户发来的语音文件坏了
OpenClaw 整体音频接入都坏了

更像是 Groq 这条转写请求在发出时就组装错了。

为什么这类问题不能当“小毛病”看

如果你把语音消息当成正式输入面，这不是一个可以忽略的提示。

它的实际伤害在于：系统会呈现出一种“半通不通”的状态：

聊天渠道看起来正常
语音消息也送达了
换个 provider 还能成功
但 Groq 路径会在请求阶段直接失败

这种故障最容易把运维和使用者都带偏，误以为是 Telegram 波动，或者误以为是个别音频文件问题。

为什么它更像请求格式错误，而不是通用 provider 故障

这条 issue 至少给了三个很强的信号。

1）同一条 Telegram 语音，Deepgram 可以工作

如果同样的输入对象，在另一个 provider 上能跑通，那问题大概率不在语音输入本身。

2）报错指向的是 HTTP 请求形态，不是模型推理质量

Groq 不是说模型不可用，也不是说识别结果差，而是直接指出上传请求的 Content-Type 不符合预期。

3）Groq 官方文档明确把文件上传视作 file-or-URL 的接口

Groq 的 Speech-to-Text 文档里明确列出 file 参数用于直传文件。实际落地时，这意味着上传请求必须是正确的 multipart 编码；如果被错误地包装成 JSON，或者表单边界没带对，就很容易触发 issue 里的同类报错。

怎么判断自己命中的就是这一个问题

如果下面多数条件同时成立，就很像：

你已经在 tools.media.audio 里开启了音频转写
当前转写 provider 是 Groq
Telegram 语音消息能正常进入系统
把 provider 切成 Deepgram 后，转写恢复正常
Groq 日志里出现：

invalid_request_error: request Content-Type isn't multipart/form-data

这比一句笼统的“音频转写坏了”要具体得多。

这事一开始不太像什么

基于当前 issue，先别急着朝这些方向浪费时间：

Telegram webhook / polling 异常
Telegram 语音格式不被支持
单纯是 Groq 模型名填错
用户端麦克风有问题
转写成功了但渲染阶段没显示

更像的失败点是：Groq 在接收到请求时，就认定上传格式不合法，因此根本没有进入真正的转写阶段。

现在最实用的止血方案

报告里已经给了一个很直接的现实结论：同样环境下，Deepgram 能工作。

所以如果你的语音转写是生产关键路径，短期最稳的做法是：

先把 Groq 移出主转写路径
让 Deepgram 承担当前在线转写
等上游确认 Groq 上传请求格式修正后，再切回测试

这不优雅，但它能最快恢复用户层面的可用性。

维护者大概率需要检查哪里

这个问题的修复方向其实比较具体。

维护者大概率需要确认 Groq 转写集成是否真的做到了：

文件上传时构造了真实的 multipart form body
Content-Type 与 boundary 正确匹配
没有把音频上传请求误序列化成 JSON 或别的非上传格式
Telegram 语音消息输入与其他音频输入走的是同一套被支持的上传逻辑

因为报错非常明确，这类问题理论上应该能用一个小型 provider 级集成测试稳定复现。

如果你要继续升级提单，建议顺手带上的信息

如果你准备补充 issue 或内部转交，建议把下面这些一起收集：

OpenClaw 版本
Groq 用的转写模型
同样语音在 Deepgram 下是否能成功
Groq 返回的完整错误文本
部署里是否还挂了自定义代理层
脱敏后的 tools.media.audio 配置块

这样能更快把它和其他“音频转写失败”类问题区分开。

结论

如果你在 OpenClaw 里使用 Groq 做音频转写，结果报出 request Content-Type isn't multipart/form-data，先别把整条语音链路都判死。

当前报告更像是在说明一件更窄、但也更关键的事：OpenClaw 发往 Groq 的转写上传请求格式可能不对，所以请求在进入真正转写前就被拒绝了；而同一条语音在 Deepgram 这类 provider 上仍可能正常工作。