Screenshots als Beweismittel für KI-Agenten: ganze Seiten, Regionen und Diffs

Einen Agenten Playwright installieren und ein PNG speichern zu lassen, kostet eine Handvoll Zeilen. Damit hat heute niemand mehr Mühe. Schwierig wird es erst, wenn diese Bilder Teil eines Produktiv-Workflows werden und sich jemand darauf verlassen muss.

Dann muss ein Agent belegen, dass eine lange Seite wirklich bis ganz unten erfasst wurde. Er muss das Ergebnis in Stücke schneiden, die ein Vision-Modell tatsächlich lesen kann, Belege aufbewahren, die sich danach nie mehr ändern, zwei Releases vergleichen, ohne dass Layoutverschiebungen Fehlalarme auslösen, Prüfungen nach Zeitplan laufen lassen und im Budget bleiben, wenn niemand zusieht.

Eine verwaltete Screenshot-API mit Remote-MCP-Server ist eine Möglichkeit, all das zu bündeln, für öffentliche Seiten oder Seiten, die der Aufrufer sehen darf. Sie soll schlichtes Playwright nicht ersetzen, wenn ein Wegwerf-Screenshot genügt. Ihre Aufgabe ist es, die Beweisebene für wiederkehrende Workflows zu bilden.

Eine Seite in einem definierten Zustand aufnehmen

Eine URL allein legt nicht fest, was ein Screenshot zeigt. Desktop, Tablet und Smartphone haben unterschiedliche Breiten, helles und dunkles Theme ebenso, und nach einem Klick ist die Seite wieder eine andere. Ein Aufnahmedienst braucht deshalb Stellschrauben für benannte Geräte und eigene Viewports, Theme-Präferenz, Wartestrategie, Aufräumen, ausgeblendete Selektoren, Header, Cookies und geskriptete Interaktionen. Damit legt ein Workflow fest, welche Version der Seite er festhalten will, statt sich mit dem zufrieden zu geben, was nach der Navigation gerade geladen war.

Die Aufnahme ganzer Seiten hat ihre eigene Falle. Die Höhe kann sich ändern, während Lazy-Content, Webfonts und Bilder nachladen, und so liefert der Browser womöglich ein Bild, dessen unterer Teil noch leer ist. Abhilfe schafft ein festes Vorgehen: schrittweise scrollen, warten, bis sich die Dokumenthöhe nicht mehr bewegt, zurück nach oben springen, aufnehmen und anschließend Breite und Höhe des fertigen PNG oder JPEG mit dem Dokument abgleichen. Kommt die Seite nie zur Ruhe oder wächst sie weiter, gibt der Aufruf einen typisierten Fehler zurück. Ein sichtbarer Fehlschlag ist besser als ein unvollständiger Beleg, der als vollständig durchgeht.

Lange Seiten in lesbare Regionen zerlegen

Quetscht man einen 12.000 Pixel hohen Screenshot in die kleine Eingabe eines Vision-Modells, wird der Text zu Brei. Der Dienst löst das mit einem regions-Flag in der Anfrage.

curl --request POST https://api.scrinly.com/render/screenshot \
  --header "Authorization: Bearer $SCRINLY_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "url": "https://example.com",
    "device": "macbook-pro-14",
    "theme": "dark",
    "fullPage": true,
    "regions": true,
    "format": "jpg",
    "quality": 80
  }'

Die Antwort enthält den kompletten Screenshot und dazu geordnete Ausschnitte für Navigationsleiste, Hero, Hauptinhalt, Calls to Action, Footer und weitere erkannte Bereiche. Ein Manifest führt für jede Region Grenzen, Reihenfolge, Konfidenz, Abdeckung, Abmessungen und Hash auf. Jeder Ausschnitt stammt aus dem final ausgelieferten Screenshot, nie aus einer zweiten Aufnahme, die abweichen könnte.

Ein design-Flag ergänzt deterministische Angaben zu Farben, Typografie, Abständen, Layout und Animationen, bereinigt und in der Größe begrenzt. Ein KI-Modell ist daran nicht beteiligt.

Scheitert die Regionen-Verarbeitung, obwohl der Screenshot selbst geklappt hat, bekommt der Aufrufer trotzdem den Screenshot, und nur der Aufpreis für die Regionen wird erstattet.

Belege, die sich nicht überschreiben lassen

Zwei Aufnahmen derselben URL dürfen sich niemals gegenseitig überschreiben. Erzeugte Dateien werden deshalb unter Namen abgelegt, die aus einem Hash der final kodierten Bytes abgeleitet sind.

{storagePrefix}/{screenshotSha256}.jpg

Unterschiedliche Bytes ergeben unterschiedliche Schlüssel, identische Aufnahmen können sich gefahrlos einen teilen. Die Ergebnisse verweisen direkt auf den Speicheranbieter statt auf einen Bild-Proxy. Standardmäßig liegt alles in Backblaze B2, REST-API-Kunden können die Dateien aber auch in eigene B2-, S3- oder R2-Buckets leiten. Caching ist per cache-Flag optional, und Batches öffentlicher Screenshots fassen bis zu 100 gespeicherte Aufnahmen, wobei Abrechnung und Erstattungen pro Element erfolgen.

Releases ohne Fehlalarme vergleichen

Es gibt zwei Vergleichsmodi: exakten Pixelabgleich und einen perzeptuellen Modus, der Rauschen toleriert. Ausgegeben werden kann ein annotiertes Overlay, eine kontextbezogene Heatmap, eine Binärmaske oder nur Metadaten.

Schwierig machen Vergleiche vor allem Verschiebungen. Fügt man unter dem Hero einen neuen Abschnitt ein, markiert ein gewöhnlicher Diff des ganzen Bildes alles darunter als geändert. Haben beide Aufnahmen aber kompatible Regionen-Manifeste, wird jeder logische Abschnitt einzeln verglichen. Der eingefügte Block erscheint als hinzugefügt, und ein Footer, der bloß nach unten gerutscht ist, gilt als unverändert.

Das Monitoring nutzt dieselbe Pipeline. Ein Monitor macht eine neue Aufnahme und vergleicht sie mit einer rollierenden oder festen Baseline. Wird ein Schwellenwert überschritten oder taucht eine Region auf bzw. verschwindet, eröffnet er einen visuellen Vorfall, verschickt signierte Webhooks oder Alarme an verifizierte E-Mail-Adressen und meldet die Erholung, sobald die Seite wieder normal aussieht.

Langsame Screenshot- und Diff-Jobs können asynchron laufen. Die API liefert eine kontobezogene Job-ID zurück, das Abfragen des Status kostet nichts, und ein signierter Webhook kann das fertige Ergebnis zustellen.

KI erst nach den deterministischen Schritten

Screenshots, Regionen, Design-Angaben, Hashes und Diffs sind allesamt deterministisch. Ein optionaler visueller Styleguide fügt eine Interpretation durch ein Modell hinzu, aber erst, wenn diese Belege vorliegen.

Das Modell, das der Server bestimmt, erhält ein größenbegrenztes Übersichtsbild, die geordneten Regionenbilder und eine bereinigte Projektion. Ziel-URL, Hostname, HTML, Cookies, Header, Selektoren, Zugangsdaten und mitgelieferter Seitentext werden ihm nicht als Text übergeben. Texte und Branding, die auf dem Bildschirm sichtbar sind, können natürlich trotzdem in den Pixeln auftauchen.

Das Ergebnis behandelt visuelle Grundlage, Farbe, Typografie, Abstände, Komponenten, Animationen, responsives Verhalten und Lücken in den Belegen, und alle Aussagen werden gegen diese Belege geprüft. Styleguides werden automatisch gecacht, ein regenerate-Flag fordert einen frischen an. Aufrufer können außerdem einen temporären OpenAI-Schlüssel in einem eigenen Header mitschicken, der nicht gespeichert wird. Schlägt die Generierung fehl, bleiben Screenshot und Regionen verfügbar, und nur der KI-Aufpreis wird erstattet.

Bereitstellung für Agenten über MCP

Der Remote-MCP-Server bietet vier Tools:

• capture_screenshot
• compare_screenshots
• get_job_status
• get_usage

Die Verbindung läuft über OAuth, mit API-Key als Fallback. In Codex sieht das so aus:

codex mcp add scrinly --url https://mcp.scrinly.com/mcp

Ergänzt wird der Server durch einen Open-Source-Skill für Agenten. MCP macht die Tools aufrufbar, der Skill bringt kompatiblen Agenten bei, wann eine Aufnahme gerechtfertigt ist, wie sie das kleinste noch ausreichende Credit-Limit wählen, was zu tun ist, solange ein angenommener Job noch läuft, damit die kostenpflichtige Anfrage nicht doppelt rausgeht, und wie zusammengehörige Screenshots, Regionen und Hashes als Satz abgelegt werden.

npx skills add davmixcool/skills --skill scrinly -g

Kostenpflichtige MCP-Operationen verlangen einen maxCredits-Wert. Würde die Abbuchung im ungünstigsten Fall das vom Nutzer angegebene Limit überschreiten, wird die Anfrage abgelehnt, bevor gerendert oder abgerechnet wird. So entsteht eine praktische Grenze zwischen dem, was ein Agent allein tun darf, und dem, wofür der Nutzer zahlt.

Designlehren, die sich übertragen lassen

1. Ein erfolgreicher Browser-Aufruf beweist noch keinen vollständigen Screenshot.
2. Abgeleitete Ausschnitte sollten aus genau dem Bild stammen, das ausgeliefert wurde.
3. Stabile Belege brauchen inhaltsadressierten Speicher.
4. Deterministische Verarbeitung sollte vor der KI-Interpretation laufen.
5. Bei Teilerfolg sollte die nützliche Arbeit zurückkommen und nur der fehlgeschlagene Teil erstattet werden.
6. Autonome Tools brauchen neben Authentifizierung auch explizite Ausgabenlimits.
7. Playwright steuert den Browser, doch ein produktiver Workflow für visuelle Belege braucht eine ganze Menge Infrastruktur drumherum.

Zu den Preisen: Der kostenlose Tarif enthält 100 Credits pro Monat. Ein reiner Screenshot kostet einen Credit, mit Regionen drei, jeder visuelle Diff einen und ein neu erzeugter, von der Plattform finanzierter Styleguide bis zu sechs.