4 Punkte von GN⁺ 2026-03-28 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Struktur, die einen IRC-basierten AI-Agenten mit einer persönlichen Portfolio-Website verbindet, sodass Besucher Fragen auf Basis der tatsächlichen Analyse des Codes in GitHub-Repositories beantwortet bekommen können
  • Nicht als einfacher Chatbot zur Zusammenfassung eines Lebenslaufs, sondern als ausführender Agent konzipiert, der Repository-Klonen, Testberechnungen und Codevalidierung durchführt
  • Das System ist in zwei Agenten aufgeteilt, den öffentlichen nullclaw und den privaten ironclaw, die über das Tailscale-Netzwerk sicher miteinander kommunizieren
  • Durch die Wahl des IRC-Protokolls als Transportebene werden Self-Hosting, Standardisierung und niedrige Kosten zugleich erreicht; außerdem werden die Modelle Haiku 4.5 und Sonnet 4.6 nach Rollen getrennt eingesetzt, um die Kosten auf 2 $ pro Tag zu begrenzen
  • Das Gesamtsystem läuft mit weniger als 10 MB Binärdateien und weniger als 5 MB Speicher und wird als Beispiel für eine leichtgewichtige AI-Infrastruktur vorgestellt, die Sicherheit, Kostenkontrolle und Transparenz vereint

Einen digitalen Doorman bauen

  • Eine Struktur, bei der ein AI-Agent auf einem VPS für 7 $/Monat bereitgestellt und ein persönlicher IRC-Server als Transportebene verwendet wird, verbunden mit GitHub-Repositories
    • Besucher können dem AI auf der Portfolio-Website Fragen stellen und Antworten erhalten, die auf echtem Code basieren
    • Kein einfacher Chatbot, der nur den Lebenslauf zusammenfasst, sondern konkrete Antworten durch Codeanalyse

Die Grenzen eines „Chatbots, der nach dem Lebenslauf gefragt wird“

  • Die meisten Portfolio-Chatbots bleiben dabei, den Inhalt eines Lebenslaufs in ein Modell einzuspeisen und neu zu formulieren
  • Dieser Ansatz liefert keine neuen Informationen und ist kaum mehr als eine formelhafte Unterhaltung
  • Auf Fragen wie „Wie verwaltest du die Testabdeckung?“ sind konkrete Antworten nötig, etwa indem das Repository geklont und die Anzahl der Tests berechnet wird
  • Dafür wurde eine Infrastruktur mit direktem Codezugriff und Analysefähigkeit aufgebaut

Systemarchitektur

  • Besteht aus zwei Agenten, zwei Servern und zwei Sicherheitsgrenzen
    • nullclaw: öffentlicher Doorman, 678-KB-Zig-Binärdatei, etwa 1 MB RAM
      • Begrüßt Besucher, beantwortet projektbezogene Fragen, klont GitHub-Repositories und führt codebasierte Validierung durch
    • ironclaw: privater Backend-Agent, läuft auf einem separaten System
      • Hat Zugriff auf E-Mails, Kalender und persönlichen Kontext
      • Erhält komplexe Anfragen von nullclaw über den IRC-Kanal #backoffice
  • Beide Systeme sind über Tailscale verbunden; der öffentliche Server hat keinen Zugriff auf persönliche Daten

Warum IRC gewählt wurde

  • Ästhetische Konsistenz: Da die Portfolio-Website auf einer Terminal-UI basiert, wirkt ein IRC-Client natürlich
  • Vollständiges Self-Hosting: Ergo-IRC-Server, gamja-Webclient und nullclaw laufen alle auf eigener Infrastruktur
  • Einfaches und standardisiertes Protokoll: Das 30 Jahre alte IRC bedeutet keine Vendor-Lock-in-Abhängigkeit und kein Risiko durch API-Änderungen
  • Derselbe Agent funktioniert nicht nur im Webclient, sondern auch im irssi-Terminalclient identisch

Modellauswahl und Design

  • Der Einsatz großer Modelle ist ineffizient, daher werden Modelle je nach Rolle getrennt
    • Haiku 4.5**: für Konversation und einfache Anfragen,** Antworten mit extrem niedriger Latenz

      • Sonnet 4.6: wird nur für Codeanalyse und komplexes Reasoning verwendet
      • Kostenobergrenze: begrenzt auf 2 $ pro Tag und 30 $ pro Monat
      • Verhindert explodierende Kosten durch missbräuchliche Nutzung oder übermäßig lange Gespräche
      • Durch eine mehrstufige Reasoning-Struktur werden Geschwindigkeit und Kosteneffizienz zugleich erreicht

Sicherheitsdesign

  • SSH: Root-Login deaktiviert, nur Schlüsselauthentifizierung erlaubt, nicht standardmäßiger Port
  • Firewall: Nur SSH, IRC (TLS) und HTTPS (WebSocket) geöffnet
  • Cloudflare-Proxy: TLS-Terminierung, Rate Limiting und Bot-Filterung
  • Agent-Sandbox: Nur schreibgeschützte Tools erlaubt, auf 10 Aktionen pro Stunde begrenzt
  • Kostenkontrolle: harte Obergrenzen von 2 $ pro Tag und 30 $ pro Monat
  • Audit-Logs und automatische Updates aktiviert
  • Minimierte Angriffsfläche: Es laufen nur die zwei Dienste ergo und nullclaw, keine direkte Auslieferung von Webinhalten
  • Im Fall einer Kompromittierung ist der Schaden auf einen IRC-Bot mit einem Limit von 2 $ pro Tag begrenzt

Aufbau des Kommunikations-Stacks

  • Alle Komponenten sind klein, selbst gehostet und austauschbar
    • Ergo: IRC-Server, einzelne Go-Binärdatei, 2,7 MB RAM
    • gamja: Web-IRC-Client, 152-KB-statische Seite, hinter Cloudflare bereitgestellt
    • nullclaw: Laufzeit des AI-Agenten, 4-MB-Zig-Binärdatei, nutzt etwa 1 MB Speicher
  • Das Gesamtsystem läuft mit weniger als 10 MB Binärdateien und weniger als 5 MB Idle-Speicher
  • Es lässt sich selbst auf der günstigsten VPS-Stufe problemlos betreiben

Die tatsächlichen Funktionen von nully (öffentlicher Agent)

  • Programmiersprachen erkennen: durch vorab geladenen Kontext und Repository-Verifizierung
  • Teststruktur analysieren: klont das Repository, liest Testdateien direkt und berichtet das Ergebnis
  • Projekte erklären: beantwortet zum Beispiel Details zum Projekt Fracture auf Basis des Codes
  • Kontaktinformationen geben: liefert nur genaue Kontaktdaten und erfindet keine falschen Angaben
  • Anfragen zur Terminvereinbarung: werden über das Google-A2A-Protokoll an ironclaw weitergeleitet; das Ergebnis wird strukturiert zurückgegeben
  • Besucher bemerken den Wechsel zum Backend nicht

A2A-Implementierung

  • Unterstützt das Google-A2A-Protokoll (v0.3.0) und verwaltet Aufgabenstatus auf JSON-RPC-Basis
  • Das Tool a2a_call sendet Nachrichten an einen entfernten Agenten und parst den Aufgabenstatus (abgeschlossen/fehlgeschlagen/in Bearbeitung)
  • HTTPS wird erzwungen, nur im internen Tailscale-Netzwerk ist HTTP zum einfacheren Debugging erlaubt
  • Struktur auf der ironclaw-Seite

    • Die nullclaw-Instanz verwendet ohne eigenen API-Schlüssel den LLM-Gateway von ironclaw als Proxy
    • Es muss nur eine einzige API-Key- und Abrechnungsbeziehung gepflegt werden
    • ironclaw verarbeitet alle Inferenzanfragen und trägt die Kosten

Sicherheit beim Handoff

  • Der A2A-Endpunkt birgt Prompt-Injection-Risiken, daher gelten strenge Beschränkungen
    • An ironclaw weiterleitbare Anfragen sind auf Termine, Kontakte und Verfügbarkeit begrenzt
    • Die Übergabe beliebiger Befehle wird abgelehnt
    • Der A2A-Endpunkt von ironclaw ist durch eine nur für Tailscale geltende Firewall geschützt
    • Beide Agenten laufen sowohl im Überwachungsmodus als auch mit einer eingeschränkten Allowlist zulässiger Befehle
  • nully entscheidet, ob eine Anfrage eskaliert wird, um wahllose Befehlsausführung zu verhindern

Erkenntnisse aus dem Aufbau

  • Die Modellauswahl ist Teil des Systemdesigns und beeinflusst Kosten, Latenz und Nutzererlebnis direkt
  • Für Kommunikation, Sicherheit und Infrastruktur wurde mehr Zeit aufgewendet als für den Agenten selbst
  • Die Einfachheit und Offenheit von IRC macht es ideal als Transportebene für AI-Agenten
  • Die Trennung zwischen nullclaw und ironclaw ist der Kern des Sicherheitsmodells
  • Durch die Kombination aus A2A-Protokoll und IRC-Log-Kanal werden strukturierte Kommunikation und Echtzeit-Sichtbarkeit zugleich erreicht
  • Vermeidung doppelter Zugangsdaten: Durch den Proxy über den Gateway von ironclaw bleibt es bei einem API-Schlüssel und einer einzigen Abrechnungsbeziehung

So kann man es ausprobieren

  • georgelarson.me/chat besuchen oder auf der Startseite im Terminal irc eingeben
  • Bei Verwendung eines IRC-Clients: irc.georgelarson.me, Port 6697 (TLS), Kanal #lobby
  • nully wartet dort und kann in Echtzeit mit Besuchern sprechen

1 Kommentare

 
GN⁺ 2026-03-28
Hacker-News-Kommentare
  • Wenn ein OpenClaw-Agent, der Zugriff auf E-Mails und persönliche Daten hat, kompromittiert wird, kann das Schadensausmaß sehr groß sein
    Das geht weit über das Niveau eines einfachen IRC-Bots hinaus; ein Angreifer könnte Passwörter zurücksetzen, um API-Beschränkungen aufzuheben, oder ihn sogar als Hub zum Teilen illegaler Inhalte missbrauchen

    • Ich kenne auch Leute, die solche OpenClaw-Agenten auf einem Mac Mini laufen lassen; seltsam, dass Menschen, die sonst sehr auf Sicherheit achten, für dieses Risiko so unempfindlich sind
    • Wenn das stimmt, was du sagst, dann wirkt das wie ein Beispiel dafür, wie Menschen sich in einer „Umgebung ohne Sicherheitsgeländer“ verhalten
  • Ich habe mich gefragt, warum Haiku/Sonnet gewählt wurde. Bei OpenRouter gibt es deutlich günstigere Modelle
    Haiku 4.5 kostet zum Beispiel $1 pro 1 Million Input-Token und $5 für Output, während MiniMax M2.7 bei $0.30 Input und $1.20 Output liegt und Kimi K2.5 bei etwa $0.45 Input und $2.20 Output
    Meiner Erfahrung nach liefern M2.7 und K2.5 eine ähnliche oder sogar bessere Leistung als Haiku

    • Wenn man das öffentlich über IRC betreibt, könnten Safety Rails ein wichtiger Faktor sein
      Ich nutze deshalb bei meinen jüngsten Agenten ebenfalls Anthropic-Modelle. Haiku lässt sich auch dann gut steuern, wenn Nutzer merkwürdige Anfragen stellen, und geht stabil mit emotionalen Gesprächen um
    • Xiaomi Mimo v2-Flash war hervorragend. In meinem Benchmark war es 8 % schneller als Haiku und 80-mal günstiger. Gemini 3.1 Flash Lite Preview ist ebenfalls eine gute Wahl
    • MiniMax M2.7 ist auch fürs Coding ziemlich brauchbar, aber Opus 4.6 ist immer noch eine Klasse darüber
    • Der Token Plan von MiniMax ist günstiger, und Agent-Nutzung ist dort ausdrücklich erlaubt
    • Ich denke, schon Gemini Flash3 ist besser als Haiku
  • IRC ist als Transportschicht gut, aber es gibt keine Zustellgarantie (delivery guarantee). Wenn die Verbindung abbricht, gehen die Nachrichten aus dieser Zeit verloren
    Für Echtzeit-Chat ist das okay, aber ein Agent, der echte Aufgaben bearbeitet, braucht at-least-once-Zustellung
    SSE (Server-Sent Events) ist ein brauchbarer Mittelweg. Man kann eine dauerhafte Verbindung halten und eine Wiederholungslogik ergänzen

    • Allerdings gibt es bei IRC schon seit langer Zeit Bouncer, daher ist eine technische Umsetzung von at-least-once durchaus möglich
  • Ich habe einmal in einem Zug von Tokio nach Osaka einen Bot mit einer ähnlichen Idee gebaut
    web-support-claw.oncanine.run — ein Projekt, das ein GitHub-Repo liest und daraus einen Intercom-Bot für Websites erstellt
    Er beantwortet die Fragen von Besuchern, sodass man keine separate Wissensdatenbank aufbauen muss

    • Wenn jedoch Anfragen möglich sind wie „Analysiere bitte die Schwachstellen der Zahlungsseite“ oder „Finde den hartkodierten Secret Key“, ist das ein Sicherheitsrisiko
  • Für die Zukunft würde ich empfehlen, eine Haiku-Instanz nur zur Überwachung einzusetzen. Benachrichtigungen könnte man auch über ntfy bekommen
    Der aktuelle Chatraum ist völlig außer Kontrolle

    • Es gibt auch einen einfacheren Weg. Man erstellt für jeden Besucher einen neuen Chat-Thread und beendet ihn nach einer gewissen Zeit.
      Für den Zweck eines „interaktiven Lebenslaufs“ sind Interaktionen mit einer undefinierten Öffentlichkeit nicht nötig
  • Unser Team nutzt ebenfalls eine ähnliche Struktur. Vier Agenten (Vertrieb, Social, Finanzen, Strategie) kommunizieren über ein FastAPI + SQLite-basiertes Message Board
    Statt eines täglichen Budgetlimits verwalten wir die Kostenobergrenze in einer Governance-Schicht
    Die Pub/Sub-Struktur von IRC passt gut zu Multi-Agent-Kommunikation, aber wir verwenden HTTP-Polling + Deduplizierung. Weniger elegant, dafür leichter wiederherstellbar, selbst wenn Agenten häufig abstürzen

  • Ich nutze bei einem Coding-Agenten ebenfalls IRC als Interface
    Ich wechsle zwischen Räumen, um Prompts umzuschalten, und steuere Projekte aus der Ferne

    • Ich frage mich, ob IRC immer noch eine Begrenzung der Nachrichtenlänge hat
    • Ich nutze es auf dieselbe Weise; ein Vergleich wäre interessant
  • Es hieß, dass die „öffentliche Box keinen Zugriff auf persönliche Daten hat“; daraus könnte man eine interessante CTF-Challenge machen
    Man versteckt eine Flag in der privaten Box und zahlt 50 Dollar an jeden, der darauf zugreift und sie herausholt

  • Der Ton von nully ist etwas rau, aber die gesamte Systemarchitektur gefällt mir
    Ich nutze ebenfalls eine geschichtete Struktur, und die unterste Ebene ist ein lokaler Qwen-Bot
    Mich interessiert die Eskalationslogik von Haiku zu Opus

    • Ich nutze eine Struktur, bei der Anfragen von Haiku zu Opus hochgestuft werden, wenn sie komplexer werden. Das ist von Claude Codes Konzept „think hard“ inspiriert
    • Wenn man die Meldung „An error occurred“ durch „Derzeit gibt es viele Nutzer. Bitte versuchen Sie es später noch einmal“ ersetzt, wirkt das auf Recruiter vermutlich attraktiver
  • Die Idee ist wirklich spannend. Ich bekomme Lust, einen Bot zu bauen, der den Recruiting-Prozess automatisiert
    Er würde in Interviews die Neigungen eines Kandidaten erfassen, passende Stellen finden und die Bewerbung dann automatisch abschicken
    Wenn auch die Bots der Unternehmen Kandidaten auf dieselbe Weise bewerten, ließe sich ein Matching nach den Präferenzen beider Seiten erreichen
    Das könnte vollständig Open Source und self-hosted umgesetzt werden und deutlich bessere Signale liefern als ein Lebenslauf

    • Noch besser wäre es, wenn der Bot sogar unbezahlte Aufgaben stellvertretend erledigen würde und der HR-Bot dann anhand des Ergebnisses über eine Einstellung entscheidet
    • Triplebyte hat früher etwas Ähnliches versucht; vielleicht ist es Zeit für ein Revival
    • Allerdings sind die Recruiting-UIs der Unternehmen alle unterschiedlich, daher bräuchte ein Bot viel Training, um sich automatisch auf allen Websites zu bewerben
    • Wenn so ein System entsteht, könnte es von Spam-Bewerbern oder gefälschten Accounts überschwemmt werden
    • Tatsächlich arbeite ich bereits an genau so einem Projekt