Un agent de remboursement expédie la v2. Un client demande un remboursement. L'agent répond :
Votre remboursement de 48,20 $ a été émis et apparaîtra dans 3 à 5 jours ouvrables.
C'est exactement ce que dit la v1. Le montant est correct. Le ton est juste. Un juge LLM le note de manière identique. Une suite de régression comparant les sorties ne voit aucune différence. Expédiez-le.
En dessous, cela s'est passé :
v1 (approuvé) v2 (expédié) remboursé.request remboursement.request -> politique.retrieve -> order.lookup -> order.lookup -> payment.refund -> fraud.check -> payment.refund <- facturé deux fois -> remboursement.calculate -> customer.notify -> payment.refund -> customer.notifyLa récupération de la politique de remboursement a disparu. Le contrôle de fraude a disparu. Et l'écriture du paiement s'est produite deux fois : un délai d'attente, une nouvelle tentative et le grand livre d'idempotence du service de paiement enregistrant les deux entrées.
Le client a reçu la bonne phrase. L'entreprise a remboursé 96,40 $ et a ignoré ses propres contrôles de conformité. Tous les contrôles basés sur les résultats en cours étaient verts.
Ce n’est pas une hypothèse. Il s'agit du mode d'échec qui apparaît lorsqu'un agent dispose d'une politique de nouvelle tentative, d'un outil qu'il peut ignorer et d'une invite modifiée par quelqu'un un vendredi. L’évaluation du résultat est structurellement aveugle, car le résultat est correct.
La trajectoire d’exécution est l’endroit où réside le bug. Et une trajectoire est exactement ce qu’est une trace distribuée.
FlightRules transforme les traces SigNoz en contrats de version déterministes. Il extrait un contrat de trajectoire à partir d'exécutions approuvées par un humain, puis évalue chaque version ultérieure par rapport à celui-ci et échoue à la version avec les traces qui le prouvent. Dans CI, c'est une commande :
$ Flightrules Gate Check --release Refund-Agent-v2 Échec : cette version a dépassé un ou plusieurs seuils de trajectoire. Résultats MISSING_PREREQUISITE (skipped_check) fraud.check est requis au moins 1 fois mais s'est produit 0 fois. DUPLICATE_SIDE_EFFECT (duplicate_write) payment.refund s'est produit 2 fois ; le contrat en autorise au plus 1 par course. code de sortie : 2Code de sortie 2. Le pipeline s'arrête.
Cinq étapes et les décisions de conception intéressantes concernent toutes ce qui n'est pas autorisé dans chacune d'entre elles.
1. Instrument. La démo est un agent de remboursement et cinq services (politique, commandes, fraude, paiement, notification) instrumentés avec OpenTelemetry et exportant des traces, des métriques et des journaux via OTLP vers SigNoz. L'agent émetgen_ai.*attributs pour l'identité et le fonctionnement de l'outil, plus un petit espace de noms FlightRules :agent.side_effect,agent.data_domain,agent.retry.number,agent.idempotence.présent.
Il n'émet aucune invite, aucune sortie de modèle, aucun argument d'outil, aucun résultat d'outil et aucune chaîne de pensée. C'était une contrainte dès le départ, et...
[Courte citation de 8% de l'article original]