Multi-Agenten-System erstellen

1. Einführung

Übersicht

In diesem Lab geht es um mehr als nur einfache Chatbots. Sie erstellen ein verteiltes Multi-Agenten-System.

Ein einzelnes LLM kann zwar Fragen beantworten, aber die Komplexität der realen Welt erfordert oft spezialisierte Rollen. Sie bitten Ihren Backend-Entwickler nicht, die Benutzeroberfläche zu gestalten, und Sie bitten Ihren Designer nicht, Datenbankabfragen zu optimieren. Ebenso können wir spezialisierte KI-Agenten erstellen, die sich auf eine Aufgabe konzentrieren und sich gegenseitig koordinieren, um komplexe Probleme zu lösen.

Sie erstellen ein System zur Kurserstellung, das aus Folgendem besteht:

  1. Researcher Agent: Verwendet google_search, um aktuelle Informationen zu finden.
  2. Judge Agent: Die Recherche wird auf Qualität und Vollständigkeit geprüft.
  3. Content Builder-Agent: Die Rechercheergebnisse werden in einen strukturierten Kurs umgewandelt.
  4. Orchestrator-Agent: Er verwaltet den Workflow und die Kommunikation zwischen diesen Spezialisten.

Vorbereitung

  • Grundlegende Python-Kenntnisse
  • Vertrautheit mit der Google Cloud Console

Aufgaben

  • Definieren Sie einen Tool-nutzenden Agenten (researcher), der im Web suchen kann.
  • Implementieren Sie die strukturierte Ausgabe mit Pydantic für judge.
  • Mit dem Agent-to-Agent-Protokoll (A2A) können Sie eine Verbindung zu Remote-Agenten herstellen.
  • Erstellen Sie eine LoopAgent, um eine Feedbackschleife zwischen dem Prüfer und dem Richter zu schaffen.
  • Führen Sie das verteilte System lokal mit dem ADK aus.
  • Stellen Sie das Multi-Agenten-System in Google Cloud Run bereit.

Architektur- und Orchestrierungsprinzipien

Bevor wir Code schreiben, sehen wir uns an, wie diese Agents zusammenarbeiten. Wir entwickeln eine Pipeline zur Kurserstellung.

Systemdesign

Architekturdiagramm

Orchestrierung mit Agents

Standard-Agents wie der Researcher funktionieren. Orchestrator-Agents (z. B. LoopAgent oder SequentialAgent) verwalten andere Agents. Sie haben keine eigenen Tools. Ihr „Tool“ ist die Delegation.

  1. LoopAgent: Dies entspricht einer while-Schleife im Code. Es wird eine Sequenz von Agenten wiederholt ausgeführt, bis eine Bedingung erfüllt ist oder die maximale Anzahl von Iterationen erreicht wurde. Wir verwenden diese für den Recherchezyklus:
    • Researcher findet Informationen.
    • Judge kritisiert es.
    • Wenn Judge „Fail“ zurückgibt, lässt EscalationChecker die Schleife weiterlaufen.
    • Wenn Judge „Pass“ sagt, unterbricht EscalationChecker die Schleife.
  2. SequentialAgent: Dies entspricht einer standardmäßigen Skriptausführung. Sie führt Agents nacheinander aus. Wir verwenden diese für die Pipeline auf hoher Ebene:
    • Führen Sie zuerst den Research Loop aus, bis er mit guten Daten abgeschlossen ist.
    • Führen Sie dann Content Builder aus, um den Kurs zu schreiben.

Durch die Kombination dieser beiden Ansätze entsteht ein robustes System, das sich selbst korrigieren kann, bevor die endgültige Ausgabe generiert wird.

2. Einrichtung

Umgebung einrichten

Cloud Shell öffnen: Öffnen Sie einen neuen Tab und geben Sie shell.cloud.google.com ein.

Starter-Code abrufen

  1. Klonen Sie das Starter-Repository in Ihr Basisverzeichnis:
    cd ~
git clone https://github.com/amitkmaraj/prai-roadshow-lab-1-starter.git
cd prai-roadshow-lab-1-starter
  2. Führen Sie das Initialisierungsskript aus, um Onramp-Guthaben mit der Abrechnung zu verknüpfen.
    chmod +x ./init.sh
./init.sh
  3. Öffnen Sie diesen Ordner in Ihrem Editor.

APIs aktivieren

Nachdem Sie ein neues Projekt erstellt haben, führen Sie den folgenden Befehl aus, um die erforderlichen Google Cloud-Dienste zu aktivieren:

gcloud services enable \
    run.googleapis.com \
    artifactregistry.googleapis.com \
    cloudbuild.googleapis.com \
    aiplatform.googleapis.com \
    compute.googleapis.com

Dies kann einige Sekunden dauern.

Abhängigkeiten installieren

Wir verwenden uv für die schnelle Abhängigkeitsverwaltung.

  1. Installieren Sie die Projektabhängigkeiten:
    # Ensure you have uv installed: pip install uv
uv sync
  2. Legen Sie Ihre Google Cloud-Projekt-ID fest.
    • Tipp: Sie finden Ihre Projekt-ID im Cloud Console-Dashboard oder durch Ausführen von gcloud config get-value project.
    export GOOGLE_CLOUD_PROJECT=$(gcloud config get-value project)
  3. Legen Sie die restlichen Umgebungsvariablen fest:
    export GOOGLE_CLOUD_LOCATION=us-central1
export GOOGLE_GENAI_USE_VERTEXAI=true
    Warnung:Umgebungsvariablen werden nicht in neuen Terminalsitzungen beibehalten.     Wenn Sie einen neuen Terminaltab öffnen, müssen Sie diese Exportbefehle noch einmal ausführen.

3. 🕵️ Der Recherche-Agent

Researcher-Agent

Der Researcher ist ein Spezialist. Seine einzige Aufgabe ist es, Informationen zu finden. Dazu benötigt sie Zugriff auf ein Tool: die Google Suche.

Warum wird der Researcher separat behandelt?

Deep Dive:Warum gibt es nicht nur einen Agenten, der alles erledigt?

Kleine, fokussierte Agents lassen sich leichter bewerten und debuggen. Wenn die Recherche schlecht ist, wiederholen Sie den Prompt des Researchers. Wenn die Kursformatierung schlecht ist, können Sie den Content Builder verwenden, um sie zu verbessern. Bei einem monolithischen „All-in-One“-Prompt führt die Korrektur eines Aspekts oft dazu, dass ein anderer Aspekt nicht mehr funktioniert.

  1. Wenn Sie in Cloud Shell arbeiten, führen Sie den folgenden Befehl aus, um den Cloud Shell-Editor zu öffnen:
    cloudshell workspace .
    Wenn Sie in Ihrer lokalen Umgebung arbeiten, öffnen Sie Ihre bevorzugte IDE.
  2. Öffnen Sie agents/researcher/agent.py.
  3. Es wird ein Gerüst mit einem TODO angezeigt.
  4. Fügen Sie den folgenden Code hinzu, um den researcher-Agenten zu definieren:
    # ... existing imports ...

# Define the Researcher Agent
researcher = Agent(
    name="researcher",
    model=MODEL,
    description="Gathers information on a topic using Google Search.",
    instruction="""
    You are an expert researcher. Your goal is to find comprehensive and accurate information on the user's topic.
    Use the `google_search` tool to find relevant information.
    Summarize your findings clearly.
    If you receive feedback that your research is insufficient, use the feedback to refine your next search.
    """,
    tools=[google_search],
)

root_agent = researcher

Schlüsselkonzept: Tool-Nutzung

Wir übergeben tools=[google_search]. Das ADK übernimmt die Komplexität der Beschreibung dieses Tools für das LLM. Wenn das Modell entscheidet, dass es Informationen benötigt, wird ein strukturierter Tool-Aufruf generiert. Das ADK führt die Python-Funktion google_search aus und gibt das Ergebnis an das Modell zurück.

4. ⚖️ Der Judge-Agent

Judge-Agent

Der Researcher arbeitet hart, aber LLMs können faul sein. Wir benötigen einen Juror, der sich die Arbeit ansieht. Der Judge akzeptiert die Recherche und gibt eine strukturierte Bewertung (Bestanden/Nicht bestanden) zurück.

Strukturierte Ausgabe

Vertiefung:Um Workflows zu automatisieren, benötigen wir vorhersehbare Ausgaben. Ein unstrukturierter Rezensionstext ist schwer programmatisch zu analysieren. Durch die Erzwingung eines JSON-Schemas (mit Pydantic) wird sichergestellt, dass der Judge einen booleschen Wert pass oder fail zurückgibt, auf den unser Code zuverlässig reagieren kann.

  1. Öffnen Sie agents/judge/agent.py.
  2. Definieren Sie das JudgeFeedback-Schema und den judge-Agent.
    # 1. Define the Schema
class JudgeFeedback(BaseModel):
    """Structured feedback from the Judge agent."""
    status: Literal["pass", "fail"] = Field(
        description="Whether the research is sufficient ('pass') or needs more work ('fail')."
    )
    feedback: str = Field(
        description="Detailed feedback on what is missing. If 'pass', a brief confirmation."
    )

# 2. Define the Agent
judge = Agent(
    name="judge",
    model=MODEL,
    description="Evaluates research findings for completeness and accuracy.",
    instruction="""
    You are a strict editor.
    Evaluate the 'research_findings' against the user's original request.
    If the findings are missing key info, return status='fail'.
    If they are comprehensive, return status='pass'.
    """,
    output_schema=JudgeFeedback,
    # Disallow delegation because it should only output the schema
    disallow_transfer_to_parent=True,
    disallow_transfer_to_peers=True,
)

root_agent = judge

Schlüsselkonzept: Agent-Verhalten einschränken

Wir legen disallow_transfer_to_parent=True und disallow_transfer_to_peers=True fest. Dadurch wird der Richter gezwungen, nur die strukturierte JudgeFeedback zurückzugeben. Es kann nicht entscheiden, mit dem Nutzer zu „chatten“ oder an einen anderen Agenten zu delegieren. Das macht sie zu einer deterministischen Komponente in unserem Logikablauf.

5. 🧪 Tests in Isolation

Bevor wir sie verbinden, können wir prüfen, ob jeder Agent funktioniert. Mit dem ADK können Sie einzelne Agents ausführen.

Schlüsselkonzept: Die interaktive Laufzeit

adk run startet eine einfache Umgebung, in der Sie der „Nutzer“ sind. So können Sie die Anweisungen und die Tool-Nutzung des Agents isoliert testen. Wenn der Agent hier fehlschlägt (z.B. Google Suche nicht verwenden kann), schlägt er definitiv bei der Orchestrierung fehl.

  1. Führen Sie den Researcher interaktiv aus. Beachten Sie, dass wir auf das spezifische Agent-Verzeichnis verweisen:
    # This runs the researcher agent in interactive mode
uv run adk run agents/researcher
  2. Geben Sie in den Chat-Prompt Folgendes ein:
    Find the population of Tokyo in 2020
    Es sollte das Google Suche-Tool verwendet und die Antwort zurückgegeben werden.Hinweis: Wenn Sie einen Fehler sehen, der darauf hinweist, dass das Projekt, der Standort und die Verwendung von Vertex nicht festgelegt sind, prüfen Sie, ob Ihre Projekt-ID festgelegt ist, und führen Sie Folgendes aus:
    export GOOGLE_CLOUD_PROJECT=$(gcloud config get-value project)
export GOOGLE_CLOUD_LOCATION=us-central1
export GOOGLE_GENAI_USE_VERTEXAI=true
  3. Beenden Sie den Chat (Strg+C).
  4. Führen Sie den Judge interaktiv aus:
    uv run adk run agents/judge
  5. Simulieren Sie die Eingabe im Chat-Prompt:
    Topic: Tokyo. Findings: Tokyo is a city.
    Es sollte status='fail' zurückgegeben werden, da die Ergebnisse zu kurz sind.

6. ✍️ Der Content Builder-Agent

Content Builder

Der Content Builder ist der kreative Autor. Dabei werden die genehmigten Forschungsergebnisse in einen Kurs umgewandelt.

  1. Öffnen Sie agents/content_builder/agent.py.
  2. Definieren Sie den content_builder-Agenten.
    content_builder = Agent(
    name="content_builder",
    model=MODEL,
    description="Transforms research findings into a structured course.",
    instruction="""
    You are an expert course creator.
    Take the approved 'research_findings' and transform them into a well-structured, engaging course module.

    **Formatting Rules:**
    1. Start with a main title using a single `#` (H1).
    2. Use `##` (H2) for main section headings.
    3. Use bullet points and clear paragraphs.
    4. Maintain a professional but engaging tone.

    Ensure the content directly addresses the user's original request.
    """,
)
root_agent = content_builder

Wichtiges Konzept: Weitergabe von Kontext

Sie fragen sich vielleicht: „Woher weiß Content Builder, was Researcher gefunden hat?“ Im ADK teilen sich Agenten in einer Pipeline einen session.state. Später konfigurieren wir im Orchestrator den Researcher und den Judge so, dass sie ihre Ausgaben in diesem gemeinsamen Status speichern. Der Prompt des Content Builders hat effektiv Zugriff auf diesen Verlauf.

7. 🎻 Der Orchestrator

Orchestrator-Agent

Der Orchestrator ist der Manager unseres Multi-Agent-Teams. Im Gegensatz zu den spezialisierten Agents (Researcher, Judge, Content Builder), die bestimmte Aufgaben ausführen, koordiniert der Orchestrator den Workflow und sorgt dafür, dass Informationen richtig zwischen ihnen fließen.

🌐 Die Architektur: Agent-to-Agent (A2A)

A2A-Architektur

In diesem Lab erstellen wir ein verteiltes System. Anstatt alle Agents in einem einzigen Python-Prozess auszuführen, stellen wir sie als unabhängige Mikrodienste bereit. So kann jeder Agent unabhängig skaliert werden und ausfallen, ohne dass das gesamte System abstürzt.

Dazu verwenden wir das Agent-to-Agent-Protokoll (A2A).

Das A2A-Protokoll

Detaillierte Informationen:In einem Produktionssystem werden Agents auf verschiedenen Servern oder sogar in verschiedenen Clouds ausgeführt. Das A2A-Protokoll bietet eine standardisierte Möglichkeit, wie sie sich gegenseitig über HTTP erkennen und miteinander kommunizieren können. RemoteA2aAgent ist der ADK-Client für dieses Protokoll.

  1. Öffnen Sie agents/orchestrator/agent.py.
  2. Suchen Sie den Kommentar # TODO: Define Remote Agents oder den Abschnitt für Remote-Agent-Definitionen.
  3. Fügen Sie den folgenden Code hinzu, um die Verbindungen zu definieren. Achten Sie darauf, dass Sie diesen Code nach den Importen und vor allen anderen Agent-Definitionen einfügen.
    # ... existing code ...

# Connect to the Researcher (Localhost port 8001)
researcher_url = os.environ.get("RESEARCHER_AGENT_CARD_URL", "http://localhost:8001/a2a/agent/.well-known/agent-card.json")
researcher = RemoteA2aAgent(
    name="researcher",
    agent_card=researcher_url,
    description="Gathers information using Google Search.",
    # IMPORTANT: Save the output to state for the Judge to see
    after_agent_callback=create_save_output_callback("research_findings"),
    # IMPORTANT: Use authenticated client for communication
    httpx_client=create_authenticated_client(researcher_url)
)

# Connect to the Judge (Localhost port 8002)
judge_url = os.environ.get("JUDGE_AGENT_CARD_URL", "http://localhost:8002/a2a/agent/.well-known/agent-card.json")
judge = RemoteA2aAgent(
    name="judge",
    agent_card=judge_url,
    description="Evaluates research.",
    after_agent_callback=create_save_output_callback("judge_feedback"),
    httpx_client=create_authenticated_client(judge_url)
)

# Content Builder (Localhost port 8003)
content_builder_url = os.environ.get("CONTENT_BUILDER_AGENT_CARD_URL", "http://localhost:8003/a2a/agent/.well-known/agent-card.json")
content_builder = RemoteA2aAgent(
    name="content_builder",
    agent_card=content_builder_url,
    description="Builds the course.",
    httpx_client=create_authenticated_client(content_builder_url)
)

8. 🛑 Eskalationsprüfung

Eine Schleife muss beendet werden können. Wenn der Richter „Bestanden“ sagt, möchten wir die Schleife sofort verlassen und zum Content Builder wechseln.

Benutzerdefinierte Logik mit BaseAgent

Weitere Informationen:Nicht alle Agenten verwenden LLMs. Manchmal benötigen Sie nur eine einfache Python-Logik. Mit BaseAgent können Sie einen Agenten definieren, der nur Code ausführt. In diesem Fall prüfen wir den Sitzungsstatus und verwenden EventActions(escalate=True), um LoopAgent zu signalisieren, dass es beendet werden soll.

  1. Noch in agents/orchestrator/agent.py.
  2. Suchen Sie nach dem EscalationChecker-Platzhalter TODO.
  3. Ersetzen Sie sie durch die folgende Implementierung:
    class EscalationChecker(BaseAgent):
    """Checks the judge's feedback and escalates (breaks the loop) if it passed."""

    async def _run_async_impl(
        self, ctx: InvocationContext
    ) -> AsyncGenerator[Event, None]:
        # Retrieve the feedback saved by the Judge
        feedback = ctx.session.state.get("judge_feedback")
        print(f"[EscalationChecker] Feedback: {feedback}")

        # Check for 'pass' status
        is_pass = False
        if isinstance(feedback, dict) and feedback.get("status") == "pass":
            is_pass = True
        # Handle string fallback if JSON parsing failed
        elif isinstance(feedback, str) and '"status": "pass"' in feedback:
            is_pass = True

        if is_pass:
            # 'escalate=True' tells the parent LoopAgent to stop looping
            yield Event(author=self.name, actions=EventActions(escalate=True))
        else:
            # Continue the loop
            yield Event(author=self.name)

escalation_checker = EscalationChecker(name="escalation_checker")

Wichtiges Konzept: Steuerung des Ablaufs über Ereignisse

Agents kommunizieren nicht nur mit Text, sondern auch mit Ereignissen. Durch das Yielden eines Ereignisses mit escalate=True sendet dieser Agent ein Signal an seinen übergeordneten Agenten (LoopAgent). Der LoopAgent ist so programmiert, dass er dieses Signal abfängt und die Schleife beendet.

9. 🔁 Der Research-Zyklus

Rechercheschleife

Wir brauchen einen Feedback-Loop: Recherchieren –> Bewerten –> (Fehler) –> Recherchieren –> …

  1. Noch in agents/orchestrator/agent.py.
  2. Fügen Sie die research_loop-Definition hinzu. Platzieren Sie diesen nach der Klasse EscalationChecker und der Instanz escalation_checker.
    research_loop = LoopAgent(
    name="research_loop",
    description="Iteratively researches and judges until quality standards are met.",
    sub_agents=[researcher, judge, escalation_checker],
    max_iterations=3,
)

Schlüsselkonzept: LoopAgent

Die LoopAgent durchläuft ihre sub_agents in der Reihenfolge.

  1. researcher: Daten finden.
  2. judge: Daten werden ausgewertet.
  3. escalation_checker: Legt fest, ob yield Event(escalate=True). Wenn escalate=True eintritt, wird die Schleife vorzeitig beendet. Andernfalls wird die Anfrage beim Researcher neu gestartet (bis zu max_iterations).

10. 🔗 Die endgültige Pipeline

Finale Pipeline

Schneide die einzelnen Clips zusammen.

  1. Noch in agents/orchestrator/agent.py.
  2. Definieren Sie root_agent unten in der Datei. Achten Sie darauf, dass dadurch alle vorhandenen root_agent = None-Platzhalter ersetzt werden.
    root_agent = SequentialAgent(
    name="course_creation_pipeline",
    description="A pipeline that researches a topic and then builds a course from it.",
    sub_agents=[research_loop, content_builder],
)

Schlüsselkonzept: Hierarchische Zusammensetzung

research_loop ist selbst ein Agent (ein LoopAgent). Er wird wie jeder andere Sub-Agent im SequentialAgent behandelt. Dank dieser Zusammensetzbarkeit können Sie komplexe Logik erstellen, indem Sie einfache Muster verschachteln (Schleifen in Sequenzen, Sequenzen in Routern usw.).

11. 💻 Lokal ausführen

Bevor wir alles ausführen, sehen wir uns an, wie das ADK die verteilte Umgebung lokal simuliert.

Im Detail: So funktioniert die lokale Entwicklung

In einer Mikrodienstarchitektur wird jeder Agent als eigener Server ausgeführt. Bei der Bereitstellung haben Sie vier verschiedene Cloud Run-Dienste. Das lokale Simulieren kann mühsam sein, wenn Sie vier Terminaltabs öffnen und vier Befehle ausführen müssen.

Mit diesem Skript werden uvicorn-Prozesse für Researcher (Port 8001), Judge (8002) und Content Builder (8003) gestartet. Es werden Umgebungsvariablen wie RESEARCHER_AGENT_CARD_URL festgelegt und an den Orchestrator (Port 8004) übergeben. Genau so werden wir es später in der Cloud konfigurieren.

App wird ausgeführt

  1. Führen Sie das Orchestrierungsskript aus:
    ./run_local.sh
    Dadurch werden vier separate Prozesse gestartet.
  2. Testen
    • Wenn Sie Cloud Shell verwenden:Klicken Sie oben rechts im Terminal auf die Schaltfläche Webvorschau > Vorschau auf Port 8080 > Port ändern zu 8000.
    • Bei lokaler Ausführung:Öffnen Sie http://localhost:8000 in Ihrem Browser.
    • Aufforderung: „Erstelle einen Kurs über die Geschichte des Kaffees.“
    • Beobachten:Der Orchestrator ruft den Researcher an. Die Ausgabe geht an den Judge. Wenn der Judge die Antwort ablehnt, geht es weiter mit der nächsten Antwort.
    Fehlerbehebung
    • „Internal Server Error“ / Authentifizierungsfehler:Wenn Authentifizierungsfehler auftreten (z.B. im Zusammenhang mit google-auth), müssen Sie gcloud auth application-default login ausführen, wenn Sie das Tool auf einem lokalen Computer ausführen. Prüfen Sie in Cloud Shell, ob die Umgebungsvariable GOOGLE_CLOUD_PROJECT richtig festgelegt ist.
    • Terminalfehler:Wenn der Befehl in einem neuen Terminalfenster fehlschlägt, müssen Sie die Umgebungsvariablen (GOOGLE_CLOUD_PROJECT usw.) noch einmal exportieren.
  3. Agents isoliert testen:Auch wenn das gesamte System ausgeführt wird, können Sie bestimmte Agents testen, indem Sie ihre Ports direkt ansprechen. Das ist nützlich, um eine bestimmte Komponente zu debuggen, ohne die gesamte Kette auszulösen.
    • Nur für Forscher (Port 8001) : http://localhost:8001
    • Nur Judge (Port 8002): http://localhost:8002
    • Nur Content Builder (Port 8003): http://localhost:8003
    • Orchestrator (Port 8004) : http://localhost:8004 (direkter Zugriff auf die Orchestrator-Logik)

12. 🚀 In Cloud Run bereitstellen

Die endgültige Validierung erfolgt in der Cloud. Wir stellen jeden Agenten als separaten Dienst bereit.

Informationen zur Bereitstellungskonfiguration

Wenn Sie Agents in Cloud Run bereitstellen, werden mehrere Umgebungsvariablen übergeben, um ihr Verhalten und ihre Konnektivität zu konfigurieren:

  • GOOGLE_CLOUD_PROJECT: Sorgt dafür, dass der Agent das richtige Google Cloud-Projekt für Logging und Vertex AI-Aufrufe verwendet.
  • GOOGLE_GENAI_USE_VERTEXAI: Weist das Agent-Framework (ADK) an, Vertex AI für die Modellinferenz zu verwenden, anstatt Gemini APIs direkt aufzurufen.
  • [AGENT]_AGENT_CARD_URL: Das ist entscheidend für den Orchestrator. Es teilt dem Orchestrator mit, wo sich die Remote-Agents befinden. Wenn Sie diese Einstellung auf die bereitgestellte Cloud Run-URL (insbesondere den Agent-Kartenpfad) festlegen, kann der Orchestrator die Researcher-, Judge- und Content Builder-Agents über das Internet erkennen und mit ihnen kommunizieren.
  1. Researcher bereitstellen:
    gcloud run deploy researcher \
  --source agents/researcher/ \
  --region us-central1 \
  --allow-unauthenticated \
  --labels dev-tutorial=prod-ready-1 \
  --set-env-vars GOOGLE_CLOUD_PROJECT=$GOOGLE_CLOUD_PROJECT \
  --set-env-vars GOOGLE_GENAI_USE_VERTEXAI="true"
    URL erfassen:
    RESEARCHER_URL=$(gcloud run services describe researcher --region us-central1 --format='value(status.url)')
echo $RESEARCHER_URL
  2. Judge bereitstellen:
    gcloud run deploy judge \
  --source agents/judge/ \
  --region us-central1 \
  --allow-unauthenticated \
  --labels dev-tutorial=prod-ready-1 \
  --set-env-vars GOOGLE_CLOUD_PROJECT=$GOOGLE_CLOUD_PROJECT \
  --set-env-vars GOOGLE_GENAI_USE_VERTEXAI="true"
    URL erfassen:
    JUDGE_URL=$(gcloud run services describe judge --region us-central1 --format='value(status.url)')
echo $JUDGE_URL
  3. Content Builder bereitstellen:
    gcloud run deploy content-builder \
  --source agents/content_builder/ \
  --region us-central1 \
  --allow-unauthenticated \
  --labels dev-tutorial=prod-ready-1 \
  --set-env-vars GOOGLE_CLOUD_PROJECT=$GOOGLE_CLOUD_PROJECT \
  --set-env-vars GOOGLE_GENAI_USE_VERTEXAI="true"
    URL erfassen:
    CONTENT_BUILDER_URL=$(gcloud run services describe content-builder --region us-central1 --format='value(status.url)')
echo $CONTENT_BUILDER_URL
  4. Orchestrator bereitstellen:Konfigurieren Sie den Orchestrator mit den erfassten Umgebungsvariablen.
    gcloud run deploy orchestrator \
  --source agents/orchestrator/ \
  --region us-central1 \
  --allow-unauthenticated \
  --labels dev-tutorial=prod-ready-1 \
  --set-env-vars RESEARCHER_AGENT_CARD_URL=$RESEARCHER_URL/a2a/agent/.well-known/agent-card.json \
  --set-env-vars JUDGE_AGENT_CARD_URL=$JUDGE_URL/a2a/agent/.well-known/agent-card.json \
  --set-env-vars CONTENT_BUILDER_AGENT_CARD_URL=$CONTENT_BUILDER_URL/a2a/agent/.well-known/agent-card.json \
  --set-env-vars GOOGLE_CLOUD_PROJECT=$GOOGLE_CLOUD_PROJECT \
  --set-env-vars GOOGLE_GENAI_USE_VERTEXAI="true"
    URL erfassen:
    ORCHESTRATOR_URL=$(gcloud run services describe orchestrator --region us-central1 --format='value(status.url)')
echo $ORCHESTRATOR_URL
  5. Frontend bereitstellen:
    gcloud run deploy course-creator \
    --source app \
    --region us-central1 \
    --allow-unauthenticated \
    --labels dev-tutorial=prod-ready-1 \
    --set-env-vars AGENT_SERVER_URL=$ORCHESTRATOR_URL \
    --set-env-vars GOOGLE_CLOUD_PROJECT=$GOOGLE_CLOUD_PROJECT
  6. Remote-Bereitstellung testen:Öffnen Sie die URL Ihres bereitgestellten Orchestrators. Die Ausführung erfolgt jetzt vollständig in der Cloud und nutzt die serverlose Infrastruktur von Google, um Ihre Agents zu skalieren. Hinweis: Alle Microservices und ihre URLs finden Sie in der Cloud Run-Oberfläche.

13. Zusammenfassung

Glückwunsch! Sie haben ein produktionsreifes, verteiltes System mit mehreren KI-Agenten erstellt und bereitgestellt.

Unsere Erfolge

  • Komplexe Aufgabe zerlegt: Anstelle eines riesigen Prompts haben wir die Arbeit in spezialisierte Rollen aufgeteilt (Researcher, Judge, Content Builder).
  • Implementierte Qualitätssicherung: Wir haben einen LoopAgent und einen strukturierten Judge verwendet, um sicherzustellen, dass nur hochwertige Informationen den letzten Schritt erreichen.
  • Für die Produktion entwickelt: Durch die Verwendung des Agent-to-Agent-Protokolls (A2A) und von Cloud Run haben wir ein System geschaffen, in dem jeder Agent ein unabhängiger, skalierbarer Mikrodienst ist. Das ist viel robuster, als alles in einem einzigen Python-Skript auszuführen.
  • Orchestrierung: Wir haben SequentialAgent und LoopAgent verwendet, um klare Muster für den Kontrollfluss zu definieren.

Nächste Schritte

Jetzt, da Sie die Grundlagen kennen, können Sie dieses System erweitern:

  • Weitere Tools hinzufügen: Gewähren Sie dem Researcher Zugriff auf interne Dokumente oder APIs.
  • Judge verbessern: Fügen Sie spezifischere Kriterien oder sogar einen „Human-in-the-Loop“-Schritt hinzu.
  • Modelle tauschen: Verwenden Sie verschiedene Modelle für verschiedene Agents, z.B. ein schnelleres Modell für den Judge und ein leistungsstärkeres Modell für den Content Writer.

Sie können jetzt komplexe, zuverlässige agentenbasierte Workflows in Google Cloud erstellen.