Как устроен AI-агент: слои-обёртки вокруг LLM и где искать источник бага

Un développeur avec un bagage en ML a publié sur Habr, en juillet 2026, une analyse du fonctionnement interne des agents IA : au centre de tout schéma agentique demeure un unique LLM, tandis qu'autour de lui grossit un « oignon » de couches d'enveloppe, et la plupart des pannes surviennent justement dans ces couches, et non dans le modèle lui-même.

Ce qui se cache derrière le mot « agent »

Un agent IA n'est pas le réseau de neurones lui-même, mais plusieurs couches de code autour de lui. Les frameworks changent, des serveurs MCP apparaissent, les plateformes cloud promettent un « agent prêt à l'emploi », mais le noyau est partout le même : un grand modèle de langage (LLM) qui lit le contexte et propose l'étape suivante. Tout ce qui est à l'extérieur est l'habillage qui prépare l'entrée et traite la sortie du modèle.

L'auteur énumère les niveaux typiques à partir desquels on assemble un agent au-dessus du modèle :

• LLM — le noyau, prédit les probabilités du prochain token
• Couche de prompt et de contexte — ce qui entre exactement dans le modèle
• Orchestration et appel d'outils — comment la réponse du modèle se transforme en action
• Serveurs MCP — accès standardisé de l'agent aux données et fonctions externes
• Frameworks et enveloppes cloud — un « agent prêt à l'emploi » par-dessus tout cela

Chaque niveau ajoute sa propre logique : l'un rassemble le contexte, l'autre décide quel outil appeler, un troisième connecte des données externes. Le modèle lui-même n'exécute aucune de ces étapes — il ne fait que prédire du texte.

Pourquoi le bug n'est généralement pas dans le modèle

La source d'une panne dans un agent se trouve généralement non pas dans le LLM, mais dans l'une des couches externes : dans la façon dont le prompt a été assemblé, dont le contexte a été transmis, dont l'appel d'outil a été traité. Le modèle lui-même, selon la formulation de l'auteur, ne fait qu'une seule chose — prédire le prochain token ; tout le reste est ajouté par les enveloppes qui l'entourent.

«

Le modèle lui-même ne fait que prédire les probabilités du prochain token ; à l'extérieur grossit un oignon d'enveloppes », — l'auteur de l'article sur Habr.

C'est précisément pour cela, note l'auteur, qu'il est important, lors du débogage, de comprendre toute la construction : si l'agent n'est pas assemblé à partir d'un kit tout fait, connaître les couches aide à localiser plus vite le problème. Vérifier le modèle en premier est une erreur fréquente : si la réponse de l'agent semble incorrecte, la cause tient plus souvent au fait qu'un mauvais contexte est parvenu au modèle, ou qu'un niveau voisin a mal interprété sa réponse. Le modèle, lui, a fonctionné normalement.

Pourquoi regarder du modèle vers l'extérieur

L'analyse est construite du noyau vers la périphérie — du LLM vers les enveloppes externes — car l'auteur est arrivé aux agents depuis le ML, où chaque nouvelle couche se pose sur quelque chose de déjà familier. Cet ordre, selon lui, rend le tableau plus clair : d'abord ce que fait le modèle, puis ce que fait chaque enveloppe au-dessus de lui. Le chemin inverse — d'un « agent prêt à l'emploi » tout fait vers l'intérieur — cache précisément où passe la frontière de responsabilité de chaque couche.

L'occasion de l'article est banale : les notes sont nées après une énième recherche conjointe de bug avec l'équipe technique. L'auteur les a rassemblées en une seule synthèse afin que la prochaine fois il soit plus facile d'expliquer aux collègues où se trouve quoi dans le schéma de l'agent et où regarder en cas de panne. Au fond, c'est une carte des niveaux commode à consulter pendant le débogage.

Ce que cela signifie

Derrière le mot à la mode « agent » se cache une pile de plusieurs couches, et comprendre cette structure est une compétence pratique de débogage : quand un agent se comporte mal, l'analyse doit commencer non pas par le LLM, mais par les enveloppes qui l'entourent, où se cache la plupart des erreurs.