Open SWE est un framework open source permettant de créer l’agent de codage asynchrone interne d’une organisation. Un développeur peut mentionner un bot dans Slack, Linear ou GitHub ; le service assemble le contexte de problème/thread, crée un sandbox cloud persistant, clone un référentiel, planifie et modifie le code, exécute des commandes, s'engage dans une branche et ouvre ou met à jour un brouillon de demande d'extraction.
Il ne s'agit pas d'un service de codage hébergé qui devient sécurisé après l'installation. Open SWE est une architecture de référence construite sur LangGraph et Deep Agents. L'opérateur doit sélectionner des modèles et des fournisseurs de sandbox, créer des applications GitHub/Slack/Linear, sécuriser le déploiement, définir les référentiels et les jetons, ajouter une validation déterministe, contrôler l'accès au réseau et être propriétaire de chaque demande d'extraction résultante.
L'architecture de bout en bout
| Calque | Rôle publié | Décision dont l'opérateur est propriétaire |
|---|---|---|
| Invocation | Mention Slack, commentaire Linear ou commentaire GitHub PR | Qui peut déclencher quels référentiels et à quel prix |
| Contexte | AGENTS.md plus historique complet des problèmes ou des discussions | Quel contenu est fiable, expurgé ou sujet à une injection rapide |
| Harnais | Deep Agents composé à l'intérieur de LangGraph | Modèle, invite système, outils, middleware et limites d'appels |
| Bac à sable | Environnement Linux distant persistant par tâche | Fournisseur, image, sortie, durée de vie, ressources et emplacement des données |
| Outils | Shell, fichiers, HTTP, Slack, Linear, GitHub et observabilité facultative | Moindre privilège, approbations à effets secondaires et limites secrètes |
| Orchestration | Sous-agents et hooks middleware déterministes | Concurrence, budget, état partagé et gestion des erreurs |
| Livraison | Valider, pousser, rédiger des relations publiques et répondre au canal source | CI, réviseurs, politique de fusion et séparation du déploiement |
Le sandboxing réduit le risque de l'hôte, pas l'autorité externe
Le référentiel indique que chaque tâche reçoit un bac à sable cloud isolé avec des autorisations shell complètes et aucune invite de confirmation, et prend en charge les bacs à sable Modal, Daytona, Runloop, E2B et LangSmith. Un bac à sable séparé limite les conflits de système de fichiers et de processus, mais la phrase du README selon laquelle le rayon d'explosion est « entièrement contenu » ne doit pas être traitée littéralement.
L'agent peut disposer d'une sortie réseau, d'une autorité de référentiel, d'un accès au registre de packages et de API externes. Il peut exfiltrer la source, graver les crédits du modèle, ouvrir des demandes d'extraction nuisibles, abuser d'un jeton ou attaquer des services internes accessibles depuis le bac à sable. Un compromis sur le plan de contrôle du fournisseur de bac à sable peut également dépasser les limites des tâches. Le confinement nécessite une politique de sortie, des informations d’identification de courte durée, des quotas, l’isolation des fournisseurs et une porte de fusion/déploiement indépendante.
| Risque | Le bac à sable aide | Contrôle compagnon requis |
|---|---|---|
| Commande shell destructrice | Limite les dommages causés au disque/processus local à un environnement jetable | Aucun support de production ; limites de ressources/temps et démontage propre |
| Dépendance malveillante | Sépare la tâche de l'ordinateur portable du développeur | Fichiers de verrouillage, liste d'autorisation du registre, analyse et sortie restreinte |
| Utilisation abusive du jeton GitHub | Peu si le jeton permet des actions externes | Jeton d'application proxy/portée limité aux opérations de dépôt et de succursale |
| Injection rapide | Peut limiter la compromission de l'hôte | Étiquettes de confiance, politique des outils et refus des systèmes sensibles |
| Mauvais code | Permet les tests dans un environnement d'exécution isolé | CI déterministe, revue de sécurité et branches protégées |
| Fuite de données | Sépare les données du poste de travail local | Examen des fournisseurs/données, rédaction et contrôles de destination sortante |
Le problème et le texte du chat sont des instructions non fiables
Open SWE injecte le problème Linear complet ou le thread Slack dans le contexte de l'agent. Cela améliore la compréhension des tâches mais crée un chemin d'injection direct d'invites : un rapporteur externe ou un journal copié peut demander à l'agent de révéler des secrets, de récupérer une URL malveillante ou de modifier un code sans rapport. AGENTS.md fait plus autorité, mais c'est aussi le contenu du référentiel qu'une branche compromise peut modifier.
Marquez le contenu par provenance et niveau de confiance. La politique système, les règles d'organisation et la configuration approuvée du référentiel doivent primer sur les descriptions de tickets, les commentaires, les journaux, les pages Web et les chaînes de code. Ne laissez pas un contributeur non fiable déclencher une exécution avec des outils d'observabilité ou de données internes. Le projet actuel limite explicitement les outils facultatifs Datadog/LangSmith aux utilisateurs autorisés ; préserver et tester cette frontière.
Conservation des outils et informations d'identification
L'ensemble d'outils par défaut comprend l'exécution du shell, les opérations sur les fichiers, la récupération d'URL, les requêtes HTTP arbitraires, la recherche/commentaires Linear et les réactions/réponses Slack. Les opérations GitHub peuvent être proxy afin que le bac à sable voie un jeton factice pendant que le serveur exécute les requêtes autorisées. Les outils facultatifs Datadog, LangSmith et Corridor s'exécutent côté serveur, gardant ces informations d'identification hors du bac à sable.
| Groupe d'outils | Autorisation minimale | Utilisation abusive à haut risque |
|---|---|---|
| GitHub | Lire le code ; pousser une branche de tâches ; ouvrir/mettre à jour le brouillon de PR | Modification des protections, secrets, versions ou autres branches |
| Slack/Linear | Lisez le fil de discussion/le problème déclencheur et répondez-y | Recherche de discussions confidentielles ou de messages de masse |
| HTTP/récupération | Documentation publique autorisée lorsque cela est possible | SSRF, accès aux métadonnées, exfiltration et instructions sur les pages hostiles |
| Observabilité | Services en lecture seule, limités et utilisateurs autorisés | Fuite de données client ou de secrets intégrés dans les journaux/traces |
| Coquille | Contrôle total uniquement dans un bac à sable aux ressources limitées | Bombes à fourche, cryptomining, analyse de réseau ou persistance |
| Sous-agents | Autorité identique ou plus étroite que celle du parent | Multiplication des coûts, des conflits et des appels d'outils |
La validation est le plus grand écart par défaut
Le README décrit la validation comme étant pilotée par une invite : l'agent est invité à exécuter des linters, des formateurs et des tests avant de s'engager. Les instructions ne sont pas exécutoires. Un agent peut ignorer des tests coûteux, mal lire les résultats, affaiblir un test, se moquer d'un comportement ou revendiquer la réussite après un délai d'attente. Le projet lui-même recommande d’ajouter des CI déterministes, une vérification visuelle ou des portes d’examen.
Déplacez l’acceptation en dehors de la boucle du modèle. Le service ne doit pas marquer une tâche comme réussie tant que les commandes requises ne sont pas exécutées dans un nouvel environnement et n'ont pas renvoyé les résultats attendus lisibles par la machine. L'agent ne doit pas modifier le flux de travail qui détermine son propre état de réussite, sauf si cette modification du flux de travail est examinée séparément.
| Porte | Preuve indépendante | Politique d'échec |
|---|---|---|
| Portée | Chemins modifiés par rapport à la liste autorisée des problèmes | Bloquer la mise à jour des relations publiques ou demander une exception humaine |
| Construire/vérifier le type | Nouvelle commande de paiement et code de sortie | Joindre les journaux et marquer comme incomplet |
| Essais | Suites requises et examen des tests modifiés | Aucune boucle de nouvelle tentative qui modifie silencieusement les attentes |
| Sécurité | Scanners de dépendances, secrets et analyses statiques | Recherche de quarantaine ; ne jamais rejeter automatiquement |
| Visuel | Comparaison de captures d'écran sur des itinéraires/fenêtres définis | Approbation humaine pour des différences significatives |
| Possibilité de révision | Champs de taille de différence, de résumé, de risque et de restauration | Diviser les changements surdimensionnés ou mixtes |
Les threads persistants nécessitent des règles de cycle de vie
Les messages de suivi Slack/Linear sont acheminés vers le même thread déterministe et le même bac à sable persistant. Cela préserve le contexte, mais peut également préserver les états compromis, les branches obsolètes, les secrets téléchargés et les processus incontrôlables. Définissez la durée de vie maximale, le délai d'inactivité, le quota de disque et un chemin de « recréation à partir d'un modèle propre ». Un ticket rouvert des semaines plus tard ne devrait pas reprendre silencieusement un ancien environnement non corrigé.
Le middleware injecte les messages en file d'attente avant le prochain appel de modèle. Enregistrez quel message a modifié la tâche, qui l'a envoyé et si la portée s'est étendue. Si un suivi demande un nouveau référentiel, un nouveau système externe ou une action de production, créez une nouvelle décision d'autorisation au lieu de la traiter comme un contexte conversationnel ordinaire.
Sous-agents : parallélisme utile avec le coût non linéaire
Deep Agents peut générer des agents enfants avec leur propre middleware, listes de tâches et opérations sur les fichiers. Utilisez-les uniquement pour des travaux indépendants nécessitant beaucoup de lecture, tels que la localisation de tests, la comparaison de API ou l'examen d'une différence limitée. Plusieurs rédacteurs dans une même branche peuvent écraser les hypothèses et créer un changement plus important et moins cohérent.
- Définissez un nombre maximum d'enfants, une limite d'appels de modèles, un budget de jetons et une date limite d'horloge murale.
- Attribuez des fichiers qui ne se chevauchent pas ou demandez à un parent de sérialiser les modifications.
- Ne laissez pas les autorisations des enfants plus larges que celles du parent.
- Faites en sorte que chaque enfant renvoie des preuves et des incertitudes, et pas seulement des conclusions en prose.
- Imputez toutes les activités enfants à la tâche d'origine pour mesurer les coûts.
Choix de déploiement et de dépendances
Open SWE nécessite plus que l'installation d'un package Python : backend, tableau de bord, services LangGraph/LangSmith, GitHub App/OAuth, intégrations d'invocation, fournisseur de bac à sable, informations d'identification du modèle et hébergement de production. Le code est sous licence MIT, mais les sandbox cloud, les modèles, les plateformes d'observabilité et de messagerie ont des conditions de tarification et de données distinctes.
Épinglez le commit Open SWE et tous les verrous de dépendance. Stockez les secrets des applications dans un système de secrets gérés, alternez les secrets des webhooks, validez les signatures et rejetez les événements rejoués. Installations de développement et de production séparées. Un webhook public et un puissant GitHub App constituent une cible attrayante.
Sélection des tâches
| Tâche | Adéquation | Raison |
|---|---|---|
| Migration mécanique API | Bon pilote | Modèles clairs, fichiers délimités et tests déterministes |
| Ajouter des tests unitaires manquants | Bien avec avis | Recherche utile, mais les tests peuvent coder un mauvais comportement |
| Mise à jour des dépendances | Conditionnel | Nécessite un journal des modifications, un examen de la sécurité et de la compatibilité |
| Caractéristique du produit ambiguë | Mauvais ajustement initial | Les exigences et le jugement UX dominent le codage |
| Refonte de l'authentification | Risque élevé | L’architecture de sécurité nécessite une expertise responsable |
| Incident de production | Mauvaise adéquation autonome | La pression du temps et l’autorité en direct amplifient les erreurs |
Mesurer les travaux d'ingénierie acceptés
Suivez le taux d'acceptation des tâches, les minutes des réviseurs, la transmission CI lors de la première exécution indépendante, les défauts rouverts, les résultats de sécurité, les minutes sandbox, les jetons de modèle et le coût total par PR fusionné. Comparez avec une référence humaine avec une complexité de tâche similaire. Le nombre de PR et les lignes modifiées correspondent au volume de production, pas à la productivité.
Maintenez un groupe de contrôle sans agent et un groupe avec agent synchrone. Les agents asynchrones peuvent réduire les interruptions tout en augmentant les lots de révision. La question utile est de savoir si les délais de livraison et la qualité acceptée s'améliorent sans transférer la charge de travail cachée aux réviseurs et aux ingénieurs de la plateforme.
Alternatives
| Options | Meilleur ajustement | Compromis par rapport à Open SWE |
|---|---|---|
| Open SWE | Équipes créant une plateforme d'agent asynchrone interne personnalisable | Intégration, sécurité et propriété opérationnelle importantes |
| Codex / Claude Code | Travail de terminal synchrone supervisé par un développeur | Moins d’orchestration des flux de travail en arrière-plan |
| GitHub Copilot agent de codage | Flux de problème à PR géré natif sur GitHub | Moins de personnalisation au niveau du framework et un modèle d'hébergement différent |
| Devin | Espace de travail de codage autonome géré | Plateforme hébergée commerciale et moins de contrôle interne |
| OpenHands | Exécution et recherche d'un agent de codage open source | Objectif d'intégration et d'orchestration différent |
| Scripts/bots CI | Migrations déterministes, formatage et mises à jour | Raisonnement moins flexible, souvent plus sûr et moins cher pour des tâches connues |
Questions fréquemment posées
Open SWE est-il un service hébergé ?
Il s'agit d'un framework open source. Les opérateurs le déploient et le configurent et achètent ou exécutent les services de modèle, de bac à sable et d'intégration requis.
Quels bacs à sable sont pris en charge ?
Le référentiel actuel répertorie Modal, Daytona, Runloop, E2B et LangSmith, ainsi qu'un chemin de personnalisation.
Prend-il en charge Slack, Linear et GitHub ?
Oui. Il s’agit des principales surfaces d’invocation et de suivi documentées.
Un bac à sable sécurise-t-il les autorisations complètes ?
Non. Cela isole l’exécution locale, mais l’autorité du réseau, du référentiel et du compte externe nécessite des contrôles distincts.
Est-ce qu'il vérifie automatiquement le code ?
La valeur par défaut s'appuie fortement sur les instructions de l'agent pour exécuter les vérifications. Les équipes doivent ajouter des CI externes déterministes et des portes d'examen.
Est-ce open source ?
Oui. Le référentiel actuel est sous licence MIT.
Sources primaires
- Dépôt officiel et architecture
- Application officielle Open SWE
- Guide d'installation officiel
- Guide de personnalisation officiel
- Politique de sécurité officielle
- LangGraph aperçu
- GitHub App bonnes pratiques de sécurité
- Conseils d’injection rapide OWASP
Dernière révision le 25 juillet 2026. Open SWE évolue rapidement ; épinglez la révision déployée et revalidez les intégrations, le comportement du bac à sable, les outils et les contrôles de sécurité après les mises à niveau.
