BLOG
Démontage d'OpenResearch : transformer Claude Code en espace de travail local prioritaire pour les agents de recherche
Démontage technique : analyse des frameworks d’IA — explication, analyse, évaluation technique, jugement de valeur, mise en œuvre. Auteur : 永亮
Le 18 septembre 2026, alphaXiv/OpenResearch comptait 4 941 étoiles sur GitHub (au 18 septembre), 305 forks, 42 issues ouvertes, sous licence MIT ; le dépôt a été créé le 7 juin 2026. Avec près de cinq mille étoiles en un peu plus de deux mois, il arbore le badge « Trending » n° 1 (trendshift) sur son README. Sa mission se résume en une phrase : ne pas créer un nouvel agent de recherche, mais transformer ceux que vous utilisez déjà — Claude Code, Codex, OpenCode, Cursor — en agents de recherche, en leur offrant un espace de travail local prioritaire. Revues de littérature, hypothèses, expériences et rapports de recherche deviennent ainsi des artefacts versionnés. Cet article analyse le projet en six parties : ce que c’est, installation, le trio du code source, analyse critique, valeur ajoutée, et conclusion.
1. Qu’est-ce que c’est
La position d’OpenResearch est définie dans la première ligne du README : « The local-first workspace for research agents and autoresearch », et la deuxième ligne est encore plus directe — « Turn your coding agents into research agents ». Notez ce verbe : turn, transformer, et non replace. Cela admet une réalité : les capacités de raisonnement et d’appel d’outils requises par les agents de recherche sont déjà possédées par les agents de codage ; ce qui manque, c’est la structure propre à la recherche — les expériences doivent être reproductibles, les hypothèses doivent avoir une lignée, les preuves doivent demeurer dans le contexte, et les résultats doivent pouvoir être examinés. Si des agents de codage généralistes se mettent directement à la recherche, la cause d’échec la plus courante n’est pas de répondre incorrectement aux questions, mais de mélanger les modifications de différentes orientations dans un même répertoire ou de considérer un résultat obtenu une seule fois comme une conclusion citable. C’est cette structure qu’OpenResearch vise à fournir.
La pile technologique elle-même illustre ce positionnement. Sur les 515 fichiers du dépôt, Rust en occupe 3,63 Mo (115 fichiers .rs), assurant le support du runtime local et de la couche de gestion du harness ; TypeScript 1,38 Mo (89 fichiers .tsx plus 47 fichiers .ts) soutient le tableau de bord ui/ composé de 254 fichiers ; JavaScript 204 Ko se trouve principalement dans les scripts de build, et Python ne compte que 49 Ko pour 40 fichiers, répartis entre les démos et les scripts. Les répertoires de premier niveau ui/, src/, demo/, agent-skills/ (29 fichiers), macos/, docs/ forment une structure « processus local + interface navigateur + packs de compétences + coquille d’application native », sans négliger le poste de travail.
Le README condense les capacités en un tableau de six lignes : exploration parallèle (une session agent indépendante pour chaque direction de recherche, avec un git worktree isolé) ; expériences reproductibles (arbre d’expériences natif git, chaque run est une archive immuable) ; preuves dans le contexte ; agent au choix (changer de harness et de modèle à chaque session) ; calcul au choix (local, cluster propre, hébergé) ; propriété locale. Ces six points ne sont pas une liste de fonctionnalités, mais un manifeste de conception — chacun répond à une défaillance spécifique des agents de codage généralistes lors de la recherche. Notez que le sixième point, « propriété locale », est listé séparément : les artefacts et les données restent dans votre propre dépôt git, ce qui constitue une position dans cette catégorie, et non une simple fonctionnalité.
2. Installation et utilisation
Installation en une seule commande :
curl -LsSf https://openresearch.sh/install.sh | shUne fois installé, lancez orx up ; le tableau de bord local démarre sur http://127.0.0.1:4791. Les opérations suivantes se font principalement dans le navigateur : ouvrir des sessions, consulter l’arborescence des expériences, parcourir les preuves. L’outil en ligne de commande est orx. La plateforme prend en charge macOS 11 et supérieur, Linux en un clic, et Windows en version bêta (nécessite Git for Windows) — l’étiquette bêta est indiquée telle quelle ; évaluez vous-même la stabilité. De plus, cela dépend fortement de git ; sur Windows, assurez-vous d’abord que Git for Windows est installé. Côté modèles, vous pouvez connecter LM Studio, oMLX, Ollama ou tout point de terminaison personnalisé compatible OpenAI, ou utiliser directement les API cloud de divers fournisseurs ; connecter des modèles locaux signifie que le processus complet peut fonctionner sans connexion Internet, ce qui est une exigence critique pour la recherche sensible aux données.
L’utilisation se divise en deux niveaux. Niveau manuel : vous ouvrez plusieurs sessions dans le tableau de bord, chaque session correspondant à une direction de recherche. Chaque session exécute son propre agent, écrit son propre code, et vous visualisez dans la vue arborescente quelle direction a produit des résultats. Le niveau automatique s’appelle Autoresearch : donnez une idée, et l’agent parcourt lui-même le cycle « proposer une idée → modifier le code → lancer l’expérience → examiner les preuves → décider de l’étape suivante ». Plusieurs agents avancent en parallèle, et l’arbre des expériences garantit que la lignée de chaque étape est traçable.
Concernant l’exécution, il y a une option méritant d’être notée séparément : orx up --remote user@host. Le même instantané de code validé (committed) peut s’exécuter localement, sur une machine SSH distante, un cluster Slurm, K8s, Ray, HuggingFace Jobs, Modal, Tinker ou dans un environnement hébergé — le navigateur et les données restent sur votre ordinateur portable, tandis que le calcul est envoyé au GPU distant. Pour ceux dont la puissance de calcul n’est pas fixée localement, cette option détermine s’il s’agit d’un jouet ou non : la majeure partie de la puissance de calcul pour les expériences de recherche réside dans l’entraînement, l’ordinateur portable ne servant qu’à visualiser les résultats.
3. Démontage approfondi : La trinité de la couche source
C’est le cœur de l’article. Le README mentionne « local-first », « isolation », « reproductibilité », des termes que chaque outil revendique. Mais en décortiquant le code source, trois aspects sont concrétisés de manière très spécifique : l’isolation de l’arbre expérimental et du worktree, le mécanisme d’injection de playbook, et la modularité des agent-skills. On peut même pointer les numéros de ligne précis.
3.1 Isolation de l’arbre expérimental et du worktree
Le plus grand risque d’un agent de recherche est la contamination : deux agents travaillant sur des directions différentes modifient le code dans le même répertoire, s’écrasent mutuellement, et au final, personne ne peut dire quel résultat provient de quel code. La réponse d’OpenResearch se trouve dans ensure_session_worktree dans src/local/git.rs — garantir au démarrage de chaque session qu’elle dispose de son propre git worktree. Le commentaire du code source énonce le principe très simplement : « one opencode serve child per chat session, cwd=私有 worktree ». Une session égale un processus fils d’agent, le répertoire de travail est un worktree privé ; au niveau du système de fichiers, les directions sont isolées, et les agents n’ont besoin d’aucune conscience particulière.
Au-dessus du worktree se trouve l’arbre expérimental. Chaque exécution (run) d’expérience correspond à un commit sur l’arbre, un archivage immuable — une fois le run terminé, ce code, cette configuration et cette entrée ne changeront plus. Les comparaisons ultérieures sont des dialogues avec des instantanés historiques plutôt qu’avec une masse de code active. La valeur de cette conception prend tout son sens au moment de la rédaction de l’article : chaque chiffre peut pointer vers un arbre reproductible. Pour qu’un relecteur reproduise les résultats, il suffit de récupérer (checkout) l’arbre et de relancer. Ici, git n’est pas un simple accessoire au contrôle de version, c’est la structure de données expérimentale en soi — c’est là tout le poids de l’expression « git natif ».
3.2 Injection de playbook : Changer le cerveau de chaque agent
Le premier défi pour transformer un agent de codage est le prompt système. OpenResearch n’exige pas que les utilisateurs écrivent manuellement des instructions de recherche dans les fichiers de configuration de chaque outil, mais intègre plutôt un SYSTEM_PROMPT.md — un playbook de recherche scientifique, qui est injecté dans chaque session via les canaux natifs de chaque agent lors de orx up. Les trois canaux ont chacun leur point d’ancrage dans le code source : Claude Code passe par les arguments de ligne de commande, src/local/claude.rs:481 est appelé avec --append-system-prompt-file ; Codex passe par le champ developerInstructions ; OpenCode passe par la liste des instructions de la configuration. Le même playbook, trois harnais (harness), chacun l’injectant par l’interface qu’il reconnaît — c’est la signification réelle de « turn your coding agents » en ingénierie : pas de détournement, pas de patch, utilisation des mécanismes natifs, l’agent croit simplement qu’il travaille normalement.
Le playbook lui-même n’est pas un texte statique. playbook_md() dans src/local/opencode.rs:179, lors du rendu, remplace une série de marqueurs de position {token} : faits du projet, état actuel, valeurs par défaut de calcul, chemins des artefacts. Autrement dit, lorsqu’une session Claude Code démarre dans OpenResearch, elle reçoit une fiche de personnage de chercheur qui sait dans quel projet elle se trouve, où sont stockés les artefacts et où lancer les calculs par défaut, plutôt qu’un message générique du type « tu es un assistant utile ». L’ingénierie du contexte commence dès la première seconde de la session, économisant à l’utilisateur les quelques centaines de mots nécessaires pour expliquer manuellement le contexte à chaque fois.
3.3 agent-skills : Le kit de compétences de recherche en 12 modules
Le deuxième obstacle est les compétences. Savoir simplement discuter ne suffit pas, la recherche a ses propres processus : comment faire une revue de littérature, comment archiver des expériences, comment produire des graphiques, comment rédiger des rapports. Dans le répertoire agent-skills/, 12 modules sont divisés selon les processus : orx-agent-delegation (comment déléguer des tâches entre agents), orx-compute (ordonnancement de la puissance de calcul), orx-create, orx-customize, orx-evidence (gestion des preuves), orx-experiment-tree (manipulation de l’arbre d’expériences), orx-figures (génération de graphiques), orx-git, orx-instances (gestion des instances en cours d’exécution), orx-lit-review (revue de littérature), orx-paper (rédaction d’articles), orx-reports (génération de rapports). Chaque module possède un fichier SKILL.md, commençant par quatre règles cardinales — établir d’abord les lignes rouges du travail de recherche, puis discuter de la manière de travailler. Au sein d’une session, ils sont chargés à la demande via orx skill <name>, on ne prend que ce qu’on utilise, sans tout injecter dans le contexte d’un coup.
La vision d’ensemble formée par ce trio est la suivante : l’isolation du worktree garantit qu’il n’y a pas de mélange physique, l’injection de playbook garantit que chaque session suit les règles de la recherche dès la première seconde, et les 12 modules de compétences garantissent que l’agent sait comment procéder respectivement pour la revue de littérature et l’archivage des expériences. La couche de gestion du harness se trouve sous src/local/harness/, avec six fichiers : claude.rs, codex.rs, cursor.rs, opencode.rs, opencode_v2.rs, detect.rs, tous gérés de manière unifiée par AgentHost (service local basé sur axum) — le parallélisme multi-agent ne signifie pas plusieurs processus s’exécutant de manière désordonnée, mais un hôte local effectuant une planification unifiée, et detect est chargé d’identifier quels harness disponibles sont installés sur la machine. Écrire cette couche en Rust est un choix raisonnable : le processus hôte doit rester actif longtemps, gérer plusieurs processus enfants simultanément, et la sécurité de la mémoire ainsi que le modèle de concurrence y sont utiles.
IV. Un regard froid
Clarifions d’abord les chiffres. 4,941 étoiles, c’est le résultat de plus de deux mois, le README affiche le badge de première place du Trending, c’est un constat factuel ; mais la vitesse de croissance des étoiles et la fiabilité de l’outil sont deux choses différentes. Pour un projet de deux mois, 42 open issues sont là, les interfaces et commandes dans les 515 fichiers bougent encore, la méthode d’intégration écrite aujourd’hui pourrait changer demain — la licence MIT couvre le pire scénario, même si le projet cesse d’être mis à jour, la version en main peut continuer à être utilisée.
Deuxièmement, le « local-first » est à la fois un avantage et une limite. Les artefacts, les preuves et le code sont tous dans le git local, la propriété est claire, ça fonctionne hors ligne, les données ne quittent pas la machine lors de la connexion à des modèles locaux — ce sont des exigences incontournables pour ceux qui traitent des données non publiques et des résultats non publiés, le travail avant soumission ne devrait de toute façon pas être sur le cloud. Mais inversement, il n’a actuellement pas de couche de partage centralisée : la collaboration d’équipe, la publication des résultats, la synchronisation entre machines, tout doit être assemblé par vous-même en utilisant les mécanismes existants de git, l’outil ne le fait pas pour vous. Ceux qui sont habitués à la collaboration à la GitHub ressentiront un manque ici.
Troisièmement, l’autonomie d’Autoresearch doit être comprise comme présentée. La description du README est « proposer une idée → modifier le code → lancer l’expérience → voir les preuves → déterminer la prochaine étape », la direction est crédible, mais la qualité de chaque boucle dépend du modèle auquel vous vous connectez et de la puissance de calcul que vous fournissez, le prix d’un mauvais choix de direction par l’agent est de brûler la puissance de calcul de tout un arbre expérimental. L’utiliser comme assistant de recherche automatisé, c’est possible ; l’utiliser comme chercheur capable de produire des conclusions de manière indépendante, ce n’est pas possible pour l’instant.
Quatrièmement, Windows est toujours en bêta. Ceux dont la machine de développement principale est un Mac ou Linux n’y verront pas de différence, les utilisateurs Windows doivent d’abord réfléchir clairement à savoir s’ils peuvent accepter l’environnement git et l’état de bêta.
V. En vaut-il la peine
Classé par public. Pour ceux qui font de la recherche en ML, sur les systèmes ou dans tout domaine nécessitant des expériences, et qui utilisent déjà Claude Code ou OpenCode, c’est le chemin d’intégration le plus fluide : pas de migration d’outils, pas de changement d’habitudes, après orx up votre agent original gagne une ossature de recherche scientifique — l’arbre d’expériences, l’isolation des worktrees, les playbooks, les packs de compétences sont tous prêts à l’emploi, le coût d’apprentissage est presque nul. Pour ceux qui ont besoin d’exécuter des modèles localement (données sensibles, budget sensible), la connexion directe avec LM Studio, oMLX, Ollama assure une souveraineté complète sur la puissance de calcul. Pour ceux dont la puissance de calcul est distante, une seule commande orx up --remote envoie le calcul à distance, gardant le navigateur et les artefacts en local ; cette approche est bien plus saine que de forcer l’exécution sur un ordinateur portable.
Les cas où il faut attendre sont également clairs : ceux qui ne font pas de recherche expérimentale et qui ont seulement besoin de lire des articles et de prendre des notes n’utiliseront pas la plupart des 12 modules de compétences ; c’est un canon pour tuer une mouche, un flux de notes pratique suffit. Ceux qui ont de forts besoins de collaboration en équipe et qui nécessitent une gestion centralisée des résultats verront que l’architecture « local-first » va à l’encontre de leurs besoins. Ceux qui s’attendent à ce que « l’agent me rédige un article automatiquement » seront déçus si leurs attentes sont fausses, car Autoresearch est une aide au processus, pas un service de rédaction. De plus, la licence MIT et l’exécution locale rendent le coût d’essai-erreur très faible — installez-le, prenez une petite tâche de reproduction et suivez le processus, en une demi-journée vous saurez s’il vous convient ; c’est la façon la plus rentable d’essayer ce type d’outil out-of-the-box.
Conclusion
OpenResearch a répondu à une question longtemps évitée : les agents de recherche doivent-ils être créés de zéro ? Sa réponse est non — les capacités de raisonnement et d’outils de Claude Code, Codex, OpenCode et Cursor sont déjà suffisantes, ce qui manque est la structure de la recherche, et la structure peut être apportée par l’ingénierie. Ce jugement est mis en œuvre de manière très concrète dans le code source : ensure_session_worktree donne à chaque session un worktree privé, un fichier SYSTEM_PROMPT.md est injecté dans chaque session via trois canaux natifs, --append-system-prompt-file (claude.rs:481), developerInstructions et config instructions, playbook_md() remplit les faits du projet et les valeurs par défaut de calcul lors du rendu, 12 modules agent-skills sont chargés à la demande via orx skill, et la couche harness est orchestrée par AgentHost. L’arbre d’expériences pousse sur git, chaque exécution est une archive immuable, la reproductibilité passe d’une promesse à une structure de données. Pour ceux qui utilisent actuellement des agents de codage pour la recherche, c’est actuellement la solution la plus complète de « modifier plutôt que reconstruire » ; pour ceux qui étudient l’ingénierie des agents, elle démontre comment faire passer le « local-first » du slogan au numéro de ligne.
Sources de référence
- alphaXiv/OpenResearch README (GitHub ; positionnement, installation, tableau des six capacités principales, Autoresearch, aspect d’exécution)
- Code source d’OpenResearch (clone local) : src/local/git.rs (ensure_session_worktree), src/local/claude.rs:481 (—append-system-prompt-file), src/local/opencode.rs:179 (playbook_md), src/local/harness/ (claude.rs / codex.rs / cursor.rs / opencode.rs / opencode_v2.rs / detect.rs), agent-skills/ (12 SKILL.md)
- Données du dépôt : 4,941★, fork 305, issues 42, MIT, créé le 2026-06-07 (au 2026-09-18)