Entwicklung von Multiagenten-Systemen: wann und wie man sie verwendet

Was ist ein Multiagentensystem?

Ein Multiagentensystem ist eine Architektur, bei der mehrere LLM-Instanzen mit getrennten Konversationskontexten ausgeführt werden und über Code koordiniert werden. Jeder Agent bearbeitet einen anderen Teil einer Aufgabe – ein Subagent recherchiert beispielsweise, während ein Orchestrator plant –, wodurch der Kontext geschützt bleibt, parallel gearbeitet werden kann und auch auf spezifische Dinge eingegangen werden kann. Das könnte ein einzelner Agent nicht leisten.

Es gibt zwar mehrere Koordinationsmuster (Agent-Swarms, fähigkeitsbasierte Systeme und Message-Bus-Architekturen), aber dieser Artikel konzentriert sich auf das Orchestrator-Subagenten-Muster: ein hierarchisches Modell, bei dem ein Lead-Agent spezialisierte Subagenten für bestimmte Teilaufgaben erzeugt und verwaltet. Dieses Muster bietet ein unkompliziertes Koordinationsmodell und ist ein guter Ausgangspunkt für Teams, die noch wenig Erfahrung mit Multiagenten-Systemen haben. In unserem nächsten Artikel werden wir uns ausführlich mit weiteren Mustern beschäftigen.

Heutzutage werden Multiagentensysteme oft in Situationen angewendet, in denen ein einzelner Agent bessere Leistungen erbringen würde, obwohl sich diese Berechnung mit der Verbesserung der Modelle ständig weiterentwickelt. Bei Anthropic haben wir gesehen, dass Teams viele Monate in die Entwicklung komplexer Multiagenten-Architekturen investiert haben, nur um festzustellen, dass verbessertes Prompting auf einem einzelnen Agenten dieselben Ergebnisse erzielte.

Nach der Entwicklung von Multiagenten-Systemen und der Arbeit mit Teams, die diese im Produktivbetrieb einsetzen, haben wir drei Situationen identifiziert, in denen mehrere Agenten durchgehend besser abschneiden als ein einzelner Agent: wenn Kontextverschmutzung die Leistung verschlechtert, wenn Aufgaben parallel ausgeführt werden können und wenn eine Spezialisierung die Toolauswahl oder den Aufgabenfokus verbessert. Bei allen anderen Szenarien übersteigen die Koordinationskosten in der Regel die Vorteile.

In diesem Artikel erklären wir, wie die Grenzen von Einzelagenten erkannt sowie die drei Szenarien identifiziert werden, in denen Multiagentensysteme sich auszeichnen, sowie sich häufige Implementierungsfehler vermeiden lassen.

Warum man mit einem einzelnen Agenten beginnt

Ein gut konzipierter einzelner Agent kann mit den entsprechenden Tools weit mehr erreichen, als viele Entwickler erwarten.

Multiagentensysteme verursachen Mehraufwand. Jeder zusätzliche Agent stellt einen weiteren potenziellen Fehlerpunkt dar, eine weitere Reihe von zu pflegenden Prompts und eine weitere Quelle für unerwartetes Verhalten.

Wir haben gesehen, dass Teams aufwendige Multiagenten-Systeme mit separaten Agenten für Planung, Ausführung, Überprüfung und Iteration erstellen, nur um festzustellen, dass bei jeder Übergabe Kontext verloren ging und mehr Tokens für die Koordination als für die Ausführung aufgewendet wurden. Bei unseren Tests verwenden Multiagenten-Implementierungen für gleichwertige Aufgaben normalerweise 3- bis 10-mal mehr Tokens als Single-Agent-Ansätze. Dieser Maehraufwand resultiert aus der Duplizierung von Kontext in den verschiedenen Agenten, den Koordinationsnachrichten zwischen Agenten und der Zusammenfassung der Ergebnisse zur weiteren Bearbeitung.

Ein Entscheidungsrahmen für Systeme mit mehreren Agenten

Multiagent-Architekturen bieten einen Mehrwert, wenn sie bestimmte Einschränkungen adressieren, die ein einzelner Agent nicht überwinden kann. Das bedeutet, dass Multiagent-Architekturen für Fälle reserviert sein sollten, in denen sie klare Vorteile bieten, die die zusätzlichen Kosten rechtfertigen. Eine verwaltete Infrastruktur kann es genauso für Sie erledigen (siehe Multiagentenorchestrierung in Claude Managed Agents).

Die folgenden Muster zeigen Fälle, in denen wir durchweg positive Renditen für diese Investition beobachten.

Schonung des Kontextfensters

Große Sprachmodelle haben endliche Kontextfenster, und die Antwortqualität kann sich mit zunehmendem Kontext verschlechtern. Wenn sich im Kontext eines Agenten Informationen aus einer Teilaufgabe ansammeln, die für die nachfolgenden Teilaufgaben irrelevant sind, kommt es zu Kontextverschmutzung. Subagenten bieten Isolation, da jeder in einem eigenen, sauberen Kontext arbeitet und sich auf seine spezifische Aufgabe konzentriert.

Stellen Sie sich einen Kundensupport-Mitarbeiter vor, der den Bestellverlauf abrufen und gleichzeitig technische Probleme bearbeiten muss. Wenn jede Auftragsabfrage dem Kontext Tausende von Tokens hinzufügt, verschlechtert sich die Fähigkeit des Agenten, über das technische Problem nachzudenken.

‍

Der Einzelagentansatz:

# Single agent accumulates everything in context
conversation_history = [
    {"role": "user", "content": "My order #12345 isn't working"},
    {"role": "assistant", "content": "Let me check your order..."},
    # Tool result adds 2000+ tokens of order history
    {"role": "user", "content": "... (order details, past purchases, shipping info) ..."},
    {"role": "assistant", "content": "Now let me diagnose the technical issue..."},
    # Context is now polluted with order details the agent doesn't need
]

Der Agent muss über das technische Problem nachdenken und dabei über 2000 Tokens des irrelevanten Bestellverlaufs im Kontext behalten, was die Aufmerksamkeit verwässert und die Antwortqualität beeinträchtigt.

‍

Der Multiagentansatz:

from anthropic import Anthropic

client = Anthropic()

class OrderLookupAgent:
    def lookup_order(self, order_id: str) -> dict:
        # Separate agent with its own context
        messages = [
            {"role": "user", "content": f"Get essential details for order {order_id}"}
        ]
        response = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            messages=messages,
            tools=[get_order_details_tool]
        )
        # Returns only essential information
        return extract_summary(response)

class SupportAgent:
    def handle_issue(self, user_message: str):
        if needs_order_info(user_message):
            order_id = extract_order_id(user_message)
            # Get only what's needed, not full history
            order_summary = OrderLookupAgent().lookup_order(order_id)
            # Inject compact summary, not full context
            context = f"Order {order_id}: {order_summary['status']}, purchased {order_summary['date']}"
        
        # Main agent context stays clean
        messages = [
            {"role": "user", "content": f"{context}\n\nUser issue: {user_message}"}
        ]
        response = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=2048,
            messages=messages
        )
        return response

Der Agent für die Auftragsabfrage verarbeitet die gesamte Auftragshistorie und extrahiert eine Zusammenfassung. Der Hauptagent erhält nur die 50 bis 100 Tokens, die er tatsächlich benötigt, wodurch der Kontextfenster „sauber“ bleibt.

Die Kontextabgrenzung ist am effektivsten, wenn Teilaufgaben ein hohes Kontextvolumen generieren (mehr als 1000 Tokens), die meisten dieser Informationen jedoch für die Hauptaufgabe irrelevant sind, wenn die Teilaufgabe genau definiert ist und klare Kriterien dafür hat, welche Informationen extrahiert werden sollen, und bei Such- oder Abrufvorgängen, die vor ihrer Verwendung gefiltert werden müssen.

Parallelisierung

Wenn Sie mehrere Agenten parallel ausführen, können Sie einen größeren Suchbereich abdecken, als ein einzelner Agent dies machen kann. Dieses Muster hat sich für Such- und Rechercheaufgaben als besonders wertvoll erwiesen.

Das Rechercheteam von Anthropic hat es in So haben wir unser Recherchesystem mit mehreren Agenten aufgebaut festgehalten. Ein Lead-Agent analysiert eine Abfrage und generiert mehrere Subagenten, um verschiedene Facetten parallel zu untersuchen. Jeder Subagent sucht unabhängig voneinander und gibt dann die destillierten Ergebnisse zurück. Die Multiagentensuche hat die Genauigkeit gegenüber Ansätzen mit Einzelagenten deutlich verbessert, da sie die Suche in größeren Informationsbereichen ermöglicht.

Die Kernimplementierung zerlegt eine Frage in separate Teilbereiche, führt Subagenten gleichzeitig aus und synthetisiert die Ergebnisse.

import asyncio
from anthropic import AsyncAnthropic

client = AsyncAnthropic()

async def research_topic(query: str) -> dict:
    # Lead agent breaks query into research facets
    facets = await lead_agent.decompose_query(query)
    
    # Spawn subagents to research each facet in parallel
    tasks = [
        research_subagent(facet) 
        for facet in facets
    ]
    results = await asyncio.gather(*tasks)
    
    # Lead agent synthesizes findings
    return await lead_agent.synthesize(results)

async def research_subagent(facet: str) -> dict:
    """Each subagent has its own context window"""
    messages = [
        {"role": "user", "content": f"Research: {facet}"}
    ]
    response = await client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=4096,
        messages=messages,
        tools=[web_search, read_document]
    )
    return extract_findings(response)

Doch diese verbesserte Abdeckung hat einen Preis. Multiagenten-Systeme verbrauchen für vergleichbare Aufgaben in der Regel 3- bis 10-mal mehr Tokens als Single-Agenten-Ansätze. Dies liegt daran, dass jeder Agent seinen eigenen Kontext benötigt, Agenten Nachrichten austauschen müssen, um sich zu koordinieren, und die Ergebnisse zusammengefasst werden müssen, wenn sie zwischen Agenten weitergegeben werden. Während Parallelität die Gesamtausführungszeit im Vergleich zur sequentiellen Ausführung aller Aufgaben reduziert, benötigen Multiagenten-Systeme oft mehr Zeit als Einzelagenten-Systeme, da der Gesamtrechenaufwand enorm zunimmt.

Der Hauptvorteil der Parallelisierung ist die Gründlichkeit, nicht die Geschwindigkeit. Wenn Sie einen großen Informationsbereich durchsuchen oder eine komplexe Frage aus vielen Blickwinkeln untersuchen müssen, können parallele Agenten mehr abdecken als ein einzelner Agent innerhalb seiner Kontextgrenzen. Der Kompromiss ist eine höhere Token-Nutzung und oft eine längere Gesamtausführungszeit im Austausch für umfassendere Ergebnisse.

Spezialisierung

Unterschiedliche Aufgaben profitieren manchmal von unterschiedlichen Tool-Sets, Systemprompts oder Fachgebieten. Anstatt einem einzelnen Agenten Zugriff auf Dutzende von Tools zu geben, können spezialisierte Agenten mit fokussierten Toolsets, die auf ihre Aufgaben zugeschnitten sind, die Zuverlässigkeit verbessern.

Spezialisierung auf ein Toolset

Wenn ein Agent Zugriff auf zu viele Tools hat, leidet die Leistung. Drei Signale deuten darauf hin, dass eine Tool-Spezialisierung hilfreich wäre:

1. Menge. Ein Agent mit zu vielen Tools (oft über 20) hat Schwierigkeiten, das richtige Tool auszuwählen.
2. Verwirrung bei den Domains. Wenn Tools mehrere nicht zusammenhängende Bereiche abdecken (Datenbankvorgänge, API-Aufrufe, Dateisystemvorgänge), verwechselt der Agent, welche Domain für eine bestimmte Aufgabe gilt.
3. Schlechtere Performance. Das Hinzufügen neuer Tools verschlechtert die Leistung bei vorhandenen Aufgaben, was darauf hindeutet, dass der Agent seine Kapazität für die Tool-Verwaltung bereits erreicht hat.

Spezialisierung bei Systemprompts

Verschiedene Aufgaben erfordern manchmal verschiedene Personas, Einschränkungen oder Anweisungen, die in Konflikt geraten, wenn sie kombiniert werden. Ein Kundensupport-Agent muss einfühlsam und geduldig sein; ein Code-Review-Agent muss präzise und kritisch sein. Ein Compliance-Überprüfungs-Agent muss starren Regeln folgen; ein Brainstorming-Agent braucht kreative Flexibilität. Wenn ein einzelner Agent zwischen widersprüchlichen Verhaltensmodi wechseln muss, führt die Aufteilung in spezialisierte Agenten mit maßgeschneiderten System-Prompts zu konsistenteren Ergebnissen.

Jeder spezialisierte Agent ist nur so gut wie seine Anweisungen – dieselben Best Practices für das Prompt-Engineering, die die Ergebnisse eines Einzelagenten verbessern, gelten auch für das Systemprompt jedes Subagenten.

Spezialisierung auf Fachwissen

Einige Aufgaben profitieren von einem tiefgehenden Fachwissen, der einen generalistischen Agenten überfordern würde. Ein Rechtsanalyse-Agent benötigt umfangreiches Know-how über die Rechtsprechung und regulatorische Rahmenbedingungen. Ein Agent für medizinische Forschung benötigt möglicherweise spezielle Kenntnisse über die Methodik klinischer Studien. Anstatt das gesamte Fachwissen einen einzelnen Agenten zu laden, können spezialisierte Agenten gezielte Expertise mitbringen, das für ihre spezifischen Verantwortlichkeiten relevant ist.

Beispiel: Integration über mehrere Plattformen hinweg. Stellen Sie sich ein Integrationssystem vor, bei dem Agenten über CRM-, Marketingautomatisierungs- und Messaging-Plattformen hinweg arbeiten müssen. Jede Plattform hat 10 bis 15 relevante API-Endpunkte. Ein einzelner Agent mit über 40 Tools tut sich mit der Auswahl schwer und verwechselt ähnliche Vorgänge auf verschiedenen Plattformen. Die Aufteilung in spezialisierte Agenten mit fokussierten Tools und maßgeschneiderten Prompts behebt diese Auswahlfehler.

from anthropic import Anthropic

client = Anthropic()

# Specialized agents with focused toolsets and tailored prompts
class CRMAgent:
    """Handles customer relationship management operations"""
    system_prompt = """You are a CRM specialist. You manage contacts, 
    opportunities, and account records. Always verify record ownership 
    before updates and maintain data integrity across related records."""
    tools = [
        crm_get_contacts,
        crm_create_opportunity,
        # 8-10 CRM-specific tools
    ]

class MarketingAgent:
    """Handles marketing automation operations"""
    system_prompt = """You are a marketing automation specialist. You 
    manage campaigns, lead scoring, and email sequences. Prioritize 
    data hygiene and respect contact preferences."""
    tools = [
        marketing_get_campaigns,
        marketing_create_lead,
        # 8-10 marketing-specific tools
    ]

class OrchestratorAgent:
    """Routes requests to specialized agents"""
    def execute(self, user_request: str):
        response = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            system="""You coordinate platform integrations. Route requests to the appropriate specialist:
- CRM: Contact records, opportunities, accounts, sales pipeline
- Marketing: Campaigns, lead nurturing, email sequences, scoring
- Messaging: Notifications, alerts, team communication""",
            messages=[
                {"role": "user", "content": user_request}
            ],
            tools=[delegate_to_crm, delegate_to_marketing, delegate_to_messaging]
        )
        return response

Dieses Muster spiegelt die effektive professionelle Zusammenarbeit wider, bei der Spezialisten mit ihren rollenbezogenen Tools effektiver zusammenarbeiten als Generalisten, die versuchen, ihr Know-how in allen Bereichen zu bewahren. Die Spezialisierung führt jedoch zu einer höheren Komplexität beim Routing. Der Orchestrator muss Anfragen korrekt klassifizieren und an den richtigen Agenten delegieren, und eine falsche Weiterleitung führt zu schlechten Ergebnissen. Die Wartung mehrerer spezialisierter Agenten erhöht außerdem den Aufwand hinsichtlich der Prompt-Wartung. Spezialisierung funktioniert am besten, wenn Fachbereiche klar trennbar sind und Routing-Entscheidungen eindeutig sind.

Single-Agent-Architekturen hinter sich lassen

Über den allgemeinen Rahmen hinaus gibt es bestimmte konkrete Signale, die darauf hindeuten, dass Einzelagenten nicht mehr ausreichen:

Annäherung an Kontextlimits. Wenn ein Agent routinemäßig viel Kontext verwendet und die Leistung nachlässt, kann der Kontextdruck zum Engpass werden. Beachten Sie, dass dank der jüngsten Fortschritte im Kontextmanagement (z. B. Komprimierung) diese Einschränkung verringert werden konnte, sodass Einzelagenten über einen viel längeren Zeitraum hinweg ein effektives Gedächtnis beibehalten können.

Verwaltung vieler Tools. Wenn ein Agent 15 bis 20 oder mehr Tools hat, verwendet das Modell viel Kontext und Aufmerksamkeit darauf, diese auszuwählen. Bevor Sie eine Multiagentenarchitektur einführen, sollten Sie das Tool Search Tool verwenden, mit dem Claude Tools bei Bedarf dynamisch durchforsten kann, anstatt alle Definitionen im Voraus laden zu müssen. Dadurch kann die Tokennutzung um bis zu 85 % reduziert und gleichzeitig die Genauigkeit bei der Toolauswahl verbessert werden.

Parallelisierbare Teilaufgaben. Wenn sich Aufgaben auf natürliche Weise in unabhängige Teile zerlegen lassen (Recherche über mehrere Quellen hinweg, Tests für mehrere Komponenten), können parallele Subagenten erhebliche Beschleunigungen erzielen.

Diese Schwellenwerte werden sich mit Verbesserungen bei den Modellen verschieben. Die aktuellen Grenzen stellen praktische Richtlinien dar, keine grundlegenden Einschränkungen.

Kontext-zentrierte Dekomposition

Bei der Einführung einer Architektur mit mehreren Agenten ist die wichtigste Designentscheidung, wie die Arbeit auf die Agenten verteilt wird. Wir haben festgestellt, dass Teams diese Entscheidung häufig falsch treffen, was zu einem Koordinationsaufwand führt, der die Vorteile eines Multiagenten-Designs zunichte macht.

Die wichtigste Erkenntnis ist, bei der Zerlegung von Arbeitsabläufen eine kontextzentrierte statt einer problemzentrierten Sichtweise einzunehmen.

Problemzentrierte Zerlegung (oft kontraproduktiv). Die Aufteilung nach Art der Arbeit (ein Agent schreibt Funktionen, ein anderer schreibt Tests, ein Dritter überprüft Code) verursacht einen ständigen Koordinationsaufwand. Bei jeder Übergabe verliert man den Kontext. Der Agent für das Testschreiben weiß nicht, warum bestimmte Implementierungsentscheidungen getroffen wurden, und dem Code-Prüfer fehlt der Kontext der Exploration und Iteration.

Kontextbezogene Zerlegung (normalerweise effektiv). Die Aufteilung nach Kontextgrenzen bedeutet, dass ein Agent, der ein Feature bearbeitet, dieses auch testen sollte, da er bereits über den erforderlichen Kontext verfügt. Arbeit sollte nur dann aufgeteilt werden, wenn der Kontext wirklich isoliert werden kann.

Dieses Prinzip ergibt sich aus der Beobachtung von Fehlermodi in Multi-Agenten-Systemen. Wenn Agenten nach Problemtyp eingeteilt werden, spielen sie ein „Telefonspiel“, bei dem sie Informationen hin- und herverschieben, wobei jede Übergabe die Genauigkeit verschlechtert. In einem Experiment mit Agenten, die auf die Rolle in der Softwareentwicklung spezialisiert waren (Planer, Implementierer, Tester, Prüfer), gaben die Subagenten mehr Tokens für die Koordination als für die eigentliche Arbeit aus.

Sinn macht die Zerlegung u. a. bei:

• Unabhängigen Recherchepfade. Die Untersuchung von „Markttrends in Asien“ versus „Markttrends in Europa“ kann parallel ohne gemeinsamen Kontext durchgeführt werden.
• Separaten Komponenten mit sauberen Schnittstellen. Mit einem klar definierten API-Vertrag können die Arbeiten an Frontend und Backend parallel erfolgen.
• Verifizierung der Blackbox. Ein Prüfer, der nur Tests ausführen und die Ergebnisse melden muss, benötigt keinen Implementierungskontext.

Problematisch wird die Zerlegung u. a. bei:

• Sequenziellen Phasen derselben Arbeit. Planung, Implementierung und Tests derselben Funktion teilen zu viel Kontext.
• Eng gekoppelten Komponenten. Komponenten, die ein ständiges Hin und Her erfordern, gehören in denselben Agenten.
• Arbeitspozessen mit einem gemeinsamen Status. Agenten, die ihr Verständnis häufig synchronisieren müssen, sollten zusammenbleiben.

Das Überprüfungs-Subagenten-Muster

Ein Multiagentenmuster, das bereichsübergreifend konstant gut funktioniert, ist der Überprüfungssubagent. Dies ist ein dedizierter Agent, der ausschließlich für das Testen oder Validieren der Arbeit des Hauptagenten verantwortlich ist.

Es ist erwähnenswert, dass immer leistungsfähigere Orchestrierungsmodelle (wie Claude Opus 4.5) die Arbeit von Subagenten direkt und ohne gesonderten Verifizierungsschritt bewerten können. Verifizierungssubagenten bleiben jedoch wertvoll, wenn Sie weniger fähige Orchestrierer verwenden, wenn die Überprüfung spezielle Tools erfordert oder wenn Sie explizite Überprüfungs-Checkpoints in Ihrem Workflow durchsetzen möchten.

Überprüfungs-Subagenten sind erfolgreich, weil sie das Problem mit dem Telefonspiel umgehen. Die Überprüfung erfordert naturgemäß nur minimale Kontextübertragung. Ein Prüfer kann ein System einem Blackbox-Test unterziehen, ohne den vollständigen Verlauf seiner Erstellung zu benötigen.

Implementierung eines Multiagentensystems

Der Hauptagent erledigt eine Aufgabe. Bevor er fortfährt, erzeugt er einen Überprüfungs-Subagenten mit dem zu überprüfenden Artefakt, klaren Erfolgskriterien und Tools für die Überprüfung.

Der Prüfer muss nicht verstehen, warum das Artefakt so gebaut wurde, wie es gebaut wurde. Es muss nur ermitteln, ob das Artefakt die angegebenen Kriterien erfüllt.

from anthropic import Anthropic

client = Anthropic()

class CodingAgent:
    def implement_feature(self, requirements: str) -> dict:
        """Main agent implements the feature"""
        messages = [
            {"role": "user", "content": f"Implement: {requirements}"}
        ]
        response = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=4096,
            messages=messages,
            tools=[read_file, write_file, list_directory]
        )
        return {
            "code": response.content,
            "files_changed": extract_files(response)
        }

class VerificationAgent:
    def verify_implementation(self, requirements: str, files_changed: list) -> dict:
        """Separate agent verifies the work"""
        messages = [
            {"role": "user", "content": f"""
Requirements: {requirements}
Files changed: {files_changed}

Run the test suite and verify:
1. All existing tests pass
2. New functionality works as specified
3. No obvious errors or security issues

You MUST run the complete test suite before marking as passed.
Do not mark as passing after only running a few tests.
Run: pytest --verbose
Only mark as PASSED if ALL tests pass with no failures.
"""}
        ]
        response = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=4096,
            messages=messages,
            tools=[run_tests, execute_code, read_file]
        )
        return {
            "passed": extract_pass_fail(response),
            "issues": extract_issues(response)
        }

def implement_with_verification(requirements: str, max_attempts: int = 3):
    for attempt in range(max_attempts):
        result = CodingAgent().implement_feature(requirements)
        verification = VerificationAgent().verify_implementation(
            requirements,
            result['files_changed']
        )
        
        if verification['passed']:
            return result
        
        requirements += f"\n\nPrevious attempt failed: {verification['issues']}"
    
    raise Exception(f"Failed verification after {max_attempts} attempts")

Anwendungen für Multiagentensysteme

Verifizierungs-Subagenten sind effektiv bei:

• Qualitätssicherung. Ausführung von Test-Suites, Linting von Code und Validierung der Ausgaben anhand von Schemata.
• Compliance-Prüfung. Überprüfung, ob Dokumente die Richtlinienanforderungen erfüllen, Prüfung der Ausgaben anhand von Regeln.
• Ausgabevalidierung. Bestätigung, dass generierte Inhalte vor der Bereitstellung den Spezifikationen entsprechen.
• Überprüfung von Fakten. Behauptungen oder Zitate in generierten Inhalten durch einen separaten Agenten überprüfen lassen.

Das Problem des frühen Erfolgs

Der wichtigste Ausfallmodus für Verifizierungssubagenten ist das Markieren von Ausgaben als bestanden, ohne gründliche Tests durchzuführen. Der Prüfer führt ein oder zwei Tests durch, beobachtet deren Bestehen und deklariert den Erfolg.

Zu den Risikominimierungsstrategien gehören:

• Konkrete Kriterien. Nutzen Sie lieber „Führe die gesamte Testsuite aus und melde alle Fehler“ als „Sorg dafür, dass es funktioniert“.
• Umfassende Prüfungen. Der Prüfer sollte mehrere Szenarien und Randfälle testen.
• Negative Tests. Weisen Sie den Prüfer an, Eingaben auszuprobieren, die fehlschlagen sollen, und dies zu bestätigen.
• Explizite Anweisungen. Die Anweisung „Du MUSST die gesamte Testsuite ausführen, bevor du sie als bestanden markierst“ ist wichtig. Ohne explizite Anforderungen an eine umfassende Validierung nehmen Verifizierungsagenten Abkürzungen.

Die Entscheidung zwischen Einzelagenten- und Multiagentensystemen

Multiagenten-Systeme sind leistungsstark, aber nicht universell einsetzbar. Bevor Sie die Komplexität mehrerer koordinierter Agenten hinzufügen, überprüfen Sie folgende Aspekte:

1. Es gibt echte Einschränkungen, die Multiagenten lösen, wie Kontextlimits, Parallelisierungsmöglichkeiten oder Spezialisierungsbedarf.
2. Die Zerlegung richtet sich nach dem Kontext, nicht nach der Art des Problems. Gruppieren Sie die Arbeit nach dem erforderlichen Kontext, nicht nach der Art der Arbeit.
3. Es gibt klare Überprüfungspunkte, anhand derer Subagenten Arbeit validieren können, ohne den vollständigen Kontext zu benötigen.

Unser Rat? Beginnen Sie mit dem einfachsten Ansatz, der funktioniert, und fügen Sie nur dann Komplexität hinzu, wenn Belege dies stützen.

Hierbei handelt es sich um den ersten einer Reihe von Beiträgen zu Multiagentensystemen. Weitere Informationen zu Mustern mit Einzelagenten finden Sie unter Erstellung effektiver Agenten. Strategien für das Kontextmanagement finden Sie unter Effektives Kontext-Engineering für KI-Agenten. Weitere Informationen dazu, wie wir unser Recherchesystem mit mehreren Agenten entwickelt haben, finden Sie unter Wie wir unser Recherchesystem mit mehreren Agenten entwickelt haben.

Danksagungen

Geschrieben von Cara Phillips mit Beiträgen von Paul Chen, Andy Schumeister, Brad Abrams und Theo Chu.