OpenFox : harnais open source pour LLM locaux, avec pipeline Build & Verify, workspaces isolés et revue PR automatisée

Déroulé structuré

Segment 1 — Positionnement, stack technique et installation

Statut : Information first-party (présentation du créateur)

• OpenFox est un harnais d’agent IA open source et gratuit, positionné à côté de Claude Code et OpenCode, conçu d’abord pour les LLM locaux tout en restant compatible cloud.
• Le présentateur (Nicefox) est le créateur du projet, développé avec des contributeurs. La vidéo est donc un guide first-party.
• Installation via npm i -g openfox, avec support PWA et réseau local.
• Connexion d’un LLM local via vLLM ou Ollama, avec détection automatique des modèles disponibles sur le point de terminal configuré. Le modèle principal tourne sur un cluster DGX Spark accessible par IP.
• Un modèle secondaire de vision (petit modèle local, ex. 3,5B via Ollama) peut être configuré pour compenser l’absence de compréhension d’images du modèle principal.
• Stack de test : 2x DGX Spark, DeepSeek V4 Flash via vLLM.

Segment 2 — Interface session et planification par critères

Statut : Information first-party (présentation du créateur)

• L’interface session affiche, après chaque réponse de l’agent, des statistiques spécifiques à l’inférence locale : vitesse de traitement du prompt en tokens/s (~1,7K), vitesse de génération en tokens/s (54,6), usage du contexte, et logs par appel.
• Le paradigme central est la planification par critères d’acceptation : un agent planner génère des critères à partir de la demande de l’utilisateur, qui les examine et ajuste via conversation. Ces critères forment un « contrat » qui pilote le pipeline Build & Verify.

Segment 3 — Pipeline Build & Verify et démo Pac-Man

Statut : Information first-party (présentation du créateur)

• Pipeline multi-agents : (1) le builder implémente le code selon les critères d’acceptation ; (2) un vérifieur indépendant ne contrôle que les critères concernés, pas tout le code ; (3) un relecteur statique analyse l’UX et la propreté du code ; (4) le builder fait le triage des remarques et décide ce qu’il corrige ; (5) un résumé est produit pour l’utilisateur.
• Démo live : prompt unique « build a Pac-Man clone ». Le modèle comprend la tâche en ~20 s et propose les critères d’acceptation.
• Le vérifieur détecte un bug d’état de victoire injoignable (critère 6 : state.win défini mais jamais assigné). Après correction, il ne relance que le critère 6.
• Le relecteur statique trouve 9 problèmes (mauvaise langue, timing incohérent, bug de logique de jeu, absence d’animation de mort). Les 9 sont corrigés.
• Un test manuel révèle un bug de direction des flèches, également corrigé. Le jeu est jouable, le premier niveau est complété.
• Tous les résultats sont auto-rapportés par le créateur.

Segment 4 — Workspaces isolés et parallélisme

Statut : Information first-party (présentation du créateur)

• Le système de workspaces permet à plusieurs agents de travailler en parallèle sur le même projet dans des environnements isolés ; les modifications d’un workspace sont invisibles des autres.
• Démo : deux sessions parallèles (changement de couleur de la carte en jaune ; ajout de 4 fantômes) dans des workspaces distincts.
• Cycle de vie : création du workspace, travail, commit, push vers le dépôt principal, suppression du workspace.
• Première version implémentée avec l’aide d’un contributeur (Renzan).

Segment 5 — Revue de PR automatisée

Statut : Information first-party (présentation du créateur)

• Workflow /review N : création d’un workspace isolé avec la source de la PR, téléchargement des fichiers, exécution des tests, identification des problèmes.
• Défini dans un fichier adjunct.md sur GitHub ; l’agent lit le document et lance le processus pour la PR spécifiée.
• Démo sur la PR 116 du projet OpenFox : tout se déroule « 100 % en isolation dans un workspace ».
• Le créateur indique gérer un volume de PR « presque à temps plein » et envisage une vidéo dédiée. Statut : information rapportée, non vérifiée.

Segment 6 — Workflows custom, MCP et personnalisation

Statut : Information first-party (présentation du créateur)

• Constructeur visuel de workflows : enchaînement d’étapes agent (builder, explorer, etc.) avec logique conditionnelle.
• Système de métadonnées pour le contrôle de flux : ex. champ finished qui doit être passé à true pour sortir d’une boucle avant passage à l’agent suivant.
• Support MCP (Model Context Protocol) : ajout de serveurs d’outils externes manuellement ou via l’agent (démo : Brave Search MCP).
• Avertissement sécurité : en mode cloud, les clés API transitent vers des destinations inconnues ; contournement par clé aléatoire à remplacer dans les paramètres.
• Modification des outils en cours de session invalide le prompt cache, nécessitant un re-traitement complet du contexte.

Segment 7 — Mention Kimi K3

Statut : Mention passagère, non confirmée

• Dans l’outro, le créateur mentionne Kimi K3, modèle récemment sorti qui « semble assez incroyable », tout en réaffirmant sa priorité à l’IA locale. Aucun détail, démo ni évaluation n’est fourni.

Points notables

• Granularité de la vérification : le vérifieur indépendant ne re-vérifie que les critères concernés après une correction, pas l’ensemble du code. Ce pattern réduit le coût d’itération dans un pipeline multi-agents.
• Pattern workspace + revue PR : l’isolation d’agents dans des workspaces avec cycle commit/push/suppression est une architecture de workflow transférable au-delà d’OpenFox, applicable à d’autres harnais d’agents.
• Modèle secondaire de vision : l’idée d’un petit modèle local dédié à la description d’images pour compléter un modèle de code principal est un pattern réutilisable pour les setups LLM locaux.
• Métadonnées de contrôle de flux : le système de clés/métadonnées (ex. finished=true) pour piloter les transitions entre agents dans un workflow custom est un mécanisme de contrôle de flux explicite.
• Statistiques inférence locale : l’affichage séparé de la vitesse de traitement du prompt vs. génération de tokens est un indicateur utile pour le dimensionnement des clusters locaux.

Limites & biais factuels

• Présentation first-party : le créateur d’OpenFox présente son propre outil ; titre promotionnel (« le meilleur harnais ») et positionnement favorable. Aucune expérience utilisateur indépendante, benchmark ni comparatif objectif avec Claude Code ou OpenCode n’est fourni.
• Résultats auto-rapportés : la détection de bugs (9 problèmes du reviewer, bug d’état de victoire du vérifieur), la productivité et le volume de PR ne sont pas vérifiés par des tiers dans cette source.
• Transcription imparfaite : les noms de modèles sont garbés dans la transcription (DeepSeek V4 Flash → « Dipsic/Dipsy V4 Flash », Claude Code → « Cloud Code »). La stack technique doit être confirmée via le dépôt GitHub ou la documentation.
• Kimi K3 : mention passagère sans détail exploitable ; ne constitue pas une information actionnable à partir de cette source.
• Volume de PR : l’affirmation « presque à temps plein » est une déclaration du créateur, non vérifiable à partir de la vidéo seule.