Voice Agent 架構 2026：Cascaded vs S2S 揀邊個

一句答你：Voice agent 架構主要分兩條路 —— Cascaded（語音辨識 → 語言模型 → 語音合成，三段砌出嚟）同 S2S（speech-to-speech，一個模型直接聽入聲、出聲）；揀邊個取決於你嘅優先次序：要控制力、可觀測性同靈活換零件，揀 Cascaded；要最自然嘅一體化聽感，睇 S2S。2026 年實務上，大部分落地場景仍然係 Cascaded 打底。

「Voice agent」講嘅係一個可以聽人講嘢、理解、再用聲音回應嘅系統 —— 電話客服、語音助手、互動對話機械人都屬呢類。好多團隊一開始就爭論「用邊個模型」，但其實更根本嘅問題係「用邊種架構」。架構揀錯，之後換邊個模型都救唔返。呢篇會由兩種架構講起，拆解各自嘅組件、優劣，再畀一套按場景揀選嘅框架。想先睇粵語語音 agent 嘅整體開發路線，可以睇《AI Agent 粵語語音指南》。

Key Takeaways

• 兩種主流架構：Cascaded（ASR → LLM → TTS 三段）同 S2S（一個模型直接對聲）
• Cascaded 嘅強項係控制力、可觀測性同「逐段換零件」；弱項係多段串接嘅延遲同誤差累積
• S2S 嘅強項係一體化嘅自然聽感同較低嘅流程開銷；弱項係可控性同除錯較難
• 粵語場景幾乎一定要有「粵語原生 TTS」呢一環 —— Cascaded 令呢件事變得可控
• 揀選五個維度：延遲預算、控制力、語言支援、成本、可觀測性
• 任務式（非串流）TTS API 都可以做出即時感：短句切分、預取、快取三招

Voice agent 架構係咩？兩個大類

先講清楚「架構」指咩。一個 voice agent 起碼要處理三個環節：聽（把用戶講嘅聲變文字或意圖）、想（理解同決定回應）、講（把回應變返聲）。架構嘅分別，就在於呢三個環節係「一段段接」定「一體化」。

Cascaded：三段串接

Cascaded（串接式）架構，係將三個環節當三個獨立模組：語音辨識（ASR）→ 語言模型（LLM）→ 語音合成（TTS）。中間傳遞嘅係文字。

S2S：一體化對聲

S2S（speech-to-speech）架構，係用一個模型直接食語音輸入、出語音輸出，中間唔一定要經過明文嘅文字步驟。聽同講喺同一個模型內部完成。

混合：按環節混用

實務上仲有混合路線：例如用 S2S 做前端聽感，但保留一個文字層做記錄同審計；或者 Cascaded 但中間插入語義理解模組。呢篇先集中講兩個極端，最後再講混合。

Cascaded 架構逐段拆解

第一段：ASR（語音辨識）

ASR 負責把用戶嘅語音轉成文字。呢段嘅輸出係成條鏈嘅起點 —— 如果辨識錯，後面 LLM 同 TTS 做得幾好都係建基於錯嘅輸入。所以要特別留意：粵語辨識、中英夾雜、專有名詞（人名、地名、產品名）。

第二段：LLM（語言模型）

文字入到 LLM，負責理解意圖、決定回應內容。呢段係「大腦」。因為輸入輸出都係文字，所以呢段嘅行為最容易測試同監控 —— 你可以直接睇 LLM 收到咩、回咩。

第三段：TTS（語音合成）

LLM 嘅文字回應，交去 TTS 出聲。呢段決定「聽感」—— 語氣、語速、自然度。粵語場景下，呢段幾乎係成敗關鍵：辨識對咗、回應啱咗，但若果把聲唔似香港人講嘢，成個體驗就扣分。

Cascaded 嘅優點

• 逐段控制：每一段都可以單獨調參數、單獨換模型、單獨測試。
• 可觀測性高：中間有文字，任何問題都可以定位到「邊一段出錯」。
• 可換零件：想換更好嘅 ASR？只換第一段。想換聲線？只換第三段。
• 審計友善：有文字記錄，方便合規、客服質檢同後續分析。

Cascaded 嘅限制

• 累積延遲：三段串接，每段都有處理時間，加埋就係整體延遲。
• 誤差累積：第一段辨識錯，會傳導落去。
• 需要協調：三段嘅介面、格式、錯誤處理要自己砌。

S2S 架構逐段拆解

原理

S2S 用一個端到端模型，接收用戶語音、直接輸出回應語音。模型內部同時處理「理解」同「生成」，唔一定要喺中間產生明文文字。

優點

• 一體化聽感：因為聽同講喺同一個模型，語氣銜接可以更自然（例如接住用戶語氣回應）。
• 流程開銷較低：唔使協調三段之間嘅傳遞同格式。
• 低延遲潛力：理論上省卻中間環節嘅傳遞時間。

限制

• 可控性較低：唔容易指定「一定要用邊把聲」「一定要跟某套規則回應」。
• 除錯較難：中間冇明文文字，出問題時較難定位係「聽錯」定「想錯」。
• 語言覆蓋：粵語呢類資源相對少嘅語言，S2S 模型嘅支援程度要逐個確認。
• 審計困難：冇文字中間層，做記錄同合規要另想辦法。

兩種架構對照

呢張表唔係話邊個「好」，而係話兩者嘅取捨位喺邊。

揀邊個？五個維度逐個秤

維度一：延遲預算

你嘅場景容許幾多延遲？電話客服通常希望「回應之間唔好有明顯停頓」；而「查詢類」對話（例如查訂單）用戶容忍度較高。延遲預算愈緊，S2S 嘅一體化優勢愈明顯；但 Cascaded 亦可以透過串流同預取補返。

維度二：控制力

你係咪需要「指定聲線」「遵守特定話術」「跟某套合規句式」？如果要，Cascaded 嘅逐段控制近乎必須。品牌客服（一定要用品牌聲線）、合規場景（一定要有既定回應）都屬呢類。

維度三：語言支援

粵語係關鍵。Cascaded 嘅好處係你可以逐段揀粵語原生嘅組件（尤其係粵語原生 TTS）。S2S 就要逐個模型確認佢嘅粵語表現 —— 唔同模型差距可以好大。呢一點喺粵語場景往往係決定性。

維度四：成本

Cascaded 三段有各自嘅成本（辨識、推理、合成），可以逐段優化同快取；S2S 嘅計費模式唔同，要按實際供應商嘅規格計。成本模型唔同，唔可以直接比單價。

維度五：可觀測性

你要唔要「睇得明發生咩事」？客服質檢、合規審計、模型調優，全部需要中間文字。Cascaded 天生有；S2S 要另建記錄層。呢點喺企業場景好重要。

粵語場景特別考慮

粵語原生 TTS 係 Cascaded 嘅殺手級優勢

Cascaded 架構令「粵語」呢件事變得可控：你可以喺第三段揀一把粵語原生、讀音準確、識中英夾雜嘅聲線。呢個係 S2S 目前較難兼顧嘅位 —— 一體化模型嘅粵語表現要逐個確認。站內《LLM 粵語語音輸出》講嘅正係「令 AI 對答開得聲講廣東話」呢一環。

中英夾雜

香港人講嘢成日中英夾雜。Cascaded 可以分別測試辨識同合成對中英夾雜嘅處理；S2S 就要整體睇。呢個係粵語場景必須專門驗證嘅一項。

語氣詞

粵語嘅語氣詞（喇、囉、啦）係對話嘅靈魂。喺 Cascaded，你可以喺 TTS 呢段專門調；喺 S2S，就靠模型自己。想聽感似香港人，語氣詞處理一定要驗。

任務式 API 點做出即時感

呢度講一個實務重點：唔少 TTS API（包括本站）係 任務式（async）：提交攞 job_id、再輪詢攞音檔 —— 唔係真串流。咁係咪做唔到即時感？做得到，靠三招：

招一：短句切分

唔好等成段回應生成完先播。將回應切成短句（每句一個提交），第一句生成完即播，之後嘅繼續生成。因為提交文字上限係 500 字符，短句切分本身亦符合規格。

招二：預取

喺對話嘅「等待期」（例如用戶仲講緊、或者 LLM 仲想緊）就預先生成可能用嘅固定回應（招呼語、常見問題答案）。到要播嗰陣，音檔已經 ready。

招三：快取

固定內容（選單、招呼語、常見回答）生成一次存起，下次直接攞本地副本，唔使再等生成。呢招同時慳配額。

三招加埋，任務式 API 都可以做出「聽落順」嘅即時感。詳細做法見《即時粵語語音 Agent》。

實作要點

打斷（barge-in）

用戶中途打斷，係語音對話嘅常見情況。架構上要處理「停止播放 + 取消未完成生成」。任務式 API 提供取消任務嘅 endpoint（DELETE），用喺打斷場景好啱。

併發同限流

如果同時處理多通對話，要留意在途任務上限同限流。在途任務上限係免費 3、入門 5、專業 10、工作室 20；限流預設每 key 每分鐘 60 次；讀取類請求（輪詢）唔限流。所以「生成要控併發、輪詢可以放心」係一個實用結論。

輪詢退避

輪詢唔好固定間隔狂問：由短間隔開始、逐步拉長。詳細策略見站內輪詢指南。呢點影響伺服器負載同你自己嘅穩定度。

串接嘅錯誤處理

Cascaded 嘅三段都要有錯誤處理同重試。尤其係 TTS 段，撞到限流要用退避。呢方面站內有專文講重試邏輯同錯誤碼對照。

混合架構：三個實務組合

極端架構少見，實務多數係混用。以下三個組合最常見。

組合一：Cascaded 為主，前端加聽感

三段串接做骨幹，但喺 TTS 段選用自然度高嘅粵語聲線，補返「聽落似真人」嘅感覺。呢個係最穩陣嘅企業組合：保留控制力，同時盡量提升聽感。

組合二：S2S 前端 + 文字記錄層

用一體化模型做即時對話，但另建一層文字記錄（例如自己嗰邊跑一次辨識存底）。適合「聽感優先、但又要審計」嘅場景。代價係多一層工程。

組合三：分工對話

簡單、高頻嘅問題（招呼、常見查詢）用快取好嘅固定回應；複雜、開放式嘅對話先交去 LLM 生成。呢個組合唔關架構事，而係「按問題類型分流」，可以同時降低延遲同成本。

三個組合冇絕對優劣，重點係按你嘅約束（控制、語言、成本、審計）揀。

三個容易忽略嘅實務陷阱

陷阱一：只測「好情況」

好多團隊用清晰、標準嘅語音測試，效果好好；一到真實環境（背景噪音、口音、講得快）就爆。做法係測試稿一定要包含「最差情況」：嘈雜環境、快語速、中英夾雜、專有名詞。

陷阱二：忽略打斷

用戶中途打斷係常態。如果架構冇處理打斷（停止播放 + 取消生成），體驗會即刻變差 —— 用戶講緊嘢，agent 仲喺度播上一句。

陷阱三：冇預算延遲

「感覺快」唔等於「快」。做法係訂立具體延遲預算（例如「用戶講完到出聲頭 1 秒內」），再逐段度。冇預算，就會流於「憑感覺話快」。

呢三個陷阱同架構選擇無直接關係，但往往係「架構揀啱但體驗唔好」嘅真正原因。

決策樹：三步揀架構

1. 有冇硬性「控制」需求？（品牌聲線、合規話術、要文字記錄）→ 有：Cascaded。
2. 語言係咪粵語為主？→ 係：Cascaded 讓你逐段揀粵語原生組件，風險最低。
3. 以上都唔係，而追求最自然聽感？→ 可以評估 S2S，但一定要用自己嘅真實對話稿實測。

三步唔使複雜：控制同語言兩項通常已經拍板。淨係「純聽感優先、場景簡單」嘅情況，先值得認真評估 S2S。

常見問題 FAQ

Cascaded 一定比 S2S 延遲高嗎？

唔一定。Cascaded 有三段處理，但可以透過串流（邊生成邊播）、預取同快取大幅改善聽感；S2S 省咗中間環節，但實際延遲取決於模型同部署。所以唔應該用「架構種類」直接推斷延遲，要用真實場景實測。

我唔識語音技術，可以點起步？

由 Cascaded 起步。因為三段可以逐段試：先揀粵語 TTS 聲線（去 playground 試聽）、再處理 LLM 文字回應、最後砌 ASR。每段獨立驗證，比一次過搞一體化模型易好多。

2026 年係咪應該直接用 S2S？

唔係「一定」。S2S 嘅聽感潛力吸引，但控制力、可觀測性同粵語覆蓋要逐項確認。實務上好多落地場景（尤其企業客服、合規要求高嘅）仍然係 Cascaded 打底。趨勢係兩者互相靠近（Cascaded 加自然度、S2S 加可控性），而唔係一邊取代另一邊。

Cascaded 中間嘅文字層會唔會影響私隱？

會涉及，所以要做保障。中間文字（用戶講嘅內容）屬個人資料，要跟《私隱條例》處理同考慮保留期限。呢方面可以睇站內關於語音 AI 合規嘅文章。反過來講，Cascaded 有文字層，令「記錄同刪除」都有得做，係可控性好處之一。

可唔可以一半 Cascaded 一半 S2S？

可以，混合架構係實務選項。例如用 S2S 做前端聽感，另存一份文字記錄做審計；或者 Cascaded 為主，個別環節用一體化模型。重點係清楚每個環節嘅職責同記錄方式。

揀好架構之後，第一個要驗嘅係咩？

粵語讀音同聽感。因為呢項最難補救、又最直接影響用戶。做法係攞你嘅真稿（有人名、地名、中英夾雜嘅實際對話）去試，唔好用架空例句。詳見《粵語語音 Agent 開發全攻略》。

任務式 API 做對話，會唔會好慢？

唔會，如果做好短句切分、預取同快取。而且任務式 API 有實際好處：唔使 hold 住長連線、易做併發控制、易做快取。對「查詢類」對話（延遲容忍度高少少）嚟講，係一個穩陣選擇。

[!CTA]

起你嘅第一個粵語 voice agent

Cascaded 打底最穩：開戶即享每月 5,000 字符，先去 playground 揀一把粵語原生聲線、跑通「文字→出聲」呢一段。去 港嘢 Playground 開始。