Stratégies d’ingénierie du contexte pour les agents IA : guide du développeur
Construire des agents d’IA fiables est plus difficile qu’il n’y paraît. Ils commencent souvent fort, mais à mesure que les tâches deviennent plus complexes, des fissures apparaissent. Les agents perdent souvent le fil des étapes précédentes, contredisent leur propre raisonnement ou se retrouvent submergés par la complexité d’un contexte trop abondant.
Ce défi a suscité un vif débat dans tout le secteur. Récemment, Anthropic (Claude) et Cognition (Devin) se sont affrontés sur la question de savoir si la collaboration multi-agents ou la conception à agent unique est la meilleure voie à suivre. Anthropic a mis en avant des expériences montrant que les configurations multi-agents atteignent des taux de réussite supérieurs de 90,2 %, tandis que Cognition a répliqué que les agents uniques avec compression de contexte long offrent une plus grande stabilité et des coûts plus faibles.
Les deux camps ont de bons arguments et, en réalité, débattent du même problème central : comment gérer efficacement le contexte des agents.
Imaginez les LLM comme des CPU et leurs fenêtres de contexte comme de la RAM. Mais il y a un hic : avec le matériel, vous pouvez toujours ajouter plus de RAM. Avec les LLM, la longueur du contexte est plafonnée par conception, et l’étendre davantage entraîne des coûts élevés en matière de vitesse et de précision. Les agents, quant à eux, génèrent d’énormes quantités d’informations lors de workflows en plusieurs étapes, atteignant rapidement ces limites. Cela crée des problèmes critiques :
Surcharge d’informations : le contexte dépasse la capacité → l’agent plante
Coûts croissants : plus de tokens traités signifie des dépenses et une latence plus élevées
Frein aux performances : l’excès d’informations ne rend pas les agents plus intelligents — il les rend plus lents et moins précis
C’est pourquoi l’ingénierie du contexte est devenue un défi de conception central pour les agents de nouvelle génération. Les leaders du secteur ont déjà essayé différentes façons de relever ce défi, dont beaucoup fonctionnent en fait très bien.
Dans ce blog, nous explorerons comment LangChain, Lossfunk et Manus abordent le problème sous différents angles — en proposant des stratégies complémentaires pour garder les agents à la fois capables et rentables.
Les 4 stratégies de LangChain pour résoudre les défis du contexte des agents
LangChain regroupe les défis du contexte des agents en quatre modes de défaillance courants :
Empoisonnement du contexte : des détails non pertinents ou incorrects s’immiscent, conduisant à des sorties absurdes.
Distraction du contexte : les informations critiques se retrouvent noyées dans le bruit.
Confusion du contexte : trop de données sans rapport font perdre le fil à l’agent.
Conflit de contexte : des entrées contradictoires entraînent un comportement incohérent.
Pour relever ces défis, LangChain a introduit un cadre en quatre stratégies pour l’ingénierie du contexte des agents : Écrire, Sélectionner, Compresser et Isoler.
#1 Écrire le contexte : Donner aux agents une mémoire externe
Les humains résolvent des problèmes en prenant des notes et en transmettant les connaissances acquises. Les agents apprennent à faire de même. Une approche courante est le « scratchpad », où les raisonnements intermédiaires et les découvertes sont enregistrés en dehors de la fenêtre de contexte. Par exemple, lors de revues de code, au lieu de rescanner toute la base de code, un agent peut consigner les problèmes et les correctifs par fichier. Au fil du temps, cela construit une mémoire persistante et interrogeable qui s’enrichit avec l’expérience.
#2 Sélectionner le contexte : Filtrer selon la pertinence
Toutes les informations ne méritent pas l’attention. L’équipe Windsurf a démontré que naviguer dans de grandes bases de code nécessite de combiner l’analyse syntaxique avec la recherche dans un graphe de connaissances, afin de garantir que les agents fassent ressortir uniquement les extraits pertinents au lieu de se noyer dans des lignes sans rapport.
#3 Compresser le contexte : Résumé à la demande
Claude Code illustre bien cette approche avec sa fonctionnalité « auto-compact ». Lorsqu’une conversation approche de la limite de contexte, le système compresse des centaines de tours en un résumé concis, en préservant les détails essentiels à la tâche tout en libérant de l’espace pour un nouveau raisonnement.
#4 Isoler le contexte : gestion modulaire du contexte
LangGraph applique ce principe au moyen d’une architecture multi-agents. Les tâches complexes sont divisées en modules, chaque sous-agent fonctionnant dans son propre espace de contexte. Cette séparation évite les interférences : un agent peut explorer des alternatives sans contaminer le chemin de raisonnement d’un autre.
Pour plus de détails, consultez le blog de LangChain sur l’ingénierie du contexte.
Les 6 conseils pratiques de Lossfunk sur l’ingénierie du contexte
Un autre point de vue vient de Lossfunk, qui traite la gestion du contexte comme une discipline d’ingénierie fondée sur le déploiement en conditions réelles. Leur approche met l’accent sur l’équilibre entre trois contraintes auxquelles toute équipe de production est confrontée : performance, fiabilité et coût. Paras Chopra, fondateur de Lossfunk, a présenté six conseils pratiques pour construire des agents LLM efficaces avec le contexte.
#1 Des tâches plus petites, un taux de réussite plus élevé
Les tâches complexes peuvent submerger les agents tout comme elles submergent les humains. Une recherche de METR montre que les LLM atteignent leurs taux de réussite les plus élevés — environ 90 % — lorsque les tâches sont limitées à 10–15 minutes de travail. Au lieu de demander à un agent de refactoriser une application entière en une seule exécution, découpez le projet en étapes plus petites et atomiques : analyser le module d’authentification, identifier les problèmes de sécurité potentiels, puis proposer des correctifs ciblés. Cela reflète la manière dont les développeurs expérimentés travaillent : une étape ciblée à la fois, avec des progrès qui se construisent progressivement.
Source : Mesurer la capacité de l’IA à accomplir des tâches longues
#2 Fichiers entiers > récupération fragmentée
Contrairement à l’accent mis par LangChain sur le filtrage et la compression, Paras soutient que plus de contexte est généralement préférable. Son point de vue est que les systèmes RAG fragmentent souvent l’information en petits morceaux incomplets, ce qui peut laisser les agents confus ou incertains. Il suggère plutôt de charger des fichiers ou des jeux de données complets directement dans la fenêtre de contexte, afin de donner au modèle une vision d’ensemble.
Lossfunk étaye cette perspective par des preuves issues de benchmarks. Sur SWE-bench-Verified, les approches utilisant un contexte de fichier complet ont atteint environ 95 % de précision, contre environ 80 % pour la récupération fragmentée. La différence vient de la cohérence : avec des fichiers complets, le modèle voit les relations dans l’ensemble du document au lieu d’assembler des morceaux disjoints.
Bien sûr, cela implique des compromis. Fournir davantage de contexte aux agents LLM augmente à la fois le coût et la latence. Les équipes doivent mettre en balance les avantages de l’exhaustivité avec le coût de prompts plus longs — un équilibre qui dépend de la tâche et des contraintes de production.
#3 Ajouter une étape de vérification après chaque tâche
Les erreurs ont tendance à s’accumuler le long de longues chaînes de raisonnement. Pour réduire ce risque, Lossfunk suggère de concevoir chaque étape comme une fonction sans état avec des contrôles explicites de réussite/échec. Après chaque appel d’outil ou action de raisonnement, l’agent doit confirmer si l’opération a réussi et indiquer clairement l’étape suivante.
Ce schéma est similaire aux tests unitaires en développement logiciel : détecter les petites erreurs tôt avant qu’elles ne se transforment en échecs plus importants. En intégrant la vérification, les développeurs créent des points de récupération naturels qui rendent les agents plus résilients dans les workflows de production.
#4 Rappeler fréquemment le modèle
Les modèles oublient souvent les instructions initiales dans les longues conversations, il est donc essentiel de renforcer continuellement les objectifs de la tâche et l’état actuel. Injectez régulièrement des résumés de tâche et les objectifs actuels dans vos prompts. Ne supposez pas que le modèle se souvient de ce qu’il était censé faire 50 échanges plus tôt. Ce n’est pas une limitation — c’est simplement ainsi que fonctionne la cognition humaine. Nous utilisons des aides-mémoire externes, comme des notes et des rappels, pour rester sur la bonne voie lors de tâches complexes.
#5 Équiper les agents d’outils de lecture/écriture pour construire le contexte à la demande
Entasser chaque information dans la fenêtre de contexte mène rapidement à la surcharge. Une meilleure approche consiste à donner aux agents des outils de lecture/écriture afin qu’ils puissent récupérer ou enregistrer des informations selon les besoins. Au lieu de précharger des ensembles complets de documentation, équipez votre agent de lecteurs de fichiers ou de connecteurs de base de données et laissez-le extraire les détails pertinents à la demande.
Cela reflète la manière dont opèrent les développeurs expérimentés : ils ne mémorisent pas une base de code entière, mais ils savent comment trouver la bonne fonction ou le bon fichier lorsque le besoin se présente. En dotant les agents de la capacité d’interroger et de mettre à jour des sources externes, les développeurs peuvent garder un contexte léger tout en s’assurant que l’agent a accès aux connaissances dont il a besoin.
#6 Garder le contexte immuable pour tirer parti du cache KV
Chaque tour de conversation avec un contexte fortement changeant peut devenir extrêmement coûteux — dépassant parfois 100 $ par réponse. Pour tirer parti des optimisations du cache KV, gardez autant que possible le contexte immuable. Au lieu de remplacer le contexte à chaque étape, ajoutez de nouvelles informations et maintenez des formats cohérents et structurés au fil des interactions.
Cet ajustement technique apparemment mineur peut apporter des bénéfices disproportionnés : réduire les coûts d’un ordre de grandeur tout en améliorant les temps de réponse. Pour les déploiements en production, c’est l’une des optimisations de bas niveau les plus efficaces que les développeurs puissent appliquer.
Pour plus de détails, consultez ce blog de Paras.
Manus : 7 leçons tirées de la création d’agents
Manus est un système d’IA entièrement autonome et multi-agent, conçu pour gérer des tâches complexes avec un minimum de supervision humaine — de la recherche à la gestion de projet. Dans le cadre de leurs travaux, l’équipe Manus a partagé des leçons pratiques sur l’ingénierie du contexte tirées de l’exploitation de leur système en production.
#1 Concevoir autour du KV-cache pour l’efficacité des coûts
Pour les agents de niveau production, l’un des indicateurs de performance les plus critiques est le taux de réussite du KV-cache, qui a un impact direct à la fois sur le coût et le temps de réponse. Les entrées des agents modernes deviennent de plus en plus longues — avec un contexte étendu et des enregistrements détaillés des appels d’outils — tandis que les sorties restent concises, ressemblant souvent à des appels de fonction. Ce décalage entraîne des coûts de préremplissage disproportionnellement élevés.
L’approche recommandée consiste à garder les préfixes de prompt stables et à éviter les éléments qui perturbent le cache, comme les horodatages qui changent à chaque requête. Utilisez une stratégie de contexte en ajout uniquement au lieu de réécrire le contenu existant, et imposez un ordre déterministe pour la sérialisation JSON. Certains frameworks de modèles nécessitent également de marquer explicitement les points de rupture du cache afin de maximiser la réutilisation du KV-cache. Suivre ces pratiques peut faire une différence significative dans l’efficacité des coûts en production.
#2 Utiliser le masquage des outils au lieu du chargement dynamique
À mesure que le nombre d’outils augmente pour atteindre plusieurs centaines, y compris des outils définis par l’utilisateur, les modèles deviennent plus sujets aux erreurs ou aux blocages pendant le processus de sélection des outils. Le problème s’aggrave parce que l’insertion ou la suppression dynamique d’outils invalide le cache KV et provoque des erreurs de référence pour les outils non définis.
Au lieu de supprimer des outils, utilisez le masquage. Les techniques de masquage de jetons vous permettent d’ajuster dynamiquement les ensembles d’outils appelables sans casser le cache. Utilisez des préfixes unifiés, tels que browser_, pour faciliter le regroupement et la limitation, et tirez parti du format Hermes ou du préremplissage d’appel de fonction pris en charge par l’API pour contrôler l’espace de sélection.
#3 Utilisez le système de fichiers comme contexte
Même si un contexte de 128K semble suffisant, il devient limité lorsqu’on rencontre de grandes pages web, des PDF et d’autres données non structurées. L’approche de compression typique consistant à écarter des informations tôt peut faire perdre un contexte critique aux étapes ultérieures.
L’approche de Manus permet aux agents d’utiliser des opérations de lecture/écriture du système de fichiers pour externaliser les données. Supprimer le contenu des pages web mais conserver les URL, effacer les documents mais garder les chemins de fichiers, afin de garantir que les informations restent récupérables. Cela met en œuvre un système de « mémoire à long terme » tout en posant les bases de futures architectures plus légères, telles que SSM.
#4 Manipulez l’attention par la récitation
Manus met continuellement à jour todo.md , en récitant les objectifs incomplets à la fin du contexte. Cette technique évite les problèmes de « perdu au milieu » et améliore la capacité du modèle à maintenir la cohérence des objectifs pendant de longs processus. Le « rappel à soi-même » en langage naturel s’est révélé être l’une des méthodes les plus efficaces pour capter et maintenir l’attention.
#5 Préservez les traces d’échec pour l’apprentissage
Les modèles de langage subissent inévitablement des hallucinations, des plantages d’environnement et des échecs d’appel. La plupart des systèmes effacent habituellement les traces d’échec, réessaient ou réinitialisent, mais cela empêche l’apprentissage de se produire. La bonne approche consiste à préserver les enregistrements d’échec, y compris les traces de pile et les résultats d’observation, aidant les modèles à ajuster leurs croyances et à éviter de répéter des erreurs identiques. La capacité de récupération après erreur représente la mesure exacte de l’intelligence des agents.
#6 Évitez les pièges du few-shot
Le prompting few-shot est une technique bien connue pour améliorer les sorties des LLM, mais Manus avertit que, dans les systèmes d’agents, elle peut introduire des problèmes subtils. Comme les modèles imitent naturellement les motifs du contexte, charger trop d’exemples few-shot répétitifs peut les enfermer dans des comportements rigides. Par exemple, lorsque Manus utilisait le prompting par lots pour examiner des CV, le modèle a commencé à répéter mécaniquement les mêmes actions au lieu de s’adapter aux spécificités de chaque cas.
Le remède consiste à introduire de la variation et de la diversité dans les exemples. Ajustez légèrement les modèles action–observation en changeant les formats, l’ordre ou la formulation. Ajouter du « bruit » structuré empêche les agents de devenir fragiles et les aide à rester adaptatifs. Cela maintient la flexibilité tout en donnant au modèle des indications utiles.
#7 Privilégiez l’ingénierie du contexte plutôt que le fine-tuning
Dans ses premiers travaux avec des modèles comme BERT, Manus s’appuyait fortement sur le fine-tuning — un processus qui nécessitait souvent des semaines d’itérations et devenait rapidement inefficace et coûteux. Sur la base de cette expérience, l’équipe a réorienté son attention de l’entraînement de bout en bout vers l’ingénierie du contexte comme principal levier d’amélioration des performances.
L’impact a été significatif : les cycles de mise à jour du produit sont passés de semaines à des heures. Les mises à niveau du modèle pouvaient être intégrées de manière transparente sans réentraînement ni réadaptation. Manus décrit la différence comme la construction de produits semblables à des navires pouvant changer de cap plutôt qu’à des poteaux cloués au fond marin, incapables de bouger face à des conditions changeantes. L’ingénierie du contexte leur a donné de la flexibilité sans sacrifier la capacité.
Pour plus de détails, consultez ce blog Manus.
Comment les bases de données vectorielles soutiennent l’ingénierie du contexte
L’un des défis les plus difficiles pour les agents IA est l’épuisement du contexte. Lorsque les agents doivent traiter d’immenses bases de connaissances externes, de longs historiques de conversation ou des données multimodales, la capacité à stocker, récupérer et réutiliser dynamiquement les informations devient essentielle pour la fiabilité.
Les bases de données vectorielles offrent une solution pratique. Milvus, par exemple, est un système open source et haute performance conçu pour gérer des données multimodales à l’échelle du milliard — texte, images, vidéo et plus encore. En représentant ces informations sous forme de vecteurs, Milvus permet aux agents d’intégrer instantanément les extraits de connaissances les plus pertinents et les interactions passées dans leur processus de raisonnement. Intégré à des frameworks comme LangChain ou LlamaIndex, Milvus alimente des systèmes de génération augmentée par récupération (RAG) qui élargissent la base de connaissances d’un agent et améliorent la précision de l’inférence. Son service managé, Zilliz Cloud, offre des fonctionnalités encore plus avancées et de meilleures performances, telles que l’interrogation en langage naturel, une fiabilité et une sécurité de niveau entreprise, ainsi qu’une disponibilité mondiale sur AWS, GCP et Azure.
L’expérience développeur est tout aussi importante. Milvus propose un SDK Python bien documenté qui facilite le stockage et l’interrogation de vecteurs en seulement quelques lignes de code. Cela abaisse la barrière technique et permet aux équipes d’établir rapidement une boucle fermée pour la gestion du contexte, en intégrant directement des capacités de mémoire robustes dans leurs agents.
from pymilvus import MilvusClient
# Create local Milvus instance
client = MilvusClient("demo.db")
# Create vector collection
client.create_collection(collection_name="knowledge_base", dimension=768)
# Batch insert vectorized data into knowledge base
client.insert(collection_name="knowledge_base", data=embedding_vectors)
# Retrieve most relevant context information
query_vector = embedding_fn.encode_queries(["What is Context Engineering?"])
results = client.search(
collection_name="knowledge_base",
data=query_vector,
limit=3,
output_fields=["text", "source"]
)
Pour plus d’informations, consultez les ressources suivantes :
Milvus + Loon : une infrastructure conçue pour les agents IA
Les bases de données vectorielles sont au cœur de l’ingénierie du contexte, mais elles ne constituent qu’une partie de la pile. Les agents ont également besoin d’un moyen de traiter en amont des données multimodales désordonnées, puis de les récupérer à grande vitesse pendant l’exécution. C’est pourquoi nous avons conçu Milvus et Loon pour fonctionner ensemble — l’un gérant la récupération, l’autre préparant les données à grande échelle.
Milvus : Milvus est la base de données vectorielle open source la plus largement adoptée, optimisée pour des charges de travail à l’échelle du milliard sur le texte, les images, l’audio et la vidéo. Elle est conçue dès le départ pour la recherche vectorielle, offrant une récupération en moins de 10 ms même à très grande échelle. Pour les agents, cela se traduit directement par de la réactivité : le fait qu’ils paraissent instantanés et fiables, ou lents et sujets aux erreurs, dépend de la vitesse de récupération.
Loon (bientôt disponible) : Loon est notre prochain service de lac de données multimodal cloud-native conçu pour le prétraitement multimodal. Les jeux de données réels sont désordonnés — dupliqués, incohérents et dispersés entre les formats. Loon utilise des frameworks distribués comme Ray et Daft pour nettoyer, dédupliquer et regrouper ces données avant de les diffuser dans Milvus. Résultat : les agents ne gaspillent pas de cycles sur du bruit ; ils consomment dès le premier jour un contexte structuré et de haute qualité.
Élasticité cloud-native : Les deux systèmes font évoluer le stockage et le calcul indépendamment, permettant aux équipes d’équilibrer le service en temps réel avec l’analytique hors ligne à mesure que les charges de travail passent de gigaoctets à des pétaoctets. Pas de surprovisionnement, pas de goulots d’étranglement — seulement l’élasticité qu’exigent les pipelines d’IA modernes.
Fondation pérenne : La priorité d’aujourd’hui est la recherche sémantique et les pipelines RAG ; celle de demain sera le raisonnement multimodal et les workflows pilotés par des agents. Avec Milvus et Loon, la même stack prend en charge les deux. Vous gagnez en flexibilité pour évoluer sans remplacer l’infrastructure — en réduisant les coûts, les risques et la complexité.
Le contexte est la véritable frontière pour les agents d’IA
Comme le montre le débat entre conception à agent unique et multi-agents, le véritable goulot d’étranglement pour les agents d’IA d’aujourd’hui n’est pas seulement la créativité — c’est le contexte. Qu’il s’agisse du framework à quatre piliers de LangChain, du guide opérationnel axé sur la production de Lossfunk, ou des enseignements durement acquis de Manus dans la création de systèmes entièrement autonomes, le secteur converge vers le même constat : les agents réussissent ou échouent selon la qualité de leur ingénierie du contexte.
Les stratégies diffèrent — certaines mettent l’accent sur l’écriture et le filtrage, d’autres préconisent un contexte de fichier complet ou une conception tenant compte du cache — mais l’objectif est le même, en particulier pour les agents prêts pour la production : garder les agents à la fois performants et rentables. Et même si aucune technique unique ne résout tout, ensemble elles forment un corpus croissant de pratiques que les développeurs peuvent adapter à leurs propres systèmes.
Chez Zilliz, nous considérons les bases de données vectorielles comme Milvus comme une pierre angulaire de cette boîte à outils. En offrant aux agents une mémoire évolutive et plus précise au-delà de la fenêtre de contexte, les développeurs peuvent rendre l’ingénierie du contexte pratique, flexible et prête pour la production. L’avenir des agents d’IA ne sera pas défini uniquement par des modèles plus grands, mais par des manières plus intelligentes d’ingénier le contexte — et c’est là que les véritables percées se produiront.
Continuer à lire
Stop Building AI Data Infra for the Wrong Stage
Learn how AI data infrastructure should evolve from prototype to enterprise scale, and when Vector Lakebase becomes the right architecture for AI apps.
How to Install and Run OpenClaw (Previously Clawdbot/Moltbot) on Mac
Turn your Mac into an AI gateway for WhatsApp, Telegram, Discord, iMessage, and more — in under 5 minutes.
Milvus/Zilliz + Surveillance: How Vector Databases Transform Multi-Camera Tracking
See how Milvus vector database enhances multi-camera tracking with similarity-based matching for better surveillance in retail, warehouses and transport hubs.