Im Inneren eines Multi-Agenten-Systems: Architekturhinweise für Krypto-Entwickler

Stellen Sie sich ein Krypto-Unternehmen vor, das an Unternehmen verkauft und Software benötigt, die DeFi-Protokolle überwacht, die Liquidität bewertet, das Risiko von Smart Contracts beurteilt, ein Treasury neu ausbalanciert, ungewöhnliche Transaktionen markiert und sogar Transaktionen nach voreingestellten Richtlinien ausführt. Ein einzelner KI-Agent, dem all das übertragen wird, ist damit überlastet. Er muss Marktdaten lesen, die Chain-Infrastruktur abfragen, Risiken bewerten, APIs aufrufen, Entscheidungen bezüglich des Geldverkehrs treffen und Transaktionen signieren – und das alles innerhalb eines einzigen Denkzyklus. Das Testen, Skalieren und Absichern einer solchen Lösung wird schnell äußerst schwierig.

Die übliche Lösung besteht darin, die Arbeit zwischen spezialisierten Agenten aufzuteilen und eine Orchestrierungsschicht darüber zu setzen. Das geht über das simple Chatten mehrerer Sprachmodelle miteinander hinaus. Es handelt sich dabei um eine Softwarearchitektur, bei der Modelllogik, Anwendungslogik, Daten, Tools, Berechtigungen und Ausführung absichtlich voneinander getrennt werden. Im Folgenden wird erläutert, wie die einzelnen Komponenten zusammenpassen und was Entwickler von Produktionsystemen in diesem Bereich berücksichtigen sollten.

Was zählt als Mehr-Agenten-System

Mehrere spezialisierte Agenten, die an einer Aufgabe zusammenarbeiten, die größer ist als das, was jeder von ihnen allein bewältigen könnte – das ist die Definition. Eine praktische Formel für einen einzelnen Agenten lautet:

Agent = KI-Modell + Anweisungen + Kontext + Tools + Zustand + Ausführungslauf

Für eine Gruppe wird eine weitere Schicht daraufgelegt:

Agenten + Orchestrierung + gemeinsamer Zustand + Kommunikation + Richtlinien

Eine Treasury-Plattform könnte folgende Komponenten umfassen:

1. Einen Forschungsagenten, der Protokoll- und Marktdaten sammelt.
2. Einen Risikoagenten, der Vertrags-, Liquiditäts- und Protokollrisiken bewertet.
3. Einen Portfolioagenten, der Möglichkeiten vergleicht und Allokationen berechnet.
4. Einen Compliance-Agenten, der die Geschäftsregeln des Unternehmens anwendet.
5. Einen Ausführungsagenten, der Transaktionen vorbereitet und einreicht.
6. Einen Überwachungsagenten, der prüft, was tatsächlich auf der Blockchain stattgefunden hat.

Nehmen wir diese Anweisung: Setzen Sie 50.000 USDC in das sicherste verfügbare Zinsprodukt ein, sofern das Protokoll die Risikopolitik erfüllt und die Ausführungskosten unter 0,5 % liegen. Dafür sind mehrere unterschiedliche Fähigkeiten erforderlich, weshalb das System dies in einen Prozessablauf umwandelt:

```text
User Request
     ↓
Orchestrator
     ↓
Research Agent
     ↓
Risk Agent
     ↓
Portfolio Agent
     ↓
Policy Check
     ↓
Execution Agent
     ↓
Blockchain
     ↓
Verification
```

Jeder Agent kümmert sich um ein kleines Problem, und keiner muss den gesamten Workflow lösen.

Die Schichten eines Produktionsystems

Sieben Komponenten tauchen immer wieder auf: ein Agent-Runtime, ein Orchestrierer, gemeinsamer Zustand, eine Tool-Schicht, eine Policy- und Sicherheitsschicht, Infrastruktur für die Ausführung sowie Möglichkeiten zur Überwachung. Jede von ihnen beantwortet eine eigene ingenieurtechnische Frage.

Agent-Runtime

Der Runtime führt einen Agent aus. In der Produktion ist ein Agent mehr als nur eine eingegebene Anfrage und eine ausgehende Antwort. Er verhält sich wie eine Schleife:

  ```text
Input
 ↓
Build Context
 ↓
Ask Model to Reason
 ↓
Choose Action
 ↓
Call Tool / Agent / Return Result
 ↓
Receive Result
 ↓
Update Context
 ↓
Reason Again
```

Nehmen wir an, ein Forschungsagent soll DeFi-Darlehensprotokolle vergleichen. Er würde eine Liste der Protokolle abrufen, ihren aktuellen TVL ermitteln, die Darlehenszinsen herausfinden, die Liquidität vergleichen, die stärksten Kandidaten auswählen und diese dem Risikoagenten übergeben. Das Modell liefert die Begründungen, während die darum herumliegende Anwendung steuert, was tatsächlich ausgeführt wird. Diese Trennung ist wichtig, denn ein Modell sollte Aufgaben nicht übernehmen, die normale Software besser erledigen kann. Das Multiplizieren von 50.000 Dollar mit 8,2 % erfordert keinen LLM, da eine einfache Funktion schneller, günstiger ist und jedes Mal das gleiche Ergebnis liefert.

Orchestrator

Der Orchestrator ist das Kontrollzentrum. Er entscheidet, welcher Agent ausgeführt wird, was diesem Agent mitgeteilt wird, was als Nächstes läuft, welche Aufgaben parallel durchgeführt werden können, wann die Arbeit abgeschlossen ist und was zu tun ist, wenn ein Agent versagt. Es gibt zwei grundlegende Ansätze.

Modellgesteuerte Orchestrierung. Ein überwachendes Modell wählt das benötigte Spezialmodell aus.

           ```text
        Supervisor Agent
              │
        ┌─────┼─────┐
        ▼     ▼     ▼
   Research  Risk  Analytics
```

Der Supervisor könnte denken, dass zunächst Protokolldaten benötigt werden, weshalb er den Forschungsagenten aufruft. Sobald das Ergebnis vorliegt, entscheidet er, dass eine Sicherheitsbewertung erforderlich ist, und ruft den Risikomanager auf. Das ist flexibel, doch die Routen können unvorhersehbar werden, zusätzliche Modellaufrufe häufen sich und damit auch die Kosten.

Code-getriebene Orchestrierung. Die Anwendung legt die Reihenfolge fest.

```text
Research
   ↓
Risk Analysis
   ↓
Policy Check
   ↓
Simulation
   ↓
Approval
   ↓
Execution
```

Diese Version ist einfacher zu testen und unter Kontrolle zu halten.

Kombination beider Ansätze. Bei B2B-Finanzprodukten ist die effektivste Konfiguration oft eine Kombination beider Ansätze. Das Modell trifft Entscheidungen, während der Code Regeln anwendet. Das Modell könnte feststellen, dass Protokoll A die beste risikoadjustierte Rendite bietet, während die Anwendung darauf besteht, dass alles über 50.000 Dollar einer weiteren Genehmigung bedarf. Die KI gibt Empfehlungen ab, und die Software sorgt für deren Umsetzung.

Gemeinsamer Zustand

Die Agenten müssen sehen können, welche früheren Schritte durchgeführt wurden. Die gesamte Konversation an jeden von ihnen weiterzuleiten, ist zeitaufwendig, daher führt das System stattdessen eine strukturierte Aufzeichnung des Workflows.

Bei einer USDC-Anfrage würde diese Aufzeichnung das Asset (USDC), die Menge (50.000), die Blockchain (Ethereum), eine Liste potenzieller Protokolle (Aave und Morpho) sowie drei Statusfelder (Risiko, Richtlinie und Ausführung) enthalten, die zunächst mit „ausstehend“, „ausstehend“ und „nicht gestartet“ versehen sind.

Der Forschungsagent füllt Felder wie Kandidatenprotokolle, Ergebnisse und Marktdaten aus. Der Risikomanager gibt eine Bewertung sowie seine Sicherheitsbefunde hinzu. Der Ausführungsagent sieht nur das, was er für seine Aufgabe benötigt. Die Struktur ist übersichtlich:

               ```text
                Shared State
                    │
         ┌──────────┼──────────┐
         ▼          ▼          ▼
    Research      Risk     Execution
     Agent        Agent     Agent
        └──────────┼──────────┘
                   ▼
             Updated State
```

Ein gemeinsames Dokument macht es außerdem viel einfacher, einen Workflow anzuhalten, fortzusetzen, zu überprüfen und zu debuggen.

Kommunikation: Übergaben und Agenten als Werkzeuge

Agenten arbeiten auf zwei nützliche Weisen zusammen. Bei einer Übergabe geht die Kontrolle von einem Agenten auf den nächsten über.

```text
Research Agent
↓
Risk Agent
↓
Portfolio Agent
```

Übergaben eignen sich für Situationen, in denen sich die Verantwortung ändert: Sobald die Marktforschung abgeschlossen ist, liegt die Bewertung der Kandidaten beim Risikomanager. Wenn ein Agent als Werkzeug verwendet wird, ruft ein Agent den anderen an und behält die Kontrolle.

     ```text
      Supervisor
      /    |   \
 Research Risk Analytics
```

Der Supervisor kann den Risikoagenten bitten, ein Protokoll anhand der Unternehmenskriterien zu prüfen, eine strukturierte Antwort zu erhalten und anschließend weiterzumachen. Dies ist hilfreich, wenn ein einziger zentraler Agent mehrere fachliche Meinungen zusammenführen muss.

Tool-Schicht

Ein Agent kann nicht allein auf eine Blockchain oder eine Datenbank zugreifen. Tools bilden die Verbindung. Ein Kryptoagent erhält möglicherweise Blockchain-RPCs, Marktdaten-APIs, DEX-Aggregator, Indexierer, Risikodatenbanken, Wallet-Infrastruktur sowie interne Finanzsysteme, die über Operationen wie get_balance(), read_contract(), estimate_gas(), simulate_transaction() und submit_transaction() zugänglich gemacht werden.

Geben Sie jedem Agenten nur den geringsten Zugriff, der für seine Arbeit ausreicht. Ein Forschungsagent benötigt möglicherweise nur read_market_data() und read_protocol_data(). Ein Ausführungsagent könnte simulate_transaction() und submit_transaction() erhalten. Es gibt keinen Grund, jedem Agenten Rechte auf Wallets oder Transaktionen zu geben, und eingeschränkte Berechtigungen verringern den Schaden, falls ein Agent sich falsch verhält oder kompromittiert wird.

Die Grenze zwischen KI und Blockchain

Das könnte der wichtigste Gestaltungsaspekt für Krypto-Produkte sein. Die Ausgabe von Modellen ist probabilistisch, während die Ausführung auf der Blockchain deterministisch ist und oft nicht rückgängig gemacht werden kann. Daher sollte kein Agent die endgültige Transaktion direkt steuern. Ein sichererer Ansatz sieht so aus:

```text
Agent Decision
     ↓
Schema Validation
     ↓
Policy Check
     ↓
Risk Check
     ↓
Transaction Simulation
     ↓
Authorization
     ↓
  Signing
     ↓
Blockchain
```

Stellen Sie sich vor, der Agent beschließt, 50.000 USDC gegen ETH einzutauschen. Die Ausführungsschicht sollte unabhängig prüfen, ob USDC ein genehmigtes Asset und ETH ein genehmigtes Ziel ist, ob der Betrag innerhalb der Grenzen des Benutzers liegt, ob eine Slippage akzeptabel ist, ob der Empfänger korrekt ist, ob die Transaktion reibungslos simuliert werden kann und ob der Benutzer zustimmen muss. Der Agent schlägt eine Aktion vor, und eine deterministische Schicht entscheidet, ob diese durchgeführt werden darf. Finanzsysteme beruhen auf dieser Trennung.

Schutzmaßnahmen und Fehlerbehandlung

Umgeben Sie jede KI-Entscheidung mit deterministischen Grenzen. Eine Konfiguration könnte beispielsweise vorsehen: maximale Transaktionssumme 50.000, maximale Slippage 0,5 %, minimale Liquidität 5 Mio., erlaubte Chains Ethereum, Arbitrum und Base. Ein Modell kann diese Zahlen nicht durch eine andere Formulierung umgehen.

Vergessen Sie auch nicht, dass eine gültige Struktur kein Beweis für korrekte Inhalte ist. Eine Ausgabe wie {"risk_score": 0.04} kann zwar perfekt strukturiert sein, dennoch auf völlig fehlerhaften Schlussfolgerungen beruhen. Ein Produktionsystem sollte das Format, die Geschäftsregeln, die Aktualität der Daten, die Zuverlässigkeit der Quellen sowie die Ergebnisse der letzten Toolaufrufe überprüfen:

```text
Agent Output
     ↓
Schema Validation
     ↓
Business Validation
    ↓
Data Validation
    ↓
Tool Execution
    ↓
Result Verification
```

Idempotenz. Betrachten wir einen Eintrag, bei dem die Frist abläuft. Der Agent könnte entscheiden, dass die Transaktion fehlgeschlagen ist, und es erneut versuchen – doch der erste Versuch könnte bereits erfolgreich gewesen sein, was zu einer Doppelung der finanziellen Aktion führen würde. Der Ausführungsdienst sollte jeder Anfrage eine eindeutige ID zuweisen, beispielsweise exec_829192, und sie mit der daraus resultierenden Transaktion verknüpfen. Wenn dieselbe Anfrage erneut eingeht, gibt der Dienst das bereits vorhandene Ergebnis zurück und sendet nichts Neues. In Finanzworkflows ist diese Eigenschaft nicht optional.

Beobachtbarkeit

Einfache Logs reichen für Agentensysteme nicht aus, denn Ingenieure benötigen den gesamten Entscheidungsweg. Für jeden Schritt muss festgehalten werden, welcher Agent ausgeführt wurde, welches Modell er verwendet hat, welche Tools er mit welchen Parametern aufgerufen hat, was zurückgekommen ist, welche Richtlinien aktiviert wurden, wie lange jeder Schritt gedauert hat und welche Transaktion schließlich versandt wurde. Wenn eine Transaktion fehlschlägt, sollte man in der Lage sein zu sagen, wer die Entscheidung getroffen hat, auf welchen Datenbasis, welche Richtlinie sie genehmigt hat, wie die Transaktion erstellt wurde und was tatsächlich auf der Blockchain passiert ist. Ohne dieses Maß an Transparenz wird der Betrieb dieser Systeme in der Produktion zu einem Ratespiel.

Um das Kernkonzept herum muss eine Produktivimplementierung Identitäts- und Zugriffskontrolle, die Verwaltung von Schlüsseln, einen Speicher für den Zustand, Throttling, Überwachung, Evaluierungsläufe sowie eine Auditspur beinhalten. Eine Demo zeigt diese Elemente nie, doch sie entscheiden darüber, ob das System in unternehmensweiter Skala funktioniert.

Verteilte Systeme mit LLMs darin

Der klarste Weg, die Herausforderung zu erkennen, besteht darin, ein Mehr-Agenten-System nicht länger als eine Ansammlung von Chatbots zu betrachten. Es handelt sich um ein verteiltes System, in dem einige Entscheidungen probabilistisch von einem Modell getroffen werden, weshalb alle klassischen Aspekte weiterhin gelten: Zustandsverwaltung, Authentifizierung, Autorisierung, Konkurrenz, Wiederholungsversuche, Idempotenz, Fehlerbehebung, Datenauswertung und Überwachbarkeit.

Das Modell ist die Denkebene und die Architektur die Steuerungsebene. Wenn echte Vermögenswerte und irreversible Transaktionen auf dem Spiel stehen, spielt dieser Unterschied eine große Rolle. Ein gut konstruiertes System strebt nicht nach unbegrenzter Autonomie, sondern nach kontrollierter Autonomie: Die Agenten sind frei, zu denken, zusammenzuarbeiten und sich anzupassen, während deterministische Software für Berechtigungen, finanzielle Grenzen, Validierung und Ausführung zuständig ist.

Die Schlussfolgerung

Der Wert liegt nicht darin, mehrere Modelle zu haben. Er besteht darin, komplexe Arbeitsabläufe in kleinere, spezialisierte Einheiten aufzuteilen, die kontrolliert werden können. Für B2B-Kryptowährungen lässt sich dieses Prinzip klar formulieren:

• Das Denken obliegt den Agenten.
• Das Abrufen von Daten und die Ausführung von Operationen gehören zu den Tools.
• Die Koordination liegt beim Orchestrator.
• Business-Regeln werden durch Richtlinien durchgesetzt.
• Transaktionen laufen über die Ausführungsschicht, die sie steuert.
• Die endgültige Abrechnung findet auf der Blockchain selbst statt.

Sobald diese Verantwortlichkeiten getrennt sind, ist das System einfacher zu skalieren, zu testen, zu sichern und zu prüfen. Das Ziel ist es nicht, KI klug erscheinen zu lassen. Es geht darum, komplexe, von KI gesteuerte Arbeitsabläufe ausreichend zuverlässig für die Produktion zu machen.