Googles Project Chrysalis: KI-Agent behebt simulierten Ausfall mit selbst geschriebenem Patch

Das Problem: Beratende Copiloten stoßen bei Live-Ausfällen an Grenzen

Anant Nawalgaria, Group Product Manager und AI Engineer bei Google, schreibt im Google Developers Blog, dass generative KI-Copiloten das Schreiben von Code und das Zusammenfassen von Logs beschleunigt haben, KI-Agenten bei der zuverlässigen Behebung von Produktionsausfällen im laufenden Betrieb aber weiterhin Schwierigkeiten haben. Eng gekoppelte Microservices können demnach in Kaskaden ausfallen, die sich laut Nawalgaria mit keinem statischen Runbook und keinem Schwellenwert-Alarm vorhersehen lassen.

Als Beispiel dient ein Flash-Sale am Black Friday. Eine Welle von Checkout-Anfragen trifft auf kalte Inventar-Schlüssel, Google Cloud Memorystore (Redis) verdrängt sie nach den Least-Recently-Used-Grenzen, und die Cache-Trefferquote fällt auf null. Der Traffic flutet daraufhin Google Cloud SQL, der PostgreSQL-Connection-Pool ist ausgelastet, und der Dienst liefert HTTP-500-Fehler.

Google beschreibt außerdem den "3:00 AM Panic Reflex": Sowohl menschliche Einsatzkräfte als auch naive LLMs starten instinktiv den Datenbank-Connection-Pool neu. Bei einer laufenden Stampede, so der Beitrag, blockiert das den Datenbankkernel, lässt die Tail-Latenz fast um das Zehnfache ansteigen und treibt die Fehlerraten Richtung Totalausfall.

Was ein selbstentwickelnder Agent leistet

Google definiert Self-Evolving AI als System, das fünf Dinge beherrscht: verteilte Ursachen über Cache- und Datenbankschichten hinweg diagnostizieren, sich selbst patchen, sich selbst kritisieren, sich erinnern und neu aufbauen. Herkömmliche Agenten sind mit dem Deployment festgelegt, mit fixen System-Prompts und vorab registrierten Tools. Der Chrysalis-Agent erweitert diese Grundfähigkeiten dagegen zur Laufzeit.

• Selbst-Patching: Stellt der Agent fest, dass die Datenbank-Auslastung von einem ungedrosselten Ansturm am Eingang herrührt, und fehlt ihm ein Tool zur Traffic-Steuerung, schreibt er einen In-Memory-Token-Bucket-Rate-Limiter, validiert dessen Abstract Syntax Tree, signiert ihn mit Cloud KMS und bindet ihn im laufenden Betrieb in das API Gateway ein.
• Selbstkritik: Nach dem Ausfall bewertet er, wie sich die Telemetrie durch jede Aktion verändert hat. Den Datenbank-Neustart straft er ab, weil er die Latenz verschlechterte, den Rate-Limiter belohnt er, weil er die Serverfehler beseitigte.
• Gedächtnis und Umbau: Er schreibt ein signiertes Betriebsprinzip in den Vektorspeicher, das Datenbank-Neustarts bei Cache-Stampedes blockiert, und beauftragt anschließend einen dauerhaften Traffic-Shaping-Spezialisten-Agenten unter dem Supervisor-Agenten.

Drei Forschungssäulen hinter dem Entwurf

Die Architektur kombiniert drei Forschungsarbeiten, um das zu lösen, was der Beitrag das SRE-Trilemma nennt: den Ausgleich von Explorationssicherheit, struktureller Anpassungsfähigkeit und Credit Assignment über mehrere Schritte.

• Dream-RSI, serverlose kontrafaktische Simulation: Request-Traces aus der Produktion werden nach Google BigQuery exportiert. Dort spielt die Engine Hunderte denkbare Token-Bucket-Konfigurationen in vektorisierten Speicher-Sweeps im Submillisekundenbereich durch, um offline Pareto-optimale Richtlinien zu finden. So müssen ungeprüfte Parameter nicht am Live-Traffic getestet werden.
• APEX, Co-Evolution auf drei Ebenen: Die Evolution ist in drei kontrollierte Zeitskalen gegliedert. Ebene 1 patcht per In-Memory-Middleware-Tools im laufenden Betrieb, Ebene 2 destilliert mit Cloud KMS signierte Erkenntnisse in Agent Platform Vector Search, Ebene 3 fügt dem Multi-Agenten-Directed-Acyclic-Graph dauerhafte Spezialisten-Subagenten hinzu.
• AgentEvolver, Shapley-Zuordnung auf Schrittebene: Er berechnet für jeden Ausführungsabschnitt den marginalen Shapley-Beitrag anhand der Veränderungen von P99-Latenz, HTTP-5xx-Rate und Datenbank-Pool-Auslastung vor und nach dem Eingriff und trennt so hilfreiche von schädlichen Patches.

Governance: keine unkontrollierte Blackbox

Google betont, dass das System nicht als unkontrollierte "Blackbox" arbeitet. Jede autonome Aktion wird durch einen mehrstufigen Schutzverbund auf Google Cloud begrenzt. Model Armor bereinigt eingehende Telemetrie von Prompt Injections und Datenlecks. Cloud KMS und Binary-Authorization-Middleware signieren die erzeugten Patches und verhindern, dass nicht verifizierter Code eingebunden wird. Ein Open Policy Agent Policy Controller erzwingt SLA-Leitplanken, die selbstverschuldete Ausfälle verhindern sollen. Eine Dual-Custody-Human-in-the-Loop-Governance verlangt vor jeder dauerhaften Änderung an der Agentenhierarchie die ausdrückliche Freigabe durch einen SRE.

Gemeldete Ergebnisse und ihre Einordnung

Google hat die Architektur als interaktive Anwendung auf der Gemini-Plattform mit dem Agent Development Kit (ADK) gebaut. In der ersten Demophase folgt auf eine warme Baseline von 5 Anfragen ein Flash-Sale-Ansturm mit 50 Anfragen über 15 kalte Inventar-Schlüssel. Die Memorystore-Trefferquote fällt von 100 % auf 0,0 %, der Cloud-SQL-Pool erreicht 100 % Auslastung (2 von 2 aktiven Verbindungen blockiert), die P99-Latenz steigt auf 312,8 bis 519,8 ms, und die HTTP-500-Fehler erreichen 72,7 % bis 80,0 %, mit 40 gescheiterten Checkouts.

In der zweiten Phase wird der ADK Supervisor Router Agent, der laut Google von Gemini 4 Argon angetrieben wird, durch Telemetrie-Alarme geweckt, nachdem Model Armor die Nutzdaten geprüft hat. Der Layer-1-Synthesizer erzeugt dann einen Rate-Limiter mit einer Kapazität von 10 Tokens und einer Auffüllrate von 40,0 Anfragen pro Sekunde. Der vorliegende Quelltext endet, bevor der Rest des Ablaufs beschrieben wird.

Über die simulierten Ausfälle hinweg berichtet Google, die Zeit bis zur ersten Gegenmaßnahme sei von 15 bis 45 Minuten auf 1,8 Sekunden gefallen, die HTTP-5xx-Fehlerrate von 72,7 % bis 80,0 % auf 0,0 %, und die P99-Latenz von 519,8 ms auf 18,2 ms. Zudem seien in BigQuery 400 kontrafaktische Traffic-Richtlinien in etwa 0,5 ms ausgewertet worden.

Diese Zahlen stammen aus Simulationen und einer unternehmenseigenen Forschungs-Referenzarchitektur, nicht aus produktiven Einsätzen. Für SRE- und Plattform-Teams ist der Beitrag ein Bauplan dafür, Agenten-Autonomie mit Signierung, Richtlinienprüfungen und menschlicher Freigabe zu verbinden, kein fertiges Produkt.