Einführung
Die Entwicklung mit KI-Agenten wirkt auf den ersten Blick täuschend einfach. Man gibt einem Agenten ein Tool, dieser ruft das Tool auf, und es liefert eine Antwort. Doch sobald man mehr als einen Agenten, mehr als einen Modellanbieter oder mehr als nur ein paar Tools hat, betreibt man ein kleines verteiltes System – und das erzeugt Netzwerkverkehr, den niemand steuert.
Genau dieses Problem löst ein Agent-Gateway. Wenn Sie bereits Erfahrung mit einem API-Gateway haben, wird Ihnen das Prinzip bekannt vorkommen: ein einziger Proxy, der vor Ihren Diensten sitzt und Routing, Authentifizierung und Observability an einer zentralen Stelle abwickelt. Ein Agent-Gateway erfüllt dieselbe Aufgabe, allerdings für die Datenverkehrsmuster, die von agentbasierten Systemen erzeugt werden.
Was ist ein Agent-Gateway?
Ein Agent-Gateway ist eine einheitliche Datenebene für den Agent-Datenverkehr. Es handelt sich um einen Proxy, der zwischen Ihren Agenten und allen Kommunikationspartnern angesiedelt ist und für verschiedene Arten von Datenverkehr gleichzeitig ein einheitliches Routing, einheitliche Sicherheitsmaßnahmen und einheitliche Überwachungsfunktionen gewährleistet:
- MCP – das Model Context Protocol, das ein Agent nutzt, um Tools zu ermitteln und aufzurufen.
- Agent-to-Agent (A2A) – Nachrichten zwischen Agenten, häufig über verschiedene Frameworks hinweg.
- LLM-Inferenz – Aufrufe an Anbieter von gehosteten Modellen oder an Ihre eigenen, selbst gehosteten Modelle.
- Serviceverkehr – das gewöhnliche HTTP, gRPC und die REST-APIs, auf die die Agenten nach wie vor angewiesen sind.
Das Gateway bündelt diese Aufgaben, sodass kein Agent die Authentifizierung, Wiederholungsversuche, Protokollierung und Richtlinien für jedes Protokoll separat implementieren muss. agentgateway, ein Open-Source-Projekt (Apache-2.0), das nun von der Agentic AI Foundation der Linux Foundation gehostet wird, beschreibt dies als „ein leistungsstarkes Gateway für Service-, LLM- und MCP-Datenverkehr“.
Worin unterscheidet sich ein Agent-Gateway von einem API-Gateway?
| API-Gateway | Agent-Gateway | |
|---|---|---|
| Hauptverkehr | Nord-Süd-HTTP/REST | MCP, A2A, LLM-Inferenz und HTTP/gRPC |
| Arbeitseinheit | Eine Anfrage | Eine Agentenaktion (Tool-Aufruf, Inferenz, Übergabe) |
| Routing | Pfad/Host → Backend | Tool-Erkennung, Modell-/Anbieter-Routing, Inferenz-Routing |
| Politische Bedenken | Wer darf diesen Endpunkt aufrufen? | Welcher Agent darf welches Tool mit welchen Argumenten verwenden? |
| Beobachtbarkeit | Anfrageprotokolle, Latenz | Überprüfung von Tool-Aufrufen, Token-Nutzung, agentenübergreifende Ablaufverfolgungen |
Die alten Bedenken bestehen weiterhin. Hinzu kommt, dass die Arbeitseinheit zu einem Akteur wird, der eine Aktion ausführt, was die Anforderungen erhöht und neue Anforderungen an das Routing und die Richtlinien mit sich bringt.
Schlüsselbegriffe
Die einheitliche Datenebene
Ein Proxy verarbeitet mehrere Protokolle (MCP, A2A, LLM, HTTP/gRPC), sodass die Richtlinien und die Überwachbarkeit über alle Protokolle hinweg einheitlich bleiben und die „KI-Komponenten“ über denselben Stack laufen wie alle anderen Komponenten auch.
MCP-Gateway
Ein kontrollierter Zugang zu Ihren Tools: Erkennung, RBAC und Protokollierung aller Model Context Protocol-Aufrufe.
LLM-Gateway
Ein Endpunkt für mehrere Modellanbieter, mit Token-Budgetierung, Caching und Failover, sodass der Wechsel des Anbieters lediglich eine Konfigurationsänderung erfordert, ohne dass Agent-Code neu geschrieben werden muss.
Inferenz-Routing
Latenz- und kostenoptimierte Verteilung der Inferenz auf selbst gehostete Modellserver (z. B. vLLM, TGI, Triton) auf Ihren eigenen GPUs.
Richtlinien und Überwachbarkeit
Sicherheitsmaßnahmen (mTLS, Authentifizierung/Autorisierung, Policy-as-Code) und Telemetrie (OpenTelemetry) werden einheitlich auf den Agent- und den herkömmlichen Datenverkehr angewendet.
Wann sollte man ein Agent-Gateway verwenden?
- Sie haben mehr als einen Modellanbieter und möchten Routing, Budgetierung und Failover nutzen, ohne die Agenten neu schreiben zu müssen.
- Sie stellen Agenten über MCP Tools zur Verfügung und benötigen eine Zugriffskontrolle sowie einen Prüfpfad.
- Sie betreiben Agenten in verschiedenen Frameworks und benötigen eine A2A-Kommunikation zwischen diesen mit einheitlichen Sicherheitsstandards.
- Sie betreiben die Inferenz auf einem eigenen Server und möchten die GPU-Kapazität gezielt nutzen.
- Sie müssen das Verhalten des Agenten steuern oder Fehler beheben – an einem Ort, an dem Sie die Frage „Was hat der Agent getan?“ beantworten können.
Wenn Ihr Agentensystem aus einem einzigen Agenten besteht, der ein einziges Tool aufruft, benötigen Sie noch kein Gateway. Der Wert wird erst dann angezeigt, sobald das System mehr als ein Element einer Art enthält.
Wo Kubernetes zum Einsatz kommt
Agent-Gateways sind in der Regel für den Betrieb auf Kubernetes ausgelegt. „agentgateway“ wird beispielsweise über Helm die Gateway-API bereitgestellt und ist Envoy. Die „agentic“-Datenebene verhält sich wie der Rest Ihrer Plattform. Sie stellen sie deklarativ bereit, skalieren sie horizontal, steuern sie mit „Policy-as-Code“ und verbinden sie mit der Netzwerkumgebung, die Sie bereits betreiben. Durch den Betrieb auf Kubernetes verbleibt der sensibelste Datenverkehr Ihrer Agenten auf einer Infrastruktur, die Sie bereits betreiben und kontrollieren – unter einem einheitlichen Sicherheits- und Betriebsmodell.
Nächste Schritte
Dies ist das erste Tutorial der Reihe „Agent Gateway auf Kubernetes “. Als Nächstes werden wir ein Agent Gateway in einem Cluster bereitstellen und unseren ersten Aufruf des MCP-Tools darüber leiten.
Als Nächstes in dieser Reihe: Installation eines Agent-Gateways auf Kubernetes → Ihr erstes MCP-Gateway → Weiterleitung von LLM-Datenverkehr über verschiedene Anbieter hinweg → Kommunikation zwischen Agenten → Absicherung des Agent-Datenverkehrs durch Richtlinien und Observability.
Zusammenfassung
- Ein Agent-Gateway ist eine einheitliche Datenebene für den Agent-Datenverkehr: MCP, Agent-zu-Agent-Kommunikation, LLM-Inferenz und gewöhnliche Dienstaufrufe.
- Es bündelt Routing, Sicherheit und Überwachbarkeit, sodass nicht jeder Agent diese Funktionen neu entwickeln muss – und es ist der natürliche Kontrollpunkt dafür, welcher Agent welche Aufgaben ausführen darf.
- Zu den wichtigsten Funktionen zählen die MCP-Tool-Governance, das LLM-Routing über mehrere Anbieter hinweg, das GPU-optimierte Inferenz-Routing, die A2A-Brückenfunktion sowie einheitliche Richtlinien und Observability.
- Es wurde speziell für Kubernetes entwickelt, wobei die agentenbasierte Steuerungsebene auf der von Ihnen betriebenen Infrastruktur verbleibt.