Multi-Agenten-Systeme – die neuen Microservices

Multi-Agenten-Systeme sind verlockend, aber nicht immer eine gewinnbringende Lösung.Rob Schultz / Shutterstock



Multi-Agenten-Systeme sind derzeit in aller Munde. Der Hype um dieses generell nützliche Pattern wird in vielen Fällen mit einer unausweichlichen Bestimmung gleichgesetzt. Wenn Sie jetzt ein Déjà-Vu-Gefühl beschleichen sollte, liegt das daran, dass es mit Microservices ganz genauso gelaufen ist.



Aus einigen guten (und auch schlechten) Gründen wurden funktionierende Anwendungen in eine verwirrende Cloud of Services zerlegt. Anschließend baute man Service Meshes, Tracing Stacks und Plattform-Teams auf – einfach nur, um die selbst kreierte Komplexität zu bewältigen. Natürlich boten Microservices auch einige echte Benefits. Aber eben eher für Konzerne wie Google mit den Problemen von Google.



Zurück in der Gegenwart sind wir nun gerade dabei, genau denselben Fehler in Zusammenhang mit Agentic AI – beziehungsweise Multi-Agent-Systemen – zu wiederholen: Keine Demo kommt heute scheinbar ohne Planungs-, Research-, Coding- und Review-Agenten aus. Multi-Agenten-Ansätze sind zwar nicht grundsätzlich eine schlechte Idee. Aber sie machen eben nicht in jedem Fall Sinn.



Die Hype-Steuer für Multi-Agenten-Systeme



Selbst die Unternehmen, die Frontier-Modelle entwickeln flehen Developer geradezu an, diese nicht wahllos einzusetzen. So empfiehlt etwa Anthropic in seinem Leitfaden zur Entwicklung effektiver KI-Agenten ausdrücklich, die Lösung zu identifizieren, die am einfachsten ist. Mehr Komplexität sollte demnach nur dann eingeführt werden, wenn es unbedingt nötig ist. Das könne laut dem KI-Anbieter auch darauf hinauslaufen, überhaupt keine agentischen Systeme aufzusetzen. Schließlich reiche es für viele Applikationen in der Regel aus, einzelne LLM-Calls mit Hilfe von Retrieval und kontextbezogenen Beispielen zu optimieren.



Informatiker und ML-Spezialist Santiago Valderrama drückt es im Rahmen eines LinkedIn-Posts noch etwas deutlicher aus: „Nicht alles ist ein Agent oder braucht ‚agentische‘ Fähigkeiten. In 99 Prozent aller Fälle reicht einfach nur normaler Code.“



OpenAI vertritt diesbezüglich einen ganz ähnlichen Standpunkt und rät in seinem Leitfaden dazu, zunächst die Fähigkeiten eines Agenten zu maximieren, weil das die Komplexität, Evaluierung und Wartung überschaubar gestalte. Der KI-Pionier empfiehlt in diesem Zusammenhang, auf Prompt-Templates zurückzugreifen. Das sei dazu geeignet, Komplexität in Schach zu halten – ganz ohne ein Multi-Agenten-Framework.



Und auch Microsoft hat eine klare Meinung zum Thema: Wenn der Anwendungsfall nicht eindeutig Sicherheits- oder Compliance-Grenzen überschreitet, mehrere Teams einbezieht oder anderweitig eine architektonische Trennung erfordert, legen die Redmonder nahe, mit einem singulären Prototyp-Agenten zu beginnen. Verschiedene Rollen würden demnach nicht automatisch mehrere Agenten rechtfertigen. Das sei auch mit einem einzelnen Agenten abzubilden, der durch bedingte Prompts und Tool-Berechtigungen verschiedene Rollen einnehmen kann. 



Microsoft weist zudem auf einen weiteren Punkt hin, der besondere Beachtung verdient: Viele offensichtliche Skalierungsprobleme sind dem Retrieval-Design geschuldet, nicht der Architektur. Bevor Sie also weitere KI-Agenten hinzufügen, sollten Sie zusehen, dass andere Dinge optimal laufen. Etwa:




Chunking,



Indizierung,



Reranking,



Prompt-Struktur und



Kontext-Selektion.




Komplexität verschwindet nicht, wenn man ein System zerlegt. Sie verlagert sich. Das haben wir im Fall von Microservices auf die harte Tour gelernt: Damals wanderte die Komplexität ins Netzwerk – nun droht sie, sich auf Hand-Offs, Prompts, Arbitration und den State von Agenten zu verlagern. Bei echten, verteilten Problemen machen Multi-Agenten-Systeme Sinn. Wenn ein solches Problem nicht existiert, nicht. Verteilte Intelligenz ist schließlich immer noch ein Distributed System – und ein solches ist weder günstig zu entwickeln noch zu warten.



Meiner Meinung nach haben die meisten Teams, die glauben, Multi-Agenten-Systeme einsetzen zu müssen, eigentlich ganz andere Probleme:




Ihre Tools sind vage,



ihre Suchfunktionen schwachbrüstig,



Berechtigungen zu weit gefasst, und



Repositories unzureichend dokumentiert.




Mehr Agenten hinzuzufügen, behebt keines dieser Probleme, sondern verschlimmert diese noch. Laut Anthropic nutzen die erfolgreichsten Implementierungen in der Regel einfache, kombinierbare Pattern statt komplexe Frameworks.



In der Microservices-Ära wurde die Ausbreitung schlechter Architekturideen zumindest noch durch den Aufwand eingeschränkt, der nötig war, um diese umzusetzen. Im Agentic-AI-Zeitalter sinken hingegen die Kosten für die Entwicklung einer weiteren Orchestrierungsschicht oder einer weiteren spezialisierten Rolle rapide. Das kann befreiend wirken, auch wenn es unsere Fähigkeit zerstört, Systeme langfristig zu warten und zu managen. Aber niedrigere Produktionskosten führen eben nicht automatisch zu höherer Produktivität. Oft machen sie es lediglich einfacher, Fragilität zu skalieren.



Wie Unternehmen vorgehen sollten



Das bringt uns zurück zu einem Punkt, den ich seit Jahren in Bezug auf Hyperscaler-Architekturen anspreche: Nur weil Google, Amazon, Anthropic oder OpenAI etwas tun, heißt das nicht, dass Sie genauso verfahren sollten. Denn mit an Sicherheit grenzender Wahrscheinlichkeit, haben Sie nicht deren Probleme. Also sollten Sie sich nicht nur die mit Multi-Agenten-Systemen verbundene Komplexität, sondern auch die Kosten sparen. Laut Anthropic verbraucht ein Multi-Agenten-System etwa 15-mal so viele Token wie ein einzelner KI-Agent (der seinerseits etwa viermal mehr Token braucht als eine Chat-Interaktion).



Deshalb empfehle ich Unternehmen, bei der Entscheidung über (Multi-)Agenten-Systeme mit folgender Frage zu starten: Was ist die minimal erforderliche Autonomie für diese Aufgabe? Geht es um die Umsetzung, starten Sie idealerweise mit einem starken Modell-Call. Reicht das nicht, fügen Sie (sukzessive) Retrieval-Funktionen, bessere Tools, oder Agenten-Loops hinzu. Sollten voneinander unabhängige Tasks wirklich parallel laufen können, eine Spezialisierung die Tool-Auswahl wesentlich optimieren können oder es tatsächlich zu „Context Pollution“ kommen, dann – und nur dann – haben Sie sich einen weiteren Agenten „verdient“. (fm)