oritera/Cairn: State-Space-Suche mit Fact-Intent-Graph statt Agentenrollen
A AI general-purpose state-space search engine, validated first on autonomous penetration testing.
Auf einen Blick
- Was ist das?
- Cairn beschreibt sich selbst als allgemeine Problemlösungsmaschine: gegeben ein Startpunkt und ein Ziel, sucht sie einen Pfad durch einen unbekannten Zustandsraum. Erprobt wurde das bisher vor allem im automatisierten Penetration Testing, der Rest ist Anspruch.
- Für wen ist es gedacht?
- Wer ein Problem mit klarem Startpunkt, klarem Erfolgskriterium und unbekanntem Pfad hat und bereit ist, einen Graph als einzigen Koordinationskanal zu akzeptieren, findet in Cairn ein ungewöhnlich schlankes Modell. Wer reproduzierbare, auditierbare Abläufe braucht, sollte zuerst prüfen, ob der Dispatcher als alleiniger Schreiber des Protokolls diese Anforderung überhaupt erfüllen kann.
- Darf ich es kommerziell nutzen?
- Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 8 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Startpunkt bekannt, Ziel bekannt, Weg unbekannt
Das README formuliert die Ausgangslage in einem Satz, der die ganze Konstruktion trägt: Penetration Testing sei eine gerichtete Suche durch einen nahezu unendlichen Zustandsraum. Die Herkunft ist bekannt (Ziel-IP, Zielsystem), das Ziel ist definiert (eine Shell, ein Flag), der Pfad dazwischen nicht. Cairn behauptet, diese Form sei nicht pentest-spezifisch. Vulnerability Research, mathematische Beweise, CTF-Aufgaben hätten dieselbe Gestalt. Das ist die eigentliche These des Projekts, und sie ist zugleich die Stelle, an der man es am härtesten befragen sollte. Adressiert sind Teams, die ein Problem mit überprüfbarem Erfolgskriterium haben und denen ein Agentenrahmen mit vordefinierten Rollen zu starr erscheint. Wer dagegen einen Chat-Assistenten mit Werkzeugkasten sucht, ist hier falsch: Cairn definiert laut README ausdrücklich keine Rollen und keine Workflows.
Fact, Intent, Hint: drei Primitiven und ein geteiltes Board
Die Architektur ist eine Blackboard-Architektur mit explizitem Fact-Intent-Graph. Ein Fact ist ein bestätigter, objektiver Fund, der auf das Board geschrieben wird. Ein Intent ist eine erklärte Explorationsrichtung, die noch nicht ausgeführt wurde. Ein Hint ist menschliches Urteil, das jederzeit eingeworfen werden kann und beim nächsten Lesen von den Agenten aufgenommen wird. Der Graph wächst von origin nach goal. Jeder Fact ist ein Trittstein, jeder Intent ein Schritt ins Unbekannte. Bemerkenswert ist, was hier fehlt: Es gibt keine Rollendefinitionen, keine vorgefertigten Jobbeschreibungen, keine MCP-Werkzeuge, kein RAG. Die Koordination läuft ausschließlich über das geteilte Board, das README nennt das Stigmergie. Keine direkte Kommunikation zwischen Agenten, keine Informationssilos. Das ist ein starkes Designversprechen, aber es verschiebt die Last: Wenn der Graph die einzige Kommunikationsfläche ist, dann hängt die Qualität des Systems an der Qualität dessen, was als Fact aufgenommen wird.
Drei Aufgabentypen, ein Worker, ein OODA-Loop
Laut README führen dieselben Worker drei Aufgabentypen aus. Bootstrap versucht zu Projektbeginn, das Problem direkt zu lösen, und liefert einen Fact sowie möglicherweise ein Complete. Reason liest den vollständigen Graphen, prüft, ob das Ziel erreicht ist, und entscheidet, was als Nächstes erkundet werden soll; Ausgabe ist Complete, neue Intents oder ein No-op. Explore beansprucht einen Intent, führt die Exploration aus und meldet einen Fact zurück. Die Worker laufen einen OODA-Loop: Observe über den ganzen Graphen, Orient am aktuellen Zustand, Decide über die nächsten Intents, Act zur Exploration, und die Ergebnisse gehen als neue Facts zurück aufs Board. Aufgaben entstehen zur Laufzeit aus dem Zustand des Graphen, nicht aus einem Stellenplan. Das ist der interessanteste Teil des Entwurfs, weil es die Frage verschiebt, wer welche Aufgabe bekommt, hin zu der Frage, was der Graph gerade hergibt. Ob Reason zuverlässig erkennt, wann ein No-op die richtige Antwort ist, lässt sich aus dem Material nicht beantworten.
Server, Dispatcher, Worker-Container: wer schreibt was
Die Aufteilung ist im README als Diagramm hinterlegt. Der Cairn Server hält ausschließlich die Konsistenz des Graphen, also Facts, Intents und Hints, und stellt eine Read/Write-API bereit. Der Cairn Dispatcher liest den Graphen, plant Aufgaben, startet und beendet Worker-Container und ist der einzige Schreiber des Protokolls. Jedes Projekt bekommt einen eigenen Worker-Container, darin laufen mehrere Agent Workers gleichzeitig. Diese Agent Workers erhalten nur einen Prompt und geben strukturierte Ausgabe zurück. Die Kette ist damit sauber getrennt: Server für Konsistenz, Dispatcher für Ablaufsteuerung und Protokoll, Worker für Ausführung. Ein einzelner Schreiber am Protokoll ist eine bewusste Einschränkung, die Konflikte vermeidet und zugleich einen Flaschenhals und einen Single Point of Failure schafft. Als Worker-Backends nennt das README Claude Code, Codex und Pi. Workers können statt in Containern auch direkt auf dem Dispatcher-Host laufen; dieser lokale Modus benötigt kein Docker.
Installation: Images ziehen, dispatch.yaml kopieren, Compose starten
Die Voraussetzungen sind im README knapp gehalten: macOS oder Linux, Python ab 3.12, Docker nur für die Container-Ausführung. Zuerst wird das Worker-Image gezogen, plattformspezifisch für linux/amd64: docker pull --platform=linux/amd64 ghcr.io/oritera/cairn-worker-container:latest. Danach wird die lokale Dispatcher-Konfiguration angelegt und mit LLM-Endpunkten und API-Schlüsseln gefüllt: cp dispatch.example.yaml dispatch.yaml. Für den empfohlenen Compose-Weg kommt zunächst das Basisimage, auf dem Cairn gebaut wird: docker pull ghcr.io/astral-sh/uv:python3.13-trixie. Anschließend docker compose up --build. Das startet cairn-server auf Port 8000 und den cairn-dispatcher, sobald der Server seinen Health Check bestanden hat. Der Dispatcher bindet dispatch.yaml aus dem Projektwurzelverzeichnis ein. Wer die Datei woanders ablegt, bekommt sie nicht eingebunden; das ist eine konkrete Stolperstelle, die direkt aus der Beschreibung folgt.
Was das Material nicht belegt
Die Ergebnisangaben beziehen sich auf einen Wettbewerb: Tencent Cloud Hackathon, AI Penetration Testing Challenge, zweite Ausgabe, 610 Teams, 1.345 Teilnehmende. Cairn gibt 54 von 54 gelösten Problemen an und Platz 3 in der Endwertung, mit dem Hinweis, das einzige Team mit vollständiger Lösung gewesen zu sein. Das README behauptet außerdem, das System sei vor dem Wettbewerb nie getestet worden; die vollständige Pipeline sei erst am Renntag um 4 Uhr morgens online gegangen, ohne Training, ohne Tuning, ohne domänenspezifische Werkzeuge. Solche Angaben sind aus der Ferne nicht überprüfbar. Wer sie als Reifegradnachweis liest, sollte wissen, dass ein einzelner Wettbewerbstag mit unbekannter Aufgabenverteilung keine Aussage über den Betrieb in einer echten Umgebung erlaubt. Die eigentliche Einschränkung liegt woanders: Cairn definiert keine Rollen und keine Workflows. Genau das macht es für offene Suchprobleme attraktiv und für regulierte Abläufe ungeeignet, in denen jeder Schritt einem festen Verfahren folgen muss. Wer Nachvollziehbarkeit über den Graphen hinaus braucht, muss selbst klären, ob der Dispatcher als alleiniger Protokollschreiber das leisten kann.
Abgrenzung zu Frameworks mit festen Agentenrollen
Die naheliegende Alternative ist ein Multi-Agent-Framework mit vorgegebenen Rollen, etwa ein Planner-Executor-Modell, in dem ein Planer Aufgaben zerlegt und ein Ausführer sie abarbeitet. Der Unterschied liegt nicht in der Anzahl der Agenten, sondern darin, woher die Aufgaben kommen. In einem Rollenmodell leitet der Planer die nächsten Schritte aus seinem eigenen Zustand ab; bei Cairn leitet der Dispatcher sie aus dem Graphen ab, und der Graph ist die einzige gemeinsame Fläche. Ein Rollenmodell lässt sich leichter nachvollziehen, weil die Zustandsübergänge im Planer lokalisiert sind. Cairn verteilt diesen Zustand auf Facts und Intents, was mehr Freiheitsgrade erlaubt und die Fehlersuche erschwert. Die zweite Abgrenzung betrifft den Umfang: Ein Rollenframework bringt typischerweise Werkzeuganbindung, Speicher und Auswertung mit. Cairn bringt bewusst nichts davon mit, keine MCP-Werkzeuge, kein RAG. Wer diese Bausteine erwartet, muss sie selbst ergänzen oder ein anderes Werkzeug wählen.
Lizenz und laufender Aufwand
Cairn steht unter AGPL-3.0. Wer das Projekt einbettet und die geänderte Fassung über ein Netzwerk zugänglich macht, sollte die Bedingungen dieser Lizenz vorher mit der eigenen Rechtsabteilung klären; eine Einschätzung, ob der konkrete Einsatz darunterfällt, kann hier nicht gegeben werden. Zu den laufenden Kosten macht das README keine Angaben. Ableiten lässt sich nur die Struktur: Jedes Projekt erhält einen eigenen Worker-Container, darin laufen mehrere Agent Workers gleichzeitig, und jeder von ihnen spricht mit einem LLM-Backend. Der Verbrauch skaliert also mit der Zahl gleichzeitiger Worker und mit der Zahl der Explore-Aufgaben, die der Graph erzeugt. Ein Upgrade auf eine neue Version bedeutet bei diesem Zuschnitt mindestens, dass Server und Dispatcher gemeinsam aktualisiert werden müssen, weil der Dispatcher als einziger Schreiber des Protokolls direkt an die Graph-API gebunden ist. Die Versionshistorie ist kurz: v0.1.0 im Mai, v0.2.0 wenige Tage später, v0.2.1 ebenfalls im Mai. Bei einem Projekt in diesem Alter ist damit zu rechnen, dass sich Schnittstellen zwischen den Komponenten noch bewegen.
Redaktionelles Fazit
Wer ein Problem mit klarem Startpunkt, klarem Erfolgskriterium und unbekanntem Pfad hat und bereit ist, einen Graph als einzigen Koordinationskanal zu akzeptieren, findet in Cairn ein ungewöhnlich schlankes Modell. Wer reproduzierbare, auditierbare Abläufe braucht, sollte zuerst prüfen, ob der Dispatcher als alleiniger Schreiber des Protokolls diese Anforderung überhaupt erfüllen kann. Und wer den Docker-Pfad wählt, sollte vor dem ersten Lauf sicherstellen, dass dispatch.yaml im Projektwurzelverzeichnis liegt, weil der Dispatcher sie genau dort einbindet.
Community-Notizen