Outils, flux de travail et tables de données

Ce sont les « capacités d'action » de LoopAgent — une fois configurées, le modèle peut les appeler de manière autonome au cours d'une conversation pour accomplir la tâche visée.

Outils et MCP

• Après avoir lié des plugins / MCP à un LoopAgent, le modèle peut appeler les outils correspondants selon les besoins.
• Sécurité des identifiants : les informations sensibles comme les URL, clés API et en-têtes d'authentification sont entièrement conservées côté plateforme, l'exécution a également lieu côté plateforme, et le modèle ne touche jamais à vos secrets. Les paramètres dont le nom ressemble à key / token / secret sont masqués au modèle et injectés par la plateforme au moment de l'exécution.
• Lorsque les outils sont peu nombreux, le modèle les voit et les appelle directement ; lorsqu'ils sont très nombreux (plus de 30), il passe en mode « chargement différé » pour économiser des Tokens et maîtriser les coûts.

Points d'attention

• Une erreur d'outil n'interrompt pas le tour : lorsqu'un appel d'outil échoue, le message d'erreur s'affiche sur la carte de l'outil, et le modèle le reformule ou réessaie, et continue à servir.
• On ne voit pas le processus d'appel d'outil : cela est contrôlé par l'interrupteur « Processus d'appel visible » sous LoopAgent - Sortie (il doit être activé à la fois au niveau du plugin et au niveau de l'agent).

Diagnostic lorsqu'un outil ne peut pas être appelé

1. Si l'interrupteur général des outils de l'agent est activé ;
2. Si le plugin est lié à cet agent et activé ;
3. Si cette opération (action) est désactivée au niveau du plugin ou de l'agent ;
4. Si la liste blanche de vérification MCP exclut cet outil.

Flux de travail

Un flux de travail publié peut devenir un outil que le modèle peut déclencher comme n'importe quel outil ; les paramètres d'entrée du nœud START du flux de travail deviennent les paramètres d'entrée de cet outil.

Pour qu'un flux de travail devienne un outil appelable, trois conditions doivent être réunies simultanément (si l'une manque, l'outil n'apparaît pas, sans erreur) :

1. L'interrupteur général des flux de travail de l'agent est activé ;
2. Le flux de travail est associé à cet agent ;
3. Le flux de travail est publié (les flux de travail qui n'existent qu'en brouillon sont ignorés).

• Si vous modifiez le brouillon d'un flux de travail sans le publier, LoopAgent exécute toujours l'ancienne version publiée.
• La « description » du flux de travail doit énoncer clairement son usage, sinon le modèle ne le trouve pas et ne l'appelle pas.
• Les crédits d'exécution du flux de travail sont imputés au compte de l'organisation propriétaire du flux de travail.

Tables de données et graphiques

Après avoir lié des tables de données à un LoopAgent, le modèle acquiert automatiquement deux capacités : interroger les tables en langage naturel, et transformer les résultats de requête en graphiques. Le modèle n'écrit jamais de SQL.

• Requête de table en langage naturel : le modèle décrit en une phrase en langage naturel ce qu'il faut interroger, et la plateforme se charge de la convertir en requête et de renvoyer les résultats.
• Générer un graphique : rend les résultats de la dernière requête de ce tour sous forme de graphique en barres / courbes / secteurs, etc., et les affiche directement à l'utilisateur.
• Interroger d'abord, dessiner ensuite : avant de générer un graphique, une requête réussie doit avoir eu lieu au cours du même tour. Si un utilisateur ouvre un nouveau tour et dit simplement « dessine un graphique » sans avoir interrogé au préalable, il est invité à interroger une fois — c'est voulu, et non un défaut.

Source des tables : les tables de données d'un LoopAgent se sélectionnent dans son propre nœud de données. Sélectionnez les tables dans le nœud de données du LoopAgent ; modifier les paramètres de tables de données ailleurs sur l'agent n'a aucun effet sur LoopAgent.