Introduction Bonjour tout le monde, je suis Max Nechaev - directeur de l'ingénierie à Snoonu, fondateur et enthousiaste de l'IA. J'ai été dans le développement de logiciels pendant un certain temps. Quand je construisais des applications iOS, il y avait des tonnes de modèles architecturaux là-bas. Ils se sentaient solides. Pensé à travers. Bataille-testé au fil des ans. À l'époque, je n'imaginais jamais que je serais celui qui créerait une nouvelle architecture - surtout pas pour les systèmes d'IA. Mais avant d’arriver à la solution, parlons du problème. En ce moment, l'IA traverse un cycle de hype folle. Les start-ups apparaissent et meurent chaque jour. De plus en plus de gens se plongent dans des outils à faible code et sans code comme Make, n8n et d'autres. Et vous savez quoi? Je pense que c'est génial. Des millions de personnes entrent dans un nouveau type de réalité. Il se sent comme dans les premiers jours de l'Internet, lorsque les sites Web sont passés de statiques à interactives, et il a soudainement l'impression que tout était possible. De plus en plus de gens construisent des agents d'IA. Et j'aime ça. Mais il y a une prise en main. Il n'y a toujours pas de compréhension partagée de la façon d'architer des systèmes d'IA flexibles et évolutifs. Aucun modèle de conception réel. Aucune structure largement adoptée. Plus je regardais autour de moi, plus je le vis. Les agents construits dans n8n ressemblent à des spaghettis. Impossible à lire, à déboguer ou à évoluer. Tutoriels sur les agents de construction dans Python? La même histoire. Tout a été jeté dans un seul fichier, aucune séparation des préoccupations. Bien sûr, les développeurs expérimentés peuvent savoir qu'ils devraient diviser les choses - mais les débutants ne le font pas. Et ils finissent par construire des systèmes qui sont complètement insoutenables. Donc, aujourd’hui, je veux partager la solution sur laquelle je me suis appuyé.C’est ainsi que je structure mes systèmes d’IA.Comment je sépare les responsabilités.Comment je maintiens les choses flexibles, évolutives et réellement saines. Laissez-moi vous présenter mon cadre, mon modèle de conception ou mon architecture - appelez-le ce que vous voulez - Les chaînes d’action de l’agent. AAC Meet AAC (Agent Action Chains) À un moment donné, j’ai réalisé quelque chose de simple.Si le chaos se reproduit encore et encore, peut-être que ce n’est pas un accident. J'ai donc commencé à expérimenter. Premièrement, avec des blocs à l'intérieur de n8n. Puis j'ai commencé à séparer la logique manuellement - voici où je gère les entrées, voici où je fais le traitement, voici la logique de base. Finalement, les rôles ont commencé à émerger. C’est ainsi que naquit AAC – Agent Action Chains. Ce n'est pas un autre cadre avec mille pages de documents. AAC est une façon de construire des systèmes d'IA comme un ingénieur adulte, pas comme quelqu'un qui ramifie les choses et espère le meilleur. Quelle est l’idée centrale ? J'ai divisé le système en agents avec des rôles clairs. Chaque agent fait exactement une chose. Ils parlent tous à travers des contrats JSON - pas de deviner, pas de magie, pas de désordre. Tout devient prévisible, évolutif et plus facile à déboguer. Pensez-y comme à une équipe. Une porte d’entrée. d’autres processus de données. Un troisième décide de ce qu'il faut faire ensuite. Un autre agent parle à la mémoire. Un des échecs. Un autre regarde et enregistre tout. Et ensemble, le système fonctionne comme une montre suisse. La beauté de l'AAC est qu'il est agnostique sur la plate-forme. Vous pouvez le mettre en œuvre dans n8n, dans , en Python en utilisant FastAPI, même à l'intérieur de LangChain ou LangGraph si vous prenez le temps de le configurer correctement. Maquillage.com Here’s How It Works (In Plain English) Imaginez une équipe solide.Non pas un groupe chaotique où tout le monde fait tout à la fois, mais une équipe où chaque personne connaît son travail, possède son espace et fournit un résultat clair. C’est exactement comme ça que fonctionne AAC. Lorsqu'une entrée frappe le système - qu'il s'agisse d'un utilisateur ou d'un service externe - elle passe d'abord par un agent qui ouvre simplement la porte et l'éteint. Puis vient le traitement de base. Nous ne nous précipitons pas vers des conclusions. Tout d'abord, nous structurons l'entrée, nettoyons le bruit, la normalisons. Cette étape seule économise des heures de débogage sur la route. Une entrée propre est la moitié de l'architecture. Ensuite vient l'orchestreur. C'est le cerveau du système. Il n'exécute pas la tâche elle-même. Au lieu de cela, il découvre qui devrait faire quoi, dans quel ordre, avec quels paramètres. Le rôle de l'orchestreur est de planifier, diriger et gérer le flux. Rien de plus, rien de moins. Ensuite, les spécialistes prennent le contrôle. Ces agents sont concentrés. Un classifie, un autre résume, un troisième récupère des données externes, etc. Chacun a un but clair. Ils ne se superposent pas, ils ne se battent pas sur les responsabilités, ils ne réécrivent pas les sorties les unes des autres. Vous pouvez les échanger, les améliorer, les réutiliser - tout comme les bons modules logiciels. Lorsque le système a besoin de se souvenir de quelque chose, la mémoire entre en jeu. C'est son propre agent. Il ne stocke pas tout aveuglément. Au lieu de cela, il sait comment récupérer les bonnes choses au bon moment - conversations antérieures, contexte utilisateur, faits internes. C'est ainsi que votre système cesse d'être un poisson d'or et commence à agir comme un véritable assistant. La gestion des erreurs est traitée aussi au sérieux. AAC comprend un agent dédié pour cela - la Garde. Il surveille les échecs, capture les exceptions, prend des mesures lorsque quelque chose se brise. Ce n'est pas un patch, pas un essai aléatoire. C'est une partie réelle de l'architecture. Et il est responsable de la résilience. Alors que tout cela se passe, l'Observateur regarde en silence. Il suit ce que fait chaque agent, combien de temps les choses prennent, quelles décisions sont prises. Non seulement pour le plaisir - cela vous donne une visibilité dans le système. Non pas "a-t-il fonctionné?" mais Il a fonctionné, Il a fonctionné, et où il pourrait échouer. Comment Pourquoi Et enfin, lorsque toute la chaîne a fait son travail, le résultat est formaté et livré - de retour à l'utilisateur, dans une réponse API, ou partout où il doit aller. C’est AAC. Un système construit non seulement pour fonctionner, mais pour évoluer, évoluer et rester sous contrôle. All AAC Roles: Who Does What and Why It Matters Chaque agent n'est pas seulement un bloc technique - c'est une unité logique avec un rôle défini et un contrat de communication.Cette section décompose ce que ces rôles sont pour, comment ils interagissent, et pourquoi sauter même l'un d'eux conduit souvent à la douleur architecturale plus tard. Ingress Agent: the Entry Point Gérer le signal entrant. Purpose: Cela pourrait être un webhook, une soumission de formulaire, un message Telegram, un événement Kafka - cela n'a vraiment pas d'importance. Parce que mélanger la logique avec les couches d'intégration est la première étape vers la construction d'un monolith. Dans n8n, ce n'est généralement qu'un nœud webhook. Il reçoit la demande, enregistre les données et passe une charge utile JSON propre dans le système. Un exemple (pseudocode) : { "source": "user", "payload": { "message": "I’d like to return my order" } } Preprocessing Agent: the Filter and Normalizer Transformez les ingrédients bruts en quelque chose d’utile. Purpose: Cet agent nettoie le bruit. Il fixe le boîtier, bande des symboles étranges, valide la structure et extrait les champs clés. Il s'assure que tout ce qui est passé dans le système est prévisible et cohérent. Beaucoup de gens sautent le pré-traitement. Grande erreur. Ce n'est pas seulement un "bon à avoir" - c'est la base. Surtout lorsque vous traitez avec des LLM, l'hygiène du contexte est tout. Une entrée gênante et toute la chaîne de raisonnement peuvent tomber en panne. Dans n8n, c'est généralement un nœud de fonction. En code, il pourrait s’agir d’un middleware, d’un manipulateur ou d’une petite classe d’utilité. const cleanInput = input.message.trim().toLowerCase() Orchestrator Agent: the Brain of the System décider de ce qui doit arriver. Purpose: L'orchestre ne fait pas le travail lui-même. Son travail est de planifier, déléguer et surveiller. Il prend l'entrée nettoyée, détermine l'intention de l'utilisateur et active les bons agents spécialisés. Dans les cas simples, cela pourrait simplement être un bloc si/else. Dans les configurations plus avancées, il s'agit d'un LLM complet fonctionnant avec des prompts soigneusement conçus. Par exemple, vous pouvez avoir GPT-4 retourner un plan d'exécution structuré dans JSON: { "steps": [ {"agent": "Classifier", "input": {...}}, {"agent": "Memory", "input": {...}}, {"agent": "Responder", "input": {...}} ] } Vous pouvez même lui passer une liste d’agents disponibles et lui laisser choisir la meilleure voie à suivre. L’idée clé est la suivante : l’orchestre ne résout pas le problème, il construit la route, il décide qui doit faire quoi et dans quel ordre. Specialist Agents: Focused Experts (TOOLS) Réaliser une tâche simple et bien définie. Purpose: Ces agents ne sont pas là pour résoudre tout le problème - juste un morceau spécifique, et le faire bien. Classification d’une demande Générer une réponse Extraction des entités Appeler une API externe Traduction du texte Vous pourriez en arriver à des dizaines. Chacune est une fonction distincte, un module propre ou un sous-flow dans n8n. Et c'est exactement ce qui rend le système flexible et évolutif. Voulez-vous ajouter une nouvelle capacité? Créez simplement un nouveau spécialiste et enregistrez-le. L'orchestreur n'a pas besoin d'être réécrit - il a juste besoin de savoir que cet outil existe. Exemple d’un contrat entre l’orchestre et un spécialiste : { "agent": "Classifier", "input": { "text": "My order never arrived" }, "output_expected": { "label": "delivery_problem" } } Memory Agent: the Interface to the Past Créer un contexte pertinent. Purpose: Cet agent récupère les faits. C'est tout. Il interroge une base de données, un magasin vectoriel, un cache Redis - quoi que vous ayez - et renvoie exactement ce qui est nécessaire. Il ne prend pas de décisions, ne suppose pas, ne hallucine pas. Vous pouvez l'utiliser pour récupérer les commandes passées d'un utilisateur, correspondre aux embeddings vectoriels d'une base de connaissances ou saisir les interactions précédentes. Dans AAC, la mémoire est toujours sa propre chose. De cette façon, vous pouvez l'évoluer, le cacher ou même le brancher dans plusieurs systèmes. SELECT * FROM orders WHERE user_id = "user_42" ORDER BY created_at DESC LIMIT 3 Guard Agent: Protection from Chaos Détecter et gérer les échecs. Purpose: Si un spécialiste tombe en panne ou si l'orchestreur tombe en panne, le garde entre. Il enregistre l'erreur, envoie des alertes et exécute optionnellement la logique de recul - comme le retrait avec un autre agent ou le retour d'une réponse par défaut sécurisée. Dans la production, ce rôle n'est pas négociable. Des erreurs se produiront. Le GPT peut retourner à la poubelle. Les API peuvent être temporisés. Vous avez besoin d'une couche qui sait quoi faire lorsque les choses vont de côté. Exemple : GPT renvoie un JSON non valide. Le garde le capture, enregistre le problème, notifie Slack et envoie un message de rétroaction. { "error": "Invalid JSON from Summarizer", "fallback_response": "Sorry, I couldn’t process your request. Forwarding it to a human operator." } Observer Agent: the System’s Black Box enregistrer, analyser et vous donner la visibilité de ce qui s’est réellement passé. Purpose: Cet agent n'interfère pas - il ne fait que regarder.Voulez-vous suivre combien de temps chaque agent a pris pour répondre?Quelles données l'agent de mémoire a tirées?Combien de fois la Garde a dû déclencher un retard?Observer enregistre tout cela à n'importe quel outil que vous utilisez - Supabase, Amplitude, Segment, ou quelque chose de personnalisé. Vous espérez ne pas en avoir besoin, mais quand quelque chose se brise, c’est le seul moyen de comprendre ce qui s’est passé mal. Sans un observateur, vous volez aveugle. Avec cela, vous obtenez une image complète. Egress Agent: the Final Touch Envelopper le processus de manière propre. Purpose: Cet agent prend la sortie finale, la formate et la livre où il doit aller - à l'utilisateur, à une API, à un webhook, à Slack, quoi que ce soit. Une des erreurs les plus courantes est d’oublier cette étape.Sans un agent d’égress dédié, vous risquez d’envoyer des données cassées, des journaux bruts ou des réponses au mauvais endroit. { "status": "success", "reply": "We’ve reviewed your case. Thank you for reaching out!" } Chacun de ces agents est un bloc de construction. Vous pouvez les exécuter en parallèle, les remplacer indépendamment, les réutiliser à travers les chaînes. What’s Next? How to Start Using AAC in Your Projects Comment commencer à utiliser AAC dans vos projets Si vous lisez ceci, les chances sont que vous avez déjà fait face aux mêmes problèmes que moi. Votre projet ne cesse de croître. Les cas d'utilisation se multiplient. La logique se répand plus largement. Les agents deviennent « plus intelligents » - mais le système devient plus fragile. Qu'est-ce qu'un MVP net hier est maintenant devenu un désordre encombré. Voulez-vous ajouter une nouvelle branche? C'est un problème. Essayer de dégager pourquoi GPT a renvoyé quelque chose d'étrange? Aucune idée où cela s'est même produit. C'est le moment où vous commencez à demander - y a-t-il un autre moyen? Il y en a. Implémenter AAC signifie changer la façon dont vous pensez.C’est un passage de la magie à l’ingénierie. Et le point de départ n’est pas le code. Il regarde votre système différemment. Essayez d'imaginer votre logique comme une chaîne de spécialistes indépendants. L'un prend l'entrée. Un autre prépare les données. Un troisième décide de ce qu'il faut faire. Puis vient l'exécuteur. Après cela - la mémoire. Puis quelqu'un attrape les échecs. Enfin, quelqu'un enregistre ce qui s'est passé. C'est votre futur agent, style AAC. En ce moment, cependant, tous ces rôles sont soit implicites ou mêlés si mal que personne ne sait ce qu'est quoi. La première étape réelle est de rendre ces rôles explicites. Même mentalement. Décrivez-les. Donnez-leur des noms. Commencez à poser les bonnes questions: qui est responsable de l'orchestration ici? Où est la mémoire? Comment puis-je savoir si les choses ont réellement fonctionné? Que se passe-t-il si un bloc échoue? Une fois que vous le faites, la valeur de la modularité devient évidente. Lorsque tout est regroupé en un seul endroit, une erreur brise l'ensemble du système. Mais lorsque les choses sont structurées en tant qu'agents liés, les défaillances sont isolées - et le système continue de fonctionner. C'est pourquoi dans AAC, chaque agent est isolé, communique par le biais de contrats et n'a aucune conscience des autres. C'est comme les microservices à l'intérieur d'un pipeline. Seulement plus simple. Et plus rapide. Puis le plaisir commence. Vous réalisez soudainement que vous pouvez réutiliser des morceaux du système. Le même agent de classification qui gère un flux peut être utilisé dans un autre. Le bloc de mémoire peut être partagé sur plusieurs chaînes. Vous pouvez même rendre l'orchestrateur plus intelligent - laissez-le choisir quels agents déclencher. Ce n'est pas de la fantaisie. C'est la maturité de base que apporte l'AAC. Sur les plates-formes sans code comme n8n, cela devient une véritable superpuissance. Vous commencez à construire une bibliothèque d'agents. Chacun est un sous-flux avec un contrat défini. Voulez-vous construire un nouveau bot? Appelez simplement les agents dont vous avez besoin, dans l'ordre dont vous avez besoin. Voulez-vous remplacer un bloc? Faites-le sans crainte. Voulez-vous surveiller la performance ou suivre où les choses échouent le plus? Vous l'avez déjà - Observer enregistre tout, Guard capture chaque échec. Vous commencez à voir le système comme un ingénieur, pas quelqu'un qui a peur de toucher le code. Vous êtes en train de concevoir.Vous transformerez une chaîne d'appels GPT en architecture réelle - quelque chose qui vit, échelle, enregistre, évolue. Et si vous n'avez pas le temps de reconstruire tout maintenant - c'est bien. Commencez avec un flux. Un point d'entrée. Un moment honnête où vous dites: "Oui, laissez-moi essayer une nouvelle approche ici. Laissez-moi séparer les rôles. Ajouter un peu de contrôle." C’est le moment où vous commencez à construire avec AAC. Et les chances sont - vous ne voudrez pas revenir.
