AI Voice Agent bauen

Kostenlose Spec für einen AI Voice Agent auf LiveKit Agents – ein Echtzeit-Voice-Loop mit Streaming-STT, schnellem LLM (Speed-Tier), Streaming-TTS, transformerbasierter End-of-Turn-Erkennung, adaptivem Barge-in, Function Tools, Gesprächsgedächtnis und einer Eval-Harness mit LLM-Judge. Ausgelegt auf ein Round-Trip-Ziel von 1.000 ms (200/400/200/200 für STT/LLM/TTS/Netzwerk).

So nutzt du diese Spec

1. Klick auf eine Zeile oben, um die ganze Task zu öffnen – Titel, Beschreibung, Subtasks, KI-Anweisungen, alles drin. Dasselbe Layout, das das Produkt intern nutzt.
2. Klick auf Copy as Prompt in der rechten Seitenleiste einer Task. Du bekommst den in XML verpackten Prompt, den Tekk intern verwendet – füg ihn in Cursor, Claude Code, Codex, ChatGPT oder sonst wo ein, und der Agent hat den vollen Kontext der Task.
3. Open in schickt denselben Prompt mit einem Klick direkt nach v0, Lovable, Bolt, Magic Patterns, Replit oder Cursor.

Was du baust

Goal 1: Liefere einen funktionierenden AI Voice Agent auf LiveKit Agents: eine Streaming-Pipeline aus STT → LLM → TTS, die über Web-Transport einen p50-Round-Trip unter 1.000 ms schafft, das Turn-Ende semantisch erkennt (nicht nur per VAD), Barge-in sauber behandelt, mitten im Gespräch Tools aufruft, sich an frühere Turns erinnert und mit Traces, Aufzeichnung und Regression-Evals im Produktivbetrieb besteht.
Voice Agent im Stil von Anthropic, gebaut auf LiveKit Agents als Hauptvariante (Pipecat als framework-unabhängige Alternative). Du wählst die Provider-Stufe einmal in STACK.md (STT / LLM / TTS / Turn Detector / Memory-Substrat); jede spätere Karte nutzt dann die passende Variante. Die Messlatte: p50-End-to-End-Latenz < 1.000 ms über die Eval-Suite mit 6 Szenarien, Fehlunterbrechungsrate < 5 % auf einer Turn-Detection-Fixture mit 50 Turns, Tool Calls brechen bei Barge-in innerhalb von 200 ms ab, der Multi-Turn-Memory-Test besteht, und die Regression-Harness zeigt nach dem Production-Hardening höchstens ±10 % Latenzdrift.

Architektur

flowchart LR
  User[User Audio] -->|WebRTC frames| Room[LiveKit Room]
  Room --> VAD[Silero VAD<br/>pre-warmed]
  VAD --> STT[Streaming STT<br/>~90-200ms]
  STT -->|partial transcripts| EOU[MultilingualModel EOU<br/>~50ms CPU]
  STT -->|partials| LLM[Speed-tier LLM<br/>preemptive gen<br/>~120-400ms TTFT]
  EOU -->|turn-end signal| LLM
  LLM -->|token stream| Tools{Function tool?}
  Tools -->|no| TTS[Streaming TTS<br/>~75-200ms first-byte]
  Tools -->|yes| Tool[Tool call<br/>interruption-aware]
  Tool -->|result| TTS
  TTS -->|audio frames| Room
  Room -->|WebRTC frames| User
  LLM <-->|history| Memory[(Session Memory<br/>in-memory)]
  TTS -.->|trace events| Tracer[Tracer<br/>JSONL stderr]
  STT -.->|trace| Tracer
  LLM -.->|trace| Tracer

Die tragende Randbedingung ist das p50-Latency-Budget von ~1.000 ms: 200 ms STT + 400 ms LLM + 200 ms TTS + 200 ms Netzwerk. Drei Architekturentscheidungen verteidigen es. Erstens: Jede Stufe streamt – STT gibt Teiltranskripte mitten in der Äußerung aus, das LLM streamt Tokens an TTS, sobald sie ankommen, TTS spielt Audio-Chunks ab, während es noch synthetisiert. Schon eine einzige Stufe ohne Streaming sprengt das Budget. Zweitens: Turn Detection ist ein Transformer-Klassifikator (MultilingualModel, 135 Mio. Parameter, ~50 ms auf der CPU) auf Silero VAD – nicht VAD allein. LiveKits eigene Daten: Das senkt Fehlunterbrechungen um 85 %, und das ist der Unterschied zwischen einem Gespräch, das sich menschlich anfühlt, und einem, in dem der Agent dazwischenredet. Drittens: Tools respektieren Unterbrechungen – jedes länger laufende Tool prüft speech_handle.interrupted und bricht bei Barge-in ab. Ohne das beendet der Agent ein verwaistes Tool 4 Sekunden, nachdem sein Gegenüber längst weiter ist, und liest ein veraltetes Ergebnis in den neuen Turn. Preemptive Generation lässt das LLM spekulativ laufen, bevor EOU bestätigt ist – das spart ~100 ms gefühlte Latenz, verbrennt aber bei jedem falschen EOU Tokens. Genau deshalb ist der Transformer-Klassifikator (nicht rohes VAD) die richtige Wahl.

Wann ein Voice Agent sinnvoll ist (und wann nicht)

Voice Agents sind ein ganz anderes Kaliber als Text-Agents. Der Handlungsspielraum ist klein (sprechen / Tool aufrufen / schweigen), aber das Fehlerbild ist brutal: Latenz. Ein Voice Agent, der 200 ms zu langsam ist, wirkt kaputt; bei einem Chat-Agent fallen 200 ms gar nicht auf. Greif zu diesem Pattern, wenn das Gespräch ZWINGEND über Audio laufen muss – Telefonsupport, Terminplanung während der Autofahrt, Workflows, bei denen die Hände voll sind. Ansonsten bau einen Chat-Agent und spar dir das Budget.

Was die Community sagt

Woran du erkennst, dass es funktioniert

Setz die Spec um und miss sie dann an diesen Kriterien (die Task mit dem Eval-Harness bewertet sie):

• p50-End-to-End-Latenz < 1.000 ms auf einer Fixture-Suite mit 6 Szenarien, gemessen pro Stufe (STT / LLM / TTS) und als Round-Trip gesamt
• p95-End-to-End-Latenz < 1.500 ms – erfasst Regressionen der Tail-Latenz, die p50 verdeckt
• Fehlunterbrechungsrate < 5 % auf einer Turn-Detection-Fixture mit 50 Clips (25 echte EOU + 25 falsche EOU; Transformer-EOU + adaptive Interruption)
• Rate verpasster Turn-Enden < 5 % auf derselben Fixture – das Modell übersieht kein echtes Turn-Ende
• Barge-in-Latenz < 200 ms – dein Gegenüber unterbricht, der Agent verstummt innerhalb von 200 ms
• Genauigkeit der Tool Calls: tool_use_judge besteht im Szenario mit Kalenderabfrage, einschließlich des Cancel-on-Interrupt-Pfads
• Multi-Turn-Gedächtnis: Fixture mit 3 Turns (in Turn 1 nennt dein Gegenüber den eigenen Namen, in Turn 3 kommt die Frage danach) – accuracy_judge besteht
• Halluzinationsfalle: Nach einer nicht existierenden Reservierung gefragt, sagt der Agent, dass es keinen Eintrag gibt, statt einen zu erfinden – accuracy_judge besteht
• Regression: Nach dem Hardening in Aufgabe 10 die Baseline erneut laufen lassen; p50-Latenz innerhalb von ±10 % der ursprünglichen Baseline

Quellen

Jede Aussage, jedes Pattern und jede Abnahmeschwelle auf dieser Seite geht auf eine dieser Quellen zurück. Lies sie, bevor du von der Spec abweichst.

• ↗ LiveKit Agents – Framework für Voice, Video und Telefonie in Produktion github.com
• ↗ LiveKit Agent Starter (Python) – kanonische Referenzimplementierung github.com
• ↗ Pipecat – Frame-basiertes Framework für Echtzeit-Voice und Multimodalität github.com
• ↗ vocode-core – LLM-Apps mit Sprache, Schwerpunkt Telefonie github.com
• ↗ Dokumentation zu LiveKit Agents docs.livekit.io
• ↗ Using a transformer to improve end-of-turn detection livekit.com
• ↗ How to build the lowest latency voice agent in Vapi (~465ms end-to-end) assemblyai.com
• ↗ Voice AI pipeline: STT, LLM, TTS and the 300ms budget channel.tel
• ↗ Show HN: Dograh — an OSS Vapi alternative news.ycombinator.com
• ↗ Is there open source alternative for VAPI or retellai? news.ycombinator.com
• ↗ Launch HN: Retell AI (YC W24) — Conversational Speech API for Your LLM news.ycombinator.com
• ↗ Are Voice AI Pipeline Platforms a Race to the Bottom? news.ycombinator.com
• ↗ Show HN: Voicetest — open-source test harness for voice AI agents news.ycombinator.com

Bau das noch heute Abend in deine Codebase

Wähl deinen Stack anhand der fünf Entscheidungen in STACK.md und registrier dich: Diese Spec mit 10 Tasks landet auf deinem Board, dein Coding-Agent (Claude Code, Codex, Cursor) baut sie über den Tekk-MCP-Server, und der gemergte PR schließt sie. Nach dem Launch behält Tekks AI-Engineering-Loop den Agent weiter im Blick – Harness, Prompts, Tools, Kontext, Memory, Retrieval, Evals und Kosten – und bringt dir ein Proposal, sobald sich etwas ändern sollte. Lieber selbst machen? Öffne oben eine beliebige Task und klick auf Copy as Prompt – und füg den Prompt in Cursor, Claude Code oder Codex ein.

Verwandte Specs