Débugger le non-déterministe
Débugger les systèmes agents traditionnels est un exercice de frustration. Vous observez un échec, mais quand vous relancez l’agent avec les mêmes entrées, il prend un chemin différent et réussit. Ou il échoue différemment. Le non-déterminisme qui rend les LLM créatifs les rend aussi quasi impossibles à débugger systématiquement.
Le génie logiciel traditionnel a des workflows de débogage bien établis : mettre un breakpoint, reproduire le bug, stepper dans le code, corriger, écrire un test de régression. Chaque étape suppose le déterminisme. Quand votre « code » est un LLM qui produit des sorties différentes à chaque fois, les breakpoints n’ont pas de sens et la reproduction est impossible.
Le développement piloté par le replay
Le développement piloté par le replay (RDD) est un nouveau paradigme qui résout ce problème en rendant les exécutions d’agents entièrement reproductibles. L’idée centrale est simple : chaque exécution d’agent est enregistrée comme un graphe d’exécution déterministe, et toute exécution peut être rejouée identiquement.
Le workflow ressemble à ceci :
- 1. Capturer — L’agent s’exécute en production. La couche d’exécution enregistre le graphe complet.
- 2. Rejouer — Quand un bug est signalé, rejouez l’exécution exacte localement.
- 3. Modifier — Forkez le graphe d’exécution au point de défaillance. Modifiez pour corriger.
- 4. Vérifier — Relancez le graphe modifié contre les entrées originales.
- 5. Déployer — Promouvez le graphe corrigé en production.
Tests de régression pour les agents
L’une des fonctionnalités les plus puissantes du RDD est le test de régression déterministe. Quand vous corrigez un bug dans un graphe d’exécution, l’exécution échouée originale devient un cas de test. Le graphe corrigé doit passer contre les entrées originales. C’est un vrai test déterministe — pas une assertion probabiliste.
Au fil du temps, votre bibliothèque de traces d’exécution devient une suite de tests complète. Chaque échec de production corrigé ajoute un nouveau test de régression. Votre système agent accumule la connaissance des cas limites et des modes de défaillance.
Débogage collaboratif
Les graphes d’exécution sont des artefacts partageables. Quand un agent échoue en production, l’ingénieur d’astreinte peut exporter la trace et la partager avec l’équipe. Tout le monde peut la rejouer localement. Le graphe d’exécution devient le langage partagé pour discuter du comportement des agents.
Au-delà du débogage
Le RDD s’étend au-delà du débogage vers le développement d’agents lui-même. Pour construire une nouvelle capacité agent, vous pouvez prototyper le graphe d’exécution manuellement, le tester avec des données réelles, et seulement ensuite le connecter au LLM. Cela inverse l’approche traditionnelle de laisser le LLM trouver le chemin d’exécution.