Google ADK 2.14: Stabile Sandboxes und A2A – was bedeutet das Upgrade?
Google stabilisiert wichtige Agenten-APIs, verbessert Evaluationen und begrenzt freie Skill-Kommandos. Bestehende Implementierungen müssen Breaking Changes prüfen.
Stabile APIs erleichtern Planung, aber A2A-Rechte, Sandboxgrenzen und Breaking Changes müssen vor dem Upgrade getestet werden.
1. Was der Release tatsächlich stabilisiert
Die offiziellen Notes benennen BaseEnvironment, LocalEnvironment, EnvironmentToolset, DaytonaEnvironment und E2BEnvironment als stabile APIs. Dateioperationen können bei unterstützten Umgebungen große Dateien in Blöcken lesen, statt jedes Dokument vollständig in den Agentenkontext zu laden. Der ContainerCodeExecutor unterstützt Ein- und Ausgabedateien. Diese API-Einstufungen erleichtern die Planung, ersetzen aber nicht die Prüfung der konkreten Isolation und der Laufzeitumgebung.
Ebenfalls als stabil bezeichnet Google die A2A-Integration. Mit dem Kommando „adk generate_agent_card“ kann eine Agentenkarte generiert werden. A2A beschreibt das Zusammenspiel von Agenten über standardisierte Interaktionen; die Freigabe von Daten, Identitäten und tatsächlichen Aktionen bleibt weiterhin eine eigenständige Systementscheidung.
2. Reproduzierbar testen statt einen Lauf vorführen
Mit MultiRunConfig, „adk eval --num_runs“ und der Parallelitätsoption lassen sich Evaluationsfälle mehrfach ausführen und deren Ergebnisse kombinieren. Der neue ToolArgsMatcher kann Argumente exakt, ohne Beachtung der Groß-/Kleinschreibung, mit numerischer Toleranz oder semantisch per LLM vergleichen.
Das ist relevant, weil ein einzelner erfolgreicher Agentenlauf die Streuung bei Planungs-, Tool- oder Retrievalfehlern verdeckt. AgentenCode empfiehlt, Fehlerklassen, Pass-Rate über mehrere Läufe und die tatsächlich erlaubten Aktionen zu messen. Eine semantische LLM-basierte Argumentbewertung sollte nicht ungeprüft als harte Sicherheitsfreigabe behandelt werden.
3. Ausführung von Skills: Ein engerer Aufrufvertrag
Besonders entscheidend ist das geänderte Verhalten von RunSkillScriptTool im Environment-Modus: statt einer freien Shell-Kommandozeichenfolge verwendet das Tool nun validierte Skriptpfade und strukturierte Argumente (args, short_options, positional_args). Der Hersteller bezeichnet dies ausdrücklich als Schließen einer Lücke, über die ein prompt-injiziertes Modell beliebige Shell-Kommandos ausführen konnte.
Die praktische Folge: Bestehende Skills oder Tests, die noch „command“ übergeben, können mit INVALID_ARGUMENTS scheitern. Der neue Vertrag reduziert eine Klasse frei zusammengesetzter Befehle, beweist aber nicht, dass alle Skill-Skripte, deren Abhängigkeiten oder ihre Berechtigungen ungefährlich sind.
4. Drei Breaking Changes, die Teams beachten müssen
| Altverhalten / Annahme | Neuer Stand laut ADK 2.14.0 | Vorbereitung |
|---|---|---|
| FunctionTool erhält bei Enum-Parametern Strings | Enum-Mitglieder statt Rohstrings | String-Vergleiche, JSON-Serialisierung und Schlüsselzugriffe prüfen |
| Beliebige Session-Konfiguration über create_session | Eingeschränkter Satz von Session-Optionen | Optionen in „state“ oder „session_id“ überführen, HTTP 400 abfangen |
| RunSkillScriptTool nutzt freie „command“-Zeichenfolge im Environment-Modus | Strukturierte Argumente und validierte Skriptpfade | Skills, Prompts, Eval-Sets und erlaubte Skripttypen migrieren |
Diese Tabelle ist eine redaktionelle Upgrade-Checkliste – keine Behauptung, dass der Wechsel in jeder Installation gleich ausfällt.
5. Kontext: Teams, Decisions und Speicher
Neu sind auch TeamsRunner zur Verbindung mit Microsoft Teams, ein OpenAIDecisionsClassifier für Workflow-/Tool-Gating-Fragen und Erweiterungen bei MongoDbMemoryService. „Verbindung“ bedeutet dabei nicht automatisch, dass ein Team bereits die nötigen Rechte, Datenverarbeitungsverträge oder Policies eingerichtet hat.
Google nennt für einen eigenen 30-Knoten-/200-Turn-Test eine 23 Prozent schnellere Ausführung bei 9 Prozent weniger Speicher-Spitze. Ohne unabhängige Wiederholung und Details zu Workload und Hardware ist das ein herstellerbezogener Messwert und kein allgemeines Performance-Versprechen.
6. AgentenCode-Entscheidungsmatrix: Was ist für wen wichtig?
| Einsatz | Nutzen aus dem Release | Offene Pflichtprüfung |
|---|---|---|
| Agenten mit Dateien oder Code | Stabilere Environment-APIs, Chunked I/O | Sandbox-Policy, Netzwerke, Dateischreibrechte, Secrets |
| Verteilte Agenten/A2A | Stabile A2A-Integration, Agent Card | Authentisierung, Trust Boundary, Policy zwischen Agenten |
| Qualitätssicherung | Mehrfach-Evals und Argument-Matcher | Verteilung und Aussagekraft der Testfälle, Freigabegrenzen |
| Bestehendes produktives ADK | Neue APIs und Integrationen | Drei Breaking Changes, Migration und Rollback |
Unsere Empfehlung: Version pinnen, Regressionstests mit repräsentativen Tool-Aufrufen ausführen, dann A2A-/Environment-Rechte getrennt testen. Erst nach überprüfbaren Kriterien produktive Automationen erweitern.
7. FAQ
Ist A2A damit automatisch sicher? Nein. Der Release-Status „stable“ betrifft die Integration, nicht eine unabhängige Sicherheitszertifizierung jeder Verbindung.
Ist jeder Skill-Shell-Aufruf jetzt erlaubt? Nein. Der neue Environment-Modus validiert Pfad und Argumente; erlaubte Skripttypen sind begrenzt.
Verbessern Mehrfach-Evals den Agenten automatisch? Nein. Sie liefern mehr Beobachtungen und können Schwankungen offenlegen. Sie ändern nicht selbst das Modell oder die Zugriffspolicy.
8. Primärquellen und redaktionelle Grenzen
- Google ADK Python v2.14.0 – offizielle Release Notes
- Google ADK Python – Quellrepository
- ADK-Dokumentation zur A2A-Integration
Methodik: Die Feature- und Breaking-Change-Angaben stammen aus dem offiziellen Changelog. Freigabematrizen und Migrationsreihenfolge sind eigenständige redaktionelle Analyse. Die Leistungszahl ist ein nicht unabhängig reproduzierter Herstellerwert, kein AgentenCode-Test.