Google lässt Gemini 4 Argon über Nacht 200.000 Zeilen Python-Code optimieren

Eine echte Codebasis statt einer Demo auf der grünen Wiese

Im Entwicklerblog von Google heißt es, die meisten Launch-Demos zeigten neue Apps, die aus einem leeren Ordner entstehen, was wenig darüber aussage, wie ein Modell mit bestehendem Code zurechtkommt. Zum Start von Gemini 4 Argon wählte das Team deshalb einen härteren Test: dateiübergreifende Performance-Engpässe in google/adk-python zu finden und zu beheben, dem Python-Repository des Agent Development Kit (ADK), Googles Open-Source-Framework zum Bau und Betrieb von Unternehmens-Agenten.

Laut Google umfasst das Repository rund 205.000 Codezeilen in knapp 800 Quelldateien und wird von fast 17.000 Unit-Tests abgesichert. Performance-Arbeit sei schwierig, schreiben die Autoren, weil die Bremse selten in der Datei sitze, in der das Symptom auftritt, und das Modell über einen langen Lauf hinweg eine Karte der gesamten Codebasis im Kopf behalten müsse.

Runde eins: keine Anweisungen, echte Funde, falsche Konventionen

In der ersten Runde erhielt Argon keine eigenen Repository-Anweisungen und nur einen einzigen Absatz als Prompt: ADK soll bei keinem Agenten spürbaren Overhead verursachen, die Modelleingabe und die öffentliche API sollen unverändert bleiben, und jede Änderung soll durch einen Regressionstest abgesichert sein. Der Lauf dauerte etwa zwei Stunden. Argon schrieb nach 7 Minuten ein Benchmark-Skript und verbrachte 70 Minuten mit Messen und Code-Lesen, bevor es irgendeinen ADK-Quellcode änderte. Es fand echte Engpässe beim Kopieren von Sessions und bei Paketimporten, und Teile seines Codes schafften es in den finalen Commit.

Bei den Konventionen der Maintainer patzte es laut Google. Argon hängte einen eigenen Hook an das Authentifizierungsmodell von ADK, was das öffentliche JSON-Schema subtil veränderte, übersah in seinem eigenen Kopierer Randfälle bei Mock-Events, führte nur 216 naheliegende Unit-Tests aus und ließ die Benchmark-Zahlen in der Beschreibung seines Pull Requests weg.

Runde zwei: Skills-Dateien und der /goal-Modus

Für die zweite Runde nahm das Team zwei Änderungen vor. Erstens legte es seine Maintainer-Richtlinien im Verzeichnis .agents/skills des Repositorys ab, wie eine Einarbeitungsmappe für einen neuen Entwickler. Jeder Skill beginnt mit einem kurzen Index namens SKILL.md, der bei Bedarf auf gezielte Dateien im Ordner references/ verweist, sodass das Kontextfenster nicht in jeder Runde überflutet wird. Argon begann um 21:11 Uhr und las Dateien wie visibility.md, die die Regel für private Module mit _-Präfix behandelt, und imports.md, die Prüfungen zum Lazy Loading behandelt, bevor es Code anfasste.

Zweitens aktivierte das Team den /goal-Modus in Google Antigravity, der das Ziel über Kontextkomprimierungen hinweg beibehält, sodass der Agent weiterarbeitet, bis die Aufgabe erledigt ist. Der Prompt verlangte zudem einen einzigen Pull Request gegen main, den die Maintainer genehmigen würden, mit Zahlen vorher und nachher, und wies den Agenten an, ihn nicht zu mergen.

Argon las 12 Richtliniendateien und führte einen Basis-Benchmark über vier Workloads aus: Paketstart, eine Unterhaltung mit 200 Schritten, eine Test-App, in der 20 Sub-Agenten einander Aufgaben übergeben, und ein Workflow mit 12 Knoten, jeweils 30 Durchläufe. Drei Minuten vor dem Ende prüfte es noch seinen eigenen Diff, fand einen Fehler in seinem eigenen Multi-Agent-Cache und ließ alle 16.892 Unit-Tests erneut laufen, bevor es von selbst stoppte.

Die zwei Änderungen, die live gingen

Argons Pull Request schlug sechs Optimierungen in 32 Dateien vor. Zwei wurden übernommen.

• Session-Verlauf vor dem Kopieren filtern. Der In-Memory-Session-Dienst von ADK kopierte bisher bei jedem Lesezugriff die gesamte gespeicherte Unterhaltung tief, bevor er auf die angefragten Events filterte. Selbst beim Auflisten von Sessions ohne Events wurde zunächst jedes Event kopiert. Argon stellte den Dienst auf Filtern zuerst um und ersetzte den generischen Deep-Copy-Pfad von Pydantic bei Sessions und Events durch einen schnellen, zyklensicheren Kopierer, der gemeinsam genutzte State-Dictionaries und Test-Mocks erhält.
• Schwere Pakete nur bei Bedarf laden. Wer import google.adk ausführte, zog selbst bei einem einfachen Text-Agenten Module für Live-Audio- und Video-Streaming, OpenTelemetry-Tracing sowie die Webserver FastAPI und Starlette mit. Das bloße Entfernen von Imports auf oberster Ebene brach Tests: Nachdem Argon drei interne Flow-Imports aus llm_agent.py entfernt hatte, bestanden zwar alle 16.892 Open-Source-Tests, aber 25 interne Google-Testtargets schlugen fehl, weil sie diese Attribute patchten. Die ausgelieferte Lösung nutzt Lazy-Module-Accessoren, sodass Pakete erst bei der ersten Verwendung geladen werden und öffentliche Attribute patchbar bleiben.

Vier im Review abgelehnt, und was das bedeutet

Die anderen vier Änderungen lehnten die Maintainer ab. Ein Multi-Agent-Event-Cache beschleunigte einen synthetischen Benchmark um 17 %, nutzte aber eine schwache Speicherreferenz, die über Sessions hinweg veraltete Daten liefern könnte, falls Python nach der Garbage Collection eine Speicheradresse wiederverwendet. Eine Telemetrie-Prüfung las ein privates Attribut der Tracer-Implementierung von OpenTelemetry, was bei einem kleinen Library-Upgrade unbemerkt brechen könnte. Eine Neufassung der Formatierung des Unterhaltungsverlaufs in ADK machte einen zentralen Pfad schwerer lesbar, ohne die End-to-End-Latenz in einem unabhängigen Holdout-Benchmark zu verbessern. Ein Lookup-Index für die Wiedergabe von Workflow-Events brachte zusätzliche Komplexität bei der Zustandsverfolgung, die nur synthetischen Replay-Tests half.

Das Team kombinierte die besten Teile beider Runden zu einer Änderung über 22 Dateien, abgesichert durch 17 neue Testfunktionen. Nach dem Review im gesamten ADK-Team landete sie in main mit dem Commit-Hinweis „Argon generated these changes“. Google fasst die Arbeitsteilung so zusammen: „the agent explores, the maintainer subtracts“.

Für Teams, die ähnliche Nachtläufe erwägen, ist die Lehre des Beitrags praktisch: Review-Konventionen in Skills-Dateien des Repositorys festhalten, das Ziel fixieren, damit es lange Sitzungen übersteht, einen ungemergten Pull Request samt Messwerten anfordern und die menschliche Prüfung als Filter beibehalten. Der hier vorliegende Quelltext bricht vor den detaillierten Benchmark-Ergebnissen ab.