Agentgateway für LLMs, MCP und A2A: Wenn ein einheitliches AI-Datenfluss-System hilft

Plattformteams, die über einen einzigen Modell-Endpunkt hinauswachsen, haben oft mit einer Vielzahl von Komponenten zu tun: LLM-Anbieter, Tool-Server und autonome Agenten – jeweils mit ihrem eigenen Eingangsmodell. LLM-spezifische Proxy-Tools wie Bifrost oder LiteLLM helfen bei der Erweiterung von Chat-Funktionen, lassen aber den Verkehr zwischen Agenten sowie die MCP-Tool-Oberflächen weiterhin als separate Probleme bestehen.

Agentgateway zielt auf diese Lücke ab: ein hochleistungsstarker Gateway für AI-native Verkehrsflüsse, nicht nur klassisches LLM-HTTP-Proxying. Die folgenden Abschnitte fassen zusammen, was Agentgateway von anderen Lösungen unterscheidet, wie die Einrichtung funktioniert, welche Steuerungsparameter wichtig sind und wann es sinnvoll ist, es zu verwenden oder wegzulassen.

Was Agentgateway von anderen Lösungen unterscheidet: Mehr als nur ein LLM-Proxy

Der entscheidende Vorteil liegt in dem nativen Verständnis für agentenorientierte Protokolle neben herkömmlichen LLM-HTTP-Routen. Es kann weiterhin OpenAI-kompatible Endpunkte bereitstellen, behandelt MCP-Toolserver jedoch eher wie Microservices – mit einer Entdeckungsfunktion, damit Agenten Tools finden können – und kann Identität sowie Tracking über alle A2A-Übertragungen hinweg sicherstellen, sodass Aufrufe zwischen Agentenframeworks nachvollziehbar bleiben.

In einem komplexen agentbasierten System senden Agenten Toolaufrufe, die auf einem MCP-Server landen können. Ohne eine gemeinsame Datenplattform entwickelt jedes Team eigene Authentifizierungsmechanismen, Rate Limits und Telemetriedaten für diese Aufrufe. Agentgateway zentralisiert diese Aspekte genauso wie ein API-Gateway für REST-Microservices und berücksichtigt dabei die Besonderheiten der LLM-Routing-Logik wie latenz-, kosten- und modellbasierte Auswahlentscheidungen.

Für A2A-Verkehr sind Identifizierung und Nachverfolgung auf jeder Stufe entscheidend: Plattformbetreiber müssen erkennen können, welcher Agent welchen Peer unter welchen Anmeldeinformationen und mit welchem Latenzbudget anruft. Die Behandlung dieser Aufgaben als erstklassige Gateway-Funktionen verringert den Drang, neben jedem Agentenprozess zusätzliche Hilfsprogramme einzusetzen.

Selbst Hand anlegen: Eine Einführungserfahrung

Eine typische Bewertung beginnt lokal. Die Installation ähnelt anderen CLI-basierten Gateway-Tools:

# This is a conceptual installation command, similar to what you might find for many CLI tools
curl -sL <some_install_script_url> | bash

Nach der Installation kann die Einrichtung eines einfachen LLM-Proxy in wenigen Minuten erfolgen: Man konfiguriert eine Route zu einem OpenAI-kompatiblen Backend und sendet einen Testaufruf. Ein vereinfachtes Route-Manifest könnte wie folgt aussehen:

# llm-route.yaml
apiVersion: gateway.agentgateway.io/v1alpha1
kind: LLMGateway
metadata:
  name: my-llm-proxy
spec:
  listener:
    port: 8080
  routes:
    - match:
        prefix: /v1/chat/completions
      destinations:
        - ref:
            name: openai-backend
            namespace: default
  backends:
    - name: openai-backend
      llm:
        provider: openai
        credentials:
          secretRef:
            name: openai-api-key
            namespace: default

Dieser Auszug zeigt einen Zuhörer, eine eingehende Route sowie einen Backend-Anbieter. Der Vorteil liegt darin, dass nur sehr wenig anpassungsfähige Zusatzkomponenten benötigt werden, um bereits einen ersten Funktionsweg einzurichten, bevor Policies hinzugefügt werden.

Die Macht der Steuerung: Routing, Sicherheit, Überwachung, Verwaltung, Kosten

Jenseits des Routings ist es gerade die Steuerungsoberfläche, die das Produkt für Unternehmen attraktiv macht.

Routing. Nicht nur HTTP/gRPC: LLM-Routen können günstigere oder schnellere Modelle bevorzugen, auf andere Anbieter umsteigen und den Verkehr der Agenten auf derselben Ebene wie gewöhnliche API-Aufrufe halten.

Sicherheit und Richtlinien. Neben JWT- und OIDC-Prüfungen können Betreiber zu LLM-Routen auch Bandbreitenbeschränkungen sowie umfangreichere Richtlinien hinzufügen. Beispiel:

# Example: Applying a rate limit policy to an LLM route
apiVersion: gateway.agentgateway.io/v1alpha1
kind: RateLimitPolicy
metadata:
  name: llm-rate-limit
spec:
  targetRef:
    group: gateway.agentgateway.io
    kind: LLMGateway
    name: my-llm-proxy
  rateLimits:
    - local:
        requestsPerUnit: 100
        unit: MINUTE
      key:
        header: "x-api-key" # Rate limit per API key

Überwachbarkeit. OpenTelemetry-Hooks sind für Teams, die bereits Spuren und Metriken standardisieren, von Vorteil. Gateway-Spans, die Modell-, Route- und Agentenidentität enthalten, verringern Blindstellen bei der Fehlersuche bei langsamen oder kostspieligen Aufrufen.

Verwaltung und Kosten. Zugriffsrichtlinien für Tools, Quoten sowie kostenbewusstes Routing ermöglichen es einem Plattformteam, einmal Budgets festzulegen, anstatt in jedem Agent-Repository Grenzen auszuhandeln. Diese Trennung der Aufgaben – Anwendungsteams liefern die Agents, Plattformteams den Datenfluss – ist der Vorteil aus betrieblicher Sicht.

Wann es einsetzen und wann man darauf verzichten sollte

Setzen Sie es ein, wenn die Organisation mehrere Agentensysteme mit verschiedenen LLM-Anbietern und MCP-Tools entwickelt und ein gemeinsames Authentifizierungs-, Tracking- sowie Kostenkontrollsystem benötigt. Wenn der A2A-Aufkommen zunimmt und jedes Team eigene Gateways entwickelt, lohnt sich die Konsolidierung.

Verzichten Sie vorerst darauf, wenn nur ein einfacher Proxy zu einem Anbieter mit minimalem Regelwerk erforderlich ist. Ein leichterer LLM-Proxy kann ausreichen, bis Agentenprotokolle und Multi-Tenant-Verwaltung zu echten Problemen werden.

Greenfield-Demos mit einem einzigen Chatbot rechtfertigen selten die Notwendigkeit eines weiteren Control-Planes. Produktionsagenten, die mit Compliance-Anforderungen zusammenarbeiten, tun das in der Regel schon.

Praktische Erkenntnisse

Agentgateway adressiert eine sich abzeichnende Infrastrukturlücke: einheitliches Routing und Policy-Management für LLMs, MCP und A2A anstelle einer Ansammlung von Proxys für Sonderfälle. Plattformteams erhalten so eine Möglichkeit, Policies zu definieren, Interaktionen zu überwachen und Kosten einzuschränken, ohne jeden Agent neu schreiben zu müssen. Anwendungsteams erhalten einen stabilen Rahmen dafür, wie auf Tools und Modelle zugegriffen wird.

Die Einführung sollte auf Belegen beruhen: Messen Sie, wie viele benutzerdefinierte Eingangswege es derzeit gibt, wie viele keinen gemeinsamen Tracing-Service nutzen und wie häufig unerwartete Kosten auftreten. Wenn diese Zahlen hoch sind, lohnt sich ein einheitliches AI-Data-Plane ausführlich. Sind sie niedrig, halten Sie die Architektur schlicht und prüfen Sie sie erneut, wenn es zu einer Überverbreitung von Agenten kommt.

Routing-Details, die einer Belastungstestung standhalten sollten

Latenz- und Kostenerfassendes Routing ist nur dann nützlich, wenn die Gesundheitsindikatoren zuverlässig sind. Während eines Ansturms muss überprüft werden, dass ungesunde Backend-Systeme schnell aus dem Pool entfernt werden und dass sticky Sessions – falls vorhanden – den Traffic nicht an ein versagendes Replikat binden. Modellbasiertes Routing sollte in den Protokollen angeben, welches Modell eine Anfrage bearbeitet hat; andernfalls argumentieren die Finanzabteilung und die SRE-Abteilung auf der Grundlage unterschiedlicher Dashboards.

Testen Sie außerdem den Failover mit absichtlich erzeugten Fehlern: Entziehen Sie eine Anbieter-Schlüssel, senken Sie die Rate-Limit-Werte und stellen Sie sicher, dass die Agenten einen kontrollierten Fehler melden anstatt bei Wiederholungsversuchen hängenzubleiben. Wiederholungsversuche auf Gateway-Ebene müssen mit den Wiederholungsversuchen des Clients koordiniert werden, um eine Verstärkung des Problems zu vermeiden.

Sicherheitsdetails für Unternehmensprüfungen

Die Validierung von JWT und OIDC ist die Grundvoraussetzung. Fragen Sie nach der Zuordnung der ACLs der Tools zu den MCP-Zielen, wie die Geheimnisse für die Anbieter-Schlüssel gespeichert werden und ob Änderungen an den Richtlinien einen vollständigen Neustart oder ein Hot Reload erfordern. Mehrfachnutzer-Cluster benötigen eine klare Trennung, damit der Agent eines Teams nicht die Tools eines anderen Teams aufrufen kann.

Rate-Limit-Richtlinien sollten zwischen interaktiven Chats und Batch-Embedding-Aufgaben unterscheiden. Eine einzige globale QPS-Obergrenze ist unpräzise; Budgets pro Route und pro Benutzer entsprechen der tatsächlichen Abrechnung der Plattform gegenüber internen Kunden.

Erwartungen an die Überwachbarkeit

OpenTelemetry im Standard ist notwendig, aber nicht ausreichend. Überprüfen Sie, ob die Metadaten von den Agent-Frameworks in die Gateway-Spans übertragen werden und ob die Attribute den Route-Name, die Modell-ID, bei Verfügbarkeit die Token-Zahlen sowie die Namen der MCP-Tools enthalten. Ohne diese Informationen erklären die Spuren zwar die Latenz, aber nicht die Kosten.

Auch Strategien zur Protokollierung von Logs sind wichtig: Die vollständige Protokollierung der Anfragen kann verboten sein; strukturierte Metadaten mit Löschrichtlinien bilden in der Regel den Kompromiss. Stellen Sie sicher, dass die Sicherheitsanforderungen erfüllt sind, bevor Sie in Umgebungen außerhalb der Produktionsumgebung ausführliche Protokolle aktivieren.

Kostensteuerung in der Praxis

Eine kostensensible Routenwahl kann günstigere Modelle für weniger kritische Verkehrsströme bevorzugen, doch Produktverantwortliche müssen angeben, welche Routen auf eine geringere Qualität reduziert werden dürfen. Verknüpfen Sie die Budgets der Gateways mit Alarmfunktionen, sobald eine Route ihrem monatlichen Limit nahekommt. Zugriffsrichtlinien für Tools, die teure MCP-Aktionen (große Crawls, Massenschreibvorgänge) einschränken, verhindern, dass ein einziger Agentenzyklus die monatlichen Kreditlimits über Nacht aufbraucht.

Umsetzungsplan

1. Deployen Sie das Gateway in einem Sandbox-Namespace mit einer einzigen LLM-Route.
2. Fügen Sie eine OTel-Exportfunktion zum bestehenden Sammler hinzu und überprüfen Sie einen „goldenen Pfad“.
3. Fügen Sie hinter der Authentifizierung sowie einer Geschwindigkeitsbeschränkung ein einzelnes MCP-Ziel hinzu.

Spiegeln Sie einen Teil des Verkehrs des Produktions-Agenten wider; vergleichen Sie die Fehlerraten sowie den p95-Wert.

Erweitern Sie A2A-Pfade erst, nachdem Identifizierung und Tracking auf den LLM- und MCP-Pfaden nachgewiesen wurden.

Diese Abfolge hält den Ausmaß der Veränderungen in Grenzen, während gleichzeitig die Funktionen genutzt werden, die Agentgateway von einem einfachen LLM-Proxy unterscheiden.

Organisatorische Passung

Plattformgruppen, die bereits API-Gateways betreiben, erkennen das Betriebsmodell: Tickets für neue Pfade, Policy-as-Code, gemeinsame Dashboards. Agent-Teams, die zuvor ihre eigenen LiteLLM-Sidecars verwendeten, könnten Widerstand leisten, bis nachgewiesen ist, dass das Gateway Aufwände reduziert – gemeinsame Schlüssel, gemeinsame Quoten, gemeinsames Tracking. Planen Sie ein Migrationsfenster, in dem beide Ansätze nebeneinander bestehen können, mit klaren Fristen.

Die Dokumentation für Entwickler von Agenten sollte zeigen, wie SDKs auf die Basis-URL des Gateways verweisen lassen, wie Identitäten übergeben werden und wie Gateway-Fehlercodes interpretiert werden. Ohne diese Unterstützung werden Teams weiterhin den regulären Datenfluss umgehen, „nur für dieses eine Experiment“.

Kernpunkte

• Einheitlicher Datenfluss: Verkehrsteuerung, Authentifizierung, Telemetrie, Richtlinien sowie Ausgabenlimits werden in einem Schritt abgewickelt, der HTTP/gRPC sowie Modell- und Agentenprotokolle versteht.
• MCP als Dienste: Tool-Server werden wie andere Microservices entdeckt und geschützt, anstatt als nachträgliche Ergänzungen neben dem LLM-Proxy zu dienen.
• Sichtbarkeit von A2A: Identitätsprüfung und Tracking auf den Agenten-Ebenen verwandeln Black-Box-Strukturen in bedienbare Systeme.
• Richtlinien am Rand: Bandbreitenbeschränkungen, Authentifizierung sowie Zugriffsrechte für Tools gehören zum Gateway, damit sich der Agentencode auf das Logikverarbeiten konzentrieren kann.

Die richtige Größe wählen: Komplexe Agentenplattformen profitieren davon; Prototypen mit einem einzigen Modell möglicherweise nicht.

Teams, die ernsthaft skalierbare, sichere und überwachbare AI-native Anwendungen anstreben – insbesondere solche, die autonome Agenten mit verschiedenen Modellanbietern kombinieren – sollten prüfen, ob ihre aktuelle Proxy-Schicht bereits Agentenprotokolle abdeckt oder nur Chat-Funktionen. Das Erstere ist eine Grundvoraussetzung für die nächste Welle an Produktionsagentensystemen; das Letztere stellt lediglich eine vorübergehende Erleichterung dar.

Operativ gesehen sollte man mit einem LLM-Pfad und einem MCP-Ziel in einem Nicht-Produktionsknotenstarten, nachweisen, dass die OpenTelemetry-Dashboards funktionieren, und anschließend die Richtlinien erweitern. Man sollte sich davor hüten, bereits am ersten Tag alle Funktionen zu aktivieren; ein eng gefasster, überwachbarer Ansatz ist besser als ein voll konfiguriertes Gateway, dem noch niemand vertraut.