OpenHands : Une plateforme ouverte pour les développeurs logiciels IA en tant qu'agents généralistes

Guide de lecture

Problème et motivation

Le développement logiciel constitue l'une des interfaces les plus expressives par lesquelles les humains interagissent avec le monde numérique. Si les grands modèles de langage (LLM) peuvent générer des extraits de code isolés, l'ingénierie logicielle en conditions réelles exige des interactions à long terme : naviguer dans des dépôts, modifier des architectures multi-fichiers, exécuter des commandes bash, lire la documentation via des navigateurs web et s'autodéboguer grâce aux retours d'exécution.

Les frameworks d'agents antérieurs souffraient souvent de lacunes architecturales majeures : manque d'environnements d'exécution isolés, exécuteurs de code sans état (stateless), absence de capacités de navigation web multimodale ou absence d'outils d'évaluation standardisés sur des domaines hétérogènes. OpenHands (anciennement OpenDevin) répond à ce besoin avec une plateforme open source (sous licence MIT) offrant des environnements d'exécution en bac à sable (sandbox), des interfaces agent-machine (ACI) extensibles, une coordination multi-agents et une évaluation comparative standardisée.

Idées clés

• Architecture de flux d'événements (Event Stream) : Les instructions utilisateur, les actions des agents et les observations à l'exécution sont suivies chronologiquement dans un flux d'événements qui unifie la communication entre les interfaces utilisateur, les agents et les environnements d'exécution sandboxés.
• Primitives en langages de programmation (PL) : Au lieu d'API personnalisées fragiles, les interactions des agents reposent sur des actions génériques : IPythonRunCellAction, CmdRunAction et BrowseInteractiveAction (via BrowserGym).
• AgentSkills extensible : Un package Python modulaire préchargé dans le noyau IPython fournit des utilitaires de haut niveau (par exemple, l'édition de lignes basée sur l'AST edit_file, l'analyse de PDF, l'extraction d'images multimodales) sans réinventer les packages existants.
• Délégation d'agents : Des agents spécialistes gèrent des flux de travail propres à leur domaine (par exemple, déléguer des tâches web via AgentDelegateAction à un BrowsingAgent dédié).
• Contrôle qualité via des tests simulés (mocked) : Des tests d'intégration continue de routine évaluent les régressions de prompts, les actions et la stabilité du bac à sable à l'aide d'une mise en cache déterministe des paires prompt-réponse, évitant ainsi des appels d'API en temps réel coûteux.

Méthode (avec les équations clés)

Le cycle d'exécution d'OpenHands fonctionne selon une fonction d'étape discrète où l'agent mappe un état de l'environnement $\mathcal{S}$ à une action $a\in \mathcal{A}$ : $$a_t=\text{Agent.step}({\mathcal{S}}_t)$$ Ici, l'état résume l'historique chronologique des actions et observations antérieures : $${\mathcal{S}}_t=\{(a_0,o_0),(a_1,o_1),\dots ,(a_{t-1},o_{t-1})\}\cup {\mathcal{M}}_t$$ où ${\mathcal{M}}_t$ assure le suivi des métadonnées d'état auxiliaires (coût cumulé des LLM, pile de délégation multi-agents active, paramètres de configuration).

L'espace d'action $\mathcal{A}$ comprend :

• CmdRunAction(command) : Exécute des commandes bash arbitraires dans le shell Linux cible.
• IPythonRunCellAction(code) : Exécute du code Python avec état dans un noyau Jupyter persistant, exposant AgentSkills.
• BrowseInteractiveAction(code) : Exécute des primitives BrowserGym pilotées par Playwright (click(bid), fill(bid, val), goto(url), etc.).
• AgentDelegateAction(subtask, agent_name) : Empile un sous-objectif sur la pile de l'agent pour invoquer un spécialiste.
• AgentFinishAction() : Termine l'exécution.

L'exécution a lieu dans un bac à sable Docker client-serveur sécurisé. Les conteneurs Docker de base sont étendus avec un serveur d'API REST OpenHands (runtime.py), étiquetés à l'aide d'un double mécanisme de taggage : un hash MD5 du contenu (target_image_repo:target_image_hash_tag) pour une reproductibilité stricte, et un tag générique sémantique (runtime:oh_v{VERSION}_{BASE_IMAGE}_tag_{IMAGE_TAG}) pour la mise en cache des builds de couches de base.

Résultats (avec les chiffres les plus importants)

OpenHands évalue les agents généralistes sur 15 benchmarks couvrant l'ingénierie logicielle, la navigation web et l'assistance générale sans adaptation de prompt par benchmark :

• SWE-Bench Lite (300 instances, sans indices) : CodeActAgent v1.8 avec claude-3-5-sonnet@20240620 obtient un taux de résolution de $26,0\%$ (coût moyen de 1,10 $ par instance), surpassant SWE-Agent ($18,0\%$) et AutoCodeRover ($19,0\%$), et approchant Aider ($26,3\%$).
• HumanEvalFix (164 instances) : CodeActAgent v1.5 avec gpt-4o-2024-05-13 résout $79,3\%$ dans une configuration d'autodébogage 0-shot (contre $48,6\%$ pour StarCoder2-15B).
• WebArena (812 instances) : BrowsingAgent v1.0 atteint $15,5\%$ en utilisant claude-3-5-sonnet et $14,8\%$ avec gpt-4o, tandis que CodeActAgent v1.8 via délégation atteint $15,3\%$.
• MiniWoB++ (125 environnements) : En zéro-shot, BrowsingAgent v1.0 avec gpt-4o atteint $40,8\%$.
• Assistance générale et raisonnement :
  • GPQA Diamond : CodeActAgent v1.8 + claude-3-5-sonnet obtient $52,0\%$ (en deçà de la référence humaine experte à $81,2\%$, mais dépassant le CoT few-shot de GPT-4 à $38,8\%$).
  • GAIA (Validation L1) : GPTSwarm v1.0 avec gpt-4o atteint $32,1\%$ ($13,2\%$ pour AutoGPT).
  • AgentBench (sous-ensemble OS) : CodeActAgent v1.5 atteint $57,6\%$.
  • MINT (Math / Code) : CodeActAgent v1.5 atteint $77,3\%$ en mathématiques et $50,0\%$ en code.

Limites et questions ouvertes

• Modifications de fichiers longs : Les primitives d'édition actuelles rencontrent des difficultés lors du traitement de dépôts volumineux ou de fichiers sources étendus où les décalages de numéros de ligne introduisent des conflits de modification.
• Intégration multimodale : Bien que les compétences auxiliaires (parse_image, parse_pdf) extraient du texte ou des résumés d'images via des modèles de vision externes, le raisonnement multimodal natif au niveau du navigateur et du terminal n'est pas encore totalement unifié.
• Automatisation des flux de travail : Les flux de travail reposent encore fortement sur des prompts système conçus manuellement et des boucles d'orchestration d'agents plutôt que sur des architectures de graphes automatiquement optimisées (par exemple, GPTSwarm).