Wie Arbeit in Agent Studio abläuft
Verfolge eine Aufgabe durch Vorbereitung, Ausführung und Review. Prüfe Belege, behandle unvollständige Ausführungen und unterscheide Integration von Abnahme.
Board-Spalten zeigen den Arbeitsschritt. Der Ausführungsstatus zeigt, ob eine CLI tatsächlich läuft. Prüfe Änderungen und Checks, bevor du etwas annimmst oder zurückgibst.
Der Aufgabenablauf
Die Plattform steuert Aufgabenübergänge und startet oder stoppt Ausführungen. Jede Coding-Ausführung nutzt einen isolierten Git-Worktree, auch bei einem Ausführungsplatz sowie beim Fortsetzen und erneuten Ausführen. Eine Karte kann nach Prozessende weiterhin in Bearbeitung stehen.
- 0-backlog: neue Arbeit, deren Auftrag noch geklärt wird.
- 1-preparation: Umfang, Vorgaben und Ausführungsauftrag festlegen.
- 2-ready: eingereihte Arbeit; Abhängigkeiten können den Start noch verhindern.
- 3-progress: Ausführungsphase; tatsächliche Aktivität zeigt der Ausführungsstatus.
- 4-auto-review: automatische Prüfung und Nachbearbeitung.
- 5-human-review: menschliche Entscheidung, einschließlich eskalierter Arbeit.
- 6-completed: von einer Person angenommene Arbeit.
- 7-archive: aufbewahrter Verlauf.
Laufprotokoll
Übernehmen. Ausführen. Liefern.
Ein Bearbeitungsversuch von der zugewiesenen Lease bis zu prüfbaren Ergebnissen.- 01
run/claimedÜbernehmen
Der Runner fragt nach vorbereiteter Arbeit. Der Task Server vergibt eine befristete Lease mit Fencing-Token.
- von
- agent-runner
- verwaltet
- Task Server
- 02
run/startedAusführen
Die gewählte Coding-Agent-CLI arbeitet auf ihrem Aufgabenbranch in einem isolierten Worktree. Das gilt auch bei nur einem Ausführungsslot.
- Bereich
- task/<id>
- Prüfung
- Prüfungen + Diff
- 03
run/deliveredLiefern
Der Runner liefert Ergebnis und Prüfergebnisse. Der Task Server leitet das Ergebnis zum Review weiter.
- Inhalt
- Status + Prüfergebnisse
- danach
- Review-Entscheidung
Aufgabe WEB-12 lease f_18 Ergebnis → Prüfergebnisse → Review Die Git-Revision verfolgen
Aufgabenarbeit wird als Lieferung dokumentiert, durchläuft automatische Prüfungen und wird vor dem menschlichen Review in den konfigurierten Branch integriert. Übernahme und versionierter Stable-Release haben eigene Prüfungen.
Automatische Prüfung und Überarbeitung
Nach einer erfolgreichen CLI-Ausführung untersucht die automatische Prüfung Ergebnis und ausgewählte Review-Aspekte. Sie kann eine begrenzte Wiederholung anfordern, die Aufgabe ans menschliche Review weitergeben oder begründet eskalieren. Sie schließt die Aufgabe nicht anstelle einer Person ab.
- Fehlende erforderliche Prüfungen oder Screenshots können Nacharbeit auslösen.
- Eine unklare Ausführung mit gesicherten Teilergebnissen braucht Prüfung; sie darf nicht in wiederholten automatischen Versuchen verschwinden.
Über die Abnahme entscheiden
Lies Diff, Ausführungsprotokoll und Belege. Nimm die Arbeit an, fordere eine konkrete Überarbeitung an oder trenne eine Folgeaufgabe ab. Integration und Abnahme werden getrennt erfasst: Die Änderung kann bereits auf develop liegen, während deine Entscheidung noch aussteht.
Ausnahmebeispiel: DEMO-9 hat ihr Limit für weitere Bearbeitungsrunden ausgeschöpft. Offene Befunde und ausstehende Integration bleiben neben den Entscheidungsoptionen sichtbar. Originalaufnahme; die Produktoberfläche enthält englische Texte.
Release-Umfang prüfen
Der Freigabedialog berechnet den genauen Git-Umfang neu und nennt angenommene Aufgaben, offene Reviews, Eskalationen und nicht zugeordnete Commits. Prüfe dieses Manifest vor der Übernahme nach main. Stable erfordert ein unveränderliches v<semver>-Tag auf einem qualifizierten main-Stand und dokumentierte Build-Belege.
Geprüfte Arbeit integrieren, verifiziertes Release markieren.
Der Release-Schritt übernimmt den Integrationsbranch mit dokumentiertem Review-Status. Ein unveränderlicher Versions-Tag kennzeichnet einen geprüften Stand.
- 01Aufgabenkarten
task/*Abgegrenzte Arbeit hält Diff, Prüfungen und Review-Befunde fest.
- 02Integrationsbranch
developRevisionen gelangen nach bestandenen konfigurierten Prüfungen nach develop. Die menschliche Annahme kann noch ausstehen.
- 03Release-Übernahme
develop → mainDer Dialog zeigt vor der Bestätigung angenommene, ungeprüfte, eskalierte und nicht zugeordnete Arbeit.
- 04Release-Branch
mainEin main-Stand hält freigegebenen Code fest. Ein eigener Versions-Tag kennzeichnet ein unveränderliches Release.
- 05Versions-Tag
v<semver>Ein geprüfter main-Commit wird mit Versions-Tag und Release-Manifest festgehalten. Ein Stable-Referenz-Checkout kann später auf einen anderen Stand wechseln.
Ergebnisprotokoll prüfen
Die Plattform committet Aufgabenänderungen und dokumentierte Lieferungen. Diffs, Screenshots mit Quellenangabe, Befehlsausgaben, Zusammenfassungen und Verlauf machen die Arbeit prüfbar. Die Sicherung nicht committeter Agentenausgaben ist Aufgabe der Plattform.
Arbeit außerhalb des Runners erfassen
Erfasse externe Arbeit mit Zusammenfassung, Quelle und Lieferungen über POST /api/tasks/{id}/external-completion. Der Aufruf gleicht Belege und Ausführungsstatus vor dem Spaltenwechsel ab; das Standardziel ist das menschliche Review. Die Kennzeichnung für extern erledigte Arbeit nennt ihren Ursprung.
Projektübergreifende Signale, Entscheidungen und Aktionen mit Filtern für Projekt und Ereignistyp. Originalaufnahme; die Produktoberfläche enthält englische Texte.
Auf einem konfigurierten Host ausführen
Ein entfernter Host führt CLI und Aufgaben-Worktree aus; der Task Server hält Aufgabenstatus und Review-Protokolle. Jeder Host braucht konfigurierten Repository-Zugriff und Konten. Die dokumentierte Prüfung auf Ubuntu 24.04 belegt diese Umgebung, nicht jede Installation.
Arbeit im Projektkontext besprechen
Projekt- und Aufgabengespräche können Board, Kontext und Belege einbeziehen. Wähle eine konfigurierte CLI, ein Modell und eine Denkstufe. Prüfe aufgezeichneten Sitzungsverbrauch und Verweise, bevor du einer Antwort folgst.