Creazione di sistemi multiagente: quando e come utilizzarli

Che cos'è un sistema multiagente?

Un sistema multiagente è un'architettura in cui vengono eseguite più istanze LLM con contesti di conversazione separati, coordinate tramite codice. Ogni agente gestisce una parte distinta di un'attività, ad esempio un subagente effettua ricerche mentre un orchestratore pianifica, in modo da proteggere il contesto, abilitare il lavoro in parallelo e consentire specializzazioni che un singolo agente non può sostenere.

Esistono molteplici pattern di coordinamento (sciami di agenti, sistemi basati sulle funzionalità e architetture message bus), ma questo articolo si concentra sul pattern orchestratore-subagent: un modello gerarchico in cui un agente lead genera e gestisce subagenti specializzati per subattività specifiche. Questo pattern offre un modello di coordinamento semplice ed è un buon punto di partenza per i team che si avvicinano per la prima volta ai sistemi multiagente. Esploreremo altri pattern in dettaglio nel nostro prossimo articolo.

Oggi, i sistemi multiagente vengono spesso applicati in situazioni in cui un singolo agente avrebbe prestazioni migliori, anche se questa valutazione continua ad evolversi man mano che i modelli migliorano. Noi di Anthropic abbiamo visto i team investire mesi nello sviluppo di architetture multiagente elaborate, solo per scoprire che un miglioramento dei prompt su un singolo agente otteneva risultati equivalenti.

Dopo aver creato sistemi multiagente e collaborato con i team per la loro distribuzione in produzione, abbiamo identificato tre situazioni in cui più agenti offrono costantemente prestazioni migliori di un singolo agente: quando la contaminazione del contesto peggiora le prestazioni, quando le attività possono essere eseguite in parallelo e quando la specializzazione migliora la selezione degli strumenti o la focalizzazione sulle attività. Al di fuori di queste situazioni, i costi di coordinamento in genere superano i benefici.

In questo articolo condividiamo come riconoscere i limiti dell'agente singolo, identificare i tre scenari in cui i sistemi multiagente eccellono ed evitare gli errori di implementazione più comuni.

Perché iniziare con un singolo agente

Un agente singolo ben progettato con strumenti appropriati può ottenere molto più di quanto molti sviluppatori si aspettino.

I sistemi multiagente introducono un overhead. Ogni agente aggiuntivo rappresenta un altro potenziale punto di errore, un altro set di prompt da gestire e un'altra fonte di comportamento inaspettato.

Abbiamo osservato team creare sistemi multiagente elaborati con agenti separati per la pianificazione, l'esecuzione, la revisione e l'iterazione, solo per scoprire che hanno risentito della perdita di contesto a ogni passaggio e hanno speso più token per il coordinamento anziché per l'esecuzione. Nei nostri test, le implementazioni multiagente utilizzano in genere un numero di token da 3 a 10 volte superiore rispetto agli approcci a singolo agente per attività equivalenti. Questo sovraccarico deriva dalla duplicazione del contesto tra gli agenti, dai messaggi di coordinamento tra gli agenti e dal riepilogo dei risultati per i trasferimenti.

Un framework decisionale per sistemi multiagente

Le architetture multiagente offrono valore quando risolvono vincoli specifici che un singolo agente non può superare. Ciò significa che le architetture multiagente dovrebbero essere riservate ai casi in cui offrono vantaggi evidenti in grado di giustificare i costi aggiuntivi. Un'infrastruttura gestita può occuparsene al posto tuo (vedi Multiagent orchestration in Claude Managed Agents).

I modelli seguenti rappresentano casi in cui osserviamo costantemente rendimenti positivi su questo investimento.

Protezione del contesto

I modelli linguistici di grandi dimensioni dispongono di finestre di contesto finite e la qualità delle risposte può degradarsi con l'aumentare del contesto. Quando il contesto di un agente accumula informazioni irrilevanti per le sottoattività successive, provenienti da una sottoattività, si verifica un inquinamento del contesto. I subagenti forniscono isolamento: ognuno opera in un contesto pulito e incentrato sull'attività specifica.

Considera un agente dell'assistenza clienti che abbia bisogno di recuperare la cronologia degli ordini mentre diagnostica problemi tecnici. Se ogni ricerca di ordine aggiunge migliaia di token al contesto, la capacità dell'agente di ragionare sul problema tecnico si deteriora.

‍

L'approccio a singolo agente:

# 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
]

L'agente deve ragionare sul problema tecnico mantenendo nel contesto oltre 2000 token di cronologia degli ordini irrilevante, diluendo l'attenzione e riducendo la qualità delle risposte.

‍

L'approccio multiagente:

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

L'agente di ricerca degli ordini elabora l'intera cronologia degli ordini ed estrae un riepilogo. L'agente principale riceve solo i 50-100 token effettivamente necessari, mantenendo focalizzato il contesto.

L'isolamento del contesto è più efficace quando le sottoattività generano un volume di contesto elevato (oltre 1000 token), ma la maggior parte delle informazioni è irrilevante per l'attività principale, quando la sottoattività è ben definita con criteri chiari sulle informazioni da estrarre e per operazioni di ricerca o recupero che richiedono un filtraggio prima dell'uso.

Parallelizzazione

L'esecuzione di più agenti in parallelo consente di esplorare uno spazio di ricerca più ampio di quanto possa coprire un singolo agente. Questo modello si è rivelato particolarmente prezioso per le attività di ricerca.

Il team di ricerca di Anthropic ha documentato questo aspetto nel post Come abbiamo sviluppato il nostro sistema di ricerca multiagente. Un agente lead analizza una query e genera subagent multipli per esaminare diverse sfaccettature in parallelo. Ogni subagent effettua ricerche in modo indipendente, quindi restituisce risultati distillati. La ricerca multiagente ha mostrato miglioramenti sostanziali nell'accuratezza rispetto agli approcci a singolo agente, consentendo l'esplorazione in spazi informativi più grandi.

L'implementazione principale scompone una domanda in aspetti indipendenti, esegue subagenti simultaneamente, quindi sintetizza i risultati.

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)

Questa copertura migliorata ha un costo. I sistemi multiagente consumano in genere da 3 a 10 volte più token rispetto agli approcci a singolo agente per attività equivalenti. Ciò accade perché ogni agente necessita di un proprio contesto, gli agenti devono scambiarsi messaggi per coordinarsi e i risultati devono essere riepilogati quando vengono passati da un agente all'altro. Sebbene il parallelismo consenta di ridurre il tempo di esecuzione totale rispetto all'esecuzione sequenziale di tutto il lavoro, i sistemi multiagente spesso richiedono più tempo complessivamente rispetto ai sistemi a singolo agente a causa del notevole aumento dei calcoli totali.

Il vantaggio principale della parallelizzazione è la completezza, non la velocità. Quando è necessario eseguire ricerche in un ampio spazio informativo o esaminare molti aspetti di una domanda complessa, gli agenti paralleli possono coprire più terreno rispetto a un singolo agente che opera entro i limiti del proprio contesto. Il compromesso è un utilizzo più elevato dei token e spesso un tempo di esecuzione totale più lungo a fronte di risultati più completi.

Specializzazione

Attività diverse possono trarre vantaggio da set di strumenti, prompt di sistema o settori di competenza diversi. Anziché fornire a un singolo agente l'accesso a decine di strumenti, gli agenti specializzati con set di strumenti mirati e adatti alle loro responsabilità possono migliorare l'affidabilità.

Specializzazione dei set di strumenti

Quando un agente ha accesso a troppi strumenti, le prestazioni ne risentono. Tre segnali indicano che una specializzazione degli strumenti sarebbe utile:

1. Quantità. Un agente con troppi strumenti (spesso oltre 20) ha difficoltà a selezionare quello appropriato.
2. Confusione del dominio. Quando gli strumenti si estendono a più domini non correlati (operazioni di database, chiamate API, operazioni di file system), l'agente confonde quale dominio si applica a una determinata attività.
3. Prestazioni ridotte. L'aggiunta di nuovi strumenti degrada le prestazioni delle attività esistenti, il che suggerisce che l'agente ha raggiunto la propria capacità di gestione degli strumenti.

Specializzazione dei prompt di sistema

Attività diverse a volte richiedono personalità, vincoli o istruzioni diverse che possono entrare in conflitto se combinate. Un agente dell'assistenza clienti deve essere empatico e paziente, mentre un agente di revisione del codice deve essere preciso e critico. Un agente che controlla la conformità necessita di regole rigide; un agente di brainstorming necessita di flessibilità creativa. Quando un singolo agente deve passare tra modalità comportamentali conflittuali, la separazione in agenti specializzati con prompt di sistema personalizzati produce risultati più coerenti.

Ogni agente specializzato vale solo quanto le istruzioni ricevute: le stesse best practice per il prompt engineering che migliorano gli output di un singolo agente si applicano al prompt di sistema di ogni subagente.

Specializzazione delle competenze di dominio

Alcune attività traggono vantaggio da un contesto di dominio profondo che sovraccaricherebbe un agente generalista. Un agente di analisi legale potrebbe aver bisogno di un contesto esteso sulla giurisprudenza e sui quadri normativi. Un agente di ricerca medica potrebbe aver bisogno di conoscenze specialistiche sulla metodologia degli studi clinici. Anziché caricare tutto il contesto di dominio in un singolo agente, gli agenti specializzati possono disporre di competenze mirate pertinenti alle proprie responsabilità specifiche.

Esempio: integrazione multipiattaforma. Prendiamo in considerazione un sistema di integrazione in cui gli agenti devono lavorare su piattaforme CRM, di automazione del marketing e di messaggistica. Ogni piattaforma dispone di 10-15 endpoint API pertinenti. Un singolo agente con oltre 40 strumenti spesso fatica a selezionare correttamente, confondendo operazioni simili sulle varie piattaforme. La suddivisione in agenti specializzati con set di strumenti mirati e prompt personalizzati consente di risolvere gli errori di selezione.

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

Questo modello rispecchia una collaborazione professionale efficace, in cui gli specialisti con strumenti adatti ai propri ruoli collaborano in modo più efficace dei generalisti che tentano di mantenere le competenze in tutti i settori. Tuttavia, la specializzazione introduce una complessità di routing. L'orchestratore deve classificare correttamente le richieste e delegare all'agente giusto. Un instradamento errato porta a risultati scadenti. La gestione di più agenti specializzati aumenta inoltre i costi di manutenzione dei prompt. La specializzazione funziona meglio quando i domini sono chiaramente separabili e le decisioni di routing sono non ambigue.

Superare le architetture ad agente singolo

Al di là del quadro generale, alcuni segnali concreti suggeriscono che i modelli basati su un singolo agente sono ormai superati:

Avvicinarsi ai limiti del contesto.Se un agente utilizza regolarmente grandi quantità di contesto e le prestazioni peggiorano, la pressione del contesto potrebbe rappresentare il collo di bottiglia. Si noti che i recenti progressi nella gestione del contesto (come la compattazione) stanno riducendo questa limitazione, consentendo ai singoli agenti di mantenere una Memoria efficace su orizzonti molto più lunghi.

Gestire molti strumenti. Quando un agente dispone di 15-20 o più strumenti, il modello dedica una quantità significativa di contesto e attenzione alla comprensione delle opzioni. Prima di adottare un'architettura multiagente, si consideri l'utilizzo dello strumento di ricerca strumenti, che consente a Claude di scoprire dinamicamente gli strumenti on-demand anziché caricare tutte le definizioni fin dall'inizio. Questo può ridurre l'utilizzo dei token fino all'85%, migliorando al contempo l'accuratezza nella selezione degli strumenti.

Sottoattività parallelizzabili. Quando le attività si suddividono naturalmente in parti indipendenti (ricerca su più fonti, test su più componenti), i sottoagenti paralleli possono accelerare notevolmente.

Queste soglie si sposteranno con il miglioramento dei modelli. I limiti attuali rappresentano linee guida pratiche, non vincoli fondamentali.

Scomposizione incentrata sul contesto

Quando si adotta un'architettura multiagente, la decisione progettuale più importante è come suddividere il lavoro tra gli agenti. Abbiamo osservato che i team effettuano spesso questa scelta in modo errato, generando un sovraccarico di coordinamento che annulla i vantaggi della progettazione multiagente.

L'intuizione chiave è adottare una visione incentrata sul contesto anziché sul problema quando si scompone il lavoro.

Scomposizione incentrata sul problema (spesso controproducente). La suddivisione per tipo di lavoro (un agente scrive funzionalità, un altro test, un terzo esamina il codice) crea un costante sovraccarico di coordinamento. Ogni trasferimento perde il contesto. L'agente di scrittura dei test non sa perché sono state prese determinate decisioni di implementazione e il revisore del codice non dispone del contesto dell'esplorazione e dell'iterazione.

Scomposizione incentrata sul contesto (solitamente efficace). La suddivisione in base ai confini di contesto implica che un agente che gestisce una funzionalità dovrebbe gestirne anche i test, poiché dispone già del contesto necessario. Il lavoro dovrebbe essere suddiviso solo quando il contesto può essere realmente isolato.

Questo principio emerge dall'osservazione delle modalità di errore nei sistemi multiagente. Quando gli agenti vengono suddivisi per tipo di problema, partecipano a un "telefono senza fili", passandosi le informazioni avanti e indietro, con ogni trasferimento che degrada la fedeltà. In un esperimento con agenti specializzati per ruolo nello sviluppo del software (pianificatore, implementatore, tester, revisore), i subagenti hanno speso più token per il coordinamento che per il lavoro vero e proprio.

I confini di scomposizione efficaci includono:

• Percorsi di ricerca indipendenti. L'indagine sulle "tendenze di mercato in Asia" rispetto alle "tendenze di mercato in Europa" può procedere in parallelo senza un contesto condiviso.
• Componenti separati con interfacce pulite. Con un contratto API ben definito, il lavoro sul frontend e sul backend può procedere in parallelo.
• Verifica della blackbox. Un verificatore che abbia solo bisogno di eseguire test e segnalare i risultati non ha bisogno di contesto di implementazione.

I confini di decomposizione problematici includono:

• Fasi sequenziali dello stesso lavoro. Pianificazione, implementazione e test della stessa funzionalità condividono troppo contesto.
• Componenti strettamente accoppiati. I componenti che richiedono un costante scambio continuo devono essere integrati nello stesso agente.
• Attività che richiedono uno stato condiviso. Gli agenti che dovrebbero sincronizzare frequentemente la loro comprensione dovrebbero rimanere insieme.

Il pattern di subagente di verifica

Un pattern multiagente che funziona costantemente bene nei diversi domini è il subagente di verifica. Si tratta di un agente dedicato la cui unica responsabilità è testare o convalidare il lavoro dell'agente principale.

Vale la pena notare che modelli di orchestrazione più capaci (come Claude Opus 4.5) sono sempre più in grado di valutare direttamente il lavoro dei subagenti senza una fase di verifica separata. Tuttavia, i subagenti per la verifica restano preziosi quando si utilizzano orchestratori meno competenti, quando la verifica richiede strumenti specializzati o quando si desidera applicare checkpoint di verifica espliciti nel flusso di lavoro.

I subagenti di verifica hanno successo perché eludono il problema del telefono senza fili. La verifica richiede per natura un trasferimento di contesto minimo, pertanto un verificatore può eseguire un test black-box su un sistema senza bisogno dell'intera cronologia di come è stato costruito.

Implementare un sistema multiagente

L'agente principale completa un'unità di lavoro. Prima di procedere, genera un subagente di verifica con l'artefatto da verificare, chiari criteri di successo e strumenti per eseguire la verifica.

Il verificatore non ha bisogno di capire perché l'artefatto è stato costruito così com'è. Deve solo determinare se l'artefatto soddisfa i criteri specificati.

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")

Applicazioni dei sistemi multiagente

I subagenti di verifica sono efficaci per:

• Garanzia qualità. Esecuzione di suite di test, linting del codice, convalida degli output rispetto agli schemi.
• Controllo della conformità. Verifica che i documenti soddisfino i requisiti delle policy e verifica degli output rispetto alle regole.
• Convalida dell'output. Verificare la conformità dei contenuti generati alle specifiche prima della distribuzione.
• Verifica dei fatti. Affidare a un agente separato la verifica di affermazioni o citazioni nei contenuti generati.

Il problema delle vittorie precoci

La modalità di fallimento più significativa per i subagenti di verifica consiste nel contrassegnare gli output come superati senza test approfonditi. Il verificatore esegue uno o due test, ne osserva il superamento e dichiara il successo.

Le strategie di mitigazione includono:

• Criteri concreti. Specifica "Esegui l'intera suite di test e segnala tutti gli errori" anziché "Assicurati che funzioni".
• Controlli completi. Richiedi al verificatore di testare più scenari e casi marginali.
• Test negativi. Indica al verificatore di tentare input che dovrebbero fallire e conferma che ciò avvenga.
• Istruzioni esplicite. L'istruzione "DEVI eseguire l'intera suite di test prima di contrassegnarla come superata" è essenziale. Senza requisiti espliciti per una convalida completa, gli agenti di verifica utilizzano scorciatoie.

Scegliere tra sistemi a singolo agente e multiagente

I sistemi multiagente sono potenti, ma non universalmente adatti. Prima di aggiungere la complessità di più agenti coordinati, verifica che:

1. Esistano vincoli autentici che possono essere risolti da più agenti, come limiti di contesto, opportunità di parallelizzazione o necessità di specializzazione.
2. La scomposizione dipende dal contesto, non dal tipo di problema. Raggruppa i lavori in base al contesto necessario, non al tipo di lavoro.
3. Esistano punti di verifica chiari in cui i subagenti possono convalidare il lavoro senza richiedere il contesto completo.

Il nostro consiglio? Inizia con l'approccio più semplice e funzionante e aggiungi complessità solo quando le prove lo supportano.

Questo è il primo di una serie di post sui sistemi multiagente. Per ulteriori informazioni sui pattern con agente singolo, consulta Creare agenti efficaci. Per strategie di gestione del contesto, consulta Ingegneria del contesto efficace per gli agenti IA. Per approfondire la modalità di sviluppo del nostro sistema di ricerca multiagente, consultare Come abbiamo sviluppato il nostro sistema di ricerca multiagente.

Ringraziamenti

Scritto da Cara Phillips, con il contributo di Paul Chen, Andy Schumeister, Brad Abrams e Theo Chu.