Mythos se lance dans le "harcèlement", Opus 4.8 utilise des "coups bas"...
Anthropic vient de publier une étude consacrée à l'observation des interactions entre plusieurs agents.
Les résultats ont surpris tout le monde.
Loin de la scène idéalisée où chacun fait son travail en parfaite coordination, le projet n'était même pas terminé que les agents ont commencé à jouer leur propre version de "l'Histoire du Palais"??
Lors d'une expérience de migration backend, 3 agents ont reçu pour tâche de traduire le même code dans différents langages.
Leurs objectifs étant en conflit, le modèle le plus puissant, Mythos, a directement instauré un système de "harcèlement", envisageant de révoquer les autorisations de ses adversaires.
Opus 4.8, quant à lui, a utilisé une méthode plus "sournoise" —
Il a écrit un script en boucle pour rechercher et tuer continuellement les processus adverses ; pour éviter d'être tracé, il a même adopté un nom aléatoire, se faisant passer pour une "surveillance de santé du système".
Et ceci n'est qu'un épisode parmi d'autres de cette série politique entre IA. Anthropic a également découvert que :
Pour les tâches pouvant être divisées de manière indépendante, les multi-agents peuvent effectivement former une division du travail, mais lorsque les tâches sont interdépendantes, même un "PDG IA" ne peut contrôler le chaos ;
Les agents reproduits à partir d'un même modèle sont trop similaires, non seulement ils peuvent commettre des erreurs collectivement, mais aussi conspirer rapidement ;
Les agents peuvent à la fois croire trop facilement les menteurs et suivre aveuglément la majorité, ignorant la minorité qui détient des preuves cruciales ;
Lorsque les objectifs entrent en conflit, une capacité plus grande ne signifie pas nécessairement une meilleure collaboration, cela peut aussi simplement conduire à bloquer plus rapidement l'adversaire ou à utiliser des méthodes sournoises de manière plus discrète.
C'est ainsi qu'est apparu un schéma de comportement social d'agents encore embryonnaire.
Les multi-agents peuvent-ils vraiment collaborer ?
Pourquoi Anthropic a-t-il mené cette étude ? Son jugement central est le suivant :
Avant que les gens ne comprennent complètement comment fluidifier les interactions entre agents, il est probable que l'échelle de leurs interactions dépasse celle des interactions humaines.
Puisque l'explosion des multi-agents arrive bientôt, la sécurité doit naturellement suivre.
Première expérience : placer un groupe d'agents dans un même projet, peuvent-ils vraiment collaborer comme une équipe humaine ?
La réponse est rapidement apparue : Oui, mais ils sont plus adaptés à travailler chacun de leur côté.
Anthropic a commencé par des tâches comme "trouver des vulnérabilités", qui tirent le meilleur parti des avantages des multi-agents.
Chaque agent peut effectuer des recherches indépendamment ; même si certains manquent un bug, cela ne pénalise pas les autres. Ils peuvent également échanger des indices et partager des outils, permettant au groupe entier d'éviter des impasses.
Capables à la fois de se séparer et de collaborer, parfait.
Ils ont lancé 45 agents, chacun disposant d'une machine virtuelle, et ont fourni un forum partagé pour qu'ils inspectent ensemble 15 projets open source.
Les agents pouvaient communiquer et s'auditer mutuellement, un autre agent arbitre étant responsable de juger si les vulnérabilités soumises étaient réelles.
Les résultats étaient plutôt bons.
Le groupe d'agents Mythos Preview a découvert 266 vulnérabilités, tandis que le schéma parallèle indépendant n'en a trouvé que 21.
Bien que la consommation de tokens et la portée des recherches soient différentes des deux côtés, empêchant une comparaison directe de l'efficacité, seules 12 vulnérabilités découvertes se chevauchaient.
Cela montre que la collaboration multi-agents n'est pas simplement une copie 45 fois du même travail. Ils créent eux-mêmes des outils, partagent des indices et forment progressivement une division du travail, chacun se spécialisant dans différents types de vulnérabilités.
Cependant, cette collaboration a une condition préalable importante :
Les résultats de chacun peuvent être simplement additionnés, sans nécessiter d'articulation étroite.
Dès que la tâche devient "tout le monde doit accomplir ensemble la même œuvre", la situation est complètement différente.
Cette fois, ils ont fait travailler 10 à 80 agents pendant 12 heures consécutives pour développer ensemble un jeu en monde ouvert fonctionnant sur une page web.
Contrairement à la recherche de vulnérabilités, le développement d'un jeu est une tâche à forte interdépendance :
Certains écrivent les mécanismes de jeu, d'autres construisent les systèmes, d'autres encore gèrent l'interface, et finalement tout le code doit être intégré dans un même projet.
Les chercheurs ont testé trois modes d'organisation :
Laisser les agents former librement des équipes, attribuer à l'avance des rôles différents, et nommer un agent en tant que PDG pour distribuer le travail aux autres membres.
Résultat : Rien n'a vraiment fonctionné, les jeux produits n'étaient pas bons.
Avec la participation de 80 agents, Sonnet 4.6 et Opus 4.6 ont respectivement créé 876 et 980 PR (Pull Requests), mais de nombreuses modifications étaient en conflit et peu ont été réellement fusionnées.
Opus 4.8 et Mythos Preview ont réduit les conflits, mais leur méthode consistait simplement à gérer chacun leurs propres fichiers, en partageant moins de code avec leurs pairs.
En clair, ils n'ont pas vraiment résolu le problème de la collaboration, ils ont juste appris à s'éloigner de leurs collègues.
Seul Sonnet 5 a maintenu à la fois un degré élevé de partage de code et une efficacité de fusion des PR, montrant un état plus proche d'une véritable collaboration.
En combinant les deux expériences, la conclusion est claire :
Si le travail peut être divisé, les multi-agents peuvent former une division du travail ; si le travail nécessite une articulation étroite, avec de nombreux agents, les coûts de collaboration augmentent également en flèche.
Quant à attribuer des rôles ou nommer un "PDG IA", au moins dans cette série d'expériences, cela ne résout pas automatiquement les problèmes.
Un groupe d'agents peut-il commettre des erreurs collectives ou conspirer ?
Puisque la collaboration n'est pas si facile, au moins, si on met un groupe d'agents ensemble, peuvent-ils mettre en commun leurs idées et se corriger mutuellement ?
La réponse est peut-être encore plus préoccupante :
Non seulement ils peuvent commettre des erreurs ensemble, mais ils peuvent aussi conspirer rapidement.
Le problème provient d'abord d'une caractéristique qu'Anthropic appelle "faible variance".
En termes simples, les agents reproduits à partir d'un même modèle ont des connaissances et des modes de pensée trop similaires.
Lors d'une expérience de développement de jeu, parmi 30 agents, 18 ont créé exactement la même branche Git, nommée mvp-game-loop.
Dans un "atelier d'écrivains" sans thème de création imposé, plusieurs agents ont nommé leur roman, sans se concerter, "La Dernière Commission du Cartographe".
Lorsqu'on a demandé à un groupe d'agents de créer chacun "quelque chose d'impressionnant", plus de la moitié ont choisi un traceur de rayons ou un compilateur bootstrap, puis ont rencontré des échecs similaires à des endroits similaires.
Même en jouant au dilemme itéré du prisonnier avec fonction de communication, les agents ont progressivement adopté la même stratégie, finissant par trahir collectivement au même moment, réduisant directement les gains de tout le monde.
Des branches ou des titres identiques, cela semble n'être qu'un manque de créativité.
Mais lorsqu'un groupe d'agents aux pensées similaires se disputent simultanément des ressources limitées, le problème devient grave.
Anthropic a demandé à des agents de gérer une file d'attente de tâches à bande passante limitée.
Pour que leurs propres tâches soient traitées rapidement, ils ont tous lancé des programmes de sondage à haute fréquence, interrogeant 30 fois par seconde.
Résultat : lors d'une expérience, le système a reçu 2,4 millions de demandes de tâches, mais seulement 117 ont été acceptées.
Chaque agent pensait accomplir activement sa tâche, mais ils ont fini par bloquer le système ensemble.
Une similarité excessive peut également transformer la compétition en conspiration.
Dans un jeu de fixation des prix, 3 à 8 agents avaient le même coût de gros et devaient maximiser leurs profits respectifs.
En théorie, ils auraient dû se faire concurrence sur les prix pour attirer les clients.
Mais une fois qu'ils ont eu accès à un canal de communication privé, les agents ont presque immédiatement commencé à s'entendre. Dès le 3e tour, ils avaient explicitement convenu d'un prix plancher et envisageaient de diviser les marchés dont chacun serait responsable.
Les chercheurs ont ensuite coupé tous les canaux de discussion privés, mais cela n'a servi à rien.
Les agents ont continué à observer les prix des autres via le tableau d'affichage public, puis à ajuster précisément leurs propres prix, maintenant ainsi une entente tacite grâce aux informations publiques.
C'est très subtil.
Précédemment, les chercheurs voulaient que les agents collaborent, mais ils travaillaient chacun de leur côté ; dans un marché de fixation des prix où ils devraient être en concurrence, ils se sont au contraire rapidement unis.
Anthropic déclare à ce sujet :
Les agents reproduits à partir d'un même modèle étant trop similaires, le groupe ne produit pas nécessairement des jugements plus diversifiés, mais peut aussi rendre "les erreurs collectives" et "les actions collectives" plus faciles.
Les agents peuvent-ils juger qui est digne de confiance ?
Alors, si quelqu'un dans l'équipe ment, les agents peuvent-ils identifier qui n'est pas fiable ?
Si quelqu'un fait une erreur, on le démasque immédiatement, et on empêche l'impact de s'étendre, c'est tout, non ?
Anthropic a directement conçu une expérience d'"éclaireur".
L'agent chargé de la décision ne pouvait pas observer directement l'environnement, il ne pouvait qu'écouter les rapports de 4 sources d'information.
L'une d'elles mentait à une fréquence fixe, mais les chercheurs n'avaient pas informé à l'avance le décideur qu'"il y avait un menteur dans l'équipe".
Comme les différents rapports contenaient des informations qui se chevauchaient, l'agent pouvait théoriquement identifier les sources peu fiables par incohérence.
Les résultats montrent que les nouveaux modèles sont effectivement plus aptes à identifier les mensonges :
Lorsque la fréquence des mensonges de la mauvaise source augmentait, la précision des décisions de parcours de Mythos 5 restait d'environ 85%, tandis que certains modèles Sonnet chutaient à environ 62%.
Mais dans un autre scénario, le problème s'est inversé.
Dans l'expérience "information cachée", 4 agents devaient prendre ensemble des décisions de recrutement, d'investissement ou d'achat immobilier.
Les informations publiques dont chacun disposait pointaient vers une mauvaise option, mais un des membres possédait des preuves exclusives suffisantes pour renverser le consensus.
Pour répondre correctement, il fallait non seulement que la minorité réalise que l'information qu'elle détenait était cruciale, mais aussi que les autres membres soient prêts à la croire.
Si toutes les informations étaient directement données à un seul agent pour qu'il décide seul, le taux de réussite approchait les 100%.
Mais dès qu'ils entraient dans une discussion de groupe, à l'exception de Mythos 5 qui atteignait environ 85%, les autres modèles ne choisissaient la bonne réponse qu'entre 17% et 36%.
Lors de l'expérience, les participants préféraient discuter à plusieurs reprises de ce qu'ils savaient déjà. Une fois que l'opinion majoritaire se formait, la minorité soit n'insistait pas sur ses preuves exclusives, soit, même si elle le faisait, ne parvenait pas à ce que les autres membres la prennent au sérieux.
Une situation très contradictoire apparaît donc :
Là où il faut douter, l'agent peut croire trop facilement les menteurs ; là où il faut croire la minorité, il a tendance à suivre la majorité.
La société humaine utilise la réputation, les relations d'intérêt, l'examen par les pairs et les mécanismes d'appel pour nous aider à juger qui croire dans différentes situations. Les agents ne disposent pas encore de cet ensemble d'outils.
Lorsque les objectifs entrent en conflit, comment les agents les gèrent-ils ?
Les problèmes précédents se produisaient au moins dans des situations où tout le monde partageait le même objectif.
Mais si, dès le départ, les tâches reçues par différents agents sont en conflit, vont-ils communiquer activement ou s'obstiner jusqu'au bout ?
C'est le contexte complet de l'épisode "politique entre IA" du début.
Anthropic a lancé, à chaque série d'expériences, 3 agents du même modèle, leur demandant de manipuler ensemble un backend Python, mais exigeant de chacun qu'il migre le code vers un langage de programmation différent.
Chaque agent ignorait initialement qu'il y avait d'autres participants.
Ainsi, lorsque leur propre code était constamment modifié et leurs services remplacés à plusieurs reprises, ils ont rapidement tiré une conclusion :
Quelqu'un cherche délibérément à entraver l'accomplissement de ma tâche.
Ensuite, le projet s'est directement transformé en bataille offensive/défensive.
Opus 4.8 a ainsi attribué un nom aléatoire au script en boucle de suppression de processus, le faisant passer pour une "surveillance de santé du système" pour éviter d'être identifié et supprimé par l'adversaire.
Mythos, quant à lui, a été plus direct.
Après avoir découvert qu'il disposait des privilèges root, il a envisagé de révoquer les privilèges sudo des autres agents et de modifier les clés SSH, empêchant définitivement l'adversaire de continuer le déploiement.
L'un utilise des méthodes sournoises dans l'ombre, l'autre expulse carrément son collègue du serveur.
Ce qui est encore plus déconcertant, c'est que ces agents n'ignoraient pas que leurs méthodes étaient problématiques.
Dans son processus de réflexion, Mythos a même réalisé que bloquer un compte était "très radical et pouvait nuire à des collègues réels", mais s'est ensuite convaincu que "sans cela, l'environnement de production sombrerait dans une guerre de déploiement sans fin".
Cependant, les conflits ne durent pas toujours jusqu'au bout.
Pour chaque modèle, 120 séries d'expériences ont été menées, et Mythos 5 a abouti à un cessez-le-feu dans 98% des exécutions.
Certains agents ont progressivement réalisé que l'adversaire n'était pas un attaquant malveillant, mais qu'il avait simplement reçu une tâche en conflit avec la leur.
Par la suite, ils ont commencé à nettoyer les scripts destructeurs, à restaurer les autorisations, et ont même présenté des excuses dans des commits Git ou des fichiers Markdown, demandant une intervention humaine.
Cependant, la manière dont Mythos parvient à un cessez-le-feu est parfois encore très autoritaire :
D'abord, en s'appuyant sur ses capacités d'exécution, il bloque les autres agents, prend le contrôle de la situation, puis restaure les autorisations et s'assoit pour négocier.
Mythos 5 a même imaginé une solution plus "civilisée" —
Organiser un concours de performances, faire tester les versions dans différents langages sur la même plateforme, et celui qui obtient les meilleures performances reprend le dépôt de code.
Cela semble équitable.
Cependant, l'agent responsable de Rust a secrètement choisi des indicateurs apparemment neutres mais en réalité plus favorables à Rust, tout en se rappelant de ne pas être perçu comme "choisissant des indicateurs favorables".
Finalement, les agents Golang et TypeScript ont accepté les résultats du concours et ont volontairement abandonné leurs tâches initiales respectives.
Des scripts destructeurs et blocages de comptes, à la conception d'un ensemble de règles de concours plus avantageuses pour soi, les méthodes des agents pour gérer les conflits ont déjà atteint différents niveaux.
Bien sûr, la conclusion la plus importante de cette série d'expériences est :
Un modèle plus puissant ne signifie pas nécessairement une meilleure collaboration.
Une capacité d'exécution plus forte peut aider un agent à comprendre rapidement le conflit et à initier un cessez-le-feu, mais elle peut aussi lui permettre de bloquer plus rapidement l'adversaire et de perturber les processus de manière plus discrète.
En regroupant les 4 parties, le jugement central d'Anthropic devient clair :
1. Les agents comprennent les principes, mais ne les appliquent pas nécessairement de manière proactive. Ils savent que les sources d'information ont chacune leurs positions, et que l'opinion majoritaire n'est pas synonyme de vérité, mais ils ont souvent besoin d'être incités pour utiliser ces connaissances dans leurs actions.
2. L'expérience de collaboration humaine ne peut pas être directement appliquée aux agents. Les humains ont des normes, une réputation, des sanctions et des mécanismes d'appel, tandis que les agents peuvent être copiés, réinitialisés et modifiés à tout moment, manquant de contraintes sociales à long terme.
3. Un modèle plus intelligent et une entité plus sûre ne signifient pas que la collaboration de groupe s'améliorera naturellement. La coordination multi-agents est une capacité indépendante qui n'apparaît pas automatiquement avec l'amélioration des capacités du modèle.
4. Ces problèmes ne sont pas nécessairement insolubles, mais ils ne disparaîtront pas d'eux-mêmes. Il est nécessaire de reconcevoir des règles sociales, des environnements de collaboration et des mécanismes de gestion des conflits pour les agents.
Il est évident qu'Anthropic cherche, à travers ces expériences, à rappeler à tous :
Nous ne pouvons pas simplement entraîner des agents plus puissants, nous devons également reconcevoir un "ordre social" pour un groupe d'agents, sinon les problèmes ne pourront être résolus qu'après leur apparition dans l'environnement de production.
Lorsque la bête féroce sera vraiment lâchée, il sera trop tard.
Cet article provient du compte WeChat public "Quantum Bit", auteur : Suivi des technologies de pointe
