Comment construire des systèmes multi-agents prêts pour la production avec Agno et Milvus

Si vous avez construit des agents d'intelligence artificielle, vous vous êtes probablement heurté à ce mur : votre démo fonctionne très bien, mais la mise en production est une toute autre histoire.

Nous avons abordé la gestion de la mémoire des agents et le reranking dans des articles précédents. Abordons maintenant le défi le plus important : construire des agents qui tiennent la route en production.

La réalité est là : les environnements de production sont désordonnés. Un seul agent suffit rarement, c'est pourquoi les systèmes multi-agents sont omniprésents. Mais les frameworks disponibles aujourd'hui ont tendance à se diviser en deux camps : les plus légers qui font une bonne démonstration mais qui se cassent la figure sous une charge réelle, ou les plus puissants qui prennent une éternité à apprendre et à construire avec.

J'ai expérimenté Agno récemment, et il semble trouver un juste milieu - axé sur l'aptitude à la production sans complexité excessive. Le projet a gagné plus de 37 000 étoiles GitHub en quelques mois, ce qui suggère que d'autres développeurs le trouvent également utile.

Dans ce billet, je vais partager ce que j'ai appris en construisant un système multi-agent utilisant Agno avec Milvus comme couche mémoire. Nous verrons comment Agno se compare à des alternatives telles que LangGraph et nous passerons en revue une implémentation complète que vous pouvez essayer vous-même.

Qu'est-ce qu'Agno ?

Agno est un cadre multi-agents conçu spécifiquement pour une utilisation en production. Il comporte deux couches distinctes :

• La couche du cadre Agno: où vous définissez la logique de votre agent

• Couche d'exécution AgentOS: Transforme cette logique en services HTTP que vous pouvez réellement déployer.

Pensez-y de la manière suivante : la couche cadre définit ce que vos agents doivent faire, tandis qu'AgentOS s'occupe de la manière dont ce travail est exécuté et servi.

La couche cadre

C'est ce avec quoi vous travaillez directement. Elle introduit trois concepts fondamentaux :

• Agent: gère un type de tâche spécifique

• L'équipe: Coordination de plusieurs agents pour résoudre des problèmes complexes

• Le flux de travail: Définit l'ordre et la structure d'exécution

Une chose que j'ai appréciée : vous n'avez pas besoin d'apprendre un nouveau DSL ou de dessiner des organigrammes. Le comportement de l'agent est défini à l'aide d'appels de fonctions Python standard. Le cadre gère l'invocation du LLM, l'exécution des outils et la gestion de la mémoire.

La couche d'exécution AgentOS

AgentOS est conçu pour répondre à des volumes élevés de requêtes grâce à une exécution asynchrone, et son architecture sans état permet une mise à l'échelle simple.

Ses principales caractéristiques sont les suivantes

• Intégration FastAPI pour l'exposition d'agents en tant que points d'extrémité HTTP

• Gestion de session et réponses en continu

• Points d'extrémité de surveillance

• Prise en charge de la mise à l'échelle horizontale

En pratique, AgentOS prend en charge la plupart des tâches d'infrastructure, ce qui vous permet de vous concentrer sur la logique de l'agent lui-même.

Une vue de haut niveau de l'architecture d'Agno est présentée ci-dessous.

Agno vs. LangGraph

Pour comprendre la place d'Agno, comparons-le à LangGraph, l'un des frameworks multi-agents les plus utilisés.

LangGraph utilise une machine à états basée sur un graphe. Vous modélisez l'ensemble du flux de travail de votre agent sous la forme d'un graphe : les étapes sont des nœuds, les chemins d'exécution sont des arêtes. Cela fonctionne bien lorsque votre processus est fixe et strictement ordonné. Mais pour les scénarios ouverts ou conversationnels, cela peut sembler restrictif. Au fur et à mesure que les interactions deviennent plus dynamiques, il devient de plus en plus difficile de maintenir un graphe propre.

Agno adopte une approche différente. Au lieu d'être une couche d'orchestration pure, c'est un système de bout en bout. Définissez le comportement de votre agent et AgentOS l'expose automatiquement sous la forme d'un service HTTP prêt à la production, avec la surveillance, l'évolutivité et la prise en charge des conversations multi-tours intégrées. Pas de passerelle API séparée, pas de gestion de session personnalisée, pas d'outil opérationnel supplémentaire.

Voici une comparaison rapide :

Dimension	LangGraph	Agno
Modèle d'orchestration	Définition explicite du graphe à l'aide de nœuds et d'arêtes	Workflows déclaratifs définis en Python
Gestion des états	Classes d'état personnalisées définies et gérées par les développeurs	Système de mémoire intégré
Débogage et observabilité	LangSmith (payant)	AgentOS UI (open source)
Modèle d'exécution	Intégré dans un runtime existant	Service autonome basé sur FastAPI
Complexité du déploiement	Nécessite une configuration supplémentaire via LangServe	Fonctionne dès le départ

LangGraph vous offre plus de flexibilité et un contrôle plus fin. Agno optimise le temps de mise en production. Le bon choix dépend de l'état d'avancement de votre projet, de l'infrastructure existante et du niveau de personnalisation dont vous avez besoin. Si vous n'êtes pas sûr, l'exécution d'une petite démonstration de faisabilité avec les deux solutions est probablement le moyen le plus fiable de prendre une décision.

Choisir Milvus pour la couche mémoire de l'agent

Une fois que vous avez choisi un cadre, la prochaine décision est de savoir comment stocker la mémoire et les connaissances. Nous utilisons Milvus pour cela. Milvus est la base de données vectorielle open-source la plus populaire, conçue pour les charges de travail d'IA, avec plus de 42 000+ étoiles GitHub.

Agno prend en charge Milvus en natif. Le module agno.vectordb.milvus intègre des fonctionnalités de production telles que la gestion des connexions, les tentatives automatiques, les écritures par lots et la génération d'embedding. Vous n'avez pas besoin de créer des pools de connexions ou de gérer les défaillances du réseau vous-même : quelques lignes de Python vous permettent de disposer d'une couche de mémoire vectorielle fonctionnelle.

Milvus s'adapte à vos besoins. Il prend en charge trois modes de déploiement :

• Milvus Lite: Léger, basé sur des fichiers, idéal pour le développement et les tests locaux.

• Standalone: Déploiement sur un seul serveur pour les charges de travail de production

• Distribué: Cluster complet pour les scénarios à grande échelle

Vous pouvez commencer avec Milvus Lite pour valider la mémoire de votre agent localement, puis passer à une solution autonome ou distribuée à mesure que le trafic augmente, sans modifier le code de votre application. Cette flexibilité est particulièrement utile lorsque vous procédez à des itérations rapides dans les premières phases, mais que vous avez besoin d'une voie claire pour passer à l'échelle par la suite.

Étape par étape : Création d'un agent Agno prêt pour la production avec Milvus

Construisons un agent prêt pour la production en partant de zéro.

Nous commencerons par un exemple simple d'agent unique pour montrer le flux de travail complet. Ensuite, nous l'étendrons à un système multi-agents. AgentOS compilera automatiquement le tout sous la forme d'un service HTTP appelable.

1. Déploiement de Milvus Standalone avec Docker

(1) Télécharger les fichiers de déploiement

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

(2) Démarrer le service Milvus

docker-compose up -d

docker-compose ps -a

2. Mise en œuvre du noyau

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) Exécution de l'agent

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

3. Connexion à la console AgentOS

https://os.agno.com/

(1) Créer un compte et se connecter

(2) Connectez votre agent à AgentOS

(3) Configurer le port exposé et le nom de l'agent

(4) Ajouter des documents et les indexer dans Milvus

(5) Tester l'agent de bout en bout

Dans cette configuration, Milvus gère la recherche sémantique à haute performance. Lorsque l'assistant de la base de connaissances reçoit une question technique, il invoque l'outil search_knowledge pour intégrer la requête, récupère les morceaux de documents les plus pertinents dans Milvus et utilise ces résultats comme base de sa réponse.

Milvus propose trois options de déploiement, ce qui vous permet de choisir une architecture adaptée à vos besoins opérationnels tout en conservant les API au niveau de l'application cohérentes dans tous les modes de déploiement.

La démo ci-dessus montre le flux principal de récupération et de génération. Toutefois, pour intégrer cette conception dans un environnement de production, plusieurs aspects architecturaux doivent être examinés plus en détail.

Comment les résultats de la recherche sont partagés entre les agents

Le mode Team d'Agno dispose d'une option share_member_interactions=True qui permet aux agents suivants d'hériter de l'historique complet des interactions des agents précédents. En pratique, cela signifie que lorsque le premier agent récupère des informations dans Milvus, les agents suivants peuvent réutiliser ces résultats au lieu d'effectuer à nouveau la même recherche.

• L'avantage : Les coûts de recherche sont amortis au sein de l'équipe. Une recherche vectorielle prend en charge plusieurs agents, ce qui réduit les requêtes redondantes.

• L'inconvénient : La qualité de la recherche est amplifiée. Si la recherche initiale renvoie des résultats incomplets ou inexacts, cette erreur se propage à tous les agents qui en dépendent.

C'est pourquoi la précision de la recherche est encore plus importante dans les systèmes multi-agents. Une mauvaise recherche ne dégrade pas seulement la réponse d'un agent, elle affecte l'ensemble de l'équipe.

Voici un exemple de configuration d'équipe :

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

Pourquoi Agno et Milvus sont-ils disposés séparément ?

Dans cette architecture, Agno se situe au niveau de la conversation et de l'orchestration. Il est responsable de la gestion du flux de dialogue, de la coordination des agents et du maintien de l'état de la conversation, l'historique des sessions étant conservé dans une base de données relationnelle. Les connaissances réelles du domaine du système, telles que la documentation sur les produits et les rapports techniques, sont traitées séparément et stockées sous forme d'enchâssements vectoriels dans Milvus. Grâce à cette division claire, la logique de conversation et le stockage des connaissances sont totalement découplés.

Pourquoi cela est important d'un point de vue opérationnel :

• Mise à l'échelle indépendante: Au fur et à mesure que la demande d'Agno augmente, ajoutez des instances Agno supplémentaires. Lorsque le volume des requêtes augmente, il faut étendre Milvus en ajoutant des nœuds de requête. Chaque couche évolue de manière isolée.

• Besoins matériels différents: Agno est lié à l'unité centrale et à la mémoire (inférence LLM, exécution du flux de travail). Milvus est optimisé pour la recherche vectorielle à haut débit (E/S sur disque, parfois accélération GPU). Leur séparation permet d'éviter les conflits de ressources.

• Optimisation des coûts: Vous pouvez régler et allouer des ressources pour chaque couche indépendamment.

Cette approche en couches vous permet d'obtenir une architecture plus efficace, plus résiliente et plus apte à la production.

Éléments à surveiller lors de l'utilisation d'Agno avec Milvus

Agno dispose de capacités d'évaluation intégrées, mais l'ajout de Milvus élargit les éléments à surveiller. D'après notre expérience, concentrez-vous sur trois domaines :

• Qualité de la récupération: Les documents renvoyés par Milvus sont-ils réellement pertinents par rapport à la requête, ou simplement superficiellement similaires au niveau du vecteur ?

• Fidélité de la réponse: La réponse finale est-elle fondée sur le contenu récupéré ou le LLM génère-t-il des affirmations non étayées ?

• Ventilation de la latence de bout en bout: Ne vous contentez pas de suivre le temps de réponse total. Décomposez-le par étape - génération d'encapsulation, recherche de vecteur, assemblage de contexte, inférence LLM - afin d'identifier les points de ralentissement.

Un exemple pratique : Lorsque votre collection Milvus passe de 1 million à 10 millions de vecteurs, vous pouvez remarquer que la latence de récupération augmente. C'est généralement le signe qu'il faut ajuster les paramètres de l'index (comme nlist et nprobe) ou envisager de passer d'un déploiement autonome à un déploiement distribué.

Conclusion

Construire des systèmes d'agents prêts pour la production ne se limite pas à assembler des appels LLM et des démonstrations d'extraction. Vous avez besoin de limites architecturales claires, d'une infrastructure qui évolue de manière indépendante et d'une observabilité qui vous permette de détecter rapidement les problèmes.

Dans ce billet, j'ai expliqué comment Agno et Milvus peuvent fonctionner ensemble : Agno pour l'orchestration multi-agents, Milvus pour la mémoire évolutive et la récupération sémantique. En gardant ces couches séparées, vous pouvez passer du prototype à la production sans réécrire la logique de base et faire évoluer chaque composant en fonction des besoins.

Si vous expérimentez des configurations similaires, je serais curieux de savoir ce qui fonctionne pour vous.

Des questions sur Milvus ? Rejoignez notre canal Slack ou réservez une session Milvus Office Hours de 20 minutes.