Angenommen, ein Coding-Agent öffnet um 18 Uhr einen Pull Request. Die Tests sind grün, eine Vorschau läuft, und die Person, die den Review macht, ist schon offline.

Die Aufgabe des Agenten ist erledigt. Die Maschine hat noch etwas zu tun: die Vorschau bereitstellen, bis jemand sie sich ansieht. Oder auch nicht. Vielleicht lässt sich die Vorschau morgen neu bauen, und der Workspace sollte jetzt herunterfahren.

Beide Entscheidungen sind vernünftig. Sie offenzulassen ist der Weg, auf dem aus einer kurzen Coding-Aufgabe eine Maschine wird, an deren Start sich niemand erinnert.

Das Coder-Walkthrough von Web Dev Cody zeigt Agenten, die in entfernten Umgebungen arbeiten, darunter ein AWS-EC2-Workspace, mit Änderungen und Vorschauen zur Prüfung. Das Video ist von Coder gesponsert. Es brachte mich auf eine engere Frage: Was sollte enden, wenn ein Agent fertig ist?

Es gibt drei getrennte Antworten: der Befehl, die Agentensitzung und der Workspace. Ein Limit für eines davon steuert die anderen nicht automatisch.

Ein Test-Timeout deckt nur den Test ab

Hier ist eine kleine Schutzmaßnahme für ein Node.js-Projekt. Sie setzt Bash, GNU timeout, installierte Abhängigkeiten und ein funktionierendes npm test-Skript voraus. Führen Sie sie im Projektverzeichnis aus:

#!/usr/bin/env bash
set -u

if timeout --kill-after=30s 10m npm test >test.log 2>&1; then
  printf 'Tests passed. Output: test.log\n'
else
  status=$?
  printf 'Tests failed or timed out (exit %s). Output: test.log\n' \
    "$status" >&2
  exit "$status"
fi

Nach zehn Minuten sendet timeout ein Beendigungssignal. Ist der Befehl dreißig Sekunden später noch nicht beendet, folgt ein Kill-Signal. Ein Timeout liefert normalerweise 124; ein erzwungener Abbruch kann 137 liefern. Andernfalls bleibt der Exit-Status des Befehls erhalten. GNU-Dokumentation

Stellen Sie sich nun vor, der Agent liest den Fehler, ändert etwas und startet die Tests erneut. Jeder Versuch hat ein Limit. Die Aufgabe als Ganzes kann trotzdem endlos weiterlaufen.

Dafür braucht es eine eigene Frist oder ein Budget für Wiederholungen, durchgesetzt von dem System, das den Agenten startet und überwacht. Ein Timeout in einem Skript, das der Agent umschreiben kann, hilft bei gewöhnlichen Fehlern, ist aber keine verlässliche Grenze für den Agenten selbst.

Ein aktiver Workspace wird vielleicht nie inaktiv

Ein Inaktivitäts-Timer klingt nach einer Antwort auf das Problem der Maschine, die über Nacht läuft. Wie nützlich er ist, hängt davon ab, was als Aktivität zählt.

Die Scheduling-Dokumentation von Coder sagt, dass ein arbeitender Agent die Abschaltfrist des Workspace verlängern kann. Das verhindert, dass eine legitime Aufgabe unterbrochen wird. Es bedeutet aber auch, dass ein Agent, der in Arbeit feststeckt, seine Umgebung am Leben halten kann.

Für den hypothetischen Pull Request um 18 Uhr wäre meine Regel: die Agentensitzung beenden, sobald sie das Ergebnis übergibt, die Nachweise für den Review sichern und die Vorschau nur bis zu einem ausdrücklichen Ablaufzeitpunkt behalten. Ein längeres Review-Fenster sollte eine bewusste Verlängerung sein.

Die Überwachung sollte auch die weniger sauberen Fälle abdecken: Der Agent stürzt ab, verliert die Verbindung oder versucht es immer wieder, ohne ein Ergebnis zu liefern. Eine Frist, die davon abhängt, dass der Agent seinen Abschluss erfolgreich meldet, deckt diese Fehler nicht ab.

Das ist eine Regel, die umgesetzt und getestet werden muss, keine Behauptung, dass jede Agentenplattform dieselben Steuerungsmöglichkeiten bietet.

Nachweise sichern, bevor der Workspace entfernt wird

Das Abschalten wird heikel, wenn die einzige Kopie einer Änderung oder ihrer Testausgabe auf der Maschine liegt, die gestoppt werden soll.

Für eine Aufgabe mit einem Git-Worktree könnte das Setup so aussehen. Führen Sie es in einem bestehenden Checkout aus, mit einem neuen Branch-Namen und einem unbenutzten Zielverzeichnis:

task_id="issue-142"
task_dir="../agent-${task_id}"

git worktree add -b "agent/${task_id}" "$task_dir" HEAD

Das startet vom committeten HEAD; nicht committete Änderungen werden nicht kopiert. Ein Worktree trennt die Arbeitsdateien, teilt sich aber die Repository-Daten. Zugangsdaten, Prozesse oder Cloud-Ressourcen isoliert er nicht. Git-Dokumentation

Sichern Sie vor dem Aufräumen den Commit auf dem Remote und hängen Sie das Testergebnis an den Pull Request. Geben Sie den ausgeführten Befehl und eventuelle Fehler an. Braucht jemand für den Review die Vorschau, halten Sie fest, welchen Commit sie ausliefert und wann sie abläuft.

Prüfen Sie nach dem Review den Worktree vom ursprünglichen Checkout aus. Entfernen Sie ihn erst, wenn seine Arbeit und nützliche Logs gesichert sind:

git -C ../agent-issue-142 status --short

# Run only after checking the status and preserving the work.
git worktree remove ../agent-issue-142

Ohne --force verweigert Git das Entfernen, solange nicht committete Änderungen oder nicht versionierte Dateien vorhanden sind. Dazu gehört auch die test.log aus dem Beispiel oben. Ein sauberer Status beweist nicht, dass die Commits gepusht wurden; prüfen Sie das gesondert.

Das Entfernen des Worktrees lässt den Branch und die Cloud-Ressourcen bestehen. Selbst das Stoppen einer EC2-Instanz ist etwas anderes als ihre Beendigung. Die Infrastruktur braucht einen eigenen Aufräumschritt und eigene Aufbewahrungsregeln. EC2-Dokumentation

Erst eine gescheiterte Aufgabe, dann zehn Agenten

Bevor Sie dieses Setup ausbauen, starten Sie bewusst eine Aufgabe, die nicht fertig werden kann. Lassen Sie ihre Frist ablaufen. Prüfen Sie dann, ob der Agent gestoppt hat, ob die Logs erhalten geblieben sind und welche Ressourcen noch aktiv sind.

Wiederholen Sie das mit einer erfolgreichen Aufgabe, deren Reviewerin oder Reviewer erst am nächsten Tag Zeit hat. Die Vorschau sollte für das zugesagte Zeitfenster verfügbar bleiben, ohne dass der Agent dafür weiterarbeiten muss.

Diese beiden Fälle würden mir mehr über die Einsatzbereitschaft sagen als eine weitere erfolgreiche Demo. Ich möchte den Laptop zuklappen können und wissen, was morgen noch läuft und warum.