Extensions personnalisées
Créez, archivez et livrez des extensions vendeur personnalisées à l'aide du SDK Extensions Scrydon
Le SDK Extensions Scrydon vous permet de créer des extensions vendeur personnalisées sous forme d'archives autonomes. Chaque archive est une archive .tar.gz contenant du code compilé et un manifeste — livrez-la via une source d'extension, installez-la depuis le catalogue d'extensions de votre organisation et elle devient immédiatement disponible dans l'éditeur de workflow.
Aucun accès au monorepo ni redéploiement de la plateforme requis. Installez le SDK depuis NPM, écrivez votre extension en TypeScript, compilez et publiez-la dans une extension.
Où cela se situe dans le produit. Tout ce qui est installé dans une organisation — extensions vendeur, serveurs MCP, et les extensions de solution et de contenu qui les fournissent — se gère au même endroit : Paramètres → Plateforme → Extensions. Une extension est le format de distribution, affiché comme provenance (« depuis Acme Field Ops v1.3.0 »), et non une destination distincte.
Vous pouvez livrer un connecteur seul, ou l'accompagner de contenu domaine (une ontologie, des workflows, un flux de processus, des notebooks) dans la même extension — voir Extensions & SDK d'authoring. Les deux arrivent comme une seule extension.
Fonctionnement
Chaque extension suit le même cycle de vie :
Utilisez les helpers SDK defineExtension(), defineToolkit(), defineTool() et defineBlock() pour déclarer votre extension en TypeScript. Les schémas Zod valident les entrées et sorties à la fois au moment de la compilation et à l'exécution.
Exécutez sdk-authoring extension build pour compiler votre TypeScript en une archive ESM unique, extraire un manifeste avec des représentations JSON Schema de vos schémas Zod, et tout empaqueter dans un .archive.tar.gz.
Publiez l'archive dans une extension vers une source Git/OCI, puis enregistrez cette source dans Paramètres > Plateforme > Extensions > Sources et installez-la depuis Ajouter une extension. La plateforme valide le manifeste, stocke l'artefact et l'enregistre dans le catalogue.
La plateforme sélectionne le backend d'exécution à partir de la provenance vérifiée de l'archive. Les outils Scrydon exacts et révisés peuvent utiliser le backend Worker Thread approuvé. Les outils non-Scrydon livrés ou installés par une organisation s'exécutent comme workload vendor_archive à usage unique, épinglé par hachage, dans une microVM Kata qualifiée. Le broker de confiance garde les identifiants réutilisables hors du JavaScript vendeur et médie les requêtes sortantes.
Lorsqu'un outil d'extension est ajouté à un Agent standard, Scrydon vérifie l'artefact installé exact, la liaison de compte, la politique, la DLP et le backend d'exécution avant la soumission de l'exécution. Un outil qui n'est pas prêt reste visible mais désactivé, avec une remédiation, dans le sélecteur ; un outil précédemment enregistré affiche le même avertissement dans le bloc Agent. Les sélections explicites ne sont jamais omises silencieusement ni converties en l'outil Search intégré sans identifiants.
Architecture
┌─────────────────────────────────────────────────────────┐
│ Your Code (TypeScript) │
│ │
│ defineExtension({ auth, provides: { toolkits: [ │
│ defineToolkit({ block, tools: [ │
│ defineTool({ input, output, execute }) │
│ ]}) │
│ ]}}) │
└─────────────────┬───────────────────────────────────────┘
│ sdk-authoring extension build
▼
┌─────────────────────────────────────────────────────────┐
│ Archive (.tar.gz) │
│ ├── manifest.json (metadata, JSON Schemas, UI def) │
│ ├── dist/index.js (compiled ESM, all deps inlined) │
│ └── assets/ (icons, optional) │
└─────────────────┬───────────────────────────────────────┘
│ Deliver via an extension source (Git/OCI)
▼
┌─────────────────────────────────────────────────────────┐
│ Platform Runtime │
│ │
│ Manifest Catalog ── metadata (what blocks/tools exist) │
│ ActorBackend ─────── canonical security-floor selector │
│ Runtime Plane ────── one vendor microVM per invocation │
│ Egress Broker ────── auth, policy, DLP, and audit │
└─────────────────────────────────────────────────────────┘Concepts clés
| Concept | Rôle |
|---|---|
| Vendor | Conteneur de niveau supérieur — métadonnées, configuration d'auth et un ou plusieurs produits |
| Product | Unité de regroupement activée/désactivée par organisation |
| Tool | Logique d'exécution — entrée/sortie validée par Zod avec une fonction execute() |
| Block | Interface de l'éditeur de workflow — champs de formulaire (subBlocks), flux de données (inputs/outputs) |
| Capability | Interfaces d'exécution optionnelles — LLM, Embedding, STT, TTS, Image, Vidéo, OCR, Modération, Recherche web, Webhooks, Discovery |
| Manifest | Métadonnées JSON générées automatiquement — la plateforme les lit sans charger votre code |
| Backend acteur | Backend sélectionné par la plateforme. Un manifeste ou une organisation peut renforcer l'isolation, mais jamais affaiblir le minimum de la plateforme |
| MicroVM vendeur | Frontière OS neuve pour le code d'outil non-Scrydon, distincte de toute microVM Agent |
Modèle de sécurité
L'exécution des outils suit un chemin gouverné unique avec un minimum de sécurité fondé sur la provenance :
- Aucune confiance par le nom — seule une source Scrydon exacte, archivée avec la version et révisée peut utiliser le backend Worker Thread approuvé
- Isolation OS pour les autres outils — les archives d'outils non-Scrydon livrées ou installées par une organisation exigent le backend microVM
vendor_archiveattesté du Runtime Plane - Épinglage de la source — l'archive active est revérifiée par rapport à son identité SHA-256 avant l'exécution
- Confinement des identifiants — le code vendeur voit des placeholders limités à l'invocation ; le broker d'egress de confiance matérialise les identifiants réutilisables uniquement dans la requête autorisée réelle
- Egress et DLP non contournables — les sockets directs sont bloqués à la frontière réseau de la VM ; DNS, redirections, plages privées, politique de destination, DLP sortante et audit s'appliquent aux requêtes émises
- Refus fermé — l'absence de KVM, d'images épinglées, de preuve de qualification, de DLP/audit ou de stockage de grants à usage unique rend l'outil indisponible ; aucun repli vers Worker Thread
- Validation du manifeste — la validation des schémas Zod à l'installation rejette les archives malformées
Les capacités temps réel et de modèle utilisent leur propre backend de capacité. Leur comportement ne prouve pas qu'un outil s'est exécuté dans une microVM vendeur.
Créez votre première extension en 5 minutes avec l'exemple hello-world
Référence API complète pour defineExtension, defineTool, defineBlock et plus encore
Ajoutez des runtimes de modèle/fournisseur sélectionnables, des webhooks et la découverte à votre vendeur
Livrez des archives via des sources d'extension, et gérez les extensions installées