Ingénierie du contexte d'Agent
Agent 上下文工程(L'ingénierie du contexte d'Agent) est une pratique technique consistant à concevoir et optimiser systématiquement les informations de contexte transmises aux Agents IA. Son objectif est de permettre aux Agents d'obtenir les informations les plus efficaces dans une fenêtre de contexte limitée, améliorant ainsi la précision, l'efficacité et la fiabilité de l'exécution des tâches.
Contrairement aux programmes traditionnels, les Agents IA n'ont pas de logique d'exécution fixe ; leur comportement est entièrement déterminé par le contexte qu'ils reçoivent — notamment les prompts système, les descriptions d'outils, l'historique de conversation et les informations récupérées à l'extérieur.
Le cœur de l'ingénierie du contexte est de répondre à une question :Dans ce tour d'invocation, de quoi l'Agent a-t-il le plus besoin de savoir ?
L'ingénierie du contexte n'est pas une écriture de prompt ponctuelle, mais un processus d'optimisation continu qui s'étend sur tout le cycle de vie du développement, des tests et de l'exploitation des systèmes d'Agent.
Éléments essentiels
Le contexte d'Agent se compose des couches suivantes :
| Couche | Contenu | Caractéristiques |
|---|---|---|
| Prompt système | Définition du rôle, règles de comportement, exigences de format de sortie | Inclus à chaque appel, relativement stable |
| Définitions des outils | Noms, paramètres et descriptions de fonction des outils disponibles | Consomme un grand nombre de tokens, doit être concis |
| Historique | Enregistrements de conversation et d'appel d'outils de la session en cours | Croît continuellement, nécessite des stratégies de troncature ou de résumé |
| Contexte récupéré | Contenu récupéré depuis des bases de connaissances externes ou des dépôts de code | Injecté à la demande, nécessite un classement par pertinence |
| Entrée utilisateur | L'instruction ou la question actuelle de l'utilisateur | Incontrôlable, mais peut être optimisée par la clarification |
Pratiques essentielles
Gestion du budget de contexte
Traitez la fenêtre de contexte comme un « budget » fini et répartissez-la raisonnablement entre les différents types de contexte.
Toutes les informations ne méritent pas d'occuper de l'espace de contexte ; chaque élément de contexte doit avoir un ROI clair.
上下文预算分配建议（以 200K token 窗口为例）： 系统提示 ██████████ 10% （20K token） 工具定义 ████████████████ 20% （40K token） 检索上下文 ████████████████████ 25% （50K token） 历史记录 ████████████████████████ 30% （60K token） 用户输入 ████████ 5%~10% （10-20K token） 预留缓冲 ████ 5% （10K token）
Le ratio réel doit être ajusté dynamiquement en fonction du type de tâche spécifique de l'Agent.
Si l'Agent effectue principalement de la génération de code, la proportion de contexte récupéré peut être augmentée.
Si l'Agent est un assistant de dialogue multi-tours, le budget d'historique doit être priorisé.
Ingénierie du prompt système
Le prompt système est la pierre angulaire du comportement de l'Agent et doit suivre des principes de rédaction structurés.
Principes de rédaction :
| Principe | Description | Exemple |
|---|---|---|
| Organisation hiérarchique | Répartir les instructions en blocs par rôle, règles, processus et format | Séparer avec des titres Markdown |
| Formulation positive | Indiquer à l'Agent ce qu'il doit faire, pas ce qu'il ne doit pas faire | « Conserver des réponses concises » vaut mieux que « ne sois pas verbeux » |
| Fournir des exemples | Utiliser des exemples few-shot au lieu de descriptions longues | Les exemples de format de sortie sont plus efficaces que les descriptions textuelles |
| Priorités claires | Quelle règle l'Agent doit suivre en cas de conflit entre règles | « Les règles de sécurité prévalent sur les exigences d'efficacité » |
| Supprimer les redondances | Supprimer les règles qui ne se déclenchent jamais et les instructions en double | Revoir et rationaliser régulièrement le prompt système |
Voici un exemple de squelette d'un prompt système structuré :
## 角色 你是一名 Python 代码审查助手。 ## 核心规则 - 每个问题附上修复建议 - 按严重程度排序输出 - 不确定时标注「待确认」 ## 工作流程 1. 分析代码变更 2. 按严重程度分类问题 3. 逐一输出问题与建议 ## 输出格式 **问题**：[问题描述] **严重程度**：[高/中/低] **建议**：[修复建议]
Optimisation des descriptions d'outils
Les descriptions d'outils occupent souvent la plus grande part du contexte, mais de nombreux outils ne sont jamais réellement invoqués.
Les stratégies d'optimisation incluent :
| Stratégie | Méthode | Effet |
|---|---|---|
| Réduction des outils | Supprimer les définitions d'outils sans rapport avec la tâche en cours | Réduire le contexte des outils de 30%~50% |
| Descriptions concises | Décrire l'objectif et les paramètres de chaque outil en une seule phrase | Améliorer la précision du modèle dans la compréhension des outils |
| Contraintes sur les paramètres | Clarifier les scénarios d'utilisation et les limites des paramètres dans la description | Réduire les erreurs de paramètres dans les appels d'outils |
| Enregistrement groupé | Enregistrer dynamiquement différents ensembles d'outils selon l'étape de la tâche | Éviter la « difficulté de choix » causée par un trop grand nombre d'outils |
Toute définition d'outil non nulle est un fardeau. Chaque outil conservé exige un compromis entre la qualité de la description et le coût en tokens.
Stratégies de compression de l'historique
Dans les conversations multi-tours, l'historique croît rapidement et consomme du contexte.
Il est nécessaire de choisir une stratégie de compression appropriée pour équilibrer l'exhaustivité du contexte et les limites de fenêtre.
常见历史压缩策略对比： 策略 方法 适用场景 ───────────────────────────────────────────────── 滑动窗口 保留最近 N 轮完整记录 短对话、实时交互 阶梯摘要 每轮做一次增量摘要 长对话、客服场景 分层摘要 近期保留完整、远期做摘要 文档生成、复杂任务 关键轮标记 标记重要轮次，其余丢弃 调试、分步执行任务
Le résumé hiérarchique est la stratégie la plus couramment utilisée : conserver les 3-5 derniers tours complets et remplacer les conversations antérieures par des résumés structurés.
Un résumé structuré doit contenir les informations clés de la conversation originale : quel était l'objectif de l'utilisateur, ce que l'Agent a fait, quelle sortie il a produite et quelles erreurs il a rencontrées.
Contrôle qualité du contexte récupéré
Lorsqu'un Agent s'appuie sur une base de connaissances externe, la qualité du contexte récupéré détermine directement la qualité de la sortie.
Points clés pour améliorer la qualité du contexte récupéré :
| Étape | Problèmes courants | Méthodes d'amélioration |
|---|---|---|
| Réécriture de requête | L'entrée utilisateur n'est pas suffisamment précise | Faire réécrire la requête par l'Agent avant la récupération |
| Filtrage de pertinence | Les résultats récupérés contiennent du contenu non pertinent | Définir un seuil de pertinence et alerter proactivement lorsqu'il est insuffisant |
| Annotation des sources | L'Agent ne peut pas juger la crédibilité des informations | Joindre le chemin de la source et la date de mise à jour |
| Troncature de longueur | Les résultats récupérés occupent trop de contexte | Tronquer par paragraphe en conservant les segments les plus pertinents |
Modèles courants
Divulgation progressive
Au lieu de bourrer tout le contexte d'informations d'un coup, les divulguer progressivement selon l'étape d'exécution.
Le contexte initial ne contient que le prompt système et les outils nécessaires à l'étape en cours. Une fois que l'Agent termine l'étape en cours, les outils et règles de l'étape suivante sont injectés.
Ce mode maintient la « densité » du contexte dans une plage raisonnable, empêchant l'Agent d'être perturbé par des informations non pertinentes.
Chaîne de compression du contexte
Lorsqu'une tâche nécessite de traiter de grandes quantités de données, la diviser en plusieurs étapes à l'aide d'appels en chaîne, en ne conservant que les résultats intermédiaires clés à chaque étape.
步骤1：读取全部日志文件 → 输出 { 错误数量，时间范围，错误类型列表 }
步骤2：基于步骤1的输出，分析 Top 3 错误 → 输出 { 根因分析，修复建议 }
步骤3：基于步骤2的输出，生成修复 PR → 输出 { PR 标题，描述，代码变更 }
L'entrée de chaque maillon est le résumé affiné de l'étape précédente, plutôt que les données brutes, maintenant le contexte à une taille contrôlable à tout moment.
Tatouage du contexte
Placer des marqueurs « filigrane » à des positions clés du contexte pour aider à surveiller et diagnostiquer le comportement de l'Agent.
上下文水印示例： <system-reminder> 当前使用的上下文策略版本：v2.3 检索到的文档来源：docs/api-reference/ 共 3 个文件 已消耗上下文：85,000 / 200,000 tokens </system-reminder>
Ces filigranes n'affectent pas directement le comportement de l'Agent, mais lors du débogage, ils permettent de localiser rapidement si l'injection de contexte a été exécutée comme prévu.
Évaluation et itération
L'efficacité de l'ingénierie du contexte doit être vérifiée par l'évaluation et ne peut pas être jugée uniquement à l'intuition.
Dimensions d'évaluation couramment utilisées :
| Dimension | Méthode d'évaluation | Indicateurs clés |
|---|---|---|
| Taux d'achèvement des tâches | Exécuter l'Agent sur un jeu de test standard | Taux de réussite, distribution des causes d'échec |
| Efficacité du contexte | Compter l'utilisation du contexte à chaque appel | Consommation moyenne de tokens, taux d'utilisation du contexte |
| Qualité des appels d'outils | Analyser la précision des appels d'outils et le taux de validité des paramètres | Ratio d'appels invalides, nombre de réessais |
| Cohérence des réponses | Plusieurs tests avec la même entrée | Stabilité de la sortie, taux de conformité du format |
L'ingénierie de contexte n'est pas une configuration ponctuelle ; elle nécessite la mise en place d'une boucle itérative « test → analyse → optimisation → retest ».
Notes
Une fenêtre de contexte plus grande n'est pas toujours meilleure. Un contexte excessif peut diluer l'attention du modèle sur les informations clés et en réalité réduire la qualité de la sortie.
Ajouter des règles à l'aveugle peut rendre les prompts système gonflés et contradictoires. Chaque nouvelle règle doit être examinée pour détecter les conflits avec les règles existantes.
Les modifications des définitions d'outils peuvent affecter le comportement des agents existants. Après modification, des tests de régression doivent être effectués dans des scénarios typiques.
La stratégie de compression de l'historique doit être choisie en fonction des caractéristiques de la tâche de l'agent ; aucune stratégie unique ne peut être optimale dans tous les scénarios.
Les informations sensibles dans le contexte (clés API, chemins internes, etc.) peuvent se propager via les appels d'outils et les journaux, une désensibilisation appropriée est donc nécessaire.
Concepts associés
| Concept | Description |
|---|---|
| Ingénierie de prompt | Se concentre sur la conception et l'optimisation du prompt pour un seul appel |
| Fenêtre de contexte | Le nombre maximal de tokens qu'un modèle peut traiter en une fois |
| Token | La plus petite unité sémantique de texte traitée par un modèle |
| RAG (Génération augmentée par récupération) | Un modèle d'architecture qui étend le contexte par une récupération externe |
| Prompting few-shot | Fournir des exemples dans le contexte pour guider la sortie du modèle |
| Chaîne de pensée | Laisser le modèle montrer son processus de raisonnement dans le contexte |