OpenHands: Vom Werkzeug-Stack zur Agent-Plattform auf Cloud Mac

In den letzten zwei Wochen haben wir im Stack-Serial L1 Runner (Fact), L2 Ollama (Inference) und L4 MCP (Context) Schicht für Schicht etabliert. Ein Satz kommt in fast jedem Feedback zurück: „Alle Tools hängen — aber ich verkette den Ablauf noch von Hand.“ Claude Code liefert Diff, MCP holt GitHub-Kontext, der Runner wird nach dem Push grün — und trotzdem sitzt jemand 40 Minuten am Terminal, bis „Issue #142 fixen und PR öffnen“ erledigt ist.

Genau das beantwortet L5 · OpenHands: nicht noch ein CLI kaufen, sondern Cloud Mac von einem Werkzeug-Stack zu einer Plattform hochstufen, die mehrstufige Engineering-Tasks autonom durchläuft. Dieser Text ist L5-Q01 · R1 · Serien-Hub: Er führt von „Coding-Tool“ zu „Agent-Plattform“ — Workflow-Position im Stack, warum OpenHands vs Claude Code keine Ersatzfrage ist, typische Tasks und OpenHands self-hosted auf macOS. Keine Docker-Installation (das ist L5-Q02).

Die Werkzeug-Stack-Falle: jedes Tool gut, die Kette noch manuell

Ein typischer Wochenablauf (den wir in Kunden-Repos mehrfach gesehen haben):

1. Montag: Claude Code ändert die API-Schicht, MCP zieht die Issue-Liste — in der Session alles glatt.
2. Dienstag: Kollege pusht von anderem Rechner, Runner rot — niemand hat Agent-Änderungen mit CI-Skripten abgeglichen (ohne L1 Execution Engine wiederholt sich das).
3. Mittwoch: Tests von Hand, Config anpassen, neue Claude-Code-Session für fehlende Dateien.
4. Donnerstag: endlich grün — aber Doku, Migrationsskripte, Beispieltests fehlen, weil „Code ändern“ mit „Anforderung liefern“ verwechselt wurde.

Merkmal eines Werkzeug-Stacks: jeder Schritt hat das beste Tool, aber keine Schicht verantwortet die ganze Anforderung. Eine Agent-Plattform ergänzt eine Workflow-Schicht, die selbst zerlegt, ausführt und nach Fehlern neu ansetzt — OpenHands ist die Open-Source-Option dafür im Stack (Nachfolger-Ökosystem von OpenDevin).

Stack-Sprache: Workflow vs Context / Diff / Fact

Serienweit gilt: Workflow nicht als bloßer Downstream von Fact zeichnen. Workflow (L5) ist Orchestrierung, die im Task-Zyklus Context konsumiert, Diff erzeugt, mit Fact prüft, bis „Anforderung erfüllt“:

Cloud Mac AI Stack · Ergebnisbeziehungen (keine Aufrufreihenfolge)

  Workflow（L5 · OpenHands）
  ├── Context（L4 · MCP）          ← Repo / Issue / API lesen
  ├── Diff（L3 · Claude Code）   ← Code / Dateien ändern
  └── Fact（L1 · Runner / Tests）← test / build / CI-Signal

Agent loop（innerhalb Workflow · mehrfach iterierbar）
       Diff  ↔  Fact
         ↑       ↓
      Observe → Plan → Execute …

Vier Ergebnisarten parallel: Context · Diff · Fact · Workflow (MCP · Coding · Runner · OpenHands). Inference (L2 · Ollama) optional, bewusst nicht im Diagramm, um Verwechslung mit dem Agent-Loop zu vermeiden.

Workflow ist kein „weiterer CI-Job“, sondern ein mehrstufiger, unterbrechbarer Task-Zustandsautomat: im Loop mehrfach Diff und Fact, bis der PR lieferbar ist. Claude Code exceliert bei einrundigem Diff; OpenHands bei unbeaufsichtigtem Durchlauf des gesamten Loops — vorausgesetzt Context und Fact stehen.

OpenHands in einer Minute (kein Lexikon)

OpenHands ist eine Open-Source-autonome Software-Engineering-Agent-Plattform: in einer Sandbox (typisch Docker) nimmt sie ein Ziel in natürlicher Sprache entgegen und führt Plan → Code/Befehle → Output lesen → Debuggen aus, mit GitHub-Anbindung (Issues, PRs, CI-Status). Im Cloud Mac AI Stack ersetzt sie weder Claude Codes Pairing noch den Runners objektiven Build-Beweis, sondern orchestriert mehrstufige Lieferung darüber.

OpenHands vs Claude Code: keine Konkurrenz, verschiedene Ebenen

Wer OpenHands vs Claude Code oder Claude Code alternative sucht, fragt oft: Kann eines das andere ersetzen? Im Stack: nein und sollte nicht — andere Ebene, anderes Ergebnis:

• Claude Code (L3) → Diff: Pair Programming, Sie sind dabei.
• OpenHands (L5) → Workflow: autonomer Agent, Sie setzen das Ziel.

OpenHands als „zweites Claude Code“ scheitert schnell: schwach bei vagen Produktintuitionen; Claude Code schwach bei acht unbeaufsichtigten Issue-Schritten. Richtig: schichten — tagsüber Claude Code für harte Stellen, nachts OpenHands für die Issue-Queue.

Faustregel: PR-Intent in einem Satz → Claude Code; „Issue erledigen“ → OpenHands. Mit CodeGraph-Index im großen Repo bleibt Pairing oft Claude Code; OpenHands passt zu templatisierten Backend-Tasks. Beide teilen MCP Context, nicht die Rolle.

Welche Tasks für OpenHands? (erste Suchfrage)

Wer OpenHands agent oder OpenHands github sucht, will wissen: Was ist zuverlässig delegierbar? Unter Tests + CI empfehlen wir — auch Pool für L5-Q02:

Nicht als erster OpenHands-Task: großer Refactor ohne Tests, UX-Umbau, schema-kritische Migration mit Business-Freigabe, Prod-Secrets. Bleibt in Claude-Code-Sessions mit menschlichem Gate, dann Runner für Fact.

Wie OpenHands arbeitet (Agent-Loop)

Suchende nach How OpenHands works oder OpenHands agent loop wollen verstehen: Wie wird aus einem Satz ein merge-fähiger PR? Kern ist der Vier-Schritte-Loop Plan → Execute → Observe → Debug:

OpenHands agent loop (Konzept · kein Einmal-Pipeline)

        ┌──────────┐
        │   Plan   │  ← Context
        └────┬─────┘
             ▼
        ┌──────────┐
        │ Execute  │  → Diff
        └────┬─────┘
             ▼
        ┌──────────┐
        │ Observe  │  ← Fact (test / build / CI)
        └────┬─────┘
             │
      fail   │  pass
             ▼
        ┌──────────┐        ┌─────────────┐
        │  Debug   │ ──────▶│ Workflow OK │ → PR
        └────┬─────┘        └─────────────┘
             │
             └──── zurück Plan oder Execute

Kein „stärkerer Chat“: OpenHands architecture = zustandsbehaftete Task-Maschine — jedes Observe landet in der Trajectory für den nächsten Plan. Fix bug und Lint cleanup sind derselbe Loop, anderer Plan-Einstieg. Task-Replay unten; Docker/UI in L5-Q02.

Erst L0–L4, dann L5 — sonst Sandbox ohne organisationalen Beweis

Wir raten vom „Tag eins OpenHands installieren“. Reihenfolge wie L1 Einführungsreihenfolge, plus L5 nach MCP:

1. L0 — Cloud Mac als dauerhafter macOS-Knoten.
2. L1 — Runner: push → grün/rot reproduzierbar.
3. L2–L3 — optional Ollama + Claude Code auf Fact.
4. L4 — MCP Hub + Berechtigungsmodell: lesen/schreiben auditierbar.
5. L5 — OpenHands: mehrstufiger Workflow.

Ohne L1 kann OpenHands technisch PRs öffnen — das Team bewertet Merge-Risiko nicht. Das ist derselbe Organisationsfehler wie „SSH grün, Actions rot“. Ohne L4 wächst die Token-Fläche des autonomen Agents.

Echter Task-Ablauf: Plan → Execute → Observe → Debug

Replay auf einem Sandbox-Fork (Zahlen illustrativ), abgleichbar mit Agent-Loop:

Ziel: Issue #218 „CSV-Export fehlt UTF-8 BOM“

  ① Issue + src/export/*.ts lesen     ~2 min · Context
  ② 6-Schritte-Plan                   ~1 min · Plan
  ③ 4 Dateien + 1 Test                ~8 min · Execute
  ④ pnpm test → Snapshot fail         ~3 min · Observe · Fact
  ⑤ Log → 2 Dateien nachziehen        ~5 min · Debug → Execute
  ⑥ Tests grün                        ~3 min
  ⑦ PR + Issue-Link                   ~1 min · Workflow-Lieferung

~23 min wall time · Mensch: Ziel freigeben + Merge-Review

Schritt ④ (Observe): Testfehler sind Loop-Input, kein Desaster. Im Pairing fixen Sie sofort; OpenHands braucht Observe → Debug → Fact in die nächste Execute-Runde. Ohne festen Testbefehl (L1 nicht verankert) dreht der Loop leer — wieder: Runner vor OpenHands.

Trigger-Konzept (kein Install-Tutorial):

# Konzept: Issue-Label startet autonomen Task
on:
  issues:
    types: [labeled]
if: github.event.label.name == 'agent:openhands'
run: |
  openhands run \
    --repo "${{ github.repository }}" \
    --issue "${{ github.event.issue.number }}" \
    --max-iterations 40 \
    --sandbox docker

Runner · OpenClaw · OpenHands: drei Namen, drei Rollen

OpenClaw trifft keine Architekturentscheidungen — „wann laufen, wie benachrichtigen“. OpenHands signiert keine iOS-Archive — lieferbar sind review-fähige PRs und Schrittlogs. Alle drei auf einem Cloud Mac, aber nicht in einem Runbook vermischen.

Typische Architektur: OpenHands self-hosted · Docker · macOS

Wer OpenHands Mac oder OpenHands self-hosted sucht, braucht Topologie, keine Install-Schritte. Minimale Produktionsform auf Apple-Silicon Cloud Mac:

OpenHands self-hosted on macOS (Cloud Mac · L0)

  GitHub（issues / webhooks / PR）
           │
           ▼
  ┌─────────────────────────────────────┐
  │  Cloud Mac · macOS · Apple Silicon   │
  │  ┌─────────────┐  ┌───────────────┐  │
  │  │ OpenHands   │  │ Claude Code   │  │  L5 + L3 (optional gleicher Knoten)
  │  │ (Docker)    │  │ (SSH/Terminal)│  │
  │  └──────┬──────┘  └───────────────┘  │
  │         │ sandbox workspace           │
  │         ▼                             │
  │  ┌─────────────┐  ┌───────────────┐  │
  │  │ MCP Servers │  │ Ollama (opt.) │  │  L4 · L2
  │  └─────────────┘  └───────────────┘  │
  │         │ git push                    │
  │         ▼                             │
  │  ┌─────────────────────────────────┐  │
  │  │ GitHub Runner (self-hosted)     │  │  L1 Fact
  │  └─────────────────────────────────┘  │
  └─────────────────────────────────────┘

Warum Workflow auf Cloud Mac, nicht auf dem Laptop?

• Dauer — Tasks oft 30–90 Min.; Deckel zu = Abbruch.
• Docker — stabiler Daemon; Cloud Mac 24/7.
• Mit Runner im Stack — gleicher Knoten validiert nach Agent-Push, weniger SSH-grün/Actions-rot.
• ABI — iOS/macOS-Ziele auf Apple Silicon statt Linux-VPS-Überraschungen.

Minimaler Docker-Start (Konzept; vollständiges compose in L5-Q02):

# Cloud Mac · OpenHands self-hosted (Skizze)
docker pull docker.all-hands.dev/all-hands-ai/openhands:0.9
docker run -d --name openhands \
  -e SANDBOX_USER_ID=$(id -u) \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v $HOME/.openhands:/.openhands \
  -p 3000:3000 \
  docker.all-hands.dev/all-hands-ai/openhands:0.9

L5 Agent Stack: welcher Cloud Mac?

Nach der Architektur die Spezifikation — Orientierung aus realen Stack-Kombinationen:

Die Kette Workflow → Cloud Mac → Spezifikation: erst L5-Bedarf klären, dann Knoten für Docker + optional Ollama + Runner — nicht umgekehrt Hardware mieten und Tools stapeln.

Grenzen klarziehen schlägt Agent-Hype

Skripte und Services: ja; reguliertes Prod-Schreiben: nein. OpenHands ist Engineering-Beschleuniger, kein entlastendes „Auto-DevOps“.

Entscheidung: Cloud Mac zur Agent-Plattform upgraden?

Self-Check — ≥3 Treffer links vor L5-Invest:

Fazit: OpenHands zählt nicht als „schlauerer Chat“, sondern als Upgrade von Werkzeug-Stack zu plattformischer Anforderungsverantwortung — wenn Fact (Runner) und Context/Policy (MCP) stehen. Sonst automatisieren Sie nur die Hand-Verkettung, Merge bleibt riskant.

L5-Serie: von der Entscheidung zum ersten autonomen Task

Vor L6 mindestens ② abschließen — ohne replizierbares OpenHands-Tutorial fehlt dem Hub die Landing. Gesamtkarte in L6-Q01; die Serie wird von „AI Tool Stack“ zu „AI Engineering Platform“.

FAQ

Agent-Loop?
Plan → Execute → Observe → Debug; siehe Wie OpenHands arbeitet.

OpenHands vs Claude Code?
Kein Entweder-oder; siehe Vergleich.

Installation?
Hub ohne Schritt-für-Schritt; L5-Q02 (geplant 14.06.).

Self-hosted auf Mac?
Ja — Cloud Mac + Docker; Architektur.

Ohne Runner?
Läuft, nicht empfohlen — erst L1.

OpenClaw?
Dreieck und OpenClaw-Notiz.

Spezifikation?
L5-Tabelle; nur OpenHands ab M4 16GB.