KI-Agent für die selbstheilende Website: repariert, was er verifizieren kann

Was der Loop für die selbstheilende Website tut

Eine Website heilt sich nur dort selbst, wo der Agent die Korrektur beweisen kann, und um genau diese Grenze haben wir den ganzen Mechanismus gebaut. Unser KI-Agent für die selbstheilende Website prüft die Live-Website jede Woche, legt jeden Fehler als Bug an und schickt jeden Bug in einen eigenen Lauf in einer isolierten Umgebung. Dieser Lauf schreibt um, was er über die CMS-API umschreiben kann, prüft die gespeicherte Seite erneut und schließt den Bug nur bei einer sauberen Prüfung. ConvOps steuert den Zeitplan, die Bug-Warteschlange und beide Workflows. Es ist einer der Loops, mit denen wir unser Unternehmen führen.

Eine selbstheilende Website ist eine Website, auf der ein Agent Fehler findet, die Leser sehen, und diejenigen repariert, die er verifizieren kann, während der Rest auf eine Person wartet. Sie ist keine selbstheilende Testsuite: Die repariert Selektoren in Tests, dieser Loop dagegen repariert die Inhalte, die ein Leser sieht.

Alle Ansichten und Zahlen unten verwenden Beispieldaten von Shutterlane, einer fiktiven Website mit Testberichten zu Kameraausrüstung, die zwei Personen unter shutterlane.example.com betreiben.

Ein wöchentlicher Prüflauf findet Fehler, jeder Bug bekommt seinen eigenen Reparaturlauf, und das Register macht aus Wiederholungen Prüfungen beim Schreiben.

Der Prüflauf (Markierung 1) legt Befunde an (2), gleicht sie mit dem Präventionsregister ab (3) und verteilt offene Bugs (4). Jeder Bug wird in seiner Spur repariert (5), verifiziert (6) und dann geschlossen oder zurückgehalten (7).

Warum wir ihn gebaut haben: ein KI-Agent, der Inhaltsfehler auf der Website behebt

Ein QA-Agent, der nur berichtet, erzeugt nur Rauschen. Ein Agent, der in einem Lauf findet und behebt, benotet seine eigenen Hausaufgaben. Wir haben beides getrennt.

Unser Prüflauf berichtete anfangs nur. Er fand jede Woche dieselben kaputten Links und veralteten Seiten, und niemand war für die Korrektur zuständig. Das Diagramm zeigt dieses Muster auf Shutterlane-Daten: Ein Bug wird angelegt (Markierung 1), sammelt jeden Dienstag eine Wiederholungsnotiz (2) und wird nie repariert (3).

Ein Prüflauf, der nur berichtet, findet jede Woche denselben Fehler, und ohne Reparaturschritt wächst nur der Stapel der Wiederholungsnotizen.

Daraus entstanden drei Prinzipien:

1. Finden und Beheben sind getrennte Jobs. Der Prüflauf schreibt nie Inhalte, und die Reparatur beurteilt nie die Website.
2. Ein Fehler ist eine Arbeitseinheit. Jeder neue Befund ist ein eigener Bug, und jeder Reparaturlauf gehört genau einem Bug.
3. Erledigt heißt verifiziert. Ein Bug wird erst nach einer erneuten Prüfung der gespeicherten Seite geschlossen, nie auf das Wort des Agenten hin.

Wenn sich Ihre QA-Berichte genauso stapeln, sehen Sie sich an, wie ConvOps aus Befunden Bugs macht, die Executors einzeln abarbeiten(wird in einem neuen Tab geöffnet).

So läuft er: Pool, Executor, Umgebung, Workflow

Das Modell ist der uninteressanteste Teil. Der Pool entscheidet, was bearbeitet wird, die Umgebung, was der Agent anfassen darf, der Workflow, wann er fertig ist. Zwei Workflows tragen die Arbeit: der Prüf-Workflow WF-qa und der Reparatur-Workflow WF-bugfix. Es ist ein Graph aus Schritten und Gates, die Form, die wir in Was ist Graph Engineering? beschreiben, derselbe Loop mit Gates und Zeitplan wie bei unseren SEO-Experimenten mit Claude Code und die Antwort auf Agent Sprawl.

Ein Pool entscheidet, was bearbeitet wird, der Executor führt es aus, die Umgebung begrenzt, was er anfassen darf, und der Workflow entscheidet, wann er fertig ist.

Befunde werden zu Bugs in einem Pool

Ein Pool ist eine gespeicherte Abfrage in ConvOps: ein Filter über Task-Typ, Tags, Projekt, Horizont und Status, dazu eine Sortierung. Er enthält nie Tasks; er löst sich bei jeder Abfrage in die passenden auf, sodass Bugs aus jedem Projekt in jedem passenden Pool landen. pools_next liefert den einen obersten Task, entscheidet Gleichstände nach Task-ID und schreibt pro Aufruf eine Abrufzeile, sodass jeder Abruf nachvollziehbar ist.

Shutterlanes Pool open-qa-bugs lautet type = bug AND tags contains qa-finding AND status in [backlog, todo], die ältesten zuerst (Markierung 1).

Executors übernehmen die Arbeit

Ein Executor ist ein benannter Runner, optional an den Pool gebunden, aus dem er abruft (Markierung 2). Es gibt genau zwei Arten:

Unser Loop läuft auf einem isolierten Claude-Code-Executor, der im Zeitplan benannt ist. Der Verteilschritt des Prüflaufs führt die Abfrage in Pool-Form selbst aus und schickt jeden Bug an diesen Executor; wird der Executor an einen Pool gebunden, übernimmt ConvOps denselben Abruf. Ein hängender Lauf wird bei time_limit_s beendet (pro Executor 60 bis 86.400 Sekunden, sonst gilt die Workspace-Einstellung: hier 14.400).

Isolierte Umgebungen begrenzen, was der Agent anfassen darf

Eine isolierte Umgebung ist die schriftliche Definition von allem, was ein Lauf anfassen darf. Jeder Lauf ist ein Kubernetes Job, angelegt im angehaltenen Zustand; ein Secret pro Lauf, das dem Job gehört, kommt vor dem Start hinzu. Ein Task-Volume bewahrt den Arbeitsordner des Tasks über seine Läufe hinweg. Der Job wird 300 Sekunden nach seinem Ende entfernt und das Secret mit ihm, sodass Credentials den Lauf nie überdauern.

Alles, was der Agent anfassen darf, ist vor dem Lauf festgelegt, und das Credential ist eine Referenz, nie ein Wert.

• Repos. Genau eines erhält Arbeit und wird immer gepusht (Markierung 1): direkt auf die ausgecheckte Ref, einmal neu angewendet, nie erzwungen.
• Tool-Regeln. Der CMS-Server verweigert standardmäßig alles und erlaubt 8 Tools (Markierung 2). Der Browser erlaubt nur lesende Tools: navigate, snapshot, screenshot und drei weitere.
• Referenzen statt Werte. CMS_API_TOKEN verweist auf einen Eintrag in einem Secret Manager (Markierung 3), und auch das Credential des Executors ist eine gespeicherte Referenz (Markierung 4). Markierung 5 ist die Pool-Bindung.
• ConvOps-Berechtigungen. Schreibzugriffe auf Tasks erreichen nur den eigenen Task des Laufs. Notizen und Lesezugriffe erreichen jeden Task, sodass der Prüflauf Bugs kommentieren kann, aber nur ein Reparaturlauf schließt seinen eigenen Bug.
• Dispatch-Limits. run_dispatch_limit liegt bei 10 pro Lauf, das begrenzt Kosten und Schadensradius eines Prüflaufs. run_dispatch_named_environment ist false, sodass ein Lauf die Sandbox dessen, was er verteilt, nicht erweitern kann.

Zwei Workflows: einer findet, einer behebt

Der Auditor liest Seiten so, wie sie beim Leser ankommen: manche im Browser gerendert, die übrigen als rohes HTML, wobei Zähler und Aktualität mit der Datenbank abgeglichen werden. Das Aktualitätsversprechen beträgt 7 Tage für Kameramodelle und 14 für Verzeichniseinträge, der Takt, in dem ihre Prüf-Loops laufen.

Der Prüflauf hat sechs Schritte, läuft jeden Dienstag um 05:00 UTC, findet Fehler, legt Bugs an und schreibt nie Inhalte.

Die Reparatur hat fünf Schritte für einen Bug, nutzt nur die Spur dieses Bugs und schließt ihn erst nach einer erneuten Prüfung.

Der Zeitplan (Markierung 1) lautet FREQ=WEEKLY;BYDAY=TU;BYHOUR=5;BYMINUTE=0. Wöchentlich passt zum 7-Tage-Aktualitätsversprechen, sodass ein Befund noch aktuell ist, wenn seine Reparatur läuft.

Ein Lauf Schritt für Schritt: ein Bug vom Befund bis zur verifizierten Korrektur

Das Spannende an einer Reparatur ist die Prüfung nach dem Schreiben, nicht das Schreiben selbst. Hier ist Shutterlanes Prüflauf qa/2026-09-15, vom Zeitplan bis zum Ergebnis.

Dienstag, 05:00 UTC: Der Prüflauf findet Fehler und legt Bugs an

Der Prüflauf läuft auf isolated-sonnet in einem Job mit shutterlane-qa. Der Auditor liest 24 Seiten (6 im Browser, 18 als rohes HTML) und liefert 7 Befunde, einen pro Regel.

Der Auditor liefert einen Befund als Seite, Regel und Detail, und ein neues Paar aus Seite und Regel wird zu einem Bug mit dem Titel Regel: Seite.

Dieser Befund ist neu und wird deshalb zum Bug demo0101, absolute-self-link: /blog/best-travel-cameras-2026, Status todo (zu erledigen). Der Lauf protokolliert qa-dedupe: 5 novel, 2 recurrences; jede Wiederholung fügt ihrem offenen Bug eine Notiz hinzu.

Der Präventionsschritt liest das Register. absolute-self-link ist covered (abgedeckt), und der Beitrag ist 3 Tage alt, also innerhalb des 7-Tage-Fensters für Durchschlüpfe. Deshalb legt der Prüflauf die Idee demo0110 als prevention-proposal an.

Der Verteilschritt listet die offenen QA-Bugs auf, die ältesten zuerst: 7, innerhalb des Limits von 10. Jeder geht an isolated-sonnet, ohne dass eine Umgebung genannt wird, und erhält so die Standardumgebung seines Projekts.

Ein Bug, ein Lauf

Jeder Bug läuft in seinem eigenen isolierten Job mit eigenem Volume und notiert seine Spur, bevor er irgendetwas anfasst.

demo0101 erhält einen eigenen Job, run-demoex01, und ein eigenes Volume. read-bug wählt die Spur nach Seitentyp und Regel: Ein Self-Link auf einer /blog/-Seite gehört zu post. Er schreibt bugfix-demo0101/2026-09-15 lane=post, bevor er irgendetwas anfasst.

Ein geschützter Schreibvorgang

Der einzige Schreibvorgang trägt die gelesene Version, sodass ein geänderter Beitrag ihn ablehnt, und er übergibt nie einen Status.

heal-post führt post-lint aus, das das fehlerhafte Ziel und seine Korrektur benennt. Dann folgt ein verankerter body_md_edits-Replace, geschützt durch die gelesene expected_version. Er übergibt nie status, sodass eine Reparatur eine Seite nie veröffentlichen oder depublizieren kann.

Bei einem Versionskonflikt liest der Agent einmal neu und baut die Änderung neu auf; eine zweite Ablehnung endet als not healed (nicht repariert). Ein toter Link ohne bekannte Adresse wird entfernt, sein Linktext bleibt erhalten. Einen Link zu entfernen ist sicher; ein Ziel zu raten nicht.

Repariert oder zurückgehalten

Ein Bug wird erst nach einem sauberen Re-Lint und ohne das fehlerhafte Ziel abgeschlossen, während ein Bug in der Wartespur für eine Person blockiert wird und der Inhalt unberührt bleibt.

Der Agent liest den gespeicherten Beitrag erneut und lintet ihn neu. Repariert heißt: Die Regel hat keinen Befund mehr UND das fehlerhafte Ziel ist aus dem gespeicherten Text verschwunden, denn der Lint kann ein Ziel übersehen, das der Auditor gesehen hat. Die Notiz lautet healed: https://shutterlane.example.com/models/orrin-k5 -> /models/orrin-k5, das Laufprotokoll wird committet, der Bug wird abgeschlossen, und Job und Secret verschwinden 300 Sekunden später.

Rechts landet demo0104 (counter-sanity: /news) in hold. Er wird auf blocked gesetzt, mit der Begründung „needs a product or operator fix“ (braucht eine Korrektur am Produkt oder durch das Betriebsteam), der Inhalt bleibt unberührt.

So sieht das Ergebnis aus: Bericht, Notizen, Register

Lesen Sie den Prüflauf nach Status, nicht nach Anzahl. Eine Wiederholung bei einer abgedeckten Regel ist ein Fehler in Ihrer Schutzprüfung, nicht in Ihren Inhalten.

Lesen Sie den Prüflauf nach Status: Neue Zeilen sind neue Bugs, Wiederholungen sind Notizen, und eine abgedeckte Regel, die wiederkehrt, bedeutet, dass die Schutzprüfung ein Leck hat.

Zwei Signale steuern den Präventionsschritt:

• Durchschlupf: eine abgedeckte Regel in einem /news/- oder /blog/-Beitrag, der innerhalb von 7 Tagen veröffentlicht wurde. Nur ein neuer Beitrag beweist, dass die Schutzprüfung beim Schreiben ihn durchgelassen hat.
• Lücke: eine teilweise oder nicht abgedeckte Regel auf 2 oder mehr Seiten in einem Lauf oder eine, die wiederkehrt. Eine Seite ist ein Fehler; zwei Seiten oder eine Wiederholung sind ein Muster.

Jede Regel bekommt einen Vorschlag; ein offener Vorschlag bekommt eine Notiz, nie eine zweite Idee.

Im Shutterlane-Bericht ist encoding-artifact covered und kehrte trotzdem auf /directory wieder: Die Schutzprüfung leckt über einen älteren Veröffentlichungsweg. Genau dieses Muster haben wir erlebt, und daraus entstand eine zweite Schutzprüfung: post-lint am Veröffentlichungs-Gate zusätzlich zu den Ablehnungen beim Schreiben in den CMS-Tools. Jedes Laufprotokoll landet in Git, der Nachweis, den wir in KI-Agenten-Observability beschreiben.

Was schiefgeht: eine Regel, drei Schreibweisen

Die meisten unserer Fehler lagen in der Verkabelung und den Berechtigungen, nicht im Modell. Der schlimmste sah aus wie ein funktionierender Loop.

Die Deduplizierung arbeitet mit dem Schlüssel (page, rule). Unser Auditor formulierte Regelnamen frei und schrieb eine Prüfung über mehrere Läufe hinweg auf drei Arten. Die Deduplizierung sah drei Regeln und legte drei Bugs für einen Fehler an. Auf Shutterlane-Daten: dead-link, broken-link und dead-internal-link auf /news/corvane-x2-firmware-3 wurden zu demo0081, demo0084 und demo0087.

Drei Schreibweisen einer Regel legten drei Bugs an; ein festgelegter Slug lässt einen Bug mit einer Wiederholungsnotiz pro Lauf übrig.

Die Regel, die daraus entstand, ist eine Zeile in der Karte des Auditors: „rule ist genau einer von encoding-artifact, dead-link, absolute-self-link, counter-sanity, vocab-drift, freshness, reader-error; nie eine Variante.“ Jetzt ist ein Link ein Bug mit einer Wiederholungsnotiz pro Lauf.

Bauen Sie Ihren eigenen: die Minimalversion

Beginnen Sie mit der Wartespur und den Tool-Berechtigungen. Legen Sie fest, was der Agent nie anfassen darf, bevor Sie ihn irgendetwas anfassen lassen.

Der minimale Loop: ein wöchentlicher Zeitplan, ein nur berichtender Auditor, ein Deduplizierungsskript, ein Bug-Pool und ein Runner in einer Sandbox, der repariert und lintet oder für eine Person zurückhält.

Halten Sie das Lint-Skript vom Netzwerk fern: Unseres beurteilt Links anhand der Routentabelle und der Entitätslisten, sodass sein Urteil exakt reproduzierbar ist. Die Wartespur ist das menschliche Gate aus KI-Systeme mit Human in the Loop bauen. Die Spurtabelle zum Kopieren:

lanes:
  post:       # rewrite through the CMS API, then re-lint
    rules: [absolute-self-link, dead-link, encoding-artifact]
    pages: ["/blog/<slug>", "/news/<slug>"]
  freshness:  # re-verify; healed when the general stamp moves
    rules: [freshness]
    pages: ["/models/<slug>", "/directory/<slug>"]
  reader:     # re-read; healed on HTTP 200 with the page's own content
    rules: [reader-error]
  hold:       # everything else: blocked, a person fixes it
    rules: ["*"]

Die Umgebung zum Kopieren:

environment: shutterlane-qa
repos:
  - repo: shutterlane/site-ops
    receives_work: true
    push_target: ref
mcp_servers:
  shutterlane-cms:
    default: deny
    allow: [post_get, post_list, post_update,
            translations_manage, model_get, tool_get,
            verification_log_manage, verdict_history]
  playwright:
    default: deny
    allow: [browser_navigate, browser_snapshot,
            browser_take_screenshot, browser_console_messages,
            browser_wait_for, browser_close]
convops_tools_any_task: [task_notes_add, task_notes_list, tasks_get]
run_dispatch_limit: 10
run_dispatch_named_environment: false
secrets:
  CMS_API_TOKEN: {kind: gcp-sm, ref: demo-project/cms-token}

Kopieren Sie die Spurtabelle und die Umgebungsdefinition und planen Sie dann Ihren wöchentlichen Prüflauf in ConvOps(wird in einem neuen Tab geöffnet). Soll das auf Ihrer eigenen Website laufen? Buchen Sie eine kostenlose Discovery Session.