Connecter un LLM suffit à faire générer du texte par une application. Ce n'est pas suffisant pour qu'un agent IA accomplisse une tâche dans le monde réel.
Demandez à un modèle de résumer un document déjà dans son contexte, et la couche modèle est suffisante. Demandez-lui de comparer les prix des concurrents d'aujourd'hui, d'enrichir un dossier d'entreprise, de vérifier un compte social ou de choisir la meilleure API pour un travail inconnu, et la moitié manquante devient évidente : l'agent a besoin d'un moyen fiable d'accéder à des systèmes externes.
Un agent de production prend donc deux décisions distinctes :
- Quel modèle doit gérer cette étape ?
- Quel outil ou API doit fournir les données ou l'action ?
AIHubMix répond à la première décision avec un accès unifié aux modèles et un routage des modèles au moment de la demande. Monid répond à la seconde avec la découverte des outils en temps d'exécution, l'inspection des schémas et l'exécution à la demande. Les produits se situent à différents niveaux de la même architecture.
Divulgation : Cet article a été créé dans le cadre d'une collaboration de contenu avec Monid. AIHubMix est la plateforme de modèle discutée ci-dessous ; Monid est la plateforme d'outils. Chacune peut être utilisée indépendamment.
Les deux problèmes de routage à l'intérieur d'un agent IA
Un fonctionnement d'agent est rarement un appel de modèle homogène. Un agent de recherche peut classifier une demande, rechercher des informations actuelles, extraire des faits structurés, comparer des résultats et rédiger une réponse finale. Ces étapes nécessitent différentes capacités.
Il en va de même en dehors du modèle. Une tâche de recherche d'entreprise peut nécessiter une API de recherche aujourd'hui, un point de terminaison d'enrichissement d'entreprise demain, et un outil d'automatisation de navigateur la semaine prochaine. Si chaque modèle et outil est codé en dur au moment de la construction, chaque nouvelle tâche devient un projet d'intégration.
Les deux couches sont parallèles :
| Couche modèle | Couche outil | |
|---|---|---|
| Décision principale | Quel modèle doit répondre ? | Quelle API doit être appelée ? |
| Temps de sélection | Par demande | Par tâche, en temps d'exécution |
| Entrée | Invite, modalité, besoins en qualité et latence | Objectif, données ou action requises, schéma et prix |
| Sortie | Une complétion de modèle | Données externes ou un résultat d'action exécuté |
| Exemple | AIHubMix | Monid |
Cette séparation est importante. Un meilleur modèle ne peut pas créer d'accès à des données en direct, et un catalogue d'outils plus large ne peut pas raisonner sur les données qu'il retourne. L'agent a besoin des deux capacités, avec un contrat clair entre elles.
Monid présente la vue complémentaire du côté des outils dans Pourquoi un agent IA a besoin de deux intégrations. Du côté modèle, la leçon architecturale est la même : garder la sélection de modèle et la sélection d'outil indépendantes, puis optimiser chaque couche pour son propre travail.
Pourquoi un modèle fixe devient coûteux dans une boucle d'agent
Utiliser un modèle partout semble simple. En pratique, cela force chaque étape à accepter le même compromis entre capacité, latence et prix.
Considérez un agent de recherche de marché :
- La classification d'intention est courte et mécanique.
- La sélection d'outil nécessite un suivi d'instructions fiable.
- Extraire des champs à partir d'un JSON retourné est principalement une transformation.
- Le rapport final peut nécessiter un raisonnement plus fort et une meilleure rédaction.
Envoyer les quatre étapes au modèle le plus capable gaspille de l'argent sur un travail routinier. Envoyer les quatre au modèle le moins cher peut réduire la qualité de la seule sortie que l'utilisateur lit. À mesure qu'une boucle d'agent se développe, ce compromis se répète à chaque appel.
AIHubMix fournit un point de terminaison compatible avec OpenAI à travers un large catalogue de modèles. Une intégration SDK OpenAI existante peut pointer vers AIHubMix en changeant la clé API et base_url :
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": "Classifiez cette demande et proposez la prochaine étape."}
],
)
Définir model sur auto déplace la sélection de modèle dans le chemin de la demande. Le routeur analyse la tâche et la résout à un modèle approprié. Un suffixe de politique rend l'objectif d'optimisation explicite :
| Valeur du routeur | Priorité | Étape typique de l'agent |
|---|---|---|
auto |
Coût d'abord | Travail par lot et transformations routinières |
auto:balanced |
Capacité, coût et latence | Travail d'agent à usage général |
auto:quality_first |
Capacité d'abord | Raisonnement complexe et livrables finaux |
auto:latency_critical |
Vitesse d'abord | Boucles interactives et planification légère |
Le routage n'ajoute pas de frais séparés. La demande est facturée au prix de liste du modèle qui l'a réellement traitée. Le modèle résolu et les détails de routage sont exposés dans la réponse, y compris l'en-tête X-Aihubmix-Router-Resolved-Model, de sorte que la décision reste observable plutôt que de devenir une boîte noire.
Le comportement complet, les points de terminaison pris en charge, les politiques et les limitations actuelles sont documentés dans le guide AIHubMix LLM Router.
Le routage des modèles ne donne pas à un agent des données en direct
Après que le routage des modèles est configuré, l'agent peut choisir un meilleur cerveau pour chaque étape. Il ne peut toujours pas savoir ce qui a changé après les données d'entraînement du modèle, accéder à un système commercial privé ou effectuer une action dans une autre application à moins qu'un outil ne fournisse cette capacité.
C'est là que de nombreux projets d'agents accumulent du code fragile. Une équipe connecte une API de recherche, puis une API de scraping, puis une API d'enrichissement. Chaque intégration introduit un autre compte, des identifiants, un format de demande, un modèle d'erreur et une relation de facturation. Les descriptions des outils sont souvent copiées dans une invite système et deviennent lentement obsolètes.
Le mode de défaillance est dangereux car il peut sembler réussi. Un modèle peut produire un appel plausible contre un schéma obsolète, recevoir une réponse incomplète et continuer comme si la tâche avait réussi. L'inspection du schéma en temps d'exécution est plus sûre que de demander au modèle de se souvenir d'un contrat API depuis l'entraînement ou depuis une ancienne invite.
La couche d'outils doit donc répondre à trois questions avant l'exécution :
- Quel outil peut satisfaire cet objectif ?
- Quel schéma et prix s'appliquent en ce moment ?
- Quel résultat l'appel a-t-il réellement retourné ?
La découverte d'outils est la deuxième couche de routage
Monid transforme l'accès aux outils en un flux de travail de découverte-inspection-exécution. Au lieu d'exiger que le développeur prévoie chaque API dont un agent pourrait avoir besoin, l'agent peut rechercher un catalogue en langage naturel, inspecter le contrat d'un candidat et exécuter le point de terminaison sélectionné.
Le flux de base ressemble à ceci :
# 1. Trouver des outils qui correspondent à l'objectif
monid discover -q "trouver les prix actuels des produits à partir d'une page web publique"
# 2. Lire le schéma et le prix du point de terminaison sélectionné
monid inspect -p PROVIDER_SLUG -e ENDPOINT_PATH
# 3. Exécuter uniquement après que l'agent a vérifié le contrat
monid run -p PROVIDER_SLUG -e ENDPOINT_PATH \
--query '{"url":"https://example.com/product"}'
La découverte et l'inspection permettent à l'agent de comparer les options avant de dépenser quoi que ce soit. L'exécution est facturée selon le modèle de prix du point de terminaison sélectionné. Le développeur conserve une intégration tandis que l'agent accède à des outils provenant de plusieurs fournisseurs.
Pour les temps d'exécution d'agents qui peuvent lire les instructions de configuration, Monid publie également une compétence lisible par machine :
Configurer https://monid.ai/SKILL.md
La documentation du flux de travail Monid explique les étapes de catalogue, d'inspection et d'exécution plus en détail.
Comment les deux couches fonctionnent ensemble
La passerelle modèle et la couche d'outils doivent rester des composants séparés avec un petit transfert explicite :
- L'agent reçoit un objectif utilisateur.
- AIHubMix route un appel de planification vers un modèle approprié.
- Le plan identifie les informations manquantes ou une action externe requise.
- Monid découvre des outils candidats et expose leurs schémas et prix.
- L'agent sélectionne et exécute un outil dans ses permissions et son budget.
- L'outil retourne des faits ou un résultat d'action.
- AIHubMix route l'appel de synthèse selon la qualité, le coût ou la latence requis.
- L'agent retourne une réponse fondée sur le résultat de l'outil.
En Python simplifié, les appels du côté modèle peuvent rester inchangés tandis que le résultat de l'outil est inséré comme contexte :
from openai import OpenAI
client = OpenAI(
api_key="<AIHUBMIX_API_KEY>",
base_url="https://aihubmix.com/v1",
)
# Un modèle rapide est suffisant pour une étape de planification légère.
plan = client.chat.completions.create(
model="auto:latency_critical",
messages=[
{
"role": "user",
"content": "Planifiez comment comparer les prix actuels de ces produits.",
}
],
)
# Votre agent utilise Monid pour découvrir, inspecter et exécuter un outil approprié.
# Remplacez ces espaces réservés par le résultat structuré retourné par cet appel.
tool_result = {
"source": "<source-url>",
"data": "<structured-tool-result>",
}
report = client.chat.completions.create(
model="auto:quality_first",
messages=[
{
"role": "system",
"content": (
"Rédigez une comparaison concise. Utilisez uniquement le résultat de l'outil fourni, "
"préservez les URL sources et indiquez quand une valeur est manquante."
),
},
{"role": "user", "content": str(tool_result)},
],
)
Le détail important n'est pas le nombre de lignes. C'est que ni le choix de modèle ni le choix d'outil n'ont besoin d'être intégrés de manière permanente dans la logique de l'application. Le modèle peut changer à mesure que l'invite change, et l'outil peut changer à mesure que la tâche change.
Les contrôles de coût appartiennent aux deux couches
Les coûts des modèles et des outils utilisent des unités différentes, donc ils doivent être mesurés séparément.
Au niveau du modèle, le modèle résolu détermine le prix des jetons. AIHubMix rend cette décision traçable et permet aux développeurs de choisir une politique de routage ou de restreindre les modèles qu'une clé API est autorisée à utiliser. Les étapes routinières peuvent privilégier le coût ou la latence, tandis que les sorties destinées à l'utilisateur peuvent privilégier la qualité.
Au niveau de l'outil, un point de terminaison peut facturer par appel ou par résultat. Monid expose les prix lors de l'inspection, avant l'exécution. Un agent peut rejeter un point de terminaison qui dépasse son budget, préférer une option vérifiée ou demander une approbation avant une opération exceptionnellement coûteuse.
Les contrôles de production utiles incluent :
- Une liste blanche de modèles ou un plafond de prix pour chaque clé API.
- Un budget maximum d'appels d'outils par tâche.
- Des listes blanches de fournisseurs ou de points de terminaison pour des données réglementées.
- Des journaux qui relient la décision de routage du modèle à l'appel d'outil et à la réponse finale.
- Une confirmation explicite avant des actions irréversibles ou sensibles.
- Une validation des sorties afin que les données de l'outil soient traitées comme une entrée non fiable, et non comme des instructions.
Cette séparation facilite également le débogage des coûts. Si un fonctionnement devient coûteux, les journaux de jetons montrent si l'agent a trop raisonné, tandis que les journaux d'outils montrent s'il a trop récupéré. Les corrections sont différentes, et l'architecture doit préserver cette distinction.
La fiabilité nécessite des contrats récents et des décisions visibles
La sélection dynamique ne doit pas signifier un comportement imprévisible.
Du côté modèle, AIHubMix rapporte le modèle résolu et la politique de routage pour chaque demande. La cohérence de session peut préserver la cohérence du modèle et les avantages de mise en cache des invites à travers un travail multi-tour, tandis que le comportement de secours peut s'éloigner d'un modèle malsain lorsque cela est nécessaire.
Du côté des outils, l'agent inspecte le schéma du point de terminaison actuel avant de faire un appel payant. Les résultats de découverte incluent les informations nécessaires pour comparer les candidats, et le résultat de l'appel réel devient la seule preuve externe passée dans la complétion finale.
Ensemble, ces contrôles créent une piste d'audit utile :
objectif utilisateur
-> décision de routage et modèle résolu
-> outils candidats découverts
-> schéma et prix inspectés
-> point de terminaison sélectionné et résultat
-> décision finale du modèle et réponse fondée
Cette piste est plus précieuse que de simplement avoir accès à de nombreux modèles ou à de nombreuses API. Elle explique pourquoi l'agent a fait chaque choix et quelles preuves ont soutenu sa réponse.
Quand vous n'avez pas besoin des deux couches
Tous les flux de travail ne bénéficient pas d'un choix en temps d'exécution.
Si une application envoie une invite stable à un modèle évalué, spécifier ce modèle directement est plus simple et plus déterministe que le routage. Si un pipeline programmé appelle toujours une API connue, intégrer cette API directement peut être plus clair que d'ajouter une couche de découverte.
L'architecture à deux couches mérite sa place lorsque la variété fait partie de la charge de travail :
- Les invites diffèrent suffisamment pour que le meilleur modèle change par étape.
- Les agents effectuent plusieurs appels de modèle et doivent contrôler le coût cumulatif ou la latence.
- Les outils requis ne peuvent pas être entièrement prédits au moment de la construction.
- Les données externes doivent être actuelles et leur source doit être visible.
- L'équipe souhaite ajouter des capacités sans ajouter une nouvelle intégration de fournisseur pour chacune d'elles.
Utilisez la couche modèle, la couche outil ou les deux selon les décisions que votre application doit réellement prendre.
Construisez l'agent autour des décisions, pas des dépendances
Un agent IA en production n'est pas défini par le nombre de modèles ou d'API auxquels il peut accéder. Il est défini par sa capacité à choisir la bonne capacité pour l'étape actuelle, à fonctionner dans un budget et à expliquer ce qui s'est passé.
AIHubMix donne à l'agent un point de terminaison de modèle unifié et un routage au moment de la demande à travers les priorités de coût, de qualité et de latence. Monid lui donne une découverte d'outils en temps d'exécution, des schémas actuels, des prix visibles et une exécution à travers des fournisseurs externes.
Une couche décide comment l'agent pense. L'autre décide comment il découvre et agit. Garder ces décisions séparées produit un agent plus facile à étendre, à observer et à contrôler.
Commencez par le démarrage rapide AIHubMix, puis connectez le côté outil via Monid.
FAQ
Qu'est-ce que le routage des modèles pour les agents IA ?
Le routage des modèles sélectionne un modèle pour chaque demande en fonction de facteurs tels que le type de tâche, la capacité, le coût et la latence. Avec AIHubMix, définir model sur auto ou une politique telle que auto:quality_first permet une sélection au moment de la demande tout en préservant une API compatible avec OpenAI.
Pourquoi un agent IA a-t-il besoin d'outils si le LLM a déjà des connaissances ?
Un LLM génère des réponses à partir du contexte qu'il reçoit et de ce qu'il a appris pendant l'entraînement. Il ne peut pas savoir de manière fiable les prix actuels, interroger une base de données privée ou effectuer une action externe sans un outil connecté. Les outils fournissent des données en direct et une exécution ; le modèle planifie et interprète le résultat.
Une passerelle de modèle est-elle la même chose qu'un serveur MCP ou une plateforme d'outils ?
Non. Une passerelle de modèle route les demandes d'inférence vers des modèles. Les serveurs MCP et les plateformes d'outils exposent des capacités externes à un agent. Ils résolvent des problèmes d'intégration complémentaires et peuvent être utilisés ensemble.
AIHubMix et Monid peuvent-ils être utilisés indépendamment ?
Oui. AIHubMix peut router des appels de modèle pour des applications sans exigences d'outils dynamiques. Monid peut fournir une découverte d'outils aux agents utilisant un autre fournisseur de modèles ou passerelle. Utiliser les deux est utile lorsqu'un agent a besoin d'un choix en temps d'exécution aux deux couches.
Comment puis-je garder le routage automatique auditable ?
Enregistrez le modèle résolu, la politique de routage, le candidat outil, le prix inspecté, le point de terminaison sélectionné et le résultat retourné pour chaque tâche. AIHubMix expose les détails du routage des modèles dans la réponse, tandis que Monid sépare la découverte et l'inspection de l'exécution afin que la décision d'outil puisse être enregistrée avant l'appel payant.
