Raindrop Workshop : déboguer un agent depuis un démon local, et faire écrire les evals par Claude Code

Le problème visé : l'agent écrit du code qu'on ne voit pas tourner

Un agent de codage produit des tokens, des appels d'outils et des décisions intermédiaires. Ces éléments disparaissent dès que la session se termine, sauf si quelque chose les capture au passage. Raindrop Workshop se présente comme le débogueur local qui manquait à cette chaîne, avec une promesse formulée dans le README : voir l'agent réfléchir localement, au moment où cela se produit. Le public visé n'est pas l'équipe plateforme qui exploite un service en production, mais la personne qui est en train d'écrire l'agent et qui veut savoir pourquoi il a choisi tel outil plutôt qu'un autre. Le second public est plus inhabituel : l'agent de codage lui-même, à qui Workshop donne accès aux traces pour qu'il rédige des evals contre le code du dépôt. Le projet ne se contente donc pas d'afficher des spans, il les rend lisibles par un programme qui va ensuite modifier votre base de code.

Un démon local, une base SQLite, des traces poussées par le SDK

L'architecture visible dans le matériel tient en trois pièces. Un démon local écoute en HTTP et en WebSocket sur le port 5899 par défaut, et sert l'interface web à la même adresse. Une base SQLite stocke les traces, par défaut dans ~/.raindrop/raindrop_workshop.db. Côté SDK, une variable d'environnement, RAINDROP_LOCAL_DEBUGGER, indique où dupliquer les traces ; le README la décrit comme non définie par défaut, ce qui signifie que l'instrumentation doit être ajoutée explicitement. Le flux est donc descendant depuis votre application vers le démon, et non l'inverse : l'agent instrumenté pousse ses spans, l'interface les affiche en streaming sans interrogation périodique ni rafraîchissement manuel, selon la description du README. Deux commandes encadrent le cycle de vie de ce stockage : raindrop workshop status pour vérifier l'état du démon, et raindrop workshop reset pour supprimer la base locale après confirmation. Cette dernière commande mérite d'être connue avant de la lancer, parce qu'elle détruit l'historique que vous avez accumulé.

Installer : une commande, puis une barre oblique dans l'agent

L'installation tient en une ligne, et le README insiste sur le fait qu'il n'y a rien à cloner ni à compiler :

curl -fsSL https://raindrop.sh/install | bash

Ensuite, dans le dépôt ouvert avec votre agent de codage, vous lancez /instrument-agent. Le README indique que cette commande instrumente l'agent avec le traçage Raindrop et ouvre Workshop dans le navigateur. Variante interactive : raindrop workshop setup écrit le fichier .env puis démarre l'interface. Trois variables d'environnement sont documentées : RAINDROP_WORKSHOP_PORT pour le port HTTP et WebSocket, RAINDROP_WORKSHOP_DB_PATH pour le fichier SQLite, RAINDROP_LOCAL_DEBUGGER côté SDK pour l'adresse de duplication des traces. Une quatrième commande, /setup-agent-replay, génère un point d'entrée HTTP qui rejoue une trace de production contre le code réel de l'agent. C'est la partie la plus intéressante du dispositif, parce qu'un rejeu déterministe transforme un incident observé en test exécutable. Le chemin contributeur, bun install puis bun run dev, existe mais le README le réserve explicitement aux personnes qui modifient Workshop lui-même.

La boucle d'evals : ce que le README promet, et ce qu'il ne détaille pas

Le README décrit une boucle auto-réparatrice : Claude écrit l'eval, exécute votre agent, constate l'échec, corrige le code, et recommence jusqu'à ce que toutes les assertions passent. La description s'arrête là. Aucun exemple d'eval, aucun format d'assertion, aucune convention de nommage de fichier n'apparaît dans le matériel fourni. On ne sait donc pas où les evals sont écrites, comment elles sont lancées, ni comment le résultat est renvoyé à l'agent. C'est une lacune documentaire réelle, pas un détail : la promesse centrale du projet repose sur un mécanisme que le README énonce sans le montrer. Deuxième réserve, la compatibilité annoncée est large (langages TypeScript, Python, Go, Rust ; SDK Vercel AI, OpenAI Agents, Anthropic, Claude Agent, LangChain, LangGraph, CrewAI, Mastra, Pydantic AI, DSPy, Google ADK, Strands, Agno, Deep Agents ; agents de codage Claude Code, Codex, Devin, Cursor, OpenCode), mais une liste de compatibilité n'est pas une preuve de profondeur d'intégration. La boucle décrite suppose que l'agent de codage sait lire les traces et écrire dans le dépôt ; toutes les combinaisons annoncées ne se valent probablement pas sur ce point, et le README ne hiérarchise rien.

Workshop local et Raindrop Cloud : deux produits, un seul binaire

Le même binaire raindrop sert les deux modes. Workshop est le débogueur local. Raindrop Cloud est le produit hébergé, décrit comme de l'observabilité de production pour vos fonctionnalités d'IA, sans démon local. La commande raindrop cloud setup vous authentifie, écrit la clé RAINDROP_WRITE_KEY de votre organisation dans ./.env, et installe le serveur MCP hébergé ainsi que les compétences cloud (raindrop-setup, raindrop-investigate) dans vos agents. L'authentification est séparée et mise en cache dans ~/.raindrop via raindrop login, avec raindrop logout pour effacer les identifiants. Le point à retenir pour l'exploitation : les deux installations coexistent sans se recouvrir, parce qu'elles utilisent des noms de serveurs MCP distincts (workshop contre raindrop) et des registres d'installation séparés. La désinstallation est également cloisonnée : raindrop cloud uninstall retire le MCP hébergé et les compétences cloud sans toucher à l'installation locale, et l'option --wipe supprime en plus RAINDROP_WRITE_KEY de ./.env. Ce cloisonnement est un choix de conception défendable, mais il implique deux chemins de configuration à comprendre si vous finissez par utiliser les deux.

Quand Workshop n'est pas le bon outil

Le cas le plus net est celui d'une équipe qui veut observer un agent déjà déployé. Workshop tourne en local, écrit dans une base SQLite sur votre machine, et son installation par défaut démarre un démon. Pour des traces de production, le README renvoie vers Raindrop Cloud ; utiliser Workshop comme substitut reviendrait à faire remonter des données de production vers un poste de développeur. Deuxième cas défavorable : un environnement où l'installation par script curl piped vers bash est interdite par la politique interne. Le README ne propose pas d'alternative packagée pour les utilisateurs ; la compilation depuis les sources est présentée comme réservée aux contributeurs, et rien n'indique qu'elle produise un artefact destiné à la distribution. Troisième cas : une équipe qui ne peut pas laisser un agent modifier son code de façon autonome. La boucle d'evals suppose que l'agent corrige le code après un échec d'assertion, et un tel comportement se heurte frontalement à une revue obligatoire avant commit. Le README ne décrit aucun mode où l'agent proposerait un correctif sans l'appliquer.

L'alternative évidente : instrumenter OpenTelemetry et regarder ailleurs

L'approche concurrente la plus directe consiste à instrumenter l'agent avec OpenTelemetry et à envoyer les spans vers une plateforme d'observabilité généraliste (Jaeger, Grafana Tempo, Honeycomb, Datadog). La différence n'est pas dans le transport mais dans ce que le système fait des données. Une plateforme généraliste vous donne des requêtes, des tableaux de bord et des alertes sur des spans ; elle ne connaît ni votre agent de codage ni votre dépôt. Workshop se place à l'intérieur de la boucle de développement : l'interface est locale, l'agent de codage lit les traces, et le point d'entrée de rejeu généré par /setup-agent-replay relie une trace à l'exécution de votre code. En contrepartie, vous renoncez à la rétention longue, aux comparaisons entre versions déployées et aux alertes, sauf à basculer vers Raindrop Cloud. Le choix se résume donc à ceci : une plateforme généraliste vous dit ce qui s'est passé en production, Workshop vous aide à écrire le test qui empêchera la récidive. Les deux ne s'excluent pas, mais ils ne répondent pas à la même question.

Maintenance, licence et rythme de publication

Le dépôt est publié sous licence MIT, ce qui autorise la modification et la redistribution avec conservation de l'avis de licence ; ce n'est pas un avis juridique, et les obligations exactes dépendent de votre usage. Le rythme des versions est le point à intégrer dans votre planning : les notes fournies montrent v0.1.19, puis v0.1.20 et v0.1.21 le même jour, le 22 août 2026. Un projet qui publie deux versions en une journée se trouve en phase de développement actif, ce qui est cohérent avec un numéro de version en 0.1.x. Concrètement, cela signifie que la commande raindrop update peut changer le comportement du démon et de l'interface entre deux de vos sessions, et que le schéma de la base SQLite peut évoluer sans procédure de migration documentée dans le matériel fourni. Avant de faire dépendre un test d'intégration de la boucle d'evals, il faut vérifier ce point : une base locale qui ne se met pas à niveau toute seule se solde par un raindrop workshop reset, donc par la perte de l'historique. La variable RAINDROP_WORKSHOP_DB_PATH est le levier à utiliser si vous voulez placer cette base sur un volume sauvegardé plutôt que sous ~/.raindrop.

Conclusion éditoriale

Workshop convient aux équipes qui développent un agent en TypeScript ou Python et veulent voir les spans sans envoyer de données à un service hébergé, à condition d'accepter un démon local, une base SQLite sous ~/.raindrop et un cycle de publication très rapproché. Il ne convient pas si vous cherchez uniquement de l'observabilité en production : c'est le rôle de Raindrop Cloud, et le README indique explicitement que les deux installations coexistent avec des noms de serveurs MCP distincts. Avant d'adopter, vérifiez trois choses concrètes : que RAINDROP_WORKSHOP_DB_PATH pointe vers un volume que vous sauvegardez si les traces doivent survivre à un redémarrage, que /instrument-agent ne modifie pas des fichiers que vous ne voulez pas voir touchés, et que l'agent de codage retenu figure bien dans la liste annoncée (Claude Code, Codex, Devin, Cursor, OpenCode), car la boucle d'evals décrite repose sur cette intégration.

Sources officielles

1. License: MIT
2. Project website
3. raindrop-ai/workshop on GitHub
4. README
5. Releases