Trasforma l'IA in un sistema di esecuzione individuale, l'ultima guida alle best practice per agenti gestiti di Claude

Titolo originale dell'articolo: Lancio di Claude Managed Agents
Autore originale: Lance Martin
Traduzione: Peggy, BlockBeats

Nota del redattore: Questo articolo introduce i Managed Agent lanciati da Claude. Fornisce una forma software più vicina al futuro: gli agenti intelligenti non sono più interfacce che rispondono alle richieste una sola volta, ma sono sistemi di esecuzione che possono essere configurati, implementati, pianificati ed eseguiti a lungo termine.

Disaccoppiando completamente "intelligenza" (modello e framework runtime), "esecuzione" (strumenti e sandbox) e "processo" (sessione e log), i Claude Managed Agent trasformano l'agente da "logica nel codice" a un'unità di infrastruttura indipendente. Questo design non solo migliora la stabilità e la sicurezza del sistema nelle attività di lunga durata, ma consente anche agli agenti di espandersi continuamente man mano che le capacità del modello si evolvono, senza vincoli da parte dei framework esistenti.

In questo quadro, anche i modelli di utilizzo comuni sono cambiati: dall'esecuzione innescata da eventi e pianificata all'esecuzione automatica "trigger-on-delivery" e alle attività complesse che durano giorni o addirittura settimane, gli agenti acquisiscono davvero la capacità di "lavorare continuamente". Ciò significa che il valore dell’IA non si riflette più solo nella qualità di una singola risposta ma nella sua capacità di accumularsi e comporsi nel tempo.

Se le API passate permettevano agli sviluppatori di "invocare l'intelligence", i Managed Agent stanno ora tentando di rispondere a un'altra domanda: come rendere l'intelligence un sistema che può essere ospitato, pianificato ed eseguito continuamente. In questo senso, gli agenti non sono più solo strumenti ma più vicini a una nuova primitiva di calcolo.

L'articolo originale è il seguente:

TL;DR

I Managed Agent di Claude sono un framework di esecuzione degli agenti (agent harness) precostruito e configurabile che viene eseguito su un'infrastruttura gestita. È sufficiente definire un agente come modello, inclusi strumenti, competenze, repository di file/codice, ecc., e il resto del framework di runtime e dell'infrastruttura sono forniti dal sistema. Questo sistema è progettato per tenere il passo con i livelli di intelligenza in rapida crescita di Claude e supportare compiti di lunga durata.

Link correlati:

·Claude Blog: Modelli di utilizzo e casi di clienti

·Blog di ingegneria: Progettazione di Claude Managed Agents

·Documentazione: Guida introduttiva, Guida rapida, CLI e SDK Panoramica

Agenti gestiti da Claude

Perché sono necessari agenti gestiti Claude

L'API dei messaggi di Claude è fondamentalmente un punto di ingresso per interagire direttamente con il modello: inserire un messaggio, recuperare un blocco di contenuti. Gli agenti intelligenti basati sull'API dei messaggi devono fare affidamento su un "runtime framework" per gestire il routing delle invocazioni degli strumenti, la gestione del contesto e altro ancora. Ciò pone tuttavia diverse sfide:

1. Il framework di runtime deve tenere il passo con le capacità in evoluzione di Claude
Recentemente ho scritto un post sul blog su come costruire un agente basato sulle capacità sottostanti di Claude API per gestire l'orchestrazione degli strumenti e la gestione del contesto. Tuttavia, il problema è che il runtime framework dell'agente spesso implica alcune ipotesi su "ciò che Claude non può fare". Man mano che le capacità di Claude crescono, queste ipotesi diventano rapidamente obsolete e possono persino diventare colli di bottiglia delle prestazioni. Pertanto, il framework di runtime deve essere continuamente aggiornato per tenere il passo con il tasso di evoluzione di Claude.

2. I cicli di vita dei compiti di Claude si allungano
La gamma di compiti che Claude può gestire sta crescendo esponenzialmente, superando le 10 ore di lavoro umano nei test di benchmark METR. Ciò pone maggiori esigenze sull'infrastruttura sottostante dell'agente: deve avere sicurezza, stabilità in scenari a lungo termine (gestire vari guasti dell'infrastruttura) e scalabilità (ad esempio, supportare più team di agenti in esecuzione simultaneamente).

Perché queste sfide contano

Affrontare le sfide sopra menzionate è fondamentale perché prevediamo che le versioni future di Claude saranno in grado di funzionare continuamente per periodi di giorni, settimane o addirittura mesi, affrontando i problemi più complessi dell'umanità.

Il Claude Agent SDK è il primo passo in questa direzione, fornendo un framework di runtime agente intelligente per tutti gli usi e facile da usare. Nel frattempo, i Managed Agent di Claude fanno un ulteriore passo avanti: partendo da questa base, forniscono un framework runtime completo + un'infrastruttura gestita specificamente progettata per supportare l'esecuzione sicura e affidabile delle attività su lunghi periodi di tempo.

Per iniziare

Un modo semplice per iniziare è usando la nostra abilità open source claude-api, che può essere usata fuori dalla scatola in Claude Code. È sufficiente installare l'ultima versione di Claude Code, quindi eseguire il seguente sottocomando per completare la configurazione di inizializzazione di Claude Managed Agents.

Personalmente ho una forte preferenza per l'approccio "skills" all'integrazione di nuove funzionalità, e uso ampiamente questa abilità nella pratica.

Inoltre, puoi fare riferimento alla nostra documentazione per iniziare rapidamente con l'SDK o la CLI e prototipare i tuoi agenti nella Console Claude.

Casi d'uso

Potete trovare molti casi d’uso interessanti nel blog ufficiale di Claude. Combinando questi casi con la mia esperienza pratica, ho osservato alcuni modelli di utilizzo comuni:

1. Evento innescato
Esecuzione di attività da parte di un Managed Agent attivato da un servizio.
Ad esempio, quando viene rilevato un bug nel sistema, viene effettuata una chiamata automatica a un agente gestito per scrivere una patch e inviare una PR. Non è necessario alcun intervento umano tra le fasi "problema individuato" e "patch applicato".

2. Esecuzione programmata
Pianificazione delle attività da eseguire per un agente gestito.
Ad esempio, molte persone, incluso me, usano questo metodo per generare briefing giornalieri (come un riepilogo delle attività sulla piattaforma X o GitHub, o il rapporto sui progressi di un team generato da un agente). Di seguito un esempio del mio riepilogo giornaliero delle attività sulla piattaforma X.

3. Fuoco-e-Dimentica
Esecuzione dell'attività da parte di un agente gestito innescata da un umano ma che non richiede un follow-up continuo. Ad esempio, l'assegnazione di attività a un agente gestito tramite Slack o Teams, che quindi completa autonomamente l'attività e fornisce i risultati (come tabelle, diapositive o persino applicazioni).

4. Compiti a lungo orizzonte
Un compito di lunga durata, che considero uno degli scenari particolarmente preziosi per i Managed Agent.
Ho condotto alcuni esperimenti basati sul repo di auto-ricerca di Andrej Karpathy, esplorando diversi modi di applicazione. Ad esempio, ho recentemente preso in input la libreria di pretesti di _chenglou e ho fatto ricercare da un agente gestito come applicarla ai contenuti del nostro blog di ingegneria.

Concetti fondamentali

Ci sono tre concetti fondamentali da comprendere nel processo di onboarding:

1. Agente
Una configurazione controllata dalla versione che definisce l'"identità" dell'agente: incluso il modello, il prompt del sistema, gli strumenti, le competenze, il server MCP, ecc. Una volta creato, può essere invocato ripetutamente tramite ID.

2. Ambiente
Un modello utilizzato per descrivere l'ambiente sandbox fornito per lo strumento agente da eseguire (ad esempio, tipo di runtime, criteri di rete, configurazione del pacchetto di dipendenze, ecc.).

3. Sessione
Un'istanza in esecuzione stateful avviata in base a un agente e un ambiente preconfigurati. Creerà una sandbox nuova di zecca dal modello di ambiente, monterà le risorse necessarie per questa esecuzione (come file, repository GitHub) e memorizzerà in modo sicuro le informazioni di autenticazione in un keystore (come le credenziali MCP).

Puoi pensarla in questo modo:

· Agente = La configurazione stessa

· Ambiente = Il modello sandbox richiesto per il funzionamento dell'agente

· Sessione = Un processo di esecuzione specifico

Un Agente può corrispondere a più Sessioni.

Uso

Fare riferimento alla documentazione per i dettagli. L'utilizzo complessivo è suddiviso in due categorie:

1. SDK (orientato al codice)
Integra l'SDK nella tua applicazione per guidare le sessioni a runtime. Attualmente, i Managed Agent supportano 6 lingue: Python, TypeScript, Java, Go, Ruby, PHP.

2. CLI (interfaccia a riga di comando)
Interagisci con tutte le risorse API tramite la riga di comando, inclusi agenti, ambienti, sessioni, vault, competenze, file, ecc. Ogni tipo di risorsa ha sottocomandi corrispondenti.

Pratica comune:
Di solito, la CLI viene utilizzata per la configurazione e l'inizializzazione, mentre l'SDK viene utilizzato per la logica di runtime.
Un modello agente è persistente: è possibile creare un modello (ad esempio, definendo il modello, prompt di sistema, strumenti, server MCP, competenze in YAML), memorizzarlo in Git e applicarlo durante il processo di distribuzione tramite la CLI.

Flusso di lavoro

Ho scritto un post sul blog di ingegneria antropica con @mc_anthropic, @gcemaj e @jkeatn, che ha fornito una spiegazione dettagliata della costruzione di Claude Managed Agents. Una conclusione chiave nell'articolo è che abilitare gli agenti a scalare con il livello di intelligenza di Claude è fondamentalmente un "problema di infrastruttura", non solo un problema di progettazione del framework di runtime.

Ciò significa che la vera sfida non sta nel "come scrivere un agente più intelligente", ma nel come costruire un sistema che possa funzionare stabilmente nel lungo periodo, essere scalabile ed evolvibile, consentendo all'agente di intraprendere attività sempre più complesse e a lungo termine.

Sulla base di questa filosofia, non did-133">abbiamo progettato un framework di runtime (harness) ad agente fisso poiché ne abbiamo anticipato la continua evoluzione. Invece, abbiamo "disaccoppiato" diverse parti chiave del sistema:

“Brain” (Claude e il suo framework di runtime)

“Mani” (sandbox e attrezzo che eseguono azioni concrete)

“Sessione” (registra i registri degli eventi di esecuzione)

Questi tre sono stati progettati come interfacce indipendenti con ipotesi minime l'uno sull'altro. Ogni parte può guastarsi o essere sostituita in modo indipendente senza influire sul sistema complessivo.

Nell'articolo abbiamo anche illustrato come questa architettura porti maggiore affidabilità, sicurezza e flessibilità, lasciando spazio anche alla futura integrazione di nuovi framework di runtime, sandbox o sessioni di hosting dell'infrastruttura.

Conclusione

Sono molto entusiasta dei progetti che esplorano la Multi-Agent Orchestration o i compiti a lungo orizzonte. Una cosa che mi ha sempre frustrato in passato è come il framework di esecuzione dell'agente fatica a tenere il passo con le capacità in evoluzione del modello.

Il significato di Claude Managed Agents è che si prende cura del framework di esecuzione e del livello di infrastruttura per te, consentendoti di concentrarti su un livello superiore, trattando l'"agente" stesso come una nuova primitiva fondamentale nell'API Claude, consentendo ulteriori esplorazioni e sviluppi in cima ad esso.

[Original Post Link]