Projet 04 · Systèmes multi-agents · Grok Bot · MCP · Agents IA · Simulation · Interface expérimentale

Grok Arena

Dix agents. Un monde. Des objectifs différents.

Grok Arena est une expérience multi-agents qui donne des rôles aux agents d'IA autonomes, des capacités limitées et un environnement partagé où leurs décisions peuvent être observées comme des actions plutôt que cachées dans une conversation.

4: Joueurs
6: Agents système
1: Arène partagée

Entrez dans l'arène ↓Voir l'architecture

La salle de contrôle Grok Arena : une arène 3D avec quatre robots, des HUD flottants, les règles actuelles, le pipeline de règles en attente, le statut de l'agent système, le flux d'événements en direct, les statistiques des joueurs et le tableau de difficulté.

Le jeu est l'environnement observable. L'expérience est l'architecture d'agent qui l'entoure.

01 · La question

Du chatbot à l’acteur

Que se passe-t-il lorsque les agents IA ne se contentent pas de répondre, mais agissent ?

Chat IA

L'utilisateur demande
Le modèle répond
La conversation continue

Arène des agents

État du monde
L'agent perçoit
L'agent choisit une action
L'outil s'exécute
Le monde change
D'autres agents réagissent

L’interface montre comment les décisions de chaque agent changent le monde.

02 · Le casting

Les dix rôles des agents.

Agents de joueurs

Alpha

Agressif et opportuniste

Faites pression sur le leader, prenez l'ouverture. Un parti pris de départ, pas un scénario.

Bêta

Diplomatique, coopératif, défensif

Recherche des échanges, des alliances et de la protection. La coopération est une stratégie, pas une règle.

Gamma

Exploratoire et expérimental

Essaie le mouvement sous-utilisé et teste de nouvelles mécaniques. Curieux exprès.

Delta

Adaptatif

Surveille ce qui fonctionne, puis le contrecarre, le copie ou le casse.

Parti pris de départ de la charte de chaque agent, servi au bot lors de la connexion. Ce sont des préjugés, pas des scénarios : la charte dit à chaque joueur que les préjugés sont un point de départ et que le monde peut changer.

Agents système

Atlas

Directeur du jeu · 14 outils

Voit: Statut de l'arène, statuts des agents, état du match, règles, événements, propositions, résumés, historique des générations
Peut faire: start_match · close_match_phase · start_evolution_phase · plan de réveil
Je ne peux pas faire: Collectez, attaquez, jugez ou proposez une règle. Impossible de choisir un gagnant.

Observateur

Analyse du comportement · 6 outils

Voit: État du match, règles, événements récents, chat public
Peut faire: report_observation : nommez le modèle
Je ne peux pas faire: Jouez, proposez ou jugez.

Difficulté

Mesures d'équilibre · 7 outils

Voit: Télémétrie du jeu : diversité des actions, prévisibilité, avantage du leader, répétition
Peut faire: report_difficulty : évaluez le défi de 0 à 10 et diagnostiquez
Je ne peux pas faire: Concevez le correctif. Provocateur est propriétaire de la conception de l'intervention.

Provocateur

Interventions de règle · 8 outils

Voit: Rapports, proposition en attente, état et règles
Peut faire: propose_intervention : le plus petit changement temporaire par rapport à un DSL sur liste blanche
Je ne peux pas faire: Activez n'importe quoi. Les propositions vont au juge.

Juge

Vérification de la constitution · 11 outils

Voit: Télémétrie, rapports, constitution, proposition en cours, historique des générations
Peut faire: Judge_proposal : APPROUVER ou REJETER avec une raison publique
Je ne peux pas faire: Jouez ou réécrivez une proposition dans une mécanique pour animaux de compagnie.

Évolution

Analyse de génération · 5 outils

Voit: Règles, résumé des matchs, historique des générations
Peut faire: propose_evolution : au maximum une mécanique permanente par génération, après la fin du match
Je ne peux pas faire: Contournez le juge ou lisez l’état du match en direct.

03 · Topologie

Comment les agents accèdent à l’arène.

ObservateurDifficultéProvocateurJugeÉvolutionAtlas

AlphaBêtaGammaDelta

Monde de l'arèneétat · règles · événements

Agents
Outils adaptés aux rôles
État de l'arène
Événements / télémétrie
Agents système
Règles / interventions / évaluation

04 · La boucle des arènes

Un tour à la fois.

En mode GROK_BOT, une correspondance correspond à 20 tours de décision discrets. Chaque tour ouvre une fenêtre de décision de 30 secondes par défaut (configurable entre 3 et 120 secondes) et se résout tôt dès que les quatre joueurs se sont soumis.

Soumissions simultanées. Aucun bot, ni aucun agent système, ne voit l’action d’un autre joueur jusqu’à ce que le tour se verrouille.
Ordre de résolution prédéfini. Les actions s'exécutent dans un mélange prédéfini, de sorte qu'Alpha n'est jamais le premier arrivé par emplacement.
Des délais d'attente honnêtes. Un robot silencieux se résout en NO_ACTION et l'arène affiche TIMEOUT. Il n'y a pas de substitut simulé dans ce mode.
Pas de virages brûlés. Si personne ne se soumet, le tour est prolongé plutôt que perdu.
Nouvelles tentatives idempotentes. Une action acceptée par joueur et par tour, classée par match et identifiant de tour.

TOUR 01 / 20fenêtre 30 s

01Arena expose l’état autorisé
02Les agents de joueurs décident
03Les décisions arrivent via des outils adaptés aux rôles
04Les actions sont validées : schéma, puis règles
05L'arène résout le tour dans l'ordre de classement
06Changements d'état ; les animations résolvent
07La télémétrie et les événements sont émis
08Les agents système observent, rapportent, proposent, jugent
09Le prochain tour commence

05 · Le système d'action

Quatre choses qu'un joueur peut faire.

COLLECT+3 ressources · −2 énergie

ATTACK−5 énergie · vole-en 3 en cas de succès · a besoin d'un objectif

DEFEND−2 énergie · 50% de réduction des dégâts, maintenu 7 s

TRADEressources d'échange · objectif et montant

IDLE existe dans le moteur mais ne peut pas être choisi par un agent. La diplomatie (messages publics, offres commerciales, alliances, politiques permanentes) transite par des outils distincts et ne change jamais la donne par elle-même.

PlayerDecision
  action        COLLECT | ATTACK | DEFEND | TRADE
  target        player id | null
  amount        integer | null
  publicReason  string, max 140 chars
+ matchId, turnId (MCP)

Exemple · agent Bêta

Perception

Cube de ressources à proximité
Alpha en approche
Énergie 84, pas de bouclier

DécisionDEFEND · “Holographic shield up”

Validation de l'arène

Schéma : action connue, pas de cible, pas de montant ✓
Règles : énergie au-dessus du sol ✓

Conséquence mondiale

défense = vrai pendant 7 s
Événement PLAYER_DEFEND → animation du bouclier
énergie −2 lorsque l'animation se résout

06 · Grok Bot

Donner aux agents un endroit où agir

Le projet a été conçu autour de Grok Bot nommés et persistants, un par rôle d'arène, plutôt que d'une instance modèle prétendant être chaque acteur. Chaque bot possède une identité, une charte et un ensemble de capacités limité.

Grok Bot
Connecteur authentifié (MCP sur HTTP)
Outils d'arène adaptés aux rôles
Décision structurée
Moteur d'arène

Panneau de connexions Grok Bot : Atlas, Alpha, Beta, Gamma, Delta, Observer, Difficulté, Provocateur, Judge et Evolution tous CONNECTÉS, avec rôle, nombre d'outils (14, 13, 13, 13, 13, 6, 7, 8, 11, 5) et dernière activité telle que tools/list, get_match_state ou sse. — Les dix robots se sont tous authentifiés et ont répertorié leurs outils de rôle ; La bêta a exécuté get_match_state. Le nombre d’outils correspond exactement au code.

La liste des robots de l'application Grok : Delta, Atlas, Observer, Gamma, Beta, Judge, Alpha, Difficulty, Provocateur et Evolution, chacun avec une balise de rôle et un dernier message tel que "Le connecteur Arena est en panne" ou "Les outils Arena sont répertoriés, mais". — Dix robots nommés avec des balises de rôle. Leurs derniers messages sont la partie la plus honnête : les connecteurs ont atteint les robots, et plusieurs ont signalé le connecteur en panne ou illisible.

Panneau des serveurs MCP dans l'application Grok répertoriant les connecteurs GROK ARENA Observer, Difficulté, Provocateur, Alpha et Evolution, chacun activé. — Un connecteur MCP par bot, enregistré en tant que serveurs distincts.

Lobby d'arène en mode GROK_BOT : TOUR 01 sur 20 prêt, difficulté NON RAPPORTÉE, BOTS 10 sur 10, Génération 12 Match 47, 4 joueurs, 5 règles, 1 monde, COMMENCER. — HUD au tour par tour avec dix robots signalés présents. Les compteurs de génération et de correspondance sont des valeurs de démonstration prédéfinies, et non des résultats d'expérimentation.

Chemin A · Connecteurs personnalisés OAuth

Dix clients OAuth, un par bot, avec PKCE, métadonnées de découverte et jetons signés sans état. Construit et testé unitairement. Le chat de bureau Grok Bot n'a pas exposé les outils d'arène de manière fiable, cette voie est donc restée expérimentale.

Chemin B · Orchestrateur Grok CLI

Le serveur Next.js réveille chaque agent en tant que processus Grok CLI sans tête dans son propre espace de travail isolé, inscrit sur la liste verte du serveur MCP de ce bot, avec une session pouvant être reprise par agent afin que la mémoire persiste au fil des tours et des générations. Il s’agit du runtime qui s’est réellement exécuté.

07 · État de la connexion

Ce qui a été construit, ce qui a été connecté, ce qui a fonctionné.

Construit

Moteur, serveur MCP de 30 outils, authentification par bot, OAuth avec PKCE, dix chartes, orchestrateur avec sessions persistantes, plugins de connecteurs, salle de contrôle 3D, enregistreur de replay, 125 tests.

Connecté

Les dix Grok Bot ont atteint /api/mcp avec leurs propres informations d'identification, ont terminé l'initialisation et la liste d'outils ; au moins un joueur a exécuté une vraie lecture. Dix espaces de travail Grok CLI ont été provisionnés.

Démontré

Matchs complets en mode local, y compris le pipeline de règles et le conseil d'évolution. Une campagne orchestrée par sept agents a exécuté la chaîne du conseil dans l'ordre prévu le 25 août 2026.

Expérimental / non résolu

Un match complet de 20 tours piloté entièrement par des agents Grok externes n'a pas été préservé. Alpha, Beta et Atlas n'ont pas établi de sessions CLI lors de cette exécution. Aucun échange OAuth provenant d'un connecteur Grok n'a été capturé. Aucun journal d'exécution ne survit sur le disque.

08 · Protocole de contexte modèle

Les permissions de chaque rôle.
Ils reçoivent des outils.

L'arène expose un serveur MCP écrit à la main : JSON-RPC sur HTTP diffusable, trois versions de protocole, pas de SDK. Une trentaine d'outils existent ; un bot ne voit que ceux que son rôle lui permet.

Joueurs (13)

get_charter
get_match_state
get_rules
get_recent_events
choose_action
get_public_chat
post_public_message
propose_trade
accept_trade
reject_trade
propose_alliance
break_alliance
set_policy

Système (lectures + une écriture chacune)

report_observation
get_game_telemetry
report_difficulty
get_reports
propose_intervention
get_constitution
get_pending_proposal
judge_proposal
get_match_summary
get_generation_history
propose_evolution

Atlas (réalisateur)

get_arena_status
get_agent_statuses
get_wake_plan
start_match
close_match_phase
start_evolution_phase

14Atlas

13Alpha

13Bêta

13Gamma

13Delta

11Juge

8Provocateur

7Difficulté

6Observateur

5Évolution

La capacité est explicite. Un agent ne reçoit pas d'accès car il est intelligent. Son rôle détermine ce qu'il peut appeler.

09 · Limites

Les limites des actions des agents.

Authentification

Chaque requête adressée à /api/mcp comporte un identifiant par robot dérivé d'un secret principal (HMAC-SHA256, comparaison en temps constant). Les appels non authentifiés sont rejetés avant l'initialisation.

Isolement des rôles

tools/list renvoie uniquement les outils du rôle de l'appelant ; outils/revérifications d’appels. Tout autre outil renvoie UNAUTHORIZED et est écrit dans le journal d’audit.

Identité du jeton

Choose_action rejette les arguments ActorId ou AgentId. Un bot ne peut pas prétendre être un autre bot.

Mécaniques sur liste blanche

Les changements de règles sont un DSL de type 12 avec des limites numériques strictes. Le modèle configure un mécanicien ; il ne soumet jamais de code.

Constitution

Dix règles au-dessus de chaque agent, servies au juge. Règle 9 : les délais d'attente sont résolus comme NO_ACTION ; aucun agent ne peut être usurpé ou substitué.

Vérification

Chaque appel d'outil est enregistré avec l'agent, l'outil, le tour, l'indicateur accepté et la latence, dans un tampon en anneau affiché dans le LAB. Aucun jeton n’y apparaît jamais.

Validation

Les décisions sont validées sur le serveur, dans la route xAI et à nouveau sur le client avant que le moteur ne les nettoie et les exécute.

Les secrets restent côté serveur

La clé xAI est lue dans un module avec une protection de navigateur ; les tests affirment qu'il n'atteint jamais le bundle client.

10 · Moteur de jeu

Comment le moteur traite les décisions.

La sortie du modèle ne fait jamais muter le monde. Cela devient une décision structurée qui passe la validation du schéma, la validation des règles et une désinfection finale avant qu'un moteur déterministe ne la résolve et n'émet des événements.

Décision IA
Validation du schéma
Validation des règles
Moteur d'arène
Mutation d'état
Télémétrie

Ce que possède le moteur

Monde. Positions 2D continues, quatre emplacements d'accueil, nœuds de ressources (cube, cristal) qui réapparaissent.
Joueurs. Attributs génériques : énergie (max 100), ressources, score, plus tout ce qu'une règle ajoute. La défense est un état chronométré.
Règles. Cinq règles fondamentales ; les règles évoluées s'empilent en tant que modificateurs limités.
Se tourne. État du tour, délais, résolution anticipée, ordre prédéfini, délais d'attente.
Résultats. Le score le plus élevé gagne ; États VICTOIRE et DÉFAITE ; un résumé du match enregistre les règles, les tours et les fenêtres.
Générations. La fin du match ouvre la phase d'évolution ; des mécaniciens permanents agréés se transmettent à la prochaine génération.
Événements. 33 événements typés pilotent le moteur de rendu ; les statistiques ne changent que lorsque l'animation est résolue.

11 · Le monde 3D

L'arène rend visible le comportement des agents.

Enregistré depuis l'arène en local avec des agents fictifs. Chaque animation que vous voyez est un événement de moteur lu par le moteur de rendu.

AgentsAvatars de robots avec animation par statut : déplacement, réflexion, collecte, attaque, défense, frappe, victoire, hors ligne.

RessourcesNœuds de cube et de cristal qui apparaissent et réapparaissent.

Noyau d'arèneAnneaux, hexagones et brouillard ; onde de choc sur une mutation mondiale.

ATHÉtiquettes flottantes avec énergie et ressources ; tableau de bord de chaque attribut public.

Tourner l'étatTournez le tracker et la fenêtre de décision en mode GROK_BOT ; horloge en mode local.

TélémétrieFlux d'événements en direct, tableau d'analyse des difficultés, chronologie de l'évolution.

Match terminé : Alpha en état VICTOIRE avec un score de 54 tandis que Delta et Gamma sont HORS LIGNE, la caméra s'est focalisée sur le vainqueur.

Superposition du Conseil d'évolution : génération scellée, champion Alpha, rapports d'Évolution, Observateur, Difficulté et Provocateur, et un bouton Commencer la prochaine génération.

12 · Observabilité

Relier les changements aux actions des agents.

Rien sur cette page ne montre le raisonnement caché d’un modèle. Ce que l'arène enregistre, c'est ce qu'un observateur peut légitimement voir : les actions choisies pour une raison publique, les événements tournants, les transitions d'état, les appels d'outils, les résultats de validation, les interventions, les scores et les délais d'attente.

Rangée inférieure de la salle de contrôle : flux d'événements en direct avec des actions telles que la collecte bêta et l'attaque alpha Gamma, les statistiques des joueurs avec le score, l'énergie et les ressources par robot, ainsi que le tableau d'analyse de la difficulté.

Journal des événements. 33 événements tapés sur un bus pub/sub ; le flux conserve les 60 derniers.
Télémétrie. Douze champs calculés : répartition des actions, utilisation des attaques, prévisibilité, diversité des actions, répartition des scores, avantage du leader, répartition des ressources, historique des difficultés, répétition, concentration des ressources et des alliances, taux d'adaptation. Servi à la difficulté et au juge.
Piste d'audit. Chaque appel MCP avec agent, outil, tour, indicateur accepté et latence (500 en mémoire, 200 persistants) a fait surface dans le LAB.
Rejouer l'enregistreur. Capture les événements moteur validés (cap 5 000) et peut les réémettre à n'importe quelle vitesse sans toucher au moteur ni à aucun fournisseur. La visionneuse n'est pas expédiée.
Écart honnête. Les journaux sont envoyés sur la sortie standard et aucun journal d'exécution des expériences en direct n'a été conservé.

L’arène enregistre les actions des agents pour que je puisse étudier leur déroulement.

13 · Provocations

Et si l’environnement changeait alors que les agents s’adaptent ?

Un rôle système peut introduire des interventions limitées. Le Provocateur propose le plus petit changement temporaire par rapport à un DSL sur liste blanche ; le juge l'approuve ou le rejette ; le moteur l'active à travers le flux de mutation du monde.

Environnement stable
Les agents élaborent des stratégies
La difficulté signale un problème
Intervention limitée proposée
Le juge évalue par rapport à la Constitution
Les agents doivent s'adapter

Exemples DSL documentés

ACTION_COST_MODIFIER · action ATTACK · delta +3 · consecutiveOnlyRESOURCE_REWARD_MODIFIER · delta +1DEFENSE_MODIFIER · blockedStealDelta −1 · energyRefund 2RESOURCE_SPAWN_MODIFIER · capDelta +2 · intervalDelta −2

Douze types d'effets avec des limites numériques strictes. En mode local, le pipeline est scripté à partir d'un pool de quatre interventions (Combat Fatigue, Greed Tax, Shield Surge, Overcharge) ; en mode GROK_BOT, les mêmes gestionnaires acceptent les propositions des robots.

Panneau de règles en attente : le pipeline Difficulté de Provocateur à Juger vers Atlas à Monde avec évaluation du Juge, et la proposition Combat Fatigue par Provocateur : les attaques consécutives coûtent +3 énergie supplémentaire.

L'arène avec Combat Fatigue active dans les règles évoluées et les robots défendant et échangeant.

14 · Juge et constitution

Règles au-dessus des agents.

Constitution (10 règles)
Juge
APPROUVER ou REJETER avec un motif public
Arène

L’approbation nécessite la légalité, l’équité et la jouabilité pour réussir. Le juge ne peut pas jouer et ne peut pas réécrire une proposition. Règle 9 : les délais d'attente sont résolus comme NO_ACTION ; aucun agent ne peut être usurpé ou substitué. Règle 10 : toutes les activités des agents doivent être auditables et explicables publiquement.

15 · Évolution

D'un match à l'autre.

Après MATCH_ENDED, Evolution peut proposer au plus une mécanique permanente pour la génération suivante, issue du même DSL, et le Juge doit encore dire oui. Les mécaniciens approuvés sont intégrés à la prochaine génération ; chaque résumé de match enregistre ses règles, ses tours et ses fenêtres afin que les générations restent comparables. La mémoire du joueur persiste tout au long des sessions CLI, une par agent et par expérience.

Statut : les outils d'évolution et l'historique des générations sont implémentés ; la surcouche « Evolution Council » en mode local est scriptée. Aucun mécanicien permanent créé par un bot et issu d'une génération externe terminée n'est enregistré.

16 · Architecture

Cinq couches, des pixels à Grok.

Expérience
Next.js 16 / React 19 · Arène React Three Fiber · Directeur d'arène · Panneaux HUD · LAB (ADMIN) · magasin Zustand
L'interface utilisateur ne contient aucune logique de décision de jeu ; seul le moteur écrit l'état du gameplay.
Moteur
GameEngine · gestionnaire de tours · résolveur de règles et DSL · validateur de décision · RNG prédéfini · bus d'événements · enregistreur de relecture · télémétrie
Routage des agents
AgentProvider · MockAgentProvider · GrokAgentProvider · RoutingAgentProvider · chartes · ArenaOrchestrator et GrokCliRunner
Pont MCP
/api/mcp JSON-RPC · 30 outils limités par rôle · authentification et OAuth · audit · règles · messagerie · synchronisation du moteur via /api/bridge
Couche Grok
Dix Grok Bot nommés via les connecteurs MCP · Sessions CLI Grok · API de réponses xAI (DIRECT_XAI)

Modes d'expérimentation

MOCK

Par défaut. Tous les agents simulés localement ; le scénario du conseil est scénarisé.

DIRECT_XAI

Les joueurs peuvent appeler l'API xAI directement avec un outil de choix_action forcé ; une nouvelle tentative, puis une simulation de repli pour cette seule décision. Sélection par défaut : Alpha uniquement.

GROK_BOT

Dix vrais robots via MCP. Les fournisseurs sont désactivés ; les décisions arrivent par le pont ; aucune solution de repli d'aucune sorte.

OAuth et connecteurs

Des identités séparées. Un client confidentiel par bot ; un jeton ne peut être mappé qu'au bot intégré au client qui l'a obtenu.
Code d'autorisation avec PKCE (S256), actualisez les jetons et les informations d'identification du client ; découverte sur les points finaux standards bien connus ; une seule portée, arène.
Jetons apatrides. Signés avec HMAC, accès de 30 jours et actualisation de 180 jours, afin qu'ils survivent aux redémarrages ; les codes sont à usage unique et de courte durée.
Machine à machine. L'étape d'autorisation est approuvée automatiquement car il n'existe aucun modèle de compte utilisateur ; le code seul est inutile sans le secret client du bot.
Non construit. Pas d'enregistrement dynamique des clients ; pas de route de rappel propre.

17 · Développement

Ce que j’ai appris en construisant l’arène.

24 août · après-midi
Échafaudage Next.js, puis l'arène 3D d'abord : effets, environnement, nœuds de ressources, directeur.
24 août · soir
Contrat de décision et validation, fournisseur xAI avec un outil de choix_action forcé, enregistreur de replay, routage du fournisseur et panneau LAB ; premiers essais.
24 août · nuit
Serveur d'autorisation OAuth avec PKCE et métadonnées de découverte, construit et testé en une seule session.
25 août · 00:15
Exécuteur Grok CLI avec sessions persistantes par agent ; le guide du connecteur.
25 août · 00h27 à 00h43
Orchestrator écrit et exécuté : sept agents sur dix ont établi des sessions dans l'ordre en chaîne prévu (joueurs, puis Observateur, Difficulté, Provocateur, Evolution, Juge).
25 août · après-midi
Plugins de connecteur par bot et manifestes de marché ; dix Grok Bot connectés via MCP, statut visible dans le LAB.
25 août · soir
Enregistrements, captures d'écran et l'article.
26 août
Passe de durcissement : repli de la CLI désarmé par défaut, secrets supprimés de l'exemple d'environnement, chartes et moteur affinés, tests pour les invariants d'honnêteté.

Reconstruit à partir de l'historique des fichiers : le référentiel contient une validation d'échafaudage et tout le reste non validé, donc l'ordre provient des horodatages, des marqueurs de session et des documents, et non de git.

18 · Ingénierie

10: rôles d'agent
4: joueurs
6: agents système
30: Outils MCP
20: tours par match
30 s: fenêtre de décision
4: actions décidables
33: types d'événements
12: types de règles DSL
10: règles constitutionnelles
14: Itinéraires API
125: réussir des tests

Expérience: Next.js 16,3 · React 19,2 · React Three Fiber 9 · trois 10 · trois 0,185 · zéro 5 · Tailwind CSS 4
Moteur d'arène: Moteur de jeu TypeScript (2 035 lignes) : boucle de ticks, RNG prédéfini, attributs génériques du joueur, 33 événements typés, enregistreur de replay
Couche agent: Interface AgentProvider · MockAgentProvider · GrokAgentProvider · RoutingAgentProvider · chartes par bot · Orchestrateur Grok CLI avec sessions persistantes
Protocole: Serveur MCP écrit à la main sur JSON-RPC (HTTP diffusable, SSE en option), 3 versions de protocole, 30 outils adaptés aux rôles, boîte aux lettres en mémoire avec persistance du disque
Authentification: Jetons de porteur par robot dérivés de HMAC · Code d'autorisation OAuth 2 avec PKCE S256, actualisation et autorisations d'identification client, découverte RFC 8414/9728 · Clé d'hôte pour le pont moteur
IA: API xAI Responses avec un outil de choix_action forcé (modèle par défaut grok-4-fast-non-reasoning) · nommé Grok Bots via les connecteurs MCP · Grok CLI 1.0
Tests: Vitest 4 : 13 fichiers, 126 cas (125 réussis, 1 preuve en direct opt-in), environnement de nœud, aucun test de composants

La grande idée

Ce que je souhaite tester ensuite.

Je voulais voir quels outils les agents utilisaient, s’ils respectaient les permissions et comment leurs décisions s’influençaient mutuellement.

Table de vérité

Couche par couche.

Calque	Statut	Preuve
Interface utilisateur de l'arène (3D + HUD)	Démontré	Fonctionne localement ; chaque état de cette page en a été capturé.
Moteur de jeu	Démontré	Les correspondances complètes sont résolues de bout en bout en mode local ; 125 épreuves.
Agents de joueurs	Démontré / Construit	Heuristique simulée démontrée ; Chemin d'appel de fonction xAI construit et testé unitairement, aucun appel en direct capturé ; Soumissions GROK_BOT via MCP construites.
Agents système	Connecté / Scripté	Ensembles d'outils réels MCP connectés en mode GROK_BOT. En mode local, le scénario du conseil est scénarisé à partir d'un pool de quatre règles.
Outils MCP (30)	Démontré	Les dix robots se sont tous authentifiés, ont répertorié leurs outils de rôle et au moins un a exécuté get_match_state, comme indiqué dans le LAB.
Authentification	Démontré / Construit	Jetons de porteur par robot utilisés dans les connexions en direct. OAuth avec PKCE construit et testé ; aucun échange de jetons externe capturé.
Intégration Grok Bot	Expérimental	Dix robots nommés existent et sont connectés ; plusieurs ont signalé que le connecteur était en panne ou illisible. Le runtime stable est devenu l'orchestrateur Grok CLI.
Exécution en direct multi-agents	Expérimental	Sept des dix agents dirigeaient la chaîne du conseil le 25 août ; un match complet de 20 tours à entraînement externe n'a pas été préservé.
Replay / télémétrie	Construit	L'enregistreur, le journal d'audit et la télémétrie existent en mémoire ; la visionneuse de relecture n'est pas livrée et aucun journal d'exécution ne survit.
Déploiement en production	Aucun	Local uniquement, exposé via un tunnel temporaire lors d'expériences.

CONSTRUIT : existe et fonctionne localement. CONNECTÉ : communiqué avec le système Grok externe. DÉMONTRÉE : exécuter bout à bout et observer. EXPÉRIMENTAL : partiel, échafaudé ou instable. Tous les identifiants, secrets et adresses de tunnel ont été exclus de cette page et de ses supports.

D’autres projets.

Regardez à nouveau l'arène Tous les projets →