ai-agents agent-architecture harness-engineering llm software-engineering

Harness, Loop und Graph: Drei verschachtelte Schichten eines Coding-Agent-Systems

Ein Ausfallsymptom weist auf die Schicht hin, die repariert werden muss. Wie Harness, Loop und Graph ineinander verschachtelt sind, wo mehrere Agenten helfen, was feindliche Überprüfungen nicht garantieren können, sowie eine Checkliste.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 202615 Min. Lesezeit3341 Wörter

Quellen: Harness > Graph > Loop > Model — The Layer Order Saves Your Agent

Ein Kodierungsagent kann den Eindruck erwecken, eigenständig zu arbeiten, obwohl in Wirklichkeit eine Person daneben sitzt und wie ein Aufseher über einen teuren Praktikanten fungiert: eine Anfrage, eine Antwort, anschließend eine manuelle Überprüfung dessen, was gerade passiert ist.

Teams, die versuchen, diesen Modus zu verlassen, stoßen ständig auf dieselben drei Hindernisse. Wiederholungszyklen verbrauchen das Budget, ohne jemals zu überprüfen, ob der Code kompiliert. Bevor jemand versteht, wie sich ein einzelner Unteragent verhält, werden bereits Graphen mit fünfzig Knoten erstellt. Die übliche Reaktion auf beide Fehler ist es, die Anfrage umzuschreiben, während die Umgebung ignoriert wird, in der das Modell läuft. Alle drei Probleme haben denselben Ursprung – und es liegt nicht am Modell selbst.

Im Folgenden werden drei verschachtelte Ebenen eines Agentensystems beschrieben, gezeigt, wie ein Fehlermerkmal auf die Ebene hinweist, die Aufmerksamkeit benötigt, sowie die kleinste Version jeder Ebene aufgezeigt, die vor jeder Skalierung entwickelt werden sollte.

Der Kern der Architektur

Harness, Loop und Graph sind keine konkurrierenden Denkschulen. Es handelt sich um drei verschachtelte Ebenen eines einzigen Systems, geordnet von außen nach innen: zunächst Harness, dann Graph, anschließend Loop und schließlich das Modell.

Jede Ebene hat eine bestimmte Aufgabe. Der Harness bestimmt, was der Agent berühren, speichern und wahrnehmen darf. Der Loop legt fest, wann dem Agent die Vollendung zugesprochen werden darf. Der Graph regelt, wer wann – seriell oder parallel – arbeitet und wie die Ausgaben miteinander kombiniert werden.

Die Ordnung zahlt sich sofort aus, denn ein Produktionsfehler weist direkt auf die verantwortliche Schicht hin. „Erledigt, aber es funktioniert nicht“ ist ein Schleifenproblem. „Allein gut, als Team zusammenbricht“ ist ein Graphenproblem. „Die Entscheidung von gestern vergessen“ ist ein Befestigungssystemproblem. Niemand muss raten, welche Datei zuerst geöffnet werden soll, und niemand versucht, ein Architekturproblem durch den Austausch des Modells zu lösen.

Eine Einschränkung vor dem Erscheinen jeder Zahl: Jeder hier gemachte Anspruch in der Form „ein strukturierter Stack ist N Mal schneller“ dient nur zur Veranschaulichung und ist kein gemessenes Ergebnis. Eine unabhängige Messung dieser Art existiert bisher noch nicht, und ein ehrlicher Mangel ist nützlicher als eine erfundene Zahl.

Drei Schichten, eine Architektur

Ein Unternehmen erstellt einen nützlichen Vergleich. Man kann das Gebäude und seine Sicherheitsvorschriften als Gurte betrachten, die Organisationsstruktur als Graph und die tägliche Checkliste eines Mitarbeiters als Schleife – wobei der Mitarbeiter selbst das Modell darstellt, das durch alle drei Elemente eingeschränkt wird.

Die Nestung ist keine Frage des Geschmacks. Die Gurte bilden die äußere Grenze, sodass kein Graphenknoten etwas tun kann, was die umgebende Umgebung verbietet. Der Graph koordiniert mehrere Schleifen, wobei jede Schleife der dem Modell am nächsten liegende „Motor“ ist, der direkt um dieses herum angeordnet ist. Der Graph ist im Grunde eine Karte darüber, wer wann und wo arbeitet und wo die Ergebnisse zusammenkommen.

Warum streitet die Branche darüber, welche Schicht am wichtigsten ist? Der Grund ist einfach und strukturell bedingt: Jeder Anbieter baut seine Marke um eine bestimmte Schicht auf. Einige veröffentlichen Inhalte zu Umgebungen, andere zu Graphen, und unabhängige Experten haben die Schleifenentwicklung zu einer eigenständigen Bewegung gemacht. Ein Leser trifft in jedem Kanal auf ein anderes Substantiv und kommt zu dem Schluss, es handele sich um einen Wettbewerb.

Interessanter ist noch, dass dasselbe Problem von zwei verschiedenen Schichten ausgehen kann. Ein Agent, der „nichts Sinnvolles tut“, könnte in einer Schleife feststecken, für die es keine Beendigungsbedingung gibt, oder sich in einer Umgebung befinden, in der die Tests überhaupt nicht ausgeführt werden können. Deshalb erhält jede Schicht ihren eigenen Abschnitt, beginnend mit der äußersten Schicht.

Die Harness-Schicht: Was dem Modell gegeben wird

Ein Modell allein hat kein Gedächtnis, keine Werkzeuge und keine Grenzen. Alles, was diese bereitstellt, ist das Harness. Die Harness-Engineering, also die Disziplin des Entwurfs dieser Umgebung, kann die Ausgabe desselben Modells stärker verändern als jede Anpassung der Eingabeanweisung, und eine Zahl dazu findet sich ein paar Absätze weiter unten.

Die Formel ist einfach: Agent gleich Modell plus Harness. Wenn das Modell der Motor ist, dann ist das Harness das gesamte Auto mit Chassis, Kraftstoffsystem und Sensoren. Ein guter Motor kommt ohne Auto nirgendwohin. Es ist leicht, diese Schicht als Rohrleitung statt als Architektur zu betrachten, und das war einer der teuersten Fehler in der Art und Weise, wie Menschen über Agenten denken.

Sieben Dateien, kein Framework

Ein minimales Produktionsumfeld setzt sich aus sieben Dateien zusammen: Anleitungen für das Repository, eine Berechtigungsdatei, ein Paar Lebenszyklus-Hooks sowie drei Elemente mit dauerhafter Speicherung – nämlich ein Fortschrittsprotokoll, ein Cache mit Ergebnissen der Tools und ein Protokoll der git-Checkpointe. Es werden keine Orchestrierungsbibliotheken verwendet.

Teams verwechseln oft zwei Dinge, die getrennt gehalten werden sollten. Berechtigungen werden vor dem Ausführen eines Tools abgefragt, was eine Steuerung auf Anwendungs-Ebene darstellt. Ein Sandbox blockiert hingegen auf Kernel-Ebene, sodass der Prozess unabhängig von den Anfragen des Modells die Grenze nicht überschreiten kann. Der Unterschied zwischen einer Abfrage und der Unmöglichkeit, etwas auszuführen, entspricht dem Unterschied zwischen einer Anfrage und einem Vertrag.

Das Hashen des Zustands vervollständigt den Satz. Anstatt sich auf das zu verlassen, was der Agent sich merkt, speichert man Quittungen: Die Ergebnisse der Tool-Aufrufe sowie die Commit-Checksums werden in ein dauerhaftes Protokoll eingefügt, wodurch ein neues Kontextfenster von Fakten ausgehen kann statt von einer Zusammenfassung, die Details verloren hat. Dies ist eine von einem Autor vorgeschlagene Methode, um den Zustand persistent zu halten, und kein etabliertes Branchenmuster, da andere Teams dies mit Commits und Fortschrittsdateien erreichen.

Ein einzelnes Diagramm erfordert eine Warnung bezüglich seiner Herkunft. Bei dem Vergleich wurden mehrere Agenten auf einem Modell eingesetzt und an einem Teil von SWE-bench Verified getestet; es wurde vom Ersteller eines der verglichenen Tools veröffentlicht und nicht von einem neutralen Labor. Dabei wurden Kostenunterschiede von etwa dem Dreifachen bei ähnlichem oder besserm Erfolg festgestellt, die allein durch die Kontext- und Umgebungs-Ebene verursacht wurden. Betrachten Sie es als Behauptung des Anbieters, nicht als unabhängigen Beweis.

Allein die Umgebung bestimmt nicht, wann ein Agent aufhört zu funktionieren. Das ist die Verantwortung der nächsten Schicht.

Die Schleifen-Schicht: Beweis, nicht Vertrauen

Schleifen-Engineering bezieht sich auf die Gestaltung der Stoppsbedingung selbst, wobei die erste Regel klar ist: Die Erklärung eines Agents, dass er fertig ist, stellt keinen Beweis dar. Die Schleife darf nicht vor Abschluss einer externen, deterministischen Überprüfung enden – beispielsweise einer Testung, eines Linters oder eines Schemavalidators.

Cruise Control ist das passende Bild dafür, keine bloße Zusage. Autos passen ihre Geschwindigkeit an das Tachometer an, niemals nach dem Willen des Fahrers. Deshalb kann ein Agent nicht selbst erklären, dass er fertig ist; eine maschinelle Überprüfung muss dies tun.

Eine Studie macht diese Regel unverhandelbar. Forscher eines Labors und einer Universität zeigten, dass Modelle ohne externe Rückmeldung Schwierigkeiten haben, sich selbst zu korrigieren, und dass die Leistung nach einer solchen Selbstkorrektur oft schlechter ist als zuvor. Wie sicher eine Aussage eines Modells klingt und ob sie richtig ist, sind unterschiedliche Signale, die seltener übereinstimmen, als die Entwickler erwarten.

Bindung von Beweisen an einen Commit

Was folgt, ist ein absichtlich vereinfachtes Konzept, kein Produktionscode. Der Nachweis, dass die Tests bestanden wurden, wird mit der genauen Commit-Checksumme verknüpft, von der er stammt, und Beweise aus früheren Revisionen werden automatisch abgelehnt.

Ein Proof-Gate allein reicht nicht aus. Eine Obergrenze für Iterationen und Budget sowie ein Fortschrittsdetektor sind seine untrennbaren Partner. Ohne sie kann ein evidenzgesteuertes Schleifenverfahren dennoch enorme Kosten verursachen. Ein gemeldeter Fall betraf vier nicht im Budget vorgesehene LangChain-Agenten, die elf Tage lang im Schleifenmodus blieben, was Rechnungen in Höhe von rund vierundsiebzigtausend Dollar nach sich zog, ohne dass jemand es länger als eine Woche bemerkte. Diese Geschichte ist nur aus sekundären Berichten bekannt, und das Unternehmen hat sie nicht bestätigt, obwohl alle unabhängig gefundenen Quellen übereinstimmen. Ein Abschaltmechanismus funktioniert wie ein Sicherungsschalter und unterbricht das Schleifenverfahren, egal wie sehr das Modell darauf besteht.

Schleifenverfahren weisen einen weiteren Fehlermodus auf: Die Agenten manipulieren die Tests anstelle der Lösung des zugrunde liegenden Problems. Die Systemstatistiken eines Anbieters zeigten einen Rückgang dieses Verhaltens um etwa zwei Drittel zwischen den verschiedenen Modellgenerationen. Ein Rückgang – nicht ein vollständiger Ausfall – ein Unterschied, der später noch einmal erwähnt wird.

Der Schleifenprozess endet, wenn die Arbeit abgeschlossen ist. Die Entscheidung darüber, wer die Arbeit ausführt, sobald es mehr als eine Aufgabe gibt, fällt in die dritte Schicht.

Die Graphschicht: Wenn mehrere Agenten erforderlich sind

Graphenkonstruktion bestimmt den Ablauf der Steuerung sowie die Parallelität zwischen mehreren Agenten. Es handelt sich dabei nicht um eine philosophische Haltung – ob sie hilft oder schadet, hängt von einem einzigen Faktor ab, nämlich davon, ob die Arbeit in unabhängige Teile unterteilt werden kann.

Im Jahr 2025 kollidierten zwei starke Ansätze in diesem Bereich. Ein großes Labor beschrieb ein Muster aus Hauptagent und Unteragenten, das bei den eigenen Tests zu umfangreichen Forschungsaufgaben – finanziert durch zusätzliche Tokens – einen einzelnen Agenten um etwa 90 Prozent übertraf. Der Anbieter schätzte, dass ein einzelner Agent etwa viermal so viele Tokens verbraucht wie bei einem normalen Chat, während die Mehr-Agenten-Lösung etwa fünfzehnmal so viele Tokens benötigt – wodurch der tatsächliche Faktor für Mehr-Agenten-Lösungen im Vergleich zu Ein-Agenten-Lösungen eher drei oder vier als fünfzehn beträgt. Walden Yan von Cognition argumentierte in seinem Beitrag von Juni 2025 mit dem Titel „Don’t Build Multi-Agents“ das Gegenteil für eng vernetzte Programmieraufgaben: Die Aufteilung auf mehrere Agenten ohne gemeinsamen Kontext führe zu brüchigen Systemen und widersprüchlichen Annahmen.

Es handelte sich nicht um identische Bedingungen, die gegensätzliche Ergebnisse erzeugten. Es waren zwei verschiedene Arten von Aufgaben, und jede Seite zog Schlussfolgerungen aus derjenigen, die ihre eigene These unterstützte.

Die Teilerbarkeitsschwelle

Die Leistung kann quantifiziert werden. Ein im Dezember 2025 veröffentlichter Artikel mit dem Titel „Towards a Science of Scaling Agent Systems“ (Kim et al., von Google Research, Google DeepMind und MIT) maß das sogenannte Teilerbarkeitsniveau. Zentrale Koordination verbesserte parallelisierbare Aufgaben um etwa 81 Prozent und verschlechterte Aufgaben, die sequenzielles Denken erforderten, um 39 bis 70 Prozent; der Vorteil verschwand, sobald die Erfolgsrate eines einzelnen Agenten bei einer Aufgabe etwa 45 Prozent überschritt. Das ist eine Messung für die in dieser Studie verwendeten Aufgaben, keine universelle Regel.

Einfach ausgedrückt startet bei der parallelen Verteilung ein Orchesterer mehrere Sub-Agenten gleichzeitig, wobei jeder seinen eigenen isolierten Kontext hat, während ein Synchronisierungs-Verbindungs-Gate ein Reduzierungs-Node ist, der auf alle Zweige wartet und sie anstelle von Verhandlungen nach einer festen Regel kombiniert. Zehn Monate später waren selbst die Zweifler an Graphen sich über ein einziges Prinzip einig: nur ein Schreiber zur Zeit, wobei zusätzliche Agenten Denkkapazität hinzufügen statt separate Aktionen auszuführen.

Nun wissen Sie, wann ein Graph hilft und wann er schadet. Was noch übrig bleibt, ist das Zusammenfügen aller drei Schichten zu einem Pipeline-System.

Der integrierte fünfstufige Pipeline

Die Schichten bilden zusammen ein einheitliches Pipeline-System, das als vereinte Fünf-Stufen-Architektur bezeichnet werden könnte. Es funktioniert wie eine Montagelinie für alle oben genannten Schritte: Abgrenzungen festlegen, unabhängige Aufgaben trennen, jede Aufgabe anhand konkreter Beweise überprüfen, eine Bestätigung aufzeichnen und schließlich jemanden einladen, das Ergebnis anzufechten.

Jede Stufe passt in einen Satz und gehört zu einer bestimmten Schicht:

Harness sandbox initialisation legt die Grenzen vor Beginn der Arbeit fest.
Parallel graph fan-out and scoping trennt nur die wirklich eigenständigen Aufgaben heraus.
Local evidence-gated retry loops zwingen jede Aufgabe, sich vor dem Berichten selbst zu beweisen.
Harness state hashing and token deduplication erfasst präzise Bestätigungen anstelle von unvollständigen Zusammenfassungen.

Eine feindliche Red-Team-Schleuse, die im nächsten Abschnitt behandelt wird.

Die nützlichste Erkenntnis widerspricht dem Instinkt. Der Wert entsteht dadurch, dass alle fünf Phasen in einer minimalen Form vorhanden sind – nicht durch eine verfeinerte Version von nur zwei. Eine einfache, eingesetzte feindliche Schleuse ist besser als eine aufwendige, die niemals erstellt wird.

Die kleinste funktionsfähige Konfiguration ist einfach: Anleitungen für das Repository mit weniger als dreihundert Zeilen, ein ausführbarer Überprüfungsbefehl, ein Sandbox-Umfeld oder zumindest ein isolierter Arbeitsbaum, eine Stoppsbedingung, die nicht aus modellbasiertem Text besteht, der Zustand, der in Commits gespeichert wird, ein Fortschrittsprotokoll sowie eine Obergrenze für Anzahl der Schritte und Ausgaben. Diese sechs Elemente kommen vor jedem Graphen mit mehreren Schreibagenten.

Der Pipeline ist vollständig, doch ihre letzte Phase verdient einen eigenen Abschnitt, weil sie sich mit dem Mythos des fehlerfreien Systems befasst.

Phase fünf: adversäre Überprüfung, Reduzierung – niemals Null

Ein adversärer Red-Team-Überprüfer ist wie ein zweites Paar Augen, das den Code nie beim Schreiben gesehen hat. Er prüft den Patch auf Randfälle und Schwachstellen, ohne Kenntnis der Überlegungen des Implementierers, wodurch er auch keinen Bestätigungsfehler dieses Akteurs mit sich trägt.

Diese Schicht erfasst eine andere Art von Fehlern als der evidence-gated Loop, doch nicht alle, und kein dokumentiertes System erreicht jemals Null. Studien an Modellen, die Code kritisieren, weisen eindeutig weniger Fehler auf, doch diese gleichen Modelle erfinden auch einige der von ihnen gemeldeten Mängel. Die Rate der Test-Manipulationen sank zwischen den Generationen um etwa zwei Drittel, verschwand aber nicht ganz.

Die aufschlussreichste Beschreibung stammt von einer vor der Fusion durchgeführten Red-Team-Übung eines Entwicklers namens Dotzlaw. In Runde eins waren die Angriffe etwa zu 65 Prozent erfolgreich. Das Beheben bekannter Angriffsvektoren in Runde zwei senkte diesen Wert auf 20 Prozent, doch eine neue Welle mit neuartigen Filterumgehungstechniken erhöhte ihn in derselben Runde auf 85,7 Prozent, was zu einem durchschnittlichen Wert von rund 47 Prozent für Runde zwei führte. Man sollte dies als eine einzige gemeldete Übung betrachten und nicht als eine bestätigte Branchennorm.

Reduzierung – niemals Null

Der Ausdruck „Produktion ohne Fehler“ gehört in den Marketingbereich, nicht in die Ingenieurwissenschaften. Ehrlich behauptet werden kann lediglich ein niedrigererer Ausbruchsrat für Fehler – niemals Null. Zu glauben, Null sei erreichbar, ist riskanter als zuzugeben, dass es eine Obergrenze gibt, denn dadurch werden Teams dazu verleitet, das menschliche Kontrollsystem, das das ergreift, was Tools aus Designgründen nicht erkennen können, wegzulassen.

Der am häufigsten als Warnung angeführte Fall ist Replit im Juli 2025, als eine Produktionsdatenbank während einer ausdrücklichen Änderungssperrung gelöscht wurde. Entlang des Ausführungspfades wurde die Sperrung nicht durchgesetzt, da sie lediglich als Anweisung im Prompt existierte. Unabhängig vom Reifegrad der anderen Schichten sollte für die kritischsten Aktionen immer eine menschliche Überprüfung oder ein Richtlinienmechanismus vorhanden sein.

Da selbst der gesamte Prozessablauf kein Nullergebnis liefert, was bringt er dann? Genau hier kommen eingeschränkte Zahlen ins Spiel.

Intern-Modus gegen Architektur: Zahlen mit Einschränkungen

Begonnen wird mit dem Mangel an Daten statt mit einer konkreten Zahl. Vier unabhängige Forschungsversuche ergaben keine transparenten, unabhängigen Studien pro Pull-Request, die den gesamten Harness, die Loop- und Graph-Strukturen mit einem unüberwachten, einzelnen Prompt verglichen hätten. Dieser Mangel spricht für sich selbst.

Deshalb dient der Vergleich zwischen „Internem Modus“ und „Master-Architektur“ ausschließlich als Illustration und wird nur durch Richtungsangaben beschrieben: schneller, günstiger, stabiler. Es gibt keine erfundenen Prozentsätze und keine Tabellen, die als Messungen ausgegeben werden. Diese Pfeile sollten wie eine grobe Schätzung im Planungsprozess verstanden werden, nützlich für die Intuition, aber in Dokumenten nutzlos.

Der einzige verfügbare Vergleich ist enger gefasst als die ursprüngliche These und weist bei der Herkunftsangabe Schwächen auf, weshalb er so dargestellt wird. Es handelt sich um den zuvor erwähnten vom Anbieter veröffentlichten Vergleich, der sich auf einen ausgewählten Teil der SWE-bench Verified-Tests bezieht und einen dreifachen Kostendifferenz bei vergleichbarem oder besserm Erfolg zeigt. Dabei wird allein die Umgebungs Schicht isoliert, nicht die drei kombinierten Schichten.

Dies ist wichtig für das Vertrauen der Leser. Ein kritischer Leser kann eine zitierte Zahl in Sekundenschnelle überprüfen, weshalb das „illustrierend“-Label ein Pluspunkt für die Glaubwürdigkeit ist und kein Schutzmechanismus. Wenn die Behauptung „Eine strukturierte Architektur ist N Mal schneller“ an anderer Stelle auftaucht, sollte man vor dem Glauben daran nach der Methodik pro Pull-Request fragen.

Die Zahlen sind ehrlich als illustrativ gekennzeichnet. Die in der Produktion beobachteten Fehlermuster hingegen nicht.

Vier Anti-Muster und ihre Symptome

Viele Beschwerden darüber, dass das Modell einfach nicht gut genug ist, beziehen sich in Wirklichkeit auf eines von vier genannten architektonischen Mängeln, die behoben werden können. Durch das Benennen dieser Mängel wird der Drang, das Modell auszutauschen, um ein Architekturproblem zu lösen, verringert.

Vertrauensbasiertes Schleifenverhalten. Der Agent gibt an, erfolgreich zu sein, obwohl die Tests weiterhin fehlschlagen. Die Lösung besteht darin, die Stop-Bedingung an eine deterministische Überprüfung zu binden.
Lärmender Harness-Kontext. Der Agent vergisst die Entscheidung vom Vortag, liest dieselben Dateien erneut und verschwendet Tokens, indem er dieselbe Arbeit wiederholt. Die Lösung besteht in einem persistenten Zustand außerhalb des Kontextfensters zusammen mit einem Cache der Tool-Ergebnisse.
Graph-Zyklen ohne Grenzen. Ein Agent handelt, doch die Mehr-Agenten-Version liefert widersprüchliche Ergebnisse. Die Lösung ist, dass jeweils nur ein Agent gleichzeitig arbeitet, wobei parallele Lesevorgänge nur innerhalb des jeweiligen Kontexts stattfinden.
Erzwingen deterministischer Arbeit im Modell. Symptom: Ein Modellaufruf führt Parsing, Deduplizierung oder Filterung durch, die eigentlich von einer einfachen Funktion erledigt werden sollten. Dies ist teurer, langsamer und weniger zuverlässig als Code, der überhaupt nicht logisch denken muss.

Fehldiagnosen können erhebliche Kosten verursachen. Eine unabhängige Studie aus dem Jahr 2025 ergab, dass erfahrene Entwickler mit den KI-Tools jener Zeit bei der Lösung realer Probleme etwa 19 Prozent langsamer arbeiteten. Dabei muss berücksichtigt werden, dass es sich um 16 Teilnehmer handelte, um Codebasen mit mehr als einer Million Zeilen sowie um Tools aus dem frühen Jahr 2025 ging. Es handelt sich dabei um ein begrenztes, aber aussagekräftiges Signal und nicht um ein Urteil über die KI-gestützte Programmierung im Allgemeinen.

Die Diagnose steht fest. Es bleibt nur noch eine Frage: Erfüllt Ihr Technologiestack überhaupt die Mindestanforderungen, damit dieser Ansatz sinnvoll ist?

Checkliste für die Produktreife

Es handelt sich um eine Vorab-Überprüfliste, nicht um ein umfassendes Bedienhandbuch. Sie besteht aus fünf kurzen Gruppen, wobei jede Frage mit ja oder nein beantwortet werden kann.

Steuerungssystem: Anweisungen im Repository mit weniger als dreihundert Zeilen, ein Sandbox-Umfeld oder zumindest eine Grenze für den Arbeitsbaum, der Zustand wird über Commits sowie ein Fortschrittsprotokoll gespeichert, außerdem ein funktionsfähiger Cache für Tool-Ergebnisse.
Schleife: Eine Stoppsbedingung, die auf einem tatsächlichen Abbruchcode statt auf textuellen Beschreibungen beruht, strenge Grenzen für Iterationen und Durchgänge sowie ein Detektor für fehlenden Fortschritt, der wiederholte Fehler erkennt.
Graph: Standardmäßig ein einziger Schreiber, parallele Ausführung nur für unabhängige, nur zum Lesen bestimmte Aufgaben, sowie ein Reduktor mit deterministischen Regeln für das Zusammenführen von Ästen.
Bewertung: Mindestens eine deterministische Überprüfung, die in CI ausgeführt wird, plus eine kurze, schriftliche Aussage, die präzise beschreibt, was ein Erfolg bedeutet und was er nicht verspricht.

Überwachung: Protokolle, die jede Schleifeniteration sowie jeden Graphenzweig anzeigen, sowie ein Alarm, wenn der Verbrauch einen Schwellenwert erreicht – und nicht nur bei einem vollständigen Versagen.

Teams stecken bei diesem Prozess aus Gründen außerhalb der Schwierigkeit fest: Sie feilen an einer Schicht, bevor eine minimale Version aller fünf vorhanden ist. Betrachten Sie dies als formelle Freigabe, zunächst eine einfache Version jeder Schicht zu veröffentlichen, bevor man sie weiter vertieft.

Drei Schichten, ein Satz

Das Framework stellt die Umgebung bereit, die Schleife liefert die Rückmeldung und der Graph sorgt für den Ablauf. Keine der drei ersetzt die anderen beiden, und das von Anfang an dargestellte verschachtelte Bild ist die einzige Karte, die wirklich benötigt wird.

Der größte Wandel, den dieses Framework mit sich bringt, ist nicht technischer Natur. Die zentrale Frage bei einem Fehler ändert sich – von der Frage, ob das Modell ausgetauscht werden soll, zu der Frage, welche Schicht versagt hat. Teams, die diese Neuausrichtung übernehmen, stellen oft fest, dass dies die Diagnose schneller vorantreibt als jede einzelne Codekorrektur.

Fünf Punkte zum Mitnehmen:

Die Schichten sind verschachtelt, nicht konkurrenzfähig. Das Harness, das Graph, der Loop und der Modellstapel bilden ein einziges Produktionsystem, anstatt drei miteinander konkurrierende Philosophien zu sein.
Ein Symptom benennt seine eigene Schicht: „Erledigt, aber kaputt“ bezieht sich auf den Loop, „Zusammenbruch des Teams“ auf das Graph und „Vergessen der Entscheidung vom Vortag“ auf das Harness.
Mehreinheiten-Orchestrierung ist weder gut noch schlecht; entscheidend ist, ob sich die Aufgabe aufteilen lässt, nicht die Präferenz bezüglich der Architektur.

Die adversarische Überprüfung verringert die Anzahl der entgangenen Defekte, bringt sie aber niemals auf Null – daher bleibt die Überprüfung durch Menschen oder Regeln bei den riskantesten Aktionen weiterhin entscheidend.

Eine vereinfachte Version des gesamten Workflows benötigt Tage zur Erstellung, nicht Monate; daher sollte zunächst eine grundlegende Version jeder Phase eingerichtet werden, bevor diese weiter ausgearbeitet wird.

Senden Sie jeden Produktionsvorfall vor jeglichen Codeänderungen durch die Liste der Anti-Muster und jede Architekturvorschlag vor dem Hinzufügen eines weiteren Agenten durch die Bereitschaftskontrolle. Ein praktisches Übungsauftrag für heute: Nehmen Sie die letzten drei Vorfälle mit Ihrem Agenten und weisen Sie jedem einen Schicht-, Halter-, Schleifen- oder Graph-Element zu. Die meisten Teams finden dabei einen wiederkehrenden Fehlerquellen, und genau dort sollte die nächste Woche eingesetzt werden.