
2026 年 6 大開源語音代理框架(排名)
上季我們用 Pipecat 交付了三個電話語音代理,然後在客戶從 20 通併發通話暴增到 400 通時,用 LiveKit Agents 重建了其中一個。兩者都是開源語音代理框架,但沒有哪個是「最好的」。它們各有所長,選錯會讓你白白浪費好幾週。
這份排名來自實際交付經驗,而不是 README 寫得漂亮。我們在 2026 年 7 月 14 日拉取了 GitHub 即時數據:Pipecat 有 13,416 顆星、LiveKit Agents 有 11,356 顆、TEN Framework 有 10,898 顆。星數不能說明一切,所以我們也衡量了 commit 活躍度、電話支援、授權條款,以及各框架在真實通話量下的表現。
簡短答案: 對 2026 年的大多數團隊來說,Pipecat 是最強的開源語音代理框架,因為它的整合庫龐大且幾乎每天都有開發更新。LiveKit Agents 在規模和原生電話方面勝出,TEN Framework 在多模態圖形編排方面領先,Bolna 則能在一個下午內讓電話代理上線。
如果你寧可購買成品而非自行組裝,我們的 ElevenLabs、Vapi 和 Synthflow 等託管平台比較以及 Retell AI vs Vapi vs Bland 是更好的起點。剛接觸這個領域?先從什麼是 AI 語音代理開始。
我們如何排名這些框架
我們根據五個真實專案成敗關鍵來評分:開發活躍度(過去 90 天的 commit 數)、STT/LLM/TTS 整合的廣度、電話支援(能否接聽真實電話號碼)、授權條款,以及併發下的表現。以下是名單一覽。
| 排名 | 框架 | 星數(2026 年 7 月) | 授權 | 語言 | 電話 | 最適合 |
|---|---|---|---|---|---|---|
| 1 | Pipecat | 13,416 | BSD-2-Clause | Python | Twilio、Daily、Telnyx | 全方位生產環境建置 |
| 2 | LiveKit Agents | 11,356 | Apache-2.0 | Python、Node | 原生 SIP + 電話號碼 | 規模化與即時通訊 |
| 3 | TEN Framework | 10,898 | Apache-2.0(混合) | C、Go、Python、JS | 透過 Agora RTC | 多模態與邊緣運算 |
| 4 | Bolna | 695 | MIT | Python | Twilio、Plivo、Exotel、SIP | 快速電話代理 |
| 5 | FastRTC | 4,618 | MIT | Python | WebRTC(自備) | 原型與展示 |
| 6 | Vocode | 3,773 | MIT | Python | Twilio、Vonage | 參考用途,但有注意事項 |
1. Pipecat — 最佳全方位選擇
Pipecat 由 Daily 背後的團隊打造,是一個 Python 框架,將對話建模為管線:音訊輸入,經過語音轉文字、語言模型和文字轉語音,音訊再輸出。這個心智模型容易理解,並在 2026 年 4 月達到穩定的 v1.0 版本。
它的差異化優勢在於整合庫。Deepgram、AssemblyAI、OpenAI、Gemini、Cartesia、ElevenLabs 等數十個服務都已接好,所以更換 TTS 供應商只需改一行程式碼,而非重寫。電話透過 Twilio、Daily 或 Telnyx 運作。擁有 13,416 顆星且幾乎每天都有 commit 提交,它也是這份清單中動能最強的。
取捨在於:因為 Pipecat 提供的是組件而非成品代理,編排邏輯由你負責。沒有拖放式建置器,你得寫 Python。對已經在寫程式的團隊來說,這是優點而非缺點。
適合你如果: 你想要一個供應商中立、生產等級的基礎,擁有最廣泛的模型支援,而且你樂於撰寫 Python。這是我們大多數客戶專案的預設起點。
2. LiveKit Agents — 為規模與即時性而生
LiveKit Agents 採取不同路線。你的代理不是線性管線,而是透過 WebRTC 以參與者身份加入房間——與 Zoom 式通話背後的技術相同。這種架構正是它在需要低延遲和大量同時對話時脫穎而出的原因。
2026 年的大新聞是電話。LiveKit 推出了原生 SIP 和電話號碼,因此撥入和撥出通話不再需要 Twilio 橋接器居中轉接。它還提供 OpenAI Realtime API 的第一方支援,並且從 1.5.x 版本開始,原生支援 Model Context Protocol 工具和自適應中斷處理。詳情可參閱 LiveKit Agents 文件。如果你想了解它封裝的即時 API,我們另有專文介紹 OpenAI Realtime API 與語音代理。
因為它運行在 LiveKit 的開源 WebRTC 媒體伺服器上,你可以自行託管整個堆疊。學習曲線比 Pipecat 陡峭,房間與參與者的思維模式需要一點時間才能上手。
適合你如果: 你預期有真正的併發需求、想要無需橋接器的原生電話,或者你正在建置一個必須承受流量尖峰的 OpenAI Realtime 代理。
3. TEN Framework — 多模態與圖形化
TEN Framework(Transformative Extensions Network)由 Agora 支持,將你的代理描述為節點圖:STT、LLM、工具、記憶、視覺。你在工作流建置器中組合圖形,TEN 負責執行。對於任何超越純語音的場景,它是這裡最靈活的選項,其 C++ 核心針對低延遲音訊進行了最佳化。
它也是這份清單中支援程式語言最廣的框架,提供 C、Go、Python、JavaScript 和 TypeScript 的擴充套件,以及 Dify 和 Coze 的現成連接器。Agora TEN Framework 頁面是最清晰的功能概覽。
兩個注意事項。第一,授權是混合式的:框架大部分是 Apache-2.0,但某些資料夾有額外限制,因此在商業發布前請閱讀 LICENSE。第二,即時傳輸依賴 Agora 的網路,這意味著需要 Agora App ID,且超過免費額度後會產生 Agora 使用費用。
適合你如果: 你正在建置多模態代理(語音加視覺或虛擬化身)、你看重圖形化組合,或者你想要開源中最低層級的音訊效能。
4. Bolna — 最快的電話代理上線路徑
Bolna 比前三名小(695 顆星)且更有主見,而這正是它的優勢。它以電話為先。其他框架要你自己組裝通話功能,Bolna 直接提供:Twilio 用於全球通話、Plivo 和 Exotel 用於印度、自訂 SIP 中繼,全部以 JSON 风格的代理定義設定,而非寫程式碼。
這種設定驅動的方式意味著你能以幾乎最快的時間讓撥入或撥出電話代理接聽真實來電。底層它透過 websocket 編排 ASR、LLM 和 TTS 供應商,所以你仍然可以選擇自己的模型。開發在 2026 年中仍保持活躍。
速度的代價是社群較小、整合比 Pipecat 或 LiveKit 少。如果你遇到邊緣案例,你更可能是第一個提交 issue 的人。對於電話密集的建置,請將它與我們語音代理電話比較中的選項一起衡量。
適合你如果: 你的使用場景以電話為先(預約提醒、撥出資格篩選、撥入支援),而且你想完全跳過電話基礎設施的搭建。
5. FastRTC — 輕量級原型選項
FastRTC 來自 Hugging Face 和 Gradio 團隊,它不是完整的代理框架,而這正是重點。它是一個 Python 函式庫,透過 WebRTC 或 websocket 處理即時音訊和視訊。你自備 STT、LLM 和 TTS,FastRTC 只需幾行程式碼就能處理串流傳輸。
對於概念驗證、展示或研究探索,這種極簡主義是一份禮物。你可以在一個下午內搭建一個會說話的原型,而不必承諾採用重量級框架的慣例。它與 Hugging Face 生態系統自然搭配,開放模型很容易接入。
反面是你必須負責框架原本會提供的一切:輪次偵測、中斷處理、電話、狀態管理。它向下擴展得很漂亮,向上擴展則很痛苦。
適合你如果: 你正在做原型、教學或建置瀏覽器展示,而且你想要最大控制權與最少的框架開銷。
6. Vocode — 歷史上重要,但有維護注意事項
Vocode 幫助定義了整個品類。它的模組化 STT/LLM/TTS 設計和內建 Twilio 及 Vonage 電話,使其成為最早真正可用的開源語音框架之一,擁有 3,773 顆星,至今仍出現在許多教學中。
誠實的部分來了,也是它排名最後的原因:開源核心已經沉寂。vocode-core 的最後一次 commit 在 2024 年 11 月,倉庫只有兩個開放 issue,這通常意味著注意力已轉移到公司的託管產品,而非健康的待辦清單。程式碼仍能運行,設計值得研究,但你將建立在一個沒有人積極維護的基礎上。
適合你如果: 你正在研究語音代理架構、維護現有的 Vocode 專案,或者你特別需要它的設計模式並接受自行維護基礎。
也值得了解
有幾個工具恰好在排名之外,但值得你關注:
- OpenAI Agents SDK(27,900+ 顆星)提供語音管線擴充。它是通用代理 SDK 而非語音優先,但如果你已經標準化使用它,這是合理的選擇。
- Gabber 是較新的多模態框架,用於能看、能聽、能說的代理,針對螢幕與攝影機使用場景。
- Jambonz 是開源電話骨幹。它不建構代理大腦,但它是將任何框架連接到真實電話網路的電信級方案。
- Rasa(21,000+ 顆星)仍是企業級對話和 NLU(跨文字與語音)的重量級選手,儘管運行起來比上述任何框架都更複雜。
- Ultravox 是快速的語音語言模型,不是編排框架,所以應將其視為可插拔組件而非競爭者。
我們實際上會為客戶建置使用什麼
在 Techsy,我們為 B2B 客戶建構語音代理,所以以下是排名背後的真實面貌。
我們的預設堆疊是 Pipecat 接 Deepgram Nova-3 做語音轉文字、GPT-4o-mini 做語言模型、Cartesia Sonic 做文字轉語音。一旦輪次偵測調校完畢,語音對語音延遲通常落在 0.7 到 1.1 秒之間,足夠接近人類對話,以至於來電者不再注意到延遲。將任何一個組件換成較慢的模型,你立刻就能感覺到。
電話是專案變得棘手的地方。我們在生產環境中運行過兩種模式:Twilio SIP 中繼橋接到 LiveKit 的原生 SIP,用於高流量撥入支援;以及 Bolna 內建的 Plivo 處理,當客戶只需要撥出提醒通話時。LiveKit 路線前期需要更多工程時數,但當 300 通電話在同一分鐘內湧入時仍能穩定運行。Bolna 則讓你在週五前上線。
自行託管的數學讓人困惑。在單個 A10G GPU 上運行本地 STT 和 TTS,無論是否有來電,每小時成本大約 0.50 到 0.90 美元。像 Deepgram 和 Cartesia 這樣的按分鐘計費 API,閒置時不花錢,但超過每月幾千分鐘後會快速累積。低於大約每月 15,000 分鐘,API 幾乎總是更划算,這也是我們對大多數客戶的建議。我們主要在併發超過幾百通同時通話時選擇 LiveKit 而非 Pipecat。
如果你那邊自建還是購買的問題仍未確定,我們在自建 vs 購買 AI 語音代理指南中詳細說明了完整的成本分析。如果你寧可讓一個團隊為你處理延遲、電話和擴展,那正是我們在 Techsy 語音代理實務做的事。
一分鐘內如何選擇
跳過分析癱瘓。以下是要點式決策:
- 你想要最安全的全方位預設: Pipecat。
- 你需要真正的併發或原生電話: LiveKit Agents。
- 你要做多模態(語音加視覺或虛擬化身): TEN Framework。
- 你需要本週讓電話代理上線: Bolna。
- 你在做原型或教學: FastRTC。
- 你寧可購買而非自建: Vapi、Retell 或 Synthflow 等託管平台,根本不用框架。
常見問題
什麼是開源語音代理框架?
它是一個可自行託管的程式碼庫,將語音轉文字、語言模型和文字轉語音串接在一起,使軟體能進行口語對話。與託管平台不同,你在自己的基礎設施上運行、選擇自己的模型,只為底層服務付費,而非按分鐘加價。
哪個開源語音代理框架延遲最低?
TEN Framework 憑藉其 C++ 核心在原始音訊管線效能上領先,但實際上網路和模型延遲主導了總延遲。調校良好的 Pipecat 或 LiveKit 堆疊搭配快速模型,通常能達到 0.7 到 1.1 秒的語音對語音延遲,在大多數實際部署中與 TEN 相當。
開源真的比 Vapi 或 Retell 便宜嗎?
不一定。開源消除了平台的按分鐘加價,但你承擔了工程、託管和維護成本。每月低於幾千分鐘通話時,一旦計入開發者時間,託管平台通常更便宜。超過數萬分鐘後,自行託管框架才會領先。
這些框架能接聽真實電話嗎?
可以。Pipecat 透過 Twilio、Daily 或 Telnyx 連接;LiveKit Agents 提供原生 SIP 和電話號碼;Bolna 內建 Twilio、Plivo 和 Exotel;Vocode 支援 Twilio 和 Vonage。FastRTC 以瀏覽器為主,需要 Jambonz 等外部橋接器才能連接電話網路。
我需要機器學習專業知識才能使用它們嗎?
不需要。你需要的是軟體工程技能,主要是 Python。繁重的工作(轉錄、推理、語音合成)由你透過 API 接入的模型處理。你是在編排服務,而非訓練模型,除非你刻意選擇自行託管開放權重模型。
哪個框架最適合初學者?
Pipecat,因為它的管線模型最容易理解,且文件和範例最完整。FastRTC 是好的第二選擇,如果你想從更小的規模開始,在採用完整框架之前先了解原始傳輸層。
開源語音框架在 2026 年已具備生產就緒嗎?
前三名是的。Pipecat 達到 v1.0,LiveKit Agents 在 1.5.x 版本線,TEN Framework 透過 Agora 驅動商業部署。主要風險不在框架本身,而在較小專案的維護狀態,這就是為什麼我們標記了 Vocode 停滯的核心。
這與 ElevenLabs 等 TTS API 有何不同?
TTS API 只將文字轉為語音,這只是一個組件。語音代理框架編排整個迴圈:它聆聽、轉錄、將文字發送到語言模型、取得回覆並朗讀出來,同時管理中斷和輪次交替。是框架調用 TTS API,而非反過來。
關於作者
Mert Batur Gurbuz 是 Techsy.io 的聯合創辦人,團隊為 B2B 客戶交付 AI 代理、自動化系統和語音/SDR 管線。他就讀於 University of Birmingham,撰寫關於 Techsy 團隊在生產環境中實際使用的 LLM 工具堆疊的文章。歡迎在 LinkedIn 上聯繫。