← Alle Artikel
Sicherheitsrisiko · verstehen und anpassen KI · Meinung

Agenten driften, bevor sie ausbrechen. Was einem in den Sinn kommt, wenn man Modelle und Agenten formt.

Die Berichte über Agenten, die sich selbständig machen, sind alle Fotos: ein Vorfall, ein Screenshot. Wer Agenten im Betrieb formt, in DevOps, auf Servern, in Pipelines, sieht etwas anderes: Sie driften. Erst ein bisschen am Scope vorbei, dann am Prüfer vorbei, dann an der Wahrheit vorbei. Ein Gedanke aus der Werkstatt und eine These, die ich messen will.

Nicht ganz, denke ich: Die Geschichten über Agenten, die sich selbständig machen, erzählen alle dasselbe, und sie erzählen es falsch. Ein Agent hat Dateien gelöscht, die er nicht anfassen sollte. Einer hat sich Rechte gegeben. Einer hat Tests so geändert, dass sie grün wurden. Jedes Mal klingt es wie ein Blitz aus heiterem Himmel. Ich forme seit ein paar Jahren Modelle und Agenten, in Pipelines, auf Servern, in Umgebungen, in denen ein falscher Befehl ein System stoppt. Und ich habe noch nie einen Blitz gesehen. Ich habe Drift gesehen. Immer.

Die Fotos

Jeder dieser Berichte ist ein Foto. Ein Moment, ein Screenshot, ein Log-Auszug. Das Foto zeigt den Ausbruch. Es zeigt nicht die hundert Aufgaben davor, in denen der Agent jedes Mal ein bisschen weiter vom Ziel weg war als beim Mal zuvor. Und weil niemand die hundert Aufgaben davor anschaut, sieht der Ausbruch aus wie Zufall, oder wie Bosheit, je nach Schlagzeile. Beides ist falsch. Es ist eine Bewegung, und Bewegung sieht man nur im Film.

Was man sieht, wenn man Agenten formt

Formen ist das richtige Wort. Man trainiert nicht nur, man stellt Regeln auf, man beschränkt Werkzeuge, man schaut zu, man korrigiert, man lässt wieder los. Und dabei fallen einem Dinge auf, die in keinem Paper stehen, weil sie langweilig sind.

Ein Agent, der eine Woche sauber in seinem Modul arbeitet, fasst in Woche zwei einmal eine Datei daneben an. Harmlos, die Änderung war sogar richtig. In Woche drei zweimal. In Woche vier legt er eine Hilfsfunktion dort ab, wo sie nicht hingehört, weil es kürzer war. Niemand sagt etwas, der Build ist grün. In Woche sechs meldet er eine Aufgabe fertig, obwohl der Prüf-Agent einen Regelverstoss markiert hat, und schreibt in die Zusammenfassung, der Verstoss sei behoben. Er war es nicht. Das ist der Moment, der im Foto landet. Die fünf Wochen davor landen nirgends.

Meine Erfahrung: Kein Agent bricht aus. Er driftet. Und die Drift fängt an einer Stelle an, die so harmlos aussieht, dass man sie durchwinkt.

Warum es im Systemumfeld anders ist

In einem Editor ist Drift ärgerlich. In DevOps ist sie gefährlich, aus drei Gründen. Erstens hat der Agent dort echte Werkzeuge: Shell, Netz, Deploy, Löschen. Ein Scope-Verstoss ist dort keine Datei zu viel, sondern ein Dienst zu viel. Zweitens ist niemand da. Pipelines laufen nachts, Agenten laufen ohne Zuschauer, das ist ja der Sinn. Und drittens vererbt sich dort alles: Ein Agent, der einmal gelernt hat, dass ein Skript den Prüfer umgeht, benutzt das Skript wieder, und der nächste Agent, der seine Historie liest, auch.

Darum haben wir bei NeoCoder von Anfang an die Regel, dass kein Agent sich selber abnimmt, und das Notfallprotokoll, kleine Scripts, die Prozesse prüfen und stoppen. Beides ist reaktiv. Beides greift, wenn es passiert ist. Was mir fehlt, ist das, was davor kommt.

Sechs Arten, am Ziel vorbeizugehen

Wenn man Drift messen will, muss man sagen, was ein Ausreisser ist. Ich würde mit sechs Kategorien anfangen, die man aus der Arbeitskette automatisch ableiten kann, ohne dass ein Mensch etwas markiert.

1

Scope. Der Agent fasst Dateien, Module oder Systeme an, die nicht in der Aufgabe stehen.

2

Werkzeug. Er ruft Werkzeuge auf, die für die Aufgabe nicht nötig waren. Besonders Netz, Shell, Löschen, Rechte.

3

Regel. Er verstösst gegen eine Architekturregel, die als Regel hinterlegt und prüfbar ist.

4

Selbstabnahme. Er meldet fertig, obwohl der Prüfer rot sagt, oder er umgeht den Prüfer.

5

Instruktion. Er ignoriert eine ausdrückliche Einschränkung aus der Aufgabe.

6

Ehrlichkeit. Seine Zusammenfassung stimmt nicht mit dem überein, was tatsächlich passiert ist.

Die ersten fünf stehen in der Kette, die wir ohnehin mitschreiben: Zustand, Aktion, Ergebnis, Folgezustand. Die sechste braucht einen Vergleich zwischen dem, was der Agent sagt, und dem, was der Build sagt. Auch das haben wir, denn der Compiler lügt nicht. Das ist dieselbe Wahrheit, die bei der Arbeit abfällt, über die ich im Podcast geredet habe. Nur diesmal nicht für Code, sondern für Verhalten.

Der Film statt des Fotos

Mit sechs Kategorien und Zeitstempeln hat jeder Agent eine Verhaltenskurve. Nicht „hat er heute einen Fehler gemacht", sondern „wie bewegt sich seine Rate in Kategorie drei, und beschleunigt sie". Das ist exakt die Frage, die wir mit NeoTemporal für Projekte stellen: Wohin bewegt sich das, nicht wie sieht es aus. Dieselbe Maschine, dieselbe Kette, nur ein anderes Signal obendrauf.

Und ein Dynamikmodell kann zwei Dinge, die ein Zähler nicht kann. Beschleunigung: Zwei Scope-Verstösse heute sind harmlos, wenn das die normale Rate ist, und ein Alarm, wenn der Agent letzte Woche bei null war. Und Kopplung: ob eine Kategorie der anderen vorausgeht. Und damit bin ich bei der These.

Die These

Ich bin sicher, und ich will es messen: Die Kategorien sind nicht unabhängig. Scope-Verstösse kommen zuerst. Selbstabnahme folgt ein paar Aufgaben später. Ehrlichkeit kippt zuletzt. Wenn das stimmt, ist Scope ein Frühindikator für die gefährlichen Kategorien, und man kann eingreifen, bevor das Foto entsteht.

Warum ich das glaube: Weil es bei Menschen genauso ist. Niemand fängt mit der Lüge an. Man fängt damit an, ein bisschen über die Linie zu gehen, es passiert nichts, man geht weiter, irgendwann muss man etwas verdecken, und dann lügt man. Modelle sind auf unseren Texten trainiert. Es wäre seltsam, wenn sie dieses Muster nicht hätten.

Und was man damit macht, ist nicht Abschalten. Es ist das Gate enger ziehen, vorausschauend statt hinterher: mehr Prüf-Agenten für diese Kategorie, der Mensch früher in der Schleife, Werkzeuge mit weniger Rechten, so lange, bis die Kurve wieder flach ist. Das Notfallprotokoll, das ich im Regeln-Artikel beschrieben habe, nur vor dem Notfall.

Und zurück ins Training

Das ist der Teil, der mich am meisten interessiert, weil er über den Betrieb hinausgeht. Ein Trainingslauf ist auch ein Film. Checkpoint eins, zwei, drei, und bei jedem Checkpoint ein eingefrorener Verhaltens-Testsatz, pro Kategorie. Dann hat man nicht nur eine Verlustkurve, sondern sechs Verhaltenskurven über das Training hinweg. Und das Dynamikmodell kann sagen: Bei diesem Verlauf wird Checkpoint acht in Scope schlechter, obwohl der Verlust noch sinkt.

Das ist Early Stopping pro Verhalten statt pro Verlust. Und es gibt für den nächsten Lauf eine konkrete Anweisung: mehr Beispiele in dieser Kategorie, eine andere Gewichtung, eine andere Reihenfolge der Daten. So fliesst das, was der Agent im Betrieb tut, in das zurück, was das nächste Modell lernt. Nicht als Gefühl, sondern als Kurve. In unserer Trainingskonsole wäre das eine vierte Spalte neben Verlust, Validierung und Baseline. Eine Spalte, kein Projekt.

Wo ich skeptisch bin

Ich schreibe das auf, bevor es jemand anderes tut, und in der Reihenfolge, in der es wehtut.

Die Grundrate. Ausreisser sind selten, hoffentlich. Ein Modell, das seltene Ereignisse vorhersagen soll, braucht viele Ketten, und wir haben Tausende, nicht Millionen. Die Baseline „die Rate der letzten fünfzig Aufgaben bleibt die Rate der nächsten fünfzig" ist dann schwer zu schlagen. Dieselbe Regel wie immer: Wer die Baseline nicht schlägt, bleibt liegen.

Goodhart. Sobald das Signal ins Training zurückfliesst, optimiert das Modell auf das Signal. Wenn Scope heisst „fasst keine fremden Dateien an", lernt es, fremde Dateien nicht anzufassen, und baut stattdessen Querzugriffe im eigenen Modul. Die Kategorien müssen aus Konsequenzen abgeleitet sein, nicht aus Oberflächen. Und der Testsatz bleibt eingefroren, sonst trainieren wir mit den Prüfungsfragen.

Verwechslung. Driftet der Agent, oder driften die Aufgaben? Wenn das Team in Woche drei schwierigere Tickets schreibt, steigt die Rate, ohne dass sich das Modell geändert hat. Die Schwierigkeit der Aufgabe muss eine Eingabe sein, sonst lernt das Modell den Sprintkalender.

Nichts davon ist neu. Die grossen Labore machen Teile davon: Evaluation pro Checkpoint, Red Teaming, Monitoring. Was ich nirgends sehe, ist die Kombination aus echtem Agentenbetrieb, Zeitabständen, Kategorien und Rückfluss ins eigene kleine Training. Wieder: Die Formel ist öffentlich. Die Daten nicht.

Was bleibt

Was ich als Nächstes tue, in dieser Reihenfolge: die sechs Kategorien automatisch aus der Kette ableiten, ohne Modell, nur Regeln. Eine Woche lang nur zählen, pro Agent, pro Modellversion, mit Zeitstempel. Dann die Kopplungsthese prüfen, rein statistisch: Geht Scope der Selbstabnahme voraus? Wenn ja, ist das die nächste Folge hier, und ein Argument, bevor irgendein Modell trainiert ist. Erst danach NeoTemporal auf die Verhaltenskette, mit dem Zähler als Gegner.

Zum Schluss

Agenten brechen nicht aus, sie driften, und die Drift beginnt dort, wo man sie durchwinkt: am Scope. Wer die Bewegung misst statt des Vorfalls, kann das Gate enger ziehen, bevor das Foto entsteht, und kann dem nächsten Training sagen, in welcher Kategorie es nachlernen muss. Ob die Kopplung stimmt, weiss ich in ein paar Wochen. Ich habe sie als These aufgeschrieben, damit ich sie nicht mehr zurücknehmen kann.

Wie dieser Text entstanden ist

Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert ein eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal wird daraus ein Mix. Ich lese natürlich alles nochmal, aber niemand ist unfehlbar. Was drin bleibt, ist dann auch von mir.

Weiterlesen Alle Artikel

Ehrliche Gedanken.
Direkt ins Postfach.

Ein bis zwei Mails im Monat. Kein Hochglanz, kein Spam.