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 unterstütze Forschende mit reproduzierbarer statistischer Analyse. 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 der Fehler zeigt sich meist im spätesten und teuersten Moment, wenn die Forschungsarbeit bewertet wird. Deshalb gibt die Pipeline ein einziges Versprechen: Jede Zahl im Bericht lässt sich bis zu dem Code und der Eingabe zurückverfolgen, die sie erzeugt haben. Was ein Ergebnis bedeutet, deutet die forschende Person selbst, und den Text der Arbeit schreibt sie selbst; die Pipeline ersetzt das nicht.

Architektur

Acht Agenten laufen der Reihe nach: Skalen-Bibliothekar, Datenprofiler, Score-Builder, Design-Interpret, Testauswähler, Analyse-Runner, Reporter und Reviewer. Daneben stehen Aufgabenagenten — etwa ein Diagrammbauer und ein Qualitätstor, das die Ausgabe jeder Stufe mit dem Anliegen der forschenden Person abgleicht. Die gesamte numerische Arbeit liegt auf der Python-Seite: Datenaufbereitung, Hypothesentests, Normalität, Reliabilitätskoeffizienten, Regressionsdiagnostik und Effektstärken. Jedes Ergebnis wird in einen strukturierten Datensatz geschrieben, der festhält, aus welchem Test und welcher Eingabe es stammt; der Bericht übernimmt die Zahlen unverändert aus diesem Datensatz. Das Modell rechnet nicht: Es steuert den Ablauf, schreibt die Begründung für den gewählten Test und überträgt die Ergebnisse in Tabellen nach den Berichtsregeln. Die Pipeline hält an drei Punkten an und wartet auf einen Menschen: Bestätigung der Skalenzuordnung, Bestätigung der Hypothese und Annahme der Ergebnisse samt Prüfnotizen.

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 Freigabepunkte an festen Stellen

   Die Freigabepunkte 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 erstellt, bevor die Ergebnisse angenommen sind, sind die Korrekturkosten am höchsten. Fachentscheidungen liegen bei der forschenden Person, die statistische Testauswahl beim System — und die Freigabepunkte 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 forschende Person nicht in der Lage, diese drei Entscheidungen zu treffen, bewegt sich die Pipeline gar nicht.

3. Jede Zahl ist bis zum erzeugenden Code nachverfolgbar

   Jeder Wert im Bericht stammt aus einem Ergebnisdatensatz, der festhält, welcher Test mit welcher Eingabe lief; der Bericht übernimmt die Zahl unverändert aus diesem Datensatz und tippt sie nie neu ab. Auch Freigaben werden festgehalten — wer sie erteilt hat und auf welcher Datei sie beruhen. Die Antwort auf "woher kommt diese Zahl" ist damit keine Vermutung, sondern eine Datei und ein Schritt. Deutung und Text schreibt die forschende Person; die Pipeline liefert die Zahlen, die Tabellen und deren Herkunft.

   KompromissEin Ergebnis, das nicht in den Datensatz passt, kommt nicht in die nächste Stufe, und schon eine kleine Änderung kann eine Anpassung des Datensatzformats verlangen. Wer von der Pipeline eine fertige Deutung erwartet, muss diese Grenze gleich zu Beginn offen besprechen.

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 den Rückmeldungen eines einzigen Bewertungsverfahrens 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 Freigabepunkten, 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 Freigabepunkt 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 Freigabepunkte wird kein Bericht ausgeliefert

Was ich heute anders machen würde

Die Berichtskonventionen habe ich nicht von Anfang an geschrieben; sie 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.