Sous-agents Codex : Améliorer les flux de travail de développement d'IA

J'aimerais examiner les points suivants sur la PR actuelle (cette branche vs main). Générez un agent par point, attendez qu'ils soient tous terminés, et résumez le résultat pour chaque point.

1. Problème de sécurité
2. Qualité du code
3. Bugs
4. Conditions de course
5. Instabilité des tests
6. Maintenabilité du code

Dans ce scénario, Codex lancerait probablement six sous-agents distincts, chacun spécialisé dans l'un des points de revue énumérés. Une fois que chaque agent aurait terminé son analyse, Codex compilerait les résultats en un rapport unique et structuré, offrant une vue d'ensemble holistique de la pull request. Cela illustre l'efficacité gagnée en distribuant la charge de travail entre des entités d'IA spécialisées.

## Gérer et Sécuriser Votre Écosystème de Sous-agents

Une gestion efficace et une sécurité robuste sont des considérations clés lors de l'utilisation de sous-agents. Codex fournit des outils et des mécanismes pour superviser les activités des sous-agents et garantir des opérations sécurisées dans leurs environnements sandbox.

Dans les sessions CLI interactives, les développeurs peuvent utiliser la commande `/agent` pour basculer entre les threads d'agents actifs, inspecter les processus en cours ou diriger un sous-agent particulier. Ce contrôle granulaire permet des ajustements en temps réel et la surveillance de la progression des agents individuels. Vous pouvez également demander explicitement à Codex d'arrêter un sous-agent en cours d'exécution ou de fermer les threads terminés pour gérer les ressources et vous concentrer.

La sécurité est primordiale, et les sous-agents héritent de la politique de sandbox actuelle de la session Codex principale. Cela garantit que leurs opérations respectent les règles de sécurité et d'accès prédéfinies. Lorsque des demandes d'approbation émanent de threads d'agents inactifs, en particulier dans les sessions CLI interactives, Codex les présente intelligemment à l'utilisateur. Une superposition d'approbation indiquera le thread source, vous permettant d'appuyer sur 'o' pour ouvrir et inspecter ce thread avant de prendre une décision éclairée d'approuver, de rejeter ou de répondre à la demande. Cela empêche les approbations aveugles et maintient la supervision du développeur.

Pour les flux non interactifs ou les situations où une nouvelle approbation ne peut pas être présentée, toute action nécessitant une nouvelle approbation échouera automatiquement, Codex signalant l'erreur au workflow parent. Ce mécanisme de sécurité empêche les actions non autorisées dans des contextes automatisés. De plus, Codex réapplique les overrides d'exécution en direct de la session parente — tels que les modifications effectuées via `/approvals` ou l'indicateur `--yolo` — aux enfants générés, assurant des postures de sécurité cohérentes dans la hiérarchie des agents. Pour les utilisateurs avancés, il est également possible de remplacer la configuration du sandbox pour des [agents personnalisés](#définir-des-sous-agents-personnalisés-pour-des-tâches-adaptées) individuels, permettant un contrôle précis de leurs permissions, par exemple, en marquant un agent comme 'lecture seule'.

## Définir des Sous-agents Personnalisés pour des Tâches Adaptées

Bien que Codex fournisse plusieurs agents intégrés, tels que l'agent `default` à usage général, l'agent `worker` pour les tâches axées sur l'exécution et l'agent `explorer` pour l'exploration de bases de code gourmandes en lecture, la véritable puissance du système de sous-agents réside dans son extensibilité. Les développeurs peuvent définir leurs propres **agents personnalisés** pour répondre à des exigences hautement spécialisées, en adaptant le comportement de l'IA à des contextes de projet uniques.

Les agents personnalisés sont définis à l'aide de fichiers TOML autonomes. Ces fichiers peuvent être placés dans `~/.codex/agents/` pour les agents personnels ou `.codex/agents/` pour les agents spécifiques au projet. Chaque fichier TOML agit essentiellement comme une couche de configuration, permettant aux agents personnalisés de remplacer les paramètres qui seraient autrement hérités de la session parente. Cela inclut des paramètres critiques comme le modèle d'IA utilisé, son effort de raisonnement, le mode sandbox et même des configurations de compétences spécifiques.

Chaque fichier d'agent personnalisé autonome *doit* définir les champs suivants :

*   **`name`**: L'identifiant unique de l'agent, que Codex utilise lors de sa génération ou de sa référence.
*   **`description`**: Des conseils lisibles par l'homme qui aident Codex à comprendre quand déployer cet agent.
*   **`developer_instructions`**: L'ensemble principal d'instructions qui dictent le comportement et la logique opérationnelle de l'agent.

Des champs facultatifs comme `nickname_candidates`, `model`, `model_reasoning_effort`, `sandbox_mode`, `mcp_servers` et `skills.config` peuvent également être inclus. S'ils sont omis, ces paramètres hériteront de la session parente, simplifiant la configuration lorsque les valeurs par défaut sont acceptables. Pour les meilleures pratiques en ingénierie d'invites, qui influence directement les instructions de l'agent, reportez-vous à des ressources comme le [Guide d'invites Codex](/fr/codex-prompting-guide).

Le champ `name` est l'identifiant définitif d'un agent personnalisé. Bien que la correspondance du nom de fichier avec le nom de l'agent soit une convention courante et recommandée, le champ `name` dans le fichier TOML est la source de vérité ultime. Le champ `nickname_candidates` est un ajout utile pour l'expérience utilisateur, permettant à Codex d'attribuer des noms d'affichage plus lisibles aux agents générés, ce qui est particulièrement utile dans les scénarios multi-agents complexes.

## Paramètres Globaux et Configuration Avancée des Sous-agents

Au-delà des définitions individuelles d'agents personnalisés, Codex offre des paramètres de configuration globaux pour gérer le comportement général des flux de travail des sous-agents. Ces paramètres se trouvent généralement sous la section `[agents]` de votre fichier de configuration principal, offrant un contrôle centralisé sur l'allocation des ressources et les paramètres opérationnels.

Voici une ventilation des principaux paramètres globaux des sous-agents :

| Champ | Type | Obligatoire | Objectif |
| :--------------------------- | :----- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `agents.max_threads`         | nombre | Non       | Limite le nombre de threads d'agents ouverts simultanément. Par défaut à `6` si non défini.                                                                                                                                                                                                                                                                                                                                                                           |
| `agents.max_depth`           | nombre | Non       | Limite la profondeur d'imbrication des agents générés (la session racine commence à 0). Par défaut à `1`. Empêche la délégation récursive au-delà des enfants immédiats pour gérer l'utilisation des jetons et la latence.                                                                                                                                                                                                                                                        |
| `agents.job_max_runtime_seconds` | nombre | Non       | Définit le délai d'attente par défaut par travailleur pour les tâches `spawn_agents_on_csv`. Si non défini, par défaut à `1800` secondes (30 minutes).                                                                                                                                                                                                                                                                                                                       |

Le paramètre `agents.max_threads`, qui est de `6` par défaut, constitue une protection contre la consommation excessive de ressources en limitant le nombre de sous-agents pouvant fonctionner simultanément. Le paramètre `agents.max_depth`, avec sa valeur par défaut de `1`, est particulièrement important. Bien qu'une imbrication plus profonde puisse sembler attrayante pour une délégation complexe, l'augmentation de cette valeur peut entraîner une augmentation significative de l'utilisation des jetons, de la latence et de la consommation de ressources locales en raison d'une prolifération répétée. Il est généralement recommandé de maintenir la valeur par défaut, sauf si un modèle de délégation récursive spécifique est absolument nécessaire et géré avec soin.

Les fichiers d'agents personnalisés peuvent également inclure d'autres clés `config.toml` prises en charge, étendant leur configurabilité au-delà des seuls champs obligatoires. Cette approche de configuration modulaire et en couches garantit que les développeurs ont un contrôle précis sur leurs agents IA, leur permettant d'optimiser les performances, les coûts et la sécurité adaptés à leurs besoins de développement spécifiques. En comprenant et en tirant parti de ces puissantes capacités de sous-agents, les développeurs peuvent repousser les limites du codage assisté par l'IA et améliorer considérablement leurs flux de travail de développement.