Architecture du Copilot
Comment l'assistant IA intégré à l'éditeur est câblé — modes, outils, streaming, contexte et dépendance au backend Copilot externe.
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
Dépendance externe : le backend Copilot
Les clusters auto-hébergés ont besoin d'un accès sortant vers copilot.scrydon.com pour que le Copilot fonctionne. Si votre cluster est isolé (air-gapped) ou interdit cette sortie, le Copilot n'est pas disponible ; le reste de la plateforme n'est pas affecté.
L'orchestration du Copilot s'exécute sur un service géré par Scrydon (copilot.scrydon.com). L'API Scrydon lui transfère les prompts utilisateurs ; le backend Copilot construit la requête LLM, appelle le modèle choisi et diffuse les réponses en retour. Votre cluster n'envoie jamais le contexte du modèle à un tiers — le backend Copilot utilise le modèle que votre organisation a configuré pour lui.
Pour les déploiements auto-hébergés :
- Allez sur scrydon.com → Paramètres → Copilot et générez une clé API Copilot.
- Définissez
COPILOT_API_KEYdans votre environnement auto-hébergé avec cette valeur. - Assurez-vous que
PUBLIC_APP_URLetAUTH_URLsont résolubles depuis l'extérieur de votre cluster (par exemple via un enregistrement DNS public ou un tunnel). Le backend Copilot rappelle votre cluster lors de l'exécution des outils.
Modes
| Mode | Valeur API | Outils | Comportement clé |
|---|---|---|---|
| Ask | ask | Recherche, docs | Questions-réponses avec citations. Ne modifie pas votre workflow. |
| Build | agent | Tous les outils | Propose des modifications (ajout de blocs, câblage de variables, changement de paramètres). Les modifications s'appliquent avec votre approbation. |
| Plan | plan | Planification + todos | Ré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 :
| Contexte | Ce qu'il injecte |
|---|---|
@workflow | La définition complète d'un autre workflow |
@current_workflow | L'état du workflow actif |
@blocks | Des blocs sélectionnés spécifiques |
@logs | Les journaux d'exécution pour le débogage |
@knowledge | Une entrée de base de connaissances |
@templates | Un template de workflow |
@docs | Une page de documentation Scrydon |
@past_chat | Une 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
La liste déroulante de modèle dans le Copilot est une liste organisée — indépendante du registre d'intégrations principal de l'organisation — de sorte qu'un utilisateur peut choisir un modèle différent pour « build » de celui utilisé dans ses blocs agent. La génération de titres et les appels utilitaires courts utilisent un modèle par défaut plus petit.
Voir aussi
- Copilot — guide produit et niveaux de profondeur.
- Architecture → Cortex — comment les appels LLM depuis l'intérieur du cluster sont acheminés.
- Sécurité → Journal d'audit — chaque modification du Copilot est auditable.