Quatre couches d'ingénierie du contexte pour les agents IA en production : comment Deep Insight les applique dans du code fonctionnel

Lorsque des agents IA en production gèrent des tâches telles que l'analyse de données et la génération de rapports, la gestion du contexte peut devenir un goulot d'étranglement majeur. Une fenêtre de 200K tokens semble généreuse jusqu'à ce qu'une tâche réelle en consomme la plus grande partie en quelques minutes. L'analyse de données et la génération de rapports laissent l'agent en échec en cours d'exécution, entraînent une perte de précision ou font exploser les coûts. Un ensemble de recommandations publiées traite déjà ce sujet, mais les techniques individuelles sont plus faciles à lire qu'à appliquer. Appliquées ensemble, elles produisent une différence mesurable : dans l'implémentation de référence que cet article présente, un simple outil d'écriture et d'exécution réduit d'environ 95 pour cent les tokens que chaque script ajoute au contexte, et le chargement des compétences à la demande réduit le prompt système d'environ 97 pour cent.

Cette série organise ces recommandations en pratiques que vous pouvez appliquer directement. Les articles d'ingénierie d'Anthropic, conjointement avec des fonctionnalités intégrées au Strands Agents SDK, convergent vers quatre couches d'ingénierie du contexte : isoler le contexte au niveau de l'architecture, le contrôler par les prompts, l'externaliser vers le système de fichiers et le vérifier avec des agents indépendants et des garde-fous. Dans cet article (Partie 2), vous apprendrez comment fonctionne chaque couche et à quoi elle ressemble dans du code fonctionnel. Nous avons appliqué ces techniques dans Deep Insight, une solution open source d'analyse de données multi-agents construite sur le Strands Agents SDK et Amazon Bedrock AgentCore, qui sert d'implémentation de référence tout au long de l'article.

Série d'articles

• Partie 1 : 5 défis de production dans les systèmes multi-agents et comment Deep Insight les a résolus.
• Partie 2 : Quatre couches d'ingénierie du contexte pour les agents IA en production : comment Deep Insight les applique dans du code fonctionnel.
• Partie 3 : L'ingénierie du harnais en pratique : faire passer Deep Insight du développement à la production. (Bientôt disponible !)

Le premier article a défini cinq défis fondamentaux que les systèmes multi-agents en production doivent résoudre. Il a présenté la manière dont Strands Agents SDK, Amazon Bedrock et Bedrock AgentCore, ainsi que AWS Fargate traitent chacun différentes couches du problème, avec des exemples de code. Ce deuxième article prend les quatre couches de la pratique d'ingénierie du contexte qui reposent sur cette architecture et montre l'implémentation de chacune. Le troisième article vous guide dans le déploiement et l'exploitation d'agents dans un réseau privé sécurisé sur Amazon Virtual Private Cloud (Amazon VPC), couvrant tout ce qui est nécessaire pour des opérations en conditions réelles.

Qu'est-ce que l'ingénierie du contexte ?

L'ingénierie du contexte est la discipline qui consiste à optimiser les informations dans la fenêtre de contexte limitée d'un grand modèle de langage (LLM) afin que les agents donnent le meilleur d'eux-mêmes. Anthropic Claude Sonnet 4.5, disponible sur Amazon Bedrock, offre une fenêtre de contexte de 200K, mais les tâches de production complexes la dépassent rapidement. Par exemple, une requête en apparence simple telle que «Analyze sales data and create a DOCX report» passe par plusieurs étapes : chargement et exploration des données (5 min), analyse des ventes par catégorie (3 min), génération de cinq graphiques pour l'analyse de séries temporelles (10 min), validation statistique (3 min) et génération du rapport final (5 min). Ensemble, elles consomment plus de 150K tokens sur 15 minutes.

Traiter de telles tâches dans un contexte unique pose des problèmes : la fenêtre déborde en cours de tâche, un contexte obsolète dégrade les performances et les erreurs nécessitent de réexécuter tout le pipeline. À mesure que le contexte s'accroît, l'attention portée aux informations importantes diminue, et l'inefficacité augmente le coût dans un modèle de tarification par token.

« À mesure que le nombre de tokens dans la fenêtre de contexte augmente, la capacité du modèle à rappeler avec précision les informations de ce contexte diminue (Context rot). »

— Anthropic, «Effective Context Engineering for AI Agents” (2025.09)

L'ingénierie du contexte résout précisément ces problèmes, et ce n'est pas seulement un ensemble de techniques. S'étendant de la conception d'architecture à la rédaction de prompts, en passant par l'implémentation d'outils et la vérification, c'est une discipline en couches où chaque couche compense ce que les précédentes manquent. Cet article détaille l'approche en quatre couches que vous pouvez appliquer pour gérer le contexte efficacement.

Comment gérer les tâches qui dépassent la fenêtre de contexte

Anthropic a publié plusieurs techniques pour gérer les tâches à long terme. Deep Insight regroupe ces techniques en quatre couches, chaque couche répondant aux limitations des autres. Le tableau suivant présente les quatre couches.

Les sections qui suivent examinent chaque couche dans l'ordre, en indiquant ce qu'elle prescrit, pourquoi les couches précédentes à elles seules sont insuffisantes, et comment la pratique est mise en œuvre dans Deep Insight.

1. Isoler le contexte grâce à une architecture multi-agents

Donnez à chaque agent spécialisé sa propre fenêtre de contexte et ne transmettez que les résultats compressés à l'orchestrateur. Deep Insight le fait avec une hiérarchie composée d'un Coordinator, d'un Planner, d'un Plan Reviewer, d'un Supervisor et de Tool Agents (Coder, Validator, Reporter, Tracker, Auditor).

Avec un seul agent, toutes les informations, des demandes de l'utilisateur jusqu'à l'exploration des données, l'analyse, la génération de graphiques, la validation et le reporting, s'accumulent dans un seul contexte et dépassent facilement la fenêtre. Le fait de donner à chaque agent son propre contexte permet de maintenir même le Coder, qui en utilise le plus, sous les 25K tokens au total. Chaque agent ne reçoit que ce dont il a besoin et signale aux autres son achèvement par une notification et un bref résumé.

La clé de l'isolation est de minimiser les informations partagées. Deep Insight utilise un dictionnaire Python, shared_state, qui ne stocke que quatre choses :

• messages: le message final de l'agent précédent (et non l'historique complet de la conversation).
• clues: les résumés compressés collectés auprès de chaque agent.
• full_plan: une liste de contrôle générée par le Planner et mise à jour par le Tracker.
• history: un bref journal des noms d'agents et des messages.

Les indices utilisent un format fixe CLUES_FORMAT : au lieu de la conversation complète de chaque agent (des dizaines de milliers de tokens), seuls les résultats essentiels compressés sont transmis.

# coder_agent_tool.py -- context passing format
CLUES_FORMAT = "Here is clues from {}:\n\n<clues>\n{}\n</clues>\n\n"
RESPONSE_FORMAT = "Response from {}:\n\n<response>\n{}\n</response>\n\n*Please execute the next step.*"

# After Coder completes: add only compressed result to clues
clues += CLUES_FORMAT.format("coder", response["text"])

Ce modèle est celui recommandé dans l'article d'Anthropic «How We Built Our Multi-Agent Research System», qui décrit un modèle orchestrateur-worker dans lequel un agent principal délègue à des sous-agents spécialisés, chaque agent ne travaillant que dans son propre contexte. Vous n'avez pas besoin de le construire vous-même : le modèle agents-as-tools du Strands Agents SDK fournit cette isolation au niveau du framework.

2. Contrôler l'entrée de contexte via les prompts

L'isolation de la couche 1 à elle seule n'est pas suffisante : même avec des contextes indépendants, un agent qui génère de longues réponses gonfle le contexte du Supervisor. La couche 2 limite la sortie de chaque agent au moyen de prompts.

Pour Deep Insight, nous utilisons des prompts pour limiter la quantité d'informations que chaque agent renvoie au Supervisor. Trois règles font l'essentiel du travail, comme le montrent les prompts de Deep Insight.

« Commencez avec le modèle le plus puissant et un prompt simple. Ajoutez ensuite progressivement des instructions spécifiques en vous appuyant sur les cas d'échec réellement observés. »

— Anthropic, « Effective Context Engineering for AI Agents » (2025.09)

Détail d'implémentation 2-1 : budgets explicites de tokens de sortie par agent

Le prompt de chaque agent spécifie un nombre maximal de tokens de réponse, ce qui évite les longues réponses qui polluent le contexte du Supervisor.

L'article d'Anthropic « Writing Effective Tools for Agents» suggère de donner aux outils une option de réponse CONCISE ou DETAILED pour l'efficacité du contexte. Appliquez la même idée un niveau plus haut, dans le prompt système de chaque agent. Dans Deep Insight, tous les agents partagent un format standardisé :

## Status
[SUCCESS | PARTIAL_SUCCESS | ERROR]
## Completed Tasks
- [Task 1 from FULL_PLAN -- use exact wording so Tracker can match]
- [Task 2 -- be specific, not generic]
## Key Insights
- [Key finding 1 with numbers and ratios]
- [Key finding 2 with business implications]
## Generated Files
- ./artifacts/chart.png -- brief description
- ./artifacts/calculation_metadata.json -- N calculations

Détail d'implémentation 2-2 : philosophie du code autonome

Le prompt de l'agent Coder indique explicitement que « les variables ne persistent pas entre les scripts ». Chaque script doit inclure tous les imports nécessaires et charger les données directement. Le prompt fournit des exemples incorrects et corrects :

# WRONG -- Attempting to use a variable from Turn 1 in Turn 2
# Turn 1:
df = pd.read_csv('data.csv')
total = df['Amount'].sum()

# Turn 2:
print(f"Total: {total}")  # NameError: name 'total' is not defined

# CORRECT -- Every script is self-contained
import pandas as pd
df = pd.read_csv('./artifacts/cache/df_main.csv')  # Load from cache
total = df['Amount'].sum()
print(f"Total: {total}")

La raison pour laquelle cette règle se rapporte à l'ingénierie du contexte est que le fait de référencer des variables de scripts précédents oblige l'agent à « se souvenir » des conversations antérieures, ce qui signifie que le code passé doit rester dans le contexte. Le principe du code autonome signifie que le code passé peut être retiré du contexte en toute sécurité.

Détail d'implémentation 2-3 : règle d'achèvement de section du Supervisor

Le prompt du Supervisor inclut la règle « Ne pas passer à l'agent suivant tant que tous les éléments de la checklist de la section de l'agent en cours ne sont pas marqués [x]». Nous exprimons cette règle dans le prompt parce que déterminer si le travail du Coder est terminé oblige le Supervisor à interpréter le plan en utilisant les informations des mises à jour du Tracker. Ce jugement est difficile à exprimer en code seul.

3. « Seulement des pointeurs dans le contexte, les données réelles dans des fichiers »

La couche 1 isole le contexte entre les agents, et la couche 2 limite la sortie au sein des agents. Mais lorsque l'agent Coder génère 100 lignes de code Python, ce code entre lui-même dans le contexte. Même avec des instructions de type « réponds brièvement » dans le prompt, certains codes ne peuvent pas être écrits brièvement. La couche 3 utilise la conception d'outils pour déplacer le contenu lourd hors du contexte, vers le système de fichiers. Quatre techniques apportent la majorité du bénéfice, comme le montrent les détails d'implémentation suivants.

Détail d'implémentation 3-1 : déplacer le code hors du contexte avec l'outil Write and Execute

Le Coder lit le plan d'analyse, écrit du Python et l'exécute pour générer des visualisations. Mais lorsque le code devient long, l'approche conventionnelle (outils distincts d'écriture de fichier et d'exécution) ajoute 100 lignes directement au contexte par script, pour un total dépassant 1 000 lignes.

La solution consiste à fusionner les deux étapes en un seul outil, afin que le code n'entre jamais dans le contexte sous forme de message. L'agent Coder de Deep Insight utilise un write_and_execute_tool pour cela.

Voici une partie du write_and_execute_tool. Après avoir écrit et exécuté le fichier, il ne renvoie qu'un résumé : « 105 lignes écrites, exécution réussie, analyse de cinq catégories terminée. » Le code reste dans le fichier et environ trois lignes de résumé demeurent dans le contexte. Sur la base de cet exemple, cela économise environ 95 pour cent des tokens.

# write_and_execute_tool.py
def _handle_write_and_execute_tool(file_path, content, timeout=300):
    """Write a Python script and immediately execute it."""
    # Step 1: Write file
    with open(file_path, 'w', encoding='utf-8') as f:
        f.write(content)
    # Step 2: Execute immediately
    result = subprocess.run(
        f"python {file_path}",
        shell=True,
        capture_output=True,
        timeout=timeout
    )
    # Return only summary
    return f"Written {len(content.split(chr(10)))} lines to {file_path}\n" \
        f"Execution successful\n" \
        f"Output: {result.stdout[:500]}"  # Only first 500 chars

« Filtrage côté serveur : filtrage des données à la couche d'exécution avant qu'elles n'atteignent le contexte, réduction des tokens de 98,7 % (de 150K à 2K). »

— Anthropic, «Code Execution with MCP” (2025.11)

Détail d'implémentation 3-2 : réutilisation de la logique commune sous forme de modules dans l'agent Coder

Les modules communs sont réutilisés entre les analyses. Plutôt que de les régénérer à chaque fois, définissez une fois les fonctions fréquemment utilisées sous forme de module et importez-les, ce qui évite le gaspillage de tokens et la duplication dans le contexte.

Sans cela, définir des fonctions comme to_python_type() ou track_calculation() dans chaque analyse produit 200 à 300 lignes de code dupliqué sur 10 analyses. Deep Insight génère un module appelé coder_analysis_utils.py avant la première tâche. Il inclut des fonctions pour convertir les types numpy, suivre les métadonnées de calcul et enregistrer en JSON. Les analyses suivantes l'importent, remplaçant 20 à 30 lignes régénérées par deux lignes d'import, ce qui économise des tokens et améliore la cohérence et le débogage.

# coder_analysis_utils.py -- common module generated before first task
import numpy as np
import json
from datetime import datetime

_calculations = []

def to_python_type(value):
    """Convert numpy/pandas types to Python native types"""
    if isinstance(value, (np.integer, np.int64)): return int(value)
    elif isinstance(value, (np.floating, np.float64)): return float(value)
    elif isinstance(value, np.ndarray): return value.tolist()
    return value

def track_calculation(calc_id, value, description, formula,
                      source_file, source_columns, importance):
    """Track calculation metadata -- Validator independently verifies later"""
    _calculations.append({
        "id": calc_id, "value": to_python_type(value),
        "description": description, "formula": formula,
        "source_file": source_file, "source_columns": source_columns,
        "importance": importance
    })

def save_calculation_metadata(path="./artifacts/calculation_metadata.json"):
    """Save all tracked calculations to JSON"""
    with open(path, 'w', encoding='utf-8') as f:
        json.dump({"generated_at": datetime.now().isoformat(),
                   "calculations": _calculations}, f, ensure_ascii=False, indent=2)

Détail d'implémentation 3-3 : enregistrer et partager les résultats d'analyse via une prise de notes structurée

Nous utilisons la prise de notes structurée pour partager les résultats d'analyse détaillés sans les faire transiter par le contexte de chaque agent. Deep Insight stocke ces résultats dans un fichier appelé all_results.txt, qui est ensuite lu par les agents selon les besoins.

Par exemple, l'agent Coder ajoute les résultats à all_results.txt après chaque tâche d'analyse :

with open('./artifacts/all_results.txt', 'a', encoding='utf-8') as f:
    f.write(f"""
## Category Sales Analysis (completed at: 14:32)
- Top revenue category: Fruit (417,166,008 KRW, 45% of total)
- Top 3 categories: Fruit, Vegetables, Meat (78% of total)
- Generated file: ./artifacts/category_sales_chart.png
""")

Le Coder consigne des résultats détaillés dans ce fichier après chaque analyse, et le Reporter le lit lors de la rédaction du rapport final. Les autres agents collaborent via all_results.txt de la même manière.

Sans prise de notes, le Coder transmet des résultats détaillés au Supervisor après chaque tâche, ce qui s'accumule dans son contexte. Avec la prise de notes, seuls un message d'environ 30 jetons du type « Analyse des ventes par catégorie terminée, 3 enseignements clés trouvés, résultats détaillés enregistrés dans all_results.txt » est transmis, et le Reporter lit le fichier au besoin.

Le schéma se généralise au-delà d'un seul fichier. Le système de fichiers lui-même peut servir de bus de communication inter-agents, comme c'est le cas dans Deep Insight :

« L'approche « juste à temps », qui charge dynamiquement les données dans le contexte à l'exécution plutôt que de pré-traiter à l'avance toutes les données pertinentes, maintient le contexte frais, pertinent et adaptatif à l'état évolutif de la tâche. »

— Anthropic, «Effective Context Engineering for AI Agents” (2025.09)

Détail d'implémentation 3-4 : ne charger que les connaissances nécessaires avec Skills

Plutôt que de placer toutes les connaissances spécialisées dans le prompt système, cette approche ne les charge qu'en cas de besoin. Inclure chaque guide de compétence (vérification de la structure des données, génération de README, création de compétence, rédaction de prompt système, création d'outils) ajouterait plus de 20K tokens, chargerait des informations inutiles dans l'agent Coder à chaque appel et imposerait un redéploiement pour ajouter une compétence.

Le système Skills de Deep Insight ne charge au démarrage qu'un catalogue de compétences d'environ 500 tokens, la liste des compétences ne contenant que des noms et de brèves descriptions. Lorsqu'un utilisateur demande « Créer un fichier README », l'agent décide « j'ai besoin de la compétence readme-generator » et appelle skill_tool(skill_name="readme-generator"). Le SkillLoader lit readme-generator/SKILL.md et renvoie un guide détaillé d'environ 3K tokens.

# 1. Skill Discovery (at initialization)
from src.utils.skills.skill_utils import initialize_skills
available_skills, skill_prompt = initialize_skills(
    skill_dirs=["./skills"],
    verbose=True
)

# 2. Add to System Prompt (~500-token catalog)
system_prompt = base_prompt + skill_prompt

# 3. Runtime -- Agent loads skill when needed
# Agent decides: "This is README generation, I need the readme-generator skill"
# -> skill_tool(skill_name="readme-generator")
# -> Returns full SKILL.md content (~3K tokens)

Chaque compétence est définie comme un fichier SKILL.md composé d'un frontmatter YAML et d'un guide markdown détaillé. Elle comprend des métadonnées comme name, description, license et allowed-tools, ainsi qu'un aperçu (Overview), quand utiliser cette compétence (When to Use This Skill), des instructions détaillées et les bonnes pratiques (Best Practices). Pour ajouter une nouvelle compétence, il suffit de créer un nouveau répertoire sous skills/ et d'écrire un fichier SKILL.md, et elle est automatiquement découverte.

Au démarrage, l'agent charge un catalogue de compétences d'environ 500 tokens au lieu de gaspiller plus de 20,000 tokens pour des guides complets (environ 97 pour cent de moins). En cas de besoin, il peut charger quelques milliers de tokens supplémentaires d'instructions détaillées pour les compétences.

4. Vérifier la qualité avec des agents de vérification et des garde-fous

Même avec les couches 1 à 3, un risque subsiste : les agents isolés ne peuvent pas voir le travail des autres, donc si le Coder se trompe dans un calcul, le Reporter transmet cette erreur dans le rapport. La couche 4 constitue la dernière ligne de défense.

« Fournissez des outils de test afin que l’agent puisse vérifier lui-même les fonctionnalités et corriger les bugs qui ne sont pas évidents à partir du code seul. Faites en sorte que le modèle enregistre sa progression dans git avec des messages de commit descriptifs et rédige des résumés d’avancement dans un fichier de progression. »

— Anthropic, «Effective Harnesses for Long-Running Agents” (2025.11)

Détail d’implémentation 4-1 : agents Tracker, Validator et Auditor : suivi de progression et assurance qualité

Tracker met à jour la liste de contrôle du plan en temps réel. Lorsque le Coder termine le chargement des données, le Supervisor appelle Tracker, qui met à jour l’élément du plan de [ ] à [x] sur la base d’informations telles que « Chargement des données terminé (1,000 lignes, 5 colonnes) ». Cela aide à la fois les utilisateurs et le système à savoir exactement où en est la progression.

Validator réexécute indépendamment les calculs du Coder pour en vérifier l’exactitude. Il lit calculation_metadata.json, refait chaque calcul à partir des données sources et compare : les correspondances avec une différence inférieure à 0.01 sont acceptées, les discordances sont signalées. Les calculs vérifiés sont envoyés à citations.json pour que le Reporter puisse les citer. Après que le Reporter a terminé, l’Auditor vérifie le DOCX final par rapport à citations.json et calculation_metadata.json sans les modifier. Il consigne les défauts de citation dans audit_findings.json et peut demander jusqu’à deux relances ciblées au Reporter.

Détail d’implémentation 4-2 : prioriser les calculs à vérifier

Vérifier chaque calcul est inefficace ; délimitez donc la vérification selon l’importance. L’OptimizedValidator de Deep Insight applique les seuils suivants :

• Plus de 50 calculs : filtrage agressif, vérifier tous les calculs élevés plus seulement 10 calculs moyens.
• Plus de 20 calculs : filtrage modéré, vérifier tous les calculs élevés plus 15 calculs moyens.
• 20 calculs ou moins : vérifier la plupart, tous les calculs élevés plus tous les calculs moyens plus 5 calculs faibles.

Il applique également une comparaison type-safe : pour éviter les problèmes de types entre numpy et Python, toutes les valeurs sont converties en float() et vérifiées avec une différence absolue inférieure à 0.01 :

# validator.md -- type-safe numerical comparison
try:
    match = abs(float(expected) - float(actual)) < 0.01
except:
    match = str(expected) == str(actual)

Détail d’implémentation 4-3 : SummarizingConversationManager, le dernier filet de sécurité

Le contexte peut encore déborder dans des cas exceptionnels ; conservez donc un filet de sécurité sous les autres couches. Deep Insight utilise le SummarizingConversationManager du Strands Agents SDK à cet effet.

# strands_sdk_utils.py -- safety net configuration at agent creation
agent = Agent(
    model=llm,
    system_prompt=system_prompts,
    tools=tools,
    conversation_manager=SummarizingConversationManager(
        summary_ratio=0.5,  # summarize oldest 50% on overflow
        preserve_recent_messages=10,  # always preserve 10 most recent messages
        summarization_system_prompt=apply_prompt_template("summarization", {})
    )
)

En cas de débordement, le LLM résume les 50 pour cent les plus anciens des messages en un seul, tout en préservant toujours les 10 plus récents pour conserver le contexte de la tâche en cours. Le prompt de résumé (summarization.md) exige que clues, plans, et tracking status soient préservés verbatim.

Détail d’implémentation 4-4 : mise en cache sélective des prompts pour l’optimisation des coûts

L’ingénierie du contexte couvre l’optimisation des coûts, et pas seulement l’économie de tokens. Activez la mise en cache des prompts par agent, selon la fréquence à laquelle chacun est appelé avec le même prompt. Les réglages par agent de Deep Insight :

Les agents avec la mise en cache activée insèrent des points de cache dans les prompts système et les définitions d'outils, réduisant les coûts de tokens d'entrée jusqu'à 90 pour cent sur les appels répétés. Il s'agit d'une fonctionnalité prise en charge nativement par le Strands Agents SDK. Le Plan Reviewer n'apparaît pas dans le tableau parce qu'il s'agit d'une étape avec intervention humaine qui recueille l'approbation ou les retours de l'utilisateur plutôt que d'appeler un modèle.

Conclusion

Cet article a détaillé l'approche d'ingénierie en quatre couches que vous pouvez utiliser pour gérer efficacement le contexte dans le cas de tâches complexes qui dépassent la fenêtre de contexte.

• Couche 1 (isolation au niveau de l'architecture) : chaque agent travaille dans un contexte indépendant grâce à une architecture multi-agents, en ne transmettant que des résumés compressés.
• Couche 2 (contrôle par les prompts) : les budgets de tokens de sortie, les formats de réponse standardisés et la philosophie du code autonome limitent activement l'entrée de contexte.
• Couche 3 (utilisation du système de fichiers) : write_and_execute_tool maintient le code hors du contexte, le système de fichiers sert de bus de communication inter-agents, et les connaissances sont chargées paresseusement uniquement lorsque c'est nécessaire.
• Couche 4 (vérification et garde-fous) : la revérification indépendante des calculs par le Validateur, l'audit des citations en lecture seule du rapport final par l'Auditeur, le suivi de la progression par le Traceur, la prévention des débordements par le SummarizingConversationManager, et la mise en cache sélective des prompts gèrent à la fois la qualité et le coût.

Chaque couche forme un système de défense qui compense ce que les couches précédentes laissent passer. Lorsque l'isolation architecturale est insuffisante, les prompts limitent la sortie. Lorsque les prompts sont insuffisants, les outils maintiennent le contenu à l'extérieur. Et lorsque des problèmes surviennent malgré tout, la vérification les détecte.

Chacune de ces couches est documentée dans les articles d'ingénierie d'Anthropic, « Effective Context Engineering for AI Agents », « Code Execution with MCP », et « Comment nous avons construit notre système de recherche multi-agents ». Une grande partie de ce qu'ils recommandent est déjà intégrée dans le Strands Agents SDK plutôt que devant être développée : SummarizingConversationManager, le prompt caching et le motif agents-as-tools.

Lors de la construction d'agents de production, la fenêtre de contexte du LLM seule suffit rarement. Appliquez ces techniques d'ingénierie du contexte pour gérer le contexte efficacement et faire évoluer vos agents pour des charges de travail de production.

Deep Insight, l'implémentation de référence utilisée ici, est open source. Examinez le code et étendez-le pour votre domaine.

• GitHub
• Atelier

À propos des auteurs