Scrydon

Architecture du Copilot

Comment l'assistant IA intégré à l'éditeur est câblé — modes, outils, streaming, contexte et moteur de capacité en plateforme.

Le Copilot est l'assistant intégré à l'éditeur qui aide les utilisateurs à construire, modifier et analyser leurs workflows. Cette page documente son câblage interne.

Pour le guide produit — ce que fait chaque mode, les niveaux de profondeur, quand utiliser lequel — voir Copilot.

Flux de haut niveau

Dispatch LLM : moteur de capacité en plateforme

Les appels LLM du Copilot sont entièrement gérés en interne. L'API Scrydon délègue au moteur de capacité de la plateforme (api-platform), qui résout le fournisseur LLM configuré par l'organisation, applique l'analyse DLP et retransmet la réponse. Aucun backend externe hébergé par Scrydon n'est impliqué — votre cluster appelle directement le fournisseur LLM en utilisant les identifiants configurés par votre organisation.

Cela signifie :

  • Aucun egress vers copilot.scrydon.com n'est requis.
  • Le modèle utilisé est l'intégration LLM configurée par l'organisation (dans Paramètres → Intégrations).
  • Tout l'egress LLM apparaît sous les points de terminaison du fournisseur configuré — comme pour toute autre fonctionnalité utilisant un LLM.

Modes

ModeValeur APIOutilsComportement clé
AskaskRecherche, docsQuestions-réponses avec citations. Ne modifie pas votre workflow.
BuildagentTous les outilsPropose des modifications (ajout de blocs, câblage de variables, changement de paramètres). Les modifications s'appliquent avec votre approbation.
PlanplanPlanification + todosRédige un plan multi-étapes avec éléments de liste avant toute modification.

La liste déroulante de mode affiche « Build » dans l'interface mais envoie agent sur le câble — conservé pour la compatibilité ascendante.

Catégories d'outils

Le Copilot peut invoquer deux types d'outils :

  • Outils client — s'exécutent dans le navigateur. Ils lisent ou modifient le workflow sur le canevas (run-workflow, edit-workflow, get-block-config, knowledge-base, navigate-to, …).
  • Outils serveur — s'exécutent dans votre cluster contre vos intégrations. Tout outil exposé par un vendeur installé est appelable depuis le Copilot lorsque les permissions le permettent.

Les outils serveur nécessitent toujours une confirmation de l'utilisateur par défaut. L'utilisateur peut opter pour l'auto-autorisation par session.

Système de contexte (@mentions)

L'utilisateur peut attacher du contexte typé à un message Copilot :

ContexteCe qu'il injecte
@workflowLa définition complète d'un autre workflow
@current_workflowL'état du workflow actif
@blocksDes blocs sélectionnés spécifiques
@logsLes journaux d'exécution pour le débogage
@knowledgeUne entrée de base de connaissances
@templatesUn template de workflow
@docsUne page de documentation Scrydon
@past_chatUne conversation Copilot précédente

La résolution du contexte s'effectue côté API avant que la requête ne quitte le cluster, de sorte que le backend Copilot ne voit jamais les identifiants d'objets bruts — uniquement les charges utiles résolues.

Points de contrôle

Chaque message Copilot qui mute le workflow enregistre un point de contrôle. Depuis le panneau de chat, vous pouvez revenir à n'importe quel point de contrôle précédent et le canevas revient à cet état. Utile quand une modification par l'agent tourne mal.

  • GET /api/copilot/checkpoints — lister les points de contrôle d'un chat.
  • POST /api/copilot/checkpoints/revert — restaurer l'état du workflow depuis un point de contrôle.

Sélection du modèle

Le modèle utilisé par le Copilot est le fournisseur LLM configuré par l'organisation, résolu au moment du dispatch par le moteur de capacité de la plateforme. La génération de titres et les appels utilitaires courts utilisent le même fournisseur avec une configuration allégée.

Voir aussi

Sur cette page

Sur cette page