Smithers : des exécutions durables et rembobinables pour les agents de codage

Un runtime pour un travail d'agent qui survit à la session

Le README présente Smithers comme un runtime durable pour le travail des agents de codage : les cas où un agent modifie un vrai dépôt sur de nombreuses étapes et où ce travail doit être inspectable, approuvable et récupérable. La promesse centrale est que chaque étape d'une exécution est une ligne de base de données, ce qui rend le suivi en direct, le rembobinage et le rejeu natifs plutôt qu'ajoutés après coup. Une exécution peut être forkée depuis n'importe quelle étape antérieure pour créer une chronologie alternative. Le README est explicite sur la limite : pour une réponse unique issue d'un prompt, il dit d'appeler le modèle directement ; Smithers est fait pour les modifications multi-étapes, les approbations humaines, les boucles de revue et la survie aux crashs.

Une création par prompt, pas à la main

Le README indique que les utilisateurs n'écrivent jamais un workflow à la main. Décrivez le résultat en anglais simple et l'agent de codage construit le workflow à partir des mêmes primitives que le pack intégré. Le prompt est l'étape de création. L'installation se fait avec `bunx smthrs init` depuis l'intérieur d'un projet : cela installe la compétence smithers dans les agents de codage détectés et crée un répertoire `.smithers/` avec les workflows de création. Le README ne précise pas quels agents sont détectés automatiquement au-delà de Claude Code et Pi comme exemples, et ne liste pas non plus le comportement complet de l'installation ; ces détails restent sur le site de documentation.

La durabilité comme différenciateur

Le README appelle la durabilité le différenciateur. Chaque étape terminée est persistée dans SQLite au moment où elle se termine. La boucle du runtime est : rendre le workflow, exécuter la tâche, valider la sortie contre un schéma, persister dans SQLite, re-rendre depuis l'état persisté pour décider de la tâche suivante. Un crash reprend depuis la dernière écriture, la tâche interrompue s'exécute à nouveau comme nouvelle tentative et les tâches terminées sont ignorées. Les approbations, les questions humaines, les nouvelles tentatives et le rejeu sont des citoyens de première classe dans ce modèle. Le README dit aussi que les exécutions survivent aux outils instables, mais ne donne pas de détails sur la classification ou la nouvelle tentative des échecs d'outils.

Les workflows sont des arbres JSX de tâches

Un workflow est un arbre JSX de tâches. L'exemple du README montre une boucle qui se répète jusqu'à ce qu'un relecteur approuve, avec un agent codeur, un agent relecteur en lecture seule, un maximum de cinq itérations et des sorties validées par schéma. Le code d'exemple référence des noms de modèles comme gpt-5.6-luna et gpt-5.6-sol, que le README n'identifie pas comme des modèles de production. Le README note que les utilisateurs n'écrivent généralement pas ces fichiers à la main, puisque l'agent les produit, mais le format est versionnable, revoyable et réexécutable, ce qui constitue le contraste avec le fan-out éphémère de sous-agents.

Aucun pari sur un seul fournisseur ou modèle

Le README dit que Smithers ne parie pas sur un seul laboratoire ou un seul framework. Les tâches peuvent pointer vers Claude Code, Codex, Cursor, Pi, Antigravity ou n'importe quel modèle du SDK AI, et plusieurs peuvent être mélangés dans un seul workflow. La même primitive Sandbox exécute un agent localement via Bubblewrap, Docker ou Microsandbox, ou via n'importe quel backend implémentant SandboxProvider. Le README dit aussi que `bunx smthrs mcp add` connecte le serveur MCP à Cursor, Copilot, Hermes, OpenClaw et environ 20 autres agents de codage, sans les énumérer.

Observer et piloter les exécutions depuis la CLI

Les workflows préinstallés s'exécutent directement depuis la CLI. Le README liste `bunx smthrs ps` pour lister les exécutions actives, en pause et récemment terminées ; `inspect` pour les étapes, agents, approbations et sorties d'une exécution ; `logs` pour suivre le journal d'événements ; `chat` pour lire la sortie de conversation de l'agent ; et `monitor` pour ouvrir une page en direct avec une liste d'exécutions groupées et un statut par nœud. Le contrôle des exécutions inclut `up` avec un drapeau `--resume`, `rewind` vers une étape antérieure, `fork` et `replay`. Le README indique que ces commandes existent et ce qu'elles font, mais ne documente pas leurs ensembles d'options complets.

Ce qui est fourni dans le paquet

`init` installe un paquet ciblé avec trois workflows de création : create-workflow, create-skill et docs-driven-development ; les anciens démarreurs restent sous examples/init-pack/. Le dossier examples contient plus de 100 workflows exécutables couvrant les boucles de revue, les flottes de tickets parallèles, les superviseurs, les débats, les migrations et plus encore. Fonctionnalités de contrôle listées dans le README : approbations pour verrouiller les étapes risquées, isolation par sandbox, métriques Prometheus et traces OpenTelemetry prêtes à l'emploi avec une pile Grafana locale en une commande, suites d'évaluation avec optimisation de prompts de style GEPA, mémoire inter-exécutions dans SQLite local avec rappel sémantique optionnel via Hindsight, et rechargement à chaud des prompts, de la configuration ou du JSX en cours d'exécution. Le dépôt est sous licence MIT, copyright 2025 William Cory ; la licence accorde l'utilisation, la copie, la modification, la fusion, la publication, la distribution, la sous-licence et la vente, et stipule que le logiciel est fourni tel quel, sans garantie. Le texte de licence ne dit rien sur le support, les garanties de sécurité ou les engagements de maintenance.

La valeur de Smithers apparaît lorsque l'exécution doit être reprise ou examinée, pas lorsqu'il suffit d'obtenir une réponse unique. Le README recommande « bunx smthrs init » dans le projet : cette commande installe la compétence et crée « .smithers/ ». Une fois un workflow lancé, « bunx smthrs ps », « inspect » et « logs » donnent des points d'observation distincts, tandis que « rewind », « fork » et « replay » permettent de comparer des trajectoires. Le modèle de persistance SQLite signifie que l'état écrit après une étape devient la base de la décision suivante ; il faut donc examiner les sorties validées par schéma et les tentatives après une interruption. L'exemple de boucle avec un agent codeur, un agent relecteur en lecture seule et cinq itérations montre une structure de revue concrète, sans prouver que tous les modèles cités sont disponibles. Bubblewrap, Docker et Microsandbox sont des backends annoncés pour Sandbox, mais la politique d'isolation effective dépend de la configuration choisie. Pour un usage d'équipe, les fichiers JSX générés, les approbations et les traces OpenTelemetry méritent une revue séparée.

Conclusion éditoriale

Smithers persiste chaque étape terminée dans SQLite, re-rend le workflow depuis cet état et laisse la création du workflow à l'agent de codage lui-même. Le README trace une ligne claire : l'utiliser pour des modifications multi-étapes de dépôt, des approbations, des boucles de revue et la reprise après crash, pas pour des réponses à un seul prompt. Pour ce projet, vérifiez d'abord les commandes, fichiers et versions cités dans le README avant de l'intégrer à votre flux.

Sources officielles

1. Official documentation
2. Official README
3. Project repository
4. Release notes