La conception d’agents reste difficile

 (lucumr.pocoo.org)
20 points par GN⁺ 2025-11-23 | 1 commentaires | Partager sur WhatsApp
  • Le processus de construction d’un agent reste complexe, et les abstractions des SDK se brisent souvent au moment de l’utilisation réelle des outils
  • La gestion du cache varie selon les plateformes ; une gestion manuelle est plus prévisible et plus efficace, et l’approche par points de cache explicites du SDK Anthropic est privilégiée
  • La boucle de renforcement (reinforcement loop) joue un rôle clé dans le suivi de l’état des tâches et la récupération après échec, et les échecs doivent être isolés séparément pour éviter l’effondrement de la boucle
  • Pour la gestion de l’état partagé, une hiérarchie de type système de fichiers est importante et sert d’infrastructure de base pour l’échange de données entre outils d’exécution de code et de raisonnement
  • Le choix des outils de sortie et des modèles reste délicat, et la complexité de la conception d’agents persiste, avec notamment Haiku, Sonnet et Gemini qui demeurent les principales options

Choisir un SDK d’agent

  • Lorsqu’on construit un agent, il faut choisir entre utiliser directement les SDK de base comme ceux d’OpenAI ou d’Anthropic, ou passer par des couches d’abstraction de plus haut niveau comme Vercel AI SDK ou Pydantic
    • L’auteur indique qu’il n’utilisait auparavant que l’abstraction provider de Vercel AI SDK, mais qu’il ne referait plus ce choix aujourd’hui
  • Les différences entre modèles sont importantes, ce qui impose de construire soi-même une couche d’abstraction pour les agents ; les abstractions des SDK existants ne conviennent pas
    • Il existe des différences subtiles sur le contrôle du cache, les exigences de renforcement, les prompts d’outils, etc.
  • Le SDK Vercel pose des problèmes dans le traitement des outils côté provider
    • Il existe des cas où l’outil de recherche web d’Anthropic corrompt l’historique des messages
    • En utilisant directement le SDK Anthropic, la gestion du cache et les messages d’erreur sont plus clairs
  • En conclusion, l’approche consistant à utiliser directement les SDK sans couche d’abstraction est aujourd’hui jugée plus avantageuse

Leçons sur la gestion du cache

  • Les approches de cache diffèrent selon les plateformes, et Anthropic facture le cache tout en exigeant une gestion explicite
    • La gestion manuelle est préférée car elle rend le coût et l’utilisation du cache plus prévisibles
  • Le cache explicite permet l’exécution de branches de conversation ou la modification du contexte
    • Il est possible de définir plusieurs points de cache : après le prompt système, au début de la conversation, etc.
  • Pour conserver le cache, le prompt système et le choix des outils doivent rester statiques, tandis que les informations dynamiques comme l’heure sont transmises dans des messages ultérieurs
  • La boucle de renforcement est utilisée activement avec le cache afin d’améliorer la prévisibilité des coûts et le niveau de contrôle

Renforcement au sein de la boucle d’agent

  • Lorsqu’un outil est exécuté, il est possible de réinjecter dans la boucle non seulement le résultat brut, mais aussi des informations comme l’objectif, l’état de la tâche ou la cause de l’échec
  • Des outils de self-reinforcement comme l’outil todo write de Claude Code aident à faire progresser la boucle
  • Lors de changements d’environnement ou au moment de récupérer d’un échec, l’injection d’informations sur les changements d’état permet de stabiliser la boucle
    • Exemple : lors d’une nouvelle tentative fondée sur des données corrompues, insertion d’un message demandant de revenir à l’étape précédente

Isolation des échecs

  • Les tâches susceptibles d’échouer de manière répétée sont exécutées séparément dans un sous-agent (subagent), puis seul le résultat réussi est rapporté à la boucle supérieure
    • Le résumé des tentatives échouées sert de matériau d’apprentissage pour la tâche suivante
  • Dans le SDK Anthropic, la fonction context editing permet de supprimer l’historique des échecs
    • On ne conserve pas l’ensemble des informations d’échec, seulement les éléments nécessaires
    • En revanche, la modification du contexte peut invalider le cache et augmenter les coûts

Sous-agents et système de fichiers partagé

  • La plupart des agents reposent sur l’exécution et la génération de code, ce qui nécessite un stockage de données commun
    • Pour cela, un système de fichiers virtuel (VFS) est utilisé
  • Différents outils, pour la génération d’images, la compression ou le raisonnement, doivent partager les mêmes chemins de fichiers
    • Les outils ExecuteCode et RunInference doivent pouvoir accéder au même système de fichiers
  • Cette structure est essentielle pour supprimer les goulots d’étranglement dans l’échange de données et traiter des tâches continues au sein de la boucle

Outil de sortie

  • L’agent fonctionne non pas comme une session de chat, mais comme une boucle interne de messages privée, et la communication avec l’extérieur passe par un outil de sortie
    • L’outil de sortie prend en charge les communications externes, comme l’envoi d’e-mails
  • Il est difficile de contrôler le ton et le style de l’outil de sortie, et l’utilisation d’un LLM auxiliaire (Gemini 2.5 Flash) entraîne une baisse de qualité et de la latence
    • Le sous-outil ne dispose pas d’un contexte suffisant, ce qui produit des résultats imprécis
  • Si l’outil de sortie n’est pas appelé à la fin de la boucle, un message de renforcement est injecté pour déclencher son appel

Choix des modèles

  • Haiku et Sonnet sont utilisés comme modèles principaux de boucle en raison de leurs bonnes performances en appel d’outils
  • Gemini 2.5 convient bien au résumé de longs documents, au traitement de PDF et à l’extraction d’informations à partir d’images
    • Le modèle Sonnet a l’inconvénient d’être souvent bloqué par les filtres de sécurité
  • Les modèles de la famille GPT n’ont pas donné de résultats marquants dans la boucle principale
  • Le coût total ne peut pas être évalué à partir du seul coût des tokens
    • Un meilleur modèle d’appel d’outils peut accomplir la même tâche avec moins de tokens

Tests et évaluation

  • L’automatisation des tests et de l’évaluation d’agents est présentée comme le problème le plus difficile
    • Contrairement aux prompts, il n’est pas possible de faire une évaluation simple depuis un système externe
    • Il faut de l’observabilité ou de l’instrumentation fondée sur les données d’exécution réelles
  • Il indique ne pas avoir encore trouvé de méthode d’évaluation satisfaisante

Mise à jour sur les agents de code

  • Les changements liés aux agents de code restent limités
    • Il teste récemment l’agent Amp et apprécie beaucoup la structure d’interaction entre le sous-agent Oracle et la boucle principale
  • Amp et Claude Code donnent l’impression d’avoir été conçus par des développeurs qui utilisent réellement leurs propres outils

À lire aussi

1 commentaires

 
GN⁺ 2025-11-23
Avis Hacker News

  • J’ai créé une entreprise dans ce domaine il y a environ 2 ans. Elle fonctionne bien aujourd’hui
    Ce que j’ai appris pendant ces 2 dernières années, c’est que beaucoup de techniques sont des optimisations temporaires destinées à compenser les limites actuelles des LLM. Comme la technologie évolue vite, le problème d’aujourd’hui peut disparaître demain
    Autrefois, quand AWS n’avait pas de fonctionnalité de chiffrement de disque, notre équipe a passé 3 mois à l’implémenter elle-même, puis AWS a sorti peu après un chiffrement standard activable en un clic. Au final, c’était du temps perdu
    Donc la leçon retenue, c’est que parfois, ne rien faire est la meilleure option

    • Je pense que c’est l’intuition essentielle. Ces temps-ci, des collègues organisent des ateliers IA en disant avoir “inventé” de nouveaux patterns, mais la plupart seront dépassés la semaine suivante
      L’époque où l’on apprenait des patterns comme un langage commun est terminée ; aujourd’hui, la demi-vie des patterns IA est d’environ une semaine. Même si vous demandez à 10 experts ce qu’est un “agent”, vous aurez 10 réponses différentes
    • Vu la vitesse des progrès de l’IA, si on attend assez longtemps, on finira peut-être simplement par utiliser OpenAI en direct
    • Je me demande si votre modèle est rentable, c’est-à-dire si le chiffre d’affaires dépasse les coûts d’exploitation. J’avais du mal à croire qu’il soit possible de gagner de l’argent avec des agents. J’aimerais connaître le secret
    • Savoir quand “ne rien faire” est lié à la capacité d’évaluer si le problème traité par l’équipe est central ou périphérique
    • D’accord. En ce moment, attendre peut aussi être une stratégie. Mais si on attend trop, on peut tomber dans le piège de ne plus rien faire jusqu’à l’arrivée de l’AGI

  • Au cours des 2 dernières années, j’ai essayé plusieurs SDK d’agent, et en en construisant un moi-même, j’ai découvert que c’était bien plus complexe que prévu
    Le Claude Code SDK (aujourd’hui Agent SDK) est excellent, mais il n’est pas encore complètement découplé de Claude Code. Par exemple, les skills doivent être placées directement dans le système de fichiers
    Le SDK d’OpenAI permet le suivi et l’évaluation automatiques dans le tableau de bord grâce à son fort couplage avec la plateforme, mais l’intégration de modèles tiers est difficile
    Le Google Agent Kit n’a pas encore de SDK Typescript, et Mastra est peu pratique parce qu’il faut lancer un serveur
    En ce moment, je teste le SDK de SmythOS, qui offre une grande liberté dans le choix du fournisseur de modèle et la définition de l’architecture
    Je me demande si votre architecture actuelle est de type Agent → SubAgents → SubSubAgents, ou plutôt de type Planner-Executor

    • La plupart des SDK deviennent un cauchemar dès qu’on dépasse les fonctionnalités de base. J’ai donc tout implémenté moi-même avec la bibliothèque cliente OpenRouter
      Il y a plus de code, mais le modèle mental est simple, donc c’est beaucoup plus facile à comprendre. Je fais tourner une boucle de type ReAct en répétant raisonnement et appels d’outils
      Au final, même sans SDK, on peut implémenter soi-même le handoff d’agent ou les workflows
    • Je pense que le terme “sub-agent” est presque inutile. Au fond, ce n’est qu’une abstraction de l’appel d’outil ; hors de la boucle principale, seul un simple contrat d’entrée/sortie importe
    • Il a été dit que Claude Code ne prenait en charge que les modèles Anthropic, mais avec Claude Code Router, on peut aussi brancher d’autres modèles
    • J’utilise la version Go de Google ADK ; c’est encore immature, mais j’en suis satisfait pour sa composition de workflows et sa compatibilité avec les fournisseurs
    • J’ai aussi utilisé le Strands Agents SDK d’AWS ; il prend en charge les principales API de fournisseurs même sans Bedrock, et le design de l’API est très flexible (je travaille chez AWS, mais c’est un avis personnel)

  • Je partage quelques principes de conception d’agent que nous avons appris

    1. S’il y a beaucoup de génération de code, Claude Code / Agent SDK est le plus efficace
    2. Le risque plus grand que la dépendance à un fournisseur, c’est de créer un produit moins bon que ChatGPT
    3. Claude Code a une excellente conscience de soi : dès qu’on lui pose une question sur lui-même, il répond immédiatement et correctement
    4. Donner un vrai ordinateur à un agent le rend beaucoup plus puissant. Nous utilisons e2b.dev, mais Modal est aussi très bien
      Pour référence, notre entreprise Definite est une plateforme de données exploitée par un ingénieur data IA, un peu comme Heroku
    • Claude est créatif, mais sur des bases de code complexes, il peut halluciner et faire du reward hacking. Dans ce cas, Codex est plus stable
    • Je pense que le problème, c’est que beaucoup de produits sortent avec une qualité inférieure à celle du site web de ChatGPT
    • Au lieu de construire à tout prix son propre système d’agent, il vaut mieux tirer parti d’outils aboutis comme Claude Code et se concentrer sur la création de vraie valeur
    • Bien sûr, dire “confions tout à la big tech” est dangereux. Le processus de construction, d’apprentissage et de partage en direct est important. Moi aussi, je progresse vite grâce à ADK et à une extension VS Code

  • Je construis des agents depuis plusieurs années, et la meilleure décision a été de bâtir directement notre propre framework
    Plusieurs couches d’abstraction open source deviennent impossibles à maintenir à mesure que les SDK évoluent, puis finissent par s’effondrer

    • Je pense pareil. Le cœur d’un agent, c’est l’entrée/sortie structurée, la boucle d’enregistrement et d’appel des outils, et la délégation entre agents
      J’ai créé OpusAgents sur la base de PydanticAI ; c’est un framework open source extensible plus simple que des serveurs MCP
    • En tant qu’auteur, je suis d’accord. J’ai résumé mes réflexions dans ce post
    • Nous aussi, en construisant un chatbot pour le support client, nous avons adopté une architecture basée sur des salons de discussion au lieu d’une structure existante. Le frontend se contente d’envoyer des messages, et le backend étend progressivement les fonctionnalités
    • Cela dit, construire soi-même un framework complet est un gros chantier. À long terme, il est possible que les plateformes d’agents se standardisent comme les moteurs de jeu

  • En ce moment, on revit les excès d’abstraction et de complexité des débuts de LangChain/RAG
    Au fond, un agent peut se concevoir comme une simple structure REPL (Read, Eval, Print, Loop).
    La version légère que j’ai implémentée avec cette idée a été bien plus stable que les SDK lourds

    • Mais dans les cas d’usage réellement complexes, on finit par avoir besoin de subagents spécialisés et de structures de partage de données. Une simple boucle a ses limites

  • Le problème le plus difficile dans les agents, ce sont les tests et les évaluations (evals).
    Il y a trop d’entrées pour évaluer avec un système externe, et il faut observer les données pendant l’exécution
    Je ne sais toujours pas vraiment quelle approche est efficace

    • Je m’inquiète du fait que la plupart des déploiements d’agents IA semblent reposer sur l’intuition sans véritables tests formels
    • Si l’on regarde la documentation d’évaluation de l’ADK, les résultats varient d’une exécution à l’autre, ce qui rend difficile la définition de critères de réussite/échec. Au final, on évalue encore avec un autre LLM

  • Même les aspects de base du développement d’agents manquent encore de lignes directrices claires
    Par exemple, dans la gestion des types d’entrée/sortie des outils de fonction, quand on passe des ID numériques, on rencontre des erreurs de sérialisation ou des pertes de précision
    J’ai fini par résoudre le problème en les convertissant en chaînes de caractères
    Si l’on regarde la documentation d’OpenAI (lien) et une issue de Google ADK (lien),
    il est écrit que “le résultat doit être une chaîne”, mais les exemples réels renvoient des dict ou des nombres. Ce décalage crée de la confusion

  • J’utilise le produit d’une certaine entreprise d’agentic coding (je ne donnerai pas le nom)
    Je suis satisfait, car ils gèrent tout — sorties de modèles, évaluations, gestion des subagents, facturation — et je peux simplement me concentrer sur mon travail

    • C’est probablement Amp de Sourcegraph. C’était brut au début, mais aujourd’hui c’est assez abouti

  • Au cours des deux derniers mois, j’ai implémenté des agents pour diverses tâches. Au départ, j’utilisais Claude Code, mais à cause de la dépendance au fournisseur et des limites d’usage, j’ai créé mon propre runtime
    Pour l’instant, il ne prend en charge qu’OpenAI, mais il a été conçu pour pouvoir ajouter aussi Claude ou Gemini
    Je l’ai publié en open source, donc cela peut servir de référence → agent-composer

  • Mon conseil est simple : n’utilisez pas de SDK, faites tourner vous-même une boucle while et manipulez le JSON
    Il faut contrôler directement la taille du contexte et les erreurs pour construire un agent vraiment flexible