{ "version": 1, "type": "tool", "canonicalUrl": "https://tools.utildesk.de/tools/swe-agent/", "markdownUrl": "https://tools.utildesk.de/markdown/tools/swe-agent.md", "data": { "slug": "swe-agent", "title": "SWE-agent", "url": "https://tools.utildesk.de/tools/swe-agent/", "category": "Entwickler-Tools", "priceModel": "Open Source", "tags": [ "ai", "coding-agent", "research", "developer-tools" ], "description": "Open-Source-Forschungsagent für reproduzierbare Repository-Aufgaben und SWE-bench-Experimente; inzwischen durch mini-SWE-agent abgelöst und nur noch im Wartungsmodus.", "officialUrl": "https://github.com/SWE-agent/SWE-agent", "affiliateUrl": null, "inLanguage": "de-DE", "tier": "C", "editorialStatus": "curated", "featureList": [ "OpenHands: Aktivere Open-Source-Plattform für agentische Entwicklungsaufgaben mit breiterem Produkt- und Integrationsfokus.", "Devin: Verwalteter Cloud-Agent für Teams, die Infrastruktur, Sitzungen und Support nicht selbst aus Forschungsbausteinen zusammensetzen wollen.", "Aider: Schlankere Terminalalternative für dialoggeführte Git-Änderungen ohne vollständigen Benchmark- und Trajektorienapparat.", "Cline: IDE-naher Open-Source-Agent mit sichtbaren Toolaktionen für interaktive Entwicklungsarbeit." ], "wordCount": 946, "contentMarkdown": "# SWE-agent\r\n\r\nSWE-agent ist ein quelloffenes Forschungsframework, das Sprachmodelle mit Werkzeugen und einer isolierbaren Repository-Umgebung verbindet, um Issues zu untersuchen und Patches zu erzeugen. Es eignet sich für reproduzierbare Experimente und spezialisierte Agenten-Workflows, ist aber keine aktuelle Standardempfehlung für neue Installationen: Die Maintainer haben mini-SWE-agent als Nachfolger benannt und SWE-agent in den Maintenance-only-Modus versetzt.\r\n\r\n## Was ist SWE-agent und für wen?\r\n\r\nDas Projekt entstand im Umfeld von Princeton und Stanford und ist eng mit SWE-bench verbunden. Forschende können damit Agentenverhalten, Modelle, Prompts, Toolsets und Umgebungen vergleichen. Engineering-Teams können einzelne Issues oder kontrollierte Batches ausführen, wenn sie bereit sind, Konfiguration, Container, Modellzugang und Auswertung selbst zu betreiben.\r\n\r\nSWE-agent nimmt eine Problemstellung und ein Repository entgegen, lässt das Modell innerhalb einer Werkzeugschleife analysieren und bearbeiten und erzeugt am Ende einen Patch samt detaillierter Trajektorie. Das Ergebnis ist ein Kandidat, keine automatisch gültige Fehlerbehebung.\r\n\r\n## Welche Komponenten bilden den Agentenlauf?\r\n\r\nDer CLI-Einstieg initialisiert eine Umgebung über SWE-ReX und einen konfigurierbaren Agenten. Die Umgebung kann einen lokalen Docker-Container oder ein entferntes Deployment starten. In der Shell stehen Tool-Bundles für Dateiansicht, Suche, Bearbeitung und Bash zur Verfügung. Eine YAML-Konfiguration definiert Modell, Prompts, Parser, Werkzeuge, History-Verarbeitung und Umgebungsaufbau.\r\n\r\n
\r\n \"Isoliertes\r\n
\r\n\r\nDie Historie aus Modellantworten, Aktionen und Beobachtungen wird verarbeitet und wieder als Kontext genutzt. Damit lässt sich ein Lauf nachvollziehen, zugleich wachsen Kontextverbrauch und Datenmenge mit jeder Iteration.\r\n\r\n## Praktischer Workflow für einen kontrollierten Lauf\r\n\r\n1. Ein Issue mit reproduzierbarem Fehler, Zielverhalten und ausführbarem Test wählen; große Produktanforderungen zuerst zerlegen.\r\n2. Repository und Abhängigkeiten in einem unveränderlichen Containerimage vorbereiten. Nur notwendige Netzwerk- und Secret-Zugriffe freigeben.\r\n3. Modell und YAML-Konfiguration versionieren, Kosten- und Schrittgrenzen definieren und einen einzelnen Lauf starten.\r\n4. Trajektorie, Log, Konfiguration und Patch gemeinsam prüfen. Der Agent darf Tests nicht einfach entfernen oder eine Reproduktion durch eine Scheinlösung ersetzen.\r\n5. Den Patch außerhalb des Agentencontainers auf sauberem Checkout bauen und testen. Erst nach menschlichem Review darf daraus ein normaler Pull Request werden.\r\n\r\nBatchläufe sollten erst beginnen, wenn ein einzelner Fall reproduzierbar funktioniert. Sonst multiplizieren sie Setupfehler, Kosten und schwer vergleichbare Ergebnisse.\r\n\r\n## Betrieb, Konfiguration und Outputs\r\n\r\nDer Befehl `sweagent run` bearbeitet einen Fall, `run-batch` mehrere Instanzen. Das Trajektorienverzeichnis enthält JSON-basierte `.traj`-Dateien, die verwendete Konfiguration und Logs; Batchläufe ergänzen zusammengeführte Vorhersagen und Exit-Status. Inspektoren für Terminal und Browser helfen beim Vergleich der Schritte.\r\n\r\nWichtig ist die Trennung von Ausführung und Bewertung. `run-batch` führt keine vollständige SWE-bench-Evaluation aus; diese ist ein eigener Schritt. Reproduzierbarkeit verlangt neben dem Patch das Containerimage, die exakte Modellbezeichnung, Konfiguration und alle Setupbefehle. Da das Projekt nur noch gewartet wird, sollten neue Anpassungen gegen mini-SWE-agent geprüft werden, bevor weitere eigene Tool-Bundles entstehen.\r\n\r\n## Qualität, Evaluation und Entscheidungsgrenzen\r\n\r\nEin Lauf ist nicht erfolgreich, nur weil er einen Diff ausgibt. Reproduziert der Ausgangstest den Fehler? Behebt der Patch diesen Test und bestehen unveränderte Regressionstests? Sind neue Tests sinnvoll und hat der Agent keine Sicherheits- oder Lizenzgrenze übergangen? Für Forschung kommen Erfolgsquote, Token- und Laufzeitkosten, Varianz über Wiederholungen und Vergleichbarkeit der Umgebung hinzu.\r\n\r\nBenchmarkwerte lassen sich nicht ohne Weiteres auf interne Repositories übertragen. Andere Sprachen, Buildsysteme, private Abhängigkeiten und unvollständige Issues verändern die Aufgabe. Für produktive Nutzung ist ein kleiner eigener Evaluationssatz aussagekräftiger als eine fremde Rangliste.\r\n\r\n## Sicherheit, Datenschutz und Governance\r\n\r\nContainer reduzieren den Zugriff auf den Host, sind aber nur so sicher wie Mounts, Netzwerk, Laufzeit und bereitgestellte Rechte. Agenten können Bash ausführen; unbekannte Repositories und Issue-Inhalte sind daher als potenziell feindlich zu behandeln. Tokens für GitHub oder Modellanbieter sollten kurzlebig, minimal berechtigt und ausschließlich als Secrets beziehungsweise Umgebungsvariablen eingebunden werden.\r\n\r\nTrajektorien können Prompts, Modellantworten, Dateiinhalte und Kommandoausgaben enthalten. Sie dürfen nicht unbesehen veröffentlicht oder als Benchmarkartefakt geteilt werden. Aufbewahrung, Zugriff und Löschung der Logs müssen genauso geregelt sein wie beim Quellcode. Das Framework steht unter MIT-Lizenz; Repository-Abhängigkeiten, Modelle und erzeugte Patches können andere Bedingungen haben.\r\n\r\n## Kosten und Betriebsaufwand\r\n\r\nSWE-agent selbst ist Open Source. Bezahlt werden Modellaufrufe, Container- oder Remote-Compute, Artefaktspeicher und die menschliche Prüfung. Batchläufe und Wiederholungen können die Modellkosten schnell vervielfachen, insbesondere wenn lange Trajektorien immer wieder in den Kontext eingehen.\r\n\r\nTeams sollten ein hartes Budget pro Instanz, Timeouts und Abbruchgründe festlegen. Wartung eigener Images, Tool-Bundles und Modelladapter bleibt ein interner Kostenblock. Für neue Projekte kann mini-SWE-agent aufgrund des kleineren Frameworks weniger Betriebsballast verursachen.\r\n\r\n## Redaktionelle Einschätzung\r\n\r\nSWE-agent empfehlen wir Forschenden und erfahrenen Agenten-Teams, die bestehende Experimente reproduzieren, historische Konfigurationen pflegen oder die detaillierte ACI-Architektur untersuchen wollen. Wert entsteht, wenn Trajektorien, Container und Evaluation bewusst Teil des Versuchsdesigns sind.\r\n\r\nFür einen neuen produktiven Coding-Agenten ist der von den Maintainers empfohlene Nachfolger oder eine aktiv betriebene Plattform meist sinnvoller. Kleine Entwicklerteams ohne eigene Evaluation und Container-Governance sollten keinen Maintenance-only-Forschungsstack zum Kern ihres Lieferprozesses machen.\r\n\r\n## Alternativen\r\n\r\n- [OpenHands](/tools/openhands/): Aktivere Open-Source-Plattform für agentische Entwicklungsaufgaben mit breiterem Produkt- und Integrationsfokus.\r\n- [Devin](/tools/devin/): Verwalteter Cloud-Agent für Teams, die Infrastruktur, Sitzungen und Support nicht selbst aus Forschungsbausteinen zusammensetzen wollen.\r\n- [Aider](/tools/aider/): Schlankere Terminalalternative für dialoggeführte Git-Änderungen ohne vollständigen Benchmark- und Trajektorienapparat.\r\n- [Cline](/tools/cline/): IDE-naher Open-Source-Agent mit sichtbaren Toolaktionen für interaktive Entwicklungsarbeit.\r\n\r\n## FAQ\r\n\r\n**Ist SWE-agent noch aktiv weiterentwickelt?**\r\n\r\nEs befindet sich laut offizieller Dokumentation im Maintenance-only-Modus. Die Maintainer konzentrieren sich auf mini-SWE-agent und empfehlen diesen Nachfolger für neue Einsätze.\r\n\r\n**Erzeugt ein Lauf automatisch einen fertigen Pull Request?**\r\n\r\nDer Kernoutput ist ein Patch mit Trajektorie und Logs. Ob daraus ein Pull Request wird, sollte ein separater kontrollierter Prozess nach Tests, Diff-Prüfung und Berechtigungsprüfung entscheiden.\r\n\r\n**Reicht Docker als Sicherheitsmaßnahme?**\r\n\r\nNein. Mounts, Netzwerk, Containerprivilegien, Secrets und Host-Laufzeit bestimmen die tatsächliche Isolation. Nutze kurzlebige Umgebungen, minimale Rechte und behandle Repository sowie Issue-Text als nicht vertrauenswürdig.\r\n\r\n**Kann man SWE-bench-Ergebnisse auf das eigene Team übertragen?**\r\n\r\nNur sehr begrenzt. Interne Repositories unterscheiden sich bei Sprache, Abhängigkeiten, Tests und Aufgabenqualität. Ein eigener kleiner Evaluationssatz mit Kosten-, Qualitäts- und Varianzmessung ist die bessere Entscheidungsgrundlage.\n" } }