Warum dein KI-Agent an echten Websites scheitert
Dein Agent funktioniert mit den Seiten, gegen die du ihn getestet hast. Dann richtest du ihn auf das offene Web, und die Antworten werden vage oder selbstbewusst falsch, oder er sagt, die Seite sei leer gewesen, während du den Inhalt im Browser vor dir siehst.
Der Reflex ist, am Prompt zu drehen. Meistens ist der Prompt in Ordnung. Der Fehler passierte, bevor das Modell irgendetwas gesehen hat — in der Schicht, die eine URL abruft und in Text verwandelt.
Wir haben diese Schicht an echten Seiten gemessen. Das sind die fünf Arten, wie sie bricht, und wie jede davon tatsächlich aussieht.
1. Die Seite hat keinen Text, bis JavaScript läuft
atlassian.com/software/jira/pricing ergibt beim gewöhnlichen Abruf aus 1,37 MB HTML ein Token lesbaren Inhalt. Nicht einen Absatz — ein Token, einen Zeilenumbruch.
Die Preise sind da drin. Sie stehen in einem <script> als Anwendungszustand und warten darauf, dass ein Browser die Seite daraus baut.
Ruf dieselbe URL mit einem Headless-Browser ab, und daraus werden 3.048 Tokens, die so beginnen:
## **Transparent pricing for every team.**
Dieselbe URL. Derselbe Tag. Null Inhalt oder die ganze Seite, je nachdem, ob du JavaScript ausgeführt hast.
Das ist der Fehler, der wie ein Modellproblem aussieht und keines ist. Dein Agent sagte „die Seite erwähnt keine Preise", weil das in den Bytes, die er bekam, zutraf.
2. Aber Rendern ist nicht die Lösung, die du dir wünschst
Die naheliegende Antwort ist, alles zu rendern. Probier es an stripe.com/docs:
FetchError: Rendered fetch failed: Navigation timeout of 25000 ms exceeded
Eine Seite, die ein einfacher Abruf in unter einer Sekunde zurückgibt, wurde in einem Headless-Browser in 25 Sekunden nicht fertig geladen. Die nicht gerenderte Fassung kam bei allen Mängeln wenigstens zurück.
Rendern kostet dich einen Browser-Prozess pro Seite, von mehreren hundert Millisekunden bis mehreren Sekunden Latenz und eine neue Fehlerklasse: Timeouts, blockierte Ressourcen, Seiten, die nie load auslösen. Wenn dein Agent standardmäßig rendert, ist er langsamer und auf Teilen des Webs unzuverlässiger, nicht zuverlässiger.
Die brauchbare Form ist: erst billig abrufen, prüfen, ob überhaupt etwas kam, und nur bei den leer zurückgekommenen Seiten auf Rendern eskalieren. Diese Prüfung ist genau der Teil, den man weglässt.
3. Du bezahlst für Markup, das du nie benutzt
Über die zwölf bekannten Seiten hinweg, die wir gemessen haben, überlebt im Median unter 1% des Gesendeten bis zum Modell. shopify.com/pricing sendet 410.515 Tokens und liefert 2.479.
Wenn dein Agent rohes HTML ins Kontextfenster stopft, bezahlst du <div>-Hüllen und Inline-SVG zu Eingabe-Token-Preisen und verdrängst die Seiten, die du auch noch lesen wolltest. Extrahiere, bevor du sendest. Besser noch: frag, ob die Seite dir direkt Markdown gibt. Manche tun das bereits — von den zwölf getesteten Seiten lieferten fünf eine Markdown-Repräsentation, eine davon unsere.
4. Die Extraktion behält den falschen Teil
Extraktion ist eine Heuristik. Sie sucht den Artikel und verwirft das Mobiliar, und bei Seiten, die nicht wie Artikel geformt sind, rät sie schlecht.
stripe.com/docs schrumpft auf 1.057 Zeichen, die so beginnen:
$ stripe payment_intents create --amount 1099 --currency "usd"
Das ist ein echtes Fragment der Seite. Es ist auch ein Terminal-Beispiel statt eines Satzes darüber, was Stripe tut. Ein Agent, dem nur das gegeben wird, muss das Produkt aus einem Code-Schnipsel erschließen.
Also: Vertrau nie darauf, dass eine erfolgreiche Extraktion auch eine nützliche ist. Billige Absicherung — wenn das Extrahierte keinen satzförmigen Text enthält oder auf einer Seite, die ein halbes Megabyte gesendet hat, kürzer als ein paar hundert Zeichen ist, behandle es als fehlgeschlagenen Lesevorgang und eskaliere, statt es dem Modell als Tatsache zu übergeben.
5. Dieselbe URL liefert nicht dieselbe Seite
Der einfache Abruf von shopify.com/pricing lieferte Englisch. Das Rendern derselben URL von derselben Maschine lieferte Spanisch: Pago mensual32 € EUR/mes, wo der einfache Abruf Pay monthly€32 EUR/mo sagte.
Hier ist nichts kaputt. Der Headless-Browser sendete andere Accept-Language- und Geolokalisierungssignale als unser einfacher Abruf und bekam eine andere, korrekte Repräsentation. Aber wenn du nur nach URL cachst oder den heutigen Lesevorgang mit dem gestrigen vergleichst, sieht dieser Unterschied so aus, als hätte die Seite ihre Preise geändert.
Sende ein explizites Accept-Language. Schlüssle deinen Cache nach dem, was du tatsächlich angefragt hast.
Der Fehler, der nicht auftrat
Wir erwarteten Blockaden. Wir haben alle zwölf Seiten zweimal sondiert — einmal als Browser, einmal als OAI-SearchBot — und die Statuscodes über Cloudflare, Vercel und CloudFront hinweg verglichen.
Keine behandelte den Bot anders. Nicht eine.
Das heißt nicht, dass niemand Agenten blockiert; viele tun es, und du solltest robots.txt weiterhin lesen und befolgen. Es heißt, dass Blockieren unwahrscheinlich der Grund ist, wenn dein Agent an einer breiten Stichprobe des Webs scheitert. Der leere Raum ist weit häufiger als die verschlossene Tür.
Eine Leseschicht, die den Kontakt mit dem Web übersteht
1. Erst Markdown anfragen → Accept: text/markdown, oder /seite.md
2. Einfacher Abruf → billig, ohne JS
3. Prüfen, was kam → satzförmig? lang genug für die gesendeten Bytes?
4. Sonst eskalieren → rendern, mit Timeout und Budget
5. Ehrlich aufgeben → „Ich konnte diese Seite nicht lesen"
Schritt 5 zählt mehr, als er aussieht. Ein Agent, der eine unlesbare Seite meldet, ist debugbar. Ein Agent, der dem Modell einen Zeilenumbruch reicht und es improvisieren lässt, ist der, der sich deine Preise ausdenkt.
Die Kurzfassung
- Die meisten Agentenfehler sind Lesefehler, keine Denkfehler.
- Leer-ohne-JavaScript ist mit Abstand der größte, und Rendern behebt ihn — zu einem Preis, und nicht immer.
- Prüfe jede Extraktion, bevor du ihr traust.
- Blockaden bekommen die Aufmerksamkeit. Die Leere richtet den Schaden an.
Prüfen, wie eine Seite gelesen wird · Was ein Agent wirklich sieht · Markdown für Agenten ausliefern