Comprendre les événements d'agent : le contrat d'exécution derrière des agents IA fiables

Conçu pour la vitesse : latence d'environ 10 ms, même en cas de charge
Une méthode incroyablement rapide pour créer, suivre et déployer vos modèles !
- Gère plus de 350 RPS sur un seul processeur virtuel, aucun réglage n'est nécessaire
- Prêt pour la production avec un support complet pour les entreprises
La réponse finale d'un agent vous indique ce que l'utilisateur a vu. Ses événements indiquent à votre application ce qui s'est passé, ce qui est en cours, ce qui nécessite une intervention humaine et comment récupérer en cas de coupure de connexion.
1. Pourquoi une API de réponse finale est insuffisante pour les agents
Un appel de modèle conventionnel a une forme rassurante : envoyer une entrée, recevoir une sortie. Même lorsque la réponse est diffusée en flux, l'application reconstruit généralement une seule réponse. L'exécution d'un agent est différente. Une exécution peut effectuer plusieurs appels de modèle, demander des outils, attendre une approbation, s'authentifier auprès d'un serveur MCP, créer un bac à sable, déléguer à des sous-agents et reprendre lors d'une requête ultérieure.
Si l'environnement d'exécution n'expose que la dernière réponse textuelle, l'application perd la structure nécessaire pour piloter ce flux de travail. Elle ne peut pas répondre de manière fiable à des questions fondamentales :
- L'agent est-il en train de réfléchir, d'invoquer un outil, d'attendre une intervention humaine ou a-t-il terminé ?
- Quel message du modèle a proposé cet appel d'outil ?
- Quels événements appartiennent à un sous-agent plutôt qu'à l'agent racine ?
- Quels fragments ont déjà été rendus ?
- Après une déconnexion, le client doit-il se reconnecter à l'exécution en cours ou se reconstruire à partir de l'état persisté ?
C'est pourquoi les événements sont essentiels. Ils constituent l'interface entre l'exécution invisible et tout ce qui doit y répondre : l'interface utilisateur, le service d'approbation, la console d'opérations, le débogueur et l'évaluateur.
2. Ce que signifie « événement » dans TrueForge
TrueForge organise l'exécution sous la forme Agent → Session → Tour → Événement → Delta. Chaque niveau répond à une question différente :
L'agent est une définition, pas un processus fonctionnant en continu. Une session conserve le contexte entre les tours. Un tour représente un cycle de requête, et un seul tour s'exécute à la fois au sein d'une session. Les événements sont les enregistrements typés produits au cours de ce tour. Certains événements — plus visiblement les messages du modèle — peuvent être assemblés progressivement via des deltas.

Cette hiérarchie permet d'éviter deux erreurs de conception courantes. Premièrement, l'historique d'une session ne doit pas être traité comme une transcription illimitée : les tours de parole offrent des limites d'exécution naturelles. Deuxièmement, un delta diffusé en continu ne doit pas être stocké ou évalué comme s'il s'agissait de l'événement sémantique final.
3. La taxonomie des événements constitue la machine à états d'exécution
L'union d'événements documentée de TrueForge couvre plusieurs catégories. L'essentiel n'est pas le nombre de types d'événements, mais le fait que chaque catégorie implique un comportement applicatif différent.
TrueFoundry AI Gateway offre une latence d'environ 3 à 4 ms, gère plus de 350 RPS sur 1 processeur virtuel, évolue horizontalement facilement et est prête pour la production, tandis que LiteLM souffre d'une latence élevée, peine à dépasser un RPS modéré, ne dispose pas d'une mise à l'échelle intégrée et convient parfaitement aux charges de travail légères ou aux prototypes.













.webp)



.png)
.png)
.png)
.png)
.png)






.png)







