Flyto2 Core : un moteur d'exécution open source pour les workflows d'automatisation et d'agents IA
Flyto2 Core est le noyau d'exécution open source pour les flux de travail d'automatisation et d'agent IA : 452 modules basés sur le registre, transport natif MCP, recettes YAML, capture de preuves, relecture, déclencheurs, file d'attente, gestion des versions et mesure.
En bref
- De quoi s’agit-il ?
- Flyto2 Core est un runtime basé sur Python qui exécute l'automatisation de navigateur, les appels API, le traitement de données et l'utilisation d'outils d'agents IA via un registre de 468 modules, des recettes YAML et des workflows rejouables.
- À qui s’adresse-t-il ?
- Le projet convient aux équipes qui cherchent le moteur Flyto Core et acceptent le périmètre décrit par flyto-core. Il convient moins à celles qui attendent une fonction, une plateforme ou une garantie que le README ne mentionne pas.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 8 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Qu'est-ce que Flyto2 Core ?
Flyto2 Core est le noyau d'exécution open source pour l'automatisation et les workflows d'agents IA. Il fournit un runtime local pour l'automatisation de navigateur, l'intégration d'API, le scraping web, l'automatisation de serveur MCP, des recettes YAML rejouables, la capture de preuves, et des outils déterministes que les agents peuvent appeler sans générer de code non examiné. Le README le décrit comme le moteur open source derrière le produit Flyto2, conçu pour des tâches impliquant l'ouverture d'une page, la capture de preuves, l'extraction de données, la vérification des performances et la nouvelle tentative uniquement de l'étape échouée.
Installation et première exécution · flytohub flyto core
Le README montre l'installation avec pip : `pip install flyto-core` pour le moteur principal, la CLI et le serveur MCP, et `pip install flyto-core[browser]` pour ajouter l'automatisation de navigateur via Playwright. Ensuite, `playwright install chromium` configure le navigateur. Une commande de démarrage rapide est `flyto recipe competitor-intel --url https://github.com/pricing`, qui exécute une recette en 12 étapes qui lance un navigateur, navigue, prend des captures d'écran, capture Web Vitals et écrit un rapport JSON. Le README affiche la sortie d'une telle exécution, montrant chaque étape avec son temps et son statut.
Trace d'exécution et relecture
Le contrat d'exécution principal est la trace et la relecture. Chaque étape produit un enregistrement structuré de l'entrée, de la sortie, du temps et du statut. La relecture réexécute à partir de n'importe quelle étape avec le contexte d'origine ou modifié, donc si l'étape 8 échoue, vous pouvez exécuter `flyto replay --from-step 8` et les étapes 1 à 7 sont ignorées. Le moteur prend également en charge les points d'arrêt, les instantanés de preuve (état complet avant et après chaque étape), la lignée des données et des gardes de délai configurables au niveau du workflow et de l'étape.
Catalogue de modules et recettes
Le README rapporte 468 modules adossés à un registre répartis dans 85 catégories de catalogue, y compris les modules browser, flow, array, api, data, string, ai, object, testing, image, verify, file, stats, test, check, crypto, http et validate, ainsi que 66 préfixes supplémentaires. Il liste également 41 recettes intégrées, qui sont des modèles de workflow YAML pour des tâches comme l'audit de site, le renseignement concurrentiel, le scraping, la capture d'écran, l'OCR et les intégrations. Le catalogue de modules est généré à partir de `ModuleRegistry` et documenté dans `docs/TOOL_CATALOG.md`. Le README ne spécifie pas le contenu exact de chaque module au-delà des exemples de tableau.
Interfaces : CLI, MCP, HTTP et Python
Flyto2 Core fournit quatre interfaces documentées. La CLI exécute des recettes et des workflows avec des commandes comme `flyto run workflow.yaml`. Le serveur MCP peut être ajouté à Claude Code, Cursor ou Windsurf via `claude mcp add flyto-core -- python -m core.mcp_server`, exposant tous les modules comme outils. L'API HTTP peut être démarrée avec `flyto serve` et offre des endpoints pour l'exécution de workflow, la relecture, l'exécution d'un module unique, la découverte de modules et le transport HTTP streamable MCP. L'API Python permet l'exécution directe via `ModuleRegistry.execute`.
Configuration, sécurité et licence
La configuration est gérée via des extras de package, des arguments CLI, des paramètres de workflow, une politique de module, des variables d'environnement et un état d'exécution local. Le README mentionne que les commutateurs sensibles à la sécurité (réseau, système de fichiers, authentification, rappels et permissions) sont documentés dans `docs/CONFIGURATION.md`. Il affirme également que la ligne 2.26.x inclut des clients HTTP protégés pour prévenir les contournements SSRF et des gardes de chemin sandbox pour les écritures de fichiers/données. Les vulnérabilités de sécurité doivent être signalées via security@flyto2.com. Le projet est sous licence Apache License 2.0, qui accorde des licences de droit d'auteur et de brevet pour l'utilisation, la reproduction et la distribution. Le texte de licence ne fournit aucune garantie ni engagement de support.
flyto-core dans son périmètre réel
flyto-core doit être lu à partir de les nœuds, déclencheurs et sorties décrits dans le README. Le README décrit un périmètre précis, avec des entrées et des sorties observables; il ne justifie pas d’attribuer au projet des intégrations qui ne sont pas citées. Cette distinction compte lorsque l’outil est placé dans une chaîne plus large. Une dépendance, un format ou une plateforme peuvent modifier le résultat sans que le dépôt prétende les prendre en charge.
Le bon point de départ est donc un flux minimal avec les dépendances déclarées. Observez le fichier créé, le message affiché et les erreurs éventuelles. Une démonstration réussie établit ce que flyto-core fait dans ce cas précis; elle ne transforme pas une option documentée en garantie générale.
Ce que l’équipe devra maintenir
flyto-core impose une lecture attentive de ses versions, de ses dépendances et de ses conventions. Les noms de fichiers, les paramètres et les exemples du README font partie de l’interface pratique. Une mise à jour peut changer une API, une sortie ou une exigence de plateforme; le dépôt consulté reste la source de ces détails.
Pour une équipe, la charge ne se limite pas à l’installation. Il faut conserver la configuration utilisée, distinguer les données d’entrée des artefacts générés et savoir où le projet signale ses incompatibilités. Cette discipline est particulièrement utile pour le moteur Flyto Core, car l’écart entre un exemple minimal et une application complète peut être substantiel.
Conclusion éditoriale
Le projet convient aux équipes qui cherchent le moteur Flyto Core et acceptent le périmètre décrit par flyto-core. Il convient moins à celles qui attendent une fonction, une plateforme ou une garantie que le README ne mentionne pas. Avant décision, un flux minimal avec les dépendances déclarées, puis examinez précisément les sorties et les erreurs.
Notes de la communauté