Multi-Agenten-Architektur: Systeme bauen, die gemeinsam denken

Warum mehrere Agenten besser sind als ein einzelner

Hier ist etwas, das wir auf die harte Tour gelernt haben: Einem einzelnen Agenten einfach mehr Faehigkeiten zu geben, skaliert nicht. Irgendwann wird dein Super-Agent zu einem verwirrten Durcheinander, das zu viele Verantwortlichkeiten jongliert.

Denk darueber nach, wie echte Teams funktionieren. Du hast nicht eine Person, die Vertrieb, Engineering, Support und Recht macht. Du hast Spezialisten, die zusammenarbeiten. Multi-Agenten-Systeme funktionieren genauso. Jeder Agent konzentriert sich auf das, was er am besten kann, und sie koordinieren sich, um komplexe Probleme gemeinsam zu loesen.

Wir haben unser erstes Produktions-Multi-Agenten-System vor zwei Jahren fuer eine Due-Diligence-Plattform gebaut. Ein einzelner Agent wurde staendig verwirrt zwischen Finanzanalyse und rechtlicher Dokumentenpruefung. Als wir ihn in spezialisierte Agenten aufteilten, stieg die Genauigkeit um 40% und die Verarbeitungszeit halbierte sich.

Die Frage ist nicht, ob du mehrere Agenten brauchst. Es ist, wann du ueber einen einzelnen Agenten hinausgewachsen bist und wie du den Uebergang architektonisch gestaltest.

Agenten-Kommunikationsmuster

Bevor Agenten zusammenarbeiten koennen, muessen sie miteinander kommunizieren. Das Kommunikationsmuster, das du waehlst, formt grundlegend, was dein System kann.

Direkte Nachrichten (Punkt-zu-Punkt)

Das einfachste Muster. Agent A sendet eine Nachricht direkt an Agent B und wartet auf eine Antwort.

// Research Agent fragt Data Agent nach Informationen
const response = await dataAgent.query({
  from: 'research-agent',
  request: 'Hole Quartalsumsaetze fuer Unternehmen im Gesundheitssektor',
  priority: 'high',
  timeout: 30000
});

Wann verwenden:

• Zwei Agenten brauchen enge Koordination
• Niedrige Latenzanforderungen
• Einfache Request-Response-Workflows

Der Nachteil: Es erzeugt enge Kopplung. Wenn Agent B ausfaellt, wartet Agent A endlos. Es skaliert auch nicht gut, wenn du Informationen broadcasten musst.

Publish-Subscribe (Event-Driven)

Agenten veroeffentlichen Events zu Topics. Andere Agenten abonnieren Topics, die sie interessieren. Niemand muss wissen, wer zuhoert.

// Wenn ein neues Dokument ankommt, Event veroeffentlichen
eventBus.publish('document.received', {
  documentId: 'doc-123',
  type: 'contract',
  source: 'client-upload',
  timestamp: Date.now()
});

// Legal Agent abonniert Vertrags-Events
eventBus.subscribe('document.received', async (event) => {
  if (event.type === 'contract') {
    await legalAgent.startReview(event.documentId);
  }
});

// Compliance Agent abonniert auch
eventBus.subscribe('document.received', async (event) => {
  await complianceAgent.checkRequirements(event.documentId);
});

Wann verwenden:

• Mehrere Agenten brauchen dieselben Informationen
• Agenten sollen unabhaengig operieren
• Du willst lose Kopplung und Skalierbarkeit

Der Nachteil: Schwerer zu debuggen, weil es keinen klaren Call Stack gibt. Events koennen verloren gehen, wenn Subscriber fehlschlagen.

Shared Blackboard

Alle Agenten lesen und schreiben in einen gemeinsamen Arbeitsbereich. Stell es dir wie ein Whiteboard in einem Konferenzraum vor, das alle aktualisieren koennen.

// Blackboard-Struktur fuer eine Recherche-Aufgabe
const blackboard = {
  task: {
    goal: 'Analysiere Marktchance fuer KI im Gesundheitswesen',
    deadline: '2025-05-20',
    status: 'in_progress'
  },
  findings: {
    marketSize: { value: '45 Mrd. EUR', source: 'ResearchAgent', confidence: 0.85 },
    competitors: { value: [...], source: 'CompetitorAgent', confidence: 0.9 },
    regulations: { value: [...], source: 'LegalAgent', confidence: 0.95 }
  },
  openQuestions: [
    'Wie sieht die Erstattungslandschaft aus?',
    'Welche Partnerschaften sind zu beruecksichtigen?'
  ]
};

Wann verwenden:

• Komplexe Probleme, die mehrere Perspektiven erfordern
• Agenten muessen auf der Arbeit anderer aufbauen
• Die Problemstruktur entsteht waehrend des Loesens

Der Nachteil: Nebenlaeufigkeit wird knifflig. Mehrere Agenten, die in denselben Bereich schreiben, koennen Konflikte erzeugen.

Message Broker (Queue-basiert)

Agenten kommunizieren ueber einen zentralen Message Broker. Nachrichten werden eingereiht und der Reihe nach verarbeitet.

Wir verwenden typischerweise eine Kombination. Direkte Nachrichten fuer zeitkritische Koordination. Pub-Sub fuer Status-Updates. Message Queues fuer Arbeitsverteilung.

Koordinationsstrategien

Agenten zu haben, die kommunizieren koennen, ist nur der Anfang. Du brauchst Strategien dafuer, wie sie zusammenarbeiten.

Hierarchische Koordination

Ein Agent fungiert als Manager. Er empfaengt Aufgaben, zerlegt sie, weist Arbeit an Sub-Agenten zu und aggregiert Ergebnisse.

                    Manager Agent
                         |
        +----------------+----------------+
        |                |                |
   Research Agent   Analyse Agent   Schreib Agent

class ManagerAgent {
  async handleTask(task) {
    // Aufgabe zerlegen
    const subtasks = await this.decompose(task);

    // An Spezialisten zuweisen
    const assignments = [
      { agent: this.researchAgent, task: subtasks.research },
      { agent: this.analysisAgent, task: subtasks.analysis }
    ];

    // Parallel ausfuehren wo moeglich
    const results = await Promise.all(
      assignments.map(a => a.agent.execute(a.task))
    );

    // Aggregieren und synthetisieren
    return this.synthesize(results);
  }
}

Am besten fuer: Klar definierte Workflows, eindeutige Aufgabengrenzen, wenn du Vorhersagbarkeit brauchst.

Marktbasierte Koordination

Agenten bieten auf Aufgaben basierend auf ihren Faehigkeiten und Verfuegbarkeit. Der am besten geeignete Agent gewinnt die Arbeit.

class TaskAuction {
  async assignTask(task) {
    // Aufgabe an alle faehigen Agenten ankuendigen
    const bids = await Promise.all(
      this.agents.map(agent => agent.bid(task))
    );

    // Jedes Gebot enthaelt Faehigkeits-Score, Verfuegbarkeit, geschaetzte Zeit
    // {
    //   agent: 'legal-agent-2',
    //   capability: 0.95,
    //   availability: 0.8,
    //   estimatedTime: 120,
    //   price: 0.15  // Kosten in Compute-Einheiten
    // }

    // Gewinner basierend auf Scoring-Funktion waehlen
    const winner = this.selectBest(bids, {
      weights: { capability: 0.5, time: 0.3, price: 0.2 }
    });

    return winner.agent.execute(task);
  }
}

Am besten fuer: Dynamische Workloads, heterogene Agenten, wenn Load Balancing wichtig ist.

Kollaborativer Konsens

Agenten diskutieren und erreichen Einigung, bevor sie handeln. Niemand trifft einseitig Entscheidungen.

class ConsensusGroup {
  async decide(proposal) {
    // Jeder Agent bewertet den Vorschlag
    const votes = await Promise.all(
      this.agents.map(agent => agent.evaluate(proposal))
    );

    // Auf Konsens pruefen (z.B. 2/3 Mehrheit)
    const approvals = votes.filter(v => v.approve).length;
    const threshold = Math.ceil(this.agents.length * 0.67);

    if (approvals >= threshold) {
      return { approved: true, confidence: approvals / this.agents.length };
    }

    // Wenn kein Konsens, teilen Agenten Begruendungen und versuchen es erneut
    const reasoning = votes.map(v => v.reasoning);
    return this.deliberate(proposal, reasoning);
  }
}

Am besten fuer: Entscheidungen mit hohem Einsatz, wenn mehrere Perspektiven wichtig sind, Reduzierung von Einzelagenten-Fehlern.

Aufgabenzerlegung: Probleme aufbrechen

Gute Aufgabenzerlegung ist eine Kunst. Zerlege Aufgaben zu fein und du ertrinkst in Koordinations-Overhead. Zerlege sie zu grob und du verlierst die Vorteile der Spezialisierung.

Funktionale Zerlegung

Aufteilen nach Art der Arbeit. Recherche-Aufgaben gehen an Recherche-Agenten. Schreibaufgaben gehen an Schreib-Agenten.

const decompositionRules = {
  'market-analysis': {
    subtasks: [
      { type: 'research', agent: 'market-research-agent' },
      { type: 'competitor-analysis', agent: 'competitor-agent' },
      { type: 'financial-modeling', agent: 'finance-agent' },
      { type: 'report-synthesis', agent: 'writing-agent', dependsOn: ['research', 'competitor-analysis', 'financial-modeling'] }
    ]
  }
};

Daten-Zerlegung

Aufteilen nach den zu verarbeitenden Daten. Jeder Agent bearbeitet eine Teilmenge.

// Verarbeitung von 10.000 Dokumenten fuer Vertragspruefung
const documents = await getDocuments();
const chunks = chunkArray(documents, 1000);

// Auf Agenten verteilen
const results = await Promise.all(
  chunks.map((chunk, i) =>
    contractAgents[i % contractAgents.length].process(chunk)
  )
);

Rekursive Zerlegung

Lass Agenten ihre eigenen Unteraufgaben zerlegen. Das bewaeltigt komplexe, unvorhersehbare Probleme.

class RecursiveAgent {
  async solve(problem) {
    // Bewerten, ob Problem direkt loesbar ist
    if (this.canSolveDirectly(problem)) {
      return this.directSolve(problem);
    }

    // In Teilprobleme zerlegen
    const subproblems = await this.decompose(problem);

    // Jedes loesen (kann weiter rekursieren)
    const solutions = await Promise.all(
      subproblems.map(sp => this.solve(sp))
    );

    // Loesungen kombinieren
    return this.combine(solutions);
  }
}

Zerlegungs-Entscheidungsmatrix

Agenten-Spezialisierung

Spezialisierte Agenten uebertreffen Generalisten konsistent in ihrem Bereich. So denken wir ueber Spezialisierung nach.

Tiefe vs. Breite Tradeoff

Generalist Agent
+------------------+
| Kann alles       |
| Mittelmaessig    |
| in allem         |
+------------------+

Spezialist Agenten
+--------+ +--------+ +--------+
|Research| |Analyse | |Schreib |
|Experte | |Experte | |Experte |
+--------+ +--------+ +--------+

Spezialisten-Agenten designen

Jeder Spezialist braucht:

1. Domaenenspezifische Prompts abgestimmt auf ihre Aufgabe
2. Spezialisierte Tools die Generalisten nicht brauchen
3. Kuratiertes Wissen relevant fuer ihre Domaene
4. Fokussiertes Gedaechtnis das domaenenspezifische Erkenntnisse speichert

const legalReviewAgent = {
  name: 'legal-review-agent',

  systemPrompt: `Du bist ein Spezialist fuer rechtliche Dokumentenpruefung.
    Fokus auf: Vertragsbedingungen, Haftungsklauseln, Compliance-Anforderungen.
    Markiere: Ungewoehnliche Bestimmungen, fehlende Standardklauseln, potenzielle Risiken.
    Ausgabeformat: Strukturiertes JSON mit Schweregradebewertungen.`,

  tools: [
    'legal-database-search',
    'precedent-lookup',
    'clause-comparison',
    'regulatory-checker'
  ],

  knowledge: [
    'contract-law-embeddings',
    'company-legal-policies',
    'historical-contract-reviews'
  ],

  memory: {
    store: 'legal-agent-memory',
    retain: ['common-issues-found', 'client-preferences', 'jurisdiction-rules']
  }
};

Wenn Spezialisierung schiefgeht

Wir haben gesehen, wie Teams ueberpezialisieren. Zeichen, dass du zu weit gegangen bist:

• Agenten verbringen mehr Zeit mit Koordination als mit Arbeit
• Einfache Aufgaben werden zwischen 5+ Agenten hin und her geschoben
• Neue Faehigkeiten hinzuzufuegen erfordert Neugestaltung des gesamten Systems
• Domaenengrenzen werden unklar

Die Loesung: Starte mit weniger, breiteren Agenten. Spezialisiere nur, wenn du klare Leistungsgewinne durch Aufteilung siehst.

Konsensmechanismen

Wenn mehrere Agenten dasselbe Problem analysieren, sind sie oft uneins. Du brauchst Mechanismen, um das zu loesen.

Abstimmungssysteme

class MajorityVote {
  async decide(question, agents) {
    const answers = await Promise.all(
      agents.map(a => a.analyze(question))
    );

    // Nach Antwort gruppieren
    const votes = {};
    for (const answer of answers) {
      const key = this.normalize(answer.conclusion);
      votes[key] = votes[key] || { count: 0, supporters: [] };
      votes[key].count++;
      votes[key].supporters.push(answer);
    }

    // Mehrheit finden
    const sorted = Object.entries(votes).sort((a, b) => b[1].count - a[1].count);
    const [winner, data] = sorted[0];

    return {
      conclusion: winner,
      confidence: data.count / agents.length,
      dissent: sorted.slice(1).map(([conclusion, d]) => ({
        conclusion,
        count: d.count,
        reasoning: d.supporters[0].reasoning
      }))
    };
  }
}

Gewichteter Konsens

Nicht alle Agenten sind gleich. Gib Spezialisten oder Antworten mit hoher Konfidenz mehr Gewicht.

class WeightedConsensus {
  async decide(question, agents) {
    const answers = await Promise.all(
      agents.map(a => a.analyze(question))
    );

    // Gewichtung nach Agenten-Expertise und selbst berichteter Konfidenz
    const weighted = answers.map(a => ({
      conclusion: a.conclusion,
      weight: a.confidence * this.getAgentExpertise(a.agent, question.domain)
    }));

    // Gewichtete Scores aggregieren
    return this.aggregateWeighted(weighted);
  }

  getAgentExpertise(agent, domain) {
    // Basierend auf historischer Genauigkeit in dieser Domaene
    return this.expertiseScores[agent.id]?.[domain] || 0.5;
  }
}

Debatte und Deliberation

Agenten argumentieren ihre Positionen und aktualisieren basierend auf der Argumentation anderer.

class DebateConsensus {
  async decide(question, agents, maxRounds = 3) {
    let round = 0;
    let positions = await this.getInitialPositions(question, agents);

    while (round < maxRounds && !this.hasConsensus(positions)) {
      // Jeder Agent sieht Positionen und Argumentation anderer
      const sharedContext = this.formatPositions(positions);

      // Agenten aktualisieren ihre Positionen
      positions = await Promise.all(
        agents.map(async (agent, i) => {
          const updated = await agent.reconsider(question, {
            myPosition: positions[i],
            othersPositions: sharedContext
          });
          return updated;
        })
      );

      round++;
    }

    return this.finalDecision(positions);
  }
}

Konsensmuster-Vergleich

Praxis-Architekturbeispiele

Schauen wir uns einige Systeme an, die wir tatsaechlich gebaut haben.

Kundensupport-System

                        Router Agent
                             |
        +--------------------+--------------------+
        |                    |                    |
   Technical Agent     Billing Agent       General Agent
        |                    |                    |
   +----+----+          +----+----+              |
   |         |          |         |              |
 Debug    Docs      Refunds   Payment         FAQ
 Agent   Agent       Agent     Agent         Agent

Kommunikation: Request-Response fuer Routing. Events fuer Eskalation. Geteilter Kundenkontext in Datenbank.

Koordination: Hierarchisch mit marktbasiertem Fallback (wenn primaerer Agent ueberlastet ist, koennen andere bieten).

Ergebnisse: 65% der Tickets vollautomatisiert. Durchschnittliche Loesungszeit sank von 4 Stunden auf 12 Minuten fuer automatisierte Faelle.

Recherche- und Analyseplattform

   Orchestrator
        |
   +----+----+----+----+
   |    |    |    |    |
  Web  Data Legal Fin  Synthesis
  Agent Agent Agent Agent Agent

Kommunikation: Shared Blackboard fuer Erkenntnisse. Message Queue fuer Arbeitsverteilung.

Koordination: Kollaborativer Konsens fuer Schlussfolgerungen. Jeder Agent traegt Erkenntnisse bei, Synthesis Agent loest Konflikte.

Zerlegung: Funktional nach Recherchedomaene. Rekursiv, wenn initiale Recherche neue zu erforschende Bereiche aufdeckt.

Dokumentenverarbeitungs-Pipeline

Ingestion -> Klassifizierung -> [Verzweigung nach Typ]
                                    |
             +----------------------+----------------------+
             |                      |                      |
       Vertrags-Flow          Rechnungs-Flow         Bericht-Flow
             |                      |                      |
        [Legal Agent]          [Finance Agent]       [Analyse Agent]
             |                      |                      |
         Validierung              Matching             Zusammenfassung
             |                      |                      |
        +----+                 +----+                  +----+
   Menschliche Review      Auto-Verarbeitung         Verteilung

Kommunikation: Event-getriebene Pipeline. Jede Stufe veroeffentlicht Abschluss-Events.

Koordination: Meist sequenziell mit parallelen Zweigen nach Dokumenttyp.

Spezialisierung: Dokumenttyp-spezifische Agenten mit tiefem Wissen ihrer Domaene.

Fehlerbehandlung und Resilienz

Multi-Agenten-Systeme versagen auf interessante Weise. Hier ist, was wir gelernt haben.

Fehlermodi

Resilienz aufbauen

class ResilientAgentSystem {
  async executeWithFallback(task, primaryAgent, fallbackAgents) {
    try {
      return await this.withTimeout(
        primaryAgent.execute(task),
        30000
      );
    } catch (error) {
      this.logger.warn(`Primaerer Agent fehlgeschlagen: ${error.message}`);

      // Fallbacks der Reihe nach versuchen
      for (const fallback of fallbackAgents) {
        try {
          return await this.withTimeout(
            fallback.execute(task),
            30000
          );
        } catch (fallbackError) {
          this.logger.warn(`Fallback fehlgeschlagen: ${fallbackError.message}`);
        }
      }

      // Alle Agenten fehlgeschlagen - an Menschen eskalieren
      return this.escalateToHuman(task, error);
    }
  }
}

Circuit Breaker

Wenn ein Agent beginnt, wiederholt zu versagen, hoere temporaer auf, ihm Arbeit zu senden.

class CircuitBreaker {
  constructor(threshold = 5, resetTime = 60000) {
    this.failures = 0;
    this.threshold = threshold;
    this.resetTime = resetTime;
    this.state = 'closed'; // closed = normal, open = blockiert
  }

  async execute(fn) {
    if (this.state === 'open') {
      throw new Error('Circuit Breaker ist offen');
    }

    try {
      const result = await fn();
      this.failures = 0;
      return result;
    } catch (error) {
      this.failures++;
      if (this.failures >= this.threshold) {
        this.state = 'open';
        setTimeout(() => {
          this.state = 'half-open';
        }, this.resetTime);
      }
      throw error;
    }
  }
}

Multi-Agenten-Systeme skalieren

Wenn dein System waechst, wirst du auf Skalierungsherausforderungen stossen.

Horizontale Skalierung

Fuehre mehrere Instanzen jedes Agententyps aus. Verwende Load Balancer zur Arbeitsverteilung.

const agentPool = {
  'research-agent': {
    instances: ['research-1', 'research-2', 'research-3'],
    loadBalancer: 'round-robin'
  },
  'analysis-agent': {
    instances: ['analysis-1', 'analysis-2'],
    loadBalancer: 'least-connections'
  }
};

Skalierungs-Metriken zum Beobachten

Loslegen

Wenn du dein erstes Multi-Agenten-System baust, hier ist unser Rat:

1. Starte mit zwei Agenten. Manager und Worker. Bring die Koordination zum Laufen, bevor du Komplexitaet hinzufuegst.

2. Verwende zuerst einfache Kommunikation. Direkte Nachrichten sind einfacher zu debuggen als Pub-Sub.

3. Instrumentiere alles. Logge jede Agenten-Entscheidung, jede Nachricht, jeden Fehler. Du wirst es brauchen.

4. Design fuer Fehler. Nimm an, dass Agenten abstuerzen. Baue Resilienz von Tag eins ein.

5. Miss den Koordinations-Overhead. Wenn Agenten mehr Zeit mit Reden als mit Arbeiten verbringen, vereinfache.

Die Architekturmuster hier sind nicht theoretisch. Wir haben Systeme mit jedem davon gebaut. Die richtige Wahl haengt von deinem spezifischen Problem ab, der Expertise deines Teams und deinen Skalierungsanforderungen.

Multi-Agenten-Systeme sind schwerer zu bauen als einzelne Agenten. Aber fuer komplexe Probleme sind sie oft der einzige Ansatz, der funktioniert. Starte einfach, miss alles und entwickle deine Architektur basierend auf dem, was du lernst.

Wenn du Multi-Agenten-Architekturen erforschst und deinen Use Case durchsprechen willst, melde dich. Wir haben viel von den Systemen gelernt, die wir gebaut haben, und teilen gerne, was wir wissen.