800 毫秒。這就是「一通電話」與「一張客服工單」之間的距離——而且它是一筆要你去工程的預算，不是一個拿來讚嘆的基準。在挑選任何一家供應商之前，這份指南先把預算、自建 vs 購買的數學、以及合規下限講清楚。
打造 AI 語音代理是代理領域中成長最快、同時也是文件記錄最差的一塊。網路上幾乎每一份指南都是廠商教學——Vapi、Retell、LiveKit、Pipecat 各自解釋怎麼用它們的平台——卻沒有一份回答真正決定正式環境成敗的問題：你的端到端延遲預算到底是多少、每分鐘在不同技術堆疊上的成本是多少、以及自建到底會不會贏過購買。
這份指南就是那層中立的東西：元件架構（STT → LLM → TTS），供應商選擇留給你自己；把「感覺好慢」變成試算表的延遲預算數學；可以套用到任何技術堆疊的每分鐘成本模型；以及讓整件事保持合法的合規檢查清單。本系列中的 TTS 與 STT 比較負責供應商選擇；這一篇負責把它們綁在一起的架構。
語音代理到底是什麼
重點：語音代理 = 聊天代理 + 語音 I/O 層——而正式環境的難度不在 LLM，在語音那一層。
把行銷話術剝掉，架構就是一個迴圈裡的三個元件：
Audio in → STT (speech to text) → LLM (decide & respond) → TTS (text to speech) → Audio out
↑ |
└────────────── interruption / barge-in handling ←────────────┘中間的 LLM，就是你聊天產品在用的同一個模型——這部分你已經懂了。讓語音代理變難的是圍繞它的所有東西：即時辨識語音、決定何時回應（話輪轉換，turn-taking）、來電者插話時停止回應、以及把這一切維持在文字介面從不需要達成的延遲預算之內。聊天使用者可以忍受兩秒的等待；來電者會把它解讀成系統壞了。
另一個要及早消滅的誤解：語音代理不是把麥克風硬裝上去的聊天機器人。它是以音訊作為介面的即時系統，需要即時系統該有的紀律——這也正是你已經知道的客服聊天機器人架構依然適用於語音層之上一切事物的原因。
為什麼正式環境的語音 AI 不一樣
重點：三個約束把語音跟其他所有代理工作負載區分開來——延遲、插話、以及每分鐘成本。
- **延遲就是產品本身。**人類對話大約容忍 800ms 的端到端延遲，超過就感覺不對勁；低於 500ms 則感覺自然——業界的經驗法則在 Twig 的延遲預算分析中有完整的記錄。一個 2 秒內回應的文字 API 沒問題；一個 2 秒才回應的語音代理就是壞的。每個元件都在貢獻這個預算，所以每個元件都必須被量測。
- **插話是功能，不是 bug。**Barge-in（插話打斷）——來電者蓋過代理說話——必須讓 TTS 在句子中間停下來、重新啟動 STT 收聽、並重新規劃 LLM 的回應。原生處理這件事的平台值真金白銀；忽略它的實作會做出蓋過客戶說話的代理，而那是通往退款請求最快的路。
- **成本按分鐘算，不是按 token 算。**每一通電話的每一分鐘，語音對話都同時燃燒 STT 秒數、LLM tokens 與 TTS 字元。下面這個每分鐘成本模型，就是你的財務團隊第一個會問的數字。
怎麼選：自建 vs 購買
重點：語音只是功能時就買平台；語音就是產品時就自建技術堆疊——而 2026 年的市場讓兩個選項都便宜了一大截。
平台這一層——Vapi、Retell、LiveKit Agents、Pipecat，還有新進場的玩家——已經成熟為一個真正的選項：代管的電信整合、話輪轉換、barge-in、開箱即用的評估工具，按分鐘計費。2026 年的價格戰讓起步變得真的便宜：xAI 以每分鐘 $0.05 的語音代理建構器進場，直接削價壓過既有平台，而 ElevenLabs 的代理產品從每分鐘 $0.08 左右起跳。如果你的公司需要一條會跟客戶說話的電話線，而且語音只是支援管道、不是產品本身，那就買——平台加價買到的是插話處理與電信整合，這些你自己做的話要花上好幾個月。
當語音是差異化的關鍵時，就自建元件技術堆疊：你需要自訂的話輪轉換、特定的 STT/TTS 供應商組合、on-premise 的資料邊界、或逐元件的成本控制。自建路徑是三個整合，而不是一個平台——更多工作、更多控制，而且量大之後，每分鐘成本可以遠低於平台定價。誠實的中間路線：自建元件、購買管線——在單一 endpoint 後面自己組裝 STT/LLM/TTS，讓一層薄薄的編排層（或乾脆不要）來處理迴圈。
怎麼建：元件技術堆疊
重點：這個技術堆疊是三個可替換的元件，不是一個供應商——各自依其優點挑選，並讓它們保持可替換。
- STT——具備插話感知的串流辨識。目前的世代（AssemblyAI 的 Universal-3-Pro、Deepgram 的 Nova-3，以及其他替代方案）在本系列的 STT 比較中有詳細介紹：代理用 realtime 層級，而且要看 time-to-first-token，不要只看 WER——因為在對話裡，你聽不出來的 WER，比不上你感覺得到的延遲重要。
- LLM——你的聊天產品在用的同一個模型層，加上為真實動作（訂位、查詢、付款）設計的 tool calling，以及為 slot-filling 設計的結構化輸出。這裡沒有什麼語音專屬的東西；你已經在用的 function-calling 模式原封不動地適用。
- TTS——串流輸出，延遲特性要符合你的預算。本系列的 TTS 比較涵蓋了品質與延遲之間的取捨；對代理來說，time-to-first-audio 是選擇標準，自然度排第二。
架構鐵則：每個元件都留在你的統一 endpoint後面——一把 Key、一個共享的計費關係、一個橫跨語音與聊天兩邊的儀表板。統一層是管線的整併，不是供應商的替換。STT 保持供應商原生、TTS 保持供應商原生，而 LLM 依任務路由——便宜的模型處理 slot-filling、前沿模型處理需要拿捏的回答。這就是自訂路由模式套用到對話上的樣子。
關於 realtime API 的議題，說一句：全包的 realtime endpoints 是正當的選項，但不是必要條件。元件式 pipeline——串流 STT、聊天 LLM、串流 TTS——是經過驗證的正式環境架構，供應商彈性更好，而這在某一間供應商重新定價的那一刻就派上用場。音訊 API 文件在同一個 endpoint 上涵蓋了語音的兩個方向。
怎麼達成延遲預算
重點：800ms 預算是技術堆疊的問題，不是模型的問題——為每個元件編預算，並在正式環境量測，不要在 demo 裡量。
端到端預算大約可以拆解成：VAD／話輪偵測（約 100-200ms）→ STT 轉文字時間（約 200-300ms）→ LLM 首個 token 時間（約 200-400ms）→ TTS 首個音訊時間（約 100-200ms）→ 播放。再加上網路跳數，加起來正是「每個元件都很快」不代表「代理很快」的原因。
三個槓桿，依影響力排序：
- **平行處理 pipeline，不要序列。**在 LLM 吐出第一個 chunk 時就開始 TTS 合成，讓回應的其餘部分繼續串流；在 TTS 播放期間就開始 STT 收聽（這正是 barge-in 之所以可行的原因）。序列式實作要付出每個元件的完整延遲；平行式實作只付出最長那條路徑的延遲。
- **全部串流。**串流 STT、串流 LLM 回應、串流 TTS——非串流元件在語音迴圈裡就是預算殺手。
- **依話輪類型分層模型。**Slot-filling 與確認用便宜／快速的層級；複雜推理用前沿層級。層級之間的延遲差異常常比成本差異還大，而兩者都支持分層。
用真實的通話錄音、在正式環境的區域、同時量 P50 與 P95——中位數會藏起真正傷人的那幾通電話。延遲預算是最先要測的東西，不是最後。
要花多少：每分鐘成本
重點：典型的正式環境代理落在每分鐘 $0.02-0.10 的區間，取決於技術堆疊與層級——而隨著 2026 年價格戰持續上演，平台定價與元件定價正在趨同。
每分鐘成本模型，適用於任何技術堆疊：
Cost per minute =
(STT seconds × per-second rate)
+ (LLM tokens × per-token rate, input + output)
+ (TTS characters × per-character rate)用一通 60 秒的通話算給你看：約 40 秒的 STT 音訊、約 300-600 個 LLM tokens、約 100-150 個 TTS 字元。以 2026 年常見的費率，一個分層良好的技術堆疊，元件加起來約每分鐘 $0.02-0.06——而像 Inworld 的成本試算模型這類平台產品、以及 xAI 與 ElevenLabs 每分鐘 $0.05-0.08 的進場價格，都確認了這個區間。差距來自三個地方：由哪個 LLM 層級來處理對話、STT/TTS 跑在 realtime 還是 async 層級、以及你付的是平台加價還是元件費率。
規模化的陷阱：一個客服代理每月處理 10,000 通話分鐘、每分鐘 $0.05，是 $500 的帳單項目——很小。一個銷售代理跑 100,000 分鐘、又用未分層的技術堆疊（每一輪都用前沿 LLM、每一句都用 premium TTS），每分鐘可能貴 3 到 5 倍。分層不是優化；它是「一個功能」與「一個會被 CFO 稽核的帳單項目」之間的差別。
該避免的常見錯誤
重點：四個架構層面的失敗會讓語音代理在正式環境翻船——沒有一個是程式 bug。
- **上線前沒有延遲預算。**demo 在安靜的桌面、快速的網路上跑；正式環境在電話線路上、在 P95 上跑。如果 800ms 的規則沒有寫進你的測試套件，它哪裡都不會成立。
- **忽視 barge-in 與話輪轉換。**蓋過來電者說話、或尷尬地停下來等靜音的代理，會被掛電話。Barge-in 處理是一個必須刻意購買或自建的功能——它永遠不會自己出現。
- **單一供應商綁定。**STT+LLM+TTS 全用一個平台，感覺很方便——直到重新定價或模型下架；而且任何供應商的 rate limits 都可能咬到高流量的代理。讓元件在一個 endpoint 後面保持可替換。
- **沒有成本歸屬。**如果你在月底答不出「這個代理每分鐘、每種通話類型各花多少錢」，你就會在帳單上發現答案——而那是最糟的學習時機。
合規：同意與告知
重點：告知與同意現在是法規要求，不是可選項——FCC 2026 年的 AI 語音通話規則，加上 TCPA/CCPA/GDPR 架構，從第一通電話起就適用於你的代理。
2026 年，AI 語音通話的監管環境變嚴了：美國 FCC 的 AI 語音通話規則疊加在 TCPA 之上，加上針對錄音與資料的 CCPA 和 GDPR——這個組合在通話錄音合規指南與 GDPR 合規框架中有深入的探討。每個部署的務實基本盤：
- 通話開始時告知——在對話展開之前，來電者必須知道他們在跟 AI 說話，而不是人類。
- 錄音要取得同意——在允許錄音的地方，取得明確同意，並與通話資料一起儲存。
- 最小化保留——音訊與逐字稿只保留到業務需求合理為止，並用與其他個人資料相同的流程回應刪除請求。
- 把 pipeline 文件化——每個元件供應商（STT、LLM、TTS）的資料處理條款，都是你合規記錄的一部分，不是事後才想到的補充。
整份檢查清單背後的模式：把每一通語音通話都預設當成個人資料處理。這個假設採用起來零成本，跳過它則要付出一切。
常見問題
語音代理和聊天機器人有什麼差別？
LLM 核心一模一樣——差別在語音 I/O 層：即時 STT/TTS、話輪轉換、barge-in，以及以數百毫秒、而不是秒為單位的延遲預算。上面連結的聊天機器人架構指南涵蓋了語音層之上的一切。
我應該自建還是購買語音代理？
當語音只是支援管道、你的差異化在別處時，買平台（Vapi、Retell、LiveKit、Pipecat，以及每分鐘 $0.05-0.08 的新進場者）。當語音就是產品時，自建元件技術堆疊——自訂的話輪轉換、供應商組合或資料邊界，會讓自建變成正確的選擇。
多少延遲預算可以接受？
端到端低於 800ms 是人類對話的可接受線；低於 500ms 感覺自然。為每個元件編預算——VAD、STT、LLM TTFB、TTS 首個音訊——並在正式環境的區域、以 P95 來執行這個預算，而不是在 demo 桌上。
語音代理每分鐘要花多少錢？
分層良好的元件技術堆疊通常落在每分鐘 $0.02-0.06；平台產品從每分鐘 $0.05-0.08 左右起跳。差距由 LLM 分層、realtime 對比 async 的音訊定價、以及平台加價驅動——這份指南裡的每分鐘模型適用於任何技術堆疊。
打造語音代理需要 realtime API 嗎？
不需要。元件式 pipeline——串流 STT、聊天 LLM、串流 TTS——是經過驗證的正式環境架構，供應商彈性更好，而且當價格或模型變動時，每個元件都保持可替換。Realtime endpoints 是選項，不是必要條件。
通話錄音與告知合規需要什麼？
通話開始時告知、在要求的地方對錄音取得明確同意、最小化保留、以及文件化的供應商資料處理條款——FCC 2026 年的 AI 語音通話規則加上 TCPA/CCPA/GDPR 是框架，而上面連結的 GDPR 指南是基本檢查清單。
總結
2026 年打造 AI 語音代理時，架構是三個可替換的元件——STT、LLM、TTS——由三件事把它們綁在一起：以 800ms 為準的延遲預算、以 $0.02-0.10 為準的每分鐘成本模型、以及從第一通電話就生效的合規層。語音只是功能時就買平台，語音就是產品時就自建元件，讓每個元件都留在統一 endpoint 後面，並把插話處理與告知都當成功能來對待——因為兩者本來就是。
打造最小的、會回話的語音迴圈。取得你的 TokSpan API Key——首次贈送 $5 免費額度——從第一通電話開始，看著每個元件的延遲落在同一個儀表板上。