par AgentPulse (LX AI)

Détection des boucles et des dérives d'agents en production

Une boucle d'agent est une exécution qui répète la même étape, ou une variation proche de celle-ci, sans faire de progrès. La dérive est un comportement qui change au fil du temps sans modification de code ou de prompt qui l'explique. Les deux sont peu coûteuses à détecter si vous enregistrez les décisions, et invisibles si vous n'enregistrez que la latence.

Pourquoi les alertes basées uniquement sur la latence échouent pour les agents

La surveillance classique des services s'est développée autour d'une demande qui commence, se termine et renvoie un code de statut. L'exécution d'un agent autonome ne respecte pas ce contrat.

Les conventions GenAI d'OpenTelemetry traitent de plus en plus le travail de l'agent comme une télémétrie de première classe : des spans de type invoke_agent, des enfants d'exécution d'outils et une capture de contenu facultative lorsque la politique de confidentialité le permet. Ces conventions aident, mais elles ne vous disent pas quels signaux méritent une page. Vous avez toujours besoin de règles de produit pour les boucles et la dérive qui correspondent à la façon dont vos agents se comportent réellement, comme décrit dans.

AgentPulse se situe dans cette couche de produit. Collez un exemple d'exécution ou un journal de comportement, choisissez un focus de surveillance et obtenez un rapport qui met en évidence les boucles probables, les candidats à la dérive et les anomalies. Il ne s'agit pas d'un backend OTLP complet et il ne s'agit pas d'une audit de sécurité formelle. La qualité de la détection dépend des événements que vous fournissez.

Un modèle de surveillance en quatre étapes

- Ingestion d'événements. Capture des décisions, des appels d'outils, des résultats, des réessais et des raisons d'abandon par exécution. Préférez les champs structurés aux journaux en texte libre uniquement afin de pouvoir compter les répétitions sans exploits de NLP. - Définition de la norme pour cet agent. Longueur de plan typique, mélange d'outils, nombre de réessais et bande de durée — par identité d'agent, et non une moyenne globale de flotte qui mélange les chatbots avec les planificateurs. - Détection d'anomalies. Étapes presque identiques répétées ; durée d'exécution loin au-dessus de la bande ; un outil jamais vu auparavant en production ; réessais croissants suivis d'abandon ; longueur de sortie ou taux de refus s'éloignant de la ligne de base. - Rapport avec preuve. Une entrée de surveillance doit être liée à un parcours relecture. Si un ingénieur de garde ne peut pas ouvrir l'exécution et voir les décisions dans l'ordre, l'alerte sera ignorée dans une semaine.

Signaux qui valent la peine d'être signalés

- Nombre de répétitions pour l'outil avec les mêmes ou des arguments quasi identiques. - Nombre d'étapes ou de durée supérieur à la bande habituelle de l'agent après exclusion des tâches longues connues. - Un outil qui n'a jamais été appelé pour cet agent apparaissant dans le trafic de production. - Réessais croissants suivis d'abandon sans réponse visible pour l'utilisateur. - Changements brusques dans le mélange d'outils après une mise à jour de modèle ou de prompt — souvent un dérive ou une mauvaise version, et non « les utilisateurs sont devenus plus difficiles ».

Ne pas signaler chaque exécution lente. Les exécutions longues qui progressent toujours ne sont pas des boucles. La fatigue d'alerte est la façon dont les produits de surveillance meurent. Préférer le taux de changement par rapport à une référence spécifique à l'agent, puis exiger un historique afin que chaque alerte puisse être fermée avec des preuves.

Références de base cassées - enregistrer les raisons

Un changement de modèle, un changement de prompt, un nouvel outil ou un changement dans le mélange de trafic va modifier vos chiffres. Si vous n'enregistrez pas ces événements, chaque version ressemble à un dérive mystérieux. Gardez un journal de modifications simple à côté des métriques : quel modèle, quel hachage de prompt, quels outils étaient activés et quand la composition du trafic a changé.

Ce que la surveillance ne fait pas

La surveillance vous indique qu'il s'est produit quelque chose. Une limite d'étape ou une barrière de sécurité à l'exécution l'arrête. Confondre les deux conduit à des allégations excessives. AgentPulse ne garantit pas que les alertes se déclencheront toujours à temps pour prévenir l'impact sur l'utilisateur. Nous ne prétendons pas détecter 100 %. Nous ne prétendons pas que vous ne manquerez jamais une boucle.

Confidentialité et rétention

Les traces contiennent souvent du contenu utilisateur. Conservez-les suffisamment longtemps pour enquêter, mais suffisamment court pour respecter ce que vous avez dit aux utilisateurs dans la politique de confidentialité. Une rétention courte par défaut, l'exportation sur demande et des contrôles d'accès conformes à l'encadrement de l'article 32 du GDPR sont le minimum — et non un badge de certification que vous pouvez apposer sur un deck de vente.

Comment AgentPulse s'intègre dans une chaîne d'outils

Utilisez votre APM existant pour les services autour de l'agent. Utilisez OpenTelemetry (ou équivalent) pour le plumbing des spans si vous avez déjà investi dans ce domaine. Utilisez AgentPulse lorsque vous avez besoin d'un rapport de surveillance ciblé sur les boucles, les dérives et l'utilisation anormale d'outils avec un récit relecture - en particulier au début, lorsque la mise en place d'un plan de contrôle complet d'agent est excessif. L'entreprise peut ajouter BYOK et les documents DPA ; Free et Demo restent étiquetés afin que rien ne prétende être une intelligence artificielle en direct lorsque la clé est manquante. De plus, les outils tels que peuvent être utilisés pour améliorer la sécurité et la conformité.

Exemple de travail (synthétique, pas une histoire de client)

Imaginez un agent planificateur qui prend normalement 6-10 étapes d'outil. Pendant la nuit, les étapes s'étendent à 40+ et le même outil de recherche est appelé avec des requêtes presque identiques. La latence est toujours « correcte » car chaque appel d'outil retourne rapidement. Un détecteur de boucle qui surveille les comptes de répétition et la longueur du plan augmenterait une entrée de surveillance ; un tableau de bord de latence uniquement resterait silencieux. L'ouverture de la trajectoire montrerait le bloc de recherche répétitif.

Maintenant, modifiez l'invite pour permettre un nouvel outil de recherche. Le mélange d'outils change. Sans journal des modifications, cela ressemble à un dérive. Avec un journal des modifications, c'est un réinitialisation de la ligne de base attendue. Les bons produits de surveillance rendent cette distinction ennuyeuse et explicite.

Liste de vérification opérationnelle

- Émettre des événements de décision par exécution (outil, hachage des arguments, classe de résultat, nombre de réessais). - Stocker un parcours répétible ordonné pour chaque incident paginé. - Établir une ligne de base par identité d'agent ; réinitialiser en cas de modification du modèle, de l'invite ou de l'outil. - Séparer la détection (surveillance) de l'application (limites de sécurité / plafonds d'étapes). - Ne jamais commercialiser une détection à 100 % ou une garantie de non-détection.

Conseils d'instrumentation pour réduire les faux positifs

Hachez les arguments des outils avant de les comparer. L'égalité des chaînes exactes sur du JSON libre crée du bruit lorsque les horodatages ou les ID de demande diffèrent. Une empreinte stable des champs sémantiques (texte de requête, ID de ressource, nom d'action) maintient la détection de boucle honnête sans stocker les charges utiles complètes pour toujours.

Séparez les réessais initiés par l'utilisateur des réessais initiés par l'agent. Un humain qui clique sur "réessayer" n'est pas le même mode d'échec qu'un agent qui réentre dans le même nœud de planification. Étiquetez l'initiateur de chaque événement de réessai afin que vos règles de surveillance puissent les traiter différemment.

Excluez les flux de travail longs connus de la page de durée par défaut. Les agents de recherche par lots peuvent légitimement s'exécuter pendant des minutes. Placez ces ID d'agent sur une liste d'autorisation avec une bande plus élevée, plutôt que de silencer toute la flotte.

Versionnez vos règles de surveillance de la même manière que vous versionnez les invites. Lorsqu'une règle change, annotEZ le tableau de bord afin qu'un pic ne soit pas mal interprété comme un dérive d'agent.

Esquisse de livre de jeu pour les appels

- Ouvrez l'entrée de surveillance et confirmez que le parcours indique un modèle de boucle ou de dérive réel. - Vérifiez le journal des modifications pour les modifications apportées au modèle, à la invite ou à l'outillage au cours des dernières 24 heures. - Si la boucle est confirmée, activez ou renforcez la limite d'étapes d'exécution pour cette identité d'agent. - Si la dérive est confirmée après une publication, restaurez ou rétablissez la référence avec une note explicite. - Si le parcours est incomplet, corrigez l'instrumentation avant de déclencher davantage de pages — les alertes sans preuve gaspillent la confiance.

Documentez la raison de fermeture sur chaque page. Des modèles tels que "faux positif dû au mélange de trafic" enseignent au prochain quart ce qu'il faut ignorer. Des modèles tels que "régression de l'invite" enseignent aux ingénieurs ce qu'il faut tester avant de lancer.

Ce que AgentPulse n'inventera pas

Nous n'inventerons pas les logos des clients, les pourcentages de temps d'activité ou les affirmations de « réduction des incidents de X % ». Les sections de preuve sociale restent marquées EN ATTENTE jusqu'à ce que des citations réelles existent. Les chiffres de ROI dans les modules de contenu sont des modèles. C'est une retenue délibérée conforme à la FTC, et non une marketing incomplète. Nous travaillons avec des outils tels que pour nous assurer que nos processus sont efficaces et sécurisés, comme indiqué dans notre documentation.

Questions fréquentes

Quelle est la différence entre une boucle et une longue course ?

Une longue course fait des progrès. Une boucle répète une étape, ou une variante presque identique, sans se rapprocher de l'objectif.

Comment évitons-nous la fatigue d'alerte ?

Alertez sur le taux de changement par rapport à la ligne de base propre à chaque agent, et exigez une traçabilité répétible afin que chaque alerte puisse être fermée rapidement.

Qu'est-ce qui brise une ligne de base ?

Un changement de modèle, un changement de prompt, un nouvel outil, ou un changement dans le mix de trafic. Enregistrez-les pour ne pas les lire comme un dérive non expliqué.

Une boucle doit-elle arrêter l'agent ?

C'est une décision de garde-fou d'exécution, et non de surveillance. La surveillance vous indique qu'il s'est produit ; une limite d'étapes l'arrête.

Combien de temps les traces doivent-elles être conservées ?

Assez longtemps pour enquêter, suffisamment court pour respecter ce que vous avez promis aux utilisateurs en matière de rétention. Les traces contiennent généralement du contenu utilisateur.

Le dérive est-il toujours mauvais ?

Non. Les changements de trafic peuvent l'expliquer. Le dérive est un signal pour regarder, et non un verdict.

AgentPulse remplace-t-il OpenTelemetry ?

Non. OpenTelemetry est une infrastructure. AgentPulse est un produit de surveillance et de rapport ciblé qui peut être placé à côté des pipelines pris en charge par OpenTelemetry.

Références

- OpenTelemetry — Observabilité GenAI (2026) - OTel GenAI étendues d'agent - NIST — Cadre de gestion des risques liés à l'IA

Essayez le produit : AgentPulse

2026-09-26 · sources primaires uniquement · pas de métriques de trafic fabriquées · prise en charge de décision uniquement · RULESET_VERSION 2026-09-26

Articles liés

- Observabilité des agents vs APM classique - Explorez la matrice complète des sujets de micro-SaaS IA →

Pourquoi les alertes basées uniquement sur la latence échouent-elles pour les agents ?

La surveillance classique des services s'est développée autour d'une demande qui commence, se termine et renvoie un code de statut. Une exécution d'agent autonome n'obéit pas à ce contrat. Il peut appeler des outils dans un arbre, réessayer le même outil avec des arguments légèrement différents, abandonner un plan en cours de route ou continuer longtemps après que l'humain aurait arrêté. Un graphique de latence p99 vert peut être affiché à côté d'un planificateur qui s'échappe et brûle des jetons sans faire de progrès.

Qu'est-ce qu'un modèle de surveillance à quatre étapes ?

N'alertez pas sur chaque exécution lente. Les exécutions longues qui avancent toujours ne sont pas des boucles. La fatigue d'alerte est la façon dont les produits de surveillance meurent. Préférez le taux de changement par rapport à une ligne de base spécifique à l'agent, puis exigez un trail afin que chaque alerte puisse être fermée avec des preuves.

Quels signaux vaut-il la peine de pager ?

Qu'est-ce que les références de base cassent — enregistrez pourquoi ?

Un changement de modèle, un changement de prompt, un nouvel outil ou un changement de mix de trafic déplacera vos chiffres. Si vous n'enregistrez pas ces événements, chaque version ressemble à une dérive mystérieuse. Gardez un journal de modifications simple à côté des métriques : quel modèle, quel hachage de prompt, quels outils ont été activés et quand la composition du trafic a changé. Les consommateurs de scores émis par les producteurs (confiance, dérive, analyse) dans les propositions OTel émergentes sont déjà averties que les jetons de méthode comptent — lorsque la méthode de notation change, réancrez la corrélation plutôt que de traiter le saut comme un comportement d'agent incorrect.

Qu'est-ce que la surveillance ne fait pas ?

La surveillance vous indique que quelque chose s'est produit. Une limite d'étape de runtime ou une barrière d'arrêt l'empêche. Confondre les deux conduit à une surestimation. AgentPulse ne garantit pas que les alertes se déclencheront toujours à temps pour prévenir l'impact sur l'utilisateur. Nous ne prétendons pas détecter 100 %. Nous ne prétendons pas que vous ne manquerez jamais une boucle. Ces lignes d'honnêteté existent parce que les règles de marketing de style FTC punissent la certitude fabriquée, et parce que les opérateurs méritent des outils qui indiquent leurs limites.

Support de décision uniquement. Pas de SLA de disponibilité, d'audit de sécurité ou de garantie que les agents ne défailliront jamais.

← Retour au blog