# Nœud Agent Le nœud **Agent** est le cerveau de Systalink Agent Builder. Il appelle un LLM avec vos instructions, raisonne sur l'entrée courante, invoque optionnellement des outils, et émet du texte ou du JSON structuré que les nœuds suivants peuvent consommer. Tout workflow non trivial contient au moins un Agent. C'est le seul nœud capable de décider *quoi faire ensuite* à partir d'une entrée libre — tous les autres nœuds Core sont des primitives déterministes. --- ## Vue d'ensemble Un nœud Agent prend : - **Instructions** (votre system prompt) - **Un message utilisateur** (construit à partir de `input`, de la sortie du nœud précédent, et optionnellement de l'historique de chat) - **Outils** (optionnels — recherche web, MCP, recherche de fichiers, interpréteur de code, shell, génération d'images, fonction) - **Format de sortie** (texte ou JSON avec un schéma) …et produit : - `outputs..raw` — la réponse texte du modèle - `outputs..parsed` — JSON parsé (quand **Format de sortie** est JSON) Le runtime utilise l'API **Responses** d'OpenAI avec `parallel_tool_calls: false` et suit les boucles d'appels de fonctions jusqu'à ce que le modèle retourne une réponse finale. --- ## Modèle Configurable depuis le panneau du nœud. Modèles disponibles : | Valeur | Notes | | --- | --- | | `gpt-5.5` | Qualité maximale, plus lent, plus cher | | `gpt-5.4` | Raisonnement général solide | | `gpt-5.4-mini` | Par défaut — rapide et économique | | `gpt-5.4-mini-2026-03-17` | Build legacy figé | | `gpt-5.3` / `gpt-5.2` / `gpt-5.1` | Snapshots plus anciens | Vous pouvez aussi régler **Effort de raisonnement** sur `low`, `medium` ou `high`. Des valeurs plus élevées laissent le modèle réfléchir plus longtemps — utile pour l'utilisation d'outils en plusieurs étapes ou les sorties structurées complexes, mais cela ajoute de la latence et du coût. > Commencez avec `gpt-5.4-mini` et `reasoning: low`. N'augmentez que quand les évaluations le justifient. --- ## System prompt (Instructions) La zone **Instructions** est envoyée comme champ `instructions` de l'appel à l'API Responses. Écrivez-la comme une fiche de poste : qui est l'agent, ce qu'il doit faire, ce qu'il doit éviter, et le format attendu de la sortie. Les placeholders sont interpolés à l'exécution depuis le contexte du workflow : | Placeholder | Résout vers | | --- | --- | | `{input}` | L'entrée courante (message de chat, payload webhook, ou sortie précédente) | | `{event.body.}` | Un champ de l'évènement déclencheur (corps webhook, payload de planification) | | `{event.headers.}` | Un header de l'évènement déclencheur | | `{outputs..raw}` | La sortie texte brute d'un nœud en amont | | `{outputs..parsed.}` | Un champ spécifique d'une sortie JSON en amont | | `{state.}` | Une variable d'état du workflow définie par un nœud Set State | Exemple : ``` Tu es un agent de triage de support pour {state.tenant_name}. Le client a écrit : {input} La catégorie de son ticket précédent était : {outputs.classify-1.parsed.classification} Réponds dans la langue du client. Sois concis (2-3 phrases). ``` --- ## Message utilisateur Le message utilisateur est construit automatiquement depuis le contexte d'exécution — vous ne l'écrivez généralement pas. L'ordre de précédence est : 1. Le message de chat courant (quand déclenché depuis l'aperçu de chat) 2. Le payload webhook ou évènement 3. La sortie du nœud en amont (`last_output`) Quand **Inclure l'historique de chat** est activé, la transcription complète de la conversation est ajoutée pour que l'agent ait du contexte multi-tour. Si aucune entrée n'est disponible et que **Autoriser les images en entrée** est activé, le runtime envoie `"Analyze the provided image input and respond to the user."` pour que le modèle ait toujours une accroche. --- ## Format de sortie Deux modes, sélectionnés depuis le menu **Format de sortie**. ### Texte Le texte libre du modèle est écrit dans `outputs..raw` et dans `last_output`. À utiliser pour les réponses de chat, résumés, ou tout contenu destiné à un humain. ### JSON (sortie structurée) Sélectionner **JSON** ouvre une modale de schéma où vous définissez la forme de la réponse. Le runtime la sérialise en JSON Schema et force le modèle à retourner une sortie structurée stricte via le paramètre `text.format = json_schema` de l'API Responses. Chaque propriété a : - **Nom** — la clé JSON - **Type** — `str`, `num`, `bool`, `enum`, `obj`, ou `arr` - **Description** — guide le modèle - **Requis** — bascule - **Valeurs d'enum** — uniquement pour les types `enum` Le résultat parsé est exposé via `outputs..parsed`. Les nœuds suivants — particulièrement **If/Else** et **Classify** — peuvent référencer les champs directement : ``` {outputs.agent-1.parsed.intent} {outputs.agent-1.parsed.confidence} ``` > **Préférez JSON dès que le nœud suivant doit prendre une décision.** Parser du texte libre est fragile ; la sortie structurée est contractuelle. --- ## Inclure l'historique de chat Bascule qui contrôle `contextMode` : - **Activé (défaut)** — `contextMode: "conversation"`. La transcription complète du chat est envoyée dans le message utilisateur. À utiliser pour les chatbots, copilotes conversationnels, tout ce qui est multi-tour. - **Désactivé** — `contextMode: "input"`. Seule l'entrée courante est envoyée. À utiliser pour les tâches one-shot : classifier un payload webhook, extraire des champs d'un document, traiter un enregistrement unique. Désactiver l'historique rend les runs moins chers, plus déterministes, et plus faciles à déboguer. --- ## Autoriser les images en entrée Quand activé, le runtime collecte les pièces jointes images du message de chat courant ou de l'entrée du workflow et les transmet au modèle comme éléments de contenu `input_image`. Le modèle actif doit supporter la vision. À utiliser pour : - Triage de captures d'écran - OCR de reçus ou factures - Contrôles qualité visuels Si aucune entrée texte n'est présente, le runtime injecte une instruction de repli pour que le modèle sache décrire ou agir sur l'image. --- ## Outils Les outils permettent à l'agent d'appeler le monde extérieur. Ils sont hébergés par OpenAI, exécutés dans notre sandbox, ou invoqués comme des outils style fonction que le modèle appelle et que votre workflow gère. Ajoutez des outils depuis le bouton **+** à côté de la ligne Outils. Chaque outil produit une puce sur laquelle vous pouvez cliquer pour la reconfigurer. | Outil | Hébergé par | À utiliser pour | | --- | --- | --- | | [Web search](/docs/tool-web-search) | OpenAI | Informations fraîches, actualité, docs publiques | | [File search](/docs/tool-file-search) | Systalink | Interroger les documents du workflow, pièces jointes, fichiers sandbox | | [MCP](/docs/tool-mcp) | Distant | Appeler n'importe quel serveur [Model Context Protocol](https://modelcontextprotocol.io) | | [Code interpreter](/docs/tool-code-interpreter) | Sandbox Systalink | Calcul, traitement de données, génération de fichiers | | [Shell](/docs/tool-shell) | Sandbox Systalink | Exécuter des commandes CLI dans la sandbox | | [Image generation](/docs/tool-image-generation) | OpenAI | Produire des images depuis des prompts (`gpt-image-1`) | | [Function](/docs/tool-function) | Local | Outil custom style fonction avec un schéma JSON que vous définissez | Chaque outil a besoin d'une **Description** claire. Le modèle utilise la description (plus vos instructions) pour décider *quand* appeler l'outil — des descriptions vagues mènent à des sur-appels ou à des non-appels. > Le runtime impose `parallel_tool_calls: false`. L'agent appelle un outil à la fois et attend le résultat avant de continuer. Les traces sont ainsi faciles à lire. --- ## Sortie (contrat aval) Après exécution, le nœud Agent écrit : ```json { "outputs": { "": { "raw": "...", "parsed": { ... } } }, "last_output": "...", "last_output_parsed": { ... } } ``` N'importe quel nœud aval — y compris un autre Agent — peut référencer ces valeurs via des placeholders. --- ## Bonnes pratiques **Écrivez un system prompt focalisé.** Un job par agent. Dites au modèle qui il est, ce qu'il doit produire, ce qu'il doit éviter, et le format de sortie. Résistez à la tentation d'entasser des tâches sans lien dans un seul agent — chaînez deux agents à la place. **Préférez la sortie structurée pour les nœuds aval.** Si le nœud suivant est `If/Else`, `Classify`, ou un autre Agent qui a besoin de champs spécifiques, passez en mode **JSON** et définissez un schéma. Parser du texte libre est une recette pour des bugs en production. **Utilisez les outils avec parcimonie.** Chaque outil ajoute de la latence, du coût, et une façon pour le modèle de se tromper. Donnez à l'agent le jeu d'outils minimum dont il a besoin. Si l'agent n'a jamais besoin de la recherche web, ne l'activez pas. **Testez avec l'aperçu de chat avant de publier.** Ouvrez le panneau de chat à droite dans l'éditeur de workflow et déclenchez votre workflow avec des entrées réalistes. Observez la trace des appels d'outils, inspectez le JSON, puis itérez. Moins cher qu'apprendre en production. **Choisissez le plus petit modèle qui marche.** Commencez avec `gpt-5.4-mini` et `reasoning: low`. N'escaladez vers un modèle plus gros qu'avec une évaluation qui prouve que ça compte. **Figez le modèle en production.** Utilisez la variante datée (par ex. `gpt-5.4-mini-2026-03-17`) une fois votre prompt réglé, pour que les upgrades silencieuses ne régressent pas votre comportement. --- *Source: https://agentbuilder.systalink.sn/docs/node-agent — human documentation.* *Other language: [/docs-md/en/node-agent.md](/docs-md/en/node-agent.md).* *Machine-readable index: [/llms.txt](/llms.txt).*