DON’T BUILD MULTI-AGENTS

Die Entwickler von Devin stellen gängige Frameworks wie OpenAI’s Swarm in Frage, indem sie argumentieren, dass parallele Subagenten fragile Systeme schaffen, die aufgrund von Kontext-Fehlern und widersprüchlichen Entscheidungen scheitern.

Einführung in die Prinzipien des Agentenbaus

Frameworks für LLM-Agenten haben sich als überraschend enttäuschend erwiesen. In diesem Artikel möchte ich einige Prinzipien für den Bau von Agenten vorstellen, die auf unseren eigenen Erfahrungen basieren, und erklären, warum einige verlockende Ideen in der Praxis tatsächlich schlecht sind.

Prinzipien des Kontext-Engineerings

Wir werden uns mit den folgenden Prinzipien beschäftigen:

1. Teile den Kontext
2. Aktionen tragen implizite Entscheidungen

Warum sollten wir über Prinzipien nachdenken? HTML wurde 1993 eingeführt. 2013 veröffentlichte Facebook React und es dominiert mittlerweile die Art und Weise, wie Entwickler Websites und Apps erstellen. Warum? Weil React nicht nur ein Gerüst zum Schreiben von Code ist, sondern eine Philosophie. Durch die Verwendung von React umarmt man den Aufbau von Anwendungen mit einem Muster der Reaktivität und Modularität, was mittlerweile als Standardanforderung akzeptiert wird.

Die Theorie des Aufbaus von langlaufenden Agenten

Beginnen wir mit der Zuverlässigkeit. Wenn Agenten tatsächlich zuverlässig arbeiten und über längere Zeiträume hinweg kohärente Gespräche führen müssen, gibt es bestimmte Dinge, die man tun muss, um das Potenzial für sich summierende Fehler zu begrenzen. An der Spitze der Zuverlässigkeit steht das Kontext-Engineering.

Was ist Kontext-Engineering?

Im Jahr 2025 sind die Modelle extrem intelligent. Aber selbst der intelligenteste Mensch kann seine Arbeit nicht effektiv erledigen, ohne den Kontext dessen, was von ihm verlangt wird. „Prompt Engineering“ war ein Begriff, der geprägt wurde, um den Aufwand zu beschreiben, der nötig ist, um eine Aufgabe im idealen Format für einen LLM-Chatbot zu formulieren. „Kontext-Engineering“ ist die nächste Stufe. Es geht darum, dies in einem dynamischen System automatisch zu tun.

Beispiel für einen Agenten

Ein typischer Agent zerlegt seine Arbeit in mehrere Teile, startet Subagenten, um an diesen Teilen zu arbeiten, und kombiniert schließlich die Ergebnisse. Diese Architektur ist verlockend, insbesondere wenn man in einem Aufgabenbereich mit mehreren parallelen Komponenten arbeitet. Sie ist jedoch sehr fragil.

Prinzip 1: Teile den Kontext

Wenn wir unseren Agenten erneut betrachten, stellen wir sicher, dass jeder Agent den Kontext der vorherigen Agenten hat. Wenn wir jedoch die gleiche Aufgabe „Baue einen Flappy Bird Klon“ geben, könnte es sein, dass Subagent 1 und Subagent 2 völlig unterschiedliche visuelle Stile haben, da sie nicht sehen können, was der andere tut.

Prinzip 2: Aktionen tragen implizite Entscheidungen

Ich würde argumentieren, dass die Prinzipien 1 und 2 so kritisch sind und so selten verletzt werden sollten, dass man standardmäßig alle Agentenarchitekturen ausschließen sollte, die diese nicht einhalten. Man könnte denken, dass dies einschränkend ist, aber es gibt tatsächlich einen weiten Raum für verschiedene Architekturen, die man für seinen Agenten erkunden kann.

Die Anwendung der Prinzipien

Wenn Sie ein Agentenbauer sind, stellen Sie sicher, dass jede Aktion Ihres Agenten durch den Kontext aller relevanten Entscheidungen anderer Teile des Systems informiert wird. Idealerweise sollte jede Aktion alles andere sehen. Leider ist dies aufgrund begrenzter Kontextfenster und praktischer Abwägungen nicht immer möglich.

Beispiele aus der Praxis

• Claude Code Subagenten: Claude Code ist ein Beispiel für einen Agenten, der Subtasks erstellt, jedoch niemals parallel mit dem Subtask-Agenten arbeitet.
• Edit Apply Modelle: Viele Modelle waren schlecht im Bearbeiten von Code. Ein gängiges Verfahren war, ein kleines Modell zu verwenden, um die gesamte Datei neu zu schreiben, anstatt ein großes Modell zu verwenden, um einen korrekt formatierten Diff auszugeben.
• Multi-Agenten: Der Gedanke, mehrere Agenten miteinander kommunizieren zu lassen, um Entscheidungen zu treffen, ist verlockend, aber in der Praxis führt dies oft zu fragilen Systemen.

Fazit

Diese Beobachtungen zum Kontext-Engineering sind nur der Anfang dessen, was wir eines Tages als Standardprinzipien für den Bau von Agenten betrachten könnten. Bei Cognition denken wir intensiv über den Agentenbau nach und entwickeln unsere internen Tools und Frameworks um diese Prinzipien herum.

Quellenliste:

• Quelle: DON’T BUILD MULTI-AGENTS
• OpenAI’s Swarm
• Microsoft’s Autogen