Blocs

Primitives de workflow intégrées — la surface principale de tout workflow Scrydon

Les blocs sont les cartes que vous déposez sur le canevas pour construire un workflow. Scrydon en propose deux types :

Blocs principaux (cette page) — primitives de workflow intégrées, toujours disponibles : Agent, API, Function, Condition, Router, Evaluator, Response, ainsi que les blocs de contrôle du flux Loop, Parallel et Workflow.
Blocs d'intégration — blocs fournis par les fournisseurs, issus des intégrations installées. Le produit de chaque intégration contribue un ou plusieurs blocs (par ex. Gmail → « Envoyer un e-mail », Sheets → « Lire une plage »). Voir Fournisseurs pour le catalogue et Intégrations pour la définition des blocs.

Blocs principaux

Traitement

Agent — appeler un LLM. Les modèles sont résolus via le registre d'intégrations — jamais codés en dur.
Function — exécuter du JavaScript / TypeScript dans un bac à sable.
API — effectuer une requête HTTP vers tout ce qui est accessible depuis le runtime du workflow.

Logique

Condition — bifurquer sur une expression booléenne.
Router — laisser un LLM choisir quelle branche en aval emprunter.
Evaluator — noter / classer du contenu avec un LLM.

Contrôle du flux

Loop — itérer sur une liste ou jusqu'à ce qu'une condition soit remplie.
Parallel — exécuter des branches indépendantes en parallèle.
Workflow — invoquer un autre workflow comme sous-workflow.

Sortie

Response — formater et renvoyer le résultat final.

Agent

Create powerful AI agents using any LLM provider with customizable system prompts and tool integrations.

API

Connect to any external API with support for all standard HTTP methods and customizable request parameters.

Condition

Add a condition to the workflow to branch the execution path based on a boolean expression.

Function

Execute custom JavaScript or TypeScript code within your workflow to transform data or implement complex logic.

Router

Intelligently direct workflow execution to different paths based on input analysis.

Evaluator

Assess content using customizable evaluation metrics and scoring criteria across multiple dimensions.

Response

Send a response back to the caller with customizable data, status, and headers.

Origine des blocs d'intégration

Les blocs d'intégration ne sont jamais créés manuellement dans le YAML du workflow. Ils sont fournis par les produits des fournisseurs et résolus via le registre d'intégrations de la plateforme :

Fournisseur (ex. google)
  └── Produit (ex. gmail)
        ├── Bloc         ← carte « Gmail » sur le canevas
        ├── Outils       ← send-mail, list-messages, get-message, …
        └── Capacités    ← (LLM/STT/TTS/Embedding/etc., le cas échéant)

Ainsi, un bloc « Envoyer un e-mail Gmail » n'est pas un concept de premier niveau distinct — c'est la surface workflow de google → gmail → bloc, avec google → gmail → tools.send-mail qui effectue le travail réel. Désactiver l'intégration (politique organisationnelle, identifiant manquant) supprime le bloc du canevas sans modifier le code du workflow.

Les blocs Agent, Router et Evaluator résolvent également leur modèle via le registre d'intégrations — ils choisissent le fournisseur compatible LLM (OpenAI, Anthropic, Mistral, Bedrock, vLLM, …) installé et sélectionné par la politique organisationnelle. Il n'y a pas de constante model: "gpt-5.4" dans le bloc ; le bloc déclare une capacité et le registre la résout.

Fonctionnement d'un bloc

Chaque bloc comporte trois couches :

Entrées — données provenant des blocs connectés en amont Configuration — champs remplis par l'auteur (sous-blocs : sélecteur de modèle, invite système, en-têtes, …) Sorties — données typées produites par le bloc, disponibles pour les blocs en aval via les connexions

Recevoir l'entrée — depuis les blocs en amont ou le déclencheur du workflow

Traiter — appliquer la configuration et exécuter la logique du bloc. Pour les blocs d'intégration, cela envoie la commande à fournisseur → produit → tool.execute() dans le bac à sable.

Émettre la sortie — JSON typé que les blocs en aval peuvent référencer

Déclencheur → Agent → Function → Response

Branchement conditionnel

Déclencheur → Router → Agent A (questions)
                     → Agent B (commandes)

Contrôle qualité

Agent → Evaluator → Condition → Response (si satisfaisant)
                               → Agent (relance si non)

Fan-out

Déclencheur → Parallel → Branche A → …
                       → Branche B → …
                       → Branche C → …

Aide-mémoire de configuration

Classe de bloc	Configuration courante
Tous	délai d'expiration, branche de gestion des erreurs
Utilisant un LLM (Agent, Router, Evaluator)	sélecteur de capacité (modèle LLM résolu via le registre), invite système, température, liste blanche d'outils
Logique (Condition, Function)	expression / code, variables d'environnement du bac à sable
Réseau (API)	URL, en-têtes, authentification, corps de la requête, analyse de la réponse
Contrôle du flux (Loop, Parallel, Workflow)	source d'itération, concurrence, ID du workflow cible
Blocs d'intégration	fournis par le produit du fournisseur — voir Fournisseurs