Agent de Production sur Claude sans LangChain et RAG: Architecture en 712 Lignes pour un Studio de Design d'Intérieur

Un développeur indépendant a publié sur Habr une analyse détaillée de l'architecture d'un agent de production sur Claude, créé pour un petit studio de design d'intérieur. L'ensemble du système tient dans un seul fichier main.py avec 712 lignes de code et deux prompts système — pas de LangChain, pas de frameworks RAG et pas de bases de données vectorielles.

De quels composants se compose l'agent ?

Les rôles de deux modèles Claude sont clairement divisés par type de tâche. L'interface de chat s'exécute sur Claude Haiku 4.5 : le modèle répond rapidement aux questions des clients, clarifie les demandes et maintient le dialogue. Claude Sonnet 4.6 gère la génération de concepts de design : il transforme les souhaits du client en une description structurée de l'intérieur. Les photos pour visualiser les concepts proviennent de la bibliothèque Pexels — c'est significativement moins cher et plus rapide que de générer des images via DALL-E.

Paramètres clés de la solution :

• Claude Haiku 4.5 — dialogue avec le client : rapide et économique
• Claude Sonnet 4.6 — génération de concepts de design structurés
• Pexels API — sélection de photos au lieu de DALL-E
• Un fichier main.py, 712 lignes de code, deux prompts système
• Pas d'orchestrateurs, pas de bases de données vectorielles, pas de frameworks par-dessus l'API

Ce choix architectural n'est pas fortuit. Pour un studio avec un budget limité et un petit flux de clients, une pile RAG complète est de l'over-engineering. Haiku est moins cher pour le dialogue ; Sonnet n'intervient que là où une génération créative structurée est nécessaire. Il n'y a aucune raison de résoudre un problème de scalabilité qui n'existe pas encore.

Quels pièges ont été rencontrés ?

Le premier point non évident est le seuil de mise en cache des prompts pour Claude Haiku 4.5. La mise en cache du contexte ne s'active que à partir de 4096 tokens. Si le prompt système est plus court que ce seuil, chaque requête est traitée comme nouvelle — la mise en cache ne fonctionne pas du tout. Sous charge élevée, cela impacte notablement à la fois le coût des requêtes et la latence de réponse.

La deuxième subtilité est le comportement de Sonnet 4.6 avec la sortie structurée. Le modèle enveloppe parfois la réponse JSON dans un bloc de texte supplémentaire au lieu de retourner du JSON pur. Le `json.loads()` standard échoue avec une erreur dans ces cas. L'auteur a essayé plusieurs stratégies d'analyse et a opté pour un wrapper simple avec logique de secours — c'est plus fiable qu'extraire JSON avec des expressions régulières.

« Ce n'est pas un guide d'un expert — plutôt un journal des décisions.

J'ai essayé d'expliquer honnêtement pourquoi j'ai pris chaque décision », explique le développeur.

La logique de division des modèles mérite une attention particulière. L'auteur a essayé de traiter tout avec un seul modèle, mais a vite compris : Haiku doit être utilisé là où la vitesse et le coût importent, et Sonnet là où vous avez besoin de qualité de sortie structurée. Tenter d'économiser en exécutant la génération de concepts via Haiku a produit des résultats notablement plus mauvais.

Où cette approche commencera-t-elle à échouer ?

Le développeur délimite honnêtement les limites de sa solution. Un fichier de 712 lignes fonctionne bien pour un MVP et un petit studio, mais la scalabilité créera des problèmes :

• À mesure que la base de clients croît, le stockage de l'historique des dialogues devient nécessaire — sans base de données vectorielle ou stockage externe, c'est inévitable
• Si le studio veut accepter et analyser des photos de clients, un pipeline multimodal sera nécessaire
• Enregistrer l'activité de l'agent dans un fichier ne fonctionne pas avec plusieurs utilisateurs simultanés et une charge réelle
• À mesure que les prompts deviennent plus complexes, il est plus difficile de les tester et de les versioner dans un seul fichier

La principale conclusion de l'auteur : pour une tâche aux limites étroites et claires, « sans RAG » n'est pas une solution paresseuse mais un choix architectural délibéré. Les frameworks résolvent des problèmes réels de scalabilité mais en créent de nouveaux : complexité, dépendances, surcharge d'infrastructure. Si le problème n'a pas encore émergé, ne le créez pas pour l'amour d'un outil.

Qu'est-ce que cela signifie

La publication montre : l'API Claude est suffisante pour un agent de production sans frameworks de support, si la tâche est suffisamment spécifique. Pour les développeurs qui commencent à construire des agents sur Claude, ceci est une analyse honnête des pièges réels — le seuil de cache pour Haiku 4.5, l'analyse JSON pour Sonnet 4.6, la distribution réfléchie des tâches entre modèles de différents niveaux.