Como criar sistemas multiagentes prontos para produção com Agno e Milvus

Se você está criando agentes de IA, provavelmente já bateu nesta parede: sua demonstração funciona muito bem, mas colocá-la em produção é uma história totalmente diferente.

Cobrimos o gerenciamento de memória do agente e o reranking em publicações anteriores. Agora vamos enfrentar o maior desafio: criar agentes que realmente se sustentem na produção.

A realidade é a seguinte: os ambientes de produção são confusos. Um único agente raramente dá conta do recado, e é por isso que os sistemas multiagentes estão por toda parte. Mas os frameworks disponíveis hoje tendem a cair em dois campos: os leves que demonstram bem, mas quebram sob carga real, ou os poderosos que levam uma eternidade para aprender e construir.

Eu tenho experimentado o Agno recentemente, e ele parece atingir um meio termo razoável - focado na prontidão de produção sem complexidade excessiva. O projeto ganhou mais de 37.000 estrelas no GitHub em poucos meses, o que sugere que outros desenvolvedores também o consideram útil.

Neste post, eu vou compartilhar o que eu aprendi enquanto construía um sistema multi-agente usando Agno com Milvus como camada de memória. Veremos como o Agno se compara a alternativas como o LangGraph e uma implementação completa que pode experimentar.

O que é o Agno?

Agno é uma estrutura multi-agente construída especificamente para uso em produção. Ele tem duas camadas distintas:

• Camada de estrutura Agno: Onde se define a lógica do agente

• Camada de tempo de execução do AgentOS: Transforma essa lógica em serviços HTTP que você pode realmente implantar

Pense da seguinte maneira: a camada de estrutura define o que os agentes devem fazer, enquanto o AgentOS lida com a forma como esse trabalho é executado e servido.

A camada de estrutura

É com ela que você trabalha diretamente. Ela introduz três conceitos principais:

• Agente: lida com um tipo específico de tarefa

• Equipa: Coordena vários agentes para resolver problemas complexos

• Fluxo de trabalho: Define a ordem e a estrutura de execução

Uma coisa que apreciei: não é necessário aprender uma nova DSL ou desenhar fluxogramas. O comportamento do agente é definido usando chamadas de função Python padrão. A estrutura lida com a invocação LLM, execução de ferramentas e gerenciamento de memória.

A camada de tempo de execução do AgentOS

O AgentOS foi projetado para grandes volumes de solicitação por meio da execução assíncrona, e sua arquitetura sem estado torna o escalonamento simples.

Os principais recursos incluem:

• Integração FastAPI incorporada para expor agentes como pontos de extremidade HTTP

• Gerenciamento de sessão e respostas de streaming

• Monitorização de pontos finais

• Suporte a escalonamento horizontal

Na prática, o AgentOS lida com a maior parte do trabalho de infraestrutura, o que permite que você se concentre na lógica do agente em si.

Uma visão de alto nível da arquitetura do Agno é mostrada abaixo.

Agno vs. LangGraph

Para entender onde o Agno se encaixa, vamos compará-lo com o LangGraph - um dos frameworks multiagentes mais usados.

O LangGraph usa uma máquina de estados baseada em gráficos. O fluxo de trabalho completo do agente é modelado como um gráfico: as etapas são nós, os caminhos de execução são arestas. Isto funciona bem quando o seu processo é fixo e estritamente ordenado. Mas para cenários abertos ou de conversação, pode parecer restritivo. À medida que as interações se tornam mais dinâmicas, manter um gráfico limpo torna-se mais difícil.

O Agno adota uma abordagem diferente. Em vez de ser uma camada de orquestração pura, é um sistema de ponta a ponta. Defina o comportamento do agente, e o AgentOS o expõe automaticamente como um serviço HTTP pronto para produção, com monitoramento, escalabilidade e suporte a conversas de várias voltas incorporado. Sem gateway de API separado, sem gerenciamento de sessão personalizado, sem ferramentas operacionais extras.

Aqui está uma comparação rápida:

Dimensão	LangGraph	Agno
Modelo de orquestração	Definição explícita do gráfico usando nós e arestas	Fluxos de trabalho declarativos definidos em Python
Gestão de estados	Classes de estado personalizadas definidas e geridas pelos programadores	Sistema de memória incorporado
Depuração e observabilidade	LangSmith (pago)	AgentOS UI (código aberto)
Modelo de tempo de execução	Integrado num tempo de execução existente	Serviço autónomo baseado na FastAPI
Complexidade da implementação	Requer configuração adicional através do LangServe	Funciona de imediato

O LangGraph dá-lhe mais flexibilidade e controlo mais preciso. O Agno optimiza o tempo de produção mais rápido. A escolha certa depende do estágio do seu projeto, da infraestrutura existente e do nível de personalização que você precisa. Se não tiver a certeza, executar uma pequena prova de conceito com ambos é provavelmente a forma mais fiável de decidir.

Escolhendo Milvus para a camada de memória do agente

Depois de escolher uma estrutura, a próxima decisão é como armazenar a memória e o conhecimento. Para isso, usamos o Milvus. O Milvus é o banco de dados vetorial de código aberto mais popular criado para cargas de trabalho de IA, com mais de 42.000 estrelas no GitHub.

A Agno tem suporte nativo ao Milvus. O módulo agno.vectordb.milvus envolve recursos de produção como gerenciamento de conexão, novas tentativas automáticas, gravações em lote e geração de incorporação. Não precisa de construir pools de ligação ou lidar com falhas de rede - algumas linhas de Python dão-lhe uma camada de memória vetorial funcional.

O Milvus se adapta às suas necessidades. Ele suporta três modos de implantação:

• Milvus Lite: Leve, baseado em arquivos - ótimo para desenvolvimento e testes locais

• Autónomo: Implantação de servidor único para cargas de trabalho de produção

• Distribuído: Cluster completo para cenários de alta escala

É possível começar com o Milvus Lite para validar a memória do agente localmente e, em seguida, passar para autônomo ou distribuído à medida que o tráfego cresce - sem alterar o código do aplicativo. Essa flexibilidade é especialmente útil quando você está iterando rapidamente nos estágios iniciais, mas precisa de um caminho claro para escalar mais tarde.

Passo a passo: Criando um agente Agno pronto para produção com Milvus

Vamos criar um agente pronto para produção do zero.

Começaremos com um exemplo simples de agente único para mostrar o fluxo de trabalho completo. Em seguida, vamos expandi-lo para um sistema multiagente. O AgentOS empacotará tudo automaticamente como um serviço HTTP chamável.

1. Implantação do Milvus Standalone com o Docker

(1) Baixe os arquivos de implantação

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

(2) Iniciar o serviço Milvus

docker-compose up -d

docker-compose ps -a

2. Implementação do núcleo

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) Executando o agente

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

3. Ligar à consola do AgentOS

https://os.agno.com/

(1) Criar uma conta e iniciar sessão

(2) Ligar o agente ao AgentOS

(3) Configurar a porta exposta e o nome do agente

(4) Adicionar documentos e indexá-los no Milvus

(5) Testar o agente de ponta a ponta

Nesta configuração, o Milvus trata da recuperação semântica de alto desempenho. Quando o assistente da base de conhecimentos recebe uma pergunta técnica, invoca a ferramenta search_knowledge para incorporar a consulta, recupera os fragmentos de documentos mais relevantes do Milvus e utiliza esses resultados como base para a sua resposta.

O Milvus oferece três opções de implementação, permitindo-lhe escolher uma arquitetura que se adeqúe aos seus requisitos operacionais, mantendo as APIs ao nível da aplicação consistentes em todos os modos de implementação.

A demonstração acima mostra o fluxo principal de recuperação e geração. No entanto, para passar esta conceção para um ambiente de produção, é necessário discutir mais pormenorizadamente vários aspectos da arquitetura.

Como os resultados da recuperação são compartilhados entre os agentes

O modo Team do Agno tem uma opção share_member_interactions=True que permite que os agentes posteriores herdem o histórico completo de interação dos agentes anteriores. Na prática, isso significa que quando o primeiro agente recupera informações do Milvus, os agentes subsequentes podem reutilizar esses resultados em vez de executar a mesma pesquisa novamente.

• A vantagem: Os custos de recuperação são amortizados por toda a equipa. Uma pesquisa vetorial suporta vários agentes, reduzindo as consultas redundantes.

• O lado negativo: A qualidade da recuperação é ampliada. Se a pesquisa inicial retornar resultados incompletos ou imprecisos, esse erro se propaga para todos os agentes que dependem dela.

É por isso que a precisão da recuperação é ainda mais importante em sistemas multiagentes. Uma recuperação incorrecta não prejudica apenas a resposta de um agente, mas afecta toda a equipa.

Aqui está um exemplo de configuração de equipa:

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*
)

Porque é que o Agno e o Milvus são colocados em camadas separadas

Nesta arquitetura, o Agno situa-se na camada de conversação e orquestração. É responsável pela gestão do fluxo de diálogo, pela coordenação dos agentes e pela manutenção do estado da conversação, com o histórico da sessão guardado numa base de dados relacional. O conhecimento real do domínio do sistema - tal como a documentação do produto e os relatórios técnicos - é tratado separadamente e armazenado como vetor de incorporação em Milvus. Esta divisão clara mantém a lógica de conversação e o armazenamento de conhecimento totalmente desacoplados.

Porque é que isto é importante em termos operacionais:

• Escalonamento independente: À medida que a demanda do Agno cresce, adicione mais instâncias do Agno. À medida que o volume de consultas aumenta, expanda o Milvus adicionando nós de consulta. Cada camada é dimensionada de forma isolada.

• Necessidades de hardware diferentes: O Agno é limitado pela CPU e pela memória (inferência LLM, execução do fluxo de trabalho). O Milvus é otimizado para recuperação vetorial de alto rendimento (E/S de disco, às vezes aceleração de GPU). Separá-los evita a contenção de recursos.

• Otimização de custos: É possível ajustar e alocar recursos para cada camada de forma independente.

Essa abordagem em camadas oferece uma arquitetura mais eficiente, resiliente e pronta para produção.

O que monitorar ao usar o Agno com o Milvus

O Agno possui recursos de avaliação integrados, mas a adição do Milvus amplia o que deve ser observado. Com base na nossa experiência, concentre-se em três áreas:

• Qualidade da recuperação: Os documentos devolvidos pelo Milvus são realmente relevantes para a consulta ou apenas superficialmente semelhantes ao nível do vetor?

• Fidelidade da resposta: A resposta final é fundamentada no conteúdo recuperado ou o LLM está a gerar afirmações sem fundamento?

• Repartição da latência de ponta a ponta: Não se limite a registar o tempo total de resposta. Divida-o por fase - geração de embedding, pesquisa de vectores, montagem de contexto, inferência LLM - para que possa identificar onde ocorrem os abrandamentos.

Um exemplo prático: Quando a sua coleção Milvus cresce de 1 milhão para 10 milhões de vectores, pode notar que a latência de recuperação aumenta. Isso geralmente é um sinal para ajustar os parâmetros do índice (como nlist e nprobe) ou considerar a mudança de uma implantação autônoma para uma distribuída.

Conclusão

A criação de sistemas de agentes prontos para a produção exige mais do que a ligação de chamadas LLM e demonstrações de recuperação. São necessários limites arquitectónicos claros, uma infraestrutura que seja dimensionada de forma independente e observabilidade para detetar problemas atempadamente.

Neste post, mostrei como o Agno e o Milvus podem trabalhar juntos: Agno para orquestração multiagente, Milvus para memória escalável e recuperação semântica. Ao manter essas camadas separadas, é possível passar do protótipo para a produção sem reescrever a lógica central - e escalar cada componente conforme necessário.

Se estiver a experimentar configurações semelhantes, gostaria de saber o que está a funcionar para si.

Perguntas sobre o Milvus? Junte-se ao nosso canal Slack ou marque uma sessão de 20 minutos do Milvus Office Hours.