Portabilität von KI-Agenten: Modellwechsel ohne Neuaufbau Ihrer Agenten

Auf Geschwindigkeit ausgelegt: ~ 10 ms Latenz, auch unter Last
Unglaublich schnelle Methode zum Erstellen, Verfolgen und Bereitstellen Ihrer Modelle!
- Verarbeitet mehr als 350 RPS auf nur 1 vCPU — kein Tuning erforderlich
- Produktionsbereit mit vollem Unternehmenssupport
Was ist KI-Agent-Portabilität?
KI-Agent-Portabilität ist die Eigenschaft, dass die Logik eines Agenten unverändert bleibt, während das zugrunde liegende Modell ausgetauscht werden kann. Der Agent referenziert ein Modell lediglich über dessen Namen und greift auf eine stabile Schnittstelle zu. Welcher Anbieter die Anfrage tatsächlich verarbeitet und welche Anmeldedaten verwendet werden, liegt vollständig außerhalb des Agenten.
Vergleichen Sie dies mit dem üblichen Ausgangspunkt: Ein Agent wird für das SDK eines spezifischen Anbieters geschrieben, der API-Schlüssel des Anbieters liegt in der Umgebung des Agenten und der Modellname ist im gesamten Code verstreut. Jeder dieser Punkte ist eine feste Bindung an einen Anbieter. Portabilität entsteht erst, wenn man alle drei Verbindungen kappt.
Der Nutzen ist praktisch: Sie können ein neueres Modell am Tag seiner Veröffentlichung übernehmen, auf einen zweiten Anbieter ausweichen, wenn der erste ausfällt, kostengünstige Anfragen an ein kleineres Modell weiterleiten und sowohl selbst gehostete als auch kommerzielle Modelle hinter derselben Schnittstelle betreiben. Nichts davon sollte eine Änderung am Agenten selbst erfordern.
Warum Portabilität bei Agenten schwieriger ist
Bei einem einfachen Chatbot ist der Modellwechsel fast schon mit einer einzigen Zeile erledigt. Bei Agenten ist dies aus mehreren Gründen komplizierter, die man kennen sollte, da sie bestimmen, was eine gute Portabilitätsschicht leisten muss.
- Agenten führen viele Aufrufe aus, nicht nur einen. Ein einzelner Agentendurchlauf verknüpft Planung, Tool-Aufrufe, Wiederholungsversuche und langen Kontext. Ein Modellwechsel muss über all diese Schritte hinweg funktionieren, nicht nur bei einer einzelnen Eingabeaufforderung.
- Das Verhalten variiert je nach Modell. Die Zuverlässigkeit bei Tool-Aufrufen, die Genauigkeit bei strukturierten Ausgaben und der Umgang mit langem Kontext unterscheiden sich je nach Modell. Daher sollten Sie pro Agent testen und wechseln sowie manchmal verschiedene Schritte an unterschiedliche Modelle weiterleiten.
- Anmeldedaten vervielfachen sich. Wenn Sie Schlüssel in jeden Agenten und jeden Arbeitsbereich integrieren, wird das Rotieren eines Anbieterschlüssels zu einer mühsamen Aufgabe für das gesamte System. Portabilität bedeutet, dass der Agent den Schlüssel gar nicht erst besitzt.
Eine Portabilitätsschicht, die lediglich einen Modell-String austauscht, aber Anmeldedaten, Routing und Fallback-Optionen innerhalb des Agenten belässt, macht den Agenten nicht wirklich portabel. Sie verlagert das Problem lediglich.
Wie TrueFoundry Agenten portabel macht
Der Ansatz von TrueFoundry besteht darin, den Modellzugriff zentral an einer Stelle zu verwalten, über das AI Gateway, und jedem Agenten zu erlauben, Modelle über ihren Namen zu referenzieren. Das Gateway verwaltet die Anmeldedaten der Anbieter, setzt Zugriffsrichtlinien durch und leitet den Datenverkehr. Die Agenten erben all diese Funktionen.
Eine einheitliche, OpenAI-kompatible API
Jedes Modell – egal ob von OpenAI, Anthropic, Azure OpenAI, Google Vertex, AWS Bedrock, Databricks, Together AI oder selbst gehostet – wird über eine einzige OpenAI-kompatible API angesprochen. Sie verweisen Ihren Code einmalig auf das Gateway und wechseln das Modell einfach durch Ändern des Modellnamens in der Anfrage. Gleiche URL, gleiche Anmeldedaten.
from openai import OpenAI
client = OpenAI(
api_key="your-truefoundry-api-key", # a gateway token, never a provider key
base_url="https://gateway.truefoundry.ai",
)
# Today:
resp = client.chat.completions.create(
model="openai-main/gpt-4o",
messages=[{"role": "user", "content": "Draft the release notes"}],
)
# Tomorrow, swap the model. Nothing else changes:
resp = client.chat.completions.create(
model="anthropic-main/claude-sonnet-4",
messages=[{"role": "user", "content": "Draft the release notes"}],
)Der Agent-Code musste nicht nennenswert angepasst werden. Die Anmeldedaten blieben unverändert. Die einzige Änderung betrifft den Modellnamen, und selbst dieser lässt sich abstrahieren – dazu gleich mehr.
Modellwechsel ohne erneute Verwaltung von Anmeldedaten für Agenten
Im Agent Harness von TrueFoundry ist das Modell eine Auswahlmöglichkeit im Builder und kein fester Wert im Code. Sie wählen einfach ein für Sie im Gateway freigeschaltetes Modell aus. Der Wechsel erfolgt mit einem Klick, ohne Codeänderungen und ohne neue Anmeldedaten.

Produktscreenshot, TrueFoundry-Dokumentation: Modell-Auswahl im Agent Harness.
Der Unterschied zu anderen Managed-Agent-Produkten liegt darin, wo die Anmeldedaten gespeichert werden. Bei vielen anderen Anbietern müssen Sie API-Schlüssel beim Erstellen eines Agenten hinterlegen oder diese pro Arbeitsbereich registrieren. Bei TrueFoundry wird der Modellzugriff zentral auf Gateway-Ebene verwaltet, und Agenten referenzieren lediglich die Modellnamen.
TrueFoundry AI Gateway bietet eine Latenz von ~3—4 ms, verarbeitet mehr als 350 RPS auf einer vCPU, skaliert problemlos horizontal und ist produktionsbereit, während LiteLM unter einer hohen Latenz leidet, mit moderaten RPS zu kämpfen hat, keine integrierte Skalierung hat und sich am besten für leichte Workloads oder Prototyp-Workloads eignet.














.webp)



.png)
.png)
.png)
.png)
.png)






.png)







