Architettura degli Agenti AI: Routing dei Modelli e Scoperta degli Strumenti

Collegare un LLM è sufficiente per far generare testo a un'applicazione. Non è sufficiente per far completare a un agente AI un compito nel mondo reale.

Chiedi a un modello di riassumere un documento già nel suo contesto, e il livello del modello è sufficiente. Chiedi di confrontare i prezzi dei concorrenti di oggi, arricchire un record aziendale, controllare un account social o scegliere la migliore API per un lavoro sconosciuto, e la metà mancante diventa ovvia: l'agente ha bisogno di un modo affidabile per raggiungere sistemi esterni.

Un agente di produzione quindi prende due decisioni separate:

1. Quale modello dovrebbe gestire questo passaggio?
2. Quale strumento o API dovrebbe fornire i dati o l'azione?

AIHubMix affronta la prima decisione con accesso unificato ai modelli e routing dei modelli al momento della richiesta. Monid affronta la seconda con scoperta degli strumenti in esecuzione, ispezione degli schemi e esecuzione a pagamento per chiamata. I prodotti si trovano su diversi livelli della stessa architettura.

Divulgazione: Questo articolo è stato creato come parte di una collaborazione di contenuti con Monid. AIHubMix è la piattaforma di modelli discussa di seguito; Monid è la piattaforma degli strumenti. Ognuna può essere utilizzata indipendentemente.

I due problemi di routing all'interno di un agente AI

Un'esecuzione dell'agente è raramente una chiamata a un modello omogeneo. Un agente di ricerca può classificare una richiesta, cercare informazioni attuali, estrarre fatti strutturati, confrontare risultati e scrivere una risposta finale. Quei passaggi richiedono capacità diverse.

Lo stesso vale al di fuori del modello. Un compito di ricerca aziendale può necessitare di un'API di ricerca oggi, di un endpoint di arricchimento aziendale domani e di uno strumento di automazione del browser la settimana prossima. Se ogni modello e strumento è codificato in modo rigido al momento della costruzione, ogni nuovo compito diventa un progetto di integrazione.

I due livelli sono paralleli:

Questa separazione è importante. Un modello migliore non può creare accesso a dati live, e un catalogo di strumenti più ampio non può ragionare sui dati che restituisce. L'agente ha bisogno di entrambe le capacità, con un contratto chiaro tra di esse.

Monid presenta la vista complementare dal lato degli strumenti in Perché un Agente AI ha Bisogno di Due Integrazioni. Dal lato del modello, la lezione architettonica è la stessa: mantenere la selezione del modello e la selezione dello strumento indipendenti, quindi ottimizzare ciascun livello per il proprio lavoro.

Perché un modello fisso diventa costoso in un ciclo di agenti

Utilizzare un modello ovunque sembra semplice. In pratica, costringe ogni passaggio ad accettare lo stesso compromesso tra capacità, latenza e prezzo.

Considera un agente di ricerca di mercato:

• La classificazione dell'intento è breve e meccanica.
• La selezione dello strumento richiede un'affidabile esecuzione delle istruzioni.
• Estrarre campi da JSON restituito è per lo più trasformazione.
• Il rapporto finale può richiedere un ragionamento più forte e una scrittura migliore.

Inviare tutti e quattro i passaggi al modello più capace spreca denaro per lavori di routine. Inviare tutti e quattro al modello più economico può ridurre la qualità dell'unico output che l'utente legge. Man mano che un ciclo di agenti cresce, quel compromesso si ripete in ogni chiamata.

AIHubMix fornisce un endpoint compatibile con OpenAI attraverso un ampio catalogo di modelli. Un'integrazione SDK OpenAI esistente può puntare a AIHubMix cambiando la chiave API e base_url:

from openai import OpenAI

client = OpenAI(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com/v1",
)

response = client.chat.completions.create(
    model="auto:balanced",
    messages=[
        {"role": "user", "content": "Classifica questa richiesta e proponi il prossimo passo."}
    ],
)

Impostare model su auto sposta la selezione del modello nel percorso della richiesta. Il router analizza il compito e lo risolve a un modello adatto. Un suffisso di policy rende esplicito l'obiettivo di ottimizzazione:

Il routing non aggiunge una tariffa separata. La richiesta viene fatturata al prezzo di listino del modello che l'ha effettivamente gestita. Il modello risolto e i dettagli del routing sono esposti nella risposta, incluso l'intestazione X-Aihubmix-Router-Resolved-Model, quindi la decisione rimane osservabile piuttosto che diventare una scatola nera.

Il comportamento completo, gli endpoint supportati, le politiche e le attuali limitazioni sono documentati nella guida AIHubMix LLM Router.

Il routing dei modelli non fornisce dati live a un agente

Dopo che il routing del modello è stato configurato, l'agente può scegliere un cervello migliore per ogni passaggio. Non può comunque sapere cosa è cambiato dopo i dati di addestramento del modello, accedere a un sistema aziendale privato o eseguire un'azione in un'altra applicazione a meno che uno strumento non fornisca tale capacità.

Questo è il punto in cui molti progetti di agenti accumulano codice fragile. Un team collega un'API di ricerca, poi un'API di scraping, poi un'API di arricchimento. Ogni integrazione introduce un altro account, credenziali, formato di richiesta, modello di errore e relazione di fatturazione. Le descrizioni degli strumenti vengono spesso copiate in un prompt di sistema e lentamente diventano obsolete.

Il modo di fallimento è pericoloso perché può sembrare di successo. Un modello può produrre una chiamata plausibile contro uno schema obsoleto, ricevere una risposta incompleta e continuare come se il compito fosse riuscito. L'ispezione dello schema in tempo di esecuzione è più sicura che chiedere al modello di ricordare un contratto API dall'addestramento o da un vecchio prompt.

Il livello degli strumenti dovrebbe quindi rispondere a tre domande prima dell'esecuzione:

1. Quale strumento può soddisfare questo obiettivo?
2. Quale schema e prezzo si applicano in questo momento?
3. Quale risultato ha effettivamente restituito la chiamata?

La scoperta degli strumenti è il secondo livello di routing

Monid trasforma l'accesso agli strumenti in un flusso di lavoro di scoperta-ispezione-esecuzione. Invece di richiedere allo sviluppatore di prevedere ogni API di cui un agente potrebbe avere bisogno, l'agente può cercare un catalogo in linguaggio naturale, ispezionare il contratto di un candidato ed eseguire l'endpoint selezionato.

Il flusso di base appare così:

# 1. Trova strumenti che corrispondono all'obiettivo
monid discover -q "trova i prezzi attuali dei prodotti da una pagina web pubblica"

# 2. Leggi lo schema e i prezzi dell'endpoint selezionato
monid inspect -p PROVIDER_SLUG -e ENDPOINT_PATH

# 3. Esegui solo dopo che l'agente ha controllato il contratto
monid run -p PROVIDER_SLUG -e ENDPOINT_PATH \
  --query '{"url":"https://example.com/product"}'

La scoperta e l'ispezione consentono all'agente di confrontare le opzioni prima di spendere qualcosa. L'esecuzione viene fatturata in base al modello di prezzo dell'endpoint selezionato. Lo sviluppatore mantiene un'integrazione mentre l'agente guadagna accesso a strumenti attraverso più fornitori.

Per i runtime degli agenti che possono leggere le istruzioni di configurazione, Monid pubblica anche una skill leggibile dalla macchina:

Imposta https://monid.ai/SKILL.md

La documentazione del flusso di lavoro di Monid spiega le fasi di catalogo, ispezione ed esecuzione in maggior dettaglio.

Come i due livelli lavorano insieme

Il gateway del modello e il livello degli strumenti dovrebbero rimanere componenti separati con un piccolo passaggio esplicito:

1. L'agente riceve un obiettivo dell'utente.
2. AIHubMix instrada una chiamata di pianificazione a un modello appropriato.
3. Il piano identifica informazioni mancanti o un'azione esterna richiesta.
4. Monid scopre strumenti candidati ed espone i loro schemi e prezzi.
5. L'agente seleziona ed esegue uno strumento all'interno delle sue autorizzazioni e budget.
6. Lo strumento restituisce fatti o un risultato dell'azione.
7. AIHubMix instrada la chiamata di sintesi secondo la qualità, il costo o la latenza richiesti.
8. L'agente restituisce una risposta basata sul risultato dello strumento.

In Python semplificato, le chiamate dal lato del modello possono rimanere invariate mentre il risultato dello strumento viene inserito come contesto:

from openai import OpenAI

client = OpenAI(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com/v1",
)

# Un modello veloce è sufficiente per un passaggio di pianificazione leggero.
plan = client.chat.completions.create(
    model="auto:latency_critical",
    messages=[
        {
            "role": "user",
            "content": "Pianifica come confrontare i prezzi attuali di questi prodotti.",
        }
    ],
)

# Il tuo agente utilizza Monid per scoprire, ispezionare ed eseguire uno strumento appropriato.
# Sostituisci questi segnaposto con il risultato strutturato restituito da quella chiamata.
tool_result = {
    "source": "<source-url>",
    "data": "<structured-tool-result>",
}

report = client.chat.completions.create(
    model="auto:quality_first",
    messages=[
        {
            "role": "system",
            "content": (
                "Scrivi un confronto conciso. Usa solo il risultato dello strumento fornito, "
                "preserva gli URL di origine e indica quando un valore è mancante."
            ),
        },
        {"role": "user", "content": str(tool_result)},
    ],
)

Il dettaglio importante non è il numero di righe. È che nessuna scelta deve essere permanentemente incorporata nella logica dell'applicazione. Il modello può cambiare man mano che il prompt cambia, e lo strumento può cambiare man mano che il compito cambia.

I controlli dei costi appartengono a entrambi i livelli

I costi del modello e degli strumenti utilizzano unità diverse, quindi dovrebbero essere misurati separatamente.

Nel livello del modello, il modello risolto determina il prezzo per token. AIHubMix rende quella decisione tracciabile e consente agli sviluppatori di scegliere una politica di routing o limitare i modelli che una chiave API è autorizzata a utilizzare. I passaggi di routine possono favorire il costo o la latenza, mentre gli output rivolti all'utente possono favorire la qualità.

Nel livello degli strumenti, un endpoint può addebitare per chiamata o per risultato. Monid espone i prezzi durante l'ispezione, prima dell'esecuzione. Un agente può rifiutare un endpoint che supera il suo budget, preferire un'opzione verificata o chiedere approvazione prima di un'operazione insolitamente costosa.

I controlli di produzione utili includono:

• Una lista di modelli consentiti o un tetto di prezzo per ciascuna chiave API.
• Un budget massimo per chiamata di strumenti per compito.
• Liste di fornitori o endpoint per dati regolamentati.
• Log che collegano la decisione di routing del modello alla chiamata dello strumento e alla risposta finale.
• Conferma esplicita prima di azioni irreversibili o sensibili.
• Validazione dell'output in modo che i dati dello strumento siano trattati come input non attendibili, non come istruzioni.

Questa divisione rende anche più facile il debug dei costi. Se un'esecuzione diventa costosa, i log dei token mostrano se l'agente ha ragionato troppo, mentre i log degli strumenti mostrano se ha recuperato troppo. Le soluzioni sono diverse, e l'architettura dovrebbe preservare quella distinzione.

L'affidabilità richiede contratti freschi e decisioni visibili

La selezione dinamica non dovrebbe significare un comportamento imprevedibile.

Dal lato del modello, AIHubMix riporta il modello risolto e la politica di routing per ogni richiesta. La coerenza della sessione può preservare la consistenza del modello e i benefici della cache del prompt attraverso lavori multi-turno, mentre il comportamento di fallback può allontanarsi da un modello malsano quando necessario.

Dal lato degli strumenti, l'agente ispeziona lo schema dell'endpoint attuale prima di effettuare una chiamata a pagamento. I risultati della scoperta includono le informazioni necessarie per confrontare i candidati, e il risultato della chiamata effettiva diventa l'unica prova esterna passata nella completamento finale.

Insieme, questi controlli creano una utile traccia di audit:

obiettivo dell'utente
  -> decisione di routing e modello risolto
  -> strumenti candidati scoperti
  -> schema e prezzo ispezionati
  -> endpoint selezionato e risultato
  -> decisione finale del modello e risposta basata

Quella traccia è più preziosa che avere semplicemente accesso a molti modelli o molte API. Spiega perché l'agente ha fatto ogni scelta e quale prova ha supportato la sua risposta.

Quando non hai bisogno di entrambi i livelli

Non ogni flusso di lavoro beneficia della scelta in tempo di esecuzione.

Se un'applicazione invia un prompt stabile a un modello benchmarkato, specificare quel modello direttamente è più semplice e più deterministico rispetto al routing. Se un pipeline programmato chiama sempre una API nota, integrare quell'API direttamente può essere più chiaro rispetto all'aggiunta di un livello di scoperta.

L'architettura a due livelli guadagna il suo posto quando la varietà fa parte del carico di lavoro:

• I prompt differiscono a tal punto che il miglior modello cambia a seconda del passaggio.
• Gli agenti effettuano più chiamate a modelli e devono controllare il costo cumulativo o la latenza.
• Gli strumenti richiesti non possono essere completamente previsti al momento della costruzione.
• I dati esterni devono essere attuali e la loro fonte deve essere visibile.
• Il team desidera aggiungere capacità senza aggiungere una nuova integrazione con un fornitore per ciascuna.

Utilizza il livello del modello, il livello degli strumenti o entrambi in base alle decisioni che la tua applicazione deve effettivamente prendere.

Costruisci l'agente attorno alle decisioni, non alle dipendenze

Un agente AI in produzione non è definito da quanti modelli o API può raggiungere. È definito da se può scegliere la giusta capacità per il passaggio attuale, operare all'interno di un budget e spiegare cosa è successo.

AIHubMix fornisce all'agente un endpoint unificato per i modelli e routing in tempo di richiesta attraverso costi, qualità e priorità di latenza. Monid gli fornisce scoperta degli strumenti in esecuzione, schemi attuali, prezzi visibili ed esecuzione attraverso fornitori esterni.

Un livello decide come l'agente pensa. L'altro decide come scopre e agisce. Mantenere separate queste decisioni produce un agente più facile da estendere, osservare e controllare.

Inizia con il AIHubMix quick start, poi collega il lato degli strumenti attraverso Monid.

FAQ

Cos'è il routing dei modelli per gli agenti AI?

Il routing dei modelli seleziona un modello per ogni richiesta in base a fattori come tipo di compito, capacità, costo e latenza. Con AIHubMix, impostare model su auto o una policy come auto:quality_first abilita la selezione in tempo di richiesta mantenendo un'API compatibile con OpenAI.

Perché un agente AI ha bisogno di strumenti se il LLM ha già conoscenza?

Un LLM genera risposte dal contesto che riceve e da ciò che ha appreso durante l'addestramento. Non può sapere in modo affidabile i prezzi attuali, interrogare un database privato o eseguire un'azione esterna senza uno strumento connesso. Gli strumenti forniscono dati live ed esecuzione; il modello pianifica e interpreta il risultato.

Un gateway di modelli è lo stesso di un server MCP o di una piattaforma di strumenti?

No. Un gateway di modelli instrada le richieste di inferenza ai modelli. I server MCP e le piattaforme di strumenti espongono capacità esterne a un agente. Risolvono problemi di integrazione complementari e possono essere utilizzati insieme.

Possono AIHubMix e Monid essere utilizzati indipendentemente?

Sì. AIHubMix può instradare chiamate ai modelli per applicazioni senza requisiti dinamici per gli strumenti. Monid può fornire scoperta degli strumenti a agenti che utilizzano un altro fornitore di modelli o gateway. Utilizzare entrambi è utile quando un agente ha bisogno di scelta in tempo di esecuzione in entrambi i livelli.

Come posso mantenere il routing automatico auditabile?

Registra il modello risolto, la politica di routing, il candidato dello strumento, il prezzo ispezionato, l'endpoint selezionato e il risultato restituito per ogni compito. AIHubMix espone i dettagli del routing del modello nella risposta, mentre Monid separa la scoperta e l'ispezione dall'esecuzione in modo che la decisione dello strumento possa essere registrata prima della chiamata a pagamento.