Enregistrer et publier
C'est la première règle à comprendre lors de l'utilisation de LoopAgent, et la plus facilement confondue : « Enregistrer » ne met à jour que la version Debug ; c'est « Publier » qui met à jour la version Online.
La règle fondamentale
- Cliquer sur Enregistrer sur la page de paramètres (changer le modèle, éditer la persona, lier une base de connaissances, ajouter un outil…) → écrit uniquement dans la version de débogage → le chat de débogage à droite prend effet immédiatement, ce qui permet de vérifier tout de suite.
- Mais tous les canaux externes (Open API, page de partage, Widget, plugin de site web, Telegram, Slack, LiveChat, LiveDesk…) s'exécutent sur l'instantané de configuration figé lors de la dernière « Publication ».
Sans cliquer sur « Publier », la production conserve toujours l'ancienne configuration.
flowchart LR
S[Cliquer sur Enregistrer] --> DBG[Version Debug]
DBG --> DC[Le chat de débogage prend effet immédiatement]
P[Cliquer sur Publier] --> PROD[Version Online]
PROD --> CH[Les canaux externes prennent effet]
Question fréquente : « J'ai changé la configuration / la persona, pourquoi la production n'a-t-elle pas changé ? » — parce que vous avez seulement enregistré sans publier. Pour qu'une modification prenne effet en production, vous devez cliquer de nouveau sur Publier / Release. Un chat de débogage qui fonctionne ≠ une production qui fonctionne.
Si un LoopAgent n'a jamais été publié, les canaux externes renverront simplement une erreur et ne pourront pas du tout s'exécuter. Publiez toujours une fois avant de connecter pour la première fois une API ou un canal.
Ce qui suit la publication et ce qui prend effet immédiatement
Tout ne nécessite pas une « Publication » pour prendre effet. Bien les distinguer évite des détours :
| Objet | Quand cela prend effet |
|---|---|
| Persona, limites de boucle, modèle, ainsi que les interrupteurs et liaisons de chaque capacité | À la publication (fait partie de la configuration de l'agent, entre dans l'instantané de publication) |
| Compétences privées de l'Agent | À la publication (même logique que la persona) |
| Compétences d'organisation / de plateforme | Immédiatement et globalement (l'enregistrement prend effet pour tous les agents qui la référencent) |
| Documents de base de connaissances, données d'événements clés, valeurs d'attributs utilisateur | Immédiatement et globalement (données d'exécution, et non configuration) |
En une phrase : les changements de configuration exigent une publication ; les changements de données / de ressources au niveau organisation prennent effet immédiatement.
Chat de débogage
Le chat de débogage à droite de la page de paramètres sert à vérifier l'effet de la configuration :
- Il lit la configuration de la version de débogage, qui prend effet juste après l'enregistrement, ce qui permet d'ajuster à répétition et de voir l'effet instantanément.
- Le chat de débogage est une vraie conversation, et il est facturé de la même façon.
- En mode débogage / prévisualisation, il ne transporte pas la mémoire d'historique inter-tours (chaque fois un contexte vierge), ce qui est normal.
Les messages envoyés à la suite fusionnent en une seule réponse
Si vous envoyez d'autres messages pendant que l'agent est encore en train de générer, ces messages ne sont pas perdus. Le système saisit d'abord un verrou de session : le message qui l'emporte est traité immédiatement ; ceux qui échouent sont mis en file d'attente ou marqués pour absorption, et sont finalement fusionnés en une seule réponse. Ainsi, « j'en ai envoyé plusieurs à la suite mais je n'ai reçu qu'une réponse » est un comportement voulu, et non un message perdu.
Les messages envoyés à la suite sont traités selon deux modes : QUEUE (file d'attente) et APPEND (ajout).
QUEUE (file d'attente, par défaut)
Les messages en file d'attente fusionnent à la frontière de message — ils ne sont pas traités comme un nouveau tour tant que la réponse en cours n'est pas entièrement terminée.
- Le message ① saisit le verrou de session et est traité immédiatement, produisant la réponse ① de son côté.
- Les messages ② et ③ arrivent alors que ① est encore en cours de traitement, échouent à saisir le verrou et entrent dans la file d'attente.
- Ce n'est qu'après que ① a terminé et libéré le verrou que le système exécute automatiquement un nouveau tour, fusionnant ② et ③ d'un coup en une seule réponse.
Le message ② n'obtiendra pas de réponse à lui seul — c'est le point le plus facilement pris à tort pour un « message perdu ».
APPEND (ajout)
Les messages ajoutés n'ont pas à attendre la fin du tour ; ils sont absorbés dans le tour en cours lors de la prochaine requête au modèle.
- Le message ② arrive alors que ① est encore en cours d'exécution et — au lieu d'être mis en file d'attente ou d'attendre la fin de ① — est simplement marqué « en attente d'absorption ».
- Lorsque le moteur atteint sa boucle suivante et lance une requête au modèle, il emporte le contenu de ② avec lui.
La fusion se produit à la frontière de boucle, plus tôt qu'en mode QUEUE : aucun nouveau message n'est créé et aucune réponse supplémentaire n'apparaît ; le client voit toujours la même réponse ①, influencée par le contenu « ajouté ». Ce mode convient aux ajouts et corrections en temps réel en cours d'exécution.
Rafales multimodales : si les messages envoyés à la suite entre les tours transportent du contenu multimodal tel que des images, des fichiers ou de l'audio, ce contenu est également soumis au modèle lors de la fusion — à condition que le modèle sélectionné prenne en charge l'entrée multimodale correspondante et que cette catégorie soit activée dans les paramètres d'entrée.
Le corps d'un même message en file d'attente / ajouté est plafonné à 8192 caractères.