La recherche web dans OpenClaw

La recherche est l’outil vers lequel la plupart des agents se tournent en premier, et c’est aussi celui que l’on relie le plus volontiers à la première clé qui traîne. OpenClaw la traite comme une interface normalisée et non comme un simple passage : les résultats de tous les fournisseurs intégrés et externes sont remis en forme à la frontière de l’outil, si bien qu’un appelant reçoit toujours exactement une forme parmi un petit ensemble fermé. Le choix du fournisseur est explicite ou détecté automatiquement, jamais accidentel. Le même soin s’étend aux marqueurs de confiance posés sur la prose renvoyée et à ce que le chemin de récupération a le droit d’atteindre.

Trois outils, une frontière

• La recherche web interroge le fournisseur configuré et renvoie des résultats normalisés mis en cache par requête pendant 15 minutes par défaut, tandis qu’OpenClaw embarque aussi une recherche de publications X et une récupération légère, celle-ci s’exécutant toujours en local et la recherche X passant toujours par les réponses xAI.
• Les fournisseurs structurés renvoient une forme de résultats portant un titre, une URL et, en option, un extrait, une date de publication et un nom de site, les fournisseurs de synthèse renvoient une forme de réponse avec du contenu et des citations facultatives, et les charges utiles de greffons externes qui ne correspondent à aucune des deux passent telles quelles sous une forme brute.
• Les extras propres à un fournisseur comme les scores bruts, les extraits, les recherches associées, les décalages de citations en ligne, les identifiants de modèle et les métadonnées de session sont abandonnés sur les branches normalisées, si bien que l’outil dédié d’un fournisseur est le moyen de conserver sa réponse la plus riche.
• Les URL de citation et de résultat doivent s’analyser en http ou https, les dates de publication doivent avoir la forme d’une date ISO, les URL sont émises sous forme canonique, et une charge utile portant une clé d’erreur est toujours signalée comme une erreur, le code brut du fournisseur étant conservé dans le message encadré.

Un fournisseur explicitement sélectionné n’utilise pas de repli automatique.

Comment un fournisseur est choisi

Les listes de fournisseurs de la documentation et des assistants de configuration sont alphabétiques, mais la détection automatique suit un ordre de priorité distinct et figé. Elle ne retient un fournisseur exigeant des identifiants que lorsqu’elle en trouve de configurés, si bien qu’une installation vide ne se met pas à chercher en silence. Les fournisseurs à API viennent d’abord, dans l’ordre Brave, MiniMax, Gemini, Grok, Kimi, Perplexity, Firecrawl, Exa, Tavily et Parallel, le point de terminaison SearXNG auto-hébergé n’étant considéré qu’après eux tous. Si un fournisseur détecté échoue, OpenClaw essaie le suivant parmi ceux qui sont éligibles, et si toutes les tentatives échouent il rapporte l’erreur du premier fournisseur afin que la panne principale soit celle que vous voyez. Les fournisseurs sans clé comme la recherche Parallel gratuite, DuckDuckGo, la recherche web Ollama et la recherche hébergée Codex ne gagnent jamais la détection automatique même s’ils portent une valeur d’ordre interne ; ils ne servent que si vous les sélectionnez explicitement. Les modèles OpenAI Responses directs font exception et utilisent la recherche hébergée d’OpenAI tant qu’aucun fournisseur géré n’est épinglé, et l’exécution app-server de Codex fait de même avec son propre outil hébergé. La recherche hébergée native et l’outil géré s’excluent mutuellement, si bien que la recherche gérée ne peut pas contourner les restrictions de domaine natives. Le nom de fournisseur configuré est validé face aux identifiants déclarés par les manifestes des greffons intégrés et installés, si bien qu’une faute de frappe fait échouer la validation de la configuration au lieu de retomber discrètement sur la détection automatique.

Paramètres et limites des fournisseurs

• Les paramètres partagés couvrent la requête, un nombre de résultats compris entre un et dix avec cinq par défaut, des codes de pays et de langue, un filtre de fraîcheur sur le jour, la semaine, le mois ou l’année, des dates de début et de fin explicites, et une liste de domaines autorisés ou exclus réservée à Perplexity.
• Tous les paramètres ne fonctionnent pas partout : le mode llm-context de Brave refuse le paramètre de langue d’interface, une date de fin exige aussi une date de début parce que les plages de fraîcheur personnalisées de Brave demandent les deux bornes, et Firecrawl et Tavily ne prennent en charge que la requête et le nombre de résultats via l’outil partagé.
• Gemini, Grok et Kimi renvoient une seule réponse de synthèse avec citations et n’acceptent un nombre de résultats que par compatibilité avec l’outil partagé, et Gemini traite la fraîcheur du jour comme un simple indice de récence tandis que des valeurs plus larges et des dates explicites fixent les plages temporelles de l’ancrage Google Search.

Les deux moitiés de cette page ont leurs propres pages de référence : La recherche web pour l’outil de recherche et ses fournisseurs, et La récupération de pages pour tirer une URL précise et en extraire un contenu lisible. Le choix du fournisseur de récupération est distinct de celui de la recherche, et les récupérations en bac à sable acceptent les fournisseurs intégrés et les greffons officiels vérifiés mais excluent les greffons externes tiers.

Pourquoi normaliser à la frontière

C’est la normalisation à la frontière de l’outil qui donne un sens au marqueur de confiance. La prose du fournisseur, c’est-à-dire les titres, les extraits, les noms de site, le contenu des réponses, les titres de citations et les messages d’erreur, est débarrassée de toute enveloppe préexistante puis réencadrée exactement une fois, si bien qu’aucune métadonnée de fournisseur ne peut usurper le marqueur. Les charges utiles brutes conservent les marqueurs posés par le fournisseur, ce qui est le coût honnête de la prise en charge de greffons qui ne correspondent à aucune des deux formes normalisées. Le même raisonnement borne le réseau : les appels de recherche gérés utilisent le chemin de récupération protégé d’OpenClaw, limité au nom d’hôte du fournisseur courant, et ce n’est que pour ce nom d’hôte qu’il accepte les réponses DNS à fausse adresse que renvoient Surge, Clash et sing-box, les autres destinations privées, de boucle locale, de lien local et de métadonnées restant bloquées. Cette tolérance ne s’applique pas aux URL de récupération arbitraires, qui exigent leurs propres options explicites avant que les plages synthétiques d’un mandataire de confiance ne soient permises. La recherche est aussi délibérément légère, un outil HTTP et non de l’automatisation de navigateur, si bien que les sites riches en JavaScript et les connexions relèvent plutôt de Le navigateur web. Et comme chaque résultat atterrit dans la fenêtre du modèle, la durée du cache et le nombre de résultats relèvent autant d’une décision de La gestion du contexte que d’une question de coût.

Sur Diali

Sur Diali, OpenClaw hébergé sur Diali tourne comme un assistant par client, avec une configuration d’exécution générée depuis le tableau de bord et remplacée à chaque version. L’état vit sur un volume persistant, avec des instantanés quotidiens et une restauration en un clic grâce à l’option Sauvegardes (incluse avec Max). Le détail des offres se trouve sur Les tarifs Diali.

• Un outil, des formes de résultats fermées, un marqueur posé à la frontière.
• La détection ne retient qu’un fournisseur déjà pourvu d’identifiants.
• Les fournisseurs sans clé se choisissent, ils ne gagnent jamais seuls.