Kategorie: Einblicke

Wenn du eine Software entwickelst und Dutzende Ansätze ausprobierst, hast du nach Stunden die beste Lösung – aber die Zwischenschritte sind nur in deinem Kopf oder in verstreuten Notizen. Experience Graphs speichern diese Erfahrungsstruktur in einer durchsuchbaren, wiederherstellbaren und gemeinsam nutzbaren Form. Sie sind das Datenfundament für KI-Agenten, die iterativ nach besseren Lösungen suchen.

Gang Liao und Kollegen von der University of Maryland und Meta schlagen mit Trellis eine Datenbank-Architektur vor, die diesen Experience Graph speichert. Bisher behandeln Agenten-Frameworks diese Daten als flüchtigen Zustand: JSON-Checkpoints und Sitzungslogs, die nach einem Absturz verloren sind. Trellis lagert den Experience Graph in eine Datenbank aus und macht frühere Probleme zu Abfragen.

Jeder Schritt wird zum Knoten

Agenten für Codegenerierung, wissenschaftliche Entdeckungen oder Hardware-Optimierung arbeiten nicht mit einem Durchlauf. Sie explorieren: Sie erzeugen Artefakte, führen Werkzeuge aus, beobachten Fehler, verzweigen, reparieren und vergleichen Alternativen. Jeder Schritt erzeugt einen Knoten im Experience Graph: das Prompt, das Artefakt, die Tool-Ausgaben, eine Bewertung, die Verbindung zum Elternknoten und zu Geschwistern. Dieser Graph ist ein kausaler Baum von Versuchen, kein bloßes Wissen.

Die Autoren kritisieren die übliche Einteilung in deklaratives, prozedurales und episodisches Gedächtnis. Sie erfasst nicht den Experience Graph, der entsteht, wenn ein Agent über viele Sessions sucht. Produktionssysteme wie Metas KernelEvolve haben die Schmerzgrenze erreicht: Fortschritt ging bei Abstürzen verloren, parallele Arbeiter brauchten ad-hoc-Koordination, frühere Entdeckungen ließen sich nicht wiederverwenden. Die Lösung: die Datenbasis ändern.

Eine Architektur aus zwei Schleifen

Die Autoren schlagen eine Zwei-Schleifen-Architektur vor. In der inneren Schleife arbeiten Agenten als zustandslose, serverlose Funktionen – sie erhalten eine Aufgabe, generieren einen Knoten, evaluieren und terminieren. Die äußere Schleife entscheidet anhand einer Suchstrategie (gierig, MCTS, evolutionär), welcher Knoten als nächstes expandiert wird. Der Graph liegt persistent in Trellis, einer Datenbank für diese Zugriffsmuster: Anhängen von Knoten, Aktualisieren von Pfaden, Vektor-Ähnlichkeitssuche für Wiederverwendung und Zeitreise-Abfragen.

Die Vorteile: Crash Recovery wird trivial, da der Graph in der Datenbank gespeichert ist. Zweitens: Wiederverwendung über Sessions hinweg – ein Agent kann den Graph ähnlicher Suchen durchsuchen, per Vektor-Embedding vielversprechende Teilbäume identifizieren und als Startpunkt nutzen. Drittens: Datenextraktion für Training – der Graph liefert alle Knoten mit hohem Reward per Datenbank-Abfrage. Viertens: Horizontale Skalierung – zustandslose Agenten lassen sich parallel laufen lassen, die Datenbank übernimmt die Konsistenz.

Messbare Vorteile und Grenzen

In einer kontrollierten Studie mit KernelEvolve erreichten die Agenten mit Trellis eine Zielbeschleunigung etwa 10-mal schneller, bei 52 % niedrigeren Token-Kosten pro gültiger Lösung. Allerdings zeigte sich ein Exploration-Anker-Effekt: zu starker Fokus auf bisherige Lösungen kann die Exploration neuer Regionen beeinträchtigen. Der Trade-off muss bewusst gesteuert werden.

Die Autoren argumentieren, dass Experience Graphs eine ähnliche Transformation auslösen könnten wie Logs für Datenbanken. Früher waren Logs flüchtige Dateien – heute sind sie zuverlässig, durchsuchbar und wiederherstellbar. Genauso könnten Experience Graphs zu einem dauerhaften Vermögenswert werden. Wenn jeder KI-Agent seine Sucherfahrungen in einer gemeinsamen Datenbank ablegt, entsteht ein kumulativer Wissensschatz.

Offene Fragen für die Forschung

Trellis ist kein ausgereiftes Produkt, sondern eine Systemarchitektur, die viele Forschungsfragen aufwirft: Wie plant man Abfragen über multimodale Daten? Wie hält man Konsistenz bei parallelen Suchstrategien? Wie gestaltet man das physische Layout für typische Zugriffsmuster? Wie bildet man bi-temporale Aspekte ab? Das sind offene Probleme – sie zeigen, dass die Datenbank-Community hier eine entscheidende Rolle spielen kann.

Die nächste Generation von KI-Werkzeugen braucht nicht nur bessere Modelle, sondern auch klügere Datenhaltung. Statt jeden Agenten wie eine Einweg-Applikation zu behandeln, versteht man die Suche als Datenbank-Problem. Experience Graphs sind kein akademisches Konzept – sie ermöglichen selbstverbessernde Agenten. Wie ein Spalier das Wachstum einer Pflanze lenkt, ohne selbst zu wachsen, gibt diese Datenbasis den Agenten Halt, weiterzukommen.

Quelle: arxiv.org

Früher trainierte man für jede Fachdomäne ein eigenes Sprachmodell. Man baute einen Tokenizer für Fachbegriffe, feinjustierte die Gewichte auf domänenspezifische Texte. Das Ergebnis war ein massgeschneidertes Modell. In der Praxis hob dieser Ansatz nie richtig ab. Der Trade‑off war zu gross: spezialisieren auf eine Nische heisst Allgemeinheit verlieren. Die meisten Unternehmen brauchen ein Modell, das Fachsprache und allgemeine Anfragen beherrscht. Alan Yahya, ein erfahrener KI‑Infrastrukturentwickler, erklärt, warum dieser Weg scheiterte und welche Richtung sich abzeichnet.

Die Spezialisierung verlagert sich aus den Modellgewichten in die Umgebung des Modells – in sogenannte Harnesses. Ein Harness ist die Softwarearchitektur, die das Modell umgibt und steuert. Er verwaltet Gedächtnis, Informationsabruf, Planung und Werkzeuge. Das Modell selbst ist stateless. Der Harness liefert Anweisungen, Kontext, Werkzeuge, Fehlerbehandlung. So wird die Anpassung an eine Domäne zur Konfigurationsfrage, nicht zum Neutrainieren. Yahya betont: Diese Verlagerung erhält die Allgemeinheit des Modells und erlaubt gleichzeitig tiefe Spezialisierung.

Gedächtnis und Werkzeuge im Harness

Ein zentrales Element eines Harness ist das Gedächtnis (Memory). Informationen in einer Fachdomäne lassen sich als Graph oder Ontologie abbilden. Ein juristischer Harness behält rohe Dateiverweise, damit das Modell jederzeit den Originaltext nachschlagen kann. In einem Forschungsumfeld, wo konzeptuelle Zusammenfassungen wichtiger sind, darf der Agent verdichten und abstrahieren. Die Compaction – die Strategie, wie der Harness den Arbeitskontext verwaltet – entscheidet, was bewahrt, wie es repräsentiert und was verworfen wird. Im Recht wäre es fahrlässig, Quellverweise zu löschen; in der kreativen Textarbeit reicht eine Zusammenfassung. Dieser Unterschied macht den Harness zu einem mächtigen Hebel für Domänenanpassung, ohne die Modellgewichte zu berühren.

Werkzeuge (Tools) sind der zweite Baustein. Sie geben dem Modell die Fähigkeit, die Aussenwelt zu beobachten oder zu verändern: Suchen, Dateizugriff, Code‑Ausführung, API‑Aufrufe, Datenbankabfragen. Ein Harness kann domänenspezifische Ein‑ und Ausgaben erzwingen, Validierungsschleifen einbauen und sicherstellen, dass der Agent vor einer Änderung eine bestimmte Datenbank konsultiert. Yahya beschreibt dies als Möglichkeit, die korrekte Verwendung domänenspezifischer Daten zu erzwingen. Die Entscheidungslogik wird in den Harness verlagert – reproduzierbar, testbar, anpassbar. Das ist ein entscheidender Vorteil gegenüber dem Fine‑Tuning, bei dem man kaum Kontrolle über einzelne Verhaltensweisen hat.

Schwindender Vorteil des Fine-Tunings

Einwurf: Die grossen Frontier‑Modelle werden bereits auf ihre eigenen Harnesses nachtrainiert. OpenAI, Anthropic, Google post‑trainieren ihre Modelle auf die Werkzeuge, Aufrufkonventionen, Fehlermeldungen und Speicherstrategien ihrer Umgebung. Hat dieser Hebel noch Bedeutung? Yahya räumt ein, dass eine Anpassung der Modellgewichte an die Umgebung einen gewissen Vorteil bringt. Aber dieser Vorteil schwindet rapide. Bei der heutigen allgemeinen Leistungsfähigkeit reicht meist ein Retry‑Loop mit einer umfassenden Fehlermeldung, damit das Modell einen Werkzeugaufruf beim zweiten Mal richtig macht. Die Differenz zwischen einem Modell, das auf seinen Harness optimiert ist, und einem allgemeinen Modell mit klarem Harness wird zunehmend vernachlässigbar.

Für Entwickler und Unternehmen heisst das: Statt Monate und hohe Kosten in Training oder Fine‑Tuning eines spezialisierten Modells zu investieren, können sie auf modulare, quelloffene Harness‑Systeme zurückgreifen. Yahya verweist auf Beispiele wie Project Pi, Codex, Qwen Code, OpenCode, Gemini CLI und Grok Build. Diese Systeme sind open source oder öffentlich verfügbar. Die Bausteine sind da – sie müssen nur auf die eigene Domäne zugeschnitten werden. Die Kunst besteht darin, Gedächtnis, Werkzeuge, Validierung und Kompaktierungsstrategie zu definieren. Einmal konfiguriert, kann der Harness mit jedem leistungsfähigen Basismodell kombiniert werden. Das eröffnet Freiheitsgrade, die das alte Modell der Spezialisierung nie bieten konnte.

Basismodell plus konfigurierter Harness

Harnesses trennen die Verantwortlichkeiten sauber: Gedächtnis ist ein austauschbares Modul, Werkzeuge sind steckbar, die Planungskomponente kann ausgetauscht werden. Yahya stellt sich eine Zukunft vor, in der Unternehmen nicht mehr ein „Juristen‑Modell“ oder „Medizin‑Modell“ kaufen, sondern ein Basis‑Modell plus einen konfigurierten Harness, der alle domänenspezifischen Regeln, Ontologien und Workflows enthält. Das reduziert Kosten und Abhängigkeit von einzelnen Modellanbietern. Der Harness ist unabhängig vom Modell – er kann mit Llama, GPT, Claude oder Gemini arbeiten, solange die Schnittstellen passen.

Yahya räumt Grenzen ein: Für extrem sicherheitskritische Anwendungen in Medizintechnik oder Luftfahrt kann ein speziell trainiertes Modell mit deterministischeren Eigenschaften sinnvoll sein. Für die allermeisten Use Cases – legale Dokumentenanalyse, Softwareentwicklung, wissenschaftliche Recherche – reicht die Kombination aus leistungsfähigem Basismodell und massgeschneidertem Harness. Entscheidend ist die Bereitschaft, die Anpassung dorthin zu verlagern, wo sie am meisten Wirkung zeigt: in die Infrastruktur, nicht in die neuronalen Gewichte.

Vom Modell zur Umgebung

Domänenspezifische Harnesses verändern, wie wir KI in Fachgebieten einsetzen. Statt „Welches Modell trainieren wir?“ fragen wir „Welche Umgebung bauen wir?“. Die Allgemeinheit der Modelle bleibt erhalten, die Flexibilität steigt, die Kosten sinken. Wer heute in domänenspezifische KI investiert, sollte die Hebel im Harness suchen, nicht in den Gewichten. Das erleichtert die Suche nach echten Problemlösungen.

Quelle: alanyahya.com

Stell dir vor, du betrittst einen Laden und wirst sofort nach deinem Geld gefragt, bevor du weißt, was du kaufen willst. Unangenehm. Genau das erlebten Besucher der Website eines globalen Dokumentenediting-Dienstes. Die Conversion Rate Experts testeten das – mit einem überraschenden Ergebnis.

Der Fall zeigt: Nutzer brauchen den richtigen Moment für eine Entscheidung. Es geht nicht darum, möglichst früh einen Call-to-Action zu platzieren, sondern die Reise des Besuchers zu verstehen. Die Agentur beschreibt in ihrem Win Report, wie sie für einen Kunden – einen der größten akademischen und professionellen Editierdienste – den prominenten „Get Quote“-Button in der Kopfzeile entfernte. Das klingt kontraintuitiv. Normalerweise gilt: Je sichtbarer der Button, desto mehr Conversions. Hier führte der Schritt zu einer Steigerung der Conversion-Rate um 39 %.

Warum ein Formular Besucher vertrieb

Die Analyse der Nutzerpfade zeigte ein klares Muster: Viele Besucher kamen auf die Startseite, klickten sofort auf „Get Quote“ und landeten auf einem Formular, das sie mit Fragen überforderte. Der Dienst unterschied zwischen „Substantive Editing“ und „Copy Editing“. Für einen Erstbesucher war das kaum zu unterscheiden. Sie mussten Angaben zu Wortanzahl, Lieferzeit und Servicelevel machen – Dinge, die nur jemand beantworten kann, der den Service bereits kennt. Die Folge: Die meisten verließen frustriert die Seite. Das war die Hypothese der Agentur: Der Button war ein zu früher Schritt, der Besucher ohne ausreichende Information in die Entscheidung trieb.

Um das zu testen, wählten die Experten eine einfache, aber mutige Variante: Sie entfernten den „Get Quote“-Button komplett aus der Kopfzeile. Kein kleiner Textlink, kein anderer Button – einfach nichts. Die Besucher mussten selbst durch die Seite navigieren. Dabei entdeckten sie die detailreichen Beschreibungen der Dienstleistungen, Referenzen und Vertrauenssignale großer Kunden. Auf jeder Serviceseite gab es einen kontextrelevanten CTA, der sich natürlich in den Lesefluss einfügte. Der Unterschied war gewaltig: Statt sofort zum Formular zu springen, informierten sich die Besucher erst und trafen dann eine fundierte Entscheidung.

Das Prinzip der sicheren Schritte

Die Conversion Rate Experts nennen das das „Safe Step Principle“: Besucher gehen den nächsten Schritt eher, wenn er sich sicher und angemessen anfühlt – proportional zu dem, was sie bereits wissen. In diesem Fall war der große Button ein unsicherer Sprung ins Ungewisse. Die Entdeckungsreise durch die Inhalte gab ein Gefühl der Kontrolle. Die Zahlen: 39 % mehr Conversions, nur durch Weglassen eines Elements.

Bedeutet das, man sollte nie einen prominenten CTA verwenden? Nein. Es heißt: Der Kontext ist entscheidend. Für bestehende Kunden wäre der Button vielleicht hilfreich gewesen. Aber für Neubesucher war er eine Hürde. Die Agentur betont, dass sie den Button nicht für immer entfernt haben, sondern erst die zugrunde liegenden Probleme im Formular beheben müssen, bevor sie ihn wieder einblenden.

Übertragbar auf jedes Interface

Diese Lektion lässt sich auf viele Bereiche übertragen – Websites, digitale Produkte, KI-gestützte Interfaces. Entwickler neigen dazu, viele Optionen und direkte Aktionsmöglichkeiten anzubieten, in der Hoffnung, User schnell zu einer Handlung zu bewegen. Die Realität ist komplexer. Menschen brauchen Zeit, Vertrauen und Kontext, bevor sie eine Transaktion durchführen. Beste Technologie nützt nichts, wenn sie den Nutzer überfordert.

Ein weiterer Punkt: Der Test war radikal. Die Agentur zitiert ihr eigenes Buch „Making Websites Win“: Kleine Verbesserungen brauchen ewig, um messbare Effekte zu zeigen. Große, mutige Änderungen sind schneller und liefern mehr Gewinn. Das klingt logisch. In der Praxis scheuen viele Unternehmen davor zurück, etablierte Elemente wie einen Header-Button zu entfernen. Dieser Test zeigte, dass genau solche Entscheidungen den Durchbruch bringen können.

Conversion ist Nutzerpsychologie

Für Tech-Experten ist das eine Erinnerung: Conversion-Optimierung ist kein Spiel mit Farben und Schriftgrößen. Es geht um Nutzerpsychologie. Nimm die Perspektive des Besuchers ein und verstehe seine Unsicherheiten. Wer den Menschen in den Mittelpunkt stellt, wird belohnt – auch wenn es bedeutet, auf den ersten Blick Wichtiges wegzulassen.

Die Einordnung: Dieser Fall ist kein Plädoyer dafür, alle CTAs zu entfernen. Er ist ein Beispiel dafür, dass mutiges Testen und gründliche Nutzeranalyse zu Ergebnissen führen, die auf den ersten Blick widersprüchlich erscheinen. Genau das macht die Arbeit von Conversion-Spezialisten aus: Sie stellen Annahmen infrage und zeigen, dass manchmal weniger wirklich mehr ist. In einer digitalen Welt voller Ablenkung und Entscheidungsdruck kann Reduktion auf das Wesentliche die stärkste Waffe sein.

Quelle: conversion-rate-experts.com

Wenn der Daten-Tacho plötzlich grün wird

Du sitzt vor einem Dashboard, das die Umsätze der letzten Stunde anzeigen soll. Du drückst auf „Aktualisieren“, und nichts passiert. Sekunden vergehen, der Ladebalken kriecht. Ist die Abfrage doch komplexer als gedacht? Dieses Warten gehört im Datenalltag dazu, besonders wenn Apache Spark im Hintergrund arbeitet. Spark verarbeitet große Datenmengen, hat aber eine Schwäche: Overhead. Jede Query muss geplant, optimiert, serialisiert und an die Executors verteilt werden. Das kostet Zeit, vor allem bei vielen kleinen Aufgaben. Ein neues Projekt, Apache DataFusion Comet, zielt genau darauf ab.

Warum Spark manchmal ins Stocken gerät

Apache Spark ist ein verteiltes Framework für große Datenmengen. Es liefert bei großen, parallelen Aufgaben gute Ergebnisse. Bei vielen kleinen Operationen – Filtern, Aggregationen, Joins auf Partitionen – wird der JVM-Overhead spürbar. Jeder Task startet in der Java Virtual Machine, Daten werden serialisiert und deserialisiert, der Scheduler verteilt die Arbeit. Die CPU ist oft nicht ausgelastet, viel Zeit geht für Organisation drauf statt fürs Rechnen.

Apache DataFusion ist eine in Rust geschriebene Query-Engine. Rust bietet Performance ohne Garbage-Collection-Pausen. DataFusion führt SQL-Abfragen nativ aus, ohne JVM-Umweg. Das Comet-Projekt nutzt das: Es ersetzt den Spark-Execution-Plan durch eine native DataFusion-Ausführung. Der Anwender merkt kaum etwas davon. Du schreibst weiterhin Spark-SQL-Abfragen, aber unter der Haube läuft ein anderer Motor.

Wie Comet den Turbo zündet

Apache DataFusion Comet ist kein eigenständiges System, sondern ein Plugin für Spark. Es fängt logische Pläne ab, die Spark generiert, und wandelt sie in physische Pläne für DataFusion um. DataFusion ist in Rust geschrieben und nutzt moderne CPU-Features wie SIMD und optimierte Speicherzugriffe. Dadurch werden Berechnungen schneller und effizienter. Tests zeigen, dass Comet die Ausführungszeit je nach Query-Typ um den Faktor zwei bis fünf reduzieren kann. Und das ohne Code-Änderungen – ein Drop-in-Beschleuniger.

Stell dir vor, du hast eine Profi-Küche mit vielen Köchen – das sind deine Spark-Executors. Bisher holte jeder Koch seine Zutaten aus dem Lager. Mit Comet stehen alle Zutaten bereit, die Kochstation ist vorgeheizt, ein Koch erledigt mehrere Schritte in einem Durchgang. Das Ergebnis: Das Essen ist schneller fertig, die Küche läuft ruhiger.

Die Verbindung zu Iceberg und Rust

Das Comet-Projekt ist eng mit der Entwicklung von Iceberg Rust verknüpft. Apache Iceberg ist ein offenes Tabellenformat für Data Lakes. Es bringt ACID-Transaktionen, Schema-Evolution und Zeitreise-Funktionen. Die offizielle Iceberg-Referenz ist in Java geschrieben, aber es gibt eine wachsende Rust-Implementierung, die Iceberg Rust Library. Rust ist schnell und ideal für DataFusion, da beide dieselbe Sprache verwenden. Wenn Iceberg Rust in DataFusion integriert wird, können Spark-Queries direkt auf Iceberg-Tabellen in Rust ausgeführt werden – ohne Java-Umweg. Das beschleunigt Queries und vereinfacht die Entwicklung.

Die Entwickler von Iceberg Rust arbeiten mit dem DataFusion-Team zusammen, um alle Iceberg-Features zu unterstützen, wie Partition Pruning, Manifest-Lesevorgänge oder Upgrades. Das ist kein theoretisches Projekt: Iceberg-Tabellen lassen sich bereits mit Spark und Comet ausführen und nutzen die Performance von Rust. Da Rust keinen Garbage Collector hat, bleiben Antwortzeiten konstant niedrig – kein ruckelnder Ladebalken.

Was das für dich bedeutet

Wenn du bereits Spark für Data-Lake-Analysen einsetzt, bekommst du mit Comet eine einfache Möglichkeit, Queries zu beschleunigen, ohne Code umzuschreiben. Du aktivierst das Plugin, konfigurierst es einmal und profitierst von der nativen Ausführung. Das spart Zeit und Rechenkosten: Schnellere Queries bedeuten entweder mehr Anfragen oder kleinere Cluster. Besonders bei wiederkehrenden ETL-Jobs oder Ad-hoc-Analysen macht sich der Unterschied bemerkbar.

Für alle, die sich mit Rust und Iceberg beschäftigen, eröffnet Comet eine neue Perspektive: eine vollständig native Pipeline von der Speicherung in Iceberg bis zur Ausführung mit DataFusion und Spark. Das reduziert die Abhängigkeit von der JVM und ermöglicht weitere Performance-Optimierungen, die nur in Rust möglich sind. Die Community arbeitet daran, auch andere Spark-Komponenten wie den Optimizer oder den Shuffle-Prozess durch native Alternativen zu ersetzen. Das ist ein Schritt zu einem „Cloud Native Spark“, das die einfache API von Spark mit der Rechenleistung von Rust vereint.

Eine realistische Einordnung

Apache DataFusion Comet ist kein Allheilmittel. Es löst vor allem Probleme bei rechenintensiven Queries, die viel CPU-Zeit in der Ausführung verbrauchen. Liegen Flaschenhälse im Netzwerk, Speicher oder I/O, bringt Comet wenig. Auch die Kompatibilität mit allen Spark-Features ist noch nicht vollständig. Einige UDFs oder spezielle Funktionalitäten müssen nachgerüstet werden. Aber die Entwicklung ist schnell, und erste Produktionseinsätze zeigen vielversprechende Ergebnisse.

Für Iceberg-Nutzer: Comet ersetzt die Iceberg-Integration nicht automatisch. Du brauchst weiterhin den Iceberg-Katalog und die Tabellenmetadaten – diese werden über die Iceberg Rust Library gelesen, die mit DataFusion spricht. Das Zusammenspiel wird kontinuierlich verbessert, sodass du am Ende einen schlanken, performanten Stack bekommst.

Fazit

Die Kombination aus Apache Spark, Apache DataFusion Comet und Iceberg Rust ist ein Beispiel dafür, wie moderne Software alte Probleme löst. Wir sehen einen Trend weg von monolithischen, JVM-lastigen Systemen hin zu modularen, nativen Komponenten. Du musst deine Gewohnheiten kaum ändern. Die Abstraktion bleibt dieselbe – Spark und SQL –, die Performance steigt. Wenn du das nächste Mal auf ein Dashboard wartest: Vielleicht liegt es nicht an der Datenmenge, sondern daran, dass der Koch noch in der Speisekammer steht. Mit Comet hat er die Zutaten schon in der Hand.

Quelle: iceberg.apache.org

Ein KI-Assistent erhält den Auftrag, Daten aus verschiedenen Quellen zu sammeln, Code zu schreiben, um sie zu analysieren, und das Ergebnis als Diagramm darzustellen. Er arbeitet stundenlang, führt Skripte aus, greift auf Dateien zu und kommuniziert mit anderen Diensten. Ein fehlerhafter Befehl könnte das System beschädigen oder ein Angreifer den Assistenten kapern. Sandboxen verhindern das: isolierte Umgebungen, in denen der Agent arbeitet, ohne das Host-System oder sensible Daten zu gefährden.

Die Ingenieure von Perplexity haben eine Plattform namens SPACE (Sandboxed Platform for Agentic Code Execution) entwickelt. Sie ist für langlaufende, zustandsbehaftete Agenten-Workloads konzipiert. Traditionelle Container-basierte Sandboxen sind für kurze, statlose Jobs optimiert und haben ein Problem: Der Kernel ist ein Single Point of Failure. Wer den Kernel im Container kompromittiert, kann auf den Host-Kernel zugreifen und andere Container gefährden. SPACE nutzt virtuelle Maschinen (VMs) mit eigenem Gast-Kernel. Selbst wenn ein Angreifer den Kernel der VM übernimmt, bleibt der Schaden auf diese eine VM beschränkt – der Host und andere Mandanten sind geschützt.

Warum herkömmliche Sandboxen für Agenten nicht reichen

Ein KI-Agent, der über Stunden oder Tage arbeitet, sammelt Kontext, verändert ein Dateisystem und hinterlässt laufende Prozesse. Bei Container-Ansätzen müsste man diese Zustände regelmäßig extern sichern und bei Fehlern neu aufbauen – aufwendig. SPACE modelliert den gesamten Lebenszyklus einer Sandbox als expliziten Zustandsautomaten: Erstellen, Pausieren, Fortsetzen, Suspendieren und Wiederherstellen sind sauber definierte Operationen. Das ermöglicht Forking, Rollback und Crash-Recovery – ohne dass der Agent jedes Mal neu starten muss.

Die drei Säulen von SPACE: Sicherheit, Funktionalität, Effizienz

Die Herausforderung beim Bau einer Sandbox-Plattform ist die Abwägung zwischen Sicherheit, Funktionalität und Effizienz. Mehr Freiheit für den Agenten bedeutet mehr Angriffsfläche. Schnellere Sandbox-Erstellung durch gemeinsame Ressourcen erhöht das Risiko von Datenlecks. Häufigere Snapshots verbessern die Wiederherstellbarkeit, kosten aber Speicher und Zeit. SPACE balanciert diese Ziele durch eine durchdachte Architektur.

Sicherheit: Mehrschichtige Isolation

Die Isolation ist mehrschichtig. Erstens die VM-Isolation: Jede Sandbox läuft in einer eigenen VM mit Gast-Kernel. Zweitens die Host-OS-Prozessisolierung: Host-Dienste laufen unprivilegiert, privilegierte Operationen werden über einen dedizierten Node-Manager abgewickelt. Kommunikation mit der Sandbox erfolgt ausschließlich über kontrollierte Kanäle: Ein in der VM laufender Daemon namens space reguliert Dateisystemzugriffe, Prozesse und Netzwerk. Dieser Daemon kommuniziert nur mit dem Host über einen privaten In-VM-Kanal – die Netzwerkschnittstelle der VM steht nur dem Workload selbst für ausgehenden Datenverkehr zur Verfügung.

Credentials werden außerhalb der Sandbox verwaltet. Geheime Schlüssel oder Passwörter gelangen nie in die Sandbox. Der Credential Manager verwaltet die Daten außerhalb. Bei Bedarf werden sie auf Netzwerkebene injiziert oder von einem Browser-Agenten automatisch ausgefüllt – sie berühren das Dateisystem des Agenten nie. Für ruhende Daten unterstützt SPACE BYOK (Bring Your Own Key): Verschlüsselungsschlüssel kommen aus dem eigenen Key-Management-Service des Kunden und verlassen nie den sicheren Bereich. Entzieht das Unternehmen den Schlüssel, sind die Daten unlesbar.

Funktionalität: Lebenszyklus für langlebige Agenten

Ein Agent startet ohne Wartezeit. SPACE hält einen Warm Pool von Pods vor, die bereits eine Vorlage (Template) eingebunden haben. Wird eine neue Sandbox angefordert, wird sie einem passenden Pod zugewiesen – das startet in Sekundenbruchteilen. Snapshots sind der Kernmechanismus für Pause, Suspend, Rollback und Wiederherstellung. Ein Scheduler erfasst regelmäßig zwei Arten: Disk-Snapshots (Momentaufnahmen des Dateisystems) und Full-Snapshots (Checkpoints der gesamten VM). Disk-Snapshots sind häufig, Full-Snapshots seltener. Sie verbleiben auf dem Knoten, die Aufbewahrungsdauer richtet sich nach einer gestaffelten Policy.

Wird eine Sandbox suspendiert, pausiert das System die VM, erstellt einen Full-Snapshot und lädt die Artefakte in den Objektspeicher hoch. Erst wenn alle Teile angekommen sind, wird der Snapshot in der Datenbank als wiederherstellbar markiert. So kann kein korrupter Zustand entstehen. Die Wiederherstellung kann auf jedem beliebigen Knoten erfolgen, da der Snapshot zentral gespeichert ist. Das ermöglicht Lastverteilung und Ausfallsicherheit.

Effizienz: Weniger Speicher und schnellere Operationen

Effizienz ist entscheidend. SPACE setzt auf das Btrfs-Dateisystem (B-tree Filesystem) auf den Knoten. Btrfs kombiniert Copy-on-Write mit logischem Volume-Management. Der Vorteil: Reflink-Kopien sind extrem schnell, da nur Metadaten kopiert werden, die Datenblöcke bleiben gemeinsam genutzt. Snapshots sind atomar und sofort. Dadurch braucht man nur den tatsächlichen Änderungsbereich zu speichern. Sandbox-Erstellung und -Wiederherstellung sind effizient.

Die Resultate: Seit der Einführung von SPACE als Sandbox-Schicht für Perplexity Computer im letzten Monat wurden Millionen von Sandboxen erstellt und zig Millionen Wiederverbindungen unterstützt – mit Startzeiten, die drei- bis fünfmal schneller sind als bei der vorherigen Lösung. 100 Prozent der Computer-Sitzungen laufen heute auf SPACE. Die Entwickler planen, die Plattform auf weitere Oberflächen auszurollen.

Was bedeutet das für die Praxis?

Für Anwender von KI-Agenten bedeutet das mehr Vertrauen in die Sicherheit ihrer Systeme. Selbst wenn ein Agent kompromittiert wird, bleibt der Schaden auf die einzelne Sandbox begrenzt. Geheimnisse sind nie im Zugriff des Agenten. Gleichzeitig arbeiten Agenten produktiver, weil sie lange Sitzungen ohne Neustart fortsetzen können. Für Betreiber von Agent-Plattformen bietet SPACE eine skalierbare, effiziente Infrastruktur, die mit den steigenden Anforderungen wächst. Sicherheit und Komfort lassen sich verbinden – wenn die Architektur entsprechend gestaltet ist.

Quelle: research.perplexity.ai