Architektur von verwalteten, selbstentwickelnden KI-Agenten auf Google Cloud

Wie weit kann man "selbstentwickelnde" Agenten treiben, wenn Governance die eigentliche Anforderung ist? Dieser Google-Cloud-Beitrag zeigt den vollständigen Kreislauf anhand eines konkreten Vorfalls – von einem Flash-Sale-Ansturm, der eine Checkout-Pipeline unterbricht, über einen autonom generierten Hotpatch bis hin zu einer strukturellen Lösung, die für die menschliche Genehmigung stoppt.

Phase 1: Der Vorfall

Eine warme Basislast von 5 Anfragen wird von einem gleichzeitigen Flash-Sale-Ansturm mit 50 Anfragen auf 15 kalte Inventarschlüssel getroffen. Die Auswirkungen sind unmittelbar und messbar: Die Memorystore-Trefferquote fällt von 100% auf 0,0%, der Cloud-SQL-Verbindungspool erreicht 100% Sättigung (2/2 Verbindungen gesperrt), die P99-Latenz steigt auf 312–520 ms und HTTP-500-Fehler springen auf 72,7–80% (40 fehlgeschlagene Checkouts).

Phase 2: ADK-Schnellschleifen-Triage und ein verwalteter Layer-1-Hotpatch

Telemetrie-Warnungen wecken einen ADK Supervisor Router Agent, der von Gemini 4 Argon betrieben wird – nachdem Model Armor die Warnungs-Payload inspiziert hat, um Prompt-Injection zu blockieren. Nach der Diagnose der Pool-Erschöpfung generiert der APEX Layer 1 Hotpatch Synthesizer einen In-Memory-Token-Bucket-Rate-Limiter (10-Token-Kapazität, 40,0 req/s Auffüllung). Bevor der Patch in die API-Gateway-Middleware eingebunden wird, durchläuft er drei automatisierte Governance-Gates:

1. AST Sandbox Visitor – stellt sicher, dass verbotene Systemmodule und dynamische Ausführungs-Sinks fehlen.
2. OPA Policy Controller – bestätigt, dass die Auffüllrate das unternehmensweite Mindest-SLA (≥ 10,0 req/s) erfüllt.
3. Cloud KMS + Binary Authorization – signiert den Artefakt-Digest (EC_SIGN_P256_SHA256) und verifiziert die Schlüsselherkunft an der Middleware-Grenze.

Bei einem zweiten Ansturm mit 50 Anfragen fallen die HTTP-500-Fehler auf 0,0%, die Pool-Sättigung auf 0%, die P99-Latenz erholt sich auf 18,2 ms und überschüssiger Burst-Traffic wird über HTTP 429 abgeworfen (40 gedrosselt, 10 warm bedient).

Phase 3: Attribution und ein menschlich geprüfter Fix der Stufe 2

Die AgentEvolver Credit Attribution Engine prüft die Ausführungs-Spannen des Vorfalls – sie bestraft den Datenbank-Neustart-Reflex (der die Latenz auf 3.800 ms hochtrieb) und belohnt den Token-Bucket-Patch (+0,97 Guthaben). Der APEX Layer 2 Principle Distiller signiert und indexiert eine unveränderliche Betriebsregel in der Gemini Platform Vector Search: "Cache-Eviction-Stampede: Datenbank-Neustart kontraindiziert; Token-Bucket-Lastabwurf anwenden."

Anstatt sich auf temporäre Hotpatches zu verlassen, schlägt das System dann eine strukturelle Aktualisierung der Stufe 2 vor: die Beauftragung eines permanenten Traffic Shaping Specialist Agent. Die Ausführung pausiert und präsentiert ein Dual-Custody-SRE-Freigabe-Modal, das die ausdrückliche Freigabe des diensthabenden SRE erfordert.

Warum diese Architektur wichtig ist

Das Muster, das es wert ist, kopiert zu werden: Schnelles autonomes Handeln ist erlaubt, aber nur innerhalb eines Schutzzaun-Envelopes (Model Armor → AST-Sandbox → OPA-Richtlinie → Signierung), und strukturelle Änderungen eskalieren immer an Menschen. Attribution schließt den Kreislauf – das System lernt, welche seiner eigenen Maßnahmen geholfen haben, und das destillierte Prinzip überlebt den Vorfall. Das ist verwaltete Selbstentwicklung mit Sorgfalt: Geschwindigkeit auf Layer 1, Kontrolle auf Layer 2.