Aujourd'hui, j'ai lu un long article sur l'ingénierie de l'exploitation — des dizaines de milliers de mots, presque certainement écrit par une IA. Ma première réaction n'était pas "wow, quel concept puissant." C'était "ces gens ont-ils des idées au-delà de la création de nouveaux termes pour d'anciens ?" J'ai toujours été agacé par ce schéma dans le monde de l'IA — la réinvention constante de concepts existants. De l'ingénierie des invites à l'ingénierie du contexte, maintenant à l'ingénierie de l'exploitation. Tous les quelques mois, quelqu'un invente un nouveau terme, écrit un essai de 10 000 mots, saupoudre quelques études de cas de grandes entreprises, et toute la communauté commence à s'agiter. Mais si vous regardez réellement le contenu, c'est la même chose à chaque fois : Concevez l'environnement dans lequel votre modèle fonctionne — quelles informations il reçoit, quels outils il peut utiliser, comment les erreurs sont interceptées, comment la mémoire est gérée entre les sessions. Cela existe depuis le jour où ChatGPT a été lancé. Cela ne devient pas une nouvelle discipline juste parce que quelqu'un — pour une raison ou une autre — a décidé de lui donner un nouveau nom. Cela dit, à part les plaintes, la recherche et les études de cas citées dans l'article ont de la valeur — surtout puisqu'elles se chevauchent fortement avec ce que j'ai construit avec how-to-sglang. Alors, permettez-moi d'utiliser cela comme une occasion de parler des erreurs que j'ai réellement commises. Un peu de contexte d'abord. Les demandes les plus courantes dans la communauté SGLang sont des questions de type How-to — comment déployer DeepSeek-V3 sur 8 GPU, que faire lorsque la passerelle ne peut pas atteindre l'adresse du travailleur, si l'écart entre GLM-5 INT4 et FP8 officiel est significatif. Ces questions couvrent une surface technique extrêmement large, et à mesure que la communauté grandit de plus en plus vite, nous ne pouvons de plus en plus pas suivre les réponses. J'ai donc commencé à construire un système multi-agent pour y répondre automatiquement. La première idée était, bien sûr, la plus naïve — construire un Agent omniscient unique, y fourrer toute la documentation, le code et les livres de cuisine de SGLang, et le laisser répondre à tout. Cela n'a pas fonctionné. Vous n'avez pas besoin de théorie de l'ingénierie de l'exploitation pour expliquer pourquoi — la fenêtre de contexte n'est pas de la RAM. Plus vous y mettez de choses, plus l'attention du modèle se disperse et plus les réponses deviennent mauvaises. Un Agent essayant de comprendre simultanément la quantification, la désagrégation PD, le service de diffusion et la compatibilité matérielle finit par ne rien comprendre profondément. Le design sur lequel nous avons finalement atterri est une architecture d'expert en sous-domaine multi-couches. La documentation de SGLang a déjà des frontières fonctionnelles naturelles — fonctionnalités avancées, plateformes, modèles supportés — avec des livres de cuisine organisés par modèle. Nous avons transformé chaque sous-domaine en un agent expert indépendant, avec un Gestionnaire de Débat d'Experts responsable de la réception des questions, de leur décomposition en sous-questions, de la consultation de la Table de Routage des Experts pour activer les bons agents, de la résolution en parallèle, puis de la synthèse des réponses. En regardant en arrière, ce design correspond presque parfaitement aux schémas que la communauté de l'ingénierie de l'exploitation préconise. Mais quand je le construisais, je n'avais aucune idée que ces schémas avaient des noms. Et je n'en avais pas besoin. 1. Divulgation progressive — nous n'avons pas déversé toute la documentation dans un seul agent. Chaque expert de domaine charge uniquement ses propres connaissances de domaine, et le Gestionnaire décide qui activer en fonction du type de question. Mon instinct me dit que ce design a apporté bien plus d'amélioration que de remplacer par un modèle plus puissant. Vous n'avez pas besoin de savoir que cela s'appelle "divulgation progressive" pour prendre cette décision. Vous devez juste avoir essayé une fois l'approche "tout fourrer dedans" et l'avoir vue échouer. 2. Référentiel comme source de vérité — tout le flux de travail vit dans le dépôt how-to-sglang. Tous les agents experts tirent leurs connaissances de fichiers markdown à l'intérieur du dépôt, sans dépendance à des documents externes ou à des accords verbaux. Au début, nous avons eu l'envie d'écrire un énorme sglang-maintain.md couvrant tout. Nous avons rapidement appris que cela ne fonctionne pas. L'équipe Codex d'OpenAI a fait la même erreur — elle a essayé un AGENTS.md surdimensionné et l'a vu pourrir de manière prévisible. Vous n'avez pas besoin d'avoir lu leur blog pour marcher sur ce champ de mines vous-même. C'est le problème classique de l'ingénierie logicielle de "la documentation monolithique devient toujours obsolète", sauf que dans un contexte d'agent, les conséquences sont pires — la documentation obsolète ne devient pas seulement non lue, elle induit activement l'agent en erreur. 3. Routage structuré — la Table de Routage des Experts mappe explicitement les types de questions aux agents. Une question sur GLM-5 INT4 active à la fois l'Expert du Domaine des Livres de Cuisine et l'Expert du Domaine de la Quantification simultanément. Le Gestionnaire ne devine pas ; il suit un index structuré. La foule de l'ingénierie de l'exploitation appelle cela "contraintes mécanisées." Je l'appelle ingénierie normale. Je ne dis pas que les idées derrière l'ingénierie de l'exploitation sont mauvaises. La recherche citée est solide, le concept ACI de SWE-agent vaut vraiment la peine d'être connu, et l'architecture à double agent d'Anthropic (agent d'initialisation + agent de codage) est un matériel de référence précieux pour quiconque effectue des tâches à long terme. Ce que je trouve fatigant, c'est la constante invention de nouveaux termes — emballer le bon sens de l'ingénierie établi en tant que nouvelle discipline, puis fabriquer de l'anxiété autour de "vous êtes en retard si vous ne connaissez pas ce mot." L'ingénierie des invites, l'ingénierie du contexte, l'ingénierie de l'exploitation — ce sont différentes facettes de la même chose. Le mois prochain, quelqu'un inventera probablement l'ingénierie des échafaudages ou l'ingénierie de l'orchestration, écrira un autre long essai citant le même article de SWE-agent, et la communauté commencera un autre cycle d'amplification. Ce que j'ai réellement appris de how-to-sglang peut être énoncé sans aucun nouveau vocabulaire :...