構建語音控制型AI代理

很多人以為構建語音代理就是把三件事接起來：語音轉文字（STT）、大語言模型（LLM）和文字轉語音（TTS）。按這個思路，使用者說完話後，STT 先轉寫出完整文本，LLM 再生成完整回覆，TTS 最後播放完整音訊。這是最簡單的順序式架構，但它不是 2026 年生產級系統的標準，因為每一級都在空等前一級完全結束，延遲層層疊加，無法帶來真實的對話感。

真正難的不是提示詞，也不是模型，而是編排。語音本質上是一個話輪切換問題，而不是轉寫問題。流式語音識別、語義級結束檢測、流式生成、打斷處理，以及語音約束下的工具呼叫，這些環節共同決定了系統是像真人對話，還是像一棵掛了聊天機器人的電話樹。

生產系統普遍採用流式模式：STT 把部分轉寫持續送給 LLM，LLM 把 token 流式交給 TTS，TTS 在 LLM 還在生成後文時就能播放第一句。這樣能顯著降低感知延遲，但對打斷、緩衝和部分狀態的處理要求更高。人跟人對話時，兩個說話人之間的自然間隔約為 200 到 300 毫秒。超過 500 毫秒就會讓人明顯覺得慢，超過 3 秒多數使用者會失去耐心甚至認為系統已經卡死。當前主流廠商的 speech-to-speech 系統首 Token 時間大多在 0.8 到 3 秒之間，所以架構選擇本身，就已經決定了你的代理落在「自然」還是「被結束通話」區間。

流式語音識別的第一項職責，不是“轉寫這段音訊檔案”，而是邊接收音訊邊輸出轉寫，並在確信使用者說完後發出訊號。生產級 STT 通常基於常駐 WebSocket 連線，音訊按約 50ms 的小塊傳送，返回的是連續事件：先是一些 PARTIAL 事件，內容隨新音訊不斷修正，最後出現一個不會再變的 FINAL 事件。下游邏輯只應該基於 FINAL 事件執行，PARTIAL 事件僅用於即時展示。實體資訊的準確率至關重要——訂單號、電話號碼、專有名詞只要聽錯一個數字，後續函式查詢就會失敗，而真人接線員本來可以透過確認來避免。

話輪檢測是一個獨立的元件，它不看轉寫文本，而是看音訊流裡的靜音模式。它要回答的問題是：使用者到底說完了沒有？如果太急，就會打斷對方思考中的停頓；如果太慢，每輪對話都會拖著尷尬的沉默。生產系統通常用兩個數字來控制：最小靜音時長，常見為 600ms，只有轉寫端也認為這句話語義完整時才結束話輪；最大靜音上限，常見為 1500ms，即使句子聽起來還不完整，也強制觸發回應。面向老人護理、醫療等語速較慢的場景，可以把上限提高到 2500ms；而快節奏對話場景則可以把下限降到 300ms。這是一個可根據業務場景調整的策略，不是寫死在架構裡的常量。

除了上述環節，流式生成、打斷處理和語音約束下的工具呼叫同樣重要。LLM 生成回覆時應把 token 持續送向 TTS，而不是等整段結束；打斷處理（barge-in）要在使用者插話時快速取消當前音訊播放、回到監聽狀態；工具呼叫則要把函式決策放進延遲預算，必要時透過對話補充缺失引數，而不是讓使用者重複輸入或等待。只有把這些編排問題一起解決，語音代理才真正談得上「可對話」。