Blockierte Aufgaben in paralleler Entwicklung triagen

Du kannst jetzt 10 KI-Coding-Agenten parallel laufen lassen. Gib jedem ein Issue, richte sie auf eine gemeinsame beads-Datenbank und lass sie arbeiten. Agenten erstellen Teilaufgaben, melden entdeckte Bugs, aktualisieren Status und schließen Issues, wenn sie fertig sind. Es ist wirklich produktiv.

Bis etwas blockiert.

Wenn ein Mensch blockiert ist, sagt er etwas. Er postet in Slack, meldet es im Standup, geht zum Schreibtisch von jemandem. Agenten tun nichts davon. Ein Agent stößt auf eine Abhängigkeit, die er nicht auflösen kann, und stagniert entweder stillschweigend oder beginnt, das Problem auf eine Weise zu umgehen, die weitere Probleme schafft. Drei Agenten können am selben ungelösten Upstream-Task feststecken und du erfährst es erst, wenn du dich fragst, warum seit vier Stunden nichts ausgeliefert wurde.

Das ist das Triage-Problem für agentenbasierte Entwicklung. Nicht "wie führen wir bessere Standups durch", sondern "wie sehen wir, was in einer Flotte autonomer Arbeiter feststeckt, die sich nicht beschweren." Hier ist, was wir beim Bau von Beadbox gelernt haben, einem Echtzeit-Dashboard für beads, das dir genau zeigt, was deine Agenten tun, worauf sie blockiert sind und was gerade verfügbar wurde.

Spring direkt zum relevanten Thema:

• Wie Agenten Blockierungsketten erzeugen -- die Muster, die für agentenbasierte Arbeit einzigartig sind
• Automatische Abhängigkeitserkennung -- Blockaden erkennen, während sie entstehen
• Ein CLI-First-Triage-Workflow -- skriptfähig, durch Agenten ausführbar
• Echtzeit-Sichtbarkeit -- Blockaden im Moment ihres Auftretens sehen
• Triage-Tools bewerten -- worauf du achten solltest
• Die Supervisor-Schleife -- wie wir täglich 10+ Agenten betreiben

Wie Agenten Blockierungsketten erzeugen

Agenten erzeugen Abhängigkeitsprobleme anders als menschliche Teams. Die Fehlermodi zu verstehen ist wichtig, weil die Triage-Reaktionen unterschiedlich sind.

Agenten modellieren Abhängigkeiten nicht im Voraus. Ein menschlicher Architekt zerlegt ein Feature in Aufgaben und denkt über die Reihenfolge nach. Ein Coding-Agent erhält eine Aufgabe, fängt an zu arbeiten und entdeckt mitten in der Implementierung, dass er etwas braucht, das noch nicht existiert. Er legt vielleicht ein neues Issue für diese Abhängigkeit an. Er versucht vielleicht, sie inline zu bauen und richtet ein Chaos an. Oder er stoppt einfach. Keines dieser Ergebnisse ist sichtbar, es sei denn, du beobachtest die Issue-Datenbank.

Agenten arbeiten schneller als Abhängigkeitsgraphen sich aktualisieren. Agent-3 schließt eine Aufgabe, auf die Agent-7 gewartet hat, aber Agent-7 weiß das nicht, weil er vor 10 Minuten nach Blockern geschaut hat. Währenddessen ist Agent-7 immer noch idle oder arbeitet an etwas mit niedrigerer Priorität. Die Freigabe ist passiert, aber die Information hat sich nicht verbreitet.

Zirkuläre Abhängigkeiten entstehen durch parallele Zerlegung. Wenn mehrere Agenten gleichzeitig Arbeit zerlegen, können sie Zyklen erzeugen, die kein einzelner Agent sieht. Agent-1 erstellt Aufgabe A, die von Aufgabe B abhängt. Agent-2 erstellt Aufgabe B, die von Aufgabe C abhängt. Agent-3 erstellt Aufgabe C, die von Aufgabe A abhängt. Jede Abhängigkeit war lokal sinnvoll. Der Zyklus ist nur von oben sichtbar.

Ressourcenkonflikte sind unsichtbar. Zwei Agenten müssen beide dieselbe Datei ändern, oder beide brauchen die Staging-Umgebung, oder beide brauchen dieselbe Bibliothek in einem stabilen Zustand. Es wird keine Abhängigkeit gemeldet, weil keiner der Agenten vom anderen weiß. Beide werden langsamer und keiner berichtet warum.

Der rote Faden: Agenten erzeugen Blockierungssituationen schneller, als sie diese melden. Du als Supervisor brauchst Werkzeuge, die Blockaden automatisch sichtbar machen, nicht Werkzeuge, die darauf warten, dass jemand ein Signal gibt.

Automatische Abhängigkeitserkennung

Die Lösung sind explizite, abfragbare Abhängigkeitsdaten, die zum Zeitpunkt der Aufgabenerstellung erfasst und kontinuierlich überprüft werden. So sieht das mit beads aus, dem Git-nativen Issue-Tracker, auf dem wir unsere Agent-Flotte betreiben.

Agenten erfassen Abhängigkeiten beim Erstellen von Aufgaben:

# Agent erstellt eine Aufgabe und entdeckt, dass eine noch nicht existierende API nötig ist
API_TASK=$(bd create \
  --title "Implement /api/v2/orders endpoint" \
  --type task --priority 2 --json | jq -r '.id')

# Agent erstellt seine eigene Aufgabe und deklariert die Abhängigkeit
UI_TASK=$(bd create \
  --title "Build order history page" \
  --type task --priority 2 --json | jq -r '.id')

bd dep add "$UI_TASK" "$API_TASK"

Dieses bd dep add ist ein einzelner CLI-Aufruf. Jeder KI-Coding-Agent (Claude Code, Cursor, Copilot Workspace) kann ihn ausführen. Keine API-Client-Bibliothek, kein Auth-Tanz. Die Abhängigkeit ist jetzt strukturierte Daten, abfragbar von jedem anderen Agenten oder Skript.

Zykluserkennung läuft automatisch:

# beads prüft den gesamten Abhängigkeitsgraphen auf Zyklen
bd dep cycles

# Ausgabe bei vorhandenen Zyklen:
# CYCLE DETECTED: beads-a1b -> beads-c3d -> beads-e5f -> beads-a1b

Bei einem 5.000-Abhängigkeiten-Graphen dauert das ~70ms. Führe es als Post-Commit-Hook oder per 5-Minuten-Cron aus. Wenn drei Agenten unabhängig voneinander einen Abhängigkeitszyklus erstellen, erkennst du ihn in Minuten statt Stunden später, wenn alle drei stagnieren.

Alle blockierten Aufgaben mit einem Befehl anzeigen:

bd blocked --json | jq -r '.[] |
  "BLOCKED: \(.id) \(.title)\n  waiting on: \(.blocked_by | join(", "))\n  assignee: \(.owner // "unassigned")\n"'

Ausgabe:

BLOCKED: beads-x7q Build order history page
  waiting on: beads-m2k Implement /api/v2/orders endpoint
  assignee: agent-3

BLOCKED: beads-r4p Deploy staging environment
  waiting on: beads-j9w Fix Docker build, beads-n1c Update TLS certificates
  assignee: agent-7

Jetzt weißt du, dass Agent-3 und Agent-7 feststecken, woran sie feststecken und was passieren muss, um sie freizugeben. Die gesamte Abfrage hat 30ms auf einer 10K-Issue-Datenbank gedauert.

Blockierte PRs über Branch-Namenskonventionen erkennen:

#!/bin/bash
# blocked-prs.sh: find PRs whose dependencies haven't merged

for pr in $(gh pr list --json number,headRefName --jq '.[].headRefName'); do
  ISSUE_ID=$(echo "$pr" | grep -oE 'beads-[a-z0-9]+')
  [ -z "$ISSUE_ID" ] && continue

  BLOCKERS=$(bd show "$ISSUE_ID" --json | jq -r '.blocked_by[]' 2>/dev/null)
  for blocker in $BLOCKERS; do
    BLOCKER_STATUS=$(bd show "$blocker" --json | jq -r '.status')
    if [ "$BLOCKER_STATUS" != "closed" ]; then
      echo "PR ($pr) blocked: $ISSUE_ID waiting on $blocker ($BLOCKER_STATUS)"
    fi
  done
done

Zwanzig Zeilen Shell. Läuft lokal, liest lokale Daten, sagt dir, welche PRs von deinen Agenten noch nicht gemergt werden können und warum.

Ein CLI-First-Triage-Workflow

Triage in einem agentenbasierten Workflow ist kein Meeting. Es ist ein Skript, das in einer Schleife läuft. Der Supervisor (Mensch oder Agent) schaut, was feststeckt, und trifft eine Entscheidung für jeden Punkt.

Hier ist das Triage-Skript, das wir tatsächlich nutzen:

#!/bin/bash
# triage.sh: agentic fleet blocker triage

echo "========================================="
echo "TRIAGE REPORT: $(date +%Y-%m-%d %H:%M)"
echo "========================================="

# 1. Was ist blockiert?
echo -e "\n--- BLOCKED TASKS ---"
bd blocked --json | jq -r '.[] |
  "[\(.priority)] \(.id) \(.title)
    blocked by: \(.blocked_by | join(", "))
    assignee: \(.owner // "unassigned")\n"'

# 2. Was ist für Agenten verfügbar?
echo -e "\n--- READY (unblocked, open) ---"
bd ready --json | jq -r '.[] |
  "[\(.priority)] \(.id) \(.title) (\(.owner // "unassigned"))"'

# 3. Welche Agenten sind verstummt?
echo -e "\n--- STALE IN-PROGRESS (no update in 2h) ---"
CUTOFF=$(date -v-2H +%Y-%m-%dT%H:%M:%S 2>/dev/null || date -d '2 hours ago' --iso-8601=seconds)
bd list --status=in_progress --json | jq -r --arg cutoff "$CUTOFF" '.[] |
  select(.updated_at < $cutoff) |
  "STALE: \(.id) \(.title) (last update: \(.updated_at), assignee: \(.owner // "unknown"))"'

# 4. Zustand der Abhängigkeiten
echo -e "\n--- DEPENDENCY CYCLES ---"
bd dep cycles 2>&1 || echo "No cycles detected."

echo -e "\n--- FLEET STATS ---"
bd stats

Für menschliche Teams bedeutet "veraltet" 48 Stunden ohne Update. Für Agenten ist 2 Stunden Stille bei einer In-Progress-Aufgabe ein Warnsignal. Entweder steckt der Agent fest und meldet es nicht, oder er ist abgestürzt. So oder so musst du nachschauen.

Der Entscheidungsbaum für jeden blockierten Punkt:

1. Kann ein anderer Agent die Blockade lösen? Die blockierende Aufgabe höher priorisieren, einen verfügbaren Agenten zuweisen.
2. Ist die Abhängigkeit falsch? Agenten erstellen manchmal während der Planung übervorsichtige Abhängigkeiten. Wenn die Blockade nicht real ist, entfernen: bd dep remove beads-x7q beads-m2k (entfernt die Abhängigkeit von x7q auf m2k, gibt x7q sofort frei).
3. Kann die Arbeit aufgeteilt werden? Den blockierten Agenten die Teile machen lassen, die die Abhängigkeit nicht brauchen. Eine Folgeaufgabe für den Rest erstellen.
4. Ist es eine externe Blockade? Etwas, das nur ein Mensch lösen kann (API-Key, Design-Entscheidung, Zugriffsberechtigung). Taggen, erwartete Lösung notieren und den Agenten auf andere verfügbare Arbeit umleiten.

Option 2 passiert ständig mit Agenten. Sie modellieren Abhängigkeiten basierend auf ihrem Verständnis der Codebasis zum Planungszeitpunkt. Sobald die Implementierung losgeht, zeigt die tatsächliche Form der Arbeit, dass die Hälfte dieser Abhängigkeiten unnötig war.

Echtzeit-Sichtbarkeit der Agenten-Arbeit

Ein Triage-Skript alle 30 Minuten lässt Lücken. Wenn Agenten schnell arbeiten, passiert viel zwischen den Prüfungen. Die Frage ist: Kannst du sehen, wie sich Blockaden in Echtzeit bilden?

Wie Beadbox es macht:

Die beads-Datenbank lebt in einem .beads/-Verzeichnis auf deinem Dateisystem. Jedes bd update, bd create oder bd close, das ein Agent ausführt, schreibt in dieses Verzeichnis. Beadbox überwacht es mit fs.watch() und pusht Änderungen innerhalb von Millisekunden über WebSocket an die UI.

Der praktische Effekt: Agent-5 führt bd update beads-x7q --status=closed in einem Terminal aus. Das Beadbox-Dashboard zeigt die Aufgabe sofort als geschlossen, und jede Aufgabe, die darauf blockiert war, leuchtet als neu verfügbar auf. Du siehst die Kaskade, ohne einen Befehl auszuführen.

Das ist wichtig, weil agentenbasierte Arbeit in Schüben stattfindet. Ein Agent kann drei Aufgaben in 90 Sekunden schließen, die jeweils unterschiedliche Downstream-Arbeit freigeben. Ein Polling-basiertes Dashboard mit 30-Sekunden-Refresh würde dir einen verwirrenden Zwischenzustand zeigen. Sub-Sekunden-Propagierung zeigt dir das vollständige Bild, während es passiert.

Wenn du Beadbox nicht nutzt, funktionieren Dateisystem-Watches trotzdem:

# Watch the beads database for changes, alert on new blocks
# Note: fswatch fires on every write. In production you'd debounce this
# (e.g., sleep 2 after each trigger) to avoid noise during burst writes.
fswatch -o .beads/ | while read; do
  BLOCKED_COUNT=$(bd blocked --json | jq length)
  if [ "$BLOCKED_COUNT" -gt 0 ]; then
    echo "$(date): $BLOCKED_COUNT tasks currently blocked"
    # Pipe to ntfy, Slack webhook, or any notification system
  fi
done

Den Kreislauf mit CI schließen:

# In your CI post-build step: auto-close the issue when the build passes
if [ "$BUILD_STATUS" = "success" ]; then
  ISSUE_ID=$(echo "$BRANCH_NAME" | grep -oE 'beads-[a-z0-9]+')
  if [ -n "$ISSUE_ID" ]; then
    bd update "$ISSUE_ID" --status=closed
    bd comments add "$ISSUE_ID" --author ci \
      "Build passed. Commit: $COMMIT_SHA. Closing automatically."
  fi
fi

Wenn CI dieses Issue schließt, wird alles, was es blockierte, freigegeben. Wenn ein Agent bd ready auf neue Arbeit überwacht, nimmt er die freigegebene Aufgabe automatisch auf. Kein Mensch in der Schleife für Routine-Freigaben.

Das ist der Unterschied zwischen Tools, die Status tracken, und Tools, die ihn propagieren. Die meisten Projektmanagement-Tools tun Ersteres: Du aktualisierst eine Karte, die Karte ändert die Farbe. Propagierung bedeutet, dass Downstream-Effekte (Abhängige freigeben, verfügbare Arbeit anzeigen, Fortschrittsbalken aktualisieren) ohne jeden Klick passieren.

Triage-Tools für agentenbasierte Workflows bewerten

Wenn du nach Werkzeugen suchst, um eine Agent-Flotte zu verwalten, sind die Anforderungen anders als bei einem menschlichen Team.

Muss: CLI, die Agenten aufrufen können. Wenn dein Issue-Tracker nur eine Web-UI hat, können Agenten ihn nicht nutzen. Sie müssen Shell-Befehle ausführen können. bd create, bd update, bd blocked sind Einzeiler, die jeder Coding-Agent schon kann. REST-APIs funktionieren auch, erfordern aber Auth-Tokens, HTTP-Clients und Fehlerbehandlung. Unix-Pipes sind einfacher.

Muss: abfragbarer Abhängigkeitsgraph. "Blockiert" als Status-Label ist für Automatisierung nutzlos. Du brauchst "A hängt von B ab" als strukturierte Daten, damit Skripte den Graphen traversieren, Zyklen erkennen und berechnen können, was bereit ist.

Muss: Lokale Lesevorgänge unter einer Sekunde. Wenn Agenten nach verfügbarer Arbeit fragen, zählt die Antwortzeit. Ein 2-Sekunden-API-Roundtrip pro Abfrage, multipliziert mit 10 Agenten, die jede Minute pollen, erzeugt messbaren Overhead. beads liefert bd ready-Ergebnisse in 30ms auf einer 10K-Issue-Datenbank, weil alles lokal ist.

Nice-to-have: Echtzeit-Änderungspropagierung. Wenn Agenten 50 Issues pro Stunde erstellen und lösen, musst du den Zustand sehen, während er sich ändert, nicht in einem Refresh-Intervall.

Warnsignal: "KI-gestützte Blocker-Erkennung." Tools, die behaupten, Blockaden durch Analyse von Issue-Beschreibungen zu erkennen, erzeugen False Positives und verpassen echte Blockaden, die nie aufgeschrieben wurden. Explizite bd dep add-Deklarationen schlagen Inferenz.

Warnsignal: Tools, die einen Browser für Triage erfordern. Eine Aufgabe über eine Web-UI freigeben dauert 5-15 Sekunden Klicken. Über die CLI dauert bd dep remove 18ms. Bei 50 blockierten Aufgaben sind das 1 Minute vs. 12 Minuten. Wenn du Agenten beaufsichtigst, die schnell arbeiten, ist Triage-Geschwindigkeit dein Engpass.

Wie gängige Tools mit Blockierungen umgehen

Die Supervisor-Schleife

Hier ist der Workflow, den wir täglich nutzen, mit 10+ KI-Agenten auf einem einzelnen Projekt:

1. Agenten deklarieren Abhängigkeiten bei der Aufgabenerstellung. Jedes bd create, das eine Voraussetzung hat, bekommt sofort ein bd dep add. Das ist ein einziger zusätzlicher CLI-Aufruf pro Aufgabe.

2. Ein Supervisor-Agent führt alle 30 Minuten bd blocked aus. Wenn etwas neu blockiert ist, löst er den Blocker entweder selbst (umpriorisieren, neu zuweisen) oder meldet es dem Menschen.

3. Beadbox läuft auf dem Bildschirm des Menschen. Das Dashboard zeigt den vollständigen Abhängigkeitsgraphen mit blockierten Aufgaben in Echtzeit hervorgehoben. Meistens kümmert sich die Automatisierung um Routine-Freigaben. Wenn sie es nicht kann (externe Abhängigkeit, Architekturentscheidung, Zugriffsberechtigung), sieht der Mensch das Problem sofort und greift ein.

4. Veraltete Aufgaben werden aggressiv gemeldet. Ein Agent, der seine In-Progress-Aufgabe seit 2 Stunden nicht aktualisiert hat, steckt entweder fest oder ist abgestürzt. Der Supervisor prüft und stupst entweder den Agenten an, weist die Arbeit neu zu oder untersucht.

5. Falsche Abhängigkeiten werden kontinuierlich bereinigt. Agenten überdeklarieren Abhängigkeiten während der Planung. Wenn die Implementierung die tatsächliche Form der Arbeit zeigt, entfernt der Supervisor (oder die Agenten selbst) Abhängigkeiten, die sich als unnötig herausgestellt haben. Ein sauberer Graph ist ein nützlicher Graph.

Das grundlegende Prinzip: Agenten sind schnell, aber nicht selbstreflektiert. Sie wissen nicht, was andere Agenten tun, sie bemerken nicht, wenn Blockaden sich auflösen, und sie beschweren sich nicht, wenn sie feststecken. Die Aufgabe des Supervisors ist es, das Nervensystem zu sein, das all das verbindet. Strukturierte Abhängigkeitsdaten, automatisch abgefragt und visuell dargestellt, machen das möglich.

Beadbox ist während der Beta kostenlos. Es zeigt dir, was deine Agenten tun, was blockiert ist und was gerade verfügbar wurde, in Echtzeit.

brew tap beadbox/cask && brew install --cask beadbox

Wenn du bereits beads nutzt, liest Beadbox dein bestehendes .beads/-Verzeichnis ohne Import-Schritt. Probier es aus.