Agnes 3.0 Flash Overclock passé en revue : un vérificateur, un panel QA et un benchmark honnête

Ce qu’est ce dépôt

Le dépôt se présente comme un kit expérimental d’ingénierie de prompts et de validation pour Agnes 3.0 Flash, construit autour de scripts vidéo courts en russe, de réécritures qui préservent la source et de JSON contraint. Son README définit « overclock » comme un réglage du flux de travail, pas une modification des poids ni une preuve de qualité maximale. Il précise qu’il n’est installé dans aucune chaîne de production.

Il faut Python 3.10 ou plus et la seule bibliothèque standard. Le vérificateur n’exige aucune clé d’API et n’utilise pas le réseau. Le fichier LICENSE est la licence MIT, et le dépôt intègre deux compétences d’autres auteurs avec leurs propres fichiers de licence.

Ce que le benchmark a montré

Le README rapporte six tâches avec deux échantillons par condition, 35 appels sur 36 prévus réalisés le 10 octobre 2026. Voici les chiffres publiés.

Le README les qualifie de scores indicatifs de contrôles de contraintes. Les sorties vides ou incomplètes ont été exclues, les dénominateurs diffèrent, il n’y a pas eu de juge de qualité en aveugle, et la référence était un jeu de réponses écrit par l’auteur, pas une exécution vérifiée d’un autre modèle. Il dit qu’aucune parité n’est démontrée. Le rapport de benchmark ajoute que les agrégats ne peuvent pas être régénérés depuis le dépôt, faute de sorties brutes, de références complètes, du scoreur d’origine et du journal d’appels, et que 4 des 36 échantillons prévus manquent aux dénominateurs sans qu’on puisse les identifier. Mon jugement : cette transparence est rare, et c’est elle qui rend les chiffres utilisables comme indice et non comme résultat.

Les cinq parties

• Vérificateur de sortie. check.py contrôle les fourchettes de mots, le JSON strict, les durées de scènes, les contraintes de paragraphes, les littéraux numériques et le texte parasite pour six tâches prédéfinies. J’ai lancé le brouillon d’exemple : il passe. Le README précise qu’une réussite ne prouve pas la vérité et que les contrôles numériques comparent des ensembles de littéraux, pas des associations.
• Panel QA de 25 agents. Une méthode à 25 angles en 5 vagues de 5, avec une CLI hors ligne qui produit les consignes, consolide les rapports et vérifie l’état des corrections. Le dépôt ne peut pas lancer d’agents ; les outils ne vérifient que la tenue des comptes. La documentation dit que l’exécution a trouvé 1 bloquant et 11 majeurs, et que ces nombres viennent de la liste de l’agent principal, pas d’un audit indépendant.
• Filtres unslop pour l’interface. Un prompt et un scanner à expressions régulières pour du code front-end à l’aspect générique. Sur le sloppy.css synthétique du dépôt, j’ai obtenu 12 résultats dont 9 élevés ou critiques ; sur clean.css, aucun. La documentation dit que les règles sont paraphrasées et relèvent du goût, que les licences d’origine n’ont pas été vérifiées et qu’un scan propre ne vaut pas validation.
• Porte de preuve de livraison. Une enveloppe JSON optionnelle avec hachages de fichiers, journal de commandes, résultats de tests et déclarations d’inspection visuelle. La documentation est explicite : elle vérifie la présence et la forme, pas la vérité, et un journal inventé mais plausible peut passer. L’exemple que j’ai lancé passe.
• Routeur et serveur MCP. route.py ne renvoie que les consignes d’une tâche et d’une phase par correspondance de mots-clés, sans modèle. Le serveur MCP expose six outils : agnes_check, agnes_list_tasks, agnes_get_prompt, agnes_build_messages, agnes_route et agnes_review_messages.

Ce que j’ai exécuté

Au commit 077e4ab, la suite complète a rapporté 113 tests, OK, 1 ignoré (le test réseau optionnel), en environ 8 secondes. Le README donne le même nombre. Les exemples du vérificateur, du scanner, du routeur et de la porte de preuve ont fonctionné comme documenté. Je n’ai lancé aucune intégration d’hôte (Cursor, Codex, Claude Code et autres) et je n’avais pas accès à Agnes : les prompts, la passe d’édition et la boucle de réparation v2 ne sont donc pas vérifiés par moi. Le dépôt le dit aussi.

Où il est solide

• Les affirmations suivent les preuves. Chaque extension est marquée non testée, et les réserves sur le benchmark sont à côté des chiffres.
• Petit et auditable. Bibliothèque standard seulement, environ 2 800 lignes de Python tests compris, aucune clé.
• Récupération distante soignée. Les routes distantes utilisent une origine fixe, aucune redirection, une limite de temps, un plafond de taille et un marqueur de contenu non fiable ; les tests les couvrent avec un réseau simulé.

Où il est mince

• Base de preuves. Le seul résultat mesuré est un petit benchmark sur des tâches vidéo courtes en russe, impossible à reproduire depuis le dépôt.
• La forme, pas la vérité. Le vérificateur, la porte de preuve et le scanner contrôlent la forme. Une relecture humaine des faits et de la voix reste nécessaire, comme le dit le dépôt.
• Support des hôtes non démontré. Les configurations MCP par hôte ont été comparées à la documentation des éditeurs, mais aucun hôte n’a été exécuté de bout en bout.
• Vérificateur étroit. Les préréglages visent les scripts vidéo en russe ; pour d’autres usages, il faut écrire ses propres contraintes.

Une précision

Trois routes de ce dépôt, jg-prompts, jg-mcp et jg-extensions, récupèrent de petites pages sur ce site, celui que vous lisez. Je n’ai aucune influence sur la rédaction du dépôt et j’ai essayé de le juger selon le même critère que n’importe quel autre. Vous devez tout de même en tenir compte.

Comment je l’évaluerais

Passez le vérificateur hors ligne sur des sorties que vous avez déjà et voyez si ses violations correspondent à ce qu’un relecteur signalerait. Mesurez la passe d’édition sur vos propres tâches, en gardant les essais échoués et vides dans le décompte. Les chiffres seront les vôtres ; je n’en ai aucun à ajouter et je ne publie pas de chiffres simulés.