Persönliche KI-Agenten-Infrastruktur

Zwei Maschinen, ein Assistent

   Nyx — Desktop, Heimnetz         Button — Root-Server, immer an
 +-------------------------------+   +-------------------------------+
 | Wake Word + VAD (auf Geraet)  |   | HTTPS-Gateway (Uhr, Handy)    |
 | Sprache rein/raus, HUD        |   | Agenten-Sitzungen headless    |
 | Lautsprecher, Scanner, Doks   |<=>| 21 MCP-Server                 |
 | 4 MCP-Server                  |ssh| Dashboard-Collector, Dienste  |
 +-------------------------------+   +-------------------------------+

Die Trennung ist keine Symmetrie, sondern Erreichbarkeit. Werkzeuge, die das Heimnetz brauchen — Lautsprecher, Scanner, alles mit lokaler Adresse — funktionieren nur vom Desktop aus. Alles andere liegt auf dem Server, weil der immer läuft. Ein Hook sagt jeder Agenten-Sitzung beim Start, auf welcher der beiden Maschinen sie aufgewacht ist — die Antwort ändert, was sie darf.

Geroutet wird zwischen beiden per Stichwortabgleich, nicht per Modellaufruf. Ein Modell zu fragen, wo die Anfrage laufen soll, hätte pro Runde einen zusätzlichen Durchlauf gekostet — und damit genau die Ersparnis aufgefressen, für die der Wechsel auf die lokale CLI gemacht wurde.

Wege hinein

• Sprache Wake Word und Sprachaktivitätserkennung laufen auf dem Gerät — Audio verlässt den Rechner erst nach dem Wake Word. Barge-in ist keine Funktion, sondern fällt aus dem Threadaufbau heraus ab: der Hauptthread blockiert nie, hört also weiter zu, während der Assistent noch spricht.
• Smartwatch Eine Wear-OS-App schickt an einen HTTPS-Endpunkt auf dem Server. Sie bekommt 202 nach ~15 ms statt der ~25 s, die eine ganze Runde dauert — ein so lange offener Request überlebt im Mobilfunk weder Androids Doze noch einen Netzwechsel.
• Der Rückweg Die Antwort kommt als Push-Data-Message zurück, bewusst nicht als Notification: die würde Android selbst anzeigen, ohne die App je zu wecken — und die ist zu dem Zeitpunkt fast immer längst beendet.
• Handy Eine eigene Android-App, derselbe Weg in den Gateway.
• Schreibtisch Die CLI direkt, dazu ein kleines dauerhaft sichtbares Fenster, das zeigt, ob der Assistent bereit ist, zuhört, nachdenkt oder spricht.
• Musik Nimmt einen Schnellpfad komplett am Modell vorbei: 0,03–0,26 s statt 7–33 s, quittiert mit zwei kurzen Tönen statt mit einem gesprochenen Satz — das Ergebnis hört man ja ohnehin.

Die Werkzeugschicht

Alles, was der Assistent tatsächlich tun kann, hängt hinter dem Model Context Protocol: 21 Server auf dem Root-Server, 4 auf dem Desktop. Nachrichten, Aufgaben und Notizen, Medien und Hausgeräte, Gesundheits- und Trainingsdaten, Dokumente, ein Browser, eine Literatursuche.

Fünf davon habe ich selbst geschrieben, weil es keinen brauchbaren Server gab — darunter die Lautsprecher, eine Chat-Plattform und zwei Geräteanbindungen, für die es gar keine öffentliche API gibt. Drei weitere sind fremde Projekte mit lokalen Patches. Beides liegt in einem eigenen Repository, getrennt vom Betriebsort: die laufenden Installationen enthalten Token und Sitzungsdaten und werden bewusst nicht gesynct — womit sie die einzige Kopie von Arbeit waren, die sich nicht nachinstallieren lässt.

Dieselbe Sammlung ist auch der Grund, warum das persönliche Dashboard über dieselben MCP-Server einsammelt, statt ein Dutzend Hersteller-APIs selbst anzusprechen. Anmeldung, Token-Refresh und die lokalen Reparaturen gibt es schon einmal. Zweimal bauen heißt zweimal kaputtgehen.

Eine Kette, durchgehend

 Uhr --> Handy (Health Connect) --> selbst gebaute Android-App
     --> Gateway --> SQLite --> MCP-Server --> Agent / Dashboard

Das deutlichste Beispiel dafür, wie weit es reicht. Der Hersteller bietet keine Consumer-Cloud-API, also wurde das fehlende Glied gebaut: eine Android-App, die den Gesundheitsspeicher des Handys liest und alle 30 Minuten an den Server schickt. Ab da ist es eine normale MCP-Quelle — der Assistent kann daraus antworten und das Dashboard stellt es dar, ohne dass einer von beiden wissen muss, woher es kommt.

Gedächtnis und Konfiguration

• Drei Konfigurationen Eine private, zwei berufliche, auf einem Desktop, per Umgebungsvariable ausgewählt. Alles Gemeinsame — Hooks, Statuszeile, Gedächtnis — liegt in einem Verzeichnis außerhalb aller drei und wird von dort über absolute Pfade referenziert. Keine Konfiguration darf in eine andere zeigen; genau diese Regel verhindert, dass eine Änderung still ins Leere läuft.
• Persistentes Gedächtnis Eine Datei je Fakt, dazu ein kurzer Index, der in jede Sitzung geladen wird. Die Speicher sind über alle drei Konfigurationen symlinked — was ein Setup lernt, wissen die anderen.
• Leitplanken als Hooks Nicht als gute Vorsätze. Ein Hook vor jedem Werkzeugaufruf verweigert git push auf einen Branch, dessen Pull Request schon gemergt oder geschlossen ist — er prüft den Zustand, was kein Linter tut.
• Aufgeschriebene Entscheidungen Jedes Projekt trägt eine Datei für den Agenten, die Entscheidungen und Sackgassen festhält statt der Bedienung — die des Assistenten ist auf 120 KB gewachsen. Sie ist der Grund, warum eine Sitzung sechs Wochen später nicht neu aufrollt, was längst entschieden und gemessen war.
• Ein Worktree je Aufgabe Mehrere Agenten-Sitzungen arbeiten gleichzeitig im selben Repository, manche davon für eine zweite Person unter Windows, die kein Git benutzt und deshalb eine strengere PR-Regel bekommt. Landet eine Sitzung mitten im Branch einer anderen, ist das schwer zu entwirren — also legt keine Sitzung je im Haupt-Checkout einen Branch an.

Was ich falsch gemacht habe

• „Erst das billige Modell, im Zweifel eskalieren" ist die falsche Voreinstellung. Die Triage schickte jede Runde zuerst an das kleine Modell und eskalierte immer dann, wenn die Antwort nicht dem erwarteten Format entsprach. Damit wurde eine richtige billige Antwort weggeworfen und durch eine erfundene teure ersetzt. Eskaliert wird jetzt nur noch auf eine ausdrückliche Markierung. Eskalation im Zweifel bevorzugt still die möglicherweise falsche teure Antwort gegenüber der möglicherweise richtigen billigen.
• Kosten gegen Latenz — bewusst entschieden, nicht wegoptimiert. Runden über die lokale CLI statt über die API zu fahren, hat jede Antwort von ~3 s auf ~7–10 s gebracht. Bewusst akzeptiert. Die Lücke deckt eine gesprochene Zwischenmeldung mit leisen Tönen ab, und diese Phrasen liegen als Audiodateien im Cache, dessen Schlüssel einen Hash der Stimmkonfiguration enthält — eine geänderte Stimme entwertet den Cache dadurch von selbst, statt beim Start noch in der alten zu sprechen.
• Lokal ist nicht automatisch besser. Vollständig lokale Sprachsynthese wurde gebaut, gemessen und wieder verworfen: günstig, und sie klang schlecht. Wake Word und Erkennung blieben auf dem Gerät, weil die lokale Variante dort auch die bessere ist. „Läuft lokal" ist ein Argument über Datenschutz und Kosten, nicht über Qualität — das zu verwechseln kostet einen Abend.
• Erst prüfen, was es schon gibt. Ein Systemcheck beim Start stand kurz davor, von Grund auf geschrieben zu werden. Das Dashboard veröffentlichte seit Wochen alle 30 Minuten ein ok-Feld. Es zu lesen kostet 0,4 s und keine Pflege.
• Eine Kette austauschbarer Stufen schlägt eine integrierte API. Eine Realtime-Sprach-API wäre pro Runde ein bis zwei Sekunden schneller. Aber bei einer schlechten Antwort sehe ich im Log, ob die Transkription oder das Modell schuld war, jede Stufe lässt sich mit einer neuen Datei und einer Zeile ersetzen, und ein Anbieterwechsel ist kein Neubau. Denselben Handel vertrete ich im Beruf.

Was darauf läuft

• Ein persönliches Dashboard, dessen Collector über die MCP-Schicht lesen; der Webserver rechnet nichts, deshalb leert eine ausgefallene Quelle nie eine Seite
• Diese Seite, durchgehend über den Agenten selbst gebaut
• Ein Werkzeug-Ökosystem für eine laufende Pen-&-Paper-Kampagne — Bots, Zusammenfassungen, eine Bild- und Audio-Pipeline
• Community-Server und Container, die seit 2011 beziehungsweise 2020 laufen
• Eine Ersatzteil-Übersicht für ein Familienmitglied, per Browsersteuerung durch den Agenten erzeugt und hinter Basic Auth veröffentlicht