Un modèle open-source gratuit fait tourner 300 agents parallèles en 4 000 étapes coordonnées à partir d’une seule instruction, et il obtient de meilleurs résultats sur des tâches de recherche réelles que des modèles que vous payez 5 fois plus cher.
La plupart des gens ne l’ont jamais ouvert.
Ils ouvrent Kimi, tapent une question, obtiennent une réponse, ferment l’onglet. C’est la boîte de dialogue. Ça marche. Mais ça ne représente qu’environ 10 % de ce que le produit peut faire.
Voici la partie que la plupart des gens sautent :
L’essaim ne fait pas qu’aller vite. Bien exécuté, il laisse toujours quelque chose derrière lui – une compétence réutilisable, un cahier des charges plus précis, une contrainte qui empêche la prochaine exécution de répéter l’erreur d’aujourd’hui.
L’essaim qui a exécuté votre tâche hier devrait être plus intelligent que celui qui l’exécute aujourd’hui.
https://x.com/Kimi_Moonshot/status/2047190578493096122
C’est la boucle. Kimi fait le travail et apprend. Opus 4.8 se tient à une porte – la porte de vérification – et son seul rôle est d’empêcher les déchets d’être sauvegardés comme compétence. Le moteur apprend. Le vérificateur le maintient honnête.
Certains choisissent un modèle et l’épousent. D’autres chassent la meilleure ligne de benchmark. D’autres encore câblent LangGraph et passent le week-end à déboguer un DAG.
Le résultat est généralement le même : un workflow qui fait exactement la même chose à l’exécution n°50 qu’à l’exécution n°1.
Ce n’est pas ça. Voici le manuel complet d’un essaim qui se bonifie. 10 étapes. Chaque instruction est copier-coller. Chaque nombre est vérifié.
Partie 1 – Construisez la boucle une fois. Exécutez-la pour toujours.
01. Rédigez un cahier des charges, pas une instruction
Quand la plupart des gens entendent « 300 agents », ils envoient une phrase – « étudiez le marché des applis fitness » – et s’attendent à des prodiges. C’est le moyen le plus rapide de brûler des crédits et d’obtenir des déchets.
Une instruction d’une ligne donne à l’essaim la permission de tout décider, et il décidera mal.
Traitez l’essaim comme un prestataire, pas comme un génie. Un cahier des charges définit quoi collecter, ce qui est valide, les sources autorisées, le format de sortie exact, et quoi faire en cas de conflit. Voici la partie que la plupart des gens sautent : Kimi décide lui-même de la décomposition.
Vous ne construisez pas les agents comme dans CrewAI, vous ne câblez pas le graphe comme LangGraph, vous ne définissez pas de structure comme AutoGen. Vous décrivez l’objectif – l’essaim construit l’organigramme.
Le cahier des charges est l’artefact au plus fort effet de levier dans toute la boucle, car à l’étape 4, il devient la graine de votre compétence réutilisable.
1# PROJET : [nom]2OBJECTIF : [une phrase — le livrable, pas le sujet]3PÉRIMÈTRE : [ce qui est inclus, ce qui est explicitement exclu]4RÈGLES : [validation — ce qui compte comme une ligne/un résultat vérifié(e)]5SOURCES : [publications officielles, articles, sources primaires uniquement — pas d'agrégateurs]6SORTIE : [type de fichier / nombre / nommage / détails de format]7EN CAS DE CONFLIT : signaler la ligne, ne jamais résoudre en silence8CONDITION D'ARRÊT : [quand s'arrêter et rapporter au lieu de deviner]
02. Lisez le plan de décomposition avant de dépenser le moindre centime
C’est l’étape que les débutants sautent, et c’est la plus coûteuse à sauter.
Après avoir soumis le cahier des charges, Kimi vous montre le plan d’exécution avant de l’exécuter – combien de sous-agents, ce que chacun gère, l’ordre des dépendances, le budget d’étapes.
Lisez-le. Un essaim de 200 agents mal décomposé coûte de l’argent réel et des heures réelles. Vérifier le plan ne coûte rien. Vous cherchez trois choses : a-t-il compris le périmètre, le nombre d’agents est-il raisonnable pour la taille de la tâche, et le plan de sortie correspond-il à ce dont vous avez réellement besoin.
Un détail à connaître : les 4 000 étapes sont un budget total coordonné pour l’essaim, pas 4 000 étapes par agent. Une exécution avec 300 agents représente en moyenne ~13 étapes chacun – des sous-tâches courtes et spécialisées. Cela vous indique si votre tâche correspond à la structure.
1Montrez-moi la décomposition proposée avant d'exécuter :2- combien de sous-agents, et ce que chacun gère3- l'ordre des dépendances (ce qui bloque quoi)4- le budget d'étapes estimé5- où se situe le plus grand risque de baisse de qualité6N'exécutez pas encore. Attendez ma confirmation.
Une instruction d’une ligne est un vœu. Un cahier des charges est un ordre. L’essaim exécute les ordres.
03. Laissez-le être gaspilleur – c’est le but
Maintenant, vous l’exécutez. Jusqu’à 300 sous-agents sont lancés en vagues parallèles. La première vague gère les sous-tâches totalement indépendantes.
Au fur et à mesure que les résultats arrivent, l’orchestrateur lance la vague suivante sur tout ce qui en dépendait, jusqu’à ce que le graphe de dépendances soit résolu.
Chaque sous-agent travaille dans sa propre fenêtre de contexte limitée. C’est l’astuce structurelle : un seul agent sur une longue tâche remplit sa fenêtre jusqu’à ce qu’il se noie et commence une synthèse avec perte, et chaque étape de raisonnement après cela empire.
L’essaim donne à chaque sous-tâche son propre contexte délimité, de sorte que seul un résultat structuré remonte au coordinateur. C’est pourquoi il ne s’effondre pas sur des tâches qui brisent un agent seul.
Comme Kimi coûte 0,95 $/M en entrée et 4,00 $/M en sortie – avec des hits de cache à 0,16 $ – vous pouvez vous permettre de jeter la première tentative et de recommencer. Un volume bon marché change ce que vous êtes prêt à essayer.
1Exécutez le cahier des charges de bout en bout.2Parallélisez partout où le plan le permet.3Rapportez la progression toutes les 30 étapes.4Signalez tout blocage immédiatement — ne le contournez pas en silence.5Si un sous-agent reste bloqué >10 min, réaffectez ou signalez.6Fusionnez le tout dans la SORTIE définie dans le cahier des charges.
04. Exigez de vrais fichiers, pas une réponse de chat
La sortie d’un essaim n’est pas du texte dans une fenêtre. Ce sont des livrables structurés qui vont directement dans votre travail – et c’est la partie que la plupart des articles oublient.
Une exécution produit des PDF, des feuilles de calcul, des jeux de données, des présentations et du code fonctionnel, le tout à partir d’un seul lancement, car Kimi émet ces formats nativement.
Donc, commencez toujours le cahier des charges par la sortie.
« Un rapport complet » donne aux agents la permission de s’arrêter tôt. « Un PDF de 40 pages + un CSV de 20 000 lignes + 14 graphiques PNG prêts à exporter » leur donne un objectif de qualité à atteindre.
La spécificité au niveau de la sortie fait toute la différence.
1SORTIE : [type de fichier] / [nombre] / [nommage] / [détail de format]23# exemples solides :4SORTIE : 1 .xlsx, une ligne par modèle, + résumé de 200 mots5SORTIE : 30 fichiers HTML, un par magasin, nommé par entreprise6SORTIE : PDF de 40 pages + CSV de 20 000 lignes + 14 graphiques PNG
05. Pointez le modèle honnête vers la sortie et demandez ce qui cloche
Voici le seul élément qui n’est pas Kimi. Le défaut connu de l’essaim : à moins que vous n’exigiez explicitement une vérification, il produit des affirmations confiantes et peu sourcées, et des sous-agents indépendants se contredisent parfois. « A l’air fini » et « est correct » sont deux planètes différentes.
Opus 4.8 est conçu exactement pour cette porte. Anthropic indique qu’il est environ 4 fois moins susceptible que 4.7 de laisser passer un défaut dans son propre code sans le mentionner, et c’est le premier Claude à obtenir un score de 0 % pour le rapport non critique de résultats erronés.
Son seul travail ici est de réfuter, pas de louer. Vous ne payez pas des jetons premium pour générer – vous les payez pour attraper le défaut silencieux avant que l’étape 4 ne l’enregistre comme compétence pour toujours.
Un volume bon marché n’est un super-pouvoir que lorsque quelqu’un de fiable vérifie le travail. Gardez la porte de vérification.
06. Enregistrez l’intégralité du workflow comme compétence
C’est l’élément qui rend la boucle auto-améliorante. Après une exécution que vous répéterez, dites à Kimi de capturer l’intégralité du workflow comme compétence réutilisable – format d’entrée, étapes des agents, format de sortie.
La première exécution prend 20 minutes. Chaque exécution suivante prend 30 secondes.
C’est la version honnête de « l’auto-apprentissage ». Le modèle ne réentraîne pas ses poids entre vos exécutions.
Le système autour devient plus intelligent – votre bibliothèque de compétences s’agrandit à chaque projet, et chaque futur essaim applique automatiquement ces compétences.
Un concurrent ne peut pas copier cette bibliothèque en une semaine. Elle est construite à partir de mois de vos vraies exécutions.
1Enregistrez ce workflow complet comme compétence réutilisable : « [nom] »2Capturez :3- le format d'entrée (quels fichiers / quelle forme de cahier des charges il attend)4- les étapes des agents qui ont fonctionné5- le format de sortie et la convention de nommage6- les règles de validation du cahier des charges7La prochaine fois que je l'exécute, je joins de nouveaux fichiers et j'obtiens la même forme.
07. Nourrissez vos propres documents comme connaissance de l’essaim
Les compétences capturent le processus. Le Document-vers-Compétence capture le domaine. Téléversez vos meilleurs travaux – une proposition conclue, un rapport soigné, une présentation – et Kimi capture leur empreinte structurelle et stylistique comme une compétence que tout futur essaim appliquera automatiquement.
C’est là que ça s’accumule : chaque PDF, transcription ou feuille de calcul que vous fournissez devient un contexte sur lequel les 300 agents parallèles peuvent s’appuyer, au lieu de se rabattre sur les données d’entraînement générales.
Plus vous en fournissez, plus chaque exécution ultérieure devient précise. Les rapports cessent de ressembler à une IA générique et commencent à ressembler à votre travail.
1Capturez ce document comme compétence réutilisable. Identifiez ce qui le rend efficace :2- la structure et l'ordre des sections3- le ton et le registre de voix4- la profondeur d'analyse par section5- le rythme d'écriture et les choix de mise en forme6Enregistrez-le sous « [nom] ». Produisez ensuite un nouveau document sur [sujet différent]7en utilisant la compétence capturée — correspondant à la barre de qualité, pas au contenu.
08. Transformez le retour de vérification en règle permanente
L’étape 5 attrape un défaut une fois. L’étape 8 garantit que l’essaim ne le commet plus jamais. Prenez la liste de correctifs d’Opus et ne vous contentez pas de corriger la sortie – intégrez la leçon dans un fichier de contraintes au niveau du projet que Kimi lit automatiquement au début de chaque session.
C’est ainsi que la boucle apprend de ses propres échecs. La dérive qu’Opus a signalée à l’exécution n°1 devient une règle stricte à l’exécution n°2.
Au bout de quelques projets, votre fichier de contraintes se transforme en documentation vivante qui s’applique elle-même – et la porte de vérification a de moins en moins à attraper à chaque fois.
1# CONTRAINTES.md — chargé automatiquement2- chaque chiffre avancé doit provenir d'une source primaire ou être signalé3- pas de résolution de conflit en silence — faites remonter les contradictions4- [règle distillée du retour d'Opus de la dernière exécution]5- [l'erreur que vous ne voulez jamais revoir]6Périmètre verrouillé : ne touchez à rien en dehors du bloc PÉRIMÈTRE du cahier des charges.
09. Rejouez la compétence sur de nouvelles entrées – regardez le coût s’effondrer
Maintenant, le résultat. L’exécution n°2 ne part pas de zéro. Elle part de la compétence, de la connaissance de l’essaim et du fichier de contraintes que vous avez construits aux étapes 6 à 8.
Même workflow, nouveaux fichiers, une fraction de la configuration.
C’est là que « l’accumulation » cesse d’être un mot à la mode et apparaît sur la facture. La première exécution de veille concurrentielle nécessite un cahier des charges complet et un passage de vérification.
La quatrième est une instruction de 30 secondes contre la compétence enregistrée, et la sortie est plus précise car elle hérite de chaque correctif des exécutions précédentes.
1Exécutez la compétence enregistrée « [nom] » sur ces nouvelles entrées.2Appliquez CONTRAINTES.md. Utilisez le format de sortie capturé.3[joindre les nouveaux fichiers]4Signalez uniquement les écarts par rapport à la forme attendue de la compétence.
20 minutes pour l’exécution n°1. 30 secondes pour la n°50. Cet écart est la raison même de construire une boucle plutôt qu’une instruction.
10. Promouvez la boucle en agent d’arrière-plan
Le geste final : une fois qu’une boucle est stable et adossée à une compétence, vous arrêtez de la lancer manuellement.
Pointez Kimi vers le déclencheur – un planning, un nouveau fichier déposé, la page de prix d’un concurrent – et laissez-le exécuter toute la boucle de manière proactive, en ne faisant remonter que le livrable et les écarts.
La veille concurrentielle est l’exemple le plus net.
L’exécution n°1, vous la construisez et la vérifiez à la main. Au moment où elle devient un agent d’arrière-plan, elle vérifie chaque concurrent en parallèle chaque semaine et dépose un briefing dans votre boîte de réception à coût temporel marginal nul.
Les seuls humains restant dans la boucle sont la question que vous avez posée et la décision que vous prenez sur la réponse.
1Exécutez la compétence « [nom] » selon un planning hebdomadaire.2Déclencheur : [planning / nouveau fichier / URL surveillée]3À chaque exécution : exécutez l'essaim, appliquez CONTRAINTES.md,4vérifiez, puis livrez la SORTIE + un diff par rapport à la dernière exécution.5Ne me contactez que si un écart dépasse [seuil].
Conclusion :
Alors que les laboratoires fermés continuent de livrer un chatbot plus intelligent à la fois, un modèle ouvert fait tourner 300 agents en parallèle – et devient plus intelligent au niveau système à chaque exécution que vous lui donnez.
Nous avons déjà vu cette empreinte exacte une fois. Une version ouverte redéfinit ce que la frontière fermée pensait posséder, et tout le domaine se recalibre du jour au lendemain. C’est arrivé avec DeepSeek.
Un essaim auto-apprenant sur un modèle à poids ouverts a la même forme.
Les bâtisseurs qui se disputent encore pour savoir quel modèle « a gagné » répondent à une question qui a cessé d’importer.
La question maintenant n’est pas quel modèle est le plus intelligent. C’est combien vous pouvez en faire tourner à la fois, qui vérifie leur travail, et si votre configuration est plus affûtée aujourd’hui qu’hier.
La plupart des gens liront ceci et continueront d’utiliser Kimi comme une boîte de dialogue. Quelques-uns construiront la boucle cette semaine. La première exécution prend 20 minutes. Chaque exécution suivante est un effet de levier que vous possédez.
Construisez-la. Vérifiez-la. Distillez-la. Puis regardez-la devenir moins chère et plus précise à chaque fois que vous l’exécutez.
