Skip to main content
web_search effectue des recherches sur le Web avec le fournisseur configuré et renvoie des résultats normalisés, mis en cache par requête pendant 15 minutes (durée configurable). OpenClaw intègre également x_search pour les publications sur X (anciennement Twitter) et web_fetch pour la récupération légère d’URL. web_fetch s’exécute toujours localement ; web_search passe par xAI Responses lorsque Grok est le fournisseur, tandis que x_search utilise toujours xAI Responses.
web_search est un outil HTTP léger, et non un outil d’automatisation de navigateur. Pour les sites qui dépendent fortement de JS ou nécessitent une connexion, utilisez le navigateur Web. Pour récupérer une URL précise, utilisez Web Fetch.

Démarrage rapide

1

Choisir un fournisseur

Choisissez un fournisseur et effectuez toute configuration requise. Certains fournisseurs ne nécessitent pas de clé, tandis que d’autres exigent une clé API. Consultez les pages des fournisseurs ci-dessous pour plus de détails.
2

Configurer

Cette commande enregistre le fournisseur et les éventuels identifiants requis. Pour les fournisseurs reposant sur une API, vous pouvez à la place définir la variable d’environnement du fournisseur (par exemple BRAVE_API_KEY) et ignorer cette étape.
3

L’utiliser

Pour les publications sur X :

Choisir un fournisseur

Brave Search

Résultats structurés avec extraits. Prend en charge le mode llm-context et les filtres par pays et langue. Une offre gratuite est disponible.

Codex Hosted Search

Réponses synthétisées par l’IA et étayées par des sources via votre compte de serveur d’application Codex.

DuckDuckGo

Fournisseur sans clé. Aucune clé API requise. Intégration non officielle reposant sur HTML.

Exa

Recherche neuronale et par mots-clés avec extraction de contenu (passages clés, texte, résumés).

Firecrawl

Résultats structurés. À associer de préférence à firecrawl_search et firecrawl_scrape pour une extraction approfondie.

Gemini

Réponses synthétisées par l’IA avec citations, fondées sur la recherche Google.

Grok

Réponses synthétisées par l’IA avec citations, fondées sur le Web via xAI.

Kimi

Réponses synthétisées par l’IA avec citations via la recherche Web de Moonshot ; les replis vers une conversation non étayée échouent explicitement.

MiniMax Search

Résultats structurés via l’API de recherche MiniMax Token Plan.

Ollama Web Search

Recherche via un hôte Ollama local connecté ou l’API Ollama hébergée.

Parallel

API Parallel Search payante (PARALLEL_API_KEY) ; limites de débit plus élevées et ajustement des objectifs.

Parallel Search (Free)

Option sans clé activée explicitement. Le Search MCP gratuit de Parallel, avec des extraits denses optimisés pour les LLM et sans clé API.

Perplexity

Résultats structurés avec contrôles d’extraction du contenu et filtrage par domaine.

SearXNG

Métarecherche auto-hébergée. Aucune clé API requise. Agrège Google, Bing, DuckDuckGo et d’autres services.

Tavily

Résultats structurés avec profondeur de recherche, filtrage par sujet et tavily_extract pour l’extraction d’URL.

Comparaison des fournisseurs

Détection automatique

Les listes de fournisseurs dans la documentation et les parcours de configuration suivent l’ordre alphabétique. La détection automatique utilise un ordre de priorité distinct et fixe, et ne choisit un fournisseur nécessitant un identifiant (requiresCredential !== false) que lorsqu’elle en trouve un configuré. Si aucun provider n’est défini, OpenClaw vérifie les fournisseurs dans l’ordre suivant et utilise le premier qui est prêt : D’abord, les fournisseurs reposant sur une API :
  1. BraveBRAVE_API_KEY ou plugins.entries.brave.config.webSearch.apiKey (ordre 10)
  2. MiniMax SearchMINIMAX_CODE_PLAN_KEY / MINIMAX_CODING_API_KEY / MINIMAX_OAUTH_TOKEN / MINIMAX_API_KEY ou plugins.entries.minimax.config.webSearch.apiKey (ordre 15)
  3. Geminiplugins.entries.google.config.webSearch.apiKey, GEMINI_API_KEY ou models.providers.google.apiKey (ordre 20)
  4. Grok — OAuth xAI, XAI_API_KEY ou plugins.entries.xai.config.webSearch.apiKey (ordre 30)
  5. KimiKIMI_API_KEY / MOONSHOT_API_KEY ou plugins.entries.moonshot.config.webSearch.apiKey (ordre 40)
  6. PerplexityPERPLEXITY_API_KEY / OPENROUTER_API_KEY ou plugins.entries.perplexity.config.webSearch.apiKey (ordre 50)
  7. FirecrawlFIRECRAWL_API_KEY ou plugins.entries.firecrawl.config.webSearch.apiKey (ordre 60)
  8. ExaEXA_API_KEY ou plugins.entries.exa.config.webSearch.apiKey ; l’option facultative plugins.entries.exa.config.webSearch.baseUrl remplace le point de terminaison Exa (ordre 65)
  9. TavilyTAVILY_API_KEY ou plugins.entries.tavily.config.webSearch.apiKey (ordre 70)
  10. Parallel — API Parallel Search payante via PARALLEL_API_KEY ou plugins.entries.parallel.config.webSearch.apiKey ; l’option facultative plugins.entries.parallel.config.webSearch.baseUrl remplace le point de terminaison (ordre 75)
Ensuite, les fournisseurs avec un point de terminaison configuré :
  1. SearXNGSEARXNG_BASE_URL ou plugins.entries.searxng.config.webSearch.baseUrl (ordre 200)
Les fournisseurs sans clé tels que Parallel Search (Free), DuckDuckGo, Ollama Web Search et Codex Hosted Search ne sont jamais sélectionnés par la détection automatique, même s’ils disposent d’une valeur d’ordre interne. Ils ne sont utilisés que lorsque vous les sélectionnez explicitement avec tools.web.search.provider ou via openclaw configure --section web. OpenClaw n’envoie pas les requêtes web_search gérées à un fournisseur sans clé simplement parce qu’aucun fournisseur reposant sur une API n’est configuré. Les modèles OpenAI Responses constituent une exception : tant que tools.web.search.provider n’est pas défini, ils utilisent la recherche Web native d’OpenAI au lieu des fournisseurs gérés ci-dessus (voir plus bas). Définissez tools.web.search.provider sur parallel-free (ou un autre fournisseur) pour les acheminer plutôt par le parcours géré.
Tous les champs de clé des fournisseurs prennent en charge les objets SecretRef. Les SecretRefs propres aux Plugins sous plugins.entries.<plugin>.config.webSearch.apiKey sont résolues pour les fournisseurs de recherche Web installés reposant sur une API, notamment Brave, Exa, Firecrawl, Gemini, Grok, Kimi, MiniMax, Parallel, Perplexity et Tavily, que le fournisseur soit choisi explicitement via tools.web.search.provider ou sélectionné par la détection automatique. En mode de détection automatique, OpenClaw résout uniquement la clé du fournisseur sélectionné ; les SecretRefs non sélectionnées restent inactives, ce qui vous permet de conserver plusieurs fournisseurs configurés sans payer le coût de résolution de ceux que vous n’utilisez pas.

Recherche Web native d’OpenAI

Les modèles OpenAI Responses directs (api: "openai-responses", fournisseur openai, sans URL de base ou avec une URL de base officielle de l’API OpenAI) utilisent automatiquement l’outil web_search hébergé d’OpenAI lorsque la recherche web OpenClaw est activée et qu’aucun fournisseur géré n’est épinglé. Ce comportement appartient au fournisseur dans le Plugin OpenAI intégré et ne s’applique pas aux URL de base de proxys compatibles avec OpenAI ni aux routes Azure. Définissez tools.web.search.provider sur un autre fournisseur tel que brave pour conserver l’outil web_search géré pour les modèles OpenAI, ou définissez tools.web.search.enabled: false pour désactiver à la fois la recherche gérée et la recherche native d’OpenAI.

Recherche web native de Codex

L’environnement d’exécution app-server de Codex utilise automatiquement l’outil web_search hébergé de Codex lorsque la recherche web est activée et qu’aucun fournisseur géré n’est sélectionné. La recherche hébergée native et l’outil dynamique web_search géré d’OpenClaw sont mutuellement exclusifs, de sorte que la recherche gérée ne peut pas contourner les restrictions de domaine natives. OpenClaw utilise l’outil géré lorsque la recherche hébergée est indisponible, explicitement désactivée ou remplacée par un fournisseur géré sélectionné. OpenClaw maintient désactivée l’extension autonome web.run de Codex (features.standalone_web_search: false), car le trafic app-server de production rejette son espace de noms web défini par l’utilisateur.
  • Configurez la recherche native sous tools.web.search.openaiCodex
  • Définissez tools.web.search.provider: "codex" pour provisionner Codex Hosted Search en tant que fournisseur web_search géré pour n’importe quel modèle parent. Chaque appel exécute un tour app-server Codex éphémère et borné, et échoue si Codex n’émet pas d’élément webSearch hébergé.
  • mode: "cached" est la préférence par défaut, mais Codex la résout en accès externe en direct pour les tours app-server sans restriction ; définissez "live" pour demander explicitement un accès en direct
  • Définissez tools.web.search.provider sur un fournisseur géré tel que brave pour utiliser le web_search géré d’OpenClaw à la place
  • Définissez tools.web.search.openaiCodex.enabled: false pour désactiver la recherche hébergée par Codex ; les autres fournisseurs gérés restent disponibles
  • La restriction de la surface d’outils native de Codex maintient également le web_search géré disponible
  • Lorsque allowedDomains est défini, le repli géré automatique échoue de manière fermée si la recherche hébergée est indisponible, afin que la liste d’autorisation native ne puisse pas être contournée
  • Les exécutions uniquement par LLM avec les outils désactivés désactivent à la fois la recherche native et la recherche gérée
  • tools.web.search.enabled: false désactive à la fois la recherche gérée et la recherche native
Les modifications persistantes de la politique de recherche Codex effective démarrent un nouveau fil lié, afin qu’un fil app-server déjà chargé ne puisse pas conserver un accès obsolète à la recherche hébergée. Les restrictions transitoires par tour utilisent un fil temporaire restreint et préservent la liaison existante pour une reprise ultérieure. Le trafic OpenAI ChatGPT Responses direct peut également utiliser l’outil web_search hébergé d’OpenAI. Ce chemin distinct reste optionnel via tools.web.search.openaiCodex.enabled: true et s’applique uniquement aux modèles openai/* admissibles utilisant api: "openai-chatgpt-responses".
Pour les environnements d’exécution et les fournisseurs qui ne prennent pas en charge la recherche Codex native, Codex peut utiliser le repli web_search géré via l’espace de noms d’outils dynamique d’OpenClaw. Utilisez un fournisseur géré explicite lorsque vous avez besoin des contrôles réseau propres au fournisseur d’OpenClaw plutôt que de la recherche hébergée par Codex. La sélection de provider: "codex" active le Plugin codex intégré et utilise les mêmes restrictions tools.web.search.openaiCodex présentées ci-dessus. Authentifiez d’abord l’app-server Codex avec openclaw models auth login --provider openai. L’agent parent peut utiliser n’importe quel modèle ou environnement d’exécution ; seul le processus de recherche borné s’exécute via Codex.

Sécurité réseau

Les appels de fournisseurs web_search HTTP gérés utilisent le chemin de récupération protégé d’OpenClaw, limité au nom d’hôte propre au fournisseur actuel. Pour ce nom d’hôte uniquement, OpenClaw autorise les réponses DNS de fausses adresses IP de Surge, Clash et sing-box dans 198.18.0.0/15 et fc00::/7. Les autres destinations privées, local loopback, locales au lien et de métadonnées restent bloquées. Codex Hosted Search constitue l’exception : son processus borné délègue l’accès réseau à l’outil web_search hébergé de l’app-server Codex. Cette autorisation automatique ne s’applique pas aux URL web_fetch arbitraires. Pour web_fetch, activez explicitement tools.web.fetch.ssrfPolicy.allowRfc2544BenchmarkRange et tools.web.fetch.ssrfPolicy.allowIpv6UniqueLocalRange uniquement lorsque votre proxy de confiance possède ces plages synthétiques.

Configuration

La configuration propre au fournisseur (clés d’API, URL de base, modes) se trouve sous plugins.entries.<plugin>.config.webSearch.*. Gemini peut également réutiliser models.providers.google.apiKey et models.providers.google.baseUrl comme replis de priorité inférieure après sa configuration dédiée de recherche web et GEMINI_API_KEY. Consultez les pages des fournisseurs pour obtenir des exemples. Grok peut également réutiliser un profil d’authentification OAuth xAI provenant de openclaw models auth login --provider xai --method oauth ; la configuration par clé d’API reste le repli. tools.web.search.provider est validé par rapport aux identifiants de fournisseurs de recherche web déclarés par les manifestes des Plugins intégrés et installés. Une faute de frappe telle que "brvae" fait échouer la validation de la configuration au lieu de revenir silencieusement à la détection automatique. Si un fournisseur configuré ne dispose que de traces de Plugin obsolètes, comme un bloc plugins.entries.<plugin> restant après la désinstallation d’un Plugin tiers, OpenClaw maintient un démarrage résilient et signale un avertissement afin que vous puissiez réinstaller le Plugin ou exécuter openclaw doctor --fix pour nettoyer la configuration obsolète. La sélection du fournisseur de repli web_fetch est distincte :
  • choisissez-le avec tools.web.fetch.provider
  • ou omettez ce champ et laissez OpenClaw détecter automatiquement le premier fournisseur web-fetch prêt à l’emploi à partir des identifiants configurés
  • web_fetch hors bac à sable peut utiliser les fournisseurs de Plugins installés qui déclarent contracts.webFetchProviders ; les récupérations en bac à sable autorisent les fournisseurs intégrés et les installations vérifiées de Plugins officiels, mais excluent les Plugins externes tiers
  • le Plugin Firecrawl officiel est actuellement le seul contributeur intégré à webFetchProviders, configuré sous plugins.entries.firecrawl.config.webFetch.*
Lorsque vous choisissez Kimi pendant openclaw onboard ou openclaw configure --section web, OpenClaw peut également demander :
  • la région de l’API Moonshot (https://api.moonshot.ai/v1 ou https://api.moonshot.cn/v1)
  • le modèle de recherche web Kimi par défaut (kimi-k2.6 par défaut)
Pour x_search, configurez plugins.entries.xai.config.xSearch.*. Il utilise le même profil d’authentification xAI que la discussion, ou l’identifiant XAI_API_KEY / de recherche web du Plugin utilisé par la recherche web Grok. L’ancienne configuration tools.web.x_search.* est migrée automatiquement par openclaw doctor --fix. Lorsque vous choisissez Grok pendant openclaw onboard ou openclaw configure --section web, OpenClaw propose également une configuration facultative de x_search avec le même identifiant, juste après la fin de la configuration de Grok. Il s’agit d’une étape de suivi distincte au sein du parcours Grok, et non d’un choix distinct de fournisseur de recherche web de premier niveau. Si vous choisissez un autre fournisseur, OpenClaw n’affiche pas l’invite x_search.

Stockage des clés d’API

Exécutez openclaw configure --section web ou définissez directement la clé :

Paramètres de l’outil

Tous les paramètres ne fonctionnent pas avec tous les fournisseurs. Le mode llm-context de Brave rejette ui_lang ; date_before nécessite également date_after, car les plages de fraîcheur personnalisées de Brave requièrent une date de début et une date de fin. Gemini, Grok et Kimi renvoient une réponse synthétisée unique avec des citations. Ils acceptent count pour la compatibilité avec l’outil partagé, mais cela ne modifie pas la forme de la réponse étayée. Gemini traite la fraîcheur day comme une indication de récence ; les valeurs de fraîcheur plus larges et les dates explicites définissent des plages temporelles pour l’étayage par Google Search. Perplexity se comporte de la même manière lorsque vous utilisez le chemin de compatibilité Sonar/OpenRouter (plugins.entries.perplexity.config.webSearch.baseUrl / model ou OPENROUTER_API_KEY) ; ce chemin supprime également la prise en charge de max_tokens et max_tokens_per_page. SearXNG accepte http:// uniquement pour les hôtes de réseau privé de confiance ou local loopback ; les points de terminaison SearXNG publics doivent utiliser https://. Firecrawl et Tavily ne prennent en charge que query et count via web_search — utilisez leurs outils dédiés pour les options avancées.
x_search interroge les publications X (anciennement Twitter) à l’aide de xAI et renvoie des réponses synthétisées par l’IA avec des citations. Il accepte les requêtes en langage naturel et des filtres structurés facultatifs. OpenClaw construit l’outil x_search intégré de xAI pour chaque requête au lieu de le maintenir enregistré en permanence ; il n’est donc actif que pendant le tour qui l’appelle effectivement.
x_search s’exécute sur les serveurs de xAI. xAI facture 5 $ pour 1 000 appels d’outil, auxquels s’ajoutent les jetons d’entrée et de sortie du modèle.
La documentation de xAI indique que x_search prend en charge la recherche par mot-clé, la recherche sémantique, la recherche d’utilisateurs et la récupération de fils de discussion. Pour les statistiques d’engagement par publication, telles que les republications, les réponses, les favoris ou les vues, privilégiez une recherche ciblée sur l’URL exacte de la publication ou l’identifiant de statut. Les recherches générales par mot-clé peuvent trouver la bonne publication, mais renvoyer des métadonnées par publication moins complètes. Une bonne méthode consiste à localiser d’abord la publication, puis à exécuter une seconde requête x_search centrée sur cette publication exacte.
Lorsque enabled est omis, x_search n’est exposé que lorsque le fournisseur du modèle actif est xai et que les identifiants xAI sont disponibles. Pour un modèle actif associé à un fournisseur connu autre que xAI, définissez plugins.entries.xai.config.xSearch.enabled sur true afin d’autoriser l’utilisation entre fournisseurs. Si le fournisseur du modèle actif est absent ou non résolu, l’outil reste masqué. Définissez enabled sur false pour le désactiver pour tous les fournisseurs. Les identifiants xAI sont toujours requis.
x_search envoie une requête à <baseUrl>/responses lorsque plugins.entries.xai.config.xSearch.baseUrl est défini. Si ce champ est omis, il utilise successivement plugins.entries.xai.config.webSearch.baseUrl, l’ancien tools.web.search.grok.baseUrl, puis le point de terminaison public de xAI (https://api.x.ai/v1). allowed_x_handles et excluded_x_handles sont mutuellement exclusifs.

Exemples

Profils d’outils

Si vous utilisez des profils d’outils ou des listes d’autorisation, ajoutez web_search, x_search ou group:web :

Voir aussi