Praktische Erkenntnisse aus 11 Multi-Agenten-Software-Builds ohne programmatische Gerüstbildung

Wichtige technische Erkenntnisse aus Multi-Agenten-System-Experimenten

Die Analyse von 11 autonomen Multi-Agenten-Software-Implementierungen ohne programmatische Gerüste, basierend auf 295 Millionen Tokens, 98 Agentensitzungen und 6,1 Millionen Zeilen Arbeitsausgabe, liefert praktische Einblicke für Entwickler, die mit KI-Codierungsagenten arbeiten.

Durchsetzung des Anwendungsbereichs und Orchestrierung

Die Durchsetzung des Anwendungsbereichs wird mechanisch gelöst, nicht durch Prompts: Prompt-basierte Ansätze scheiterten 0/20 Mal unter Compiler-Druck, während mechanische Ansätze (Agenten alles bearbeiten lassen und git revert für Dateien außerhalb des Bereichs verwenden) 20/20 Mal erfolgreich waren. Die zentrale Erkenntnis: Bitten Sie Modelle nicht, Grenzen zu respektieren – setzen Sie sie nachträglich durch.

Orchestrierungskosten sind speichergebunden: Etwa 95 % der Eingabekosten entstehen durch das erneute Lesen der Konversationshistorie. Die „Prämie für Zustandsbehaftung“ bedeutet, dass ein fortschrittlicher Orchestrator, der keinen ausgelieferten Code schreibt, so viel kosten kann wie die gesamte Arbeitsflotte. Die Optimierung sollte auf weniger Interaktionen und weniger Wiedereingabe abzielen, nicht auf günstigeres Denken.

Koordinations- und Skalierungsdynamiken

Modelle entdecken Koordination nicht eigenständig: Bare-prompt Opus mit vollem Werkzeugzugang delegierte nie, schrieb nie Spezifikationen und entdeckte nie parallele Verteilung – es baute einfach alles alleine. Die Koordinationsvorlage leistet echte Arbeit.

Tiefe skaliert anders als Qualität: Flache Verteilung schlägt Hierarchie bei ≤10 Domänen in Durchsatz, Token-Effizienz und Echtzeit. Über 10 Domänen hinaus ermöglicht Hierarchie Parallelität, die flache Verteilung nicht erreichen kann.

Alleinarbeit übertrifft Koordination, bis Kontextgrenzen binden: Der Solo-Durchsatz liegt bei etwa 325 LOC/min und ist unabhängig von der Projektgröße. Der Pyramidendurchsatz skaliert mit den Arbeitern. Unter ~30.000 LOC ist Delegation reiner Overhead.

Arbeitsleistung und Typsysteme

Die Fähigkeiten des Arbeitsmodells bestimmen den Durchsatz: Gleiche Architektur, gleiche Spezifikation, drei Arbeitsmodelle erzeugten: 17.761 LOC vs. 6.001 vs. 1.818 – eine 9,8-fache Lücke. Die Architektur ermöglicht parallelen Durchsatz; das Arbeitsmodell bestimmt ihn.

Typverträge bieten gemeinsame Sprache: Die Integration gelingt ohne Verträge in jedem getesteten Maßstab (6–36 Module), selbst unter schreibgeschützten Einschränkungen. Aber ohne Verträge erzeugen parallele Arbeiter stillschweigend strukturell inkompatible Typen, die nur kompilieren, weil nichts querreferenziert. Ein einziger blind geschriebener 984-Zeilen-Vertrag hielt über 10 unabhängige Domänen.

Typverträge eliminieren Koordinations-Overhead im großen Maßstab: Ein kontrollierter Skalierungstest (1–20 Arbeiter, feste Spezifikation) zeigte null Integrationsfehler über 50 Domänen-Builds. Der Sweet Spot bei 10 Arbeitern: 2,05-fache Echtzeitbeschleunigung. Bei 20 Arbeitern negieren serielle Phasenabhängigkeiten die Parallelitätsgewinne (Amdahls serieller Anteil ~44 %).

Kontext- und Delegationsmuster

Kontextvorbereitung funktioniert; das Format ist egal: 0 % Formeltransfer kalt, 100 % mit vorhandenem Designkontext (N=10 pro Bedingung). Ein statisches Referenzdokument erzeugt identische Transferraten wie eine synthetische Boot-Konversation.

Delegationskomprimierung ist inhärent: Jede Delegationsebene fungiert als verlustbehafteter Zusammenfasser. Quantitative Anforderungen („80 Waffen“) verschwinden; strukturelle Anforderungen (Typschnittstellen) überleben. Lösung: Arbeiter sollten vollständige Spezifikationen vom Dateisystem lesen, anstatt sich auf komprimierte Prompt-Ketten zu verlassen.

Komprimierungswiederherstellung ist robust mit guten Zusammenfassungen: Kein Aufgabenrückfall über 11 Komprimierungsereignisse. Das Modell gibt den erwarteten Zustand an und liest dann die Festplatte zur Überprüfung.

Fehlermodi und Lösungen

• Abstraktionsreflex: Baut einen Orchestrator statt zu orchestrieren – nennen Sie ihn im Prompt
• Selbstmodellfehler: Behauptet falsche Fähigkeiten – dokumentieren Sie verfügbare Werkzeuge explizit
• Identitätsparadoxon: Kann keine Doppelrollen einnehmen – verwenden Sie separate Modellinstanzen
• Delegationskomprimierung: Verwenden Sie enumerative Spezifikationen plus Dateisystemzugriff