語音 Agent 101：會對話的 AI 背後的架構與延遲挑戰

原始來源與檔名：20260512_2026-05-12T093219+0800-Voice Agents 101 The Architecture Behind AI That Talks Back.md

來源：[[@manthanguptaa]] / X — 2026-05-06 原始檔名：2026-05-12T093219+0800-Voice Agents 101 The Architecture Behind AI That Talks Back.md

NAPKIN | 餐巾紙

餐巾紙公式

Voice Agent = STT + LLM + TTS. Constraint: Total Latency < 800ms. Solution to Latency = Streaming (overlapping stages). Human Conv = Full-Duplex (requires VAD + Barge-in + Echo Cancellation).

當你把文字 Agent 直接接上語音輸入輸出，聽起來就像是在跟 2003 年的衛星電話溝通。這篇文章深入解剖了語音 Agent 的底層架構：從傳統的級聯架構 (Cascade: 語音轉文字 -> LLM -> 文字轉語音) 到新興的端到端語音模型 (End-to-End)。在語音互動中，工程師對抗的最大敵人是「延遲 (Latency)」—回應時間若超過 800 毫秒，對話就會顯得極不自然。要打造流暢體驗，不僅需要即時串流 (Streaming) 技術，還要解決全雙工對話中的「插話打斷 (Barge-in)」、噪音環境辨識以及語音專屬的提示詞工程（嚴禁出現 Markdown）。

一句話

做一個好用的語音 AI，不是把 ChatGPT 接上喇叭這麼簡單。人類講話的延遲容忍度是 500 到 800 毫秒。如果你的系統是等使用者講完、轉成文字、丟給 LLM、拿到回答再轉成語音，那延遲肯定破 2 秒。真正的語音工程，是在 LLM 剛吐出第一個單字時，TTS 就要同步開始發聲 (Streaming)；同時系統還要全時開啟 VAD (語音活動偵測)，只要使用者一插嘴，AI 就要立刻閉嘴 (Barge-in)。語音 Agent 本質上是一個毫秒必爭的「延遲工程學」。

餐巾紙草圖

[ Voice Agent Streaming Architecture ]

User Speaks 
  --> VAD detects end of speech 
  --> STT (Deepgram: ~200ms) 
  --> Transcript hits LLM 
  --> LLM Streams TTFT (Time To First Token: ~400ms)
  --> TTS catches token, buffers 5 words, starts speaking (Cartesia: ~150ms)
  
Total Latency ~750ms.
*Barge-in: If VAD detects user speaking again, immediately KILL TTS stream and restart pipeline.

ROUND 1: SKELETON | 骨架掃描

“這篇文章在說什麼”

• 兩種主要架構:
  • Cascade (級聯): STT (語音轉文字) -> LLM -> TTS (文字轉語音)。優點是可控性極高、元件可替換；缺點是延遲高、會丟失情緒和語調上下文。
  • End-to-End (端到端): 如 GPT-4o Realtime、Moshi。直接語音進、語音出。延遲極低 (200-300ms)，能帶情緒。缺點是難以除錯、工具調用 (Tool calling) 較弱、成本極高。
• 延遲預算 (Latency Budget):
  • 必須壓在 500-800ms 內。
  • 唯一解法是 Streaming (串流)：LLM 逐字輸出，TTS 接收到 5-15 個字元後立刻開始合成發聲，而不是等整句話說完。
• 全雙工 (Full-Duplex) 與打斷 (Barge-in):
  • 半雙工是對講機模式 (一次只能一人說話)。全雙工是人類說話模式 (可插話)。
  • 打斷技術的挑戰：需要極快的 VAD (語音活動偵測) 來分辨是使用者講話還是環境噪音，並且需要回音消除 (Echo Cancellation) 避免 AI 聽到自己的聲音。
• 給語音 LLM 的提示詞:
  • 絕對不要輸出 Markdown、列點、標題。
  • 使用短句、口語化詞彙、縮寫 (I’ll, you’re)。
  • 適當加入填補詞 (“let me think about that for a moment”) 爭取計算時間。
• 未解決的難題: 嘈雜環境辨識、多說話者分離 (Speaker diarization)、超長語音對話的上下文記憶。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

核心論證鏈

1. 文字工程與語音工程是完全不同的領域: 在文字對話中，3 秒鐘的等待時間使用者是可以接受的（看著打字機特效）。但在語音對話中，電話那頭沉默 3 秒，使用者會以為斷線了。因此，語音工程的第一公民是「時間 (Milliseconds)」。
2. 端到端模型目前無法完全取代級聯模型: 雖然 GPT-4o 的語音模式令人驚豔，但在企業級生產環境（客服、業務）中，企業需要絕對的「可觀測性」和「結構化輸出 (JSON)」，這正是端到端語音模型目前的弱項。因此 2026 年的主流架構依然是極致最佳化的 Cascade。

關鍵證據

• 拆解了 Naive pipeline (串列處理，延遲高達 1.95s) 與 Streaming pipeline (管線交疊處理，延遲可降至 500ms 左右) 的具體時序差異。並透過 40 行的 Pipecat 框架程式碼範例，證明現在透過成熟框架整合 WebRTC、VAD 與 LLM，已經變得非常容易。

邊界條件

• 電話網路的物理限制: 如果語音 Agent 部署在傳統 PSTN 電話網路 (如 Twilio) 上，電話網路本身的 Jitter buffer 就會吃掉 150-200ms 的延遲預算。在這種環境下，要達到人類體感的順暢度難度倍增。

ROUND 3: SOUL | 靈魂提取

“還能怎么用”

• 知識連結: 呼應了上一篇早報提到的「Voice AI 何時迎來 Her 時刻」，進一步從技術實作層面解釋了 200 毫秒延遲和全雙工的困難度所在。
• 深層洞見: “A 98% accurate transcription that takes 800ms to produce is often worse than a 95% accurate one that takes 150ms.” 在語音互動中，「速度」本身就是一種「正確性」。一個精確但反應遲鈍的 AI 助理，比一個偶爾聽錯但反應機敏的 AI 更讓人抓狂。這挑戰了傳統 AI 開發者「準確率至上」的信仰。
• 行動呼籲: 如果你正在為公司開發語音客服 Agent，請立即審查你的 System Prompt。如果你沒有在裡面明確寫上「嚴禁使用條列式、Markdown，並請使用自然口語短句回答」，你的 Agent 唸出來的腳本聽起來一定會像是在讀維基百科。將文字輸出「降級」為日常口語，是提升語音 AI 體驗的第一步。