L'outil shell n'est pas une solution miracle pour l'ingénierie du contexte

Les outils les plus importants dont dispose un agent sont les outils de rechercher qu’il peut utiliser pour construire son propre contexte. Les récents articles de LlamaIndex et LangChain ont suscité une discussion : un outil shell et un système de fichiers sont-ils tout ce dont un agent a besoin pour l’ingénierie du contexte ? Malheureusement, la discussion a rapidement dévié sur un sujet inapproprié : système de fichiers contre base de données.

Ce billet se concentre sur la question suivante : quelles sont les bonnes interfaces de recherche dont un agent a besoin pour construire son propre contexte ? Il couvre d'abord les compromis entre les outils de shell et les outils de base de données dédiés. Il propose ensuite un framework pratique pour trouver les interfaces adaptées aux besoins de votre agent.

Que signifie concrètement pour un agent le terme « contexte de construction » ?

Dans les premiers pipelines de Retrieval-Augmented Generation (RAG), le développeur concevait un pipeline de recherche fixe, et le grand modèle de langage (LLM) était un récepteur passif du contexte. C'était une limitation fondamentale : le contexte était récupéré à chaque requête, qu'il soit nécessaire ou non, sans vérification qu'il aidait réellement.

Avec le passage au RAG agentique, les agents ont désormais accès à un ensemble d’outils de recherche pour construire leur propre contexte. Par exemple, Claude Code [1] et Cursor [2] permettent tous deux à l’agent de choisir entre différents outils de recherche et même de les combiner pour des requêtes chaînées, en fonction de ce que la tâche exige réellement.

Quelles interfaces de recherche existent pour l'ingénierie contextuelle ?

Le contexte peut se trouver à différents endroits, par exemple sur le Web, dans un système de fichiers local ou dans une base de données. Un agent peut interagir avec chacune de ces sources de données hors contexte à l'aide de différents outils :

• Les outils Shell peuvent exécuter des commandes shell et accéder au système de fichiers local. Quelques exemples d’outils shell intégrés sont l’outil bash de Claude API, l’outil exécutif d’OpenClaw, et l’outil shell de LangChain.
• Les outils de base de données dédiés, tels que les outils d’un serveur Model Context Protocol (MCP) (par exemple, le serveur MCP Elastic Agent Builder) ou les outils personnalisés (par exemple, run_esql(query) ou db_list_index()), peuvent interroger les bases de données.
• Les outils de recherche de fichiers dédiés peuvent rechercher et lire des fichiers locaux (ou téléchargés) (sans accès complet au shell). Quelques exemples d'outils de recherche de fichiers intégrés sont l'outil de recherche de fichiers de Gemini API ou l'outil de recherche de fichiers d'OpenAI.
• Les outils de recherche Web peuvent extraire des informations du web.
• Les outils de mémoire stockent et rappellent la mémoire à long terme (quelle que soit la manière dont elle est stockée).

Comme vous pouvez le voir, l’outil shell est polyvalent et peut être utilisé pour récupérer du contexte à partir de différentes sources de données, notamment :

• Système de fichiers : l'agent explore la structure des répertoires (ls, find), recherche le contenu pertinent (grep, cat) et répète l'opération jusqu'à ce qu'il ait construit un contexte suffisant.
• Base de données : l’agent peut utiliser des outils d’interface en ligne de commande (CLI) de base de données (par exemple, elasticsearch-sql-cli), appeler des API HTTP via curl, ou exécuter des scripts, ce qui est particulièrement utile en combinaison avec les compétences de l’agent, qui sont des exemples réutilisables et documentés injectés dans le contexte de l’agent pour guider l’utilisation correcte des outils (par exemple, Elastic Agent Skills pour Elasticsearch).
• Web : l’agent peut exécuter des recherches web via une commande curl à travers l’API d’un fournisseur de recherche.

Cependant, l'outil shell fournit un accès système direct et nécessite donc des mesures de sécurité, telles que l'exécution dans un environnement sandbox isolé et le logging de toutes les commandes exécutées.

Quand utiliser quelles interfaces de recherche

L'interface de recherche appropriée dépend de vos données, de vos modèles de requête et de votre cas d'utilisation. Cette section constitue un point de départ pratique.

Les systèmes de fichiers ne rendent pas les bases de données obsolètes

Le débat entre systèmes de fichiers et bases de données ne porte pas sur la couche de stockage. Par exemple, LangChain explique que son système de mémoire ne stocke pas réellement la mémoire dans un véritable système de fichiers. Au lieu de cela, il stocke la mémoire dans une base de données et la représente sous la forme d'un ensemble de fichiers pour l'agent [3].

Les systèmes de fichiers sont particulièrement adaptés aux cas d'utilisation natifs basés sur les fichiers, tels que les agents de codage. Ils fonctionnent également bien comme bloc-notes temporaire ou mémoire de travail pour les scénarios à utilisateur unique ou à agent unique où la concurrence n'est pas une préoccupation. Dans ces cas, un système de fichiers physique ou la représentation des données sous forme de système de fichiers vous offre une certaine flexibilité avant de vous engager dans une interface dédiée.

Mais le stockage par système de fichiers présente de réels inconvénients, tels qu'une faible concurrence, l'application manuelle du schéma et les transactions atomiques. Ces problèmes deviennent plus évidents lorsque votre application doit scaler ou passer à un scénario multi-agents. Quiconque ignore ces inconvénients est condamné à réinventer péniblement des bases de données de moindre qualité, sans bénéficier des décennies d'ingénierie qui sous-tendent la sécurité des transactions ou le contrôle d'accès que les bases de données de production offrent déjà. De plus, dans la plupart des contextes d'entreprise, on ne choisit pas d'utiliser ou non une base de données puisqu'elle est déjà en place et stocke des données essentielles à l'activité.

Outil shell + système de fichiers

Un outil shell est le point de départ naturel pour la recherche dans le système de fichiers. Actuellement, les agents de codage sont à l'origine de nombreux progrès dans le champ. Parce qu'ils travaillent avec du code dans des fichiers locaux, ce sont naturellement des cas d'utilisation gourmands en fichiers. Par conséquent, les LLM sont affinés lors de la phase de post-entraînement pour les tâches de codage. C'est pourquoi de nombreux LLM savent non seulement écrire du code, mais aussi utiliser des commandes shell et naviguer dans les systèmes de fichiers.

L'utilisation d'un outil shell avec des CLI intégrées, comme ls et grep, pour rechercher des fichiers est efficace. Avec grep, une requête comme « Trouver tous les fichiers qui importent matplotlib» est rapide, précise et peu coûteuse. Mais lorsque l'agent doit gérer des requêtes conceptuelles, comme « Comment notre application gère-t-elle une authentification défaillante ? », La correspondance de motifs avec grep peut rapidement atteindre ses limites. Plusieurs alternatives qui apportent des capacités de recherche sémantique à la ligne de commande ont émergé pour combler ce manque, notamment jina-grep.

Cependant, grep et plusieurs de ses alternatives de recherche sémantique fonctionnent en O(n) sur le corpus. Pour les cas d'utilisation sur des bases de code, cela peut convenir. Cependant, si vos données s'accumulent, la latence deviendra perceptible. Dans ce cas, un datastore indexé devient nécessaire pour assurer la maintenance des performances.

Outil shell + base de données

Une autre façon d'ajouter des capacités de recherche, telles que la recherche sémantique ou hybride, à vos données est de les stocker dans une base de données, comme le fait Cursor, par exemple. De plus, lorsque les données nécessitent des jointures relationnelles complexes ou des agrégations, une interface de base de données est non négociable.

Lorsque les données se trouvent dans une base de données plutôt que dans le système de fichiers, un outil shell peut servir d'interface de base de données légère pour certains cas d'utilisation. Si vos requêtes sont assez simples pour une interface de ligne de commande ou un appel curl, un outil de base de données dédié peut ajouter de la complexité inutile.

Cette approche est également adaptée aux premières étapes de l’exploration, lorsque vous ne savez pas encore quels modèles de requête votre agent développera réellement. Dans ce cas, les compétences des agents peuvent donner à l’agent suffisamment de structure pour effectuer des requêtes correctement sans avoir recours à un outil spécialement conçu. Cependant, lorsque l'agent doit effectuer de nombreuses itérations pour déterminer la meilleure façon d'interroger la base de données pour des tâches répétitives, la surcharge de jetons associée à l'utilisation d'un outil shell comme interface ne justifie plus l'avantage de simplicité qu'offre l'évitement d'un outil supplémentaire.

Outil de base de données dédié

Des outils de base de données spécialisés deviennent nécessaires, surtout lorsque les modèles de requêtes répétées sont structurés ou analytiques. Un article de blog de Vercel et Braintrust a comparé des agents utilisant différents ensembles d'outils de recherche pour des tâches de récupération réelles sur des données semi-structurées, telles que les tickets de service client et les transcriptions d'appels de vente (par exemple : « Combien de problèmes ouverts mentionnent la « sécurité » ? » ou « Trouver les problèmes où quelqu'un a signalé un bug et où quelqu'un a ensuite soumis une PR prétendant le corriger ? »). [4].

Les agents utilisant des outils de base de données dédiés consommaient moins de jetons, étaient plus rapides et faisaient moins d'erreurs que ceux utilisant uniquement un outil shell et un système de fichiers. La leçon à retenir est que les outils de base de données directs constituent le meilleur choix lorsque la requête exige un raisonnement analytique sur des données semi-structurées.

Combinaison d'interfaces de recherche

Aucune interface de recherche unique ne traite correctement toutes les requêtes. Par exemple, Cursor combine des outils shell (pour les recherches via grep) et des outils de recherche sémantique, et permet à l'agent de sélectionner l'outil approprié en fonction de la requête de l'utilisateur. Ils indiquent que l'agent choisit grep pour faire correspondre des symboles ou des chaînes spécifiques, la recherche sémantique pour les questions conceptuelles ou liées au comportement, et les deux pour les tâches exploratoires.

L'expérience Vercel rapporte la même chose : son agent hybride, ayant accès à la fois à un outil en ligne de commande (shell) et à un outil de base de données dédié, a obtenu les meilleures performances parmi tous les agents testés, en utilisant d'abord les outils de base de données dédiés, puis en vérifiant les résultats en parcourant le système de fichiers avec la commande « grep ». Cependant, cette approche utilise plus de tokens et de temps pour le choix et la vérification des outils.

Le schéma est identique dans les deux exemples : la composition Beats toute interface unique, mais elle implique un compromis en termes de coût et de latence supplémentaires.

Recommandations pratiques pour trouver les bons outils

Le bon ensemble d'interfaces de recherche est restreint, ciblé et spécifique aux schémas de requêtes réels de votre agent. La bonne pratique actuelle est d'avoir un agent avec le moins d'outils possible au lieu d'avoir un agent avec des centaines d'outils MCP. En effet, le fait d'exposer d'emblée tous les outils possibles a pour inconvénient de gonfler la fenêtre contextuelle et d'embrouiller l'agent quant à l'outil à utiliser. Par exemple, Claude Code ne disposerait que d'une vingtaine d'outils.

L'idée de la divulgation progressive est plutôt de commencer avec un ensemble minimal d'outils et de laisser l'agent découvrir des capacités supplémentaires uniquement lorsqu'il en a besoin. Les recherches menées par Anthropic [5] et Cursor [6] ont montré que cette approche permet de réaliser une économie de tokens de 47%–85%. Claude Code, par exemple, implémente cela directement, permettant à l'agent de découvrir progressivement comment interroger une API ou une base de données, sans que cette connaissance ne consomme du contexte à chaque appel de LLM.

Une fois que vous vous êtes familiarisé avec les modèles de requête de l’agent, vous pouvez revoir l’ensemble des outils de recherche auxquels l’agent a accès par défaut. Une façon utile d'envisager ce compromis est le principe « plancher bas, plafond haut » pour décider quels outils doivent être retenus. Les outils à haut plafond ne limitent pas le potentiel de l’agent. Par exemple, un outil shell polyvalent permet à l’agent d’écrire des requêtes de base de données complètes, y compris celles ambiguës, mais au prix d’une surcharge de raisonnement, d’une latence plus élevée et d’une fiabilité moindre.

Les outils à plancher surbaissé sont à l'opposé. Ce sont des outils spécialisés qui répondent à des requêtes spécifiques et sont immédiatement accessibles à l'agent avec un minimum de frais de raisonnement, ce qui permet de réduire les coûts et d'accroître la fiabilité. Mais ils nécessitent un travail d’ingénierie préalable, ne peuvent pas couvrir toutes les requêtes possibles, et peuvent compliquer le choix du bon outil pour l’agent.

Pensez à chaque outil sur un spectre : les outils à seuil bas sont faciles à utiliser correctement par l'agent mais sont limités en portée. Les outils à haut potentiel sont polyvalents, mais nécessitent davantage de réflexion pour être utilisés efficacement.

La plupart des agents ont besoin d'une combinaison de différents outils de recherche. Mais chaque outil doit mériter son ajout. Nous recommandons de commencer par un outil de recherche polyvalent (par exemple un outil search_database() ou un outil shell). Réutilisez ensuite les logs de commandes que vous conservez déjà à des fins de sécurité pour suivre ce que votre agent fait réellement, y compris les appels d’outils, les nouvelles tentatives et le nombre d’appels par requête utilisateur. Et, lorsque vous voyez un modèle de requête se répéter ou échouer, c'est le signal pour créer un outil spécialement conçu à cet effet.

Résumé

Le débat système de fichiers contre base de données détourne l'attention de la véritable question que les ingénieurs doivent se poser : quelles sont les bonnes interfaces de recherche dont un agent a besoin pour construire son propre contexte ? La réponse est, selon toute vraisemblance, pas une seule.

Un outil shell est un outil polyvalent pour interagir avec différentes sources hors contexte et constitue ainsi un bon point de départ. Mais il est moins efficace et précis pour les cas d'utilisation avec des requêtes analytiques structurées que les outils de base de données dédiés.

L'objectif est de trouver l'ensemble minimal d'outils de recherche qui gère bien les modèles de requêtes réels de votre agent. Commencez avec un outil shell, et consignez ce que fait réellement votre agent dans les logs. Lorsque vous constatez qu'un schéma de requête se répète et échoue, il est temps de concevoir des outils spécialisés.

Références

1. Thariq (Anthropic). Leçons tirées de la construction du code Claude : voir comme un agent (2026).

2. Cursor : Documentation. Recherche sémantique et agentique (2026).

3. Harrison Chase (LangChain). Comment nous avons construit le système de mémoire d'Agent Builder (2026).

4. Ankur Goyal (Braintrust) et Andrew Qu (Vercel). Tester si « bash est tout ce dont vous avez besoin » (2026).

5. Anthropic. Présentation de l'utilisation d'outils avancés sur la plateforme de développement Claude (2025).

6. Cursor. Découverte dynamique du contexte (2026).