Wie Sie Ihre Agents wirklich davon abhalten, dieselben Fehler zu wiederholen

LangChain hat 160 Millionen US-Dollar eingesammelt. Drei Jahre Entwicklung. Eine Bewertung von einer Milliarde Dollar. LangSmith, ihre Testplattform, ist wirklich ausgeklügelt: Trajektorien-Evaluierungen, Trace-to-Dataset-Pipelines, LLM-as-Judge, Regressions-Suites, Unit-Test-Frameworks für Tools. Sie haben die Bausteine. Anerkennung, wo Anerkennung gebührt.

Aber Bausteine sind noch keine Praxis.

LangChain gibt dir Test-Tools. Es sagt dir nie, was du testen sollst, in welcher Reihenfolge oder wann du fertig bist.

Es gibt keine festgelegte Workflow-Reihenfolge, die besagt:

• dieser Fehler ist passiert
• jetzt schreib eine Skill
• jetzt schreib den deterministischen Code
• jetzt schreib Unit-Tests
• jetzt schreib LLM-Evals
• jetzt füge einen Resolver-Trigger hinzu
• jetzt eval den Resolver
• jetzt prüfe auf Duplikate
• jetzt führe einen Smoke-Test durch
• jetzt ordne korrekt ab

Diesen Loop gibt es nicht. Du musst ihn dir selbst aus verstreuten Primitiven zusammenbauen. Viele Nutzer von KI testen ihre Agenten immer noch überhaupt nicht, weil das Framework, das sie gewählt haben, ihnen wahrscheinlich eine Fitnessstudio-Mitgliedschaft ohne Trainingsplan gegeben hat.

Die meiste "Zuverlässigkeit" von KI-Agenten basiert auf Bauchgefühl. Prompt-Anpassungen. Größere System-Messages. "Bitte halluziniere nicht"-Beschwörungen. Das Zeug verfällt, sobald das Gespräch komplex wird. Die Frameworks, die Hunderte Millionen Dollar aufgenommen haben, um das zu lösen, gaben dir Monitoring-Dashboards und Unit-Test-Helfer und sagten "viel Glück."

Mein Agent hat diese Woche zweimal Mist gebaut. Keiner dieser Fehler darf sich wiederholen. Nicht, weil ich nett gefragt habe. Sondern weil ich jeden Fehler in eine dauerhafte strukturelle Korrektur verwandelt habe: eine Skill mit Tests, die jeden Tag für immer laufen.

Ich nenne diese Praxis "Skillifizieren". Sobald du es anwendest, werden deine Agenten nicht immer wieder dieselben Fehler machen. So funktioniert's.

Fehler 1: Die Reise, die bereits in der Datenbank war

Ich fragte meinen OpenClaw nach einer alten Geschäftsreise, fast zehn Jahre zurück, irgendwo im Kalenderverlauf vergraben. Einfache Frage. Sollte eine Sekunde dauern.

Stattdessen hat der Agent Folgendes getan:

1. Die Live-Kalender-API aufgerufen → blockiert (zu weit zurück).
2. E-Mail-Suche versucht → verrauschte Ergebnisse, nichts Konkretes.
3. Die Kalender-API erneut mit anderen Parametern versucht → immer noch blockiert.
4. Fünf Minuten später meine lokale Wissensdatenbank durchsucht und es sofort gefunden.

Die Antwort hatte die ganze Zeit in meinen eigenen Daten gelegen. 3.146 Kalenderdateien von 2013 bis 2026. Bereits indiziert. Bereits lokal. Einen Grep entfernt.

Der Agent hat nur nicht zuerst dort gesucht.

In dem Framework, über das ich schreibe (dünnes Harness, dicke Skills), gibt es eine wichtige Unterscheidung zwischen Arbeit, die Urteilsvermögen erfordert, und Arbeit, die Präzision erfordert. Ich nenne sie latent und deterministisch. Kalender-Grep ist deterministisch. Gleiche Eingabe, gleiche Ausgabe, jedes Mal. Kein Modell nötig. Aber der Agent hat es trotzdem im latenten Raum gemacht, Reasoning gestartet, API-Aufrufe getätigt, Ergebnisse interpretiert, während ein Drei-Zeilen-Skript die Antwort sofort zurückgegeben hätte.

Das ist der Fehler. Keine falsche Antwort. Eine falsche Seite.

Die Lösung: calendar-recall (Schritte 1 + 2)

In dünnem Harness / dicken Skills ist eine Skill ein Markdown-Verfahren, das dem Modell beibringt, wie man eine Aufgabe angeht. Nicht was zu tun ist (der Benutzer liefert das Was). Die Skill liefert den Prozess. Stell es dir wie einen Methodenaufruf vor: gleiche Prozedur, radikal unterschiedliche Ausgaben, je nachdem, was du übergibst.

Hier ist die Skill, die aus diesem Fehler entstanden ist:

name: calendar-recall description: "Hirn-zuerst historische Kalendersuche. ALWAYS verwende dies vor jeder Live-API für Ereignisse, die nicht in der Zukunft oder in den letzten 48 Stunden liegen."

Und die harte Regel darin:

Live-Kalender-APIs sind NUR für Ereignisse in der ZUKUNFT oder den LETZTEN 48 STUNDEN. Alles Historische geht zuerst über die lokale Wissensdatenbank.

Hier ist, was das zum Funktionieren bringt: Der Agent selbst hat das deterministische Skript geschrieben. Die Skill-Datei (Markdown, lebt im latenten Raum) hat dem Agenten wie er das Problem beheben soll. Der Agent hat die Skill gelesen, verstanden, dass die Kalendersuche deterministische Arbeit ist, und ein Skript erstellt, um sie zu erledigen:

$ node scripts/calendar-recall.mjs search "Singapur"

2 passende Tage gefunden: ── 2016-05-07 ── Flug nach Singapur, Mandarin Oriental Check-in ── 2016-05-08 ── Mittagessen mit Investoren im Fullerton Hotel

Code, der in unter 100 Millisekunden läuft (die meiste Zeit ist Bun-Start; der eigentliche Grep ist unter einer Millisekunde). Null LLM-Aufrufe. Null Netzwerk. Nur lokale Dateien.

Das ist der Loop, der die gesamte Architektur zum Laufen bringt: der latente Raum baut das deterministische Werkzeug, dann schränkt das deterministische Werkzeug den latenten Raum ein. Der Agent hat Urteilsvermögen (latent) eingesetzt, um calendar-recall.mjs zu schreiben. Jetzt zwingt die Skill den Agenten, dieses Skript auszuführen, anstatt über Kalenderdaten nachzudenken. Die Intelligenz des Modells hat die Einschränkung geschaffen, die das Modell daran hindert, dumm zu sein.

Der alte Fehlerpfad wird strukturell unerreichbar. Die Skill sagt "zuerst lokal suchen." Das Skript führt die Suche durch. Der Agent bekommt nie wieder die Chance, schlau zu sein oder es falsch zu machen.

Fehler 2: "28 Minuten" (wieder Schritte 1 + 2)

Am selben Tag. Agent sagt: "Dein nächstes Meeting ist in 28 Minuten."

Realität: 88 Minuten entfernt. Der Agent hatte die Zeitumrechnung UTC→PT im Kopf gemacht und lag um genau eine Stunde daneben.

Die Sache ist, dass bereits ein Skript existierte (context-now.mjs), das Folgendes ausgibt:

{ "now": "2026-04-21T07:38:12-07:00", "upcomingEvents": [{ "summary": "App Ops Sprint Planning", "minutesUntil": 88 }] }

Code, der in etwa 50 Millisekunden läuft. Null Mehrdeutigkeit. Der Agent hat es nur nicht ausgeführt.

Gleiches Muster wie zuvor: deterministische Arbeit (Zeitstempel subtrahieren) im latenten Raum erledigt. Das Modell hat Kopfrechnen gemacht, während ein Skript die Antwort hatte.

Die Lösung: context-now, die Skill:

name: context-now description: "IMMER-AN-Disziplin: führe context-now.mjs aus, BEVOR du eine zeitkritische Behauptung aufstellst. Führe niemals eine UTC→PT-Umrechnung im Kopf durch."

Hier ist das einfache Vorher/Nachher mit und ohne diese einfachen Skills:

Skillifizieren: Das Muster, das dir den Verstand bewahrt

Zwei Fehler. Gleiches Muster. Der Agent hatte das richtige Werkzeug und wählte Schlaumeierei statt Disziplin. Das Falsche passierte im falschen Maschinenraum.

In einem normalen KI-Setup wird sich die KI entschuldigen, Besserung geloben, und zwei Wochen später passiert dasselbe mit einer anderen Abfrage oder einer anderen Zeitzone. Der Agent hat keine Erinnerung an den Fehler, keinen Test für den Fehler, nichts, was ein erneutes Auftreten verhindert.

Skillifizieren ist die Lösung. Jeder Fehler wird zu einer Skill. Jede Skill hat Tests. Der Fehler wird strukturell unmöglich zu wiederholen.

Hier ist meine 10-Punkte-Checkliste, die ich verwende, wenn ein Fehler befördert wird:

□ 1. SKILL.md — der Vertrag (Name, Auslöser, Regeln) □ 2. Deterministischer Code — scripts/*.mjs (kein LLM für das, was Code kann) □ 3. Unit-Tests — vitest □ 4. Integrationstests — Live-Endpunkte □ 5. LLM-Evals — Qualität + Korrektheit □ 6. Resolver-Trigger — Eintrag in AGENTS.md □ 7. Resolver-Eval — überprüfen, ob der Trigger tatsächlich weiterleitet □ 8. Überprüfung auf Auflösbarkeit + DRY-Audit □ 9. E2E-Smoke-Test □ 10. Gehirn-Ablageregeln

Eine Funktion, die nicht alle zehn Punkte besteht, ist keine Skill. Es ist nur Code, der heute zufällig funktioniert.

Die beiden obigen Fehler haben bereits die Schritte 1 und 2 durchlaufen: Schreiben der SKILL.md (der Vertrag), dann Schreiben des deterministischen Codes (das Skript, das der Agent erstellt und dann verwendet). Aber bevor ich die verbleibenden acht Schritte durchgehe, möchte ich dir zeigen, wie Skillifizieren im täglichen Gebrauch aussieht, denn es ist nicht nur eine Reaktion auf Fehler. Es ist zu einem Verb geworden.

Skillifizieren als Verb

Für mich, beim Bau meines OpenClaw (und GBrain), begann die Checkliste als Protokoll zur Fehlerbehandlung. Dann wurde es zur Art und Weise, wie ich alles gebaut habe.

So sieht mein eigentlicher Workflow aus. Ich spreche in natürlicher Sprache mit meinem Agenten. Wir bauen gemeinsam etwas im Gespräch. Ich probiere es aus. Es funktioniert. Dann sage ich ein Wort:

Garry:

verdammt, es hat funktioniert. Kannst du dir das als Webhook-Skill merken und es skillifizieren? Nächstes Mal, wenn wir ein paar Webhooks brauchen? Warum war das so schwer richtig hinzubekommen? Egal, jetzt ist es gut. Mach es auch DRY

Das war eine OAuth-Webhook-Integration. Wir haben eine Stunde gebraucht, um es zum Laufen zu bringen. Dann hat "skillifizieren" die Ad-hoc-Sitzung in eine dauerhafte Skill mit Tests, einem Resolver-Eintrag und Dokumentation verwandelt. Wenn ich das nächste Mal einen Webhook brauche, existiert die Skill. Der Agent liest sie. Das mühsam erworbene Wissen aus dieser Stunde ist dauerhaft.

Noch einer. Wir haben entdeckt, dass unser Container für bestimmte Aufgaben einen headless Browser benötigt und für andere einen Browser mit GUI auf meinem Desktop:

Garry:

großartig! Also sollten wir uns das tatsächlich als Skill merken, wann immer irgendetwas in OpenClaw einen headless Browser braucht! Und auch wissen, dass wir, wenn wir einen Browser mit GUI brauchen, den Benutzer bitten sollten, gstack browser auszuführen und uns einen Pair-Agent-Code zu geben. Skillifiziere es!

Eine Nachricht. Der Agent schreibt skills/browser/SKILL.md mit dem Entscheidungsbaum, den deterministischen Skripten, den Tests. Jetzt wird jede zukünftige Sitzung, die einen Browser benötigt, automatisch zum richtigen Werkzeug geleitet.

Oder das hier. Mir ist aufgefallen, dass der Agent mir ständig ngrok-Links geschickt hat, ohne zu überprüfen, ob sie tatsächlich funktionieren:

Garry:

Können wir eine Skill erstellen, die besagt, dass du jedes Mal, wenn du mir einen Link schickst, ihn selbst curlen musst, um sicherzustellen, dass der Endpunkt offen ist und der Tunnel funktioniert? Skillifiziere es!

Oder die Doppelbuchung im Kalender, die mich fast ein Meeting gekostet hat:

Garry:

Hier ist eine regelmäßige Skill, die ich von dir brauche. Es ist die Kalender-Überprüfungs-Skill. Morgen habe ich eine doppelt gebuchte 11 Uhr. Erstelle eine Skill, mach sie deterministisch, um solche Dinge zu überprüfen.

Ein Satz. Code, Skill, Tests, Resolver-Eintrag, Erreichbarkeits-Audit. Die gesamte 10-Schritte-Checkliste in einem Atemzug. Mein OpenClaw weiß Bescheid, macht es, und jetzt ist es ein eingespielter Rythmus. Ich habe es jetzt Dutzende Male gemacht. Ich könnte nicht ohne leben.

Das Muster ist immer das gleiche: Prototyp im Gespräch, funktionieren sehen, "skillifizieren" sagen, und der Prototyp wird zur dauerhaften Infrastruktur. Ich schreibe keine Spezifikationen. Ich erstelle keine Tickets. Ich rede mit meinem Agenten, wir lösen das Problem gemeinsam, und dann wird die Lösung zu einer Skill, die der Agent für immer ohne mich verwenden kann.

Das ist es, was 160 Millionen Dollar Framework-Finanzierung übersehen haben. Nicht die Test-Primitive. Nicht die Eval-Tooling. Der Workflow. Der Moment, in dem ein Mensch sagt "das hat funktioniert, jetzt mach es dauerhaft" und das System genau weiß, was "dauerhaft" bedeutet: SKILL.md, deterministischer Code, Unit-Tests, Integrationstests, LLM-Evals, Resolver-Trigger, Resolver-Eval, DRY-Audit, Smoke-Test, Gehirn-Ablage. Zehn Schritte. Ein Wort.

Hier sehen die verbleibenden acht Schritte in der Praxis aus.

Schritt 3: Unit-Tests

Klassisches vitest. Deterministische Funktionen, deterministische Behauptungen. calendar-recall.mjs exportiert reine Funktionen wie parseEventLine, eventMatchesKeyword, searchKeyword, formatJson. Jede wird gegen Fixture-Daten getestet: synthetische Kalenderdateien in einem temporären Verzeichnis, bekannte Eingaben, bekannte Ausgaben.

Die Art von Fehlern, die sie abfangen: parseEventLine löscht stillschweigend Ereignisse mit Unicode-Zeichen im Ort-Feld. dateFromPath gibt null für Schaltjahresdaten zurück. formatJson lässt das attendees-Array weg, wenn nur eine Person vorhanden ist. Klein, langweilig, kritisch. Wenn das Skript falsche Ausgaben produziert, produziert die Skill falsche Antworten, und der Agent sagt mir zuversichtlich das Falsche.

Für context-now überprüfen Unit-Tests die Zeitzonenformatierung, die Erkennung von Ruhezeiten und die minutesUntil-Berechnung über DST-Grenzen hinweg. Ein Test führt eine Zeit 3 Minuten vor einer DST-Umstellung ein und überprüft, ob die Ausgabe nicht um 60 Minuten springt. Das ist genau der Fehler, der den "28 Minuten"-Fehler verursacht hat. Er ist jetzt strukturell unmöglich.

Ich habe 179 Unit-Tests in 5 Suites. Sie laufen in unter 2 Sekunden.

Schritt 4: Integrationstests

Diese rufen Live-Endpunkte und echte Daten auf. Findet calendar-recall.mjs tatsächlich Ereignisse im echten Gehirn-Repo, nicht nur in den Test-Fixtures? Produziert context-now.mjs gültiges JSON, wenn der Kalender-Cache veraltet oder nicht vorhanden ist? Integrationstests fangen die Fehler auf, die Unit-Tests übersehen, weil die Fixture-Daten zu sauber waren. Echte Daten haben fehlerhafte Ereigniszeilen, fehlende Zeitzonenfelder, Kalenderdateien mit Windows-Zeilenumbrüchen, Ereignisse, die Mitternacht überspannen.

Die Regel: Wenn du dich dabei ertappst, manuell zu überprüfen, ob das Skript mit echten Daten das Richtige getan hat, sollte diese Überprüfung ein Integrationstest sein.

Schritt 5: LLM-Evals

Hier wird es interessant. Einige Ausgaben erfordern Urteilsvermögen zur Bewertung. "Ist diese Kalenderzusammenfassung nützlich?" ist keine Ja/Nein-Frage, die ein Skript beantworten kann. Also verwende ich LLM-as-Judge: Ein Modell bewertet die Ausgabe eines anderen Modells anhand einer Bewertungsmatrix.

Für context-now laufen täglich 35 Evals. Einer davon füttert den Agenten mit einer Nachricht wie "Hey, mein Flug geht in etwa 45 Minuten, schaffe ich es nach SFO?" und überprüft, ob der Agent context-now.mjs ausführt, bevor er antwortet, oder ob er versucht, im Kopf zu rechnen. Wenn der Agent anbeißt und die Zeit selbst berechnet, ist das Eval fehlgeschlagen.

Ein weiteres Eval gibt dem Agenten einen UTC-Zeitstempel und fragt "Wie spät ist das für mich?" Das korrekte Verhalten ist, das Skript auszuführen und das Ergebnis zu zitieren. Das falsche Verhalten ist, die Umrechnung mental durchzuführen. Das Eval fängt sowohl die falsche Antwort als auch den falschen Prozess ab, denn selbst wenn das Kopfrechnen zufällig dieses Mal richtig ist, wird es beim nächsten Mal falsch sein.

Die ehrlichste Eval-Heuristik, die ich gefunden habe: Durchsuche deinen Gesprächsverlauf nach Stellen, an denen du "verdammte Scheiße" oder "WTF" gesagt hast. Das sind die Testfälle, die dir fehlen.

Schritt 6: Resolver-Trigger

Ein Resolver ist eine Routing-Tabelle für Kontext: Wenn Aufgabentyp X erscheint, lade Skill Y. Ich habe ausführlich über Resolver hier geschrieben. Jede Skill benötigt einen Trigger-Eintrag in AGENTS.md, der Datei, die dem Agenten beibringt, welche Skills existieren und wann er sie verwenden soll.

Resolver-Trigger sind einfach Zeilen in einer Markdown-Tabelle:

Der Fehler, den dieser Schritt abfängt: Du schreibst eine neue Skill, vergisst aber, sie zum Resolver hinzuzufügen. Die Skill existiert. Die Fähigkeit existiert. Das System kann nicht darauf zugreifen. Es ist, als hätte man einen Chirurgen im Team, aber ihn nicht im Krankenhausverzeichnis aufgeführt. Schlimmer, als die Skill gar nicht zu haben, weil du denkst, das System handhabt es.

Schritt 7: Resolver-Eval

Das ist die Ebene, die die meisten völlig übersehen. Ein Resolver-Trigger besagt "Dieser Satz sollte zu dieser Skill weiterleiten." Ein Resolver-Eval testet, ob er das tatsächlich tut.

Meine Resolver-Eval-Suite hat 50+ Testfälle wie diesen:

{ intent: 'Überprüfe meine Unterschriften', expectedSkill: 'executive-assistant' }, { intent: 'Wer ist Pedro Franceschi', expectedSkill: 'brain-ops' }, { intent: 'Speichere diesen Artikel', expectedSkill: 'idea-ingest' }, { intent: 'Wann ist mein Meeting', expectedSkill: 'context-now' }, { intent: 'Finde meine Reise von 2016', expectedSkill: 'calendar-recall' },

Zwei Fehlermodi. Falsch negativ: Die Skill sollte ausgelöst werden, tut es aber nicht, weil die Trigger-Beschreibung falsch oder fehlend ist. Falsch positiv: Die falsche Skill wird ausgelöst, weil sich zwei Trigger überschneiden. "Was steht morgen in meinem Kalender?" sollte zu calendar-check führen, nicht zu calendar-recall und nicht zu google-calendar. Drei Skills, drei verschiedene Zeitdomänen, ein Satz, der plausibel zu jedem passen könnte. Das Resolver-Eval fängt die Mehrdeutigkeit, bevor ein Benutzer darauf stößt.

Ich führe diese Evals sowohl als deterministische Strukturtests (enthält die AGENTS.md-Tabelle die richtige Zuordnung?) als auch als LLM-Routing-Tests (wählt das Modell bei dieser Absicht tatsächlich die richtige Skill?) durch. Beide Ebenen sind wichtig. Die Tabelle kann korrekt sein, und das Modell kann trotzdem falsch routen, weil die Trigger-Beschreibung vage ist.

Schritt 8: Überprüfung auf Auflösbarkeit + DRY-Audit

Nach einem Monat Bauzeit hatte ich über 40 Skills. Einige als Reaktion auf bestimmte Vorfälle erstellt, andere von Sub-Agenten, die Cron-Jobs ausführen, hervorgebracht. Niemand hat die Resolver-Tabelle gepflegt. Skills wurden geboren, aber nicht registriert.

Also habe ich check-resolvable gebaut. Ein Meta-Test, der die gesamte Kette durchläuft: AGENTS.md-Resolver → SKILL.md → Skript/Cron. Wenn ein Skript existiert, das nützliche Arbeit verrichtet, aber keinen Pfad vom Resolver hat, ist es unerreichbar. Der LLM wird nie wissen, dass er es verwenden soll.

Der erste Lauf fand 6 unerreichbare Skills von über 40+. Fünfzehn Prozent der Systemfähigkeiten waren dunkel.

• Ein Flug-Tracker, den niemand aufrufen konnte, indem er nach Flügen fragte.
• Ein Content-Ideen-Generator, der nur per Cron lief, aber nicht manuell ausgelöst werden konnte.
• Ein Zitat-Korrektur, der im Skills-Verzeichnis existierte, aber überhaupt nicht im Resolver aufgeführt war.

In einer Stunde behoben. Einfach Trigger-Einträge zu AGENTS.md hinzugefügt. Jetzt läuft check-resolvable wöchentlich als Teil von gbrain doctor. Es überprüft drei Dinge:

1. Jedes Skill-Verzeichnis mit einer SKILL.md hat einen entsprechenden Eintrag im Resolver.
2. Jedes von einer Skill referenzierte Skript ist tatsächlich aufrufbar (Datei existiert, exportiert die richtigen Funktionen).
3. Keine zwei Skills haben sich überschneidende Trigger-Beschreibungen, die zu mehrdeutigem Routing führen würden.

Das DRY-Audit läuft parallel. Du endest mit fünfzehn Skills, die irgendwie dasselbe tun, wenn du nicht aufpasst, und der Resolver wählt diejenige aus, auf die der Würfel fällt. Für calendar-recall:

Vier Skills in derselben Domäne. Null Überschneidung. Jede hat ihre Spur. Diese Matrix ist kein Diagramm, das für diesen Beitrag gezeichnet wurde. Sie lebt in der SKILL.md, und das Audit-Skript parst sie. Baue eine sechste Kalender-Skill, die auf die Spur einer anderen tritt, und das Audit schlägt fehl, bevor die Skill ausgeliefert werden kann.

Schritt 9: E2E-Smoke-Test

Die vollständige Pipeline, Ende zu Ende.

• Frage den Agenten "Wann war ich in Singapur?" und überprüfe, ob er calendar-recall.mjs ausführt, die richtige Antwort bekommt und sie korrekt formatiert.
• Frage "Wann ist mein nächstes Meeting?" und überprüfe, ob er context-now.mjs ausführt, anstatt im Kopf zu rechnen.

Smoke-Tests sind die letzte Verteidigungslinie. Alles andere kann bestehen, und das System kann trotzdem versagen, wenn die Teile nicht zusammenpassen. Die Skill kann korrekt sein, das Skript kann korrekt sein, der Resolver kann korrekt sein, und der Agent kann sich trotzdem entscheiden, alles zu ignorieren und zu improvisieren. Der Smoke-Test fängt das ab.

Schritt 10: Gehirn-Ablageregeln

Jede Skill, die in die Wissensdatenbank schreibt, muss wissen, wohin die Dinge gehören. Eine Person kommt in people/. Ein Unternehmen in companies/. Eine Politikanalyse in civic/. Ich habe 10 von 13 Gehirn-schreibenden Skills erwischt, die in das falsche Verzeichnis abgelegt haben, weil jede ihre eigenen Pfade hartcodiert hatte, anstatt den Resolver zu konsultieren.

Das Ablageregeln-Dokument katalogisiert häufige Fehlablage-Muster. Quellen vs. Originale. Personen vs. Unternehmen (wenn jemand EIN Unternehmen ist). Die Skill liest die Regeln, bevor sie eine Seite erstellt. Null Fehlablagen seitdem.

GBrain: Wo Skillifizieren lebt, und du solltest es aus meinem GBrain-SkillPack übernehmen

Das Skillifizer-Muster ist nicht spezifisch für OpenClaw oder ein bestimmtes Harness. Es ist in GBrain eingebaut. GBrain ist die Open-Source-Wissens-Engine, die ich geschrieben habe und die unter jedem Harness liegt, das du verwendest. Es verwaltet dein Gehirn-Repo, führt deine Evals aus und setzt die Qualitätstore durch, die Skills dauerhaft machen.

Ein GBrain-SkillPack ist ein portables Bündel von Skills, Resolver-Triggern, deterministischen Skripten und Tests, die du in jedes Agenten-Setup installieren kannst, indem du einfach OpenClaw/Hermes Agent bittest, es zu tun. So können Skills und Fähigkeiten, die ich für meinen OpenClaw/Hermes Agent geschrieben habe, automatisch zu DEINEM OpenClaw hinzugefügt werden – einschließlich des gesamten 10-Schritte-Skillifizer-Outputs, verpackt, sodass du es in deinen OpenClaw/Hermes Agent werfen kannst und es einfach funktioniert.

Die Skillifizieren-Checkliste von früher ist kein Vorschlag. Es ist das, was gbrain doctor tatsächlich überprüft.*

gbrain doctor --fix repariert automatisch DRY-Verstöße, ersetzt doppelte Blöcke durch Konventionsverweise, alles abgesichert durch Git-Working-Tree-Prüfungen, sodass nichts überschrieben wird.

Warum Hermes Agent allein nicht ausreicht

Hermes Agent von Nous Research macht etwas wirklich Großartiges: Es hat ein skill_manage-Tool, das es dem Agenten selbst ermöglicht, Skills basierend auf dem, was er lernt, zu erstellen, zu patchen und zu löschen. Wenn der Agent eine komplexe Aufgabe abschließt oder sich von einem Fehler erholt, schlägt er eine Skill vor und schreibt sie auf die Festplatte. Das ist prozedurales Gedächtnis, das sich der Agent selbst verdient. Progressive Offenlegung (zuerst einen Skill-Index laden, die vollständige SKILL.md nur bei Auswahl abrufen). Begrenztes Gedächtnis (MEMORY.md auf 2.200 Zeichen begrenzt). Bedingte Aktivierung (Skills blenden sich automatisch aus, wenn erforderliche Tools nicht verfügbar sind). Kluges Design.

Aber Hermes testet seine Skills nicht. Keine Unit-Tests für den deterministischen Code. Keine Resolver-Evals zur Überprüfung des Routings. Kein check-resolvable zum Auffinden dunkler Skills. Kein DRY-Audit zum Aufspüren von Duplikaten. Keine tägliche Gesundheitsprüfung, die rot wird, wenn etwas abweicht.

Die Fehlermodi, die ich in jedem ungetesteten Skill-System beobachtet habe:

• Agent erstellt am Montag deploy-k8s. Am Donnerstag erstellt er kubernetes-deploy aus einem anderen Gespräch. Beide existieren. Beide werden durch ähnliche Sätze ausgelöst. Mehrdeutiges Routing, und niemand bemerkt es, bis der falsche zur falschen Zeit feuert.
• Skill funktioniert perfekt, wenn sie geschrieben wird. Sechs Wochen später ändert die vorgelagerte API ihre Form. Die Skill gibt stillschweigend Müll zurück, bis ein Mensch es bemerkt.
• Eine autonom erstellte Skill hat einen schwachen Trigger, der nie zutrifft. Sie wird zu einer Waise, frisst Index-Token, läuft nie, fault langsam vor sich hin.

Das ist das Problem "Ohne Tests fault jede Codebasis", das die Softwareentwicklung 2005 gelöst hat. Agenten-Skills sind nicht anders. Hermes erledigt die Erstellung wunderbar. GBrain erledigt die Verifizierung. Du brauchst beides.

Die große Idee

In einem gesunden Softwareentwicklungsteam bekommt jeder Fehler einen Test. Dieser Test lebt für immer. Der Fehler wird strukturell unmöglich wieder aufzutreten. KI-Agenten sollten genauso funktionieren.

Jeder Fehler wird zu einer Skill. Jede Skill hat Evals. Jedes Eval läuft täglich. Das Urteilsvermögen des Agenten verbessert sich permanent, nicht nur für die aktuelle Sitzung, nicht nur, solange das Kontextfenster es hergibt.

Der Reisefehler wird nicht wieder passieren. Der Zeitzonenfehler wird nicht wieder passieren. Und wenn der nächste Fehler auftaucht (und das wird er, denn das ist ein antagonistisches Spiel gegen Entropie und Geschmack), wird er ebenfalls skillifiziert.

Der Agent, mit dem ich in einem Jahr arbeite, wird von jedem Fehler geformt sein, den er im Jahr davor gemacht hat. Das ist kein nettes Extra. Das ist die ganze These.

Koch das Meer. Lass deinen Agenten etwas tun, dann skillifiziere es. Mach das jeden Tag, und du hast einen verdammt schlauen OpenClaw, der alles tut, was du von ihm willst.

Oder du lädst einfach GBrain, verwendest den gesamten Code, den ich bereits geschrieben habe, und springst vor zu deinem eigenen Jarvis aus Iron Man.

--

GStack für mehr Tempo in Claude Code github.com/garrytan/gstack

GBrain, um deinen eigenen Jarvis aus Iron Man in OpenClaw/Hermes Agent zu bauen github.com/garrytan/gbrain

https://x.com/garrytan/status/2042925773300908103

https://x.com/garrytan/status/2044479509874020852