Google optimiert Agent Development Kit per Nachtlauf von Gemini 4 Argon
Ein elfstuendiger unbeaufsichtigter Lauf von Gemini 4 Argon lieferte zwei akzeptierte Optimierungen fuer die rund 200.000 Zeilen grosse Python-Codebasis des Google Agent Development Kit. Der Overhead der Session-Vorbereitung sank dabei um etwa 40 Prozent, die Importzeit um 21 Prozent.
Eines der Ziele der Google-Ingenieure bestand darin, herauszufinden, "wie das Modell mit einer bestehenden Codebasis umgeht", eine deutlich schwierigere Aufgabe als die Erstellung von "Greenfield-Apps, die aus einem leeren Ordner entstehen", so die Aussage. Um dies zu testen, konzentrierten sie sich auf die Optimierung der Leistung ihres eigenen Agent Development Kit (ADK), einer Codebasis mit über 200.000 Codezeilen, verteilt auf rund 800 Dateien und nahezu 17.000 Unit-Tests.
Leistungsarbeit ist ein harter Test für ein Modell, denn man kann nicht einfach eine Datei öffnen und die Verlangsamung entdecken. Man muss orthogonal zum Ort betrachten, an dem das Symptom auftritt, und über einen langen Zeitraum eine mentale Karte davon pflegen, wie die gesamte Codebasis zusammenspielt.
Nach einem anfänglichen, kurzen Durchlauf, der ihnen half zu erkennen, was der Prompt enthalten musste, damit der Agent den Konventionen des Teams für Unit-Testing und Benchmarking folgte, legten die Google-Ingenieure repositoryspezifische Richtlinien über.agents/skills-Dateien fest, "wie ein Onboarding-Leitfaden für neue Ingenieure". Der Agent wurde angewiesen, nur die für die Aufgabe erforderliche Skill zu laden, um das Kontextfenster nicht zu überfluten. Schließlich entwickelten sie den folgenden Prompt, wobei sie den /goal-Modus von Antigravity nutzten, um sicherzustellen, dass das Ziel über die Kontextkompaktion hinweg erhalten blieb:
/goal Make ADK add no noticeable overhead to any agent: at startup, in long sessions, in multi-agent and workflow setups. Keep what the model receives and the public API unchanged, and back each change with a test that would catch a regression. Open one pull request against main that the ADK maintainers would approve, with before and after numbers in its description. Don't merge it. Nach Abschluss der Aufgabe erklärt Google, zeigten Argons Protokolle, dass der Agent die Repository-Richtlinien gelesen, Leistungsbaselines erstellt, Optimierungen vorgeschlagen, seine eigenen Änderungen überprüft und alle 16.892 Open-Source-Unit-Tests ausgeführt hatte, bevor er die Arbeit beendete.
Wichtiger ist, dass Argon die arbeitsintensive Arbeit über Modulgrenzen hinweg erledigte, die ein Profiler nicht für einen übernehmen kann. Ein Profiler verrät einem, dass das Kopieren von Sessions und das Importieren von Paketen Zeit kosten. Was er nicht tut, ist jeden Aufrufer, Mock-Ziel und jede geteilte Referenz über 40 Dateien hinweg nachzuverfolgen, damit die Beschleunigung dieser Pfade bestehende Anwendungen nicht beschädigt.
Die beiden letztlich in die Codebasis übernommenen Optimierungen verbesserten die Handhabung des Sitzungsverlaufs im ADK, indem Ereignisse vor dem Kopieren gefiltert wurden, und führten Lazy Loading ein, um zu verhindern, dass schwere Pakete importiert werden, bevor sie benötigt werden.
Diese Änderungen machten die Vorbereitung von In-Memory-Sessions und den Paketimport jeweils um 40 Prozent und 21 Prozent schneller. Diese Aufgaben sind im Vergleich zur Gesamtdauer eines Agent-Durchlaufs nicht besonders teuer; Google weist darauf hin, dass das ADK Multi-Tool-Interaktionen über Dutzende oder sogar Hunderte von Iterationen unterstützt, wodurch sich diese kleinen Leistungsgewinne aufsummieren:
Bei einem einzelnen LLM-Aufruf, der Sekunden dauert, spürt ein Mensch 28 ms oder 78 ms nicht. Über 158 interne Runden von Tool-Calling-Interaktionen hinweg summieren sich diese Kopien jedoch: Ihr Wegfall verkürzt den gesamten 158-Runden-Durchlauf von 65,6 Sekunden auf 56,1 Sekunden (nahezu 10 Sekunden reinen Framework-Overheads).
Während Googles Erfahrung mit Gemini 4 Argon bei der Optimierung der ADK-Codebasis zeigt, dass KI-Agenten bestehende Codebasen erfolgreich verändern können, bleibt ihre Wirksamkeit derzeit durch den Zeit- und Arbeitsaufwand für Aufgaben nach dem Codieren begrenzt, einschließlich PR-Review, Debugging und Testing. Googles Erkenntnisse bestätigen diesen Trend: Argon lieferte 4 Änderungen, die beim Review durch Entwickler abgelehnt wurden, aufgrund von Bedenken hinsichtlich Zuverlässigkeit, Wartbarkeit, Kompatibilität oder messbarem Leistungsnutzen.
Präsentiert von: David Iparraguirre, Senior Product Marketing Manager bei Datadog, und Jessica Yang, Product Manager bei Datadog
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
One of the goals of Google engineers' was to learn "about how the model handles an existing codebase", a much harder task than creating "greenfield apps built from an empty folder", they say. To test this, they focused on optimizing the performance of their own Agent Development Kit (ADK), a codebase spanning over 200k lines of code across approximately 800 files and including nearly 17,000 unit tests.
Performance work is a hard test for a model because you can't just open one file and spot the slowdown. You have to look orthogonally to where the symptom appears and hold a map of how the entire codebase fits together over a long run.
After an initial, short run helped them identify what the prompt needed to include to ensure the agent followed the team's conventions for unit testing and benchmarking, Google engineers specified repository-specific guidelines through.agents/skills files, "like an onboarding guide for a new engineer". The agent was instructed to load only the required skill for the task, to avoid flooding the context window. Finally they came up with the following prompt, where they used Antigravity's /goal mode to ensure the goal was preserved across context compaction:
/goal Make ADK add no noticeable overhead to any agent: at startup, in long sessions, in multi-agent and workflow setups. Keep what the model receives and the public API unchanged, and back each change with a test that would catch a regression. Open one pull request against main that the ADK maintainers would approve, with before and after numbers in its description. Don't merge it. On task completion, Google explains, Argon's logs showed that the agent had read the repository guidelines, established performance baselines, proposed optimizations, reviewed its own changes, and ran all 16,892 open-source unit tests before finishing.
More importantly, Argon did the cross-module legwork a profiler can't do for you. A profiler will tell you that copying sessions and importing packages take time. What it won't do is trace every caller, mock target, and shared reference across 40 files so that speeding up those paths doesn't break existing apps.
The two optimizations finally accepted into the codebase improved how the ADK handled session history by filtering events before copying them and introduced lazy loading to prevent heavy packages from being imported until needed.
These changes made in-memory session preparation and package import faster by 40% and 21%, respectively. These tasks are not particularly expensive compared with the overall duration of an agent run, Google notes that the ADK supports multi-tool interactions spanning dozens or even hundreds of iterations, allowing these small performance gains to compound:
On a single LLM call that takes seconds, a human won't feel 28 ms or 78 ms. Across 158 internal turns of tool calling interactions, however, those copies compound: removing them cuts the full 158-turn run from 65.6 seconds to 56.1 seconds (nearly 10 seconds of pure framework overhead).
While Google's experience with Gemini 4 Argon optimizing the ADK codebase demonstrates AI agents' ability to modify existing codebases successfully, their effectiveness remains currently limited by the time and effort required for post-coding tasks, including PR review, debugging, and testing. Google's findings confirm this trend, with Argon producing 4 modifications that were rejected upon developer review because of concerns about reliability, maintainability, compatibility, or measurable performance benefits.
Presented by: David Iparraguirre - Senior Product Marketing Manager at Datadog, and Jessica Yang - Product Manager at Datadog