OpenHands: Offene Plattform für KI-Softwareagenten und was sie für die Finanzautomatisierung bedeutet

Ich stoße immer wieder auf OpenHands als Gerüstschicht unter TheAgentCompany, InvestorBench und einer wachsenden Liste von Evaluierungspapieren – dennoch habe ich das primäre Paper bisher nicht gelesen. Dies ist die Infrastruktur, auf der der Rest des Feldes im Stillen aufbaut. Daher ist es wichtiger zu verstehen, was sie tatsächlich bietet und wo sie zu kurz greift, als jedes einzelne Benchmark-Ergebnis, das darauf aufbaut.

Das Paper

OpenHands (Wang et al., 2024; ICLR 2025) ist eine Open-Source-Plattform zur Erstellung und Evaluierung von LLM-Agenten, die als generalistische Softwareentwickler agieren. Unter der Leitung von Xingyao Wang und Graham Neubig sowie einem Team von 24 Autoren behauptet das Paper im Kern, dass die meisten bestehenden Agenten-Frameworks entweder zu forschungsspezifisch (fest codierte Aufgabenschleifen) oder zu produktionsspezifisch (Closed Source oder zweckgebunden) sind, um als gemeinsame Grundlage für die Forschungsgemeinschaft zu dienen. OpenHands versucht dies zu beheben, indem es eine standardisierte Laufzeitumgebung, eine saubere Agentenabstraktion und 15 integrierte Evaluierungsbenchmarks in einem MIT-lizenzierten Repository bereitstellt.

Die Laufzeitumgebung ist eine Docker-sandboxed Umgebung, die eine Bash-Shell, einen Jupyter IPython-Server und einen Playwright-gesteuerten Chromium-Browser enthält. Agenten interagieren über drei primäre Aktionstypen: IPythonRunCellAction für Python, CmdRunAction für Shell-Befehle und BrowserInteractiveAction für die Web-Navigation. Ein Primitiv zur Koordination mehrerer Agenten, AgentDelegateAction, ermöglicht es einem Hauptagenten, spezialisierte Sub-Agenten zu erzeugen. Das Standard-Backbone ist CodeAct – ursprünglich als eigenständiges Paper veröffentlicht, das argumentiert, dass Code der ideale vereinheitlichte Aktionsraum für LLM-Agenten ist – und die Plattform liefert mehrere Agenten-Implementierungen mit, darunter einen allgemeinen CodeActAgent und einen spezialisierten BrowsingAgent.

Kernideen

• Code als universeller Aktionsraum: CodeAct konsolidiert alle Agentenaktionen (Dateibearbeitungen, API-Aufrufe, Datentransformationen) in Python oder Bash, sodass das LLM in demselben Medium logisch argumentieren kann, in dem es am intensivsten trainiert wurde. Dies umgeht die Sprödigkeit von JSON-Schemata, die Agenten mit Funktionsaufrufen oft plagen.
• Sandboxed Docker-Laufzeitumgebung: Jeder Agent läuft in einem isolierten Container, sodass Agenten frei beliebigen Code ausführen können, ohne den Host-Rechner zu gefährden – eine Voraussetzung für jeden produktiven Finanzagenten, dem echte Zugangsdaten anvertraut werden könnten.
• 15 Benchmarks in einem System: SWE-Bench Lite (Code-Reparatur), HumanEvalFix (Fehlerbehebung), WebArena (Web-Navigation), GPQA (Argumentation auf Graduiertenniveau), GAIA (allgemeine Problemlösung) und zehn weitere. Die Zusammenführung dieser Benchmarks verhindert selektive Evaluierungen.
• CodeActAgent + claude-3.5-sonnet erreicht 26 % auf SWE-Bench Lite und 79,3 % auf HumanEvalFix; BrowsingAgent erreicht 15,5 % auf WebArena – wettbewerbsfähiges Zero-Shot ohne aufgabenspezifisches Training.
• GAIA-Performance: 32,1 % mit GPTSwarm, weit unter dem menschlichen Baseline-Wert von 92 % – konsistent mit jedem anderen allgemeinen Agenten-Benchmark, der eine Lücke von 60–70 Punkten zwischen Mensch und Agent zeigt.
• Community-Skalierung: 71,4k GitHub-Sterne und über 188 Mitwirkende zum Zeitpunkt der ICLR-Einreichung; TheAgentCompany hat OpenHands als Evaluierungssystem übernommen, was ihm de facto den Status einer Benchmark-Infrastruktur verleiht.

Was Bestand hat – und was nicht

Das Design der sandboxed Laufzeitumgebung ist solide Ingenieurskunst. Die Isolierung der Agenten-Ausführung in Docker ist der richtige Standard für jedes System, dem später Schreibzugriff auf echte Finanzhauptbücher gewährt werden könnte. Es ist zudem wirklich nützlich, dass die Benchmarks zusammengeführt sind, anstatt über inkompatible Repositories verstreut zu sein.

Die Abdeckung der Benchmarks ist jedoch eher aspirativ als systematisch. Die 15 Benchmarks umfassen extrem unterschiedliche Aufgabentypen und Schwierigkeitsgrade, ohne ein klares Framework dafür, wie Ergebnisse aggregiert oder verglichen werden sollten. Die Angabe von 26 % auf SWE-Bench Lite neben 79,3 % auf HumanEvalFix im selben Paper riskiert den Eindruck, dass derselbe Agent gleichzeitig mittelmäßig und exzellent ist – die Aufgaben sind schlicht nicht vergleichbar. Die Autoren bieten keine fundierte Methodik zur Aggregation über mehrere Benchmarks hinweg an.

Die CodeAct-Annahme – dass Code das richtige universelle Aktionsformat sei – ist umstritten. Sie funktioniert gut für Entwicklungsaufgaben, erzwingt aber eine Python/Bash-Vermittlungsschicht für jede Aktion. Dies erhöht die Latenz und führt zu Problemen, wenn die Aktionssemantik nicht sauber auf Code abgebildet werden kann (mehrdeutige Benutzeranweisungen, reine Natural-Language-APIs). Das Paper führt keine Benchmarks gegen Nicht-Code-Aktionsräume durch, um zu beweisen, dass der Vorteil real ist und nicht nur auf dem LLM-Backbone basiert.

Die wichtigste Lücke ist vielleicht die Kluft zwischen Evaluierung und Einsatz. Der Wert von 26 % bei SWE-Bench stammt aus einem relativ sauberen, gut spezifizierten Benchmark. Community-Berichte und GitHub-Issue-Threads beschreiben konsistent eine viel geringere Zuverlässigkeit bei mehrdeutigen oder langfristigen Aufgaben in der realen Welt – derselbe Fehlermodus, den TheAgentCompany dokumentiert hat. Das Paper befasst sich nicht damit, wie Robustheit unter realistischen Bedingungen mit ungenauen Aufgabenspezifikationen gemessen oder verbessert werden kann.

Warum dies für Finanz-KI wichtig ist

OpenHands kommt einem gemeinsamen Agenten-Substrat in der Community am nächsten. Wenn Bean Labs eine Evaluierungsinfrastruktur für Beancount-Agenten aufbaut, ist die Laufzeitarchitektur hier – Docker-Sandbox, Python/Bash-Aktionen, austauschbare LLM-Backends – eine Übernahme wert, anstatt sie neu zu bauen. Das AgentDelegateAction-Primitiv lässt sich natürlich auf eine Finanzagenten-Pipeline übertragen, bei der ein Orchestrator auf oberster Ebene an spezialisierte Sub-Agenten delegiert: einer für das Lesen des Hauptbuchs, einer für die Kennzeichnung von Anomalien, einer für einen vorgeschlagenen Rückschreibvorgang, den ein Mensch prüft.

Die Zahlen von SWE-Bench und TheAgentCompany etablieren zusammen eine ernüchternde Ausgangslage: Selbst die besten verfügbaren Agenten erledigen etwa 26–30 % der realistischen, eindeutigen Softwareaufgaben. Die Automatisierung von Finanzbüchern ist schwieriger – Transaktionen sind oft mehrdeutig, die Auswirkungen von Fehlern sind real und die Absichten der Benutzer sind häufig unterdefiniert. Die richtige Schlussfolgerung ist nicht, dass Agenten nicht bereit sind, sondern dass die ersten produktiven Einsätze eng gefasste Write-Once-Workflows (Kategorisierungsvorschläge, Kennzeichnung von Abstimmungen) sein werden, anstatt autonomer mehrstufiger Bearbeitungen des Hauptbuchs.

Was man als Nächstes lesen sollte

• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — paart ein günstiges Modell mit einem teuren und delegiert nur dann an das teure Modell, wenn die Unsicherheit hoch ist; befasst sich direkt damit, wie ein Agent im OpenHands-Stil entscheiden sollte, wann er eine Beancount-Rückbuchung zur menschlichen Überprüfung eskaliert.
• FinTrace: Holistic Trajectory-Level Evaluation of LLM Tool Calling for Long-Horizon Financial Tasks (arXiv:2604.10015) — 800 von Experten annotierte Aufgabensequenzen in 34 Finanzszenarien; die Evaluierungsmethodik für finanzspezifische, langfristige Tool-Nutzung, die OpenHands fehlt.
• FinMCP-Bench: Benchmarking LLM Agents for Real-World Financial Tool Use under the Model Context Protocol (arXiv:2603.24943) — 613 Proben aus 65 echten MCP-Finanzwerkzeugen, direkt relevant dafür, wie ein auf der OpenHands-Laufzeit basierender Beancount-Agent in einem realen MCP-Einsatz evaluiert würde.