
Construire un agent autonome avec function calling en Node.js/TypeScript
Les LLM seuls, c’est bien. Un LLM qui peut exécuter des actions, c’est mieux. Le function calling (ou tool use) permet à un agent de décider d’appeler des fonctions pour interagir avec le monde réel : API, base de données, système de fichiers, etc.
J’ai construit un agent autonome en TypeScript capable de planifier, exécuter et s’adapter. Voici comment.
Le principe du function calling
L’idée est simple : on fournit au LLM une description des fonctions disponibles, et il peut décider de les invoquer. Le LLM ne les exécute pas lui-même, il renvoie un appel de fonction, c’est à nous de l’exécuter.
Question : “Quel est le temps dispo sur mon serveur ?”
- LLM décide d’appeler checkServerHealth(“myserver”)
- Notre code exécute la fonction
- On renvoie le résultat au LLM
- LLM formule la réponse finale
Définition des outils
Commençons par définir les fonctions que notre agent pourra utiliser :
interface Tool { |
Un outil concret pour interroger un serveur :
const serverHealthTool: Tool = { |
L’agent avec Vercel AI SDK
J’utilise le Vercel AI SDK qui gère tout le cycle des tool calls de manière élégante (fonctionne aussi en Node.js, pas besoin de Next.js) :
import { generateText } from "ai"; |
maxSteps permet à l’agent de faire plusieurs appels d’outils séquentiels, en utilisant le résultat d’un appel pour décider du suivant.
Agent avec mémoire et planification
Un agent un peu plus avancé garde un historique et planifie ses actions :
class Agent { |
Exemple concret : agent DevOps
J’ai créé un agent qui combine plusieurs outils pour gérer mon infrastructure :
const devOpsTools = [ |
Le résultat : l’agent enchaîne les appels (vérification disque, nettoyage SSH, notification Slack) en adaptant ses décisions aux résultats intermédiaires.
Agents avec Ollama en local
Le function calling fonctionne aussi en local avec Ollama. Les modèles comme llama3.2 et qwen2.5 supportent nativement les tool calls :
import { ollama } from "ollama-ai-provider"; |
Le principal frein est la taille du contexte : chaque tour d’outil ajoute des messages à l’historique. qwen2.5:7b supporte 32K tokens de contexte, ce qui laisse une bonne marge.
Limitations et bonnes pratiques
Quelques leçons apprises en pratiquant :
- Validez les entrées des outils : ne faites jamais confiance au LLM pour générer des arguments valides
- Timeout sur les exécutions : un outil qui bloque fait échouer tout l’agent
- Limitez le nombre d’itérations :
maxStepsou votre propre compteur pour éviter les boucles infinies - Journalisez tout : chaque appel d’outil doit être loggé pour debug
async executeWithTimeout(tool: Tool, args: any, timeout = 10000) { |
Conclusion
Le function calling transforme un LLM statique en un agent capable d’agir sur le monde réel. Avec le Vercel AI SDK ou une boucle maison en TypeScript, vous pouvez construire des assistants DevOps, des bots de support, ou des automatisations complexes.
J’utilise le mien au quotidien pour gérer mon homelab : il surveille, alerte et répare automatiquement. La prochaine étape, c’est de lui donner accès à Git pour qu’il crée lui-même ses PR de correction.
Et vous, quel genre d’agent aimeriez-vous construire ?