Subagents und autonome Abläufe

Subagents und autonome Abläufe

0:00 Im vorigen Modul haben wir mehrere unabhängige Prüfungen auf denselben Diff angesetzt. Technisch stellt sich damit die Frage, wie so etwas eigentlich läuft — und die Antwort heißt Subagents. Damit sind wir bei einem Thema, das derzeit viel Aufmerksamkeit bekommt und bei dem sich Erwartung und Nutzen leicht auseinander entwickeln.

0:19 Meine Einordnung vorweg: Ein zweiter Kontext ist billig und erstaunlich nützlich. Ein zweiter Schreibzugriff auf dieselbe Datei ist es nicht. Zwischen diesen beiden Sätzen liegt das ganze Modul.

Subagents und autonome Abläufe

0:31 Vier Kapitel. Zuerst die Frage, wofür sich Subagents überhaupt eignen — und wofür ausdrücklich nicht. Dann sehen wir uns an, wie man einen definiert; das sind erstaunlich wenige Angaben. Danach die Zuständigkeitsgrenze zwischen dem, der baut, und dem, der auswählt. Und zum Schluss die autonomen Schleifen, bei denen es vor allem darum geht, wann sie anhalten müssen. Am Ende sichern Sie einen solchen Lauf selbst ab.

Geeignete Einsatzfelder für Subagents

0:57 Beginnen wir mit der Einordnung. Ein Subagent ist nichts Magisches — er ist ein eigener Kontext, in dem gearbeitet wird und aus dem nur das Ergebnis zurückkommt. Daraus ergibt sich fast automatisch, wofür er taugt und wo er Ärger macht. Der Nutzen liegt im Lärm. Wenn Sie eine große Codebasis durchsuchen lassen, entstehen Hunderte Zeilen Zwischenergebnis: Treffer, Fehlversuche, Testausgaben, Stapelspuren.

1:22 All das landet im Hauptkontext und verdrängt dort, was Sie eigentlich brauchen. Ein Subagent nimmt diese Arbeit auf einen eigenen Thread und gibt nur das Ergebnis zurück. Der Vergleich: Sie schicken jemanden ins Archiv, statt das Archiv in Ihr Büro zu tragen. Zurück kommt die Antwort, nicht der Aktenberg — und Ihr Schreibtisch bleibt benutzbar.

1:43 Die Faustregel in der Fußzeile fasst die ganze Tabelle zusammen: lesen gern parallel, schreiben lieber nacheinander. Lesende Arbeit ist konfliktfrei — zwei Prüfungen stören einander nicht, egal wie viele Dateien sie öffnen. Schreibende Arbeit ist es nicht. Sobald zwei Threads dieselbe Datei ändern, brauchen Sie Koordination, und die kostet meist mehr, als die Parallelität einbringt.

2:05 Die rechte Spalte ist deshalb keine Verbotsliste, sondern eine Warnung: Wenn Sie das tun, brauchen Sie getrennte Arbeitsbereiche und eine Reihenfolge — und dann fragen Sie sich, ob es den Aufwand wert war. Vier Vorteile, und der dritte ist der, den man nicht sieht. Mit vollem Kontext sinkt die Verlässlichkeit spürbar — das ist ein gut dokumentierter Effekt, und er setzt früher ein, als die großen Zahlen in den Datenblättern vermuten lassen.

2:31 Wer den Hauptkontext frei hält, arbeitet also nicht nur ordentlicher, sondern schlicht mit einem verlässlicheren Werkzeug. Dazu kommt der praktische Punkt: Zusammenfassungen statt Rohdaten, und mehrere Prüfperspektiven gleichzeitig statt nacheinander. Bei vier Review-Linsen ist das der Unterschied zwischen Minuten und einer Viertelstunde.

2:51 Der erste Punkt ist der wichtigste: Der Subagent gibt eine Behauptung zurück, und niemand prüft sie am Code. Eine Zusammenfassung klingt immer plausibel — das ist ihre Aufgabe. Deshalb sollte jeder Befund Datei und Zeile nennen. Der zweite Punkt ist die Kehrseite des Nutzens: Zusammenfassen heißt weglassen, und manchmal ist das Weggelassene der Fehler.

3:11 Der dritte betrifft die Menge — zu viele Threads erzeugen Koordinationsaufwand statt Tempo. Und der vierte ist der technische: Schreibende Threads kollidieren und hinterlassen einen halben Stand.

Subagents definieren

3:23 Kommen wir zur Praxis. Einen eigenen Subagenten zu definieren, ist erstaunlich wenig Arbeit — drei Pflichtangaben, eine Datei. Interessant ist weniger die Syntax als die Frage, welche dieser Angaben tatsächlich über den Nutzen entscheidet. So viel vorweg: Es ist nicht die Modellwahl, und es ist auch nicht der Name. Es sind die zwei Zeilen, die man am liebsten weglässt.

3:47 Eine Datei je Agent, abgelegt entweder im Projekt oder im Benutzerverzeichnis. Pflicht sind drei Dinge: ein Name zum Aufrufen, eine Beschreibung, wann er einzusetzen ist, und die Anweisungen, die sein Verhalten bestimmen. Der Unterschied zwischen Projekt und Benutzerverzeichnis ist derselbe wie bei den Regeldateien: Was das Team teilt, gehört ins Projekt und wird versioniert.

4:08 Was nur Ihre eigene Arbeitsweise betrifft, bleibt bei Ihnen. Diese Trennung sauber zu halten, erspart später die Frage, warum ein Ablauf bei einer Kollegin anders funktioniert. Achten Sie auf zwei Dinge in diesem Beispiel. Erstens die Anweisungen: „Lies nur" steht dort ausdrücklich, obwohl weiter unten auch die Sandbox auf lesend gesetzt ist.

4:29 Das ist kein Doppel — das eine ist die Absicht, das andere die technische Grenze, und beide gehören hin. Zweitens die letzten beiden Anweisungszeilen. Ein Rückgabeformat und eine Obergrenze machen aus einer Prosa-Antwort ein verwertbares Ergebnis. Ohne sie bekommen Sie einen Fließtext, den Sie erst wieder lesen und sortieren müssen — und dann hätten Sie auch selbst suchen können.

4:52 Die Beschreibung wirkt wie Dokumentation, ist aber funktional: Sie entscheidet, wann der Hauptagent diesen Subagenten überhaupt auswählt. Eine vage Beschreibung führt dazu, dass er nie aufgerufen wird — oder immer. Der zweite Punkt ist die Zuständigkeit: Eine enge Beschreibung hält den Agenten bei seiner Aufgabe. Der dritte ist die Stelle, an der lesend oder schreibend festgelegt wird, und der vierte betrifft das Rückgabeformat.

5:17 Kurz gesagt: Diese wenigen Zeilen entscheiden über den praktischen Wert, nicht die Modellwahl darunter. Der erste Punkt ist ein Sicherheitsthema: Ein Subagent ohne ausdrückliche Sandbox-Angabe darf unter Umständen mehr, als Sie beabsichtigt haben. Der zweite ist banal und trotzdem ärgerlich — wenn die Zahl gleichzeitiger Threads nicht gesetzt ist, ist der Rechner belegt, während Sie weiterarbeiten wollen.

5:40 Der dritte betrifft die Pflege: Anweisungen, die die Projektregeln wiederholen, laufen irgendwann auseinander; besser darauf verweisen. Und der vierte ist der, den ich am häufigsten sehe: Der lesende Agent wird für schreibende Arbeit benutzt, weil er gerade da war.

Orchestrierung und Ausführung

5:56 Im dritten Kapitel geht es um eine Zuständigkeitsgrenze, die auf den ersten Blick nach Wortklauberei aussieht und im Betrieb sehr praktisch ist: Wer eine Arbeitseinheit baut, wählt nicht die nächste aus. Sehen wir uns an, warum diese Trennung hilft. Und warum sie auch dann gilt, wenn gar keine Automatik im Spiel ist, sondern ein Mensch die Auswahl trifft.

6:16 Die Ausführung erledigt genau eine Arbeitseinheit: klären, planen, umsetzen, prüfen, Status melden. Punkt. Die Auswahl der nächsten Einheit, die Abhängigkeiten und die Entscheidung über das Weiterlaufen sind eine andere Zuständigkeit. Der Vergleich aus der Werkstatt: Der Monteur baut den Auftrag, den er bekommt. Welcher Wagen als Nächstes auf die Bühne kommt, entscheidet die Annahme — und zwar mit Blick auf alle Aufträge, nicht auf den einen.

6:43 Wer beides vermischt, bekommt einen Monteur, der zwischendurch die Auftragslage sortiert. Die letzte Zeile ist der Kern: Die Ausführung kennt nur ihren Auftrag, die Orchestrierung kennt den Bestand. Das ist keine Einschränkung, sondern der Grund, warum der Endstatus überhaupt auswertbar ist — er bedeutet immer dasselbe. Und lesen Sie unbedingt die Fußzeile: Ohne Orchestrator übernimmt ein Mensch die Auswahl, und das ist ein gültiger Aufbau. In unserem Beispielprojekt ist genau das der Fall.

7:12 Sie brauchen also keine Automatik, um die Trennung zu nutzen — Sie brauchen nur die Klarheit darüber, wer gerade welche Rolle hat. Vier praktische Effekte. Der Endstatus wird auswertbar, weil er immer dieselbe Bedeutung hat — fertig, blockiert, Rückfrage. Abhängigkeiten werden an einer Stelle verwaltet statt in jeder Sitzung neu bedacht.

7:33 Getrennte Arbeitsbereiche — ein eigener Worktree je Einheit — verhindern Konflikte technisch statt nur per Absprache. Und Teilergebnisse lassen sich einzeln zurücknehmen. Der letzte Punkt ist im Zweifelsfall der wertvollste: Wenn eine von vier Einheiten schiefgeht, wollen Sie nicht alle vier verwerfen müssen. Der erste Punkt ist die Vermischung, über die wir gerade gesprochen haben — sie kostet den Fokus der Ausführung.

7:59 Der zweite ist der technische Klassiker: parallele Einheiten, die in dieselben Dateien schreiben. Dagegen hilft die Tabelle aus Modul 6, in der steht, welche Story welche Dateien berührt. Der dritte betrifft die Zusammenführung: Teilergebnisse werden gemerged, ohne einzeln geprüft worden zu sein. Und der vierte ist ein Buchhaltungsproblem — ohne gemeinsames Artefakt weiß niemand, welche Einheit gerade welchen Stand hat.

Grenzen autonomer Schleifen

8:24 Zum Schluss die autonomen Schleifen. Sie sind das, worüber am meisten gesprochen wird, und ich möchte den Blick auf einen bestimmten Aspekt lenken: nicht darauf, was so ein Lauf alles kann, sondern darauf, wann er anhält. Denn genau das entscheidet, ob man ihn verantworten kann. Eine autonome Schleife hat Voraussetzungen: stabile Anforderungen, ein sauberer Arbeitsstand, verfügbare Subagents.

8:47 Fehlt eine davon, startet sie nicht — und das ist eine Funktion, kein Mangel. Wichtiger noch: Sie endet nicht nur mit Erfolg, sondern mit einem von mehreren definierten Blockadezuständen. Ein Lauf, der anhält und sagt „der Intent ist unklar", hat richtig funktioniert. Wer das als Fehlschlag verbucht, wird die Blockadegründe irgendwann abschalten wollen — und hat dann eine Maschine, die weiterläuft, obwohl sie nicht weiß, wohin.

9:14 Fünf Gründe, und drei davon sind Qualitätssicherung in Reinform. Unklarer Intent und Intent-Lücke im Review bedeuten: Die Absicht und das Ergebnis passen nicht zusammen. Fehlgeschlagene Verifikation heißt: Das Ergebnis ist nicht belegbar. Und die Reparaturschleife mit ihrer Obergrenze verhindert das, was Menschen genauso passiert — immer weiter am selben Fehler zu drehen, ohne näherzukommen.

9:37 Die Fußzeile beschreibt den Umgang mit dem heikelsten Fall: Bei einer Intent-Lücke wird zurückgenommen und der Patch zur Prüfung abgelegt. Nichts geht verloren, nichts wird stillschweigend übernommen. Zusätzlich zu den eingebauten Grenzen gibt es die, die Sie selbst setzen — und die sind mindestens so wichtig. Laufzeit und Kosten je Lauf begrenzen, weil beides sonst unbemerkt wächst. Nur lokal committen und das Veröffentlichen beim Menschen lassen.

10:03 Freigabepunkte an den riskanten Stellen setzen statt überall. Und den Rückweg klären, bevor der erste Lauf startet — also wissen, auf welchen Stand Sie zurücksetzen, wenn es schiefgeht. Diese vier Festlegungen kosten zehn Minuten und sind der Unterschied zwischen einem Experiment und einem Risiko. Ihre Aufgabe: Legen Sie für einen unbeaufsichtigten Lauf die Bedingungen fest, unter denen er anhalten muss.

10:27 Voraussetzungen, Abbruchgründe, Kostengrenze, Freigabepunkte — schriftlich. Der Hinweis auf der Folie ist der eigentliche Startpunkt: Prüfen Sie zuerst, welche Ihrer Stories überhaupt stabil genug für so einen Lauf sind. Erfahrungsgemäß ist das die Hälfte oder weniger, und diese Erkenntnis ist wertvoller als jede Konfiguration.

10:47 Eine Story mit einer offenen Fachfrage gehört nicht in eine Schleife, egal wie gut die abgesichert ist. Vier Punkte. Subagents halten Lärm aus dem Hauptkontext und arbeiten am besten lesend. Name, Beschreibung und Anweisungen entscheiden über ihren praktischen Wert — nicht das Modell darunter. Ausführung baut eine Einheit, Orchestrierung wählt die nächste, und diese Trennung macht den Status auswertbar.

11:12 Und eine Schleife ohne definierte Abbruchgründe ist kein Automat, sondern ein Risiko. Im nächsten Modul geht es genau darum weiter: um Rechte, Grenzen und die Frage, was ein Agent überhaupt dürfen sollte.