AssemblyAI提出三階段語音代理架構，LiveKit音訊傳輸驗證須另設

AssemblyAI提出一套語音代理架構，透過單一API金鑰串接語音辨識（STT）、回答生成與語音輸出（TTS）；若使用LiveKit傳輸音訊，仍須另行設定LiveKit驗證資訊。

AssemblyAI於9月30日公開的開發指南介紹，STT可使用「Universal-3.6 Pro Realtime」、回答生成採用「LLM Gateway」，語音輸出則使用AssemblyAI的Text-to-Speech API。這三個階段可透過LiveKit、Pipecat或自建執行流程串接。

指南所稱的「一把金鑰、一張帳單」，是指AssemblyAI的STT、LLM與TTS服務。若選擇LiveKit作為部署途徑，連線LiveKit所需的驗證資訊仍須另外管理。

這套架構的流程是先由STT將使用者語音轉成文字，再由大型語言模型（LLM）生成回答，最後透過TTS轉為語音。串接各階段的模型與服務後，即可建立語音對話流程。

各工具的分工也有所不同：LiveKit負責即時音訊傳輸，LiveKit Agents則負責協調並執行STT、LLM與TTS流程。

台灣開發者可留意各服務的繁體中文支援範圍。LiveKit的AssemblyAI STT文件將中文列為支援語言，但TTS支援清單僅列出英語、西班牙語、德語、法語、義大利語與葡萄牙語。STT支援中文語音轉文字，不代表同一套架構也支援中文語音回答。

LiveKit Agents提供串接AssemblyAI STT與TTS的外掛。LLM Gateway則是相容OpenAI API的服務；LiveKit文件也說明，連接相容的語言模型時，可設定自訂的base_url。

各元件的串接依據分散在不同文件中，開發者須自行組合相關方法進行實作。目前並未提供一份將三項服務整合在一起的官方執行範例。

AssemblyAI另行發布的LiveKit教學採用不同組合：語音辨識使用AssemblyAI，回答生成使用GPT-4o，語音輸出則使用Cartesia。

該教學列出的環境變數，分別包含LiveKit、AssemblyAI、OpenAI與Cartesia的驗證資訊。因此，這份教學並非由AssemblyAI包辦三個階段的「單一金鑰」執行案例。

驗證方式與用量管理會依TTS串接途徑而異。若透過AssemblyAI外掛直接串接TTS，就需要AssemblyAI API金鑰；若改用LiveKit Inference，則可由LiveKit Cloud管理用量與額度，無須另設AssemblyAI金鑰。

AssemblyAI公開的語音辨識基準資料呈現的是STT模型效能，不能據此推論包含LiveKit在內的整體代理回應時間或營運穩定性。

本刊先前曾報導，Agora通話轉錄範例缺少回答生成與語音輸出程式碼。這次的指南則介紹分別串接STT、LLM與TTS的開發方式。

AssemblyAI另有一份Voice Agent API指南，架構與上述三階段配置不同。在該方案中，LiveKit負責傳送音訊，AssemblyAI則在單一WebSocket連線中處理STT、LLM與TTS；LiveKit金鑰與密鑰仍須另行設定。