Comment fonctionne Codex : un harness fin plutôt qu'un agent lourd
CodexИИ-агентыархитектура ПО
Codex repose sur une couche légère
Le point le plus marquant est que Codex n'est pas conçu comme un agent monolithique, mais comme un modèle associé à un harness relativement fin. Dans l'article de Pragmatic Engineer « Building Codex with Tibo Sottiaux », les éléments clés sont un Codex CLI ouvert en Rust, la prise en charge de modèles issus de plusieurs fournisseurs et une couche responsable de la sécurité, de la fiabilité et de l'efficacité.
Au moment de la publication, le CLI était ouvert et le produit n'était pas enfermé chez un seul fournisseur de modèles. Le choix de Rust semble être un pari sur les performances, la portabilité et le comportement prévisible d'un outil local. Le code ouvert réduit aussi la méfiance envers un agent qui peut accéder au dépôt et exécuter des commandes.
L'idée la plus forte de l'article ne concerne pas le langage d'implémentation. Le harness évolue avec les modèles et s'amincit lorsqu'ils deviennent meilleurs pour planifier, choisir les outils et garder le cap sur la tâche. Les scénarios d'agents codés en dur passent vite du rôle de filet de sécurité à celui de plafond qui freine un modèle plus compétent.
Fin ne veut pourtant pas dire simple. Il faut compresser le contexte sans perdre l'état de travail et normaliser les comportements de modèles différents dans une boucle commune. L'ajout d'une interface conversationnelle complique encore l'ensemble : exécution de code, dialogue et travail autonome de l'agent doivent coexister sans conflit.
Selon l'article, l'équipe n'utilise pas Codex uniquement pour générer des extraits de code. Les cas d'usage incluent la revue, la maintenance et la réarchitecture. C'est un signal important : le produit est pensé pour l'ensemble du processus d'ingénierie, et non pour une simple démonstration spectaculaire d'autocomplétion.
Ce qui change pour l'architecture des agents
La conclusion pratique est que les frameworks lourds pour agents commencent à céder du terrain à un harness compact et robuste. Plus le modèle est capable, plus les couches superflues de planification, de routage et de rôles prédéfinis coûtent cher.
- La logique se déplace vers le modèle. Le harness garde le contrôle des outils, de la sécurité et de la reprise après incident, mais ne cherche pas à imposer chaque étape.
- Le multi-modèle exige de la rigueur. La liberté de choisir un fournisseur apporte une complexité d'intégration : une interface identique ne garantit pas un comportement identique.
- Le contexte devient une composante de l'architecture. La qualité de l'agent dépend non seulement du modèle, mais aussi de l'état qui survit à chaque cycle.
Ce n'est pas une recette universelle, mais un changement de priorité utile : moins de magie dans l'orchestration, plus d'attention aux limites d'accès, à l'état et aux défaillances. La frontière entre un harness utile et une supervision superflue du modèle est désormais le principal risque architectural.