Titre de l'article : Bot de trading de simulation multi-LLM avec Claude Opus comme ingénieur principal et Gemini comme stratège : Analyse de l'architecture

Un développeur a partagé un bot de paper-trading autonome fonctionnant sur Alpaca, utilisant une architecture multi-LLM avec des rôles délimités et un processus de veto documenté. Le projet compte environ 4 900 lignes de code réparties sur cinq modules Python et est entièrement open-source sur GitHub.

Architecture : trois rôles, périmètres définis

• Commandant (humain) : Autorité sur le capital et validation de la thèse. Tout ce qui touche à l'argent nécessite une approbation humaine.
• Stratège (Gemini Pro) : Limité à la seule adjudication de thèse. N'a pas le droit de faire des choix d'implémentation, de choisir le SDK du courtier ou de décider de l'architecture.
• Ingénieur en chef (Claude Opus 4) : Écrit tout le code. Audite les directives du Stratège et a un droit de veto sur les directives qui ne résistent pas à la réalité technique. Les vetos sont enregistrés officiellement.

Aucune partie ne peut déployer de manière autonome. Chaque désaccord est consigné dans un document appelé « Codex du Stratège », qui contient désormais plus de 270 entrées. Le codex ne cache jamais les revirements — si un principe est ultérieurement remplacé, les deux versions restent avec leurs dates.

Pourquoi le multi-LLM fonctionne ici

Le créateur affirme qu'un seul LLM n'a aucune incitation à être en désaccord avec lui-même. Deux LLM de fournisseurs différents, avec des périmètres définis et un processus de veto documenté, produisent quelque chose de plus proche d'un véritable processus de revue technique. La friction force le désaccord à se produire en phase de conception plutôt qu'en post-mortem.

Exemple concret : désaccord sur un champ du SDK du courtier

Directive du Stratège : ancrer une horloge de déchéance de position sur 14 jours au champ Position.created_at du SDK du courtier. Claude (Ingénieur) a vérifié dir(Position) sur le SDK live d'Alpaca et a constaté que le champ n'existe pas. Il a implémenté un registre côté état et enregistré la mise à jour de doctrine avec la justification : « le courtier ne fournissait en fait pas le champ supposé par l'adjudication initiale. » Lors de la revue d'architecture, Claude a encore refactorisé parce que la première version verrouillait un état sur plusieurs appels au courtier. Les deux passages sont enregistrés dans le Codex.

À qui cela s'adresse

Développeurs créant des workflows multi-agent avec LLM, en particulier pour l'automatisation financière ou tout domaine où les pistes d'audit et la revue contradictoire sont essentielles. Également pertinent pour ceux qui explorent les systèmes multi-agents coordonnés avec journalisation explicite des vetos.

Dépôt et article d'architecture complet de 9 pages : https://github.com/ALGEM-hub/Whitepaper