Pourquoi il faut créer soi-même des agents

• Les agents LLM sont une architecture technique qu’il vaut mieux implémenter soi-même plutôt que de seulement comprendre en théorie, afin d’en saisir concrètement le fonctionnement
• Avec seulement quelques dizaines de lignes de code Python, on peut créer un agent conversationnel à l’aide de l’OpenAI Responses API, et en y ajoutant la fonction d’appel d’outils (tool call), lui permettre d’agir de manière autonome
• Le cœur d’un agent réside dans une boucle d’appels répétés vers un LLM sans état, avec une gestion directe du contexte de conversation pour mettre en œuvre des échanges sur plusieurs tours
• Le Context Engineering est un vrai problème de niveau programmation, qui exige de concevoir une optimisation des entrées, sorties et descriptions d’outils dans les limites de tokens disponibles
• La conception d’agents constitue aujourd’hui un espace ouvert de problèmes d’ingénierie logicielle, dans lequel même un développeur individuel peut tenter de nouvelles approches par l’expérimentation

---

La simplicité d’écrire un agent

• Un agent LLM peut être implémenté sans configuration complexe, avec la seule OpenAI Responses API
  • Dans l’exemple de code, la liste context sert à stocker les échanges entre l’utilisateur et le modèle, puis à les réinjecter en boucle pour produire des réponses conversationnelles de type ChatGPT
• En créant deux contextes avec une « bonne personnalité » et une « mauvaise personnalité », on peut simuler une conversation à personnalités multiples
  • Le LLM est sans état, et la continuité de la conversation est maintenue par un tableau de chaînes (context) géré par l’utilisateur
• Cette structure simple suffit déjà à permettre une conversation sur plusieurs tours, tout en donnant une compréhension directe du fonctionnement d’un LLM

Intégration d’outils et fonctionnement autonome

• On peut ajouter à l’agent une fonction ping enregistrée comme outil pour vérifier l’état d’une connexion réseau
  • L’API OpenAI demande une définition d’outil au format JSON, et lorsque le LLM demande l’appel d’un outil, le code Python l’exécute puis renvoie le résultat
• Même sans instruction explicite, le LLM ping automatiquement plusieurs hôtes (google.com, www.google.com, 8.8.8.8)
  • Cela montre qu’avec le seul « droit d’utiliser un outil », le LLM a effectué un jugement autonome
• La boucle complète suit simplement la structure « demande d’appel d’outil → exécution → retour du résultat », ce qui permet de mettre en œuvre un agent autonome sans logique de contrôle complexe

Applications concrètes et critique de MCP

• Le code d’exemple est simple, mais on peut l’étendre de manière utile en y combinant des outils supplémentaires (comme traceroute) ou un stockage du contexte basé sur SQLite
• Le MCP (Multi-Context Protocol) n’est qu’une interface de plugin pour Claude Code ou Cursor, pas une technologie indispensable
  • En manipulant directement l’API, il est possible d’implémenter les mêmes fonctions sans MCP
• Le MCP n’est utile que dans des environnements où l’on n’a pas le contrôle du code, et il peut au contraire limiter la flexibilité de l’architecture d’agent
• La sécurité des LLM est complexe, mais il est possible de concevoir une structure sûre grâce à des contextes séparés et des restrictions sur les outils

L’importance du context engineering

• Le « prompt engineering » est un concept exagéré, mais le context engineering est un véritable problème de programmation
  • Le nombre de tokens dans la fenêtre de contexte est limité, et les entrées, sorties ainsi que les descriptions d’outils occupent toutes de l’espace
  • Si cette limite est dépassée, la qualité des réponses du modèle devient instable
• Comme solution, on peut créer des sous-agents (sub-agents) avec des contextes et des outils différents, puis les concevoir pour qu’ils résument et échangent entre eux
  • Ce type de structure peut être étendu à diverses expérimentations, comme des réseaux d’agents en arbre ou une compression fondée sur des résumés en temps réel
• Même des idées complexes conservent un niveau de simplicité permettant une implémentation en 30 minutes

Un problème d’ingénierie ouvert et la valeur de l’expérimentation

• Aujourd’hui, de nombreuses startups développent des agents de détection de vulnérabilités, et un développeur individuel peut mener les mêmes expérimentations
• La conception d’agents inclut des problèmes d’ingénierie encore non résolus, tels que :
  • l’équilibre entre non-déterminisme et programmation structurée
  • la vérification par le réel (ground truth) et la prévention d’un arrêt prématuré de la boucle
  • les formats d’échange de données entre agents multi-étapes (JSON, SQL, Markdown, etc.)
  • l’allocation des tokens et le contrôle des coûts
• Ces problèmes ne relèvent pas nécessairement de recherches à grande échelle : ils peuvent aussi être explorés par des expérimentations individuelles, chaque itération étant réalisable en quelques dizaines de minutes
• En conclusion, l’expérience de construire soi-même un agent est le point de départ pour comprendre la technologie des LLM

[GN⁺]

Avis Hacker News

• Il y a vraiment énormément de choses à faire. J’aimerais construire un CPU moi-même sur une breadboard avec des portes NAND, et aussi créer un CDN en Rust, mais je manque de temps
  Alors j’ai construit un LLM en suivant le tutoriel de Karpathy, et j’ai trouvé que faire ce genre de petites expérimentations au fil de l’eau est plutôt une bonne approche

  • Ça ressemble à une courbe sans fin. Avant, j’avais construit un ordinateur 8 bits sur une breadboard, et cette fois je me suis plongé dans la formation de pilote (PPL)
    Chaque fois que j’ai l’impression d’avoir « enfin fini », j’ai la sensation que la ligne d’arrivée s’éloigne encore. Au fond, les gens comme nous sont sans doute du genre à ne jamais être totalement satisfaits
  • Le début du TFA explique à quel point c’est facile à faire. C’est justement le point central de l’article

• L’exemple utilise GPT-5, mais l’interface de requête est déjà au niveau d’un standard industriel
  Par exemple, en branchant OpenRouter.ai, on peut facilement changer de modèle et de fournisseur à l’exécution
  Il propose aussi des modèles gratuits (par ex. DeepSeek), mais ils sont lents et limités. Cela dit, c’est excellent pour expérimenter

• Il y a quelques mois, j’ai créé moi-même un agent en Ruby. C’était vraiment amusant
  La logique centrale tenait en seulement quatre lignes, et c’était conceptuellement étonnamment simple

  until mission_accomplished? or given_up? or killed?
    determine_next_command_and_inputs
    run_next_command
  end
  

• Il y a 2 ans, j’ai créé un agent en 25 lignes de PHP, et à l’époque il n’y avait même pas de tool calling, mais ça fonctionnait plutôt bien
  Pour moi, les LLM ressemblent à des outils UNIX de manipulation de texte comme sed ou awk — on leur donne une entrée et une instruction, et ils produisent une sortie
  En combinant ainsi des appels à des LLM et en ajoutant des boucles ou des branchements, on obtient un système assez puissant
  Code associé : hubcap, llm

  • J’aime vraiment beaucoup hubcap. Il y avait peu de code, mais le résultat était impressionnant
    J’ai été très inspiré par l’article de Simon Willison

• La partie sur la création de sa propre alternative à Claude Code me parle particulièrement. Construire un agent de codage auto-améliorant est une expérience presque magique
  On peut changer de modèle librement, et avec des modèles rapides comme Cerebras, la différence est énorme même dans les appels d’outils conversationnels
  En y ajoutant de la mémoire, de la reconnaissance vocale, etc., c’est bien plus efficace. Ça peut se mettre en place en quelques minutes et c’est vraiment amusant

  • Je me demande quel modèle de reconnaissance vocale tu utilises. Whisper était lent et peu précis, et les modèles audio de GPT produisent souvent des réponses de refus
    Les modèles de Google avaient une qualité faible, et les modèles de Mistral sont rapides mais réagissent parfois au texte lui-même
    Du coup, il arrive parfois qu’au lieu de transcrire ce que j’ai dit, ils retranscrivent le flux de conscience du LLM
  • J’aime vraiment beaucoup l’expression « build your own lightsaber »
    Au départ je l’ai fait pour comprendre la structure interne, mais c’était plus simple que je ne l’imaginais, donc maintenant j’ajoute directement les fonctions que je veux
    On peut ajouter des fonctionnalités plus vite qu’un produit conçu pour une équipe. Les agents ont une structure étonnamment simple
  • Pour débuter, je ne saurais même pas par où commencer. C’est la première fois que j’entends parler de Cerebras. Pour l’instant, je n’utilise que Copilot dans VS Code
    Je me demande si ça repose sur des modèles locaux
  • Cerebras propose désormais glm 4.6. C’est toujours incroyablement rapide, et maintenant c’est aussi bien plus intelligent

• Cet article donne envie de recréer la philosophie Unix — des outils qui font bien une seule chose
  Non seulement cela simplifie les agents, mais cela améliore aussi leur sécurité

  • En 2021, j’ai créé un agent pour tester la connectivité réseau, et confier à l’agent des outils de base comme ping, dig, traceroute donnait des résultats plutôt corrects
    Ce n’était pas aussi parfait qu’un système de télémétrie conçu par des humains, mais on pouvait atteindre 90 % d’utilité bien plus facilement
  • On peut aussi imaginer un ensemble d’outils à objectif limité exposé directement aux humains
  • Pour bien faire une seule chose, il faut davantage d’outils, et donc une compréhension du contexte plus importante
    La taille idéale d’un LLM se situerait probablement à mi-chemin, un peu au-dessus des outils Unix traditionnels

• Je me demande : « faut-il vraiment construire un agent ? »
  Alors que tous les fournisseurs d’IA perdent de l’argent, je doute qu’un modèle économique durable soit possible

  • Le fait d’en construire un soi-même permet de comprendre intuitivement le fonctionnement et les limites des agents. C’est ça l’essentiel
  • Cet article parle simplement d’expérimenter la technologie pour le plaisir. Cela n’a rien à voir avec la monétisation
    C’est une logique comparable au fait d’évoquer les pertes d’Astral comme raison pour ne pas utiliser Python
  • Toutes les entreprises d’IA ne sont pas déficitaires
    Elles ont besoin de financement parce que le coût d’entraînement du modèle suivant est élevé, mais l’inférence est rentable
  • On peut aussi devenir soi-même fournisseur d’IA
  • Ce commentaire dégage une certaine fatigue émotionnelle. Je me demande si son auteur est un développeur très expérimenté

• La partie sur le context engineering me parle particulièrement
  Je construis un assistant personnel, et il a davantage de mémoire, de suivi des tâches et de capacité de résolution de problèmes qu’un agent générique
  Je l’ai conçu pour que plusieurs agents dialoguent entre eux afin de résoudre des problèmes, et le premier agent joue le rôle de superviseur de gestion des tâches
  Plus on approfondit ce processus, plus cela devient un problème d’ingénierie
  J’ai détaillé cela dans mon billet de blog

  • Ça a l’air d’être un projet vraiment génial

• Tout le monde aime créer des agents, mais personne n’aime les déboguer
  Au début, ça marche comme par magie, puis les échecs probabilistes s’accumulent peu à peu et deviennent difficiles à reproduire
  Chaque étape prend 0,5 seconde, donc pour vérifier où ça a déraillé, il faut parfois attendre 10 à 20 minutes

  • C’est pour ça que j’ai créé un outil d’exécution parallèle, pour lancer des centaines d’essais avec le code modifié
    et rejouer aussi les anciens scénarios afin de vérifier que rien n’a été cassé

• J’ai créé un MCP à partir du code fourni : gurddy-mcp.fly.dev
  Le code source est visible dans le dépôt GitHub