KI-Agenten: Wann ein Agent reicht und wann ein Team hilft

Mit 1 Agenten und besseren Tools beginnen: Das ist auch bei KI-Agenten der sinnvollste Ausgangspunkt. Multiagentensysteme lohnen sich, wenn einzelne Agenten unabhängig recherchieren, mit unterschiedlichem Kontext arbeiten oder klar getrennte Aufgaben verantworten können. Müssen sich Planung, Recherche, Programmierung und Prüfung dagegen ständig über dieselben Informationen abstimmen, entsteht schnell mehr Koordinationsaufwand als produktiver Fortschritt.

Entscheidend ist, ob ein Agent einen klaren Auftrag übernehmen, ohne ständige Rückfragen sinnvoll daran arbeiten und ein überprüfbares Ergebnis zurückliefern kann. Ist das nicht möglich, verlagert die Aufteilung die eigentliche Schwierigkeit meist nur in den Nachrichtenaustausch zwischen den Agenten.

Die im Folgenden beschriebenen Funktionen der Frameworks wurden am 26. Oktober 2026 anhand der aktuellen Herstellerdokumentation geprüft. Die Entscheidungstabelle überträgt diese dokumentierten Muster auf typische Entwicklungsaufgaben.

Was sind Multiagentensysteme?

In einem Multiagentensystem übernehmen eigenständige Agenten Teile einer größeren Aufgabe und tauschen ihre Arbeitsergebnisse aus. In einer Anwendung mit einem großen Sprachmodell (LLM) arbeitet ein Agent in einer Schleife: Er wählt Tools aus, prüft deren Ergebnisse und entscheidet über den nächsten Schritt. Mehrere Agenten stimmen diese Entscheidungen untereinander ab, statt sie einem einzigen Agenten zu überlassen. Der Überblick von IBM beschreibt die übergeordnete Struktur solcher miteinander interagierenden Agenten.

Die Agenten können dasselbe Modell verwenden. Eigenständig sind sie durch ihren Ausführungskontext und ihre Zuständigkeit, nicht durch unterschiedliche Modellnamen. Ein Rechercheagent erhält beispielsweise Quelldokumente und Suchwerkzeuge, während ein Programmieragent Zugriff auf das Repository und einen präzisen Änderungsauftrag bekommt.

Ein passender Vergleich ist ein Musikproduzent, der getrennt aufgenommene Spuren zusammenführt. Unabhängige Aufnahmen funktionieren, wenn sich die Musiker auf ein Arrangement geeinigt haben. Ändern alle laufend das Tempo und schreiben dieselbe Passage um, verbringt der Produzent die Sitzung damit, unvereinbare Aufnahmen aufeinander abzustimmen. Agententeams stehen vor derselben Wahl zwischen eigenständiger Arbeit und fortlaufender Abstimmung.

KI-Agenten im Team: Um welche Systeme geht es hier?

Das breitere Forschungsfeld umfasst auch Roboter, autonome Fahrzeuge und Simulationen, wie Google Cloud in seinem Überblick erläutert. Hier geht es um die Entscheidung, wie LLM-Agenten bei Recherche, Softwareentwicklung und betrieblichen Aufgaben zusammenarbeiten sollen.

Mehrere Modellaufrufe machen aus einer Anwendung noch kein Multiagentensystem. Ein Agent kann suchen, eine Datei lesen, Code schreiben und seine Arbeit prüfen, ohne dass dabei ein weiterer Agent beteiligt ist. Auch eine feste Abfolge von Prompts kann ein Workflow ohne autonome Akteure bleiben. Ausschlaggebend ist, wer Entscheidungen treffen darf und auf welchen Kontext diese Entscheidungen gestützt werden.

Wie Modellaufrufe, Tools und Abbruchbedingungen zusammenspielen, erklärt der Beitrag zum Agent Loop. Die übergeordnete Architektur von KI-Agenten braucht unabhängig von der Agentenzahl weiterhin eine Zustandsverwaltung, Berechtigungen und beobachtbare Ergebnisse.

KI-Agenten aufteilen: Die Aufgabe bestimmt die Architektur

Mehrere Agenten sind dann sinnvoll, wenn die Aufteilung mehr Komplexität beseitigt, als sie erzeugt. Eine sinnvolle Grenze trennt Belege, Fachwissen oder Zuständigkeiten. Eine rein kosmetische Grenze gibt lediglich dem nächsten Prompt eine Berufsbezeichnung.

Vor der Wahl eines Frameworks helfen diese Ausgangspunkte:

Für Gründer bedeutet das: Die erste Version eines Assistenten braucht kein Organigramm. Für Entwickler heißt es, die konkrete Abhängigkeit zu benennen, die einen Agenten am eigenständigen Weiterarbeiten hindert. Im Betrieb zählt der abgeschlossene Vorgang einschließlich der Korrekturarbeit, nicht die Zahl der beteiligten Spezialisten.

Die bekannte Aufteilung in Planer, Rechercheur, Programmierer und Prüfer beschreibt sinnvolle Tätigkeiten. Daraus folgt noch keine sinnvolle Aufteilung in getrennte Prozesse. Planung kann innerhalb des Programmieragenten stattfinden. Recherche kann ein Tool-Aufruf sein. Eine Prüfung kann mit Tests beginnen, die eindeutig bestehen oder fehlschlagen.

Angenommen, ein Rechnungsexport soll repariert werden. Hängt der Plan vom Datenbankschema ab und zeigt sich bei der Implementierung eine Ausnahme in diesem Schema, muss ein separater Planungsagent immer wieder neue Informationen erhalten. Dann sollten Planung und Umsetzung eng beieinanderbleiben. Ein unabhängiger Prüfer kann trotzdem helfen, wenn er den fertigen Patch, die Anforderungen an den Export und die relevanten Testergebnisse erhält.

Architekturmodelle für Multiagentensysteme

Die Muster unterscheiden sich vor allem darin, wer die Antwort verantwortet und wie viele Informationen zwischen den Agenten fließen. Supervisor, Hierarchie, Übergabe und Gruppenchat sind kombinierbare Organisationsformen, keine Produktkategorien, die einander ausschließen.

Supervisor oder Orchestrator-Worker: Ein Agent verantwortet das Ergebnis

LangGraph, eine Laufzeitumgebung für zustandsbehaftete Agenten-Workflows, unterstützt einen Supervisor, der klar abgegrenzte Aufgaben delegiert und die Ergebnisse zusammenführt. Die Verantwortung für das Ergebnis gegenüber dem Nutzer bleibt beim Supervisor; die ausführenden Agenten liefern Erkenntnisse oder Arbeitsergebnisse zurück.

Im aktuellen Supervisor-Tutorial von LangChain werden Kalender- und E-Mail-Agenten als übergeordnete Tools eingebunden. Der Supervisor ruft diese Tools auf und erhält die abschließenden Antworten der Spezialisten. Nicht jeder Zwischenschritt muss in seinem eigenen Gesprächsverlauf stehen.

Bei der Umsetzung ist eine Unterscheidung wichtig: Die Referenz zu langgraph-supervisor dokumentiert weiterhin create_supervisor, empfiehlt für die meisten Anwendungsfälle aber, das Supervisor-Muster direkt über Tools umzusetzen. So lässt sich genauer steuern, welchen Kontext die ausführenden Agenten erhalten und zurückgeben. Das Paket dokumentiert außerdem Supervisoren, die andere Supervisoren verwalten.

Dieses Muster eignet sich für einen Recherchebericht mit voneinander unabhängigen Fragen: Produktfunktionen untersuchen, technische Abhängigkeiten prüfen und Belege aus getrennten Quellenbeständen sammeln. Jeder Agent kann einen sinnvollen Teilauftrag abschließen, während der leitende Agent für die gemeinsame Antwort verantwortlich bleibt.

Die Grenze liegt beim Zusammenführen der Ergebnisse. Braucht jeder Agent laufend die neuesten Erkenntnisse aller anderen, wird der Supervisor zum Boten. Fehlende Belege kann er auch durch eine selbstsicher formulierte Gesamtdarstellung nicht ersetzen.

Hierarchische Teams: Delegation über leitende Agenten

CrewAI, ein Framework zur Koordination rollenbasierter Agenten, organisiert eine Crew anhand von Agenten, Aufgaben und einem Ausführungsprozess. Der hierarchische Prozess verwendet Process.hierarchical mit entweder manager_llm oder manager_agent. Der Manager verteilt die Arbeit, prüft die Ergebnisse und entscheidet, ob Aufgaben abgeschlossen sind.

Eine Hierarchie kann sich auf Manager erstrecken, die ganze Teams beaufsichtigen. Eine hierarchische Crew in CrewAI bedeutet für sich genommen aber noch keine tief verschachtelte Organisation. CrewAI unterstützt auch Process.sequential, bei dem Aufgaben in der festgelegten Reihenfolge ausgeführt werden. Das sind unterschiedliche Ausführungsmodelle, keine austauschbaren Bezeichnungen für Zusammenarbeit.

Ein Beispiel ist eine Produktbewertung mit einem Recherchebereich und einem Umsetzungsbereich. Eine Hierarchie ist plausibel, wenn beide Bereiche bereits schlüssige Zuständigkeiten haben und ein stabiles Arbeitsergebnis liefern. Weniger überzeugend ist sie, wenn die gesamte Aufgabe nur eine kurze Antwort verlangt und die Manager hauptsächlich die Anweisungen der anderen wiederholen.

Die Grenze liegt beim Verwaltungsaufwand. Jede Ebene muss den Auftrag verstehen und über ihr Ergebnis berichten. Eine zusätzliche Ebene ist dann gerechtfertigt, wenn die Arbeit tatsächlich eine Teamgrenze enthält, nicht schon deshalb, weil menschliche Unternehmen Abteilungen haben.

Handoffs: Ein Spezialist übernimmt

OpenAI Agents SDK, eine Codebibliothek zum Ausführen von Agenten und Tools, setzt Handoffs als Übergabe der Kontrolle an einen anderen Agenten um. Die Konfiguration handoffs listet die Zielagenten auf, an die ein Agent delegieren kann. Der übernehmende Spezialist verantwortet die nächste Antwort. Anders ist es beim Aufruf eines Spezialisten über as_tool(): Hier bleibt die Verantwortung für die Antwort beim Manager. Die Orchestrierungsdokumentation von OpenAI benennt diesen Unterschied ausdrücklich.

Der Unterschied zeigt sich in einem Supportgespräch. Muss ein Spezialist für Abrechnung Rückfragen stellen und ein Rechnungsproblem lösen, ist es sinnvoll, ihm das Gespräch zu übergeben. Braucht der Hauptassistent dagegen nur eine Abrechnungsberechnung für die Antwort auf eine umfassendere Frage, genügt möglicherweise ein Tool oder ein begrenzter Spezialistenaufruf.

Die Grenze liegt bei der Übergabe selbst. Der übernehmende Agent braucht die relevanten Fakten, offenen Fragen und Berechtigungen. Ein Handoff bedeutet weder automatisch, dass die bisherige Arbeit korrekt war, noch dass der Spezialist jede Aktion ausführen darf. Zugriffs- und Freigaberegeln muss der Anwendungscode durchsetzen.

Handoffs sind sinnvoll, wenn die Zuständigkeit wechseln soll. Dienen sie nur dazu, jeder Stufe eine andere Persona zu geben, entstehen zusätzliche Stellen, an denen Kontext verloren gehen kann.

Gruppenchat: Agenten arbeiten in einer gemeinsamen Diskussion

Microsoft Agent Framework, ein Framework für Agentenanwendungen und Workflows, setzt Gruppenchats mit einem Orchestrator um, der den nächsten Sprecher auswählt. Sein Python-GroupChatBuilder unterstützt eine Auswahlfunktion oder einen agentenbasierten Orchestrator sowie eine Abbruchbedingung. Die Teilnehmer haben getrennte Sitzungen, deren Gesprächsverläufe synchronisiert werden. Microsofts Dokumentation zum Gruppenchat erläutert den Mechanismus.

Das passt zu einem Vorschlag, der durch Austausch besser wird: Ein Autor überarbeitet den Entwurf, nachdem ein Prüfer eine fehlende Anforderung entdeckt hat. Anschließend prüft ein weiterer Spezialist die überarbeitete Argumentation. Anders als bei unabhängigen Recherchepfaden bauen spätere Beiträge hier bewusst auf früheren auf.

Die Grenze liegt beim wachsenden Gesprächsverlauf. Teilnehmer können ihre Beiträge darauf verwenden, über die Arbeit zu diskutieren, statt sie zu verändern. In der gemeinsamen Diskussion können sie zudem dieselbe falsche Ausgangsannahme übernehmen. Einigkeit in diesem Gespräch ist keine unabhängige Überprüfung.

Ein Gruppenchat braucht ein konkretes Arbeitsergebnis, das verbessert werden soll, ein eindeutiges Abnahmekriterium und eine Abbruchregel. Für Aufgaben mit einer klaren, festen Reihenfolge ist ein einfacher Workflow meist leichter zu verstehen.

Der Vergleich von Frameworks für KI-Agenten behandelt die weitergehende Wahl der technischen Umsetzung. Ist die Aufteilung begründet, erklärt der Beitrag zur Orchestrierung von KI-Agenten, wie Koordination, Zustand, Freigaben und betriebliche Steuerung zusammenspielen.

Beispiele für Multiagentensysteme: Wo sich die Aufteilung lohnt

Breit angelegte Recherche ist ein überzeugenderer Ausgangspunkt als die Bearbeitung eng voneinander abhängiger Inhalte. Das dokumentierte Research-System von Anthropic nutzt einen leitenden Agenten und parallel arbeitende Agenten, die unterschiedliche Richtungen untersuchen und ihre Erkenntnisse zurückliefern. In der veröffentlichten internen Evaluation übertraf ein leitender Claude Opus 4 mit Claude Sonnet 4 als Subagenten einen allein arbeitenden Claude Opus 4 um 90.2%. Das ist eine berichtete relative Verbesserung in dieser Recherche-Evaluation, keine Erfolgsquote von 90.2% und kein allgemeiner Leistungsgewinn durch zusätzliche Agenten. Der Vergleich verändert zudem die Anordnung der Modelle und den Rechenaufwand. Anthropics Entwicklungsbericht.

Bei der Bewertung von Integrationsmöglichkeiten wäre die entsprechende Aufgabe, die Dokumentation jedes Kandidaten unabhängig zu untersuchen und Belege zu denselben Anforderungen zurückzuliefern. Für die abschließende Entscheidung muss weiterhin jemand widersprüchliche Aussagen und Informationslücken klären. Parallele Recherche kann die verfügbare Beleglage erweitern; unvereinbare Belege bringt sie nicht automatisch in Einklang.

Bei der Programmierung sehen die Abhängigkeiten anders aus. Unabhängige Agenten könnten den Authentifizierungscode untersuchen, relevante Tests finden und das dokumentierte Verhalten einer Bibliothek recherchieren. Das sind begrenzte Untersuchungsaufträge. Mehrere Agenten gleichzeitig denselben Authentifizierungsablauf umschreiben zu lassen, ist wesentlich schwieriger, weil ihre Entscheidungen einander hinfällig machen können.

Im Kundensupport kann ein anderer Grund für die Aufteilung ausschlaggebend sein: Zuständigkeit. Ein allgemeiner Assistent erkennt das Problem, ein Spezialist übernimmt einen abgegrenzten Fachbereich. Der Nutzen entsteht durch die enger gefassten Anweisungen und Tools des Spezialisten, nicht durch ein längeres Gespräch.

Diese Programmier- und Supportszenarien sind Entwurfsbeispiele, keine dokumentierten Einsätze oder gemessenen Verbesserungen. Ihr Nutzen hängt davon ab, ob der zusätzliche Agent etwas leisten kann, das dem ursprünglichen Agenten mit einem besseren Tool oder einem präziser eingegrenzten Prompt nicht ebenso klar möglich wäre.

Warum scheitern Multiagentensysteme mit LLMs?

Sie können an den Schnittstellen scheitern, obwohl jeder Agent für sich kompetent wirkt. Mit jedem zusätzlichen Agenten kommen weitere Aufträge hinzu, die verstanden werden müssen, weitere Zwischenergebnisse, denen vertraut wird, und weitere Stellen, an denen sich die Bedeutung der ursprünglichen Anforderung verschieben kann.

Mehr Tokens und Wartezeiten zwischen abhängigen Schritten

Delegation erfordert Anweisungen, Kontext für die ausführenden Agenten, zurückgelieferte Ergebnisse und deren Zusammenführung. Wiederholte Versuche und gemeinsame Gesprächsverläufe verursachen weiteren Aufwand. Anthropic berichtet auf Grundlage eigener Daten, dass seine Multiagentensysteme etwa 15× so viele Tokens wie Chats verbrauchten. Die Vergleichsbasis sind Chats, keine Durchläufe mit einem einzelnen Agenten; daraus lässt sich kein allgemeiner Multiplikator für die Planung ableiten. Anthropics Angaben zum Tokenverbrauch.

Zusätzlicher Tokenverbrauch ist ein Risiko, das gemessen werden muss, kein Naturgesetz für jedes Multiagentensystem. Getrennte Kontexte können verhindern, dass irrelevantes Material immer wieder geladen wird. Entscheidend ist der Gesamtverbrauch bis zu einem akzeptierten Ergebnis, einschließlich gescheiterter Teilaufgaben und Nacharbeit.

Parallel arbeitende Agenten können die Gesamtdauer nur dort verkürzen, wo ihre Arbeit unabhängig ist. Muss erst die Recherche enden, bevor die Planung beginnen kann, und wartet anschließend die Programmierung auf den Plan, bleibt es eine Abhängigkeitskette. Andere Bezeichnungen für diese Schritte machen sie nicht gleichzeitig ausführbar.

Die Fehlersuche wird schwieriger

Die abschließende Antwort kann die erste falsche Entscheidung verdecken. Ein Programmieragent kann eine fehlerhafte Anforderung korrekt umsetzen, während ein Prüfer die Implementierung anhand derselben fehlerhaften Anforderung freigibt. Wer nur die letzte Antwort betrachtet, macht die falsche Komponente verantwortlich.

Anthropic berichtet, dass eine vollständige Ablaufverfolgung im Research-System dabei half, Fehler bei der Suche, der Quellenauswahl und der Tool-Nutzung auseinanderzuhalten. Der Bericht beschreibt auch, wie sich Fehler über zustandsbehaftete Agentendurchläufe hinweg verstärken. Erkenntnisse aus der Entwicklung.

Beim Architekturvergleich zählt deshalb, ob sich die früheste Abweichung vom Auftrag erkennen lässt: Welche Anweisungen erhielt der Agent, welche Belege lagen ihm vor, was lieferte er zurück, und was behandelte der nächste Agent als gesicherte Tatsache? Ohne Einblick in diese Übergänge lässt sich nicht beurteilen, ob ein zusätzlicher Prüfer das System verbessert oder lediglich eine beruhigende Abschlussmeldung ergänzt.

Fehler verstärken sich von Übergabe zu Übergabe

In einem hypothetischen Beispiel schreibt ein Rechercheagent: „Dieser Endpunkt scheint Exporte zu unterstützen, aber die erforderlichen Berechtigungen sind unklar.“ Ein Planungsagent verdichtet das zu: „Den Export-Endpunkt verwenden.“ Der Programmieragent setzt den Plan um. Ein Prüfer gleicht den Patch mit dem Plan ab und erkennt keine Abweichung.

Die ursprüngliche Unsicherheit ist verschwunden, ohne dass sie jemand geklärt hätte. Mehr Agenten waren beteiligt, doch keiner prüfte die fehlenden Belege.

Zur Zusammenfassung gehören deshalb Quellenverweise, ausdrücklich benannte Wissenslücken und das tatsächliche Arbeitsergebnis. Prüfer brauchen die ursprüngliche Anforderung, nicht nur die Darstellung des Erstellers. Das spricht für ein kleines, gut überprüfbares Team statt einer langen Kette vage beschriebener Rollen.

Was wird an Agententeams überschätzt?

Die Zahl der Rollen sagt wenig über die Leistungsfähigkeit aus. Mehr Agenten bringen nicht automatisch mehr Wissen, unabhängigere Urteile oder eine schnellere Ausführung. Entscheidend ist, welche zusätzliche Arbeit durch die Aufteilung überhaupt möglich wird.

Ein einzelner Agent kann Tools parallel aufrufen. Gleichzeitige Suchanfragen allein erfordern deshalb kein Team. Er kann bei Bedarf auch spezialisierte Anweisungen laden. LangChain dokumentiert ein Skills-Muster, bei dem ein Agent die Kontrolle behält und relevantes Wissen nach Bedarf hinzunimmt.

Getrennte Prompts sind außerdem nicht mit sicherheitstechnischer Isolation gleichzusetzen. Einen Agenten als Rechercheur und einen anderen als Freigabeinstanz zu bezeichnen, schränkt deren Zugriff noch nicht ein. Die Anwendung muss die vorgesehenen Tool-Berechtigungen und Freigabegrenzen durchsetzen.

Das stärkste Argument für mehrere Agenten ist meist konkret: Ein Agent braucht einen eigenen Kontext, kann eine Frage unabhängig untersuchen oder soll einen anderen Gesprächsbereich verantworten. „Es sieht aus wie ein Team“ reicht als Begründung nicht aus.

Der nächste praktische Schritt: Die kleinste sinnvolle Aufteilung vergleichen

Ein einzelner Agent bleibt die Vergleichsbasis; hinzu kommt nur der Agent, der eine erkennbare Schwäche behebt. Funktioniert das vorhandene System, schaffen zusätzliche Manager und Prüfer zunächst ein neues System, dessen Nutzen erst belegt werden muss.

1. 1

   Die Schwäche im bestehenden Workflow benennen

   Geeignet sind tatsächliche Aufgaben, bei denen der Agent Belege übersieht, falsche Tools auswählt, Anforderungen verliert oder ein unbrauchbares Arbeitsergebnis liefert. Fehlende Tools und unklare Anweisungen sollten behoben werden, bevor die Agentenzahl als Ursache gilt.

2. 2

   Eine klar begrenzte Alternative definieren

   Bei einem Programmierassistenten bleibt der Hauptagent für den Patch verantwortlich. Ein unabhängiger Prüfer kommt nur hinzu, wenn die Prüfung tatsächlich die Lücke ist. Festzulegen sind die Eingaben des Prüfers und die Belege, die er zurückliefern muss. Der gesamte Workflow sollte dabei nicht auf einmal umgebaut werden.

3. 3

   Akzeptierte Ergebnisse vergleichen

   Ausgangssystem und Alternative bearbeiten dieselben Aufgaben nach denselben Abnahmekriterien. Erfasst werden Ergebnisqualität, gesamter Tokenverbrauch, Gesamtdauer und der menschliche Aufwand für Fehlerdiagnose und Korrekturen. Unterschiede zwischen den Modellen müssen bei der Auswertung berücksichtigt werden.

4. 4

   Die Aufteilung beibehalten oder zurücknehmen

   Der zusätzliche Agent bleibt, wenn seine Verbesserung des Ergebnisses den betrieblichen Mehraufwand rechtfertigt. Wiederholt er hauptsächlich Kontext oder die Arbeit eines anderen Agenten, gehört diese Tätigkeit zurück in den ursprünglichen Agenten. Ohne gemessene Schwäche können Betreiber abwarten; für Entwickler mit unabhängigen Recherchepfaden gibt es einen klareren Grund, jetzt zu experimentieren.

Häufige Fragen zu Multiagentensystemen

Ist ChatGPT ein Multiagentensystem?

Der Name ChatGPT allein sagt nichts über die Architektur eines bestimmten Workflows aus. Eine Funktion lässt sich erst dann als Multiagentensystem einordnen, wenn getrennte Agenten dokumentiert sind, die Arbeit austauschen oder die Kontrolle übergeben. Eine Chatoberfläche, Tool-Nutzung oder eine lange Antwort reichen als Beleg nicht aus.

Was ist ein Beispiel für ein Multiagentensystem?

Das Research-System von Anthropic delegiert Untersuchungen an ausführende Agenten und führt deren Erkenntnisse zusammen. Es ist ein Beispiel für das Orchestrator-Worker-Muster.

Welches Multiagentensystem ist das beste?

Ein universell bestes System gibt es nicht. Das Muster muss zur Aufgabe passen: ein Supervisor für begrenzte Spezialistenaufträge, Handoffs für einen Wechsel der Gesprächsverantwortung und Gruppenchat für nützliche, wiederholte Kritik. Verbessert die Aufteilung das Ergebnis nicht, bleibt es bei einem Agenten.

Was sind die „Big 4“ der KI-Agenten?

Eine verbindliche Branchenliste namens „Big 4“ gibt es nicht. Planer, Rechercheur, Programmierer und Prüfer sind verbreitete Rollenbezeichnungen in vorgeschlagenen Agententeams, keine Pflichtbestandteile. Erst muss die Arbeit einer Rolle feststehen, bevor daraus ein eigener Agent wird.

Ist ChatGPT ein Agent oder ein LLM?

ChatGPT ist der Name einer Anwendung; LLM bezeichnet die zugrunde liegende Modellart. Ein Agent ist ein System, das mithilfe eines Modells Aktionen auswählt und auf Ergebnisse reagiert. Die Begriffe beschreiben unterschiedliche Ebenen. Entscheidend ist deshalb die konkrete Funktion; die Bezeichnungen sind nicht austauschbar.

Welche 7 Arten von KI-Agenten gibt es?

Listen mit sieben Einträgen vermischen unterschiedliche Einteilungen, etwa Entscheidungsregeln, Lernverhalten, Aufgabenrollen oder Formen der Zusammenarbeit. Es gibt keine feste siebenteilige Architektur, die umgesetzt werden müsste. Für die hier behandelte Entscheidung muss das Verhalten eines einzelnen Agenten von der Organisation mehrerer Agenten unterschieden werden.

Welche KI-Agenten sind am weitesten verbreitet?

Nützliche Kategorien für Unternehmen sind Supportassistenten, Rechercheagenten und Programmieragenten. Das sind Aufgabenkategorien, keine belegte Rangliste nach Verbreitung. Ihre Namen verraten nicht, ob sie allein, unter einem Supervisor oder mit Handoffs arbeiten.

Was sind konkrete Beispiele für KI-Agenten?

Beispiele sind ein Supportagent, der eine Bestellung nachschlägt und die nächste Aktion auswählt, ein Rechercheagent, der Quellen sucht und prüft, sowie ein Programmieragent, der Dateien bearbeitet und Tests ausführt. Jeder davon kann ein einzelner Agent sein, auch wenn er viele Schritte ausführt.

Welche 5 Arten von KI-Agenten gibt es?

IBM beschreibt eine klassische Einteilung in einfache reflexbasierte, modellbasierte reflexbasierte, zielbasierte, nutzenbasierte und lernende Agenten. Sie ordnet ein, wie ein Agent entscheidet oder lernt. Daraus ergibt sich keine Vorgabe dafür, wie viele LLM-Agenten eine Anwendung einsetzen sollte.

Für praktische Entscheidungen beim Entwickeln mit KI: den Newsletter abonnieren.