OpenAI Realtime API 是什麼？語音 AI 的架構、選型與安全實作

語音 AI 的價值不在於「會說話」而已，而在於使用者能否自然插話、系統能否安全地查資料或執行工具、以及整段互動是否足夠快且可被治理。OpenAI Realtime API 是用於低延遲即時互動的 API 路徑，可支援 speech-to-speech 語音對話，也能搭配文字、音訊與工具事件。不過，它不會自動取代所有客服、語音轉文字或電話系統；正確的架構選型、權限與失敗處理，才決定語音體驗是否真的可用。

本文把原本「顛覆市場」式的說法改成可執行的判斷框架：什麼問題適合 Realtime、何時該採用串接式語音管線、瀏覽器與伺服器應選哪種連線、以及上線前怎麼處理金鑰、工具與人工作業。

OpenAI Realtime API 是什麼？

Realtime API 是為即時、低延遲互動設計的連線式 API。它維持一個 session，讓應用程式持續送入音訊或文字、接收模型輸出與事件，並可在對話中使用工具。OpenAI 的目前文件把低延遲語音 agent、即時翻譯與即時轉錄分為不同路徑；其中低延遲語音 agent 的文件以 gpt-realtime-2.1 為起點。模型與產品名稱、可用區域與價格都可能變動，因此實作前應回到官方文件與帳戶設定確認。

對使用者而言，speech-to-speech 的目標是更自然的對話節奏：能處理語音輸入、產生語音回覆、接受中斷，並在需要時呼叫後端工具。它適合需要即時回應的導覽、預約初篩、現場協助、語音介面或具備即時工具查詢的服務；但「即時」不等於每一步都更準確，也不等於可以略過認證、資料核對或人工覆核。

先選架構：即時語音，還是可控的串接流程？

第一個決定不是模型名稱，而是是否真的需要 live audio。若使用者期待自然輪替、barge-in（使用者插話）、低 first-audio latency 與即時工具使用，speech-to-speech 的 Realtime session 是合適的起點。OpenAI 的 Voice agents 指南也把這類需求列為 live audio 路徑的典型情境。

但如果流程需要明確的逐字稿、既有文字 agent、規則檢查、審核或可預期的步驟，串接式流程往往更好：先 speech-to-text，再執行文字 agent 與業務邏輯，最後 text-to-speech。這會增加一些延遲，卻能讓每個中間結果被記錄、替換或送入人工批准。例如理賠、醫療行政、金融交易、客服承諾與高風險工具操作，不應只因為語音流暢就跳過文字驗證與權限邊界。

瀏覽器、伺服器與電話系統怎麼連？

傳輸方式應由音訊在哪裡產生與播放決定。對需要直接收錄麥克風、播放模型語音的瀏覽器或行動端，官方文件建議優先使用 WebRTC，以取得較一致的即時音訊表現。若伺服器已經從電話系統、媒體管線或 worker 收到原始音訊，則較適合使用 WebSocket。電話語音 agent 也可評估 SIP，但要先確認選用模型與情境的支援狀態。

以瀏覽器語音 agent 為例，一個健康的責任分工通常是：前端負責麥克風權限、音訊播放與互動狀態；應用程式後端負責建立 session、使用者身分、工具授權、業務資料與稽核；Realtime session 專注處理對話、音訊與事件。不要把訂單、帳務、CRM 或權限判斷硬塞進前端提示詞，也不要讓模型直接擁有無限制的後端憑證。

金鑰與使用者識別：不能為了方便放到前端

一般 OpenAI API key 應只存在受信任的伺服器。對瀏覽器或行動端的 Realtime 連線，後端應使用自己的標準金鑰建立短效的 ephemeral client secret，再把該短效憑證交給前端建立 session；或由後端使用 unified interface 代為完成 session 初始化。這能避免把長期 API key 放進網頁、App bundle 或前端 log。

如果應用程式可識別終端使用者，官方文件建議在後端用穩定且保護隱私的識別值（例如雜湊的內部 user ID）設定 safety identifier，並在建立短效憑證或連線時送出。這個值不是把個人資料交給模型的捷徑，也不能取代自己的帳號、同意、速率限制與濫用偵測；它只是讓平台能更精準地處理可疑濫用，而不是影響整個組織。

語音 agent 的工具與人工交接

語音介面會讓工具呼叫看起來很自然，但它不該降低操作門檻。建議讓 agent 只能呼叫範圍明確的工具：查詢公開營業時間、讀取已授權的訂單狀態、建立草稿或提出預約候選時間。涉及付款、取消訂單、修改地址、存取敏感資料或對外承諾的動作，應再次驗證身分、明確朗讀／顯示關鍵結果，並在必要時要求使用者確認或轉交人員。

為每個工具建立可稽核的輸入 schema、權限檢查、限流與錯誤訊息。模型說「已完成」不應取代後端的成功回應；前端應根據工具的實際結果更新狀態。當工具逾時、資料不完整、使用者情緒升高或問題超出授權範圍時，設計一條可立即交接給真人或改走文字／表單的路徑，比持續猜測更重要。

延遲不只來自模型

一段語音回覆的等待時間，還包含麥克風擷取、網路、turn detection、模型推論、工具呼叫、文字或音訊串流，以及裝置播放。只量 API 回傳時間，無法代表使用者感受到的延遲。測試時應分別記錄使用者開始說話到系統開始回應的時間、工具呼叫耗時、完成回覆時間、插話後停止播放的速度，以及斷線後的恢復行為。

也要用真實條件測試：吵雜環境、不同口音、多人交談、專有名詞、慢網路、藍牙耳機、長停頓與使用者中途改口。語音介面最容易在 demo 很順、真實使用卻失敗；把可聽懂、可中斷、可恢復與可轉真人列為正式驗收條件，會比追求一次性的驚豔回覆更有價值。

隱私、資料與內容安全的最低要求

在錄音或分析語音前，應以清楚方式告知使用者用途、資料是否保存、可否改走文字渠道，以及如何聯絡真人。不同地區與產業的法律要求不同，涉及個資、健康、金融或未成年人時，應由合規與法務依實際情境確認。從產品設計角度，預設少收集、設定必要的保存期限、限制錄音與逐字稿的存取角色，並避免把敏感片段直接送進不必要的工具或分析系統。

此外，語音輸入同樣可能包含提示注入、冒名、越權要求或惡意誘導。將指令、使用者內容、外部資料與工具權限分開處理；不要因為一段語音聽起來急迫，就繞過既有的身分、授權與交易確認流程。把 guardrails、工具 allowlist、人工覆核與事件紀錄視為語音產品的一部分，而不是上線後再補的附加功能。

上線前檢查清單

確認任務需要即時語音；若需要可稽核文字與確定性流程，優先評估串接式管線。
瀏覽器／行動端使用 WebRTC 與短效 client secret；標準 API key 僅保留在後端。
為每個工具設定 schema、授權、可審計結果與失敗時的真人交接。
測量 end-to-end latency、插話、斷線、嘈雜音訊與工具超時，而不是只看 demo。
定義錄音、逐字稿與個資的告知、存取、保存與刪除策略。
以真實語言、口音、業務術語與高風險情境測試品質，並設定可關閉或降級的開關。

常見問題：一定要把所有電話都改成 Realtime 嗎？

不需要。若通話主要是固定選單、簡單通知、離線檔案轉錄或明確的人工處理流程，既有 IVR、文字聊天或串接式語音流程可能更容易維護。Realtime 的優勢在於需要自然、低延遲、可中斷的對話與即時工具互動；是否值得導入，應由使用者需求、失敗成本、可用資料與團隊維運能力決定，而不是因為新技術本身很吸引人。

最務實的做法是先挑選一個低風險、可人工接手的情境，例如門市資訊、預約意圖蒐集或服務導覽，設定清楚的成功率、轉真人率與滿意度門檻，再決定是否擴大到更多流程。這能避免把語音 AI 當成一次性的技術替換，而是把它當成可驗證、可回退的服務能力。

結語

OpenAI Realtime API 讓低延遲語音 agent、翻譯與即時轉錄有了更直接的實作路徑，但它真正改變的不是「語音能不能生成」，而是應用程式如何把音訊、事件、工具和安全控制整合成可用服務。選擇 speech-to-speech 或串接式管線、把長期金鑰留在後端、限制工具權限、測量全程延遲並保留真人交接，才能讓語音 AI 從吸睛展示走向可靠產品。