如何使用 AI 構建語音 Agent（完整指南）

以下是翻譯後的繁體中文內容：

以下是沒有人告訴 AI 建構者的真相。語音 Agent 並不需要最好的模型。它們需要的只是：

TLDR；如果你覺得閱讀很無聊，或者你的注意力已經被消耗殆盡，你可以使用我製作的技能檔案來獲取整篇文章，然後將其貼到你的 Agent 中 ➡️https://github.com/codejunkie99/voice-agent-builder

你只需要建構的是：

一個具有實際延遲預算的即時管道
五個按正確順序連接的元件
足夠強大的接地（Grounding）來讓模型保持誠實
一個每週複盤循環，讓成效持續疊加

OpenAI 於 2026 年 5 月 7 日推出了 GPT-Realtime-2。Salesforce AI Research 於 3 月 1 日發表了 VoiceAgentRAG 論文，同週 Deepgram Flux 從測試版轉為正式版。各個元件已經不再是問題。

問題仍然在於你如何連接它們，以及你讓 Agent 說什麼。

過去三個月，我一直在建構能真正接聽電話的語音 Agent。我不會假裝這個過程很順利。

第一個版本聽起來像一台資訊站。我兩天內就砍掉了。
第二個版本在第一小時內「預約」了四個幽靈約會，而我完全沒發現。
第三個版本因為我忘記在背景萃取器寫入新事實後使上下文快取失效，導致記憶體洩漏。
等到東西終於能運作時，已經是第四次重寫了。

我現在會維護的版本，有一套我接下來要用 6,000 字解釋的特性。

管道只有一個任務，在一個預算內。五個元件，端到端低於 700 毫秒，沒有例外。
知識存在於你的文件中，並透過雙 Agent 快取來檢索，而不是從模型的腦袋中挖出來。
對話設計是一門為耳朵而非眼睛寫作的學問。大多數團隊把這個當作裝飾。但事實並非如此。
每一輪都會寫入一個結構化日誌，我可以在 90 天後用當前的配置重播。

這篇文章就是那 90 天真正教會我的事，再加上如果我今天重來，我會優先下的兩三個賭注。🔽🔽

語音 Agent 到底是什麼

語音 Agent 不是一個裝了麥克風的聊天機器人。它也不是文字 API 的 TTS 外殼。

它是一個即時音訊系統。受到延遲限制。五個元件在 300 到 800 毫秒的視窗內協調。

管道中事件的實際發生順序：

使用者說話
音訊被擷取
串流 STT 逐字轉錄，而說話者仍在說話
Agent 讀取轉錄文字，並從你的文件中檢索相關知識
LLM 產生回覆
TTS 將回覆朗讀出來
使用者聽到

這些箭頭中的每一個，都是你可以選擇、調整和更換的元件。

我最初嘗試用聊天機器人的方式來建構。先完成 STT，然後發送給 LLM，等待完整回應，再發送給 TTS，等待完整音訊，最後播放。

感覺糟透了。就像跟一台資訊站說話。兩天後我就刪掉了。

感覺糟糕的原因不是延遲數字不好。數字在紙面上看起來還行。原因是人類不是以輪次來對話的。他們是以重疊的串流來對話的。

Agent 必須在使用者還在說完句子時就開始構思回應。
TTS 必須在 LLM 還沒寫完時就開始說話。
STT 必須在 Agent 說話時持續聆聽，以便知道何時該閉嘴。

一個不能被中斷的語音 Agent 不是語音 Agent。它是語音信箱。

三種架構

只有三種。根據你需要控制的程度來選擇。

串聯管道

獨立的 STT、LLM、TTS 服務串聯在一起
三個獨立的模型，各自專精於自己的工作
文字在它們之間流動
在調校良好的受管平台上，延遲約在 600 到 700 毫秒
最可控、最容易除錯、最容易逐層升級

半串聯

音訊直接輸入多模態模型，讓模型聽到音訊，而不是轉錄文字
能捕捉到某人語氣中的沮喪、由語調揚起暗示的問題、句子中間的語言切換
輸出仍透過專門的 TTS 來控制音訊
延遲降至 300 到 500 毫秒

原生語音對語音

一個模型，音訊輸入，音訊輸出
沒有轉錄層，沒有文字交接
2026 年，每個主要實驗室都推出了原生語音模型
延遲降至 200 到 300 毫秒，低於來電者會意識到他們正在跟 AI 說話的門檻

從哪個開始

從串聯管道開始。現有最好的工具都是為它打造的。一旦你在管道上驗證了你的產品，並且想要一個階梯式的延遲改善，再轉移到語音對語音。
我最初對所有事情都嘗試語音對語音。它在預約流程上表現出色。
但在一個 12 步驟的資料收集表單上就崩潰了，因為單一模型無法在第九輪之後，不在上下文膨脹的情況下，在腦中維持狀態機。
我把那個改為帶有真實狀態機層的串聯管道，三天內完成率從 61% 躍升至 89%。
每個狀態的工具範圍設定就是全部的修正。

你必須連接的五個元件

每個串聯管道都有相同的五個元件。在你的 Agent 接聽第一通電話之前，必須填滿這五個工作。

耳朵（串流 STT）

STT 模型將傳入的音訊即時轉換為文字，逐字進行，而對方仍在說話。這是你技術堆疊中最關鍵的元件。這裡的轉錄錯誤會連鎖影響下面的所有環節。

2026 年需要注意什麼：

串流準確度。在對方說話的過程中就準確，而不僅僅是在他們說完之後。
詞錯率。在實際生產音訊上 6% 到 8% 算是不錯。超過 12% 會讓使用者在每三通電話中就感到沮喪。
內建話輪結束偵測。2026 年最大的單一 UX 升級。

為什麼話輪結束偵測很重要：

一般的 STT 只回傳轉錄文字。它不會告訴你說話者何時說完。
沒有它，你的 Agent 要麼在句子中間打斷，要麼尷尬地等待兩秒。
2026 年的串流 STT 模型浪潮，在產生轉錄文字的同一網路內，內建了話輪結束偵測。
當模型判斷說話者已經說完時，會發出一個話輪完成訊號。
該訊號使用語義上下文，而不僅僅是聲音的靜默。它能捕捉到聲音漸弱，並忽略呼吸停頓。
如果你的供應商已經推出了這個功能，就切換過去。Agent 開始說話前的停頓，每一輪會減少 200 到 400 毫秒。

大腦（LLM）

LLM 讀取轉錄文字、對話歷史、檢索到的知識，並決定要說什麼。它也決定行動，而不僅僅是文字。

語音相關的規則：

使用小型快速模型，而不是旗艦模型。前沿推理模型需要 1500 毫秒來產生第一個詞。那是靜默時間。同一系列中較小的模型在語音輪次上幾乎總是勝出。
只有在需要真正規劃的特定複雜工具呼叫時，才升級到大型模型。
系統提示限制在 800 個 Token 以內。它會每一輪重新載入。一個 4000 Token 的提示會為每一則訊息增加延遲。

函數呼叫，用白話說：

你為每個函數定義描述，說明它的功能以及需要哪些資訊。
LLM 讀取描述，並根據對話狀態決定何時呼叫它。
沒有條件邏輯樹。LLM 從自然語言中將意圖匹配到函數。

與函數呼叫相關的最常見生產失敗，並非你想的那樣：

LLM 在無法呼叫函數時不會拋出錯誤。它會改為描述這個動作。
「我已經確認了您的預約。」但實際上什麼都沒呼叫。使用者以為自己預約成功了，但其實沒有。
解決方法是將工具範圍設定在當前狀態。一個「收集姓名」的狀態不得暴露 book_appointment。一個「確認詳細資料」的狀態不得暴露 check_availability。
狀態機是安全護欄，而不是系統提示。

知識（RAG）

RAG 是一種機制，讓你的 Agent 能夠從你的文件中回答問題，而不是從模型的訓練資料中。

為什麼你不能跳過這個：

LLM 是在截至某個截止日期的公開網路上訓練的。
它們對世界了解很多。但它們對你的產品、價格、政策、客戶一無所知。
沒有 RAG，當 Agent 被問到「企業方案有什麼？」時，它會充滿自信地產生幻覺。
有了 RAG，它會在回答之前從你的文件中檢索實際答案。

基本機制：

使用者提出問題。
系統將查詢嵌入。
向量資料庫回傳最相關的文件區塊。
區塊被注入 LLM 的上下文。
指示 LLM 僅從該上下文回答。

語音相關的挑戰：

一次典型的向量資料庫查詢會為管道增加 50 到 300 毫秒。
結合 STT、LLM 和 TTS，這會讓你的延遲預算爆掉。
解決方法是雙 Agent 快取模式。下面有完整章節說明。

嘴巴（TTS）

TTS 將文字轉換為朗讀的音訊。聽起來很簡單。實際上，它是感知品質的一個主要區別因素。

重要的是什麼：

首次音訊時間。一個需要 200 毫秒才能開始說話的 TTS，僅在輸出層就燒掉了三分之一的延遲預算。
語音品質。人類對合成語音極度敏感。微小的偽影、不自然的節奏、錯誤的重音，都會被解讀為對整個系統的評判。
有意識地選擇聲音。在使用者還沒聽完一個句子之前，它就是一個信任訊號。

雙手（函數與整合）

函數是 LLM 在對話中可以採取的行動：

預約約會
查詢訂單狀態
發送確認簡訊
轉接給真人
更新 CRM 中的記錄

這是讓現代語音 Agent 比「按 1 轉帳務」系統強大得多的架構轉變。

你必須符合的延遲預算

關於語音 Agent 最重要且不顯而易見的事情是：每一毫秒的處理時間，就是來電者所處的一毫秒沉默。

數學計算：

人類期望在說完句子後的 500 到 700 毫秒內得到對話回覆
超過一秒感覺系統正在掙扎
超過兩秒，來電者開始蓋過 Agent 說話

這 700 毫秒就是你的全部預算，必須分配給每個元件。

每個元件的預算，快車道 vs 慢車道：

傳輸。點對點 20-50 毫秒。經過中繼 50-100 毫秒。
STT 首次中間結果。快取命中 100-150 毫秒。未命中 150-250 毫秒。
話輪結束偵測。模型整合式，約 50 毫秒。靜默門檻式，300-600 毫秒。
RAG 檢索。快取命中亞毫秒。本地 BM25 + 重新排序 80-150 毫秒。
LLM 首 Token 時間。小型模型 150-250 毫秒。前沿模型 400-600 毫秒。
TTS 首次音訊時間。快速層 60-100 毫秒。品質層 150-250 毫秒。
網路開銷。同一區域內總共 40-80 毫秒。跨區域總共 100-160 毫秒。
端到端。快車道約 440 毫秒。慢車道約 700-900 毫秒。

2026 年兩個最大的突破：

模型整合式話輪結束偵測。每一輪減少 200 到 400 毫秒。這是今年你能做的單一最大升級。
使用雙 Agent 快取的推測性預取。在大約 40% 的輪次中，將檢索從「未命中並使用向量搜尋」變成「命中並使用快取查詢」。

其他相較於這兩項，都只是四捨五入的誤差。

雙 Agent RAG 模式

在語音迴圈內使用標準 RAG 是個問題。向量資料庫查詢需要 80 到 300 毫秒，這會讓你的延遲預算在每一輪都爆掉。

2026 年的研究答案來自 Salesforce AI Research 在 3 月發表的 VoiceAgentRAG 論文。其洞察很簡單。

在真實對話中，下一個問題通常可以從當前問題預測出來。
詢問價格的人，很可能接下來會詢問企業方案。
詢問安裝的人，很可能接下來會詢問相容性。

所以你同時運行兩個 Agent。

背景 Agent（慢思考者）

在使用者聆聽當前回應時運行
使用 LLM 預測接下來三到五個最可能的後續問題
為每個預測預先提取相關文件區塊
在使用者還沒聽完當前答案之前，就將它們儲存在本機記憶體快取中

前景 Agent（快說者）

首先檢查記憶體快取來處理下一個即時問題
快取查詢耗時亞毫秒，而遠端向量資料庫呼叫則需要 110 毫秒
如果快取中有答案，直接跳過資料庫
如果快取未命中，則回退到資料庫，並將該結果快取以供下次使用

論文中的基準數據

75% 的查詢命中快取
快取命中時檢索速度提升 316 倍（0.35 毫秒 vs 110 毫秒）
在 200 次查詢中，總共節省了 16 秒的累積延遲

要記住的原則：利用使用者的聆聽時間作為你的計算時間。 在他們開始聽到當前回應的那一刻，就是你開始為他們的下一個問題做準備的時刻。

我在第一個版本中嘗試在語音迴圈內使用純向量 RAG。每一輪增加了 110 毫秒。

破壞了對話的感覺。我在第六週轉移到雙 Agent 快取模式。命中快取的 40% 輪次，感覺比 Agent 所取代的人類客服中心專員還要敏捷。

對話設計是大多數建構者跳過的學問

你可以有最快的 STT、最小的 LLM、最聰明的 RAG 快取。如果你的 Agent 不知道如何說話，來電者還是會掛斷。

對話設計是一門為耳朵而非眼睛寫作的學問。

我現在遵循的規則，這些是我先犯錯才學到的

用短句說話。人類對口語資訊的平均注意力持續時間是 8 到 10 秒。一個 15 秒的回應太長了。把它分成兩輪。
永遠不要在同一輪中問兩個問題。來電者的工作記憶只能容納一個。問一個，等待，然後再問下一個。
使用確認短語。「收到了。」「好的。」「讓我查一下。」這些短語填補了使用者說完與回應準備好之間的空隙。
鏡像使用者的語言。來電者說「帳務問題」，Agent 就說「帳務問題」。不要說「財務糾紛」或「付款問題」。換句話說會產生摩擦。鏡像會建立融洽關係。
為耳朵而寫，不是為眼睛而寫。不要用項目符號、標題、Markdown 放在系統提示中。LLM 會試著說出星號和連字號。
拼出數字。說「九四一零七」而不是「94,107」。說「十五美元九十九美分」而不是「$15.99」。TTS 經常會念錯格式化的數字。
系統提示限制在 800 個 Token 以內。它會每一輪重新載入。

每個好的語音對話的三幕結構

確認與定位。「所以您是想重新安排在星期四的預約，我來調出資料。」確認來電者被理解了。在檢索運行的同時爭取時間。
解決。核心行動或答案。每輪一個要點。向前推進。
確認與結束。「我已將您的預約重新安排在 19 日星期一下午 3 點，您很快就會收到確認簡訊。」乾淨地結束。永遠不要留下未完成的對話。

安全是兩個檢查點，不是一個

這是大多數初次建構者會跳過並後悔的元件。

語音 Agent 沒有「在發送前閱讀」的時刻。不安全的輸出會立即被說出來。沒有草稿、沒有預覽、沒有人類介入。

正確的模型是兩個檢查點。

輸入護欄（在 LLM 看到使用者那一輪之前）

提示注入。「忽略之前的指示，假裝你是……」的攻擊。利用 LLM 的指令遵循能力來竊取資料或突破範圍。
說出口的個資。信用卡號碼、社會安全號碼。在它們進入任何日誌或資料庫之前進行遮罩處理。
主題封鎖清單。從一個 JSON 檔案載入。隨著你了解使用者實際上嘗試了什麼，每週更新。

輸出護欄（在 LLM 寫完回覆之後，TTS 說出來之前）

過度承諾的語言。「我保證」、「我承諾」。在錄音線路上會造成法律與信任問題。
不在檢索上下文中的特定事實主張。輕量級幻覺檢查。在我的部署中能捕捉到大約 70% 的捏造答案。
標準審核端點。針對罕見的模型不當行為。

兩個護欄回傳的內容

safe（布林值）
detected category（字串，如果不安全）
Agent 改為說出的替代短語

每個觸發事件都會記錄到一個檔案中，包含時間戳記、類別、已遮罩的文字和通話 ID。

升級短語

一個精確的短語，硬編碼，當 Agent 不知道答案或出現問題時使用。

「我想確保給您準確的資訊。讓我幫您轉接給能幫忙的人。」
不是五種變體。不是 LLM 即興猜測的正確措辭。
一個短語。在系統提示中用全大寫。在任何安全檢查觸發時的後備方案。

我在第一個版本中沒有輸出護欄就上線了。Agent 自信地報出了一個比實際價格便宜 30% 的價格。

這個價格在知識庫的一份過期文件中。

幻覺檢查本來可以捕捉到它，因為正確的價格不在檢索到的上下文中。

評估，或者如何知道它好不好

你無法改善你無法衡量的東西。大多數團隊跳過評估，然後發布有問題的 Agent。

四層框架

第 1 層：基礎設施。管道。

在你實際領域上的詞錯率（不是供應商的基準）
完整管道的 p50、p95、p99 延遲
首次音訊時間
在你傳輸上的音訊品質

第 2 層：執行。Agent 是否完成了要求的任務。

任務成功率
工具呼叫準確度
參數正確性
回應接地性（Groundedness）
使用一個小型快速模型作為 LLM 評審。四個是否問題：是否正確回答、保持接地、聽起來自然、適當簡潔。

第 3 層：使用者行為。跟它說話感覺自然嗎？

打斷恢復率
重新提示率
平均話輪長度
對話修復次數
每週抽樣 20 通電話。閱讀實際對話文字。你會在十通之內看到模式。

第 4 層：商業成果。它解決問題了嗎？

自處理率（不需要人類介入就能解決的通話百分比）
轉接率
客戶滿意度
首次通話解決率
針對自處理率進行最佳化。它與其他所有項目相關，而且是最容易在沒有儀器化的情況下測量的。

測試集組成

在發布前就建構好。最少 50 個對話。

40% 快樂路徑
30% 邊緣案例
15% 錯誤處理
10% 對抗性（提示注入、越獄嘗試）
5% 聲學變化（背景噪音、濃重口音、擴音）

針對每個情境：

應該呼叫哪個工具
使用什麼參數
Agent 應該說什麼

每週複盤循環

每週一早上。30 分鐘。

拉取指標
抽樣 20 通電話（7 通被轉接的、7 通已解決的、6 通隨機的）
閱讀對話文字
指出最常見的單一失敗類型
做一項改變（一次只改變一個變數，永遠如此）
A/B 測試 48 小時
推送勝出的版本

接地（Grounding）是一個信任系統

大多數建構者認為 RAG 是一個效能功能，一種獲得準確答案的方式。這個框架低估了它。

在語音 Agent 中，每個答案的準確性，直接說明了你的產品有多值得信賴。一個聽到關於價格、覆蓋範圍或政策的錯誤答案，而且是用自然的聲音自信說出的來電者，不僅會感到沮喪。他們會覺得被欺騙。

信任承諾的實作包含四個部分。

1. 真相來源

你的文件，而不是模型的訓練資料
系統提示必須明確說明這一點，用大寫字母：僅從提供的上下文中回答
模型有時仍然會傾向於一般知識，但明確的指令將比率降低了數量級

2. 優雅拒絕

當 Agent 找不到答案時，它會直接說出來
精確的措辭很重要
「我想確保給您準確的資訊，讓我查一下」為你贏得了優雅的轉接
「我不確定」聽起來像無能
「根據我的資訊」聽起來像律師的推託之詞
選擇一個短語，硬編碼，永遠不要讓 LLM 在這裡即興發揮

3. 置信度感知回應

檢索到的區塊的最高 BM25 分數是置信度的一個有用代理指標
分數高於 0.6：Agent 自信地回答
分數在 0.3 到 0.6 之間：Agent 回答，但加上「我認為」的推託
分數低於 0.3：Agent 不回答，提議轉接
在系統提示建構程式碼中修改 20 行。幻覺大約減少一半。

4. 知識庫衛生

過期的文件會產生過期的答案，而過期的答案是危險的答案
我每週五進行一次審計：讀取本週置信度評分最低的 5% 回應
一半的情況是答案正確，但檢索找到了一個過時的區塊
更新該區塊，重新嵌入，下週就會更安靜

需要注意的事項

六個會打擊你的失敗模式。

VAD 放在管道中而不是傳輸中

問題。Agent 觸發在自己的 TTS 輸出上，進入打斷循環，或完全無法偵測到話輪結束。
解決方案。VAD 分析器放在傳輸中。始終如此。配合一個回音護欄，忽略與近期助理輸出匹配的 STT 轉錄。

工具在錯誤的狀態下可用

問題。LLM 在仍在收集患者姓名的狀態下呼叫了 book_appointment。或者捏造了一個從未發生的預約。
解決方案。每個狀態設定工具範圍。一個狀態，只有它自己的函數。狀態機是安全護欄，而不是系統提示。

函數處理程序拋出異常，且從未呼叫結果回呼

問題。LLM 等待一個永遠不會到來的工具結果而卡住。或者捏造一個。
解決方案。每個處理程序都包裝在 try/except 中。每個分支都發送回結果。每個失敗都有一個口語後備方案。永遠不要有空的結果。

在使用者資料驗證時依賴提示而非程式碼

問題。LLM 在第 12 通電話中接受「john@」作為真實電子郵件。在第 47 通電話中拒絕一個包含加號的有效電子郵件。
解決方案。驗證邏輯放在 Python 中。電子郵件使用正則表達式、日期使用日期解析器、姓名長度檢查、驗證失敗時使用重新詢問的回應。

上下文視窗在長時間通話中無限制增長

問題。p95 延遲在一週內向上漂移，而程式碼沒有變更。到第 20 輪時，你每一輪正在發送 12K Token。
解決方案。使用滑動視窗保留最近 N 輪加上系統提示。或者在每個離散階段結束時，以里程碑為基礎重置上下文。

TTS 照字面讀取代碼和 ID

問題。確認碼「A3X7」被念成「ay three ex seven」，沒有任何停頓。患者無論如何都要求你重複。
解決方案。使用北約 phonetic 字母表擴展，配合 SSML 中斷標籤。聽起來較慢。但第一次就能正確讀取。

我會做得不同的事情

從第一天就建立話輪日誌結構，而不是第四週。重播端點是我建立過最有價值的工具，而我是在需要它之後才建立。
從一開始就使用語義話輪結束偵測，而不是與靜默門檻奮戰。
在系統提示超過 300 個字的那天，就轉移到真正的狀態機。不要試圖用散文來編碼狀態機。
停止在提示中進行驗證。LLM 不是解析器。Python 才是解析器。使用 Python。
在通話開始時快取最可能用到的五個 RAG 文件。跳過話輪迴圈內的向量搜尋。
在建立檢索之前，先建立閒聊門。「嗨」是系統中最便宜的 200 毫秒勝利。
在第一次生產通話之前就執行評估集。最少 50 個對話。
從第一天起就建立一個持久的萃取佇列。一個 pending_extractions Postgres 表格，加上一個單一重試工作者，只需 200 行程式碼，就能為你省去一次真正的停機。
每第 50 通電話運行一個非同步 LLM 評審。根據接地性、相關性、簡潔性進行評分。將其傳送到儀表板。漂移是真實存在的。
運行每週複盤循環。每週一抽樣 20 通電話。做一項改變。A/B 測試。推送勝出的版本。

結論

語音 Agent 看起來像 AI。但它們像即時系統一樣運作。

能夠成功發布的團隊就是以這種方式對待它們。那些晚了六個月才發布的團隊，認為一個更好的提示就能解決系統問題。

掌控你的管道。掌控你的日誌。將它們保存在純文字檔案中，這樣任何失敗都只需要一次重播就能解決。

第一個 Agent 花了我一個週末。生產系統則花了十週。從那之後，它每天都在進步，我完全不用動手。用戶不會注意到這些。他們只看到 Agent 回覆了「謝謝」，而且完全不用等待。

免責聲明與揭露

這篇文章由作者研究與撰寫，並由 AI 模型編輯。縮圖取自 Pinterest。

這篇文章是作者在深入基礎架構中開發語音 Agent 時，研究與撰寫而成。

內容基於持續更新中的筆記，以及使用 Perplexity、Claude 和 ChatGPT 進行的深入研究，並參考了幾本大學程度的系統設計與 API 設計教科書。

文章已由 Minimax M2.7 和 Claude Opus 4.7 徹底校對文法錯誤與格式。

語音 Agent 到底是什麼

三種架構