百聆 (Bailing): ein Sprachassistent aus vier austauschbaren Modulen

Vier Module, ein Loop: was 百聆 tatsächlich zusammensetzt

Der Name steht für vier Komponenten, die jeweils aus einem anderen Open-Source-Projekt stammen: FunASR für die Spracherkennung, silero-vad für die Erkennung von Sprachaktivität, ein DeepSeek-Modell für die Antwortgenerierung und eine austauschbare TTS-Schicht. Das ist keine eigene Modellforschung, sondern eine Verdrahtung. Genau darin liegt der Nutzen: Wer wissen will, wie sich ein GPT-4o-artiger Dialogloop aus fertigen Bausteinen bauen lässt, bekommt hier eine vollständige Referenz statt eines Papiers.

Die Zielgruppe ist entsprechend eng. Angesprochen sind Entwickler, die auf einem Mac oder einem Server ohne GPU einen sprechenden Assistenten betreiben wollen, und die bereit sind, die Qualität jeder Stufe einzeln zu bewerten. Wer ein fertiges Produkt mit Support sucht, ist hier falsch. Die Projektbeschreibung selbst nennt als Zweck ausdrücklich persönliches Lernen und Forschung, nicht den kommerziellen Einsatz.

Der Robot-Layer: Zustandslogik statt Modellglanz

Die eigentliche Ingenieursleistung steckt in der Tabelle, die das README zur Abbruchlogik zeigt. Sie kreuzt zwei Werte: läuft die Wiedergabe gerade, und spricht der Nutzer gerade. Vier Kombinationen, vier Konsequenzen. Läuft die Wiedergabe und der Nutzer schweigt, ist alles normal. Läuft die Wiedergabe und der Nutzer spricht, greift der Abbruch. Läuft nichts und niemand spricht, wartet das System. Läuft nichts und der Nutzer spricht, übernimmt die VAD-Kette und die Erkennung startet.

Diese Matrix ist der Grund, warum das Projekt überhaupt als Dialog und nicht als Frage-Antwort-Werkzeug funktioniert. Ein Assistent, der nicht unterbrochen werden kann, fühlt sich wie ein Anrufbeantworter an. Der Robot-Layer übernimmt laut README außerdem Aufgabenverwaltung und Gedächtnis und koordiniert die Module untereinander. Wie das Gedächtnis technisch gespeichert wird, geht aus dem Material nicht hervor. Das ist eine offene Stelle, die man vor einem Einsatz selbst im Code prüfen müsste.

Installation: Klonen, zwei Requirements-Dateien, eine YAML

Der Einstieg ist konventionell. Zuerst das Repository klonen und hineinwechseln, dann zwei Abhängigkeitslisten installieren, wobei die zweite auf das mitgelieferte OpenManus-Verzeichnis zeigt:

git clone https://github.com/wwbin2017/bailing.git cd bailing pip install -r requirements.txt pip install -r third_party/OpenManus/requirements.txt

Danach folgt die eigentliche Arbeit in der Konfiguration. Die Datei config/config.yaml nimmt die Einstellungen für ASR und LLM auf. Das SenseVoiceSmall-Modell muss separat nach models/SenseVoiceSmall heruntergeladen werden, der Download liegt bei Hugging Face. Für das LLM ist ein API-Schlüssel nötig, das README verweist auf die DeepSeek-Plattform und nennt OpenAI, Qwen, Gemini und 01yi als Alternativen. Wer die als testend gekennzeichnete AIGC-Konfiguration nutzt, trägt Modell, base_url und api_key zusätzlich in third_party/OpenManus/config/config.toml ein, und für OpenClaw kommen Berechtigungsdaten in config/.env. Der Start erfolgt entweder lokal über python main.py, optional mit vorherigem python server.py im Verzeichnis server, oder als Serverbetrieb mit selbst signiertem Zertifikat über openssl req -x509 -newkey rsa:4096 ... und anschließend python server.py, woraufhin die Oberfläche unter http://localhost:8000 erreichbar ist.

Bemerkenswert ist die Reihenfolge der Abhängigkeiten. Dass eine zweite Requirements-Datei aus einem eingebetteten Fremdprojekt stammt, bindet 百聆 an dessen Versionsstand. Ein Upgrade von OpenManus kann damit unerwartet den Assistenten brechen.

Vier TTS-Pfade und die Frage, was 800 ms bedeuten

Das README nennt für die Sprachausgabe gleich vier Optionen: edge-tts, Kokoro-82M, ChatTTS und das macOS-eigene say. Das ist bewusst als Wahlfreiheit angelegt, hat aber eine Konsequenz, die im Text nicht ausgeführt wird. Jeder dieser Pfade hat eine andere Latenz- und Qualitätscharakteristik, und die Angabe von 800 ms Ende-zu-Ende kann sich sinnvoll nur auf eine davon beziehen. Welche, sagt das Material nicht. Ebenso fehlen Angaben zu Hardware, Textlänge und Netzwerkanbindung, unter denen dieser Wert gilt.

Für die Planung heißt das: die 800 ms sind eine Projektangabe, keine garantiierte Obergrenze. Wer Latenz als Anforderung hat, muss den eigenen Aufbau messen, und zwar pro TTS-Pfad. Der Hinweis auf MacOS say ist dabei der pragmatischste Eintrag der Liste, weil er ohne Modell-Download und ohne Cloud-Anbindung auskommt, allerdings auch am wenigsten natürlich klingt.

Tool-Aufrufe: sieben Funktionen plus OpenClaw als Generalschlüssel

Die Funktionstabelle im README listet sieben aufrufbare Werkzeuge. Sechs davon sind eng umrissen: get_weather für Wetter an einem Ort, get_day_of_week für Datum und Wochentag, schedule_task für zeitgesteuerte Erinnerungen, open_application zum Starten von Programmen auf dem Mac, web_search für Suchanfragen und ielts_speaking_practice für Übungsdialoge. Das siebte, aigc, ist die offene Flanke: beschrieben als universelles Werkzeug, das jede Aufgabe erledigen kann, angebunden über OpenClaw.

Diese Konstruktion ist ehrlich, aber auch riskant. Ein Werkzeug ohne festen Vertrag bedeutet, dass die Zuverlässigkeit nicht mehr vom Assistenten, sondern vom nachgelagerten Agenten abhängt. Das Projekt nennt OpenClaw selbst eine Kernschicht für komplexe, mehrstufige Aufgaben und beschreibt den Weg vom Chatbot zum handelnden Assistenten. Ob das in der Praxis trägt, lässt sich aus dem Material nicht beurteilen. Klar ist nur: Wer aigc nutzt, debuggt im Fehlerfall zwei Systeme gleichzeitig.

Wann 百聆 das falsche Werkzeug ist

Die Disclaimer-Sektion ist ungewöhnlich deutlich und sollte ernst genommen werden. Sie erklärt das Projekt für ungeeignet in Produktionsumgebungen, schließt kommerzielle Nutzung aus und verweist jeden Supportanspruch an den Nutzer. Zusätzlich wird vor Datenverlust und Systemfehlern gewarnt. Das ist keine Formalie, sondern eine Beschreibung des Reifegrads: drei Releases seit Oktober 2024, die letzte Version v0.0.3 mit dem Vermerk, AIGC-Fähigkeiten seien neu und die allgemeine AIGC-Konfiguration befinde sich im Test.

Konkret heißt das: Wer eine Sprachschnittstelle für Kundenkontakt, Barrierefreiheit in einem Produkt oder Telefonie sucht, sollte woanders beginnen. Auch für Mehrbenutzerbetrieb gibt es im Material keine Hinweise auf Sitzungstrennung oder Rechtekonzept. Der Servermodus mit selbst signiertem Zertifikat ist ausdrücklich als Entwicklungsumgebung markiert. Wer den Assistenten mehreren Personen zugänglich macht, betreibt ihn außerhalb dessen, wofür er beschrieben ist.

Der Vergleich mit einem reinen Cloud-Sprachassistenten

Die naheliegende Alternative ist der Weg über einen kommerziellen Anbieter, bei dem Erkennung, Modell und Stimme aus einer Hand kommen und die Latenz vertraglich zugesichert wird. Der Unterschied liegt nicht in der Qualität der einzelnen Stufe, sondern in der Kontrolle. Bei 百聆 tauscht man jedes der vier Module einzeln aus, weil sie laut README unabhängig voneinander sind, und kann die gesamte Kette ohne GPU auf einem Mac betreiben. Dafür trägt man die Integrationslast selbst: Modell-Download, API-Schlüssel, YAML-Konfiguration, eine zweite Requirements-Datei aus einem Fremdprojekt und die Abstimmung von VAD-Schwelle und Abbruchverhalten.

Ein zweiter Vergleichspunkt ist die Anbindung an Agenten. 百聆 setzt auf OpenClaw als Ausführungsschicht und beschreibt das als Weg zum handelnden Assistenten. Ein Cloud-Assistent löst dasselbe über einen herstellereigenen Funktionsaufruf, mit dem Vorteil einer dokumentierten Schnittstelle und dem Nachteil, dass man an diesen Hersteller gebunden ist. Wer die Bindung vermeiden will, zahlt bei 百聆 mit Konfigurationsarbeit.

Lizenz und Pflegeaufwand

Der Code steht unter der MIT-Lizenz, die im Repository als LICENSE-Datei liegt. Das erlaubt Nutzung, Änderung und Weitergabe unter Beibehaltung des Lizenzhinweises. Diese Angabe steht allerdings in Spannung zum Disclaimer im README, der die Nutzung auf persönliches Lernen und Forschung begrenzt und kommerzielle Verwendung ausschließt. Wer den Code tatsächlich einsetzen will, muss diese beiden Texte gegeneinander abwägen und gegebenenfalls rechtlichen Rat einholen. Eine Einschätzung, welcher der beiden Texte im Streitfall greift, ist hier nicht möglich.

Der Pflegeaufwand hängt an zwei Stellen. Erstens an den externen Modellen: SenseVoiceSmall wird separat heruntergeladen und muss selbst aktuell gehalten werden. Zweitens am eingebetteten OpenManus-Verzeichnis, dessen Abhängigkeiten mitinstalliert werden. Ein Upgrade dort ist kein isolierter Vorgang. Die Abdeckung der Roadmap ist gemischt: Grundfunktionen, Plugin-Aufrufe, Aufgabenverwaltung, RAG und Agent, Gedächtnis, OpenClaw und WebRTC/WebSocket sind abgehakt, die Sprachweckfunktion ist offen. Zwischen v0.0.2 im März 2025 und v0.0.3 im Mai 2025 liegen gut zwei Monate, danach folgen weitere Commits bis April 2026. Ein festes Release-Tempo lässt sich daraus nicht ableiten.

Redaktionelles Fazit

Wer einen lokal laufenden Sprachloop zum Experimentieren mit Abbruchlogik und Tool-Aufrufen sucht, findet in 百聆 eine kleine, klar getrennte Codebasis. Wer Produktionsbetrieb mit definierter Latenz-Zusage braucht, sollte zuerst die eigene Hardware gegen die vier TTS-Pfade und die VAD-Schwelle in config/config.yaml prüfen, denn der 800-ms-Wert im README ist eine Projektangabe ohne Messbedingungen und die mitgelieferte Lizenz schließt kommerzielle Nutzung aus.

Offizielle Quellen

1. Issues
2. License: MIT
3. README
4. Releases
5. wwbin2017/bailing on GitHub