+190 XP

Agents auf Google AI: das Agent Development Kit

# Agents auf Google AI: das Agent Development Kit

Mit Googles Agent Development Kit (ADK) bauen Sie Agents, die Tools in einer Schleife aufrufen, bis eine Aufgabe wirklich erledigt ist, statt eine bestmögliche Antwort zu liefern und zu hoffen. Das Agent-Konzept kennen Sie schon: ein Modell, das entscheiden kann zu handeln, Ergebnisse zu beobachten und erneut zu handeln. Diese Lektion zeigt, wie Google dieses Muster in ein Produkt gießt, wann sich die zusätzliche Komplexität lohnt und wie Sie einen echten Agent ausliefern.

Was ADK tatsächlich ist

ADK ist ein Open-Source-Framework für Python (mit Java-Support), um Agents im Code zu definieren. Es ist dasselbe Framework, das Google intern für Produkte wie Agentspace nutzt. Sie definieren einen Agent, geben ihm Tools, wählen ein Gemini-Modell, und ADK führt die Reason-Act-Observe-Schleife für Sie aus.

Die zentralen Objekte:

  • Agent: ein Modell plus Instructions plus eine Menge von Tools.
  • Tool: eine Python-Funktion (oder ein Built-in wie Google Search), die der Agent aufrufen kann.
  • Runner: die Komponente, die die Schleife ausführt und Sessions und State verwaltet.

ADK ist modellflexibel, aber auf Gemini abgestimmt. Sie entwickeln lokal, testen in einem eingebauten Web-UI und deployen dann auf Vertex AI Agent Engine, die managed Runtime von Google Cloud für Agents. Von lokal bis Produktion nutzen Sie denselben Code.

Wo ADK im Vergleich zu allem anderen steht

Sie haben mehrere Wege, auf Google AI „Agents zu machen“, und sie sind weniger Konkurrenten als unterschiedliche Flughöhen:

  • Gems in der Gemini-App: gespeicherte Personas und Instructions. Kein Code, keine Tool-Schleife.
  • Gemini API Function Calling: die Schleife bauen Sie selbst.
  • ADK: Schleife, State, Multi-Agent-Orchestrierung und Deployment werden für Sie übernommen.
  • Vertex AI Agent Engine: dort laufen ADK-Agents in Produktion.

Wenn das Modell nur einmal eine Funktion aufrufen soll, brauchen Sie ADK nicht. Greifen Sie danach, wenn die Aufgabe mehrstufig ist.

Wann ein Agent besser ist als ein einzelner Call

Ein einzelner Gemini-Call (auch mit Function Calling) ist das richtige Werkzeug, wenn die Arbeit aus einem Schritt besteht: diese E-Mail klassifizieren, diese Felder extrahieren, diese Antwort entwerfen. Geminis langer Kontext und die native Multimodalität lassen einen Call schon eine Menge erledigen.

Ein Agent lohnt sich, wenn die Anzahl der Schritte vorab unbekannt ist und davon abhängt, welche Zwischenergebnisse zurückkommen. Anzeichen, dass Sie diese Grenze überschritten haben:

  • Das Modell muss suchen, das Gefundene lesen und dann entscheiden, ob es erneut sucht.
  • Der Input jedes Schritts hängt vom Output des vorherigen Schritts ab.
  • Die Aufgabe erstreckt sich über mehrere Tools (Suche, dann ein Rechner, dann ein Datenbank-Write).
  • Sie wollen, dass der Agent erneut versucht oder die Strategie wechselt, wenn ein Tool fehlschlägt.

Eine Aufgabe wie „recherchiere und fasse dieses Thema zusammen“ ist das Standardbeispiel. Sie können nicht vorab wissen, wie viele Suchen es braucht, um ein Thema gut abzudecken. Das entscheidet der Agent zur Laufzeit. Dieses dynamische, datenabhängige Looping kann ein einzelner Call nicht leisten, und genau dafür existiert ADK.

Die Kosten sind real: mehr Latenz, mehr Tokens, mehr Fehlerquellen. Nutzen Sie für die Schleife Flash, wo es geht (schnell und günstig), reservieren Sie Pro für Schritte, die tiefes Reasoning brauchen, und greifen Sie nie zu einem Agent, wenn ein einzelner strukturierter Call ausreicht.

Ein konkreter Research-and-Summarize-Agent

Bauen wir einen. Der Agent nimmt ein Thema, nutzt Google Search Grounding, um aktuelle Informationen zu sammeln, loopt, bis er genug hat, und schreibt dann eine strukturierte Zusammenfassung.

Zuerst die Umgebung einrichten. Sie brauchen das SDK und einen Gemini-API-Key aus Google AI Studio (oder Vertex-AI-Credentials, wenn Sie in die Cloud deployen).

bash
pip install google-adk
export GOOGLE_API_KEY="your-key-here"
export GOOGLE_GENAI_USE_VERTEXAI=FALSE

Jetzt der Agent. ADK bringt ein eingebautes google_search-Tool mit, das Antworten in aktuellen Google-Search-Ergebnissen groundet, sodass Sie die Such-Infrastruktur nicht selbst schreiben.

python
from google.adk.agents import Agent
from google.adk.tools import google_search

root_agent = Agent(
    name="research_summarizer",
    model="gemini-2.5-flash",
    description="Researches a topic and writes a sourced summary.",
    instruction=(
        "You are a research assistant. Given a topic, search for "
        "current, credible information. Run multiple searches if the "
        "first results are thin or one-sided. Stop when you can cover "
        "the topic accurately. Then write a summary with: a two-line "
        "overview, 3 to 5 key findings as bullets, and a 'Sources' "
        "list. Never state a fact you did not find in results."
    ),
    tools=[google_search],
)

Diese instruction leistet die eigentliche Arbeit. Beachten Sie, dass sie dem Agent sagt, *wann er loopen soll* („run multiple searches if the first results are thin“) und *wann er aufhören soll* („when you can cover the topic accurately“). Vage Stop-Bedingungen sind die Hauptursache für Agents, die endlos loopen oder zu früh abbrechen.

Lokal ausführen

ADK gibt Ihnen ein Dev-UI, in dem Sie die Schleife beobachten können, inklusive jedem Tool-Call und dem Reasoning des Modells zwischen den Schritten. Aus dem Ordner, der Ihren Agent enthält:

bash
adk web

Das öffnet ein lokales Browser-UI, in dem Sie ein Thema eingeben und zusehen, wie der Agent sucht, beobachtet, wieder sucht und schreibt. Die Zwischenschritte zu sehen, ist der Weg, Instructions zu debuggen. Sucht der Agent einmal und hört auf, ist Ihre Stop-Bedingung zu lose. Sucht er achtmal für ein einfaches Thema, ziehen Sie sie an.

Für den Headless-Betrieb stellt ADK einen Runner bereit, den Sie aus eigenem Code aufrufen oder in eine API wrappen können.

Warum Grounding hier wichtig ist

Das google_search-Tool ist mehr als einfache Suche. Es ist Grounding mit Google Search, das echte Ergebnisse in das Modell einspeist und Quellen-Metadaten zurückgibt. Für einen Research-Agent ist das der Unterschied zwischen einer selbstbewussten Zusammenfassung und einer *korrekten*. Ohne Grounding schreibt das Modell aus Trainingsdaten mit einem Cutoff. Mit Grounding liest der Agent das heutige Web. Grounden Sie immer Agents, die faktische Aussagen über die aktuelle Welt machen.

Build your first AI agent with ADK

Watch on YouTube

Ein eigenes Tool hinzufügen

Die eingebaute Suche ist in Ordnung, aber echte Agents brauchen *Ihre* Tools: eine Funktion, die Ihre Datenbank abfragt, in Slack postet oder in ein Google Sheet schreibt. In ADK ist ein Tool eine typisierte Python-Funktion mit einem klaren Docstring. Der Docstring ist keine Dokumentation für Sie, er ist die Beschreibung, die das Modell liest, um zu entscheiden, wann es das Tool aufruft.

python
def save_summary(topic: str, summary: str) -> dict:
    """Saves a finished research summary to the team archive.

    Args:
        topic: The researched topic, used as the record title.
        summary: The full formatted summary text to store.

    Returns:
        A dict with 'status' and the saved record 'id'.
    """
    record_id = _write_to_store(topic, summary)
    return {"status": "ok", "id": record_id}

Fügen Sie es der tools-Liste des Agents neben google_search hinzu. Jetzt kann der Agent in einer Schleife recherchieren *und* archivieren. Schreiben Sie Tool-Docstrings, als würden Sie die Funktion einem klugen neuen Kollegen erklären: was sie tut, was jedes Argument bedeutet, was sie zurückgibt. Schlampige Docstrings führen dazu, dass das Modell Tools zum falschen Zeitpunkt aufruft oder unbrauchbare Argumente übergibt.

Eine Einschränkung im Blick behalten: ADKs eingebaute Tools wie google_search haben je nach Modell Regeln zur Kombination mit eigenen Tools. Im Zweifel verteilen Sie die Zuständigkeiten auf mehrere Agents.

Multi-Agent: wenn eine Schleife nicht reicht

Die eigentliche Stärke von ADK zeigt sich bei Multi-Agent-Systemen: ein Koordinator-Agent, der an spezialisierte Sub-Agents delegiert. Für unser Beispiel könnten Sie einen researcher-Agent (nur Suche) und einen writer-Agent (Formatierung und Archivierung) haben, mit einem coordinator, der zwischen ihnen routet.

Das ist wichtig, weil jeder Agent fokussiert bleibt. Ein fokussierter Agent mit drei Tools verhält sich weit zuverlässiger als ein Agent, der zehn jongliert. Sie definieren Sub-Agents und übergeben sie über den Parameter sub_agents an einen Parent; der Parent entscheidet, wer was übernimmt. Starten Sie mit einem einzelnen Agent und teilen Sie erst auf, wenn die Instructions eines Agents lang und voller Bedingungen werden.

Wissenscheck

1. Was unterscheidet einen Agent (wie mit ADK gebaut) grundlegend von einem einzelnen Gemini-Call mit Function Calling?

2. Wann lohnt sich laut Lektion die zusätzliche Komplexität eines Agents gegenüber einem einzelnen Call wirklich?

3. Welche Rolle hat das Runner-Objekt in ADK?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aussagen, die die verschiedenen „Flughöhen“ für Agents auf Google AI korrekt beschreiben.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Anzeichen, die darauf hindeuten, dass eine Aufgabe die Grenze überschritten hat und einen Agent statt eines einzelnen Calls braucht.

Wählen Sie alle richtigen Antworten aus.

In Produktion auf Vertex AI

Lokales adk web ist zum Bauen. Produktion ist Vertex AI Agent Engine, ein managed Service, der Ihren Agent hostet, Sessions verwaltet, skaliert und sich in den Rest von Vertex AI integriert. Derselbe Agent-Code deployt mit minimalen Änderungen; im Wesentlichen wechseln Sie von API-Key-Auth zu Vertex-AI-Auth und richten ADK auf Ihr Google-Cloud-Projekt aus.

Was Sie bekommen, wenn Sie auf Agent Engine deployen statt einen eigenen Server zu betreiben:

  • Managed Sessions und State: das Conversation-Memory bleibt erhalten, ohne dass Sie dafür eine Datenbank bauen.
  • Skalierung und Monitoring: läuft als managed Endpoint mit eingebauter Observability.
  • Enterprise-Kontrollen: liegt in Ihrem Google-Cloud-Projekt, unter Ihren IAM- und VPC-Regeln, was zählt, wenn der Agent interne Daten anfasst.

Für Agents, die auf Unternehmensdaten operieren, ist der letzte Punkt der ganze Grund, auf Vertex zu sein statt die reine Gemini API aus einem Skript aufzurufen.

Evaluation: der Schritt, den man überspringt

Ein Agent, der in einer Demo funktioniert, und ein Agent, der mit echten Inputs funktioniert, sind zwei verschiedene Dinge. ADK enthält eine Evaluation-Funktion: Sie definieren Testfälle (Input plus erwartetes Verhalten oder erwartete Tool-Trajektorie), und ADK lässt den Agent dagegen laufen und bewertet sowohl die finale Antwort als auch, *welche Tools er in welcher Reihenfolge aufgerufen hat*.

Diese Trajektorien-Prüfung ist agentspezifisch und sehr wichtig. Einen einzelnen Call bewerten Sie nur am Output. Einen Agent bewerten Sie zusätzlich an seinem *Pfad*, denn ein Agent, der zufällig zur richtigen Antwort kommt (oder zwanzig Tool-Calls dafür verbrennt), ist nicht produktionsreif. Bauen Sie eine Handvoll Eval-Fälle, bevor Sie deployen, und lassen Sie sie jedes Mal neu laufen, wenn Sie eine Instruction ändern.

Ein realistisches Mental Model

Denken Sie an ADK als die Schicht, die Gemini von „einem Modell, das einen Tool-Call vorschlagen kann“ in „einen Prozess, der eine Aufgabe zum Abschluss treibt“ verwandelt. Das Modell ist weiterhin das Gehirn. ADK ist die Schleife, das Memory, das Routing, das Deployment und das Test-Harness darum herum. Sie bringen drei Dinge: präzise Instructions (besonders Stop-Bedingungen), gut beschriebene Tools und Eval-Fälle. ADK und Vertex erledigen den Rest.

Key Takeaways

  • Greifen Sie nur zu einem Agent, wenn die Schritte dynamisch sind. Ist die Arbeit einstufig, nehmen Sie einen einzelnen gegroundeten Gemini-Call. Agents bringen Latenz, Kosten und Fehlerquellen; sie müssen sich verdienen.
  • Stop-Bedingungen stehen in der Instruction. Die meisten ausufernden oder faulen Agents repariert man, indem man dem Modell explizit sagt, wann es weitermachen und wann es fertig sein soll, nicht indem man das Modell wechselt.
  • Tool-Docstrings sind Prompts. Das Modell wählt Tools und Argumente anhand des Docstrings. Schreiben Sie jeden klar, mit typisierten Args und beschriebenem Rückgabewert.
  • Grounden Sie alles Faktische mit dem eingebauten google_search-Tool, damit Zusammenfassungen das aktuelle Web abbilden und nicht den Trainings-Cutoff.
  • Entwickeln Sie mit `adk web`, deployen Sie auf Vertex AI Agent Engine und sichern Sie Deployments mit ADK-Evals ab, die die Tool-Trajektorie prüfen, nicht nur die finale Antwort.