L’outil PDF d’OpenClaw

L’outil PDF analyse un ou plusieurs documents PDF et renvoie du texte. Sur les modèles Anthropic et Google, il utilise l’entrée de document native, en envoyant les octets bruts au fournisseur comme partie de document ; sur tout autre fournisseur, il se replie sur l’extraction de texte et d’images. Ce que les gens ratent, c’est que l’outil n’existe que quand un modèle capable de lire des PDF peut être résolu et authentifié pour l’agent. Voici cet ordre de résolution, les entrées, les deux modes et ce que chacun interdit, la configuration, et les erreurs.

Quand l’outil existe

• Ordre de résolution : un modèle PDF explicite avec principal et replis, puis un modèle d’image explicite, puis le modèle de session ou par défaut résolu de l’agent si son fournisseur prend en charge l’entrée PDF native ou a déjà un modèle de vision configuré, puis les fournisseurs à vision détectés automatiquement avec une authentification utilisable, les fournisseurs à PDF natif d’abord.
• Chaque candidat de repli est vérifié pour l’authentification avant usage, si bien qu’un fournisseur et un modèle configurés ne comptent que si OpenClaw peut authentifier ce fournisseur pour l’agent.
• Les entrées : un chemin ou une URL de PDF, ou jusqu’à dix dans une liste, fusionnés et dédoublonnés ; un prompt d’analyse avec une valeur par défaut ; un filtre de pages comme une plage ou une liste séparée par des virgules, lu en pages à partir de un, dédoublonné, trié et plafonné à la limite de vingt pages ; un mot de passe pour les fichiers chiffrés ; un modèle de remplacement facultatif ; et un plafond de taille par fichier de dix mégaoctets par défaut.
• Les références : un chemin local avec expansion du tilde, une URL de fichier, une URL HTTP ou HTTPS, ou une référence de média entrant gérée par OpenClaw ; les autres schémas renvoient une erreur de référence non prise en charge, les URL distantes sont rejetées quand l’outil tourne en bac à sable, et une politique de fichiers limitée à l’espace de travail rejette les chemins locaux hors des racines autorisées tout en permettant les références entrantes gérées.

Si aucun modèle utilisable n’est résolu, l’outil pdf n’est pas exposé.

Les deux modes

Le mode natif sert pour les deux fournisseurs qui déclarent la prise en charge native des documents PDF : les octets bruts vont directement à l’API du fournisseur comme partie de document native par fichier, et deux paramètres lèvent une erreur, le filtre de pages et le mot de passe, si bien qu’un PDF chiffré exige un modèle non natif. Le mode d’extraction sert pour tous les autres : l’extension intégrée d’extraction de documents, construite sur un paquet PDFium en WebAssembly, extrait le texte des pages choisies jusqu’au plafond de pages ; si le texte extrait fait moins de deux cents caractères, les mêmes pages sont rendues en PNG dans un budget total de quatre millions de pixels partagé proportionnellement entre les pages qui ont besoin d’images, si bien que les pages avec assez de texte sautent le rendu ; puis le texte, les images éventuelles et le prompt vont au modèle choisi. L’extraction tourne dans un worker réutilisable pour ne jamais bloquer la passerelle, annuler l’exécution l’arrête, un modèle sans entrée d’image et sans texte extractible est une erreur, un rendu échoué abandonne les images et continue, et un modèle texte seul ne reçoit que du texte.

Configuration, sortie, erreurs

• Trois clés sous les valeurs par défaut des agents : le modèle PDF avec principal et replis, qui retombe sur le modèle d’image puis sur le modèle de session ; le plafond de taille par fichier, dix par défaut ; et le plafond de pages, vingt par défaut.
• L’analyse revient à la fois comme texte de contenu et dans les détails, si bien que Code Mode et la recherche d’outils lisent le même résultat ; les détails portent aussi le modèle résolu, un indicateur natif, les tentatives de repli échouées avant le succès, le ou les chemins, et toute réécriture de chemin par le bac à sable.
• Les erreurs : aucune entrée lève une erreur qui demande un chemin ou une URL ; plus de dix PDF, ou un schéma de référence non pris en charge, reviennent comme codes d’erreur dans les détails ; le filtre de pages ou le mot de passe avec un fournisseur natif lève le message de non-prise en charge correspondant.

OpenClaw avec Claude et OpenClaw et Gemini sont les deux configurations de fournisseurs où le chemin natif s’applique.

Choisir le modèle pour les documents

Le conseil pratique découle des modes : pour les documents scannés ou chiffrés, ou quand il vous faut un filtre de pages, pointez le modèle PDF vers un fournisseur qui prend le chemin d’extraction et accepte les images ; pour des documents texte propres sur Claude ou Gemini, le chemin natif est un seul appel sans étape d’extraction. Modèles et fournisseurs d’OpenClaw couvre le choix de fournisseur et de modèle que parcourt l’ordre de résolution, et Le bac à sable d’OpenClaw expliqué explique pourquoi une exécution en bac à sable ne peut pas récupérer une URL distante.

Sur Diali

Sur Diali, l’outil PDF suit le modèle que vous avez choisi : avec Claude ou Gemini il lit le document en natif, avec tout autre le chemin d’extraction tourne dans l’instance. OpenClaw hébergé sur Diali est l’assistant.

• Pas de modèle capable de lire des PDF, pas d’outil.
• Natif sur Claude et Gemini ; extraction, puis images, ailleurs.
• Pages et mots de passe, seulement en extraction.