speech-recognition 實戰：讓 Agent 聽懂人話，不只是語音轉文字

為什麼你需要這個技能

事情是這樣的。上週五下午，Franky在車裡發了條語音訊息到工作群：「把下週要發的文章清單列給我。」

正常情況下，這條訊息會沉在群裡沒人管。但有了 speech-recognition 技能之後，事情變成了這樣：

語音訊息 → 自動轉文字 → Agent 識別意圖 → 從 CMS 拉取排程 → 回覆列表。

全程 4 秒。Franky 連車都沒停。

這就是 speech-recognition 技能在 OpenClaw 裡的真實價值——不是「把語音變成文字」這麼簡單，而是讓 Agent 能回應語音輸入，打通人機互動的最後一道障礙。

安裝和基礎設定

安裝很簡單，一行命令搞定：

clawhub install speech-recognition

安裝完之後，在 OpenClaw 的設定檔裡加上：

skills:
  speech-recognition:
    provider: whisper
    model: base
    language: auto

這裡有個關鍵選擇：用本地 Whisper 還是雲端 API？

我的建議很直接：如果你跑的是中文語音，用 large-v3 模型。base 模型對中文的識別率大概只有 65%，large-v3 能到 93% 以上。代價是記憶體佔用——large-v3 需要大約 3GB 顯示記憶體/記憶體。我們的 MS01 伺服器跑 large-v3 毫無壓力，但如果你的機器比較老，small 模型是個折衷方案。

實戰場景：語音訊息自動處理

這是我們目前在 SFD 實驗室的真實用法。

OpenClaw 的 Telegram bot 收到語音訊息後，speech-recognition 技能會自動攔截，把語音轉成文字，然後交給 Agent 的決策層處理。

細節一：音訊格式轉換。Telegram 發來的語音是 OGG 格式，Whisper 原生支援 OGG，但如果你用的是其他平台（比如微信、Slack），可能需要先轉成 WAV 或 MP3。我們在 skill 裡加了一個格式檢測層，自動判斷是否需要 ffmpeg 轉換。

細節二：長音訊分段處理。Whisper 對單段音訊的長度有限制。超過 30 秒的語音，我們自動切成 25 秒的片段分別識別，再把結果拼接。拼接的時候要注意——Whisper 的每段輸出開頭可能有重複詞，需要做一個去重處理。

細節三：說話人區分。如果一段語音裡有多個人說話，Whisper 本身做不了說話人分離。我們的方案是結合 pyannote.audio 做說話人標記，但這會顯著增加處理時間。

踩坑記錄

說三個真實踩過的坑：

坑一：背景噪音吃掉識別率。有次 Franky 在咖啡廳發語音，識別率直接掉到 40%。解決方案是在 skill 設定裡加一個降噪預處理步驟。加了降噪之後識別率從 40% 回到 85%。

坑二：中英混合語音識別混亂。這是中文使用者最常見的場景——一句話裡夾雜著英文術語。Whisper large-v3 對中英混說的支援還不錯，但有一個技巧：在 prompt 參數裡指定主語言。

坑三：記憶體泄漏。如果你用的是本地 Whisper 模型並且高頻處理語音，注意模型載入後不要每次都重新初始化。我們把模型實例做成了全域性單例，只在啟動時載入一次。

和 edge-tts 的組合拳

speech-recognition + edge-tts 是我們最常用的組合。speech-recognition 負責「聽」，edge-tts 負責「說」。兩個技能配合起來，Agent 就有了完整的語音互動能力。

和 smart-web-scraper 的配合

另一個實用組合：語音指令 + 網頁抓取。比如你說「幫我查一下今天GitHub上 trending 的 Python 專案」，speech-recognition 轉文字後，Agent 呼叫 smart-web-scraper 去抓取 GitHub Trending 頁面，然後把結果回傳給你。

這種「語音指令 → 自動執行 → 回傳結果」的模式，才是語音識別技能真正發揮價值的地方。

SFD 編者註

今天測試 speech-recognition 的時候，小鸚鵡在旁邊說了一句話：「如果 Agent 能聽懂語音，那它算不算有了耳朵？」

我想了想，回答：「不算。耳朵只是硬體，聽懂才是關鍵。Whisper 強就強在它真的『理解』語音的語意，而不只是機械地把聲波轉成文字。」