先找音频文件
会先抓到第一份音频附件，必要时先下载到本地。
Nodes 导读
音频转文字：先配模型，再设权限，最后调回退
OpenClaw 自动检测音频模型顺序：回复模型 → 本地 CLI → Gemini → 提供商。若不想自动，手动配置 `tools.media.audio.models` 并注意 CLI 必须在 PATH 上。最易错的是 `maxBytes` 限制和回退逻辑——第一个模型失败或超时才会用下一个。
先讲这一页到底在解决什么
音频转文字：先配模型，再设权限，最后调回退
OpenClaw 自动检测音频模型顺序：回复模型 → 本地 CLI → Gemini → 提供商。若不想自动，手动配置 `tools.media.audio.models` 并注意 CLI 必须在 PATH 上。最易错的是 `maxBytes` 限制和回退逻辑——第一个模型失败或超时才会用下一个。
第一站
🪜 它的工作顺序很像“先试第一位听写员，不行就换下一位”
这页真正的主角不是某一个模型，而是回退顺序。
检查大小
超过 maxBytes 的候选人会先跳过，别把大包裹硬塞给它。
按顺序试模型
一个失败、超时、跳过，就换下一个 provider 或 CLI。
成功后替换正文
转写成功就把 Body 换成音频块，并塞入 {{Transcript}}。
第二站
🤖 auto-detection 像自动找最近能上岗的听写员
你不手工配置时，系统会先自己找本地 CLI，再找 Gemini CLI，再找 provider key。
本地 CLI
像先找办公室里现成的 Whisper、sherpa 这类本地听写员，不必先出门联网求助。
Gemini CLI
这是第二站，像请另一位外援看本地文件内容。
Provider keys
再往后才轮到 OpenAI、Groq、Deepgram、Google 这些外部服务。
tools.media.audio.enabled: false这句像把自动听写开关彻底关掉，谁也别来自动帮忙转写。
第三站
🛠️ 配置 models 列表，本质上是在给听写员排班
你可以让 OpenAI 先上，再让 whisper CLI 兜底，也可以反过来。
Provider-only
纯 provider 配置像“全部交给云端听写员”。
CLI fallback
把 CLI 放后面，就是“云端不行时，退回本地救场”。
Scope gating
还能限制哪些聊天类型允许转写，比如群聊里别自动偷听。
🎈 最后记一句
Audio 这页讲的不是一个模型，而是一整条“谁先听、谁兜底、听完后怎么改写正文”的流水线。