Die meisten KI-Assistenten funktionieren nach dem Prinzip „nutzen und vergessen“. Korrigieren Sie heute eine Gewohnheit, wiederholen sie morgen denselben Fehler. Erklären Sie ihnen letzte Woche den besonderen Arbeitsablauf Ihres Teams, tun sie diese Woche so, als hätten sie nie davon gehört. Jedes Gespräch beginnt bei null. Wie klug das Modell auch ist, es bleibt eine kluge Person mit Amnesie.
Orkas verfolgt etwas anderes: Der Agent soll aus seiner täglichen Nutzung lernen und wiederkehrende Erfahrungen verdichten, damit er sie beim nächsten Mal selbst anwenden kann. Einfach gesagt: Je mehr Sie ihn nutzen, desto nützlicher wird er. Und diese Nützlichkeit entwickelt sich auf Sie zu — Ihre Vorlieben, Ihr Fachgebiet — statt auf etwas, das der Modellanbieter für alle vorgegeben hat.
Dieser Artikel erklärt den Aufbau dieses Mechanismus. Es ist nicht so einfach wie „das Modell soll sich an das Gespräch erinnern“. Dahinter steht eine vollständige Schleife: sich selbst beobachten → entscheiden, ob Reflexion sinnvoll ist → tatsächlich reflektieren → Schlussfolgerungen wiederverwendbar festhalten → beim nächsten Mal wieder nutzen. Wir gehen sie Stück für Stück durch.
Das Wichtigste zuerst: Alles Folgende — sämtliches „Beobachten“, „Aufzeichnen“ und „Reflektieren“ — geschieht vollständig auf Ihrem eigenen Gerät. Laufdaten, Skills und das Selbstverständnis des Agenten liegen lokal als gewöhnliche Dateien vor. Nichts davon wird auf Orkas-Server hochgeladen, nutzerübergreifend analysiert oder zum Modelltraining verwendet. „Selbstweiterentwicklung“ bedeutet, dass ein Programm seine eigenen Laufaufzeichnungen lokal liest und sich lokal verbessert — nicht, dass es Ihre Daten sammelt. Diese Erfahrung verlässt den Rechner nie und dient nur Ihnen auf diesem einen Rechner.
Die Schleife von Anfang bis Ende
echte Nutzung, immer wieder
│ lokal erfasst: welche Tools aufgerufen wurden, Fehler oder nicht, korrigiert oder nicht
▼
Signale sammeln sich an
│ Signale direkt aus dem Gespräch extrahiert; alles bleibt auf dem Gerät
▼
entscheiden, ob reflektiert werden soll
│ gewichtete Bewertung der Signale, Auslösung erst über einem Schwellenwert; Netzwerkstörungen zählen nicht
▼
im Hintergrund reflektieren
│ nicht in jeder Runde, sondern regelmäßig für die Agenten, die die Kriterien erfüllen
▼
auf zwei Ergebnisse verdichten
│ ① wiederverwendbare "Skills" ② ein "Verständnis" von sich selbst
▼
in der nächsten Runde automatisch einbeziehen
└──────────► zurück zum Anfang, weiter geht’sJeder Schritt dieser Schleife hat seine Feinheiten. Am leichtesten geht gerade bei den beiden Schritten etwas schief, die zunächst am einfachsten wirken: wann reflektiert wird und was danach aufgezeichnet wird. Beginnen wir vorn.
Schritt 1: Sich selbst nahezu kostenlos beobachten
Um aus Erfahrung zu lernen, braucht man zunächst „Erfahrung“, die man betrachten kann. Am Ende jedes Agentenlaufs zählt das Programm lokal und unmittelbar einige einfache Fakten zum Lauf: ungefähr wie viele Tools in diesem Durchgang aufgerufen wurden, ob Fehler auftraten, ob sie vorübergehend waren, etwa Netzwerkprobleme, oder echte Fehler, und ob der Nutzer direkt korrigierend eingegriffen hat. Nur eine Handvoll Zähler und Kennzeichen, vollständig auf dem Rechner berechnet, ohne Modellaufruf und ohne Versand.
Das ist wichtig, weil dabei keine Modellkosten entstehen. Diese Werte werden direkt aus dem Gesprächsprotokoll des aktuellen Durchgangs gezählt; es braucht keinen zusätzlichen Modellaufruf zur „Selbstanalyse“. Würde jeder Durchgang einen weiteren Modellaufruf zur Selbstreflexion erfordern, wären Kosten und Latenz untragbar, und der gesamte Mechanismus würde nie ausgeliefert.
Das Kennzeichen „korrigiert oder nicht“ ist durchaus interessant. Es ist ein rein heuristisches lokales Urteil, geschätzt durch den Abgleich einiger Formulierungen in der Nachricht auf Ihrem Gerät — chinesisch etwa „不对“ / „应该是“ / „重新“, englisch wrong, actually, instead. Präzision ist nicht das Ziel: Es ist nur ein Signal, kein Urteil. Gelegentliche Fehlalarme sind akzeptabel, weil es später zusammen mit anderen Signalen gewichtet wird; nichts wird allein darauf entschieden.
Schritt 2: Wann sich Reflexion tatsächlich lohnt
Hier zeigt der gesamte Mechanismus meines Erachtens das meiste handwerkliche Können.
Der naive Ansatz lautet: „Nach N Vorkommnissen einmal reflektieren.“ Das ist jedoch grob: Drei Netzwerk-Zeitüberschreitungen hintereinander und drei Nutzerkorrekturen hintereinander sind offensichtlich nicht dasselbe und sollten nicht gleich behandelt werden. Orkas nutzt eine gewichtete Bewertung mehrerer Signale: Jedes bemerkenswerte Phänomen ist ein Signal mit Gewicht. Die Gewichte der in diesem Durchgang ausgelösten Signale werden summiert. Reflektiert wird erst, wenn die Summe einen Schwellenwert überschreitet, standardmäßig 0.7.
Die wichtigsten Signale sehen ungefähr so aus:
| Signal | Gewicht | Auslösebedingung |
|---|---|---|
| Nutzerkorrektur | 0.9 | In diesem Durchgang wurde eine Nutzerkorrektur erkannt |
| Skill unwirksam | 0.85 | Ein Skill wurde geladen, der Durchgang schlug trotzdem fehl |
| Von einem Fehler erholt | 0.8 | Fehler aufgetreten, letztlich aber erfolgreich abgefangen |
| Bekannte Schwäche aufgetreten | 0.7 | Die Aufgabe traf auf eine in der Selbsteinschätzung vermerkte Schwachstelle |
| Aufgabenkomplexität | 0.5 | Die Zahl der Tool-Aufrufe überschritt einen bestimmten Wert |
Beispiel: Ein Durchgang mit Nutzerkorrektur (0.9) und einer gewissen Komplexität (0.5) ergibt 1.4, deutlich über 0.7, also wird reflektiert. Ein lediglich etwas komplexer Durchgang (0.5) bleibt darunter und wird übersprungen. Die Gewichtung enthält auch ein Werturteil: Eine direkte Nutzerkorrektur erhält mit 0.9 das höchste Gewicht, weil sie das beste Signal-Rausch-Verhältnis liefert. Der Nutzer hat ausdrücklich gesagt, dass etwas falsch ist; daher lohnt sich die Aufzeichnung sehr wahrscheinlich.
Die eine entscheidende Ausnahme
In der gesamten Bewertungslogik gibt es eine Regel, die für mich darüber entscheidet, ob dieser Mechanismus „das Richtige lernt“: Vorübergehende Fehler zählen nie.
Netzwerk-Zeitüberschreitungen, Verbindungsabbrüche, Ratenbegrenzungen — das sind Umgebungsprobleme, keine Defizite der eigenen Fähigkeiten des Agenten. Werden sie nicht ausgeschlossen, passiert etwas Schlechtes: Ein Tool scheitert wegen einer zufälligen Netzwerkstörung, und der Reflexionsmechanismus speichert „Dieses Tool ist unzuverlässig, seltener nutzen“ — oder verstümmelt beziehungsweise löscht sogar einen völlig brauchbaren Skill. Von da an hat der Agent eine falsche Lehre gezogen, die ihn weiter begleitet.
Deshalb schließen die Signale „von einem Fehler erholt“, „Skill unwirksam“ und „bekannte Schwäche aufgetreten“ rein vorübergehende Fehler ausdrücklich aus. Auch der Reflexions-Prompt wiederholt den Hinweis: Netzwerkfehler sind umgebungsbedingt, nicht als Schwächen aufzeichnen, die zugehörigen Skills nicht verändern. Ein sich selbst verbesserndes System sollte nicht langsames Lernen am meisten fürchten, sondern Lernen in die falsche Richtung. Genau davor schützt diese Ausnahme.
Schritt 3: Reflexion im Hintergrund statt vor Ihrer Nase
Eine naheliegende Falle: Sobald „Zeit zur Reflexion“ erkannt wird, sofort anhalten und reflektieren. Dadurch wirkt der Agent, als stottere er gelegentlich und schweife ab, um „über das Leben nachzudenken“ — eine schlechte Nutzungserfahrung.
Orkas verlagert die Reflexion in den Hintergrund, in einen festen Rhythmus. Die Zeitplanregeln sind ungefähr:
- In regelmäßigen Abständen einen Reflexionszyklus starten, etwa alle zwölf oder mehr Stunden.
- Zwischen zwei Reflexionen desselben Agenten eine Mindestpause von einigen Stunden erzwingen, damit es nicht zu häufig geschieht.
- Wenn er aber zu lange nicht reflektiert hat, etwa über eine Woche, eine Reflexion erzwingen, damit sie nicht unbegrenzt aufgeschoben wird.
- Die Anzahl der pro Zyklus ausgewählten Agenten begrenzen, damit nicht zu viel auf einmal geschieht.
Ein kleines Design, das ich besonders mag, heißt Dirty Gate: Zu Beginn eines Zyklus wird zuerst geprüft, ob es seit der letzten Reflexion dieses Agenten etwas Neues gibt — neue Signale oder aktualisierte Gesprächsaufzeichnungen. Hat sich gar nichts verändert, wird er diesmal übersprungen, ohne eine Modellkosten verursachende Reflexion zu verschwenden. Einfach, spart in der Praxis aber viel.
Schritt 4: Wie Reflexion tatsächlich funktioniert
Wenn es wirklich Zeit zur Reflexion ist, läuft es so: Zuerst werden die jüngsten Aktivitäten zu einem „Paket“ geordnet, dann mit einem sorgfältig formulierten Prompt kombiniert und dem Modell zum Lesen und Zusammenfassen übergeben.
Das Paket hat ein Budget: höchstens eine Handvoll neuerer Gespräche, dazu einige Klassen von Systemereignissen, chronologisch ineinander einsortiert und insgesamt unter einem Tokenlimit gehalten, etwa etwas über zehntausend. Nicht der gesamte Verlauf wird hineingeschaufelt — er würde nicht passen, und das Signal-Rausch-Verhältnis wäre schlecht.
Besondere Sorgfalt braucht der Prompt. Er verlangt vom Modell keine „Beschreibungen“, sondern ausführbare Handlungsanweisungen. Der Unterschied wirkt klein und ist enorm wichtig. Vergleichen Sie:
✗ „Die Ausgabe des Agenten ist manchmal zu ausführlich; darauf achten.“
✓ „Bei Antworten auf Family-Office-Fragen niemals mehr als 5 Aufzählungspunkte verwenden.“
✗ „Der Nutzer scheint knappe Ausgaben zu bevorzugen.“
✓ „Bei Antworten im Family-Office-Kontext immer zuerst das Ergebnis nennen, dann die Begründung.“
Der Prompt lenkt das Modell ausdrücklich auf „niemals / immer / wenn-dann“-Strukturen mit konkreten Auslösebedingungen. Der Grund ist praktisch: Eine Notiz wie „auf Kürze achten“ gibt dem Agenten beim nächsten Lesen nichts konkret Ausführbares, während „niemals mehr als 5 Aufzählungspunkte“ direkt befolgt werden kann. Damit Selbstverbesserung nützlich ist, muss das Verdichtete eine wirksame Anweisung sein, keine zutreffende Floskel.
Nach der Reflexion kann das Modell einiges tun: einen Skill erstellen oder ändern, sein Selbstverständnis aktualisieren oder — wenn es in diesem Zeitraum tatsächlich nichts Merkenswertes gibt — einfach „nichts zu speichern“ sagen. Nichts tun zu dürfen ist selbst eine wichtige Designentscheidung: Erzwingen Sie keinen Lernerfolg, sonst häufen Sie nutzloses Rauschen an.
In zwei Dinge verdichtet
Die Ergebnisse der Reflexion landen an zwei Stellen.
Die eine sind Skills. Jeder Skill ist ein Markdown-Dokument mit Metadaten: ein Frontmatter-Block mit Name, Beschreibung, Erstellungs- und Aktualisierungszeit, Anzahl der Änderungen und letzter Nutzung, gefolgt von den eigentlichen Schritten oder Kernpunkten:
---
name: "Weekly Report Export"
description: "Compile this week's data into the standard weekly-report format"
createdAt: "2025-01-01T00:00:00Z"
updatedAt: "2025-01-08T00:00:00Z"
patchCount: 2
lastUsedAt: "2025-01-09T10:00:00Z"
---
## Steps
1. ...
2. ...Skills als Dateien zu speichern ist pragmatisch: Menschen können sie direkt lesen und bearbeiten, statt dass sie in einer undurchsichtigen Datenbank eingeschlossen sind.
Die andere ist das Selbstverständnis. Dieser Teil ähnelt eher einem Memo, das der Agent an sich selbst schreibt, in zwei Teilen: einer notiert „was ich gut kann und worüber ich häufig stolpere“, der andere „welche Vorgehensweisen ich für diesen Nutzer und dieses Fachgebiet entwickelt habe“. Beide haben eine Längenbegrenzung und müssen dadurch knapp bleiben. Nicht länger ist besser, sondern zutreffender. Zu Beginn des nächsten Gesprächs wird dieser Inhalt in den System-Prompt eingefügt, sodass der Agent mit einem „Verständnis seiner selbst“ antritt.
Skills werden nicht nur geschrieben
Wenn man nur Skills erstellt, sammelt sich mit der Zeit ein Schrottplatz an. Deshalb haben Skills einen vollständigen Lebenszyklus.
Neben dem Erstellen ist der häufigere Vorgang tatsächlich das gezielte Ändern: einen kleinen Bereich eines bestehenden Skills anpassen, statt ihn abzureißen und neu zu schreiben. Jede Änderung erhöht einen Zähler und aktualisiert den Änderungszeitpunkt. So kann ein Skill mit Erfahrung allmählich wachsen, statt bei jedem Durchgang vollständig umgeschrieben zu werden.
Auch die Anzahl ist begrenzt. Die Gesamtzahl der Skills ist gedeckelt, etwa auf 200. Ist sie erreicht, verdrängt ein neuer Skill einen alten nach LRU (Least Recently Used, am längsten nicht genutzt). Dabei werden bevorzugt Skills entfernt, die seit ihrer Erstellung nie genutzt wurden. Ein nie gelesener Skill wurde vermutlich schon anfangs nicht richtig abgeleitet und sollte besser Platz machen.
Jedes Mal, wenn der Agent einen Skill liest, wird dessen „letzte Nutzungszeit“ aktualisiert. Dieser Zeitstempel fließt sowohl in die LRU-Entscheidung ein als auch in die lokale Beurteilung, welche Skills tatsächlich verwendet werden und welche nur Platz belegen.
Woran man erkennt, ob ein Skill tatsächlich nützlich ist
Diesen Schritt lassen viele „selbstlernende“ Systeme bequem aus: Es wurde etwas gelernt — aber taugt es etwas? Orkas macht daraus einige lokal berechnete Kennzahlen. Diese dienen ausschließlich dem Weiterentwicklungsmechanismus auf dem Rechner, um zu entscheiden, welcher Skill überarbeitet oder gelöscht wird, und verlassen diesen Rechner ebenfalls nie.
Der Mechanismus: Zu Beginn jedes Durchgangs erscheinen die verfügbaren Skills im Index des System-Prompts — das ist eine „Einblendung“. Liest der Agent in diesem Durchgang tatsächlich einen Skill, ist das ein „Aufruf“. Aus dem Vergleich ergibt sich die erste Kennzahl:
- Aufrufrate = Aufrufe / Einblendungen. Ein Skill, der Tag für Tag unbeachtet bleibt, hat eine niedrige Aufrufrate. Er ist entweder nutzlos oder so beschrieben, dass niemand erkennt, wann er verwendet werden sollte.
- Nachbearbeitungsrate nach Aufruf = Anteil der Fälle, in denen ein Skill aufgerufen wurde, der Nutzer das Ergebnis anschließend aber manuell bearbeitete. Ein hoher Wert bedeutet, dass das Ergebnis nicht ganz dem Geschmack des Nutzers entspricht.
- Unwirksamkeitsrate = Anteil der Fälle, in denen ein Skill aufgerufen wurde, der Durchgang aber mit einem nicht vorübergehenden Fehler endete. Ein hoher Wert deutet darauf hin, dass mit dem Skill selbst etwas nicht stimmt.
Hier zeigt sich die Ausnahme erneut: Bei der Unwirksamkeitsrate zählen vorübergehende Fehler nicht, ebenso wenig Durchgänge, die der Nutzer unterwegs manuell angehalten hat. Ein völlig brauchbarer Skill darf nicht wegen einer einzigen Netzwerkstörung negativ bewertet werden.
Mit diesen wenigen Zahlen werden Skills von „etwas, das sich in einer Blackbox ansammelt“ zu „etwas, das bewertet und optimiert werden kann“. Welcher Skill überarbeitet oder gelöscht wird, ist keine reine Bauchentscheidung mehr.
Die Schleife schließen
Zusammengefügt sieht ein vollständiger Zyklus so aus:
Der Agent bearbeitet echte Aufgaben, zeichnet Laufdaten lokal auf und markiert dabei Signale. Wenn der Reflexionszyklus im Hintergrund fällig wird, wählt er Agenten mit neuen Aktivitäten und abgelaufener Wartezeit aus, ordnet ihre jüngsten Aktivitäten jeweils zu einem Paket und lässt das Modell sie anhand seines aktuellen Selbstverständnisses prüfen: zusammenführen, was zusammengehört; ausmustern, was ausgedient hat; zu neuen Skills verdichten, was sich dafür eignet. Aus der Prüfung entstehen Skills und Selbstverständnis. Im nächsten Gespräch gelangen die Skills in den Prompt-Index und das Selbstverständnis in den System-Prompt. Der Agent tritt mit dem an, was er in der letzten Runde gelernt hat. Diese Runde erzeugt dann neue Kennzahlen und Signale, die wieder an den Anfang zurückfließen.
Die Schleife läuft Runde um Runde weiter. Nicht jede bringt einen dramatischen Sprung, aber die Richtung bleibt dieselbe: Sie besser verstehen und dieselben Fehler seltener wiederholen.
Einige Abwägungen, die benannt werden sollten
Rückblickend sind einige Entscheidungen in diesem Mechanismus entscheidend.
Selbstbeobachtung muss günstig sein. Sie nutzt Kennzahlen ohne Modellkosten. Die tatsächlich teure Reflexion wird in den Hintergrund verlagert, selten ausgeführt und zuerst durch die Änderungsprüfung begrenzt. Wird der teure Teil streng eingegrenzt, kann der gesamte Mechanismus tatsächlich laufen.
Lieber nicht lernen als falsch lernen. Die Ausnahme für vorübergehende Fehler, die Möglichkeit „nichts speichern“ und ausführbare Anweisungen statt vager Beschreibungen weisen alle auf dasselbe Urteil: Für ein sich selbst verbesserndes System ist Lernen in die falsche Richtung viel gefährlicher als langsames Lernen.
Gelerntes muss sichtbar, bearbeitbar und in Ihren Händen sein. Skills sind Klartextdateien, das Selbstverständnis ein Klartextmemo, und die Wirksamkeit von Skills ist anhand von Kennzahlen prüfbar. Alle diese Dateien liegen auf Ihrem eigenen Rechner, nicht in der Cloud. Nirgends eine Blackbox; ein Mensch kann alles jederzeit öffnen und anpassen.
Dem Lernen Grenzen setzen. Anzahlgrenzen, LRU-Verdrängung, Längenlimits — ohne sie wird „kontinuierliches Lernen“ früher oder später zu „kontinuierlichem Aufblähen“. Vergessen, Verwerfen und Beschneiden sind ebenso wichtig wie Erinnern.
Zum Abschluss
Im Kern ergänzt die Selbstweiterentwicklung von Orkas den Agenten um eine langsame Schleife: Die schnelle ist die unmittelbare Antwort in jedem Gespräch; die langsame blickt regelmäßig zurück und verdichtet Erfahrung zu etwas, das beim nächsten Mal nutzbar ist. Schwierig ist nicht, „das Modell zum Erinnern zu bringen“, sondern die leicht übersehenen technischen Entscheidungen: Welche Erfahrungen sind merkenswert, wie vermeidet man Fehlsteuerung durch zufällige Fehler, wie wird Gelerntes wirklich ausführbar, und wie beschneidet man es, bevor es aufbläht?
Zusammen machen diese Entscheidungen aus „wird nützlicher, je mehr Sie es nutzen“ einen tatsächlich laufenden Mechanismus statt eines Werbespruchs. Ein Assistent, der von Ihnen lernt und dabei nicht die falschen Dinge lernt, kommt dem, was die meisten Menschen wirklich wollen, möglicherweise näher als einer, der bloß klüger ist.