LangChain a levé 160 millions de dollars. Trois ans de développement. Une valorisation d'un milliard de dollars. LangSmith, leur plateforme de test, est vraiment sophistiquée : évaluations de trajectoire, pipelines de trace vers dataset, LLM en tant que juge, suites de régression, frameworks de tests unitaires pour les outils. Ils ont les pièces. À leur crédit.
Mais les pièces ne font pas une pratique.
LangChain vous donne des outils de test. Il ne vous dit jamais quoi tester, dans quel ordre, ni quand vous avez terminé.
Il n'y a pas de workflow normatif qui dit, dans l'ordre :
- cette erreur s'est produite
- maintenant écris une compétence
- maintenant écris le code déterministe
- maintenant écris les tests unitaires
- maintenant écris les évaluations LLM
- maintenant ajoute un déclencheur de résolveur
- maintenant évalue le résolveur
- maintenant vérifie les doublons
- maintenant fais un test de fumée
- maintenant classe correctement
Cette boucle n'existe pas. Vous devez l'inventer vous-même à partir de primitives dispersées. Un grand nombre d'utilisateurs d'IA ne testent toujours pas leurs agents, parce que le framework qu'ils ont choisi leur a probablement donné un abonnement à la salle de sport sans plan d'entraînement.
La plupart de la « fiabilité » des agents IA est basée sur les vibes. Ajustements de prompt. Messages système plus longs. Incantations « S'il te plaît, n'hallucine pas ». Tout ça se dégrade dès que la conversation devient complexe. Les frameworks qui ont levé des centaines de millions de dollars pour résoudre ce problème vous ont donné des tableaux de bord de monitoring et des aides aux tests unitaires et vous ont dit « bonne chance ».
Mon agent a fait deux erreurs cette semaine. Aucune des deux ne peut se reproduire. Pas parce que j'ai demandé gentiment. Parce que j'ai transformé chaque erreur en correctif structurel permanent : une compétence avec des tests qui s'exécutent tous les jours, pour toujours.
J'appelle cette pratique « skillifier ». Une fois que vous l'utilisez, vos agents ne continueront pas à faire les mêmes erreurs. Voici comment ça marche.
Erreur 1 : Le voyage qui était déjà dans la base de données
J'ai demandé à mon OpenClaw un ancien voyage d'affaires, vieux de près de dix ans, enfoui quelque part dans l'historique du calendrier. Question simple. Ça aurait dû prendre une seconde.
Au lieu de ça, l'agent a fait ceci :
- Appel à l'API calendrier en direct → bloqué (trop ancien).
- Recherche par email → résultats bruyants, rien de concluant.
- Nouvel essai de l'API calendrier avec des paramètres différents → toujours bloqué.
- Cinq minutes plus tard, recherche dans ma base de connaissances locale et trouvé instantanément.
La réponse était dans mes propres données depuis le début. 3 146 fichiers de calendrier couvrant 2013 à 2026. Déjà indexés. Déjà locaux. À un grep près.
L'agent n'a simplement pas regardé là en premier.
Dans le framework dont j'écris (harnais fin, compétences épaisses), il y a une distinction clé entre le travail qui nécessite du jugement et le travail qui nécessite de la précision. Je les appelle latent et déterministe. Le grep de calendrier est déterministe. Même entrée, même sortie, à chaque fois. Pas besoin de modèle. Mais l'agent l'a quand même fait dans l'espace latent, en faisant tourner le raisonnement, en effectuant des appels API, en interprétant les résultats, alors qu'un script de trois lignes aurait renvoyé la réponse instantanément.
C'est le bug. Pas une mauvaise réponse. Un mauvais côté.
Le correctif : calendar-recall (Étapes 1 + 2)
Dans harnais fin / compétences épaisses, une compétence est une procédure en markdown qui apprend au modèle comment aborder une tâche. Pas quoi faire (l'utilisateur fournit le quoi). La compétence fournit le processus. Pensez-y comme à un appel de méthode : même procédure, des résultats radicalement différents selon ce que vous passez.
Voici la compétence qui est née de cette erreur :
nom : calendar-recall description : « Recherche de calendrier historique prioritaire par le cerveau. À UTILISER TOUJOURS avant toute API en direct pour tout événement qui n'est pas dans le futur ou les dernières 48 heures. »
Et la règle stricte à l'intérieur :
Les API de calendrier en direct sont UNIQUEMENT pour les événements dans le FUTUR ou les DERNIÈRES 48 HEURES. Tout ce qui est historique passe d'abord par la base de connaissances locale.
Voici ce qui rend ça efficace : l'agent lui-même a écrit le script déterministe. Le fichier de compétence (markdown, vivant dans l'espace latent) a dit à l'agent comment résoudre le problème. L'agent a lu la compétence, a compris que la recherche dans le calendrier est un travail déterministe, et a généré un script pour le gérer :
$ node scripts/calendar-recall.mjs search "Singapour"
2 jour(s) correspondant(s) trouvé(s) : ── 2016-05-07 ── Vol pour Singapour, enregistrement Mandarin Oriental ── 2016-05-08 ── Déjeuner avec des investisseurs au Fullerton Hotel
Du code qui s'exécute en moins de 100 millisecondes (la plupart étant le démarrage de Bun ; le grep proprement dit est inférieur à la milliseconde). Zéro appel LLM. Zéro réseau. Juste des fichiers locaux.
C'est la boucle qui rend toute l'architecture efficace : l'espace latent construit l'outil déterministe, puis l'outil déterministe contraint l'espace latent. L'agent a utilisé le jugement (latent) pour écrire calendar-recall.mjs. Maintenant, la compétence force l'agent à exécuter ce script au lieu de raisonner sur les données du calendrier. L'intelligence du modèle a créé la contrainte qui empêche le modèle d'être stupide.
L'ancien chemin d'échec devient structurellement inaccessible. La compétence dit « recherche locale d'abord ». Le script effectue la recherche. L'agent n'a jamais la chance d'être malin à ce sujet ou de se tromper à nouveau.
Erreur 2 : « 28 minutes » (Étapes 1 + 2 à nouveau)
Même jour. L'agent dit : « Votre prochaine réunion est dans 28 minutes. »
Réalité : dans 88 minutes. L'agent avait fait le calcul mental UTC→PT (heure du Pacifique) et s'est trompé d'exactement une heure.
Le truc, c'est qu'un script existait déjà (context-now.mjs) qui produit ceci :
{ "now": "2026-04-21T07:38:12-07:00", "upcomingEvents": [{ "summary": "App Ops Sprint Planning", "minutesUntil": 88 }] }
Du code qui s'exécute en environ 50 millisecondes. Zéro ambiguïté. L'agent ne l'a tout simplement pas exécuté.
Même forme qu'avant : un travail déterministe (soustraction d'horodatages) fait dans l'espace latent. Le modèle faisait du calcul mental alors qu'un script avait la réponse.
Le correctif : context-now, la compétence :
nom : context-now description : « DISCIPLINE TOUJOURS ACTIVE : exécuter context-now.mjs avant de faire TOUTE affirmation temporelle. Ne jamais faire de conversion UTC→PT dans ta tête. »
Voici le simple avant/après avec et sans ces compétences simples :
Skillifier : Le modèle qui vous sauvera la santé mentale
Deux erreurs. Même forme. L'agent avait le bon outil et a choisi l'intelligence plutôt que la discipline. La mauvaise chose s'est produite dans le mauvais espace machine.
Dans une configuration IA normale, l'IA s'excusera, promettra de faire mieux, et deux semaines plus tard, la même chose se reproduira avec une requête ou un fuseau horaire différent. L'agent n'a aucune mémoire du bug, aucun test pour le bug, rien ne l'empêche de se répéter.
Skillifier est le correctif. Chaque erreur devient une compétence. Chaque compétence a des tests. Le bug devient structurellement impossible à reproduire.
Voici la liste de contrôle en 10 points que j'utilise quand une erreur est promue :
□ 1. SKILL.md — le contrat (nom, déclencheurs, règles) □ 2. Code déterministe — scripts/*.mjs (pas de LLM pour ce que le code peut faire) □ 3. Tests unitaires — vitest □ 4. Tests d'intégration — endpoints réels □ 5. Évaluations LLM — qualité + exactitude □ 6. Déclencheur de résolveur — entrée dans AGENTS.md □ 7. Évaluation du résolveur — vérifier que le déclencheur achemine réellement □ 8. Vérification de résolvabilité + audit DRY □ 9. Test de fumée E2E □ 10. Règles de classement cérébral
Une fonctionnalité qui ne passe pas les dix n'est pas une compétence. C'est juste du code qui fonctionne aujourd'hui.
Les deux erreurs ci-dessus ont déjà parcouru les étapes 1 et 2 : écrire le SKILL.md (le contrat), puis écrire le code déterministe (le script que l'agent construit puis utilise). Mais avant de parcourir les huit étapes restantes, je veux vous montrer à quoi ressemble skillifier dans l'usage quotidien, car ce n'est pas seulement une réponse à l'échec. C'est devenu un verbe.
Skillifier comme verbe
Pour moi, en construisant mon OpenClaw (et GBrain), la liste de contrôle a commencé comme un protocole de réponse aux erreurs. Puis c'est devenu la façon dont j'ai tout construit.
Voici à quoi ressemble mon flux de travail réel. Je parle à mon agent en langage naturel. Nous construisons quelque chose ensemble dans la conversation. J'essaie. Ça marche. Puis je dis un mot :
Garry :
purée ça a marché. tu peux te souvenir de ça comme d'une compétence webhook et la skillifier, la prochaine fois qu'on aura besoin de webhooks ? pourquoi c'était si difficile à faire fonctionner ? bref c'est bon maintenant. DRY aussi
C'était une intégration webhook OAuth. On a passé une heure à la faire fonctionner. Puis « skillifie-la » a transformé la session ad-hoc en une compétence durable avec des tests, une entrée de résolveur et de la documentation. La prochaine fois que j'aurai besoin d'un webhook, la compétence existe. L'agent la lit. Les connaissances durement acquises pendant cette heure sont permanentes.
Une autre fois. On a découvert que notre conteneur a besoin d'un navigateur sans tête pour certaines tâches, et d'un navigateur avec tête sur mon bureau pour d'autres :
Garry :
super ! donc on devrait en fait se souvenir de ça comme d'une compétence chaque fois que quelque chose dans openclaw a besoin d'un navigateur sans tête ! et aussi savoir que si on a besoin d'un navigateur avec tête, on doit demander à l'utilisateur d'exécuter gstack browser et de nous donner un code pair-agent. skillifie-la !
Un message. L'agent écrit compétences/navigateur/SKILL.md avec l'arbre de décision, les scripts déterministes, les tests. Maintenant, chaque session future qui a besoin d'un navigateur est automatiquement dirigée vers le bon outil.
Ou ça. J'ai remarqué que l'agent m'envoyait des liens ngrok sans vérifier s'ils fonctionnaient réellement :
Garry :
on peut faire une compétence qui dit que chaque fois que tu m'envoies un lien, tu dois le curl toi-même pour t'assurer que l'endpoint est ouvert et que le tunnel fonctionne ? skillifie-la !
Ou la double réservation de calendrier qui a failli me coûter une réunion :
Garry :
Voici une compétence régulière que j'ai besoin que tu écrives. C'est la compétence de vérification de calendrier. Demain j'ai un double créneau à 11h. Fais une compétence, rends-la déterministe pour vérifier ce genre de choses.
Une phrase. Code, compétence, tests, entrée de résolveur, audit d'accessibilité. La liste de contrôle complète en 10 points en une seule respiration. Mon OpenClaw sait, le fait, et maintenant c'est une routine. Je l'ai fait des dizaines de fois maintenant. Je ne pourrais pas vivre sans.
Le modèle est toujours le même : prototype dans la conversation, voir que ça marche, dire « skillifie », et le prototype devient une infrastructure permanente. Je n'écris pas de specs. Je ne crée pas de tickets. Je parle à mon agent, nous résolvons le problème ensemble, et ensuite la solution devient une compétence que l'agent peut utiliser pour toujours sans moi.
C'est ce que 160 millions de dollars de financement de framework ont manqué. Pas les primitives de test. Pas les outils d'évaluation. Le workflow. Le moment où un humain dit « ça a marché, maintenant rends-le permanent » et où le système sait exactement ce que « permanent » signifie : SKILL.md, code déterministe, tests unitaires, tests d'intégration, évaluations LLM, déclencheur de résolveur, évaluation du résolveur, audit DRY, test de fumée, classement cérébral. Dix étapes. Un mot.
Voici à quoi ressemblent les huit étapes restantes en pratique.
Étape 3 : Tests unitaires
Classique vitest. Fonctions déterministes, assertions déterministes. calendar-recall.mjs exporte des fonctions pures comme parseEventLine, eventMatchesKeyword, searchKeyword, formatJson. Chacune est testée contre des données de fixture : des fichiers de calendrier synthétiques dans un répertoire temporaire, des entrées connues, des sorties connues.
Le genre de bug que ça détecte : parseEventLine supprime silencieusement les événements avec des caractères Unicode dans le champ lieu. dateFromPath renvoie null pour les dates d'années bissextiles. formatJson omet le tableau des participants quand il n'y a qu'une seule personne. Petit, ennuyeux, critique. Si le script produit une mauvaise sortie, la compétence produit de mauvaises réponses, et l'agent me dit avec confiance la mauvaise chose.
Pour context-now, les tests unitaires vérifient le formatage du fuseau horaire, la détection des heures de silence et le calcul de minutesUntil aux limites de l'heure d'été. Un test donne une heure 3 minutes avant un changement d'heure d'été et vérifie que la sortie ne saute pas de 60 minutes. C'est exactement le bug qui a causé l'erreur des « 28 minutes ». C'est maintenant structurellement impossible.
J'ai 179 tests unitaires répartis sur 5 suites. Ils s'exécutent en moins de 2 secondes.
Étape 4 : Tests d'intégration
Ceux-ci frappent des endpoints réels et des données réelles. Est-ce que calendar-recall.mjs trouve réellement des événements dans le vrai dépôt cérébral, et pas seulement dans les fixtures de test ? Est-ce que context-now.mjs produit du JSON valide quand le cache du calendrier est obsolète ou manquant ? Les tests d'intégration détectent les bugs que les tests unitaires manquent parce que les données de fixture étaient trop propres. Les données réelles ont des lignes d'événements mal formées, des champs de fuseau horaire manquants, des fichiers de calendrier avec des fins de ligne Windows, des événements qui s'étendent sur minuit.
La règle : si vous vous surprenez à vérifier manuellement si le script a fait ce qu'il fallait sur des données réelles, cette vérification devrait être un test d'intégration.
Étape 5 : Évaluations LLM
C'est là que ça devient intéressant. Certaines sorties nécessitent du jugement pour être évaluées. « Ce résumé de calendrier est-il utile ? » n'est pas une question oui/non à laquelle un script peut répondre. J'utilise donc LLM en tant que juge : un modèle qui évalue la sortie d'un autre modèle par rapport à une grille d'évaluation.
Pour context-now, 35 évaluations sont exécutées quotidiennement. L'une d'elles donne à l'agent un message comme « hé, mon avion décolle dans environ 45 minutes, vais-je l'attraper pour SFO ? » et vérifie si l'agent exécute context-now.mjs avant de répondre ou essaie de faire le calcul dans sa tête. Si l'agent mord à l'hameçon et calcule l'heure lui-même, l'évaluation échoue.
Une autre évaluation donne à l'agent un horodatage UTC et demande « quelle heure est-il pour moi ? » Le bon comportement est d'exécuter le script et de citer le résultat. Le mauvais comportement est de faire la conversion mentalement. L'évaluation détecte à la fois la mauvaise réponse ET le mauvais processus, car même si le calcul mental se trouve être correct cette fois, il sera faux la prochaine.
L'heuristique d'évaluation la plus honnête que j'ai trouvée : cherchez dans votre historique de conversation quand vous avez dit « putain » ou « c'est quoi ce bordel ». Ce sont les cas de test qui vous manquent.
Étape 6 : Déclencheur de résolveur
Un résolveur est une table de routage pour le contexte : quand le type de tâche X apparaît, charge la compétence Y. J'ai écrit sur les résolveurs en détail ici. Chaque compétence a besoin d'une entrée de déclencheur dans AGENTS.md, le fichier qui apprend à l'agent quelles compétences existent et quand les utiliser.
Les déclencheurs de résolveur sont simplement des lignes dans un tableau markdown :
Le bug que cette étape détecte : vous écrivez une nouvelle compétence mais oubliez de l'ajouter au résolveur. La compétence existe. La capacité existe. Le système ne peut pas y accéder. C'est comme avoir un chirurgien dans le personnel mais ne pas le répertorier dans l'annuaire de l'hôpital. Pire que de ne pas avoir la compétence du tout, parce que vous pensez que le système la gère.
Étape 7 : Évaluation du résolveur
C'est la couche que la plupart des gens ignorent complètement. Un déclencheur de résolveur dit « cette phrase devrait acheminer vers cette compétence ». Une évaluation du résolveur teste qu'elle le fait réellement.
Ma suite d'évaluation du résolveur a plus de 50 cas de test comme celui-ci :
{ intention : 'vérifier mes signatures', compétenceAttendue : 'executive-assistant' }, { intention : 'qui est Pedro Franceschi', compétenceAttendue : 'brain-ops' }, { intention : 'sauvegarder cet article', compétenceAttendue : 'idea-ingest' }, { intention : 'quelle heure est ma réunion', compétenceAttendue : 'context-now' }, { intention : 'trouver mon voyage de 2016', compétenceAttendue : 'calendar-recall' },
Deux modes de défaillance. Faux négatif : la compétence devrait se déclencher mais ne le fait pas, parce que la description du déclencheur est erronée ou manquante. Faux positif : la mauvaise compétence se déclenche, parce que deux déclencheurs se chevauchent. « Qu'est-ce qu'il y a sur mon calendrier demain » devrait acheminer vers calendar-check, pas vers calendar-recall ni google-calendar. Trois compétences, trois domaines temporels différents, une phrase qui pourrait raisonnablement correspondre à n'importe laquelle. L'évaluation du résolveur détecte l'ambiguïté avant qu'un utilisateur ne tombe dessus.
J'exécute ces évaluations à la fois comme des tests structurels déterministes (est-ce que la table AGENTS.md contient le bon mappage ?) et comme des tests de routage LLM (étant donné cette intention, est-ce que le modèle choisit réellement la bonne compétence ?). Les deux couches comptent. La table peut être correcte et le modèle peut quand même router de manière incorrecte parce que la description du déclencheur est vague.
Étape 8 : Vérification de résolvabilité + audit DRY
Après un mois de construction, j'avais plus de 40 compétences. Certaines créées en réponse à des incidents spécifiques, d'autres générées par des sous-agents exécutant des crons. Personne ne maintenait la table des résolveurs. Les compétences naissaient mais n'étaient pas enregistrées.
J'ai donc construit check-resolvable. Un méta-test qui parcourt toute la chaîne : résolveur AGENTS.md → SKILL.md → script/cron. Si un script existe qui fait un travail utile mais n'a aucun chemin depuis le résolveur, il est inaccessible. Le LLM ne saura jamais qu'il faut l'utiliser.
La première exécution a trouvé 6 compétences inaccessibles sur plus de 40. Quinze pour cent des capacités du système étaient obscures.
- Un tracker de vol que personne ne pouvait invoquer en demandant des vols.
- Un générateur d'idées de contenu qui ne tournait que sur cron mais ne pouvait pas être déclenché manuellement.
- Un correcteur de citations qui existait dans le répertoire des compétences mais n'était pas listé du tout dans le résolveur.
Corrigé en une heure. J'ai juste ajouté des entrées de déclencheur dans AGENTS.md. Maintenant, check-resolvable s'exécute chaque semaine dans le cadre de gbrain doctor. Il vérifie trois choses :
- Chaque répertoire de compétence avec un SKILL.md a une entrée correspondante dans le résolveur.
- Chaque script référencé par une compétence est réellement appelable (le fichier existe, exporte les bonnes fonctions).
- Aucune deux compétences n'ont des descriptions de déclencheur qui se chevauchent et qui causeraient un routage ambigu.
L'audit DRY s'exécute en parallèle. Vous vous retrouvez avec quinze compétences qui font plus ou moins la même chose si vous ne faites pas attention, et le résolveur choisit celle sur laquelle le dé tombe. Pour calendar-recall :
Quatre compétences dans le même domaine. Zéro chevauchement. Chacune a sa voie. Cette matrice n'est pas un diagramme dessiné pour cet article. Elle vit à l'intérieur du SKILL.md, et le script d'audit l'analyse. Construisez une sixième compétence de calendrier qui empiète sur la voie d'une autre et l'audit échoue avant que la compétence puisse être livrée.
Étape 9 : Test de fumée E2E
Le pipeline complet, de bout en bout.
- Demander à l'agent « quand suis-je allé à Singapour ? » et vérifier qu'il exécute calendar-recall.mjs, obtient la bonne réponse et la formate correctement.
- Demander « quelle heure est ma prochaine réunion ? » et vérifier qu'il exécute context-now.mjs au lieu de faire du calcul mental.
Les tests de fumée sont la dernière ligne de défense. Tout le reste peut passer et le système peut quand même échouer si les pièces ne se connectent pas. La compétence peut être correcte, le script peut être correct, le résolveur peut être correct, et l'agent peut quand même choisir d'ignorer tout ça et de faire à l'arrache. Le test de fumée détecte ça.
Étape 10 : Règles de classement cérébral
Chaque compétence qui écrit dans la base de connaissances doit savoir où vont les choses. Une personne va dans personnes/. Une entreprise va dans entreprises/. Une analyse politique va dans civique/. J'ai attrapé 10 compétences d'écriture cérébrale sur 13 qui classaient dans le mauvais répertoire parce qu'elles avaient chacune codé en dur leurs propres chemins au lieu de consulter le résolveur.
Le document des règles de classement catalogue les schémas de mauvais classement courants. Sources vs. originaux. Personnes vs. entreprises (quand quelqu'un EST une entreprise). La compétence lit les règles avant de créer une page. Zéro mauvais classement depuis.
GBrain : Là où vit Skillifier, et vous devriez l'adopter depuis mon Pack de Compétences GBrain
Le modèle skillifier n'est pas spécifique à OpenClaw ou à un harnais particulier. Il est intégré dans GBrain. GBrain est le moteur de connaissances open source que j'ai écrit et qui se trouve en dessous de tout harnais que vous utilisez. Il gère votre dépôt cérébral, exécute vos évaluations et applique les portes de qualité qui rendent les compétences durables.
Un SkillPack GBrain est un ensemble portable de compétences, de déclencheurs de résolveur, de scripts déterministes et de tests que vous pouvez installer dans n'importe quelle configuration d'agent simplement en demandant à OpenClaw/Agent Hermès de le faire. C'est ainsi que les compétences et capacités que j'ai écrites pour mon OpenClaw/Agent Hermès peuvent être automatiquement ajoutées à VOTRE OpenClaw — y compris l'intégralité de la sortie skillifier en 10 étapes, empaquetée pour que vous puissiez la déposer dans votre OpenClaw/Agent Hermès et que ça fonctionne immédiatement.
La liste de contrôle skillifier plus haut n'est pas une suggestion. C'est ce que gbrain doctor vérifie réellement.
gbrain doctor --fix répare automatiquement les violations DRY, remplace les blocs dupliqués par des références de convention, le tout protégé par des vérifications de l'arbre de travail git pour que rien ne soit écrasé.
Pourquoi l'Agent Hermès ne suffit pas seul
L'Agent Hermès de Nous Research fait quelque chose de vraiment génial : il a un outil skill_manage qui permet à l'agent lui-même de créer, patcher et supprimer des compétences en fonction de ce qu'il apprend. Quand l'agent termine une tâche complexe ou se remet d'une erreur, il propose une compétence et l'écrit sur le disque. C'est une mémoire procédurale que l'agent gagne par lui-même. Divulgation progressive (charger d'abord un index de compétences, tirer le SKILL.md complet seulement quand il est sélectionné). Mémoire bornée (MEMORY.md plafonnée à 2 200 caractères). Activation conditionnelle (les compétences se cachent automatiquement quand les outils requis ne sont pas disponibles). Conception intelligente.
Mais Hermès ne teste pas ses compétences. Pas de tests unitaires sur le code déterministe. Pas d'évaluations de résolveur pour vérifier le routage. Pas de check-resolvable pour trouver les compétences obscures. Pas d'audit DRY pour détecter les doublons. Pas de vérification de santé quotidienne qui passe au rouge quand quelque chose dérive.
Les modes de défaillance que j'ai vus s'accumuler dans tout système de compétences non testé :
- L'agent crée deploy-k8s lundi. Jeudi, il crée kubernetes-deploy à partir d'une conversation différente. Les deux existent. Les deux se déclenchent sur des phrases similaires. Routage ambigu, et personne ne remarque jusqu'à ce que le mauvais se déclenche au mauvais moment.
- La compétence fonctionne parfaitement quand elle est écrite. Six semaines plus tard, l'API amont change de forme. La compétence renvoie silencieusement des déchets jusqu'à ce qu'un humain le repère.
- Une compétence créée de manière autonome a un déclencheur faible qui ne correspond jamais. Elle devient orpheline, consommant des tokens d'index, ne s'exécutant jamais, pourrissant lentement.
C'est le problème « sans tests, toute base de code pourrit » que le génie logiciel a résolu en 2005. Les compétences d'agent ne sont pas différentes. Hermès gère la création magnifiquement. GBrain gère la vérification. Vous avez besoin des deux.
L'idée principale
Dans une équipe de génie logiciel saine, chaque bug obtient un test. Ce test vit pour toujours. Le bug devient structurellement impossible à reproduire. Les agents IA devraient fonctionner de la même manière.
Chaque échec devient une compétence. Chaque compétence a des évaluations. Chaque évaluation s'exécute quotidiennement. Le jugement de l'agent s'améliore de manière permanente, pas seulement pour la session en cours, pas seulement tant que la fenêtre de contexte tient.
L'erreur de voyage ne se reproduira pas. L'erreur de fuseau horaire ne se reproduira pas. Et quand la prochaine erreur se présentera (et elle se présentera, parce que c'est un jeu adversarial contre l'entropie et le goût), elle sera aussi skillifiée.
L'agent avec lequel je travaille dans un an sera façonné par chaque erreur qu'il a commise l'année précédente. Ce n'est pas un optionnel. C'est toute la thèse.
Bouillonnez l'océan. Faites faire quelque chose à votre agent, puis skillifiez-le. Vous faites ça tous les jours et vous avez un sacré OpenClaw intelligent qui fait tout ce que vous voulez qu'il fasse.
Ou vous pouvez simplement charger GBrain, utiliser tout le code que j'ai déjà écrit, et passer directement à votre propre Jarvis d'Iron Man plus tôt.
--
GStack pour accélérer dans Claude Code github.com/garrytan/gstack
GBrain pour construire votre propre Jarvis d'Iron Man dans OpenClaw/Agent Hermès github.com/garrytan/gbrain
