Ein Web-Such-Tool für KI-Agenten, das den Seitentext zurückbringt

Warum braucht ein Agent den Seitentext und nicht nur Snippets?

Weil die Antwort selten im Snippet steht. Eine Ergebnisseite liefert einen Titel und ein bis zwei Zeilen, die die Suchmaschine auswählt. Die Zahl, das Datum oder die Regel, nach der Ihr Nutzer fragt, steht weiter unten auf der Seite.

Ein Agent, der nur Snippets sieht, hat zwei schlechte Optionen. Er kann aus einem Fragment antworten und riskiert, falsch zu liegen, oder er ruft ein zweites Tool auf, um jede Seite abzurufen. Die zweite Option verdoppelt die Roundtrips und die Tool-Definitionen.

Mit LLMWebSearch kommen die ersten Seiten bereits gelesen an. Navigation, Werbung und Cookie-Banner sind entfernt, sodass das Modell seine Tokens für Inhalte ausgibt. Die übrigen Ergebnisse tragen weiterhin ihre Snippets, die dem Modell helfen zu entscheiden, ob es erneut suchen soll.

Wie sollte das Such-Tool definiert werden?

Halten Sie das Schema klein: ein erforderliches query und höchstens ein oder zwei Schalter. Modelle rufen einfache Tools zuverlässiger auf. Das folgende Beispiel stellt ein recent-Flag bereit, das auf time_range=month abbildet; alles andere ist in Ihrem Code festgelegt.

Die Funktion gibt reinen Text zurück, kein JSON. Jede Quelle beginnt mit einer Nummer, einem Titel und einer URL, gefolgt von ihrem Markdown. Dieses Layout macht Zitate wie [2] für das Modell natürlich.

Wenn Ihr Agent bereits ein Tool namens web_search mitbringt, wie es Claude Code und OpenClaw tun, geben Sie Ihrem Tool einen anderen Namen, etwa search_web. Zwei Tools mit einem Namen verwirren das Modell.

Wann sollte ein Agent suchen, und wie oft?

Suchen Sie, wenn die Antwort von Fakten abhängt, die sich ändern oder die das Modell nicht kennen kann. Preise, Versionen, Gesetze, Zeitpläne und aktuelle Ereignisse qualifizieren sich. Definitionen und stabiles Wissen in der Regel nicht.

Schreiben Sie diese Regel in den System-Prompt und fügen Sie ein Budget hinzu. Drei Gewohnheiten helfen:

• Erst planen, dann suchen. Bitten Sie das Modell, seine Suchanfragen zuerst zu formulieren. Zwei präzise Suchanfragen schlagen fünf vage.
• Aufrufe begrenzen. Erlauben Sie etwa vier Suchen pro Nutzer-Turn. Erhöhen Sie das Limit nur für Rechercheaufgaben.
• Stoppen, wenn die Quellen übereinstimmen. Wenn drei unabhängige Seiten dasselbe sagen, kann der Agent antworten.

Wie halte ich das Kontextfenster unter Kontrolle?

Drei Parameter entscheiden, wie viel Text das Modell erreicht. read legt fest, wie viele Seiten gelesen werden, von 0 bis 10. max_chars begrenzt jede Seite, von 500 bis 50.000 Zeichen. max_results legt fest, wie viele Ergebnisse aufgelistet werden, von 1 bis 20.

Für einen Chat-Agent liefert read=3 mit max_chars=4000 etwa 12.000 Zeichen Seitentext pro Suchanfrage. Das lässt Raum für mehrere Suchanfragen in einem Gespräch. Für eine Rechercheaufgabe, die fortlaufend zusammenfasst, sind längere Seiten in Ordnung.

Das Feld word_count sagt Ihnen, wie lang die vollständige Seite vor dem Kürzen war. Der Agent kann es nutzen, um zu entscheiden, ob er mit dem extract-Endpoint mehr abruft.

Was passiert, wenn eine Seite nicht gelesen werden kann?

Das Ergebnis kommt trotzdem zurück, mit Titel, URL und Snippet, aber ohne Inhalt. Ein Feld content_status gibt den Grund an.

• blocked_by_robots: Die robots.txt der Seite erlaubt unserem Reader keinen Zugriff.
• blocked_by_site_policy: Eine Website, die in ihrer robots.txt Content-Signal: ai-input=no setzt, hält ihre Seiten aus dem Inhalt Ihrer Ergebnisse heraus.
• target_refused: Die Seite hat mit einer Ablehnung geantwortet; ihr Status steht in target_status.
• fetch_failed oder fetch_timeout: Die Seite wurde nicht rechtzeitig geladen.

Wenn eine Website unseren Reader abweist, kommt das Ergebnis ohne Inhalt und mit dem Status der Website zurück: Wir lösen niemals CAPTCHAs, melden uns nicht in Konten an und umgehen weder eine Sperre noch eine Paywall. Weisen Sie den Agent an, das Snippet oder eine andere Quelle zu nutzen, wenn eine Seite leer zurückkommt. Die Suchanfrage selbst kostet weiterhin einen Credit, egal was mit den einzelnen Seiten passiert ist.

Warum nicht das in das Modell eingebaute Such-Tool nutzen?

Eingebaute Tools sind praktisch, geben Ihnen aber weniger Kontrolle. Stand 22. Oktober 2026 kostet OpenAIs web_search-Tool $10 pro 1.000 Aufrufe plus den Suchinhalt, der als Input-Tokens abgerechnet wird. Die Websuche von Anthropics Claude kostet ebenfalls $10 pro 1.000 Suchanfragen plus Token-Kosten. Gemini 3 Grounding enthält 5.000 kostenlose Suchanfragen pro Monat im kostenpflichtigen Tarif, danach $14 pro 1.000.

Diese Tools geben meist eine geschriebene Antwort mit Zitaten zurück, nicht die Rohseiten. Außerdem binden sie Ihre Suche an einen Modellanbieter. Ein eigenständiges Tool funktioniert mit jedem Modell und lässt Sie die Länge jeder Seite festlegen. Der Vergleich der eingebauten Tools enthält die vollständige Tabelle.

Was kostet es, einen Agenten auf LLMWebSearch zu betreiben?

Ein Credit pro Suchanfrage, wenn read 3 oder weniger ist. Ein Assistent, den ein Team nutzt und der 100 Fragen pro Tag mit je 4 Suchanfragen beantwortet, kommt auf etwa 12.000 Suchanfragen pro Monat. 25.000 Suchanfragen zu 41,25 $ deckt diesen Monat und einen Großteil des nächsten ab.

Ein Coding-Agent, den ein einzelner Entwickler nutzt, sucht vielleicht 20-mal pro Tag, also etwa 600-mal pro Monat. 5.000 Suchanfragen zu 9,25 $ hält dann mehrere Monate, weil Credits nie verfallen. Der Kostenleitfaden zeigt die Rechnung für größere Workloads.