Come costruire sistemi multi-agente pronti per la produzione con Agno e Milvus

Se state costruendo agenti di intelligenza artificiale, probabilmente vi siete scontrati con questo muro: la vostra demo funziona benissimo, ma portarla in produzione è tutta un'altra storia.

Abbiamo trattato la gestione della memoria degli agenti e il reranking nei post precedenti. Ora affrontiamo la sfida più grande: costruire agenti che reggano davvero in produzione.

La realtà è che gli ambienti di produzione sono disordinati. Un singolo agente raramente è sufficiente, ed è per questo che i sistemi multiagente sono ovunque. Ma i framework disponibili oggi tendono a dividersi in due campi: quelli leggeri che funzionano bene ma si rompono sotto carico reale, o quelli potenti che richiedono un'eternità per essere appresi e costruiti.

Di recente ho sperimentato Agno, che sembra trovare una ragionevole via di mezzo, concentrandosi sulla prontezza di produzione senza eccessiva complessità. Il progetto ha guadagnato oltre 37.000 stelle su GitHub in pochi mesi, il che suggerisce che anche altri sviluppatori lo trovano utile.

In questo post, condividerò ciò che ho imparato costruendo un sistema multi-agente utilizzando Agno con Milvus come livello di memoria. Vedremo come Agno si confronta con alternative come LangGraph e vedremo un'implementazione completa che potrete provare voi stessi.

Che cos'è Agno?

Agno è un framework multi-agente costruito appositamente per l'uso in produzione. Ha due livelli distinti:

• Livello del framework Agno: Dove si definisce la logica dell'agente

• Livello di runtime AgentOS: Trasforma questa logica in servizi HTTP che si possono effettivamente distribuire.

Il livello framework definisce ciò che gli agenti devono fare, mentre AgentOS gestisce il modo in cui il lavoro viene eseguito e servito.

Il livello di struttura

È quello con cui si lavora direttamente. Introduce tre concetti fondamentali:

• Agente: gestisce un tipo specifico di attività

• Team: Coordina più agenti per risolvere problemi complessi

• Flusso di lavoro: Definisce l'ordine di esecuzione e la struttura

Una cosa che ho apprezzato: non è necessario imparare un nuovo DSL o disegnare diagrammi di flusso. Il comportamento dell'agente è definito utilizzando chiamate di funzione Python standard. Il framework gestisce l'invocazione di LLM, l'esecuzione degli strumenti e la gestione della memoria.

Il livello di runtime di AgentOS

AgentOS è progettato per volumi elevati di richieste attraverso l'esecuzione asincrona e la sua architettura stateless rende semplice la scalabilità.

Le caratteristiche principali includono:

• Integrazione FastAPI integrata per esporre gli agenti come endpoint HTTP.

• Gestione delle sessioni e risposte in streaming

• Endpoint di monitoraggio

• Supporto per lo scaling orizzontale

In pratica, AgentOS gestisce la maggior parte dell'infrastruttura, consentendo di concentrarsi sulla logica dell'agente.

Di seguito è riportata una vista di alto livello dell'architettura di Agno.

Agno vs LangGraph

Per capire dove si colloca Agno, facciamo un confronto con LangGraph, uno dei framework multi-agente più diffusi.

LangGraph utilizza una macchina a stati basata su grafi. L'intero flusso di lavoro dell'agente viene modellato come un grafo: i passi sono nodi, i percorsi di esecuzione sono bordi. Questo funziona bene quando il processo è fisso e strettamente ordinato. Ma per gli scenari aperti o di conversazione, può risultare restrittivo. Quando le interazioni diventano più dinamiche, mantenere un grafo pulito diventa più difficile.

Agno adotta un approccio diverso. Invece di essere un puro livello di orchestrazione, è un sistema end-to-end. Definite il comportamento dell'agente e AgentOS lo espone automaticamente come servizio HTTP pronto per la produzione, con monitoraggio, scalabilità e supporto per le conversazioni a più turni. Nessun gateway API separato, nessuna gestione personalizzata delle sessioni, nessuno strumento operativo aggiuntivo.

Ecco un rapido confronto:

Dimensione	LangGraph	Agno
Modello di orchestrazione	Definizione esplicita del grafo tramite nodi e bordi	Flussi di lavoro dichiarativi definiti in Python
Gestione degli stati	Classi di stato personalizzate definite e gestite dagli sviluppatori	Sistema di memoria incorporato
Debug e osservabilità	LangSmith (a pagamento)	AgentOS UI (open source)
Modello di runtime	Integrato in un runtime esistente	Servizio autonomo basato su FastAPI
Complessità di distribuzione	Richiede una configurazione aggiuntiva tramite LangServe	Funziona già dalla scatola

LangGraph offre maggiore flessibilità e controllo a grana fine. Agno ottimizza il time-to-production. La scelta giusta dipende dalla fase del progetto, dall'infrastruttura esistente e dal livello di personalizzazione necessario. Se non si è sicuri, eseguire un piccolo proof of concept con entrambi è probabilmente il modo più affidabile per decidere.

Scegliere Milvus per il livello di memoria dell'agente

Una volta scelto il framework, la decisione successiva è come memorizzare la memoria e la conoscenza. Per questo usiamo Milvus. Milvus è il più popolare database vettoriale open-source costruito per i carichi di lavoro dell'intelligenza artificiale, con oltre 42.000 stelle su GitHub.

Agno ha un supporto nativo per Milvus. Il modulo agno.vectordb.milvus racchiude funzionalità di produzione come la gestione delle connessioni, i tentativi automatici, le scritture in batch e la generazione di embedding. Non è necessario creare pool di connessioni o gestire da soli i guasti della rete: poche righe di Python forniscono un livello di memoria vettoriale funzionante.

Milvus si adatta alle vostre esigenze. Supporta tre modalità di distribuzione:

• Milvus Lite: Leggero, basato su file, ottimo per lo sviluppo e i test locali.

• Standalone: Distribuzione a server singolo per carichi di lavoro di produzione

• Distribuito: Cluster completo per scenari su larga scala

È possibile iniziare con Milvus Lite per convalidare la memoria dell'agente a livello locale, quindi passare allo standalone o al distribuito man mano che il traffico cresce, senza modificare il codice dell'applicazione. Questa flessibilità è particolarmente utile quando si sta iterando rapidamente nelle fasi iniziali, ma si ha bisogno di un percorso chiaro per scalare in seguito.

Passo dopo passo: Creare un agente Agno pronto per la produzione con Milvus

Costruiamo da zero un agente pronto per la produzione.

Inizieremo con un semplice esempio di agente singolo per mostrare il flusso di lavoro completo. Poi lo espanderemo in un sistema multi-agente. AgentOS confezionerà automaticamente tutto come servizio HTTP richiamabile.

1. Distribuzione di Milvus Standalone con Docker

(1) Scaricare i file di distribuzione

**wget** **
<https://github.com/Milvus-io/Milvus/releases/download/v2.****5****.****12****/Milvus-standalone-docker-compose.yml> -O docker-compose.yml**

(2) Avviare il servizio Milvus

docker-compose up -d

docker-compose ps -a

2. Implementazione del nucleo

import os
from pathlib import Path
from agno.os import AgentOS
from agno.agent import Agent
from agno.models.openai import OpenAIChat
from agno.knowledge.knowledge import Knowledge
from agno.vectordb.milvus import Milvus
from agno.knowledge.embedder.openai import OpenAIEmbedder
from agno.db.sqlite import SqliteDb
os.environ\["OPENAI_API_KEY"\] = "you-key-here"
data_dir = Path("./data")
data_dir.mkdir(exist_ok=True)
knowledge_base = Knowledge(
    contents_db=SqliteDb(
        db_file=str(data_dir / "knowledge_contents.db"),
        knowledge_table="knowledge_contents",
    ),
    vector_db=Milvus(
        collection="agno_knowledge",
        uri="http://192.168.x.x:19530",
        embedder=OpenAIEmbedder(id="text-embedding-3-small"),
    ),
)
*# Create Agent*
agent = Agent(
    name="Knowledge Assistant",
    model=OpenAIChat(id="gpt-4o"),
    instructions=\[
        "You are a knowledge base assistant that helps users query and manage knowledge base content.",
        "Answer questions in English.",
        "Always search the knowledge base before answering questions.",
        "If the knowledge base is empty, kindly prompt the user to upload documents."
    \],
    knowledge=knowledge_base,
    search_knowledge=True,
    db=SqliteDb(
        db_file=str(data_dir / "agent.db"),
        session_table="agent_sessions",
    ),
    add_history_to_context=True,
    markdown=True,
)
agent_os = AgentOS(agents=\[agent\])
app = agent_os.get_app()
if __name__ == "__main__":
    print("\n🚀 Starting service...")
    print("📍 http://localhost:7777")
    print("💡 Please upload documents to the knowledge base in the UI\n")
    agent_os.serve(app="knowledge_agent:app", port=7777, reload=False)

(1) Esecuzione dell'agente

**python** **knowledge_agent.py**

3. Connessione alla console AgentOS

https://os.agno.com/

(1) Creare un account e accedere

(2) Collegare l'agente ad AgentOS

(3) Configurare la porta esposta e il nome dell'agente

(4) Aggiungere documenti e indicizzarli in Milvus

(5) Testare l'agente end-to-end

In questa configurazione, Milvus gestisce il recupero semantico ad alte prestazioni. Quando l'assistente della base di conoscenza riceve una domanda tecnica, richiama lo strumento search_knowledge per incorporare la domanda, recupera i pezzi di documento più rilevanti da Milvus e utilizza questi risultati come base per la sua risposta.

Milvus offre tre opzioni di implementazione, che consentono di scegliere l'architettura più adatta alle proprie esigenze operative, mantenendo le API a livello di applicazione coerenti in tutte le modalità di implementazione.

La demo qui sopra mostra il flusso principale di recupero e generazione. Per trasferire questo progetto in un ambiente di produzione, tuttavia, è necessario approfondire alcuni aspetti architettonici.

Come i risultati del reperimento vengono condivisi tra gli agenti

La modalità Team di Agno ha un'opzione share_member_interactions=True che consente agli agenti successivi di ereditare l'intera cronologia delle interazioni degli agenti precedenti. In pratica, ciò significa che quando il primo agente recupera informazioni da Milvus, gli agenti successivi possono riutilizzare quei risultati invece di eseguire nuovamente la stessa ricerca.

• Il vantaggio: I costi di ricerca vengono ammortizzati tra i membri del team. Una ricerca vettoriale supporta più agenti, riducendo le query ridondanti.

• Il lato negativo: La qualità del recupero viene amplificata. Se la ricerca iniziale restituisce risultati incompleti o imprecisi, l'errore si propaga a tutti gli agenti che dipendono da essa.

Ecco perché l'accuratezza del reperimento è ancora più importante nei sistemi multiagente. Un cattivo reperimento non degrada solo la risposta di un agente, ma si ripercuote sull'intero team.

Ecco un esempio di configurazione del team:

from agno.team import Team
analyst = Agent(
    name="Data Analyst",
    model=OpenAIChat(id="gpt-4o"),
    knowledge=knowledge_base,
    search_knowledge=True,
    instructions=\["Analyze data and extract key metrics"\]
)
writer = Agent(
    name="Report Writer",
    model=OpenAIChat(id="gpt-4o"),
    knowledge=knowledge_base,
    search_knowledge=True,
    instructions=\["Write reports based on the analysis results"\]
)
team = Team(
    agents=\[analyst, writer\],
    share_member_interactions=True,  *# Share knowledge retrieval results*
)

Perché Agno e Milvus sono stratificati separatamente

In questa architettura, Agno si trova al livello di conversazione e orchestrazione. È responsabile della gestione del flusso di dialogo, del coordinamento degli agenti e del mantenimento dello stato delle conversazioni, con la cronologia delle sessioni memorizzata in un database relazionale. La conoscenza effettiva del dominio del sistema, come la documentazione del prodotto e i rapporti tecnici, viene gestita separatamente e memorizzata come embeddings vettoriali in Milvus. Questa chiara divisione mantiene la logica di conversazione e l'archiviazione della conoscenza completamente disaccoppiate.

Perché questo è importante dal punto di vista operativo:

• Scalabilità indipendente: Quando la domanda di Agno cresce, si aggiungono altre istanze Agno. Quando il volume delle interrogazioni cresce, si espande Milvus aggiungendo nodi di interrogazione. Ogni livello scala in modo isolato.

• Esigenze hardware diverse: Agno è legato alla CPU e alla memoria (inferenza LLM, esecuzione del flusso di lavoro). Milvus è ottimizzato per il recupero vettoriale ad alta velocità (I/O su disco, talvolta accelerazione GPU). La loro separazione evita la contesa delle risorse.

• Ottimizzazione dei costi: È possibile sintonizzare e allocare le risorse per ogni livello in modo indipendente.

Questo approccio a strati consente di ottenere un'architettura più efficiente, resiliente e pronta per la produzione.

Cosa monitorare quando si utilizza Agno con Milvus

Agno dispone di funzionalità di valutazione integrate, ma l'aggiunta di Milvus amplia gli aspetti da tenere sotto controllo. In base alla nostra esperienza, è bene concentrarsi su tre aree:

• Qualità del recupero: I documenti restituiti da Milvus sono effettivamente rilevanti per la query o solo superficialmente simili a livello vettoriale?

• Fedeltà della risposta: La risposta finale è basata sul contenuto recuperato o l'LLM genera affermazioni non supportate?

• Analisi della latenza end-to-end: Non limitatevi a tenere traccia del tempo di risposta totale. Suddividetelo per fasi - generazione dell'embedding, ricerca del vettore, assemblaggio del contesto, inferenza dell'LLM - in modo da poter identificare i punti in cui si verificano i rallentamenti.

Un esempio pratico: Quando la vostra collezione Milvus passa da 1 milione a 10 milioni di vettori, potreste notare un aumento della latenza di recupero. Questo di solito è un segnale per mettere a punto i parametri dell'indice (come nlist e nprobe) o per considerare la possibilità di passare da un'implementazione standalone a una distribuita.

Conclusione

Per costruire sistemi di agenti pronti per la produzione non basta mettere insieme chiamate LLM e demo di recupero. Servono confini architettonici chiari, infrastrutture che scalino in modo indipendente e osservabilità per individuare tempestivamente i problemi.

In questo post ho illustrato come Agno e Milvus possono lavorare insieme: Agno per l'orchestrazione multi-agente, Milvus per la memoria scalabile e il recupero semantico. Mantenendo questi livelli separati, è possibile passare dal prototipo alla produzione senza riscrivere la logica di base e scalare ogni componente secondo le necessità.

Se state sperimentando configurazioni simili, sarei curioso di sapere cosa funziona per voi.

Domande su Milvus? Iscrivetevi al nostro canale Slack o prenotate una sessione di 20 minuti di Milvus Office Hours.