Die Verbindung eines LLM reicht aus, um eine Anwendung Text zu generieren. Es reicht jedoch nicht aus, um einen KI-Agenten eine reale Aufgabe zu erfüllen.
Bitten Sie ein Modell, ein Dokument, das bereits in seinem Kontext vorhanden ist, zusammenzufassen, und die Modellebene ist ausreichend. Bitten Sie es, die Preise der Wettbewerber von heute zu vergleichen, einen Unternehmensdatensatz zu bereichern, ein soziales Konto zu überprüfen oder die beste API für einen unbekannten Job auszuwählen, und die fehlende Hälfte wird offensichtlich: Der Agent benötigt einen zuverlässigen Weg, um auf externe Systeme zuzugreifen.
Ein Produktionsagent trifft daher zwei separate Entscheidungen:
- Welches Modell sollte diesen Schritt übernehmen?
- Welches Tool oder welche API sollte die Daten oder Aktionen bereitstellen?
AIHubMix adressiert die erste Entscheidung mit einheitlichem Modellzugriff und Modell-Routing zur Anfragezeit. Monid adressiert die zweite mit Laufzeit-Tool-Entdeckung, Schema-Inspektion und Pay-per-Call-Ausführung. Die Produkte befinden sich auf verschiedenen Ebenen derselben Architektur.
Offenlegung: Dieser Artikel wurde im Rahmen einer Inhaltszusammenarbeit mit Monid erstellt. AIHubMix ist die Modellplattform, die unten diskutiert wird; Monid ist die Tool-Plattform. Jede kann unabhängig verwendet werden.
Die zwei Routing-Probleme innerhalb eines KI-Agenten
Ein Agentenlauf ist selten ein homogener Modellaufruf. Ein Forschungsagent kann eine Anfrage klassifizieren, nach aktuellen Informationen suchen, strukturierte Fakten extrahieren, Ergebnisse vergleichen und eine endgültige Antwort schreiben. Diese Schritte erfordern unterschiedliche Fähigkeiten.
Das Gleiche gilt außerhalb des Modells. Eine Unternehmensforschung kann heute eine Such-API, morgen einen Unternehmensanreicherungs-Endpunkt und nächste Woche ein Browser-Automatisierungstool benötigen. Wenn jedes Modell und Tool zur Build-Zeit fest codiert ist, wird jede neue Aufgabe zu einem Integrationsprojekt.
Die beiden Ebenen sind parallel:
| Modellebene | Tool-Ebene | |
|---|---|---|
| Kernentscheidung | Welches Modell sollte antworten? | Welche API sollte aufgerufen werden? |
| Auswahlzeit | Pro Anfrage | Pro Aufgabe, zur Laufzeit |
| Eingabe | Prompt, Modalität, Qualitäts- und Latenzbedürfnisse | Ziel, benötigte Daten oder Aktion, Schema und Preis |
| Ausgabe | Eine Modellvervollständigung | Externe Daten oder ein ausgeführtes Ergebnis |
| Beispiel | AIHubMix | Monid |
Diese Trennung ist wichtig. Ein besseres Modell kann keinen Zugang zu Live-Daten schaffen, und ein größeres Tool-Katalog kann nicht über die Daten, die es zurückgibt, nachdenken. Der Agent benötigt beide Fähigkeiten, mit einem klaren Vertrag zwischen ihnen.
Monid präsentiert die komplementäre Tool-Seitenansicht in Warum ein KI-Agent zwei Integrationen benötigt. Von der Modellseite ist die architektonische Lektion die gleiche: Halten Sie die Modellauswahl und die Toolauswahl unabhängig, und optimieren Sie dann jede Ebene für ihren eigenen Job.
Warum ein festes Modell in einer Agentenschleife teuer wird
Überall ein Modell zu verwenden, sieht einfach aus. In der Praxis zwingt es jeden Schritt, denselben Kompromiss zwischen Fähigkeit, Latenz und Preis zu akzeptieren.
Betrachten Sie einen Marktanalyse-Agenten:
- Die Absichtsklassifizierung ist kurz und mechanisch.
- Die Toolauswahl benötigt zuverlässiges Befolgen von Anweisungen.
- Das Extrahieren von Feldern aus zurückgegebenem JSON ist größtenteils Transformation.
- Der endgültige Bericht kann stärkere Argumentation und besseres Schreiben erfordern.
Alle vier Schritte an das fähigste Modell zu senden, verschwendet Geld für Routinearbeiten. Alle vier an das günstigste Modell zu senden, kann die Qualität der einzigen Ausgabe, die der Benutzer liest, verringern. Wenn eine Agentenschleife wächst, wird dieser Kompromiss bei jedem Aufruf wiederholt.
AIHubMix bietet einen OpenAI-kompatiblen Endpunkt über ein breites Modellkatalog. Eine bestehende OpenAI SDK-Integration kann auf AIHubMix verweisen, indem der API-Schlüssel und base_url geändert werden:
from openai import OpenAI
client = OpenAI(
api_key="<AIHUBMIX_API_KEY>",
base_url="https://aihubmix.com/v1",
)
response = client.chat.completions.create(
model="auto:balanced",
messages=[
{"role": "user", "content": "Klassifizieren Sie diese Anfrage und schlagen Sie den nächsten Schritt vor."}
],
)
Das Setzen von model auf auto verschiebt die Modellauswahl in den Anfragepfad. Der Router analysiert die Aufgabe und löst sie einem geeigneten Modell zu. Ein Richtlinien-Suffix macht das Optimierungsziel explizit:
| Router-Wert | Priorität | Typischer Agentenschritt |
|---|---|---|
auto |
Kosten zuerst | Batch-Arbeiten und Routine-Transformationen |
auto:balanced |
Fähigkeit, Kosten und Latenz | Allzweck-Agentenarbeit |
auto:quality_first |
Fähigkeit zuerst | Komplexe Argumentation und endgültige Ergebnisse |
auto:latency_critical |
Geschwindigkeit zuerst | Interaktive Schleifen und leichte Planung |
Routing fügt keine separate Gebühr hinzu. Die Anfrage wird zum Listenpreis des Modells abgerechnet, das tatsächlich damit umgegangen ist. Das aufgelöste Modell und die Routing-Details werden in der Antwort offengelegt, einschließlich des X-Aihubmix-Router-Resolved-Model Headers, sodass die Entscheidung beobachtbar bleibt, anstatt zu einer Black Box zu werden.
Das vollständige Verhalten, unterstützte Endpunkte, Richtlinien und aktuelle Einschränkungen sind im AIHubMix LLM Router-Leitfaden dokumentiert.
Modell-Routing gibt einem Agenten keine Live-Daten
Nachdem das Modell-Routing konfiguriert ist, kann der Agent für jeden Schritt ein besseres Gehirn auswählen. Er kann jedoch nicht wissen, was sich nach den Trainingsdaten des Modells geändert hat, auf ein privates Geschäftssystem zugreifen oder eine Aktion in einer anderen Anwendung ausführen, es sei denn, ein Tool bietet diese Fähigkeit.
Hier sammeln viele Agentenprojekte brüchigen Code. Ein Team verbindet eine Such-API, dann eine Scraping-API, dann eine Anreicherungs-API. Jede Integration führt ein weiteres Konto, Anmeldeinformationen, Anfrageformat, Fehlermodell und Abrechnungsbeziehung ein. Tool-Beschreibungen werden oft in einen System-Prompt kopiert und werden langsam veraltet.
Der Ausfallmodus ist gefährlich, weil er erfolgreich aussehen kann. Ein Modell kann einen plausiblen Aufruf gegen ein veraltetes Schema erzeugen, eine unvollständige Antwort erhalten und fortfahren, als ob die Aufgabe erfolgreich gewesen wäre. Die Laufzeit-Schema-Inspektion ist sicherer, als das Modell zu fragen, sich an einen API-Vertrag aus dem Training oder von einem alten Prompt zu erinnern.
Die Tool-Ebene sollte daher drei Fragen vor der Ausführung beantworten:
- Welches Tool kann dieses Ziel erfüllen?
- Welches Schema und welcher Preis gelten gerade?
- Welches Ergebnis hat der Aufruf tatsächlich zurückgegeben?
Tool-Entdeckung ist die zweite Routing-Ebene
Monid verwandelt den Tool-Zugriff in einen Entdecken-Inspektions-Ausführungs-Workflow. Anstatt den Entwickler zu zwingen, jede API vorherzusagen, die ein Agent benötigen könnte, kann der Agent in natürlicher Sprache in einem Katalog suchen, den Vertrag eines Kandidaten inspizieren und den ausgewählten Endpunkt ausführen.
Der grundlegende Ablauf sieht so aus:
# 1. Finden Sie Tools, die das Ziel erfüllen
monid discover -q "aktuelle Produktpreise von einer öffentlichen Webseite finden"
# 2. Lesen Sie das Schema und die Preise des ausgewählten Endpunkts
monid inspect -p PROVIDER_SLUG -e ENDPOINT_PATH
# 3. Führen Sie nur aus, nachdem der Agent den Vertrag überprüft hat
monid run -p PROVIDER_SLUG -e ENDPOINT_PATH \
--query '{"url":"https://example.com/product"}'
Entdeckung und Inspektion ermöglichen es dem Agenten, Optionen zu vergleichen, bevor er etwas ausgibt. Die Ausführung wird gemäß dem Preismodell des ausgewählten Endpunkts abgerechnet. Der Entwickler behält eine Integration, während der Agent Zugriff auf Tools über mehrere Anbieter erhält.
Für Agentenlaufzeiten, die Einrichtungsanweisungen lesen können, veröffentlicht Monid auch eine maschinenlesbare Fähigkeit:
Set up https://monid.ai/SKILL.md
Die Monid-Workflow-Dokumentation erklärt die Katalog-, Inspektions- und Ausführungsphasen im Detail.
Wie die beiden Ebenen zusammenarbeiten
Das Modell-Gateway und die Tool-Ebene sollten separate Komponenten mit einem kleinen, expliziten Übergang bleiben:
- Der Agent erhält ein Benutzerziel.
- AIHubMix leitet einen Planungsaufruf an ein geeignetes Modell weiter.
- Der Plan identifiziert fehlende Informationen oder eine erforderliche externe Aktion.
- Monid entdeckt Kandidaten-Tools und legt deren Schemata und Preise offen.
- Der Agent wählt ein Tool aus und führt es innerhalb seiner Berechtigungen und seines Budgets aus.
- Das Tool gibt Fakten oder ein Aktionsresultat zurück.
- AIHubMix leitet den Syntheseaufruf gemäß der erforderlichen Qualität, Kosten oder Latenz weiter.
- Der Agent gibt eine Antwort zurück, die auf dem Tool-Ergebnis basiert.
In vereinfachtem Python können die Modellaufrufe unverändert bleiben, während das Tool-Ergebnis als Kontext eingefügt wird:
from openai import OpenAI
client = OpenAI(
api_key="<AIHUBMIX_API_KEY>",
base_url="https://aihubmix.com/v1",
)
# Ein schnelles Modell ist ausreichend für einen leichten Planungs-Schritt.
plan = client.chat.completions.create(
model="auto:latency_critical",
messages=[
{
"role": "user",
"content": "Planen Sie, wie die aktuellen Preise dieser Produkte verglichen werden können.",
}
],
)
# Ihr Agent verwendet Monid, um ein geeignetes Tool zu entdecken, zu inspizieren und auszuführen.
# Ersetzen Sie diese Platzhalter durch das strukturierte Ergebnis, das von diesem Aufruf zurückgegeben wurde.
tool_result = {
"source": "<source-url>",
"data": "<structured-tool-result>",
}
report = client.chat.completions.create(
model="auto:quality_first",
messages=[
{
"role": "system",
"content": (
"Schreiben Sie einen prägnanten Vergleich. Verwenden Sie nur das bereitgestellte Tool-Ergebnis, "
"bewahren Sie die Quell-URLs und geben Sie an, wann ein Wert fehlt."
),
},
{"role": "user", "content": str(tool_result)},
],
)
Das wichtige Detail ist nicht die Anzahl der Zeilen. Es ist, dass keine der Entscheidungen dauerhaft in der Anwendungslogik eingebettet sein muss. Das Modell kann sich ändern, wenn sich der Prompt ändert, und das Tool kann sich ändern, wenn sich die Aufgabe ändert.
Kostenkontrollen gehören zu beiden Ebenen
Modell- und Toolkosten verwenden unterschiedliche Einheiten, daher sollten sie separat gemessen werden.
Auf der Modellebene bestimmt das aufgelöste Modell die Token-Preise. AIHubMix macht diese Entscheidung nachvollziehbar und ermöglicht Entwicklern, eine Routing-Politik auszuwählen oder die Modelle einzuschränken, die ein API-Schlüssel verwenden darf. Routine-Schritte können Kosten oder Latenz bevorzugen, während benutzerorientierte Ausgaben Qualität bevorzugen können.
Auf der Tool-Ebene kann ein Endpunkt pro Aufruf oder pro Ergebnis Gebühren erheben. Monid legt die Preise während der Inspektion offen, bevor die Ausführung erfolgt. Ein Agent kann einen Endpunkt ablehnen, der sein Budget überschreitet, eine verifizierte Option bevorzugen oder um Genehmigung bitten, bevor eine ungewöhnlich teure Operation durchgeführt wird.
Nützliche Produktionskontrollen umfassen:
- Eine Modell-Whitelist oder Preisobergrenze für jeden API-Schlüssel.
- Ein maximales Tool-Call-Budget pro Aufgabe.
- Provider- oder Endpunkt-Whitelists für regulierte Daten.
- Protokolle, die die Entscheidung zum Modell-Routing mit dem Tool-Aufruf und der endgültigen Antwort verbinden.
- Explizite Bestätigung vor irreversiblen oder sensiblen Aktionen.
- Ausgabevalidierung, sodass Tool-Daten als unzuverlässige Eingaben behandelt werden, nicht als Anweisungen.
Diese Trennung erleichtert auch das Kosten-Debugging. Wenn ein Lauf teuer wird, zeigen Token-Protokolle, ob der Agent zu viel überlegt hat, während Tool-Protokolle zeigen, ob er zu viel abgerufen hat. Die Lösungen sind unterschiedlich, und die Architektur sollte diese Unterscheidung bewahren.
Zuverlässigkeit erfordert frische Verträge und sichtbare Entscheidungen
Die dynamische Auswahl sollte nicht unvorhersehbares Verhalten bedeuten.
Auf der Modellseite berichtet AIHubMix das aufgelöste Modell und die Routing-Politik für jede Anfrage. Sitzungsstabilität kann die Modellkonsistenz und die Vorteile des Prompt-Caches über mehrstufige Arbeiten hinweg bewahren, während das Fallback-Verhalten von einem ungesunden Modell abweichen kann, wenn dies erforderlich ist.
Auf der Tool-Seite inspiziert der Agent das aktuelle Endpunkt-Schema, bevor er einen kostenpflichtigen Aufruf tätigt. Die Entdeckungsergebnisse enthalten die Informationen, die benötigt werden, um Kandidaten zu vergleichen, und das Ergebnis des tatsächlichen Aufrufs wird zum einzigen externen Beweis, der in die endgültige Vervollständigung eingeht.
Zusammen schaffen diese Kontrollen eine nützliche Prüfspur:
Benutzerziel
-> Routing-Entscheidung und aufgelöstes Modell
-> Entdeckte Tool-Kandidaten
-> Inspiziertes Schema und Preis
-> Ausgewählter Endpunkt und Ergebnis
-> Endgültige Modellentscheidung und fundierte Antwort
Diese Spur ist wertvoller, als nur Zugang zu vielen Modellen oder vielen APIs zu haben. Sie erklärt, warum der Agent jede Wahl getroffen hat und welche Beweise seine Antwort unterstützt haben.
Wann Sie nicht beide Ebenen benötigen
Nicht jeder Workflow profitiert von der Laufzeitwahl.
Wenn eine Anwendung einen stabilen Prompt an ein benchmarktes Modell sendet, ist es einfacher und deterministischer, dieses Modell direkt anzugeben, als Routing zu verwenden. Wenn eine geplante Pipeline immer eine bekannte API aufruft, kann die direkte Integration dieser API klarer sein, als eine Entdeckungsebene hinzuzufügen.
Die Zwei-Ebenen-Architektur verdient ihren Platz, wenn Vielfalt Teil der Arbeitslast ist:
- Prompts unterscheiden sich so stark, dass das beste Modell je nach Schritt wechselt.
- Agenten tätigen mehrere Modellaufrufe und müssen die kumulierten Kosten oder die Latenz steuern.
- Erforderliche Tools können zur Build-Zeit nicht vollständig vorhergesagt werden.
- Externe Daten müssen aktuell sein und ihre Quelle muss sichtbar sein.
- Das Team möchte Fähigkeiten hinzufügen, ohne für jede neue eine neue Anbieterintegration hinzuzufügen.
Verwenden Sie die Modellebene, die Tool-Ebene oder beide, je nach den Entscheidungen, die Ihre Anwendung tatsächlich treffen muss.
Bauen Sie den Agenten um Entscheidungen, nicht um Abhängigkeiten
Ein Produktions-KI-Agent wird nicht dadurch definiert, wie viele Modelle oder APIs er erreichen kann. Er wird dadurch definiert, ob er die richtige Fähigkeit für den aktuellen Schritt auswählen, innerhalb eines Budgets arbeiten und erklären kann, was passiert ist.
AIHubMix gibt dem Agenten einen einheitlichen Modellendpunkt und Routing zur Anfragezeit über Kosten-, Qualitäts- und Latenzprioritäten. Monid gibt ihm Laufzeit-Tool-Entdeckung, aktuelle Schemata, sichtbare Preise und Ausführung über externe Anbieter.
Eine Ebene entscheidet, wie der Agent denkt. Die andere entscheidet, wie er herausfindet und handelt. Diese Entscheidungen getrennt zu halten, produziert einen Agenten, der leichter zu erweitern, zu beobachten und zu steuern ist.
Beginnen Sie mit dem AIHubMix-Quickstart, und verbinden Sie dann die Tool-Seite über Monid.
Häufig gestellte Fragen
Was ist Modell-Routing für KI-Agenten?
Modell-Routing wählt ein Modell für jede Anfrage basierend auf Faktoren wie Aufgabentyp, Fähigkeit, Kosten und Latenz aus. Mit AIHubMix ermöglicht das Setzen von model auf auto oder eine Richtlinie wie auto:quality_first die Auswahl zur Anfragezeit, während eine OpenAI-kompatible API erhalten bleibt.
Warum benötigt ein KI-Agent Tools, wenn das LLM bereits Wissen hat?
Ein LLM generiert Antworten aus dem Kontext, den es erhält, und dem, was es während des Trainings gelernt hat. Es kann aktuelle Preise, eine private Datenbank abfragen oder eine externe Aktion nicht zuverlässig ausführen, ohne ein verbundenes Tool. Tools bieten Live-Daten und Ausführung; das Modell plant und interpretiert das Ergebnis.
Ist ein Modell-Gateway dasselbe wie ein MCP-Server oder eine Tool-Plattform?
Nein. Ein Modell-Gateway leitet Inferenzanfragen an Modelle weiter. MCP-Server und Tool-Plattformen stellen externe Fähigkeiten für einen Agenten bereit. Sie lösen komplementäre Integrationsprobleme und können zusammen verwendet werden.
Können AIHubMix und Monid unabhängig verwendet werden?
Ja. AIHubMix kann Modellaufrufe für Anwendungen mit keinen dynamischen Tool-Anforderungen leiten. Monid kann Tool-Entdeckung für Agenten bieten, die einen anderen Modellanbieter oder Gateway verwenden. Die Verwendung beider ist nützlich, wenn ein Agent Laufzeitwahl auf beiden Ebenen benötigt.
Wie kann ich das automatische Routing nachvollziehbar halten?
Protokollieren Sie das aufgelöste Modell, die Routing-Politik, den Tool-Kandidaten, den inspizierten Preis, den ausgewählten Endpunkt und das zurückgegebene Ergebnis für jede Aufgabe. AIHubMix legt die Details des Modell-Routings in der Antwort offen, während Monid Entdeckung und Inspektion von der Ausführung trennt, sodass die Tool-Entscheidung vor dem kostenpflichtigen Aufruf aufgezeichnet werden kann.
