Labs — interne Agentensysteme

Problem

Ein Projekt vor dem Launch von Anfang bis Ende zu prüfen, ist in einem Ein-Personen-Team das, was am leichtesten ausfällt. "Ich habe drübergeschaut" ist nicht verlässlich, weil die Checkliste im Kopf steht und bei jedem Projekt andere Punkte herausfallen. Der zweite Punkt ist feiner: Einem Sprachmodell zu sagen "prüfe diese Seite" funktioniert nicht. Ein Befund ohne Messgrundlage kommt selbstbewusst und falsch heraus, und die Falschheit zeigt sich erst beim Beheben. Der Wert eines Audits liegt nicht in der Zahl der gefundenen Probleme, sondern darin, dass jedes gefundene Problem echt ist.

Architektur

Die Pipeline läuft der Reihe nach. Ein Scout profiliert das Projekt und entscheidet, ob die bedingten Auditoren nötig sind. Danach läuft das Playwright-Harness parallel: Screenshots, ein Lighthouse-Durchlauf in drei Runden und ein axe-Scan zur Barrierefreiheit. Bei Projekten mit Produktionsreife wird zusätzlich ein echter Build erzeugt. Sind diese Messungen vorhanden, laufen 13 feste und 1 bedingter Auditor parallel — visuelles Design, Interaktion, Conversion, Text, Designsystem, technisches und inhaltliches SEO, Frontend- und Backend-Performance, Barrierefreiheit, Sicherheit, rechtliche Konformität, Datenintegrität und, falls erkannt, Datenvisualisierung. Die Ausgabe jedes Auditors geht in ein eigenes QA-Red-Team; was dort besteht, geht an einen einzigen übergreifenden Reviewer. Ergebnis ist ein Markdown-Bericht mit einer Freigabe-Checkbox neben jedem Befund. Die freigegebenen Korrekturen wendet ein einziger schreibberechtigter Agent an, danach folgt ein Verifikationsdurchlauf.

Zentrale Entscheidungen

1. Das Audit beginnt nach der Messung und ersetzt sie nicht

   Bevor die Auditoren etwas sagen, liegen Playwright-Screenshots, der Median aus drei Lighthouse-Läufen und die axe-Ausgabe bereits vor. Ein Performance-Befund lautet nicht mehr "die Seite wirkt langsam", sondern bezieht sich auf eine gemessene Kennzahl. Für Barrierefreiheit gilt dasselbe: Ein von axe erfasster Verstoß und eine Vermutung des Modells wiegen nicht gleich schwer.

   KompromissDas Aufsetzen des Harness ist in jedem Projekt ein zusätzlicher Schritt, und die Routenkonfiguration wird von Hand geschrieben. In einem Projekt, in dem keine Messung möglich ist — eine Anwendung, die lokal nicht startet oder eine Datenbank braucht — verengt sich die Pipeline, und ein Teil des Audits entfällt.

2. Die Ausgabe jedes Auditors durchläuft ein eigenes Red Team

   Einen Agenten seinen eigenen Befund prüfen zu lassen, funktioniert nicht; er verteidigt seinen eigenen Text. Deshalb gibt es je Auditor einen eigenen QA-Durchlauf, dessen Aufgabe das Finden von Fehlern ist: Halluzination, überhöhte Schweregrade, blinde Flecken. Ein Befund, der nicht besteht, wird höchstens zweimal zurückgeschickt.

   KompromissDie Zahl der Agenten und damit die Kosten verdoppeln sich nahezu, das Audit dauert länger. In einem kleinen Projekt kann dieser Aufwand den Wert des gefundenen Problems übersteigen — deshalb läuft das Kit bei Projekten kurz vor dem Launch, nicht bei jedem Projekt.

3. Schreibrechte hat ein Agent, und sein Umfang steht vorher fest

   Keiner der Agenten, die Befunde erzeugen, darf Dateien ändern. Korrekturen wendet allein der Fix-Applier an, und er darf die Dateiliste der freigegebenen Korrektur nicht verlassen. So wird aus "während des Audits ist etwas kaputtgegangen" nie eine Suche danach, welcher Agent was getan hat.

   KompromissEin offensichtlicher Fehler außerhalb des Umfangs bleibt unbehoben und erfordert einen eigenen Durchlauf. Da alle Sammelkorrekturen durch einen Agenten laufen, entsteht hier der Engpass der Pipeline.

4. Keine Korrektur ohne Freigabe

   Der Bericht kommt mit Markdown-Checkboxen: anwenden, zurückstellen, wird nicht behoben. Die Entscheidung bleibt bei mir, denn manche Befunde sind richtig, für dieses Projekt aber falsch — ein Compliance-Befund in einem frühen Prototyp ist technisch berechtigt und praktisch nicht die nächste Aufgabe.

   KompromissBei einem Bericht mit hundert Punkten kann die Freigabe so lange dauern wie die Arbeit selbst. Sammelfreigaben mildern das, beseitigen es aber nicht; es ist keine vollautomatische Pipeline, und das soll sie auch nicht sein.

Performance

Lighthouse läuft dreimal, je Kennzahl wird der Median genommen — ein einzelner Lauf bildet die Realität besonders bei einem Kaltstart nicht ab. Die Auditoren laufen parallel, sodass die Gesamtdauer der Pipeline von der längsten Kette abhängt, nicht vom langsamsten einzelnen Auditor.

Ergebnisse

Agenten

18 Agenten · 5 Slash-Kommandos · 5 TypeScript-Harness-Skripte

Prüfumfang

13 feste Auditoren + 1 bedingter (wenn ein Dashboard oder eine Chart-Bibliothek erkannt wird)

Verifikationsschicht

Ein Red Team je Agent plus ein übergreifender Reviewer

Architekturgarantie

Schreibrechte hat genau ein Agent, und er kann die freigegebene Dateiliste nicht verlassen

Was ich heute anders machen würde

Den übergreifenden Reviewer hätte ich von Anfang an einbauen müssen. In der ersten Fassung schrieb jeder Auditor seinen eigenen Bericht, und dasselbe Problem kam von drei Agenten mit drei verschiedenen Schweregraden; wer den Bericht las, wusste nicht, welchem er glauben sollte. Dasselbe Muster gibt es auf der Code-Seite dieses Portfolios: Bei Bergaz Operations führte das Belassen der Garantie in der Anwendungsschicht dazu, dass jeder neue Pfad dieselbe Regel neu aufbauen musste. Auch hier machte jeder Auditor seine eigene Deduplizierung, bis sie an einer Stelle zusammengeführt wurde.

Problem

Ich biete statistische Analysen für akademische Arbeiten an, aber Statistik ist nicht mein Fach; Code schon. Diese beiden Tatsachen zusammen haben bestimmt, wie das System gebaut sein muss. Ein Sprachmodell einen p-Wert rechnen zu lassen, erzeugt eine Zahl, die richtig aussieht und es nicht ist — und die Falschheit zeigt sich am Prüfungstisch. Der zweite Punkt ist der Text: Jeder Satz, den das System erzeugt, muss original sein, weil die Ausgabe durch Plagiatsprüfungen läuft und ein kopierter Absatz die gesamte Abgabe zurückweisen lässt.

Architektur

Acht nummerierte Agenten laufen der Reihe nach: Skalen-Bibliothekar, Datenprofiler, Score-Builder, Design-Interpret, Testauswähler, Analyse-Runner, Reporter und Reviewer. Daneben stehen Aufgabenagenten — Diagrammbauer, akademischer Interpret, Diskussionsschreiber, Präsentationsbauer und ein QA-Tor. Die gesamte numerische Arbeit liegt auf der Python-Seite: Datenaufbereitung, Hypothesentests, Normalität, Reliabilitätskoeffizienten, Regressionsdiagnostik und Effektstärken. Das Modell macht genau vier Dinge — Orchestrierung, Testauswahl samt Begründung, Ergebnisdeutung und Berichtstext. Die Pipeline hält an drei Punkten an und wartet auf einen Menschen: Bestätigung der Skalenzuordnung, Bestätigung der Hypothese und Annahme des Abschlussberichts.

Zentrale Entscheidungen

1. Gerechnet wird nie vom Modell

   Jeder p-Wert, F, t, Reliabilitätskoeffizient, jede Korrelation und Regressionsausgabe stammt aus echten Statistikbibliotheken. Eine vom Modell erzeugte Zahl ist nicht verteidigbar, weil ihre Quelle nicht gezeigt werden kann; die Rechnung an eine Bibliothek zu geben, macht jede Zahl der Ausgabe reproduzierbar.

   KompromissJeder Übergang zwischen Modell und Rechnung braucht ein Schema: Was der Agent anfordert und was Python zurückgibt, muss vorher definiert sein. Ein neuer Test bedeutet damit Arbeit auf beiden Seiten — die Pipeline kommt merklich langsamer voran als eine, die mit freiem Text arbeitet.

2. Drei Freigabetore an festen Stellen

   Die Tore sitzen unmittelbar vor den teuersten Fehlern der Pipeline. Ist die Skalenzuordnung falsch, ist jede folgende Rechnung falsch; ist die Hypothese falsch, beantwortet eine korrekte Rechnung die falsche Frage; wird der Bericht ohne Annahme geliefert, sind die Korrekturkosten am höchsten. Fachentscheidungen liegen bei der Kundschaft, die statistische Testauswahl beim System — und die Tore machen diese Trennung sichtbar.

   KompromissDie Pipeline ist nicht vollautomatisch und kann es nicht sein: An drei Punkten wartet sie auf eine Antwort von außen. Kommt die Antwort spät, steht die Arbeit; und ist die Kundschaft nicht in der Lage, diese drei Entscheidungen zu treffen, bewegt sich die Pipeline gar nicht.

3. Originalität ist eine harte Regel, keine Stilfrage

   Satzstrukturen aus einer Quellarbeit, einer Skalenentwicklungsstudie oder einer Vorlagearbeit zu übernehmen, ist verboten; eine korrekte Zitation genügt nicht, auch der umgebende Text darf keine Kopie sein. Die Regel entstand, nachdem in einer Abgabe ein Abschnitt vollständig kopiert war — aus einer Beobachtung, nicht aus Vorsicht.

   KompromissGründliches Umschreiben ist langsamer als direktes Zitieren und erfordert in jedem Durchlauf eine Checkliste. Da Zahlen und bibliografische Angaben unverändert bleiben müssen, kann die Bearbeitung nur an der Sprache ansetzen — der Spielraum ist eng.

4. Berichtskonventionen gelten ab dem ersten Entwurf

   In einer Abgabe waren die Rechnungen korrekt, der Bericht ging aber wegen Formkonventionen in die Überarbeitung. Diese Regeln sind nun in der Pipeline definiert und gelten ab dem ersten Entwurf — nicht als Politur, die man später aufträgt.

   KompromissDie Regeln stammen aus einer einzigen Prüfungssituation und sind nicht an jeder Institution identisch. Bei einer anderen Institution muss das Regelwerk überprüft werden, und das geschieht heute von Hand.

Performance

Die Dauer der Pipeline kommt von den Toren, nicht von der Rechnung: Ein Analyselauf misst sich in Minuten, das Warten auf Freigabe in Tagen. Die Pipeline ist deshalb so geteilt, dass sie während des Wartens an einem Tor den nächsten Schritt vorbereiten kann.

Ergebnisse

Agenten

8 sequenzielle Pipeline-Agenten + 12 Aufgabenagenten

Aktive Entwicklung

22 Commits

Architekturgarantie

Jedes numerische Ergebnis stammt aus Python-Bibliotheken; das Modell rechnet nicht

Architekturgarantie

Ohne alle drei Freigabetore wird kein Bericht ausgeliefert

Was ich heute anders machen würde

Die Originalitätsregel und die Berichtskonventionen habe ich nicht von Anfang an geschrieben; beide kamen hinzu, nachdem eine Abgabe schiefging. Heute würde ich beim Bau einer Pipeline zuerst fragen "wo wird die Ausgabe abgelehnt" und erst danach "wie wird sie erzeugt" — die Ablehnungskriterien formen die Pipeline. Dieselbe Lehre kam aus dem Launch Audit Kit: Auch dort wurde die Verifikationsschicht nachgereicht, und bis dahin war ein Teil der erzeugten Befunde unbrauchbar.