Comment ça passe inaperçu
Le build a échoué, mais l'agent est déjà passé à la rédaction d'un résumé. A-t-il récupéré, ou un échec important a-t-il disparu entre deux étapes? L'action suivante est souvent là où une revue utile devrait commencer.
Dans une session chargée, une erreur peut défiler juste avant un appel d'outil différent. L'agent peut avoir une stratégie de récupération valide. Ou il peut continuer sans traiter l'échec. Dans les deux cas, vous avez besoin de la séquence environnante pour décider.
Ce que ClawMetry détecte
ClawMetry signale un résultat d'outil en échec suivi d'une activité continue sans nouvelle tentative ni accusé de réception reconnu. Il crée une détection informative d'écart d'action. Cette sévérité réduite est importante : c'est une invitation à inspecter la transition, pas un verdict sur l'intention de l'agent.
La différence qui change tout
Exemple déclencheur
Échec, outil différent
Information
Comparaison silencieuse
Échec, nouvelle tentative avec le même outil
Aucune détection pour ce détecteur.
L'exemple vérifié échoue à un build shell puis appelle un outil différent. Il lève une détection informative. Un échec suivi d'un autre appel au même outil est traité comme une nouvelle tentative et reste silencieux pour ce détecteur.
Inspecter le résultat du détecteur
{
"kind": "action_discrepancy",
"severity": "info",
"evidence": {
"failed_tool": "Bash",
"continued_as": "tool_call"
}
}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
Comparez l'étape en échec avec ce qui a suivi. La nouvelle action était-elle un chemin de récupération? L'erreur a-t-elle été reconnue ailleurs? Avant de vous fier à un rapport de complétion, vérifiez le résultat sous-jacent que l'opération en échec devait produire.
- Inspecter le résultat en échec
- Vérifier le chemin de récupération
- Valider le résultat annoncé
Ce que ce signal établit
Le détecteur ne vérifie pas la déclaration de complétion finale. Une récupération légitime via un autre outil peut aussi correspondre.