Continuum et le choix d'une agent runtime : 7 capacités à vérifier du notebook à la production
Dans un notebook, vous avez fait tourner un agent : il appelle des outils, raisonne en plusieurs étapes, la démo est belle. Mais dès que vous le passez en production, où il doit gérer la concurrence, retenir le contexte, redémarrer après un plantage en cours de route et rester traçable en cas de problème, tout un tas de pièces manquantes apparaît. Choisir une agent runtime, c’est au fond choisir la couche qui manque entre le jouet et la production.
Continuum est une réponse de ShyftLabs. Mais plutôt que de simplement la vanter, il est plus utile de s’en servir pour répondre à une question plus tranchante : quelles capacités faut-il vraiment vérifier au moment de choisir une agent runtime ?
Là où la frontière casse
La rupture arrive rarement au premier appel LLM. Elle arrive quand une tâche longue tombe au milieu, qu un outil écrit seulement une partie du résultat, que le contexte disparaît après redémarrage ou que le coût monte sans signal. Une runtime doit rendre ces ruptures visibles et choisir entre reprise, dégradation ou arrêt propre.
Capacités en pratique
Pour valider, regardez des faits vérifiables : sorties structurées, routage de modèles traçable, mémoire courte et longue séparées, outils MCP avec artefacts, workflows durables, tracing et gouvernance. Chaque capacité doit avoir un test, sinon elle reste un mot d architecture.
Chemin de commande minimal
from orchestrator.agent import AgentRunner puis AgentRunner.run(agent, input_data) suffit pour un petit essai. Pour la production, vérifiez ensuite où Redis, la base vectorielle, Temporal et Langfuse sont réellement branchés.
Tableau de décision
| Critère | Continuum convient | Framework léger convient |
|---|---|---|
| Plusieurs agents | Oui, si routage et validations comptent | Graphes simples |
| Coût | Budget et Smart Inference à tester | Facturation directe provider |
| Exploitation | Équipe infra disponible | Script ou démo |
Liste de risques
- Tester panne provider et dépassement de budget.
- Documenter suppression mémoire et export de données.
- Coupler les droits d écriture outil à une validation humaine.
- Prévoir des switches de rollback pour routing, mémoire, MCP et Temporal.
L’essentiel : ce qu’est Continuum
Continuum est l’agent runtime Python de niveau production de ShyftLabs, open source sur GitHub sous shyftlabs/continuum, avec le slogan « pour ceux qui livrent ».
Ses capacités tiennent en une phrase : il réunit un cœur d’agent typé et propre, une inférence multi-modèles attentive au coût, une mémoire long et court terme à état, des appels d’outils au standard ouvert (MCP), l’exécution durable et l’observabilité de bout en bout derrière une API petite, composable et type-safe. Dit simplement, il comble la couche d’ingénierie qui manque entre « ça tourne » et « ça se livre de façon fiable et reste visible ».
Une attente à caler d’abord : ce n’est pas un énième framework léger qui sort une démo en cinq minutes, mais une runtime conçue contre une checklist de production. Voyez donc les sept dimensions ci-dessous moins comme les arguments de vente de Continuum que comme une grille de score dans votre propre main. Que vous le choisissiez ou non au final, cette grille reste utile.
Avec Continuum comme loupe : 7 dimensions au moment de choisir
Les points ci-dessous sont à la fois la liste de capacités de Continuum et une grille de score à appliquer à n’importe quel framework d’agents.
1. Orchestration et patterns multi-agents. Les vraies tâches sont rarement un agent qui file tout droit sur un seul chemin. Continuum offre des primitives d’agent fortement typées, des hooks de cycle de vie complets, une sortie structurée validée par schéma, et 9 patterns multi-agents composables : séquentiel, parallèle, boucle, routage, planification, réflexion, débat, scatter et superviseur. Au moment de choisir, vérifiez qu’il gère les formes de collaboration dont vous avez besoin et que la sortie est structurée et validable plutôt que de simples chaînes recollées. Les résultats intermédiaires passés en chaînes recollées deviennent la panne la plus dure à tracer dès que les agents se multiplient.
2. Accès aux modèles et coût. L’élément le plus sous-estimé et le plus coûteux. Le Smart Inference de Continuum laisse les agents appeler un seul endpoint compatible OpenAI, tandis que le routeur répartit selon complexité et coût sur, selon le projet, 250+ modèles et 45+ fournisseurs, avec un registre de budget et des plafonds de sortie dynamiques, et des niveaux strict/modest/quality par agent. Les points de contrôle : le framework est-il indépendant du modèle, sait-il router par coût, y a-t-il un contrôle de budget. Sinon la facture vous échappe.
3. Mémoire. Un agent doit « se souvenir » pour tenir la route. Continuum sépare les sessions court terme (Redis) de la mémoire vectorielle long terme (mem0 + Qdrant/Milvus). Vérifiez s’il couvre les deux couches ou s’il ne vous donne qu’un buffer de session. Un agent avec un seul buffer de session « oublie » après une conversation et n’est pas utilisable durablement.
4. Outils et standards. Le standard de fait pour l’appel d’outils est désormais MCP. Continuum est natif MCP, avec un ToolExecutor et des run artifacts. Qu’une runtime soit native MCP est un bon indicateur du coût de branchement à l’écosystème.
5. Exécution durable et validation humaine. Les tâches longues redoutent de planter à mi-chemin et de tout reprendre. Continuum utilise Temporal pour des workflows durables et inclut des portes d’approbation. Ces deux-là, la reprise et la validation humaine, sont invisibles au stade démo et cruciales dès la mise en production.
6. Observabilité. Ce qu’on ne peut pas tracer, on ne peut pas l’exploiter. Continuum branche Langfuse pour le tracing, les métriques et la remontée d’erreurs, de sorte que vous voyez chaque appel LLM, appel d’outil, récupération mémoire et handoff. Contrôle obligatoire : peut-on tracer chaque étape de l’agent.
7. Déploiement et gouvernance. Enfin : « peut-on le confier à l’entreprise en confiance ». Continuum est auto-hébergé et indépendant du cloud, et met l’accent sur l’audit et la conformité d’entreprise. En secteur régulé, ce point est souvent une porte dure.
Pourquoi Smart Inference mérite un regard à part
Des sept dimensions, la deuxième, accès aux modèles et coût, est la plus susceptible de virer à la catastrophe de facturation après la mise en ligne, et le Smart Inference de Continuum vise exactement cela, d’où l’intérêt de le détailler à part.
L’idée centrale : votre agent ne parle qu’à un seul endpoint compatible OpenAI, le reste revient au routeur. Le routeur classe chaque prompt par complexité et coût et répartit sur, selon le projet, 250+ modèles et 45+ fournisseurs, envoyant les requêtes simples à de petits modèles bon marché et n’escaladant que les difficiles vers de plus gros, plus chers. Il embarque aussi un registre de budget et des plafonds de sortie dynamiques, avec des niveaux strict, modest et quality réglables par agent.
Le câblage est léger : réglez SMART_GATEWAY_URL, et GatewayProvider remplace automatiquement les clients par fournisseur que vous mainteniez par éditeur, si bien que vous n’écrivez plus de code d’intégration distinct par éditeur de modèle. Pour des agents qui tournent longtemps et appellent beaucoup, cette couche contient le coût et transforme « changer de modèle » d’un changement de code en un changement de config.
En gros comment l’utiliser
L’usage minimal est concis : après git clone, from orchestrator.agent import AgentRunner, puis AgentRunner.run(agent, input_data) lance un agent.
from orchestrator.agent import AgentRunner
response = AgentRunner.run(agent, input_data)
Mais exploiter vraiment ces sept capacités est une autre affaire : mémoire long terme sur Qdrant ou Milvus, sessions sur Redis, workflows durables sur Temporal, tracing sur Langfuse. La façon de combiner les modules et d’écrire la config fait foi via la doc ; le projet est jeune, les détails peuvent bouger.
Vu autrement, ce ne sont pas des ornements optionnels mais le socle qui remplit la dimension correspondante : sans Redis et base vectorielle, la dimension mémoire est vide ; sans Temporal, pas d’exécution durable ; sans Langfuse, l’observabilité n’est qu’un slogan. Le réflexe pragmatique est donc de décider d’abord des dimensions dont vous avez vraiment besoin, puis de l’infrastructure à câbler, au lieu d’empiler tout le stack d’emblée.
Coût de démarrage et pour qui c’est fait
Disons-le d’emblée : Continuum n’est pas un pip install d’une ligne de bibliothèque légère, mais un framework d’entreprise qui exige de l’infrastructure. Son point idéal est donc les équipes qui amènent vraiment des agents en production, voire à l’échelle entreprise ; si vous voulez juste un petit script à agent unique pour jouer, c’est surdimensionné, et un framework plus léger ou un SDK de modèle direct est plus rapide.
| Votre situation | Conseil |
|---|---|
| Amener un système multi-agents en production/à l’échelle entreprise, soucieux du coût et de l’observabilité | Bon choix ; il couvre l’essentiel des 7 dimensions |
| En secteur régulé avec besoin d’audit et de gouvernance | Auto-hébergement plus gouvernance est un plus |
| Juste lancer vite une démo à agent unique | Lourd ; un framework léger ou un SDK brut est plus rapide |
| Équipe sans capacité d’infra-ops (Redis/base vectorielle/Temporal) | Pesez d’abord le coût de démarrage |
| Comparer plusieurs runtimes côte à côte | Notez chaque candidat sur les 7 dimensions ci-dessus |
Les alternatives sont nombreuses. LangGraph, agentrail et diverses agent runtimes font des choses similaires, sans optimum absolu. Ce billet traite Continuum comme un exemple de checklist de sélection : le but n’est pas « prends celui-ci » mais d’apprendre à peser n’importe quel candidat avec ces sept dimensions.
Comparer les runtimes : ne pas s arrêter à ça tourne
| Option | Cas adapté | Manque principal |
|---|---|---|
| SDK modèle brut | Scripts à agent unique et tâches rares | Orchestration, mémoire, observabilité, validation humaine |
| Framework type LangGraph | Graphes d état et orchestration contrôlée | Routage de coût, gouvernance, infrastructure de production |
| Continuum | Systèmes multi-agents avec budget, persistance et observabilité | Infrastructure et exploitation plus lourdes |
| Runtime maison | Conformité spéciale ou logique métier très liée | Coût de construction et de maintenance maximal |
Redis, base vectorielle, Temporal, Langfuse
Redis couvre les sessions courtes et la reprise d état, pas la mémoire long terme. Qdrant ou Milvus couvre la mémoire vectorielle, avec gestion des embeddings, du rappel et de la suppression. Temporal sert aux longues tâches, retries, compensations et reprises. Langfuse apporte traces, métriques et replay.
La vraie limite de Smart Inference
Smart Inference centralise le routage derrière un endpoint compatible OpenAI. C est utile pour les coûts et la migration, mais cela dépend toujours des classifieurs, des providers disponibles, des budgets et des limites de sortie. En production, il faut aussi journaliser pourquoi tel modèle a été choisi et quoi faire en cas d échec ou de dépassement de budget.
Les trois pièges les plus faciles au moment de choisir
En mettant les sept dimensions en pratique, trois pièges attrapent presque tout le monde.
Le premier : prendre une démo pour une recette. Faire tourner une belle démo et tenir la concurrence de production, la reprise après plantage et la mémoire long terme sont deux choses ; la durabilité et l’observabilité qui décident vraiment du succès sont justement ce qu’on ne sent pas au stade démo. Le deuxième : brancher le modèle directement sur un seul éditeur. Le plus simple à court terme, mais à long terme cela verrouille coût et migration, et on se retrouve coincé quand un modèle augmente ou est retiré, ce qui est précisément la raison d’être du routage par coût comme Smart Inference. Le troisième : utiliser un framework d’entreprise pour un petit travail. Le point idéal d’une runtime comme Continuum, ce sont les systèmes multi-agents à l’échelle entreprise ; le forcer sur un simple petit script et le coût d’infrastructure et de maintenance dépasse le bénéfice.
Ordre de validation de l infrastructure
N activez pas toutes les dépendances en même temps. Ajoutez d abord Langfuse ou un tracing équivalent pour voir le choix du modèle, les appels d outils, les erreurs et le coût. Ajoutez ensuite Redis pour vérifier la reprise de session, puis une base vectorielle limitée aux fragments reconstruisibles, et enfin Temporal pour les tâches longues. Cet ordre sépare les problèmes au lieu de tout mélanger.
Les interrupteurs de rollback vont dans la configuration
Chaque pilote en production a besoin d interrupteurs de rollback : désactiver Smart Inference et figer un modèle, couper la mémoire et garder seulement la session courante, couper MCP et revenir aux outils manuels, couper Temporal et n autoriser que les tâches courtes. Chaque interrupteur doit avoir une valeur par défaut, un responsable et une condition de déclenchement.
Pour aller plus loin
Si vous voulez continuer sur « l’architecture d’agents » et « l’accès aux modèles », voici de bonnes lectures :
- Analyse de l’architecture DeepAgents : outils de planification, sous-agents et système de fichiers
- L’API OpenAI part toujours en timeout ? Construire un canal privé avec Workers, plus stable et à coût zéro
- Workers AI, tutoriel complet : 10 000 appels de modèle gratuits par jour, 90 % moins cher qu’OpenAI
L’erreur la plus fréquente au moment de choisir une agent runtime est de ne regarder que « est-ce qu’une démo tourne ». Ce qui décide vraiment de votre capacité à livrer, c’est si l’orchestration, le coût, la mémoire, les outils, la durabilité, l’observabilité et la gouvernance sont tous en place. Continuum emballe cette infrastructure, mais ce qui vaut le plus la peine d’emporter, c’est cette liste des « 7 capacités à vérifier » ; l’appliquer à n’importe quel candidat sert plus que de retenir le nom d’un framework précis.
FAQ
Qu'est-ce que Continuum, et quel problème résout-il ?
Quelles capacités vérifier vraiment au moment de choisir une agent runtime ?
Qu'est-ce que le Smart Inference de Continuum ?
En gros, comment utilise-t-on Continuum, et est-ce dur à démarrer ?
À qui s'adresse Continuum, et comment choisir parmi les frameworks d'agents ?
11 min de lecture · Publié le: 8 juin 2026 · Mis à jour le: 15 juin 2026
Boîte à outils AI Agent
Vous lisez le premier article de cette série. Continuez avec le suivant ou ouvrez le hub de la série pour voir tout le parcours.
Précédent
Vous êtes au début de cette série.
Suivant
guizang-social-card-skill : une chaîne de production pour cartes Xiaohongshu et couvertures WeChat
Comment utiliser guizang-social-card-skill ? Ce guide s'appuie sur le README GitHub et la doc Skills de Claude Code / Codex pour expliquer installation, gabarits, thèmes, rendu, licence et checklist QA.
Partie 2 sur 4
Articles liés
female-portrait-director : transformer les prompts de portrait en Skill réutilisable
female-portrait-director : transformer les prompts de portrait en Skill réutilisable
ADHD : corriger la convergence prématurée des agents de code par un raisonnement divergent parallèle
ADHD : corriger la convergence prématurée des agents de code par un raisonnement divergent parallèle
Mnemo, couche mémoire locale : un rappel portable pour Ollama et vos apps LLM
Commentaires
Connectez-vous avec GitHub pour laisser un commentaire