NeoGraph - Un moteur d’agents qui porte LangGraph en C++

Bonjour.
Je partage NeoGraph, un moteur d’orchestration d’agents que j’ai créé.
Il est basé sur C++17, et vous pouvez l’installer avec la commande ci-dessous.
pip install neograph-engine

Pourquoi l’avoir créé

En utilisant LangGraph, basé sur Python, j’ai souvent trouvé les performances décevantes. Comme les ressources nécessaires au démarrage d’un serveur sont aussi assez élevées, je me suis souvent dit qu’il serait bien d’avoir un moteur d’orchestration léger et rapide. C’est ce qui m’a conduit à l’implémenter en C++ pour viser de meilleures performances.

Caractéristiques ?

Les graphes sont traités comme des données, et non comme du code.

La plupart des frameworks Python définissent les graphes comme des objets Python. NeoGraph, lui, définit la structure du graphe elle-même en JSON. Il n’est pas défini comme un objet StateGraph, mais comme un bloc JSON unique qui tient dans une ligne de base de données.

Cela rend possibles des choses comme :

1. Hot swap sans déploiement - pour modifier la structure de l’agent (topologie du graphe), il suffit de remplacer une seule ligne JSON dans la base de données.
   Aucun redéploiement, aucun redémarrage du processus, aucune perte des conversations en cours.

2. Multi-tenant - il est possible d’exécuter, dans un seul processus, des structures d’agents différentes pour chaque client. En pratique, avec OpenAI gpt-4o-mini, lors du traitement simultané de 1 000 clients, le RSS était de 29 MB et il n’y a eu aucune erreur. Avec la même configuration sur LangGraph, comme il faut un processus par client, j’estime qu’il faudrait au total plusieurs dizaines de GB.

3. Agent auto-évolutif - le LLM observe les conversations de chaque client et réécrit le graph_def (JSON) correspondant. Autrement dit, l’agent « change lui-même de forme » pour s’adapter au comportement de l’utilisateur.

Et c’est rapide.

Framework	Overhead moteur (1 exécution de nœud)	Par rapport à NeoGraph
NeoGraph	5.0 µs	1×
Haystack	140 µs	28×
LangGraph	643 µs	128×
LlamaIndex	1,565 µs	313×
AutoGen	3,127 µs	625×

Bien sûr, cela peut varier selon la méthode de mesure, et dès qu’un véritable appel LLM intervient, les I/O externes dominent, donc la vitesse perçue peut devenir similaire.
Je pense que ces chiffres en µs prennent vraiment leur sens dans des cas multi-tenant ou edge où des milliers de requêtes arrivent sur une seule machine.

GitHub: https://github.com/fox1245/NeoGraph
PyPI: https://pypi.org/project/neograph-engine/

Vos retours sont les bienvenus.