Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Ambito dello strumento
Esistono due approcci per lo sviluppo di strumenti: granulari e a grana grossa.
Granulare
Con un approccio granulare, creeresti uno strumento per API, azione o query. Ad esempio, puoi crearecreate_issue, get_issue add_labelassign_issue, e close_issue strumenti per il tuo repository Git. Ciò consentirebbe all'LLM di effettuare chiamate granulari a ciascuna API e di orchestrarle ciascuna secondo necessità. Considerate la seguente richiesta: «Create un problema per il servizio di prodotto chiamato 'Query restituisce solo risultati parziali', etichettatelo come bug e con priorità alta e assegnatelo ad Alice». L'immagine seguente mostra come un tool-per-API approccio risponderebbe a questa richiesta.
In questo approccio, il prompt di sistema e ogni definizione di strumento registrata vengono fornite all'LLM a ogni chiamata. Ciò consuma ulteriore contesto e comporta una penalità di latenza perché ogni chiamata allo strumento rappresenta una singola chiamata al LLM. Inoltre, aumenta la complessità della gestione degli errori all'interno del flusso di lavoro.
A grana grossa
Un approccio a grana grossa, o basato sul flusso di lavoro, sarebbe costituito da strumenti orientati al flusso di lavoro. Lo strumento si concentra sull'intento dell'utente piuttosto che sulla struttura delle API. end-to-end Invece di a tool-per-API, hai uno strumento che ne chiama in modo deterministico molti. APIs Utilizzando il precedente esempio di repository Git, è possibile creare uno create_and_setup_issue strumento che viene chiamato una sola volta dall'agente. L'implementazione dello strumento crea il problema, aggiunge etichette e lo assegna a un utente, in base ai parametri forniti allo strumento. L'immagine seguente mostra come un approccio a grana grossa elaborerebbe lo stesso prompt.
Questo approccio mostra come tutta la complessità rimanga nascosta al livello LLM. Quando la logica di orchestrazione è incorporata nell'implementazione dello strumento, tutti i passaggi sequenziali, la registrazione, la logica dei tentativi, gli interruttori automatici e la limitazione della velocità vengono eseguiti in modo deterministico nello strumento. L'approccio basato sul flusso di lavoro rende più semplice per l'LLM richiamare lo strumento corretto con i parametri corretti. È importante notare che alcune API potrebbero già fornire l'intento del flusso di lavoro, come l'API Amazon RunInstances EC2. In questi casi, a tool-per-API potrebbe fornire il design orientato al flusso di lavoro che desideri.
Tuttavia, anche gli strumenti possono avere una grana troppo grossa. Se un unico strumento di flusso di lavoro tenta di fare troppe cose e ha molti parametri possibili, l'LLM può avere difficoltà a ragionare su come utilizzare correttamente lo strumento. Può anche creare problemi nella selezione dei parametri e nella gestione degli errori. Pertanto, lo sviluppo degli strumenti deve raggiungere un equilibrio che sia in linea con le intenzioni dell'utente ed evitare funzionalità insufficienti o eccessive in un singolo strumento. Ti consigliamo di progettare strumenti basati su flussi di lavoro utente completi, raggruppando le operazioni che di solito avvengono insieme (come tre o più chiamate API). Ti consigliamo inoltre di scomporre gli strumenti che superano otto o più parametri o di gestire più intenti utente distinti. Esegui il test con istruzioni reali per verificare che gli agenti siano in grado di utilizzare correttamente ogni strumento.
Se disponi di flussi di lavoro complessi e dinamici che non possono essere facilmente incapsulati come strumento deterministico, potresti prendere in considerazione l'utilizzo del modello. agent-as-tool Invece che l'agente principale cerchi di orchestrare attività complesse in un flusso di lavoro, un agente specializzato può fungere da strumento. Questi tipi di strumenti possono implementare processi decisionali e ramificazioni avanzati, gestire errori e riprovare logiche che non possono essere gestite facilmente nel codice deterministico. Si tratta di un protocollo simile ma distinto dal protocollo Agent2Agent
Ti consigliamo di iniziare con l'analisi del flusso di lavoro mappando i flussi di lavoro degli utenti più comuni per identificare le funzionalità principali di cui ogni agente ha bisogno. Questo stabilisce il set di strumenti minimo utilizzabile. Sulla base della nostra esperienza nello sviluppo di server MCP su larga scala, consigliamo le seguenti pratiche. Quando queste pratiche sono in conflitto, dai la priorità alle intenzioni e al flusso di lavoro dell'utente.
Le migliori pratiche per la definizione degli strumenti MCP
-
Pensate alle storie degli utenti e raggruppate le operazioni comuni: gli strumenti devono essere mappati direttamente per completare le interazioni degli utenti anziché richiedere l'orchestrazione di più operazioni. Se i flussi di lavoro richiedono in genere tre o più chiamate separate, combinale in un unico strumento. Ciò riduce il carico cognitivo sull'LLM, minimizza il numero di chiamate agli strumenti, riduce il consumo di contesto e la latenza necessari per completare le attività e migliora la precisione e la latenza.
-
Limita i parametri a otto o meno: se uno strumento supera gli otto parametri, scomponilo in più strumenti. LLMs faticano a selezionare i parametri man mano che la complessità aumenta.
Nota
Se le operazioni di raggruppamento richiedono più di otto parametri, dai la priorità al raggruppamento rispetto al conteggio dei parametri, perché la semplificazione del flusso di lavoro è più importante dei rigidi limiti dei parametri.
-
Operazioni di lettura e scrittura separate: fornisce diversi strumenti per leggere i dati e modificarli. Questa separazione rende esplicito quando gli agenti eseguono operazioni potenzialmente distruttive, abilita politiche di autorizzazione diverse e riduce il rischio di modifiche involontarie durante la raccolta delle informazioni.
-
Fornisci impostazioni predefinite ragionevoli: progetta strumenti in modo che l'LLM debba specificare solo i parametri specifici della singola richiesta. Le impostazioni predefinite riducono la complessità dei parametri e migliorano la precisione della selezione degli strumenti riducendo al minimo le informazioni su cui l'LLM deve ragionare.
-
Preferisci l'esecuzione deterministica: rendi deterministici l'esecuzione degli utensili e l'output quando possibile. Gli strumenti deterministici sono più affidabili e facili da testare. Per flussi di lavoro complessi che richiedono un'orchestrazione intelligente, una logica di ramificazione o una gestione avanzata degli errori che non possono essere facilmente gestite nel codice deterministico, prendi in considerazione l'utilizzo di agenti specializzati come strumenti. Tuttavia, utilizzate questo modello in modo selettivo perché aggiunge complessità.
