Cadres d'agents IA : Connectez une API à plusieurs modèles

Les cadres d'agents IA sont là où les équipes définissent le comportement des agents : objectifs, outils, mémoire, transferts, boucles et les règles pour déterminer quand un agent doit s'arrêter. Mais la couche d'accès au modèle est une décision différente. Si chaque cadre d'agent est directement connecté à un seul fournisseur, le produit hérite des tarifs, des limites de taux, des pannes, des modifications de modèle et des règles de compte de ce fournisseur.

C'est pourquoi les cadres d'agents IA fonctionnent mieux lorsque le cadre appelle une API de modèle stable et que la couche de modèle gère le choix, le routage, le basculement, la visibilité de l'utilisation et la facturation. ShareAI correspond à cette couche. L'application de l'agent reste en dehors de ShareAI, tandis que ShareAI offre aux développeurs une API pour 150+ modèles, des signaux de marché, une utilisation payante par jeton et un chemin Builder lorsque le trafic de l'agent doit devenir monétisable.

Pourquoi les cadres d'agents IA ont besoin d'une couche d'accès au modèle

Un cadre d'agent devrait vous aider à définir le travail. Il ne devrait pas forcer chaque appel de modèle, étape d'outil et décision de repli dans un chemin de fournisseur codé en dur.

Un agent en production a généralement différents types d'appels de modèle. Un planificateur peut nécessiter un raisonnement plus fort. Un classificateur peut nécessiter un faible coût et une faible latence. Un résumeur peut nécessiter une route moins chère. Une réponse visible par le client peut nécessiter un modèle de meilleure qualité et un repli plus sûr. Traiter toutes ces étapes comme un modèle par défaut unique rend le coût et la fiabilité plus difficiles à contrôler.

ShareAI donne à l'application une couche de modèle stable. Les développeurs peuvent comparer les modèles, tester des options et router le trafic via une API unique au lieu de maintenir des intégrations de fournisseurs distinctes pour chaque cadre ou étape d'agent.

Le modèle de connexion de base

La plupart des intégrations suivent le même modèle :

• Gardez votre cadre d'agent responsable de la logique de flux de travail, des outils et de l'état.
• Pointez le client de modèle du cadre vers le point de terminaison des complétions de chat de ShareAI.
• Utilisez une clé API ShareAI depuis votre environnement côté serveur.
• Choisissez la route de modèle qui correspond à chaque étape de l'agent.
• Enregistrez l'utilisation par utilisateur, espace de travail, fonctionnalité ou route d'agent avant le lancement.

Ce modèle est particulièrement utile lorsque votre cadre prend déjà en charge un client de modèle de chat compatible avec OpenAI. LangChain documente comment son intégration ChatOpenAI peut utiliser une URL de base configurable, ce qui est le modèle que de nombreuses équipes utilisent lors du routage via un proxy, une passerelle ou une API de modèle compatible. Documentation LangChain ChatOpenAI.

Étape 1 : Prouver la demande ShareAI

Avant de modifier une configuration de framework, effectuez une requête directe côté serveur. Cela vous donne une base propre pour les identifiants, la sélection du modèle et la forme de la réponse.

curl -X POST "https://api.shareai.now/v1/chat/completions" \"

Gardez la clé sur le serveur. Ne l'exposez pas dans le code du navigateur, les dépôts publics, les plugins côté client ou les modèles d'agents partagés. Lorsque la requête réussit, déplacez le même point de terminaison et la clé dans la configuration du framework.

Étape 2 : Pointer le framework vers ShareAI

Pour les frameworks orientés code, le modèle est généralement une URL de base, une clé API et un nom de modèle. Dans LangChain, cela peut ressembler à ceci :

import os

Pour les outils qui utilisent des variables d'environnement, définissez les variables API du modèle du framework sur la clé ShareAI et l'URL de base dans l'environnement de déploiement, puis redémarrez le runtime du worker ou de l'agent.

SHAREAI_API_KEY="votre-clé-côté-serveur"

Pour les outils visuels, recherchez les paramètres du fournisseur de modèle ou les paramètres du fournisseur personnalisé. La documentation de Dify, par exemple, sépare les fournisseurs système des fournisseurs personnalisés dans sa configuration de fournisseur de modèle : Documentation du fournisseur de modèle Dify. Les étiquettes exactes diffèrent selon le produit, mais les entrées pratiques sont généralement les mêmes : clé, point de terminaison, modèle et champ d'application d'utilisation.

Étape 3 : Diviser les routes des agents par tâche

Une fois que le framework peut appeler ShareAI, évitez d'envoyer chaque étape au même modèle par habitude. Une meilleure configuration attribue des routes de modèle par type de tâche.

• Planification de l'itinéraire : utiliser un modèle plus puissant pour la décomposition, le choix des outils et les raisonnements longs.
• Itinéraire rapide : utiliser un modèle à moindre coût pour la classification, la réécriture, l'extraction ou le formatage.
• Itinéraire visible par le client : utiliser le modèle qui équilibre le mieux qualité, latence et fiabilité pour la réponse finale.
• Itinéraire de secours : choisir un modèle de sauvegarde capable d'accomplir la même tâche lorsque l'itinéraire préféré se dégrade.

C'est ici qu'une approche à API unique devient utile. Le cadre n'a pas besoin d'une intégration distincte pour chaque décision de fournisseur. L'application peut conserver un modèle d'appel stable tandis que l'équipe modifie les itinéraires en fonction des changements de prix, de latence, de disponibilité ou de qualité.

Si vous utilisez déjà plusieurs agents, considérez cela comme faisant partie de votre modèle opérationnel, et non seulement comme un paramètre de code. Le guide plus large Opérations de flotte d'agents IA explique comment le routage, la tarification et la propriété s'intègrent une fois qu'un agent devient plusieurs.

Où s'inscrit la monétisation des Builders

Certains flux de travail des agents sont des centres de coûts internes. D'autres sont des fonctionnalités de produit destinées aux clients. Si un Builder possède une application, un plugin, un flux de travail, un chatbot ou un produit agent en dehors de ShareAI, ce trafic d'agent peut devenir une partie d'un modèle commercial basé sur l'utilisation.

Le Builder continue de développer et de posséder l'application en dehors de ShareAI. ShareAI gère l'utilisation de l'inférence IA routée, le paiement client pour cette utilisation routée, la configuration de la marge ou de la surcharge, et le paiement mensuel du Builder basé sur les revenus générés.

Cela est important pour les cadres d'agents car les agents peuvent créer une utilisation inégale. Un client peut exécuter quelques résumés de support par mois. Un autre peut exécuter des milliers d'appels de recherche, de triage et de flux de travail. Avec la monétisation ShareAI Builder, le Builder peut router le trafic IA via ShareAI, définir une marge et laisser les clients à forte utilisation payer pour l'inférence qu'ils génèrent.

Lorsque vous êtes prêt à cartographier l'aspect commercial, ouvrez le Console du constructeur. Pour la planification de l'implémentation, gardez le documentation ShareAI à proximité.

Liste de contrôle de production pour les cadres d'agents IA

• Conservez les clés API ShareAI côté serveur.
• Nommez chaque itinéraire d'agent avant le lancement.
• Suivez l'utilisation par client, espace de travail, fonctionnalité ou agent.
• Séparez les itinéraires à raisonnement élevé des itinéraires utilitaires à faible coût.
• Testez le cadre avec au moins un chemin de modèle de secours.
• Enregistrez le modèle, la latence, l'utilisation des jetons, la raison de l'erreur et l'itinéraire final.
• Évitez de placer les clés du fournisseur dans les invites ou les modèles d'agent exportés.
• Décidez quelles étapes de l'agent sont facturables au client avant que le trafic n'augmente.

Le déploiement utile le plus petit est un agent, un itinéraire, une sauvegarde et une étiquette d'utilisation. Une fois ce chemin mesurable, étendez le modèle à l'étape suivante de l'agent.

FAQ

Qu'est-ce que les cadres d'agents IA ?

Les cadres d'agents IA aident les développeurs à définir le comportement des agents, les outils, la mémoire, les flux de travail, l'état et les boucles d'exécution. Ils sont différents de la couche d'accès au modèle qui décide quel modèle répond à chaque requête.

Pourquoi connecter les cadres d'agents IA à une API unique ?

Une API unique facilite le changement d'accès au modèle. Les équipes peuvent diriger différentes étapes d'agent vers différents modèles, comparer les signaux du marché et réduire la dépendance à une intégration unique avec un fournisseur.

ShareAI est-il un cadre d'agent IA ?

Non. ShareAI est un marché et une API d'IA. Il ne construit pas l'application d'agent. Il peut être placé derrière un cadre d'agent en tant que couche d'accès au modèle, de routage, d'utilisation, de facturation et de monétisation.

Puis-je utiliser ShareAI avec LangChain ?

Oui, lorsque l'intégration LangChain est configurée pour appeler le point de terminaison des complétions de chat de ShareAI avec une clé API ShareAI et un nom de modèle pris en charge. Testez la requête API directe avant de l'intégrer dans la chaîne complète.

Les constructeurs d'agents visuels peuvent-ils utiliser ce modèle ?

Souvent, oui. Si l'outil visuel prend en charge un fournisseur de modèle personnalisé ou un point de terminaison compatible avec OpenAI, la configuration se résume généralement au point de terminaison, à la clé API, au nom du modèle et à l'endroit où l'outil stocke les informations d'identification du fournisseur.

Comment devrais-je choisir les modèles pour les différentes étapes de l'agent ?

Commencez par la tâche. Utilisez des modèles plus puissants pour la planification et les réponses de grande valeur, des modèles moins coûteux pour des tâches simples de classification ou de mise en forme, et des itinéraires de secours pour les étapes qui ne peuvent pas échouer silencieusement.

Comment le basculement aide-t-il les agents IA ?

Le basculement offre à un agent un autre chemin de modèle lorsque l'itinéraire préféré est indisponible, lent, trop coûteux ou inadapté à une requête. Il est particulièrement utile lorsqu'il est testé avant que le trafic en production n'augmente.

Les constructeurs peuvent-ils monétiser l'utilisation du cadre d'agents ?

Oui, lorsque le constructeur possède l'application, le flux de travail, le plugin, le chatbot ou le produit agent en dehors de ShareAI et dirige son trafic d'inférence IA via ShareAI. Le constructeur peut définir une marge ou une surtaxe pour ce trafic.

Qui paie pour l'utilisation des agents routés ?

Dans le modèle du constructeur, le client, l'espace de travail, l'utilisateur ou le compte qui génère l'utilisation IA routée paie ShareAI pour cette utilisation. ShareAI paie le constructeur mensuellement en fonction des revenus générés par la marge ou la surtaxe configurée.

Les fournisseurs et les constructeurs gagnent-ils de la même manière ?

Non. Les constructeurs gagnent grâce au trafic d'application qu'ils dirigent via ShareAI. Les fournisseurs gagnent via des programmes de fournisseurs approuvés en contribuant une capacité de calcul éligible au réseau ShareAI.

Que devrais-je suivre avant le lancement ?

Suivez le nom de l'agent, l'utilisateur ou l'espace de travail, l'itinéraire du modèle, la latence, l'utilisation des jetons, le taux d'erreur, les événements de secours, et la fonctionnalité ou l'action du client qui a déclenché l'appel. Ces données facilitent grandement les décisions de tarification et de routage par la suite.