AgentField : un plan de contrôle Go pour exposer des agents comme des API

Le problème visé : des agents qui restent appelables par le reste de la pile

Un agent utile ne vit presque jamais seul. Il est appelé par un frontend, par un traitement planifié, parfois par un autre agent. Le README pose le problème en une phrase : AgentField est un plan de contrôle open source qui rend les agents IA appelables par n'importe quel service de la pile, comme n'importe quelle autre API. Le public visé est donc l'équipe qui a déjà écrit de la logique d'agent et qui bute sur ce qui l'entoure. Routage, coordination, mémoire, exécution asynchrone, observabilité : la liste est donnée telle quelle dans le README. Rien de tout cela n'est propre à l'IA, et c'est justement l'argument. Un agent qui note des dossiers de sinistres, avec détection de motifs et validation humaine pour les cas incertains, ressemble côté exploitation à un service qui répond à des requêtes. Le README va jusqu'à proposer une commande d'installation et une invite à coller dans un agent de codage pour obtenir une pile Docker Compose complète. C'est le scénario d'entrée : décrire un système en une ligne, obtenir un backend multi-agents avec un point de terminaison REST à tester au curl. Le projet ne cherche pas à améliorer le raisonnement d'un modèle. Il prend en charge la plomberie autour.

Une fonction devient une route, et l'appel récursif passe par le plan de contrôle

Le mécanisme central tient dans un décorateur. Dans l'exemple Python du README, on instancie un objet Agent avec un node_id et une version, puis on décore une fonction asynchrone avec app.reasoner. La ligne app.run() expose, selon le commentaire du README, POST /api/v1/execute/researcher.research. La fonction n'est pas enveloppée dans un graphe déclaratif ni décrite dans un fichier YAML. Elle reste une fonction Python ordinaire, avec ses paramètres et sa valeur de retour. Le point intéressant est ailleurs. À l'intérieur de la fonction, l'appel app.call("researcher.research", ...) ne s'exécute pas en local : d'après le commentaire du README, chaque sous-question est renvoyée vers le même agent à travers le plan de contrôle. C'est ce détour qui permet à une seule requête entrante de se ramifier, et c'est le plan de contrôle qui prend en charge la file d'attente, les reprises et la trace de chaque branche. Le README ajoute qu'aucun broker ni configuration de file d'attente n'est nécessaire. La borne est laissée à l'auteur du code : dans l'exemple, un compteur depth arrête la récursion à 3 et renvoie une réponse directe. Autrement dit, la protection contre l'emballement n'est pas fournie par la plateforme, elle est écrite dans la fonction. C'est un choix de conception assumé, et il faut le savoir avant de laisser une fonction se rappeler elle-même.

Installation : un script, un démon, et un drapeau pour s'en passer

L'installation tient en une commande : curl -fsSL https://agentfield.ai/install.sh | bash. Le README précise que le script dépose aussi le harnais de codage aforge à côté de af dans ~/.agentfield/bin, et que l'option --no-aforge permet de l'omettre. Sur macOS, le même script enregistre le plan de contrôle pour qu'il démarre à l'ouverture de session via launchd et ajoute une icône dans la barre de menus. Deux commandes sont documentées pour le piloter : af service stop pour l'arrêter, af service status pour afficher l'état de santé et le travail en cours. Le README signale un piège concret : un simple kill est interprété comme un plantage et le service redémarre. L'option --no-tray évite l'installation de l'icône. Ces détails disent quelque chose du modèle de déploiement : AgentField s'installe d'abord comme un service local sur la machine du développeur, pas comme un composant de cluster. Le README mentionne ensuite une pile Docker Compose générée à partir d'une spécification, avec l'agent, le plan de contrôle et un point de terminaison REST. Le contenu exact de cette pile n'est pas reproduit dans le matériel fourni, et je ne peux pas le décrire. Le fichier LICENSE n'est pas non plus inclus dans l'extrait, même si le badge et les métadonnées indiquent Apache-2.0.

La version 0.1.138-rc.16 et ce qu'elle implique pour la maintenance

Le dépôt n'est pas archivé et la dernière poussée date du 9 septembre 2026. Les trois versions les plus récentes portent toutes le suffixe rc : v0.1.138-rc.16, v0.1.138-rc.15 et v0.1.138-rc.14, publiées le même jour à quelques heures d'intervalle. Trois candidates de la même série en une journée, c'est le signe d'une phase de stabilisation active, pas d'un cycle de publication figé. Pour une équipe qui évalue le projet, cela veut dire deux choses. D'abord, le numéro de version mineure reste en 0.1, ce qui n'engage aucune compatibilité ascendante selon les conventions habituelles du versionnement sémantique. Ensuite, une montée de version peut demander de relire les notes de publication, puisque les candidates se succèdent à un rythme serré. Le README ne décrit aucune politique de support, aucune branche de maintenance pour les versions antérieures, et aucun guide de migration. C'est une lacune du matériel disponible, pas nécessairement du projet, mais elle compte au moment de choisir. Le point sur la licence : les métadonnées du dépôt et le badge du README indiquent Apache-2.0, ce qui autorise en principe l'usage commercial et la modification avec conservation des mentions. Je ne peux pas vérifier le texte du fichier LICENSE à partir de l'extrait fourni, et ce n'est pas un avis juridique.

Là où le modèle coince : un plan de contrôle central et des cas mal servis

Le README affirme que le même code passe d'un agent sur un ordinateur portable à dix mille agents dans un seul flux de travail. C'est une affirmation de conception, pas un résultat mesuré, et le matériel fourni ne contient aucun chiffre de débit, de latence ou de coût par appel. Le point d'étranglement est structurel : chaque appel récursif traverse le plan de contrôle. Un agent qui en appelle un autre ne le fait pas en mémoire, il passe par le routeur. Cela apporte la traçabilité et les reprises, et cela ajoute un saut réseau à chaque branche. Pour une chaîne de deux ou trois appels, ce détour est probablement indolore. Pour une boucle interne serrée qui appelle un modèle des dizaines de fois, il faut mesurer avant de généraliser. Le deuxième cas mal servi est le poste de développement verrouillé. Le script d'installation enregistre un service au démarrage de session sur macOS et ajoute une icône de barre de menus. Une équipe qui n'a pas les droits pour installer un démon persistant devra passer par --no-tray et gérer le processus elle-même, ou renoncer. Troisième cas : un seul agent, appelé par un seul service, sans ramification. Le plan de contrôle n'apporte alors rien que le service appelant ne fasse déjà, et il ajoute une dépendance à exploiter. Enfin, le README ne mentionne aucune limite de débit, aucun quota, aucune stratégie de reprise configurable. Les reprises existent, leur politique n'est pas documentée dans le matériel fourni.

Ce qui distingue AgentField d'un cadre d'orchestration multi-agents

La comparaison la plus directe se fait avec les cadres d'orchestration multi-agents écrits en Python, où l'on déclare des agents et des transitions dans le même processus que l'application. Dans ce modèle, l'appel d'un agent à un autre est un appel de fonction : rapide, mais sans file d'attente, sans reprise après un redémarrage du processus, et sans trace distribuée. AgentField déplace cette frontière. Le plan de contrôle est un service séparé, écrit en Go, et l'appel inter-agents devient une requête HTTP. La conséquence pratique est que l'état d'un flux survit au redémarrage d'un agent, puisque c'est le plan de contrôle qui détient la file. La conséquence inverse est qu'il faut faire tourner ce service. Un cadre en processus unique se teste avec un interpréteur et rien d'autre. AgentField ajoute un composant à superviser, avec ses commandes de service et son comportement de redémarrage automatique. L'autre différence tient au découpage des langages : les SDK existent en Python, Go et TypeScript, et une API REST est documentée. Une équipe peut donc garder un agent en Python et en écrire un autre en Go sans réécrire l'interface. C'est un avantage réel si la pile est déjà hétérogène, et un coût de maintenance supplémentaire si elle ne l'est pas.

Conclusion éditoriale

AgentField convient aux équipes qui ont déjà plusieurs agents et qui veulent les exposer comme des services REST avec un point d'entrée unique. Passez votre chemin si vous n'avez qu'un seul agent, si vous refusez d'installer un démon sur vos postes, ou si vous ne pouvez pas dépendre d'une version 0.1.138-rc. Avant d'aller plus loin, vérifiez deux choses dans le dépôt : le contenu réel du fichier LICENSE et l'existence d'un fichier de composition dans les sources, car le README ne fournit ni l'un ni l'autre.

Sources officielles

1. Agent-Field/agentfield on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases