構建語音控制型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）要在用户插話時快速取消當前音頻播放、回到監聽狀態；工具調用則要把函數決策放進延遲預算，必要時通過對話補充缺失參數，而不是讓用户重複輸入或等待。只有把這些編排問題一起解決，語音代理才真正談得上「可對話」。