Multi-LLM Papier-Trading-Bot mit Claude Opus als leitendem Ingenieur und Gemini als Stratege: Architekturaufschlüsselung

Ein Entwickler hat einen autonomen Paper-Trading-Bot vorgestellt, der auf Alpaca läuft und eine Multi-LLM-Architektur mit festgelegten Rollen und einem dokumentierten Veto-Prozess verwendet. Das Projekt umfasst rund 4.900 Codezeilen in fünf Python-Modulen und ist vollständig als Open Source auf GitHub verfügbar.

Architektur: Drei Rollen, klar abgegrenzte Verantwortlichkeiten

• Commander (Mensch): Kapitalentscheider und Freigabe der Anlagestrategie. Alles, was Geld betrifft, erfordert menschliche Zustimmung.
• Strategist (Gemini Pro): Beschränkt auf die Bewertung von Anlagestrategien. Darf keine Implementierungsentscheidungen treffen, das Broker-SDK auswählen oder die Architektur festlegen.
• Lead Engineer (Claude Opus 4): Schreibt den gesamten Code. Prüft die Anweisungen des Strategists und hat ein Vetorecht gegen Anweisungen, die in der Praxis nicht umsetzbar sind. Vetos werden dokumentiert.

Keine Partei kann eigenständig Änderungen vornehmen. Jede Meinungsverschiedenheit wird in einem „Strategist Codex“ festgehalten, der mittlerweile über 270 Einträge umfasst. Der Codex verschweigt keine Änderungen – wird ein Grundsatz später überholt, bleiben beide Versionen mit Datum erhalten.

Warum Multi-LLM hier funktioniert

Der Ersteller argumentiert, dass ein einzelnes LLM keinen Anreiz hat, mit sich selbst zu widersprechen. Zwei LLMs verschiedener Anbieter mit klar abgegrenzten Rollen und einem dokumentierten Veto-Pfad erzeugen einen Prozess, der einer echten technischen Überprüfung näher kommt. Die Reibung verlagert Meinungsverschiedenheiten in die Entwurfsphase statt in die Nachbetrachtung.

Praxisbeispiel: Uneinigkeit über das Broker-SDK-Feld

Anweisung des Strategists: einen 14-Tage-Positionsverfalls-Timer am Position.created_at-Feld des Broker-SDKs verankern. Claude (Engineer) prüfte dir(Position) gegen das Live-Alpaca-SDK und stellte fest, dass das Feld nicht existiert. Stattdessen implementierte er ein state-seitiges Hauptbuch und dokumentierte die Aktualisierung der Doktrin mit Begründung: „Der Broker hat das Feld, das die ursprüngliche Entscheidung voraussetzte, tatsächlich nicht bereitgestellt.“ Bei der Architekturprüfung nahm Claude weitere Umstrukturierungen vor, weil der erste Entwurf eine Zustandssperre über mehrere Broker-Aufrufe hinweg hielt. Beide Versionen sind im Codex festgehalten.

Für wen ist das gedacht

Für Entwickler, die Multi-LLM-Agenten-Workflows erstellen, insbesondere für Finanzautomatisierung oder Bereiche, in denen Prüfpfade und kritische Gegenprüfung wichtig sind. Auch interessant für alle, die koordinierte Multi-Agenten-Systeme mit expliziter Veto-Protokollierung erforschen.

Repository und vollständiges 9-seitiges Architektur-Papier: https://github.com/ALGEM-hub/Whitepaper