百聆（Bailing）：用 FunASR 加 DeepSeek 加 edge-tts 拼出的低延遲語音對話迴路
百聆 是一个类似GPT-4o的语音对话机器人，通过ASR+LLM+TTS实现，集成DeepSeek R1等优秀大模型，接入openClaw，真正的个人语音助手，时延低至800ms，Mac等低配置也可运行，支持打断
秒懂
- 它是什麼？
- 百聆把 VAD、ASR、LLM、TTS 四個模組串成一條可打斷的語音迴路，目標是在沒有 GPU 的機器上跑出接近即時的反應。它的價值在於模組替換的自由度，代價是你要自己處理模型下載、API key 與多個第三方配置檔。
- 適合誰用？
- 百聆適合願意自己動手調配置的個人開發者：你能接受手動下載 SenseVoiceSmall 到 models/SenseVoiceSmall、自己申請 DeepSeek api_key、並且把它當成 Mac 上的個人助手而非產品。不適合需要多用戶併發、需要 SLA 或需要長期免維護的團隊，README 的免責聲明本身就寫明不適用於商業用途或生產環境。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 163 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
百聆要解的是一個延遲問題，不是一個功能問題
語音對話助手在 2024 年之後並不稀缺，稀缺的是能在普通筆電上跑完一整圈的那種。百聆的定位寫得很直白：無需 GPU，實現類 GPT-4o 的對話效果，適用於各種邊緣設備和低資源環境。這意味著它放棄了端到端語音模型那條路線，改用 ASR、VAD、LLM、TTS 四個獨立元件拼接。
拼接路線的優勢是可以逐段換零件。ASR 用 FunASR，VAD 用 silero-vad，TTS 可選 edge-tts、Kokoro-82M、ChatTTS 或 macOS 的 say，LLM 預設 DeepSeek，README 也提到可以配置 openai、qwen、gemini、01yi。你不需要為了一個環節不滿意就換掉整套系統。代價是每一段都要自己接線，任何一段的延遲或格式不相容都會直接反映在對話體驗上。
它的目標使用者因此很明確：手上有一台 Mac 或一台沒有獨顯的機器，想拿開源模型組一個能真的用語音聊起來的助手，並且不介意讀配置文件。如果你要的是開箱即用的產品，這個專案從第一天就會讓你失望。
四個模組怎麼串成一條可打斷的迴路
README 的流程圖把架構畫成一個由 Robot 統籌的迴路，Robot 負責任務管理與記憶管理，同時處理使用者的打斷請求，並協調各模組之間的連接。這是整個設計的核心：它不是一條單向的管線，而是一個帶狀態的循環。
狀態由兩個維度決定，播放器是否正在播放，以及使用者是否正在說話。README 用一張表列出四種組合。播放中且未說話是正常狀態；播放中且說話就是打斷場景；未播放且未說話是待機；未播放且說話則交給 VAD 判斷、再交給 ASR 識別。打斷的判定因此不需要額外的喚醒詞，靠的是播放與收音兩個狀態的交叉。
資料流的順序是：FunASR 把語音轉成文字，silero-vad 過濾掉無效音訊以提升識別效率，DeepSeek 產生回覆，最後由 TTS 合成語音播放。VAD 放在 ASR 之前的意義在於省算力，不是省頻寬，這對沒有 GPU 的機器是必要的取捨。
工具呼叫走的是另一條路徑。使用者的自然語言請求會被轉成可執行任務，透過 OpenClaw 調用外部工具完成搜尋、分析與操作。README 把 OpenClaw 描述為核心執行層之一，並列出 get_weather、schedule_task、open_application、web_search、aigc 等函式，其中 aigc 被定義為接入 OpenClaw 的通用型任務入口。這層的實際可用性取決於你能不能拿到 OpenClaw 的授權，README 只說要修改 config/.env 配置 Auth 權限，沒有給出授權取得流程。
從 clone 到瀏覽器按下開始按鈕的實際步驟
安裝路徑在 README 裡寫得算完整。先複製倉庫並進入目錄，然後裝兩份依賴：requirements.txt 與 third_party/OpenManus/requirements.txt。第二份容易被忽略，漏掉的話工具層會直接壞掉。
配置分散在三個地方，這是這個專案最容易卡住的地方。config/config.yaml 管 ASR 與 LLM；third_party/OpenManus/config/config.toml 管 model、base_url、api_key；config/.env 管 OpenClaw 的授權。README 明確標註通用 AIGC 配置仍在測試中，若不可用可以退回 tag 分支 v0.0.1 或 v0.0.2。
模型要自己下載。SenseVoiceSmall 必須放到 models/SenseVoiceSmall，README 給的是 Hugging Face 上 FunAudioLLM/SenseVoiceSmall 的連結。LLM 方面要到 DeepSeek 官網取得 api_key，或改用其他相容模型。
執行方式有兩種。本地是進 server 目錄跑 python server.py，再回到根目錄跑 python main.py。伺服器模式則是先產生自簽憑證，README 給的指令是 openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes，然後直接執行 python server.py（不需要 cd server），瀏覽器打開 http://localhost:8000 點開始按鈕。README 推薦伺服器模式，理由是可以用移動端對話，但自簽憑證在手機瀏覽器上會觸發憑證警告，這一點文件沒有提。
Python 版本要求 3.12 或更高。這個門檻會擋掉一些仍在 3.10 的環境。
800ms 這個數字該怎麼讀
README 在開頭與專案特點兩處都提到端到端延遲 800ms，但沒有說明這個數字是在什麼硬體、什麼模型組合、什麼語句長度下測出來的。ASR 用本地 FunASR、LLM 走 DeepSeek 的雲端 API、TTS 用 edge-tts 也是雲端服務，這條鏈路裡有兩段依賴網路。800ms 在網路條件良好時可能成立，但它是個觀測值，不是保證值，也沒有對應的基準測試腳本可以重跑。
更值得注意的設計選擇是 TTS 的多樣性。edge-tts 與 Kokoro-82M 走的是不同的合成路徑，ChatTTS 又是另一套，macOS 的 say 則是本機指令。這四者延遲特性差異很大，README 沒有給出選擇建議，也沒有說明預設走哪一個。對延遲敏感的部署，這個選擇可能比 LLM 選型影響更大。
打斷功能同樣與延遲耦合。要讓打斷聽起來自然，系統必須在播放的同時持續收音並判斷，這代表 VAD 不能停。README 列出打斷策略可配置，能識別關鍵字與語音，但沒有說明關鍵字清單放在哪個配置鍵下。這是文件偏薄的一處。
模組化是優點，也是維護成本轉移
把 ASR、VAD、LLM、TTS 拆成四個獨立模組，換來的是替換自由。你可以只換 TTS，也可以只換 LLM 供應商。README 在感謝開源社區的段落裡列出 DeepSeek、FunASR、Silero-VAD、ChatTTS、openclaw，這五個都是外部專案，各有自己的版本節奏。
這意味著百聆的升級成本不完全由百聆自己決定。FunASR 或 silero-vad 改介面，你要等百聆跟進或自己打補丁。third_party/OpenManus 被直接放進倉庫，這種 vendoring 做法讓安裝步驟多了一步，也讓 OpenManus 的更新與百聆的更新綁在一起。
版本歷史也值得看一眼。v0.0.1 在 2024 年 10 月，v0.0.2 在 2025 年 3 月，v0.0.3 在 2025 年 5 月並標註新增 aigc 能力。三個版本都停在 0.0.x，README 自己也把通用 AIGC 配置標為測試中。這是一個仍在快速變動、介面尚未穩定的專案，不適合當成不會動的基礎設施。
授權是 MIT，README 說明可以自由使用、修改與分發，但需保留原始授權聲明。要注意的是倉庫內捆綁的 third_party/OpenManus 及其他開源元件的授權需各自確認，MIT 只覆蓋百聆自身的程式碼。README 的免責聲明另外寫明本專案僅供個人學習與研究，不適用於商業用途或生產環境，也不提供任何技術支援或保證。這是作者自己劃下的界線。
什麼情況下不該選百聆
如果你的需求是多用戶同時在線，百聆的架構沒有對應設計。README 描述的是單一使用者的個人助手，記憶功能記的是「使用者的偏好與歷史對話」，任務管理管的是個人的提醒事項。要改成多租戶，等於在 Robot 這一層重寫。
如果你需要離線且不依賴任何雲端服務，這條鏈路預設就會斷。LLM 走 DeepSeek 的 API，edge-tts 也是雲端合成，README 沒有說明如何在完全離線的條件下替換這兩段。要離線就得自己換上本地 LLM 與本地 TTS，那已經不是照著 README 安裝的範疇。
如果你需要的是穩定的語音辨識準確率而不是對話體驗，直接用 FunASR 或 SenseVoiceSmall 會更直接。百聆在這一層沒有加值，它做的是把辨識結果接進對話迴路。
真正該考慮的替代方案是 Pipecat 這類語音代理框架。差異在抽象層級：Pipecat 把語音代理拆成 frame 在 pipeline 中流動，提供統一的傳輸層與服務抽象，讓你能把不同供應商的 STT、LLM、TTS 當成可插拔的 processor 組合，並且原生處理 WebRTC 與多路會話。百聆的模組化是在應用層用配置檔切換，耦合度更高，但改動的範圍也更小、更容易看懂。要快速做出一個能跑的個人助手，百聆的路徑短；要做成可擴展的服務，Pipecat 的抽象值得多花的那段學習成本。
採用前該驗證的三件事
第一件是模型檔案。SenseVoiceSmall 要手動放到 models/SenseVoiceSmall，README 只給了 Hugging Face 連結，沒有提供自動下載腳本。路徑寫錯的話，ASR 這一段不會有任何輸出，而錯誤訊息是否清楚取決於 FunASR 本身。
第二件是 LLM 端點。config/config.yaml 要填對 ASR 與 LLM 的配置，DeepSeek 的 api_key 從 platform.deepseek.com/api_keys 取得。若改用 openai、qwen、gemini 或 01yi，要確認介面相容性，README 只列出可換，沒有給對應的配置範例。
第三件是 OpenClaw 授權。config/.env 裡的 Auth 權限是工具呼叫與 aigc 能力的前提，README 沒有說明申請方式。拿不到授權的話，百聆仍然可以當純語音聊天用，但 README 花了大篇幅描述的「行動型助手」那一層就用不上。先確認這三項，再決定要不要投入時間調延遲。
編輯結論
百聆適合願意自己動手調配置的個人開發者：你能接受手動下載 SenseVoiceSmall 到 models/SenseVoiceSmall、自己申請 DeepSeek api_key、並且把它當成 Mac 上的個人助手而非產品。不適合需要多用戶併發、需要 SLA 或需要長期免維護的團隊，README 的免責聲明本身就寫明不適用於商業用途或生產環境。動手前先確認三件事：config/config.yaml 的 ASR 與 LLM 段落能否對上你手上的模型與端點、third_party/OpenManus/config/config.toml 的 model 與 base_url 是否可用（README 標註通用 AIGC 配置仍在測試中）、以及 config/.env 裡的 OpenClaw 授權能否申請到。這三項任一項卡住，整條語音鏈路就跑不起來。
社群筆記