Open SWE ist ein Open-Source-Framework zum Aufbau des internen asynchronen Coding-Agenten einer Organisation. Ein Entwickler kann einen Bot in Slack, Linear oder GitHub erwähnen; Der Dienst stellt Issue-/Thread-Kontext zusammen, erstellt eine persistente Cloud-Sandbox, klont ein Repository, plant und bearbeitet Code, führt Befehle aus, führt einen Commit für einen Zweig durch und öffnet oder aktualisiert einen Pull-Request-Entwurf.
Es handelt sich nicht um einen gehosteten Codierungsdienst, der nach der Installation sicher wird. Open SWE ist eine Referenzarchitektur, die auf LangGraph und Deep Agents basiert. Der Betreiber muss Modelle und Sandbox-Anbieter auswählen, GitHub/Slack/Linear-Anwendungen erstellen, die Bereitstellung sichern, Repositorys und Tokens festlegen, deterministische Validierung hinzufügen, den Netzwerkzugriff steuern und alle resultierenden Pull-Anfragen besitzen.
Die End-to-End-Architektur
| Schicht | Veröffentlichte Rolle | Die Entscheidung liegt beim Betreiber |
|---|---|---|
| Anrufung | Slack Erwähnung, Linear Kommentar oder GitHub PR-Kommentar | Wer kann welche Repositories zu welchem Preis auslösen? |
| Kontext | AGENTS.md plus vollständiger Issue- oder Thread-Verlauf | Welche Inhalte sind vertrauenswürdig, geschwärzt oder anfällig für Prompt-Injection? |
| Geschirr | Deep Agents komponiert in LangGraph | Modell, Systemaufforderung, Tools, Middleware und Aufrufgrenzen |
| Sandkasten | Persistente Remote-Linux-Umgebung pro Aufgabe | Anbieter, Image, Ausgang, Lebensdauer, Ressourcen und Datenspeicherort |
| Werkzeuge | Shell, Dateien, HTTP, Slack, Linear, GitHub und optionale Beobachtbarkeit | Geringste Privilegien, Nebenwirkungsgenehmigungen und geheime Grenzen |
| Orchestrierung | Subagenten und deterministische Middleware-Hooks | Parallelität, Budget, gemeinsamer Status und Fehlerbehandlung |
| Lieferung | Commit, Push, PR-Entwurf und Quellkanal-Antwort | CI, Prüfer, Zusammenführungsrichtlinie und Bereitstellungstrennung |
Sandboxing reduziert das Host-Risiko, nicht das Risiko externer Autorität
Das Repository besagt, dass jede Aufgabe eine isolierte Cloud-Sandbox mit vollständigen Shell-Berechtigungen und ohne Bestätigungsaufforderungen erhält und die Sandboxen Modal, Daytona, Runloop, E2B und LangSmith unterstützt. Eine separate Sandbox begrenzt Dateisystem- und Prozesskonflikte, aber der Satz in der README-Datei, dass der Explosionsradius „vollständig eingedämmt“ sei, sollte nicht wörtlich genommen werden.
Der Agent kann über Netzwerkausgang, Repository-Berechtigung, Zugriff auf die Paketregistrierung und externe APIs verfügen. Es kann die Quelle exfiltrieren, Modell-Credits vernichten, schädliche Pull-Requests öffnen, einen Token missbrauchen oder interne Dienste angreifen, die über die Sandbox erreichbar sind. Eine Kompromittierung der Steuerungsebene des Sandbox-Anbieters kann auch Aufgabengrenzen überschreiten. Die Eindämmung erfordert Ausgangsrichtlinien, kurzlebige Anmeldeinformationen, Kontingente, Anbieterisolation und ein unabhängiges Merge/Deploy-Gate.
| Risiko | Sandbox hilft | Erforderliche Begleitsteuerung |
|---|---|---|
| Zerstörerischer Shell-Befehl | Begrenzt lokale Festplatten-/Prozessschäden auf die verfügbare Umgebung | Keine Produktionshalterungen; Ressourcen-/Zeitlimits und sauberer Abbau |
| Böswillige Abhängigkeit | Trennt die Aufgabe vom Entwickler-Laptop | Sperrdateien, Zulassungsliste für die Registrierung, Scannen und eingeschränkter Ausgang |
| GitHub-Token-Missbrauch | Wenig, wenn das Token externe Aktionen zulässt | Proxy-/bereichsbezogenes App-Token, beschränkt auf Repo- und Branch-Vorgänge |
| Schnelle Injektion | Kann Host-Kompromisse einschränken | Vertrauenskennzeichnungen, Tool-Richtlinien und Ablehnung sensibler Systeme |
| Schlechter Code | Ermöglicht Tests in einer isolierten Laufzeit | Deterministisches CI, Sicherheitsüberprüfung und geschützte Zweige |
| Datenleck | Trennt lokale Workstation-Daten | Anbieter-/Datenüberprüfung, Schwärzung und ausgehende Zielkontrollen |
Problem- und Chattext sind nicht vertrauenswürdige Anweisungen
Open SWE fügt das vollständige Linear-Problem oder den Slack-Thread in den Agentenkontext ein. Das verbessert das Aufgabenverständnis, schafft aber einen direkten Weg zur Eingabeaufforderung: Ein externer Reporter oder ein kopiertes Protokoll kann den Agenten anweisen, Geheimnisse preiszugeben, eine schädliche URL abzurufen oder nicht verwandten Code zu ändern. AGENTS.md ist maßgeblicher, es handelt sich jedoch auch um Repository-Inhalte, die ein gefährdeter Zweig ändern kann.
Markieren Sie Inhalte nach Herkunft und Vertrauensstufe. Systemrichtlinien, Organisationsregeln und genehmigte Repository-Konfiguration sollten Vorrang vor Ticketbeschreibungen, Kommentaren, Protokollen, Webseiten und Codezeichenfolgen haben. Lassen Sie nicht zu, dass ein nicht vertrauenswürdiger Mitwirkender einen Lauf mit Observability- oder internen Datentools auslöst. Das aktuelle Projekt beschränkt optionale Datadog/LangSmith-Tools explizit auf autorisierte Benutzer; Bewahren und testen Sie diese Grenze.
Tool-Kuratierung und Referenzen
Der Standard-Toolset umfasst Shell-Ausführung, Dateioperationen, URL-Abruf, beliebige HTTP-Anfragen, Linear Suche/Kommentare und Slack Reaktionen/Antworten. GitHub-Vorgänge können per Proxy ausgeführt werden, sodass die Sandbox ein Dummy-Token sieht, während der Server autorisierte Anfragen ausführt. Die optionalen Tools Datadog, LangSmith und Corridor werden serverseitig ausgeführt, sodass diese Anmeldeinformationen nicht in der Sandbox gespeichert werden.
| Werkzeuggruppe | Mindesterlaubnis | Missbrauch mit hohem Risiko |
|---|---|---|
| GitHub | Code lesen; einen Aufgabenzweig pushen; PR-Entwurf öffnen/aktualisieren | Ändern von Schutzmaßnahmen, Geheimnissen, Freigaben oder anderen Zweigen |
| Slack/Linear | Lesen Sie den auslösenden Thread/das auslösende Problem und antworten Sie dort | Suche nach vertraulichen Diskussionen oder Massennachrichten |
| HTTP/Abruf | Öffentliche Dokumentation nach Möglichkeit auf die Zulassungsliste setzen | SSRF, Metadatenzugriff, Exfiltration und Anweisungen für feindliche Seiten |
| Beobachtbarkeit | Schreibgeschützte, bereichsbezogene Dienste und autorisierte Benutzer | Offenlegung von Kundendaten oder in Protokollen/Spuren eingebetteten Geheimnissen |
| Muschel | Vollständige Kontrolle nur innerhalb der ressourcenbeschränkten Sandbox | Fork-Bomben, Kryptomining, Netzwerk-Scanning oder Persistenz |
| Subagenten | Gleiche oder engere Autorität als das übergeordnete Element | Kosten, Konflikte und Werkzeugabrufe vervielfachen sich |
Die Validierung ist die größte Standardlücke
In der README-Datei wird die Validierung als aufforderungsgesteuert beschrieben: Der Agent wird angewiesen, vor dem Festschreiben Linters, Formatter und Tests auszuführen. Weisungen stellen keine Durchsetzung dar. Ein Agent kann teure Tests überspringen, die Ausgabe falsch interpretieren, einen Test abschwächen, Verhalten verfälschen oder nach einer Zeitüberschreitung Erfolg versprechen. Das Projekt selbst empfiehlt die Hinzufügung von deterministischem CI, visueller Verifizierung oder Review-Gates.
Akzeptanz außerhalb der Modellschleife verschieben. Der Dienst sollte eine Aufgabe erst dann als erfolgreich markieren, wenn erforderliche Befehle in einer neuen Umgebung ausgeführt werden und erwartete maschinenlesbare Ergebnisse zurückgeben. Der Agent darf den Workflow, der seinen eigenen Erfolgsstatus bestimmt, nicht bearbeiten, es sei denn, diese Workflow-Änderung wird separat überprüft.
| Tor | Unabhängige Beweise | Fehlerpolitik |
|---|---|---|
| Umfang | Geänderte Pfade im Vergleich zur Issue-Zulassungsliste | Blockieren Sie die PR-Aktualisierung oder fordern Sie eine menschliche Ausnahme an |
| Build/Typprüfung | Neuer Checkout-Befehl und Exit-Code | Protokolle anhängen und als unvollständig markieren |
| Tests | Erforderliche Suiten plus geänderte Testbewertung | Keine Wiederholungsschleife, die die Erwartungen stillschweigend ändert |
| Sicherheit | Abhängigkeits-, Geheim- und statische Analysescanner | Quarantänebefund; niemals automatisch schließen |
| Visuell | Screenshot-Vergleich an definierten Routen/Ansichtsfenstern | Menschliche Zustimmung für sinnvolle Unterschiede |
| Überprüfbarkeit | Unterschiedliche Größen-, Zusammenfassungs-, Risiko- und Rollback-Felder | Teilen Sie übergroße oder gemischte Änderungen auf |
Persistente Threads benötigen Lebenszyklusregeln
Folgenachrichten vom Typ Slack/Linear werden an denselben deterministischen Thread und dieselbe persistente Sandbox weitergeleitet. Dadurch bleibt der Kontext erhalten, es können aber auch kompromittierte Zustände, veraltete Zweige, heruntergeladene Geheimnisse und außer Kontrolle geratene Prozesse erhalten bleiben. Definieren Sie die maximale Lebensdauer, das Leerlauf-Timeout, das Festplattenkontingent und einen Pfad zum „Neuerstellen aus einer sauberen Vorlage“. Ein nach Wochen wieder geöffnetes Ticket sollte nicht stillschweigend eine alte, nicht gepatchte Umgebung wiederherstellen.
Middleware fügt vor dem nächsten Modellaufruf Nachrichten in die Warteschlange ein. Notieren Sie, welche Nachricht die Aufgabe geändert hat, wer sie gesendet hat und ob der Umfang erweitert wurde. Wenn eine Folgeaktion ein neues Repository, ein neues externes System oder eine neue Produktionsaktion anfordert, erstellen Sie eine neue Autorisierungsentscheidung, anstatt sie als gewöhnlichen Konversationskontext zu behandeln.
Subagenten: nützliche Parallelität mit nichtlinearen Kosten
Deep Agents kann untergeordnete Agenten mit eigener Middleware, Aufgabenlisten und Dateioperationen erzeugen. Verwenden Sie sie nur für unabhängige, leseintensive Arbeiten wie das Auffinden von Tests, den Vergleich von APIs oder die Überprüfung eines begrenzten Diffs. Mehrere Autoren in einem Zweig können Annahmen überschreiben und eine größere, weniger kohärente Änderung bewirken.
- Legen Sie eine maximale Anzahl von Kindern, ein Limit für Modelaufrufe, ein Token-Budget und eine Deadline fest.
- Weisen Sie nicht überlappende Dateien zu oder verlangen Sie, dass ein übergeordnetes Element die Änderungen serialisiert.
- Halten Sie die Berechtigungen des Kindes nicht umfassender als die des Elternteils.
- Lassen Sie jedes Kind Beweise und Unsicherheit zurückgeben, nicht nur prosaische Schlussfolgerungen.
- Ordnen Sie zur Kostenmessung alle untergeordneten Aktivitäten der ursprünglichen Aufgabe zu.
Bereitstellungs- und Abhängigkeitsoptionen
Open SWE erfordert mehr als die Installation eines Python-Pakets: Backend, Dashboard, LangGraph/LangSmith-Dienste, GitHub App/OAuth, Aufrufintegrationen, Sandbox-Anbieter, Modellanmeldeinformationen und Produktionshosting. Der Code ist MIT-lizenziert, aber für Cloud-Sandboxen, Modelle, Observability- und Messaging-Plattformen gelten separate Preis- und Datenbedingungen.
Fixieren Sie das Open SWE-Commit und alle Abhängigkeitssperren. Speichern Sie Anwendungsgeheimnisse in einem verwalteten Geheimsystem, rotieren Sie Webhook-Geheimnisse, validieren Sie Signaturen und lehnen Sie wiederholte Ereignisse ab. Getrennte Entwicklungs- und Produktionsanlagen. Ein öffentlicher Webhook und ein leistungsstarker GitHub App sind ein attraktives Ziel.
Aufgabenauswahl
| Aufgabe | Eignung | Grund |
|---|---|---|
| Mechanische API Migration | Guter Pilot | Klare Muster, begrenzte Dateien und deterministische Tests |
| Fehlende Unit-Tests hinzufügen | Gut mit Rezension | Nützliche Forschung, aber Tests können falsches Verhalten verschlüsseln |
| Abhängigkeitsaktualisierung | Bedingt | Änderungsprotokoll, Sicherheits- und Kompatibilitätsprüfung erforderlich |
| Unklare Produktfunktion | Schlechte anfängliche Passform | Anforderungen und UX-Urteil dominieren die Codierung |
| Neugestaltung der Authentifizierung | Hohes Risiko | Sicherheitsarchitektur erfordert verantwortungsvolles Fachwissen |
| Produktionsvorfall | Schlechte autonome Passform | Zeitdruck und lebende Autorität verstärken Fehler |
Abgenommene Ingenieurarbeiten messen
Verfolgen Sie die Aufgabenannahmerate, Prüferminuten, CI-Übergabe beim ersten unabhängigen Lauf, erneut geöffnete Fehler, Sicherheitsbefunde, Sandbox-Minuten, Modell-Tokens und Gesamtkosten pro zusammengeführtem PR. Vergleichen Sie es mit einer menschlichen Basislinie bei ähnlicher Aufgabenkomplexität. PR-Anzahl und geänderte Zeilen sind Ausgabevolumen, nicht Produktivität.
Pflegen Sie eine Kontrollgruppe ohne Agenten und eine Gruppe mit synchronen Agenten. Asynchrone Agenten können Unterbrechungen reduzieren und gleichzeitig die Überprüfungsstapel erhöhen. Die nützliche Frage ist, ob sich die Durchlaufzeit und die akzeptierte Qualität verbessern, ohne dass versteckte Arbeitslasten auf Prüfer und Plattformingenieure übertragen werden.
Alternativen
| Option | Beste Passform | Kompromiss versus Open SWE |
|---|---|---|
| Open SWE | Teams bauen eine anpassbare interne Async-Agent-Plattform auf | Erhebliche Integration, Sicherheit und betriebliche Eigenverantwortung |
| Codex / Claude Code | Synchrone, vom Entwickler überwachte Terminalarbeit | Weniger Hintergrund-Workflow-Orchestrierung |
| GitHub Copilot Codierungsagent | GitHub-nativ verwalteter Issue-to-PR-Flow | Weniger Anpassungen auf Framework-Ebene und anderes Hosting-Modell |
| Devin | Verwalteter autonomer Codierungsarbeitsbereich | Kommerziell gehostete Plattform und weniger interne Kontrolle |
| OpenHands | Open-Source-Coding-Agent-Laufzeit und -Forschung | Unterschiedlicher Integrations- und Orchestrierungsschwerpunkt |
| CI-Skripte/Bots | Deterministische Migrationen, Formatierungen und Updates | Weniger flexibles Denken, bei bekannten Aufgaben oft sicherer und kostengünstiger |
Häufig gestellte Fragen
Ist Open SWE ein gehosteter Dienst?
Es handelt sich um ein Open-Source-Framework. Betreiber stellen es bereit und konfigurieren es und erwerben oder betreiben die erforderlichen Modell-, Sandbox- und Integrationsdienste.
Welche Sandboxes werden unterstützt?
Das aktuelle Repository listet Modal, Daytona, Runloop, E2B und LangSmith sowie einen Anpassungspfad auf.
Unterstützt es Slack, Linear und GitHub?
Ja. Dies sind die primär dokumentierten Aufruf- und Folgeoberflächen.
Macht eine Sandbox vollständige Berechtigungen sicher?
Nein. Es isoliert die lokale Ausführung, aber Netzwerk-, Repository- und externe Kontoautorität erfordern separate Kontrollen.
Verifiziert es den Code automatisch?
Die Standardeinstellung stützt sich bei der Durchführung von Prüfungen stark auf die Anweisungen des Agenten. Teams sollten deterministische externe CI- und Review-Gates hinzufügen.
Ist es Open Source?
Ja. Das aktuelle Repository ist unter MIT lizenziert.
Primärquellen
- Offizielles Repository und Architektur
- Offizielle Open SWE-Anwendung
- Offizielle Installationsanleitung
- Offizieller Anpassungsleitfaden
- Offizielle Sicherheitsrichtlinie
- LangGraph Übersicht
- GitHub App Best Practices für die Sicherheit
- OWASP-Anleitung zur sofortigen Injektion
Zuletzt überprüft am 25. Juli 2026. Open SWE entwickelt sich schnell; Fixieren Sie die bereitgestellte Revision und validieren Sie Integrationen, Sandbox-Verhalten, Tools und Sicherheitskontrollen nach Upgrades erneut.
