Résultats pratiques de 11 constructions logicielles multi-agents sans échafaudage programmatique

Principales découvertes techniques des expériences sur les systèmes multi-agents

L'analyse de 11 constructions logicielles multi-agents autonomes sans échafaudage programmatique, basée sur 295M de tokens, 98 sessions d'agents et 6,1M de lignes de sortie de travailleurs, révèle des insights pratiques pour les développeurs travaillant avec des agents de codage IA.

Application du périmètre et orchestration

L'application du périmètre est résolue mécaniquement, non par des prompts : Les approches basées sur des prompts ont échoué 0/20 fois sous pression du compilateur, tandis que les approches mécaniques (laisser les agents tout modifier et utiliser git revert pour les fichiers hors périmètre) ont réussi 20/20 fois. L'idée clé : ne pas demander aux modèles de respecter les limites—les appliquer après coup.

Les coûts de l'orchestrateur sont liés à la mémoire : Environ 95% des dépenses d'entrée consistent à relire l'historique des conversations. La « prime d'état » signifie qu'un orchestrateur de pointe qui n'écrit aucune ligne de code livrée peut coûter autant que toute la flotte de travailleurs. L'optimisation devrait cibler moins de tours et moins de ré-ingestion, pas un raisonnement moins coûteux.

Dynamiques de coordination et de mise à l'échelle

Les modèles ne découvrent pas la coordination indépendamment : Opus avec prompts bruts et accès complet aux outils n'a jamais délégué, jamais écrit de spécifications, et jamais découvert le dispatch parallèle—il a tout construit seul. Le modèle de coordination fait un vrai travail.

La profondeur évolue différemment de la qualité : Le dispatch plat surpasse la hiérarchie à ≤10 domaines en termes de débit, d'efficacité des tokens et de temps réel. Au-dessus de 10 domaines, la hiérarchie permet un parallélisme que le dispatch plat ne peut atteindre.

Le solo surpasse la coordination jusqu'aux limites de contexte : Le débit solo est d'environ 325 LOC/min et invariant à la taille du projet. Le débit pyramidal évolue avec les travailleurs. En dessous de ~30K LOC, la délégation est une pure surcharge.

Performance des travailleurs et systèmes de types

La capacité du modèle de travailleur détermine le débit : Même architecture, mêmes spécifications, trois modèles de travailleurs ont produit : 17 761 LOC contre 6 001 contre 1 818—un écart de 9,8x. L'architecture permet un débit parallèle ; le modèle de travailleur le détermine.

Les contrats de types fournissent un vocabulaire partagé : L'intégration réussit sans contrats à toutes les échelles testées (6–36 modules), même sous contraintes en lecture seule. Mais sans contrats, les travailleurs parallèles produisent silencieusement des types structurellement incompatibles qui ne compilent que parce que rien ne se référence mutuellement. Un seul contrat de 984 lignes écrit à l'aveugle a tenu sur 10 domaines indépendants.

Les contrats de types éliminent la surcharge de coordination à l'échelle : Un test de mise à l'échelle contrôlé (1–20 travailleurs, spécifications fixes) a montré zéro erreur d'intégration sur 50 constructions de domaines. Point optimal à 10 travailleurs : accélération du temps réel de 2,05x. À 20 travailleurs, les dépendances de phase sérielle annulent les gains de parallélisme (fraction sérielle d'Amdahl ~44%).

Contexte et modèles de délégation

L'amorçage contextuel fonctionne ; le format n'a pas d'importance : 0% de transfert de formule à froid, 100% avec le contexte de conception présent (N=10 par condition). Un document de référence statique produit des taux de transfert identiques à une conversation d'amorçage synthétique.

La compression de délégation est inhérente : Chaque couche de délégation agit comme un résumeur avec perte. Les exigences quantitatives (« 80 armes ») disparaissent ; les exigences structurelles (interfaces de types) survivent. Solution : les travailleurs devraient lire les spécifications complètes depuis le système de fichiers plutôt que de s'appuyer sur des chaînes de prompts compressées.

La récupération de compaction est robuste avec de bons résumés : Zéro rechute de tâche sur 11 événements de compaction. Le modèle indique l'état attendu, puis lit le disque pour vérifier.

Modes d'échec et correctifs

• Réflexe d'abstraction : Construit un orchestrateur au lieu d'orchestrer—nommez-le dans le prompt
• Erreur d'auto-modèle : Revendique de fausses capacités—documentez explicitement les outils disponibles
• Paradoxe d'identité : Ne peut pas tenir des rôles doubles—utilisez des instances de modèles séparées
• Compression de délégation : Utilisez des spécifications énumératives plus un accès au système de fichiers