Il tuo agente non ha bisogno di tutti gli strumenti nel suo contesto

L'agente AI di DynoTable può raggiungere 38 strumenti. Raramente li vede tutti insieme. Dove abbiamo tracciato il confine tra ciò che ottiene il modello immediatamente e quello che doveva cercare si è rivelato essere il massimo decisione consequenziale nell'intero toolkit e la linea non è finita da nessuna parte vicino a dove l'abbiamo messo per la prima volta.

Abbiamo creato un meccanismo di scoperta in modo che il modello inizi con un set piccolo e cercare il resto. Poi abbiamo visto i modelli economici usarlo e ne abbiamo spostati 27 i 38 strumenti nuovamente nel nucleo sempre visibile. Il meccanismo è sopravvissuto. Il nostro la teoria su chi ne avesse bisogno no.

Lo abbiamo imparato costruendo una superficie di strumenti per modelli che non possono esserlo fidato di andare a cercare.

Uno strumento che il modello non chiama mai ti costa comunque

Ogni strumento che esponi contiene il tuo nome, la tua descrizione e il tuo schema di input completo, serializzato nella richiesta prima che l'utente abbia digitato qualsiasi cosa. Trentotto di quelli non sono gratuiti.

I gettoni rappresentano la metà più piccola del conto. Il vero costo è l’accuratezza della selezione: più opzioni quasi identiche vengono scansionate da un modello, più spesso sceglie le opzioni quello sbagliato. Il nostro catalogo è pieno di opzioni quasi identiche apposta. Cinque dei nostri strumenti esistono due volte, openTable e proposeOpenTable, openWorkbench e proposeOpenWorkbench e così via. Ogni coppia fa la stessa cosa; uno lo fa immediatamente, l'altro emette un chip su cui l'utente fa clic per primo. Quella distinzione è portante persicurezza e quasi invisibile in un appartamento elenco dei nomi.

ILLa guida del cliente di conduce esattamente a questo punto: caricare in anticipo ogni definizione di strumento spreca token, aggiunge latenza e degrada le prestazioni del modello. Essere d'accordo con questo è facile. Decidere quale gli strumenti perdono la loro sede ed è qui che la cosa diventa interessante.

Abbiamo creato uno strumento di ricerca. Il modello da pavimento non lo chiamerebbe.

Il meccanismo è a due livelli. Una serie di strumenti è attiva fin dal primo passaggio. Il resto sono invisibili finché il modello non chiama searchTools(query), che assegna il punteggio cataloga su nomi, descrizioni e parole chiave, restituisce le corrispondenze e le aggiunge all'insieme di strumenti che il modello può richiamare nei passaggi successivi.

Poi lo abbiamo confrontato con il nostro modello da pavimento. Non sintonizziamo questo agente contro a modello di frontiera su cui funziona le tue credenziali Bedrock, così le persone scelgono modelli economici e ottimizziamo per quello più economico. Alla domanda su un allegato file, quel modello è andato invece a cercare nell'elenco delle schede aperte. Esso raramente chiamato lo strumento di ricerca. Tutto ciò che non è direttamente visibile non esiste per lui.

Questo risultato uccide il design ovvio. Se la scoperta è l’unica strada verso uno strumento, ogni richiesta che necessita di quello strumento dipende dal modello che sceglie di cercare, e i modelli che hanno maggiori probabilità di aver bisogno di aiuto sono quelli che meno probabilmente lo chiederanno.

Quindi la scissione ha smesso di essere "piccolo nucleo, grande coda" ed è diventata una questione di significato la richiesta, non lo strumento: la frase dell'utente nomina lo strumento? Gli 11 gli strumenti che abbiamo mantenuto rilevabili sono quelli in cui la risposta è sì. "Esporta questo to CSV" effettua una ricerca del modello per export. "Mostrami gli ordini del mese scorso" sì non farlo cercare uno strumento di impostazione del filtro, in modo che uno rimanga in linea. Indice statistiche, specifiche salvate, introspezione delle relazioni e modifica graduale le superfici sono tutte cose che un utente chiede per nome quando le desidera, e mai implicitamente.

Ventisette in linea non è un numero che avremmo difeso in anticipo. È il numero che è sopravvissuto al contatto con il modello con cui spediamo effettivamente.

La corsa che avrebbe reso silenziosamente inutile la scoperta

La scoperta ha un vincolo temporale che è facile da sbagliare e difficile da notare.

Quando lo strumento di ricerca restituisce corrispondenze, tali nomi devono unirsi al set consentito prima che venga preparato il passaggio successivo del modello. Il posto più ovvio per farlo è il gancio che si attiva al completamento di un passaggio. In alcuni è documentato che quel gancio spara Versioni dell'SDK, dopo la preparazione del passaggio successivo, ovvero la mutazione atterra un passo troppo tardi.

La modalità di fallimento è brutta. Il modello cerca. Ottiene una denominazione corretta del risultato lo strumento di cui ha bisogno. Richiama lo strumento nel passaggio successivo e gli viene indicato lo strumento non esiste. Intermittente, a seconda della versione dell'SDK risolta e del problema sembra un modello stupido piuttosto che un corridore rotto.

La soluzione consiste nel modificare il set consentito all'interno dell'esecuzione dello strumento di ricerca, che è garantito per essere completato prima che il ciclo avanza. Questa è una riga differenza nel luogo in cui vive un'affermazione, ed è la differenza tra a meccanismo di scoperta funzionante e che fallisce una frazione delle volte ragioni che nessuno attribuirà correttamente.

Tre ricerche, poi stop

La ricerca è limitata a 3 chiamate per turno di agente. Il quarto restituisce invece questo di correre:

{"error": "search-budget-exhausted", "budgetCap": 3}

Il limite esiste a causa di un ciclo specifico. Il modello cerca, non trova cosa immagina, cerca di nuovo un sinonimo, non trova neanche quello e brucia il tuo intero budget di passaggio all'interno dello strumento di ricerca senza mai toccare il banca dati. Limitarlo impone una decisione, impegnarsi già in uno degli strumenti trovato, o chiedi all'utente, nel punto in cui ulteriori ricerche hanno smesso di pagare.

Il messaggio di errore quando un modello chiama uno strumento che non ha scoperto segue il file stesso principio che usiamo per ogni validatore nell'agente:

Tool 'startExport' not in active set. Call searchTools(query='startExport')
to discover it, or use one of: <inline tool names>

Un rifiuto che nomina l'azione di recupero costa un passaggio aggiuntivo. Un rifiuto questo dice semplicemente che il turno non costa nulla.

Una riga per utensile, tutto il resto derivato

Ogni strumento viene dichiarato una volta, in un unico elenco semplice, e la riga porta il simbolo l'intera identità dello strumento: il nome e la descrizione, le parole chiave ricercate se inizia in linea o rilevabile, in quale livello viene eseguito e come è esposto su MCP.

Questi livelli contano tanto quanto la ripartizione della visibilità. Ventuno strumenti lo sono silenzioso, legge che scorre senza interrompere nessuno. Sedici sono recintati dietro la scala di autorizzazione. Esattamente uno non appartiene a nessuno dei due, perché il lo strumento di ricerca non è una funzionalità che l'agente utilizza sui tuoi dati; fa parte del ciclo stesso. MCP l'esposizione è un terzo asse sulla stessa riga: sola lettura, stadiazione, pieno o escluso del tutto, quali sono i tre strumenti.

La regola che mantiene tutto ciò onesto è che ogni altro elenco nel sistema lo è derivato da quelle righe, il set di livelli silenziosi, i livelli di ambito MCP, il set con ambito di scrittura e nessuno di essi viene gestito manualmente. Una mano tenuta silenziosa l'elenco accanto a un elenco MCP tenuto a mano è esattamente il modo in cui uno strumento finisce correttamente in chat e tranquillamente slegato da un cliente esterno.

Il vincolo che non ci aspettavamo è che l'elenco delle dichiarazioni debba contenere zero importazioni di runtime. È condiviso dall'interfaccia utente desktop e dal backend e a la singola importazione raggiunge, transitivamente, una dipendenza crittografica solo del nodo per mezzo di uno implementazione dello strumento. Inseriscilo nel pacchetto del browser e l'app fallisce carico del modulo. Né il controllo del tipo né i test unitari lo rilevano, entrambi si risolvono l'importazione felicemente. Ciò che lo cattura è un test che legge il file come testo e fallisce su qualsiasi dichiarazione di importazione, che sembra rozza fino alla prima tempo ti fa risparmiare.

Quali trasferimenti se ne stai costruendo uno

Conta i tuoi strumenti prima di difendere la tua architettura. La divisione giusta è a misura, non un principio.
Metti alla prova la scoperta rispetto al tuo modello più debole. Un modello di frontiera cercherà quando dovrebbe; questo non ti dice nulla sul modello scelto dai tuoi utenti.
Decidi la visibilità in base alla frase dell'utente che nomina lo strumento. Strumenti invocato appartiene implicitamente in linea; è possibile trovare gli strumenti richiesti dalle persone per nome.
Controlla quando i ganci del gradino del tuo framework si attivano effettivamente prima di inserire qualsiasi cosa sensibile all'ordine in uno.
Limitare i meta-strumenti. Tutto ciò che può essere chiamato ripetutamente senza toccarsi lo stato reale sarà, e un budget speso per la ricerca è un turno sprecato.
Assegnare agli errori dello strumento non scoperto il nome della chiamata di ripristino, uguale a qualsiasi altra errore del validatore.
Dichiarare ogni strumento una volta e derivare da esso ogni altro elenco. Due tenuti a mano gli elenchi degli stessi strumenti alla fine non sono d'accordo e il disaccordo si manifesta in un confine di sicurezza.
Se un modulo comporta un vincolo portante che il tuo compilatore non può esprimere, scrivi il test grezzo che lo applica come testo.

Dove corre

Tutto questo viene spedito all'interno di DynoTable. catalogo degli strumenti, query in base allo schema per conto proprio

credenziali, con scritture che arrivano sempre e solo in a area di sosta revisionabile. Le stesse dichiarazioni guidano il MCP server a cui si connettono gli agenti esterni, dove il livello di esposizione su ciascuna riga diventa l'ambito concesso a un cliente esterno; come lo abbiamo reso sicuro (OAuth, consenso, isolamento delle credenziali) è una storia a parte.

E lo strato sottostante, i validatori che creano ciascuno di questi strumenti sopravvivere con un modello economico, lo è il proprio post.