Comment ça passe inaperçu
Un build échoue. L'agent réessaie. Il échoue encore. Chaque tentative ajoute plus de sortie, mais le problème sous-jacent est toujours là. Si vous vérifiez seulement si la session est active, vous pouvez manquer l'échec qui se répète.
Imaginez un agent préparant une modification pendant que son outil shell renvoie une erreur en continu. La cause peut être une dépendance manquante, une commande invalide ou un accès indisponible. La question utile est quel outil continue d'échouer, et combien de fois.
Ce que ClawMetry détecte
ClawMetry compte les erreurs attribuées au même outil dans la fenêtre d'événements. Lorsque le compteur dépasse le seuil applicable, une alerte d'échec d'outil répété est levée. La détection nomme l'outil, le nombre d'échecs et le seuil utilisé.
La différence qui change tout
Exemple déclencheur
4 erreurs de Bash
Alerte
Comparaison silencieuse
1 erreur de Bash
Aucune détection pour ce détecteur.
Dans l'exemple vérifié, quatre résultats shell en échec produisent une alerte. Un seul échec reste en dessous du seuil. C'est différent d'une boucle d'appels identiques : les commandes peuvent changer pendant que le même outil continue de renvoyer des erreurs.
Inspecter le résultat du détecteur
{
"kind": "repeated_tool_failure",
"severity": "warning",
"evidence": {
"tool": "Bash",
"failures": 4,
"threshold": 3,
"threshold_source": "static"
}
}Comment l'exemple a été vérifié
Ces exemples évaluent le détecteur publié avec des données d'événements créées pour l'occasion ou des fichiers de configuration jetables. Les vidéos illustrent ces comportements. Il ne s'agit pas d'enregistrements d'agents réels ni de l'interface du produit. Aucune commande dans les exemples n'a été exécutée.
Le résultat établit le comportement pour ces entrées. Il n'établit pas l'ingestion en temps réel, la prévention ni un véritable compromis. Inspecter le contrat source épinglé.
Que vérifier ensuite
Ouvrez les résultats en échec et recherchez la cause commune. Corrigez le problème d'environnement ou d'accès, ou réduisez la portée de la tâche avant de laisser les tentatives s'accumuler. Vérifiez ensuite que le résultat suivant de l'outil réussit réellement.
- Lire les résultats d'erreur
- Corriger la cause commune
- Vérifier le résultat suivant
Ce que ce signal établit
Il s'agit d'un signal de fiabilité. Il ne diagnostique pas la cause racine ni ne prouve que l'agent est sous attaque.