Starte bei Bedarf mit dem Agent-Tools Hub, wenn du den größeren Stack sehen willst. Dieser Artikel ist die engere Version: was du nutzt, wenn ein OpenClaw-Agent suchen, prüfen oder Kontext zurückholen muss, ohne blind durchs Web zu stolpern.
Die Kurzfassung
Es gibt nicht das eine beste Suchwerkzeug. Es gibt nur das beste Werkzeug für die Art von Suche, die du gerade brauchst.
- web_fetch für schnelle öffentliche Seiten ohne JavaScript.
- Browser-Automatisierung für Logins, Klicks und dynamische Seiten.
- memory_search für Fakten, die schon in deinen Speicherdateien liegen.
- Tavily oder Exa, wenn du eine Such-API willst, die das Web für dich priorisiert.
Native, angrenzend und extern
Die saubere Denkweise ist simpel. Native OpenClaw-Tools behandeln lokalen Kontext und direkten Seitenzugriff. Externe Such-APIs übernehmen die breite Web-Recherche. Browser-Tools sitzen dazwischen, wenn die Seite selbst das Hindernis ist.
| Werkzeug | Typ | Am besten für | Wichtigster Trade-off |
|---|---|---|---|
| web_fetch | Native | Schnelle Extraktion aus statischen öffentlichen Seiten | Schwach bei JavaScript und Auth |
| Browser-Automatisierung | Native | Login-Flows, UI-Schritte, dynamische Inhalte | Langsamer und fragiler |
| memory_search | Native | Frühere Entscheidungen, Notizen und gespeicherter Kontext | Kennt nur, was du gespeichert hast |
| Tavily / Exa | Extern | Websuche mit priorisierten Treffern oder Zitaten | Zusätzliche API-Kosten und mehr Abhängigkeiten |
Wann Suchqualität am meisten zählt
Suchqualität zählt, wenn die Antwort über mehrere Seiten verteilt ist, wenn Aktualität wichtig ist oder wenn du Zitate statt einer weichen Zusammenfassung brauchst. Sie zählt auch dann, wenn der erste Treffer oft falsch ist. Genau darum geht es bei Agenten: weniger selbstsichere Fehler.
Wenn du externe Such-APIs brauchst, sind die offiziellen Dokus der richtige Startpunkt: Tavily Quickstart und Exa Answer.
Kosten gegen Geschwindigkeit
web_fetch ist hier praktisch die günstigste Option. Es ist schnell, einfach und für viel Dokumentationsarbeit völlig ausreichend. Browser-Automatisierung kostet mehr Zeit, weil zuerst ein Browser startet und die Seite Schritt für Schritt abgearbeitet wird. Externe Such-APIs kosten meist Geld pro Anfrage, sparen aber Zeit, wenn du breite Suche statt manuell gebautem Fetching brauchst.
Der schlechte Reflex ist, Browser-Automatisierung für jedes Suchproblem zu nehmen. Dann wird aus einem scharfen Werkzeug ein langsamer Hammer.
Was Anfänger oft übersehen
- memory_search ist keine Websuche. Es ist für deinen eigenen gespeicherten Kontext, nicht für das Live-Web.
- Browser-Automatisierung ist nicht der Standard. Nutze sie nur, wenn die Seite Interaktion erzwingt.
- Such-APIs sind kein Zauber. Du brauchst trotzdem gute Prompts, Prüfung und menschliche Kontrolle bei heiklen Themen.
Best Fit nach Workflow
Solo-Builder
Starte mit web_fetch und memory_search. Browser-Automatisierung kommt erst dazu, wenn die Seite dich dazu zwingt. Das hält den Stack leicht.
Recherche-lastiger Workflow
Nutze Tavily oder Exa für breite Suche, danach bestätigst du wichtige Details mit web_fetch oder Browser-Automatisierung. Diese Mischung schlägt meistens ein einzelnes Tool, das alles können soll.
Agent mit gespeichertem Kontext
Frag zuerst memory_search. Wenn die Antwort schon gespeichert ist, sparst du Zeit, Geld und noch eine Chance, selbstsicher daneben zu liegen.
Empfehlung
Wenn du einen vernünftigen Standard willst, nutze diese Reihenfolge: zuerst memory_search, dann web_fetch, Browser-Automatisierung nur bei Bedarf und externe Such-APIs für breitere Websuche oder Zitate.
Wenn du nur den nativen Tool-Überblick willst, öffne als Nächstes den Suchwerkzeuge-Vergleich.