Lebenszyklus der Agenten-Ausführung

Was eine Ausführung ist

Eine Ausführung ist ein Lauf eines Agenten, in einer Unterhaltung, auf einem Adapter. Alles daran passiert auf cc_server: Der Client schickt eine Nachricht und beobachtet danach den Ereignisstrom. In keinem Client gibt es einen Ausführungspfad.

Agenten werden aus sechs Gründen geweckt. Der Lauf trägt sie als Aufwachkontext, damit der Agent weiß, warum er wach ist:

Aufwachgrund	Auslöser
`userMessage`	Jemand hat in einem Bereich eine Nachricht geschickt oder den Agenten erwähnt
`assignment`	Ein Ticket wurde dem Agenten zugewiesen
`pipelineStep`	Ein Pipeline-Schritt hat ihn ausgeführt
`childCompleted`	Ein untergeordnetes Ticket ist fertig
`followUp`	Ein geplanter Folge-Heartbeat
`recovery`	Der Wiederherstellungspfad hat nach einem Fehler erneut ausgeführt

Der Aufwachkontext trägt die IDs zum Grund, also Ticket, Bereich, Nachricht und Pipeline-Lauf, und sie werden in die Umgebung und den Prompt des Agenten geschrieben.

Prompt-Aufbau

Der Prompt entsteht in Schichten. Jede Schicht ist ein beschrifteter Abschnitt:

Identität: die eigene ID des Agenten, sein Name und die ID des Arbeitsbereichs, mit der ausdrücklichen Anweisung, genau diese UUIDs an arbeitsbereichsbezogene Tools zu übergeben. Der Arbeitsbereich gehört zum Agenten und ist deshalb immer vorhanden.
Werkzeugkatalog und Ressourcenprotokolle, danach das Layout des Arbeitsbereichs.
Überschreibung des System-Prompts, falls der Agent eine hat, dann die Persona (nach Rolle parametrisiert) und das Team-Briefing.
Skills: die Namen am Agenten.
Ausführungskontrakt und Verfahren für den aktuellen Modus.
Aufwachkontext und Erwähnungskontext: wer den Agenten gerufen hat und wer sonst noch dabei ist.
Modusblock: erzeugt aus dem Fähigkeitsprofil des Modus und der tatsächlich bereitgestellten Werkzeugliste, damit ein Prompt nie ein Werkzeug nennt, das der Lauf nicht hat.
Gedächtniskontext: Fakten, die zur Aufgabe geholt wurden.
Unterhaltungskontext: der jüngere Verlauf des Bereichs, gedeckelt bei 50.000 Zeichen wörtlichem Fenster, unabhängig von der konfigurierten Kontextgröße des Agenten. Älterer Verlauf wird nicht abgeschnitten. Der Agent holt ihn bei Bedarf mit get_messages, und semantisch passende ältere Nachrichten tauchen weiter auf.

Die Befehle sitzen an zwei Stellen. /todo und /compact fängt das Eingabefeld ab. Sie werden bewusst nie als Nachrichten gespeichert und nie an den Agenten geschickt. Würde /compact gespeichert, rückte der Kompaktierungsschnitt um einen Turn nach hinten und das Transkript wäre verunreinigt. /plan wird an beiden Stellen behandelt: Das Eingabefeld schaltet den Modus des Bereichs um. Genau das bringt Werkzeugoberfläche, Vorgabe der Schutzregeln und Prompt für diesen Turn und jeden folgenden in Einklang. /goal, /loop und /skill:<name> laufen im Lauf selbst und nur auf dem eingebauten Harness. /goal und /loop starten autonome Arbeit mit einem Kostenbudget, und ein Name mit dem Präfix skill: wird als Skill nachgeschlagen, dessen Rumpf aus SKILL.md zur Anweisung dieses Turns wird. Der Namensraum hält die beiden Vokabulare auseinander: Einen bloßen Namen gegen Skills aufzulösen hieß, dass ein Skill namens plan oder compact dauerhaft vom eingebauten Befehl verdeckt war. Ein bloßer Name, der kein eingebauter Befehl ist, löst sich weiter auf, für Nachrichten, die geschrieben wurden, bevor es den Namensraum gab. Ein unbekannter Name bleibt einfach Klartext.

Worktree-Bereitstellung

Bevor irgendetwas läuft, bekommt die Unterhaltung eine eigene Arbeitswurzel und darunter pro Repo einen isolierten Copy-on-Write-Worktree. Standardmäßig sind das alle Repos, die mit dem Arbeitsbereich verknüpft sind. Ein PR-Bereich, oder ein Bereich, der mit einer ausdrücklichen Auswahl angelegt wurde, stellt nur die freigegebenen bereit. Eine PR-Review-Unterhaltung pinnt ihr einziges Repo auf den Head-Ref des Pull Requests, die übrigen bleiben auf ihrem Standardbranch. Der Quell-Checkout wird nie verändert, und das Verzeichnis der Unterhaltung wird freigegeben, wenn der Bereich gelöscht wird.

Copy-on-Write ist überall, wo rift mitgeliefert wird, die einzige Umsetzung, getragen von der mitgelieferten nativen Bibliothek. Ein Dateisystem ohne Reflink, oder ein Datenverzeichnis auf einem anderen Volume als das Repo, lässt die Bereitstellung scheitern, statt auf einen Ersatz auszuweichen. git worktree ist das Backend unter Windows, wo es kein Copy-on-Write-Backend zu bauen gibt, und auf anderen Hosts ist es keine stille Abstufung. Fehlt rift auf einer Plattform, die es mitliefert, ist die Installation defekt. Der Server verweigert den Start, statt leise auszuweichen, weil ein stiller Ersatz den Defekt für immer hinter einem langsameren Pfad versteckt.

Identität und Zugangsdaten

Pro Lauf werden zwei Identitäten aufgelöst, bevor irgendein Prozess startet.

Git-Autorenschaft. Commits eines Agenten entstehen als der Agent, <Name> (agent) <agentId@agents.control-center.local> sowohl in GIT_AUTHOR_* als auch in GIT_COMMITTER_*. Er gibt nie einen Menschen vor. Der Local-Part ist die UUID des Agenten, nicht der Slug seines Namens. Der anfragende Mensch wird mit einem Trailer Co-Authored-By: genannt. Der steht in der Umgebung und wird im System-Prompt angewiesen. Eine Identität, die der Aufrufer ausdrücklich setzt, gewinnt immer gegen beide.

Forge-Identität. Die GitHub-Zugangsdaten des Laufs sind immer nur die des Brokers: ein auf das Repo begrenztes App-Installationstoken oder ersatzweise das PAT aus der Umgebung, nie das gespeicherte Token des anfragenden Mitglieds. actingUserId begrenzt den PAT-Fallback, damit ein Mitglied, das nicht der Besitzer des Servers ist, nicht die Reichweite des Servers erbt. Es legt kein persönliches Token in die Umgebung des Agenten.

Zugangsdaten des Modellanbieters lösen sich in fester Reihenfolge auf, und die Reihenfolge zählt:

eine Umgebungsüberschreibung pro Adapter,
die Umgebung des Aufrufers,
der Zugangsdatenspeicher des Servers (ein OAuth-Token wird aufgefrischt, wenn es bald abläuft),
die Prozessumgebung.

Weil die Überschreibung pro Adapter zuerst kommt, überstimmt sie stillschweigend ein Anbieterkonto, das in der App verbunden ist. Belastet ein Lauf das falsche Konto, sieh zuerst dort nach. Die Zugangsdaten der Anbieter gelten für den ganzen Host und sind über alle Arbeitsbereiche der Installation geteilt.

Das GitHub-Token des Laufs kommt vom Zugangsdaten-Broker: ein auf das Repo des Worktrees begrenztes Token, das nur lesen darf. Ein Push läuft durch das Gateway für Agentenläufe, das vor dem Weiterleiten die Regel Zu einem Remote pushen fragt, und ein Ticketing-Schlüssel wird nicht injiziert. Siehe Sandbox und Sicherheit.

Start

Der Lauf startet mit seinem Worktree als Arbeitsverzeichnis und, bei Claude Code, mit einer erzeugten MCP-Konfiguration, damit der Agent die Werkzeugoberfläche von Control Center erreicht. ACP und das bash des Harness bekommen eine bereinigte Umgebung. Claude Code über NoSandboxAdapter erbt die Umgebung des Hosts.

cc_server prüft den Host einmal beim Start und umschließt die Agentenprozesse, sobald ein Backend da ist: Seatbelt unter macOS, bubblewrap unter Linux und WSL2. Beide Nahtstellen der Ausführung werden umschlossen, denn sie teilen sich keine. Die Claude-Code-CLI geht durch den Sandbox-Port. ACP-Adapter und das Werkzeug bash des eingebauten Harness gehen durch den Sandbox-Manager. Derselbe Mechanismus setzt die geschützten Pfade des Laufs: Deine registrierten Repo-Checkouts sind in der Sandbox in jedem Modus schreibgesperrt.

Ohne Backend läuft der Lauf nicht in einer Sandbox, und nichts anderes ändert sich zum Ausgleich. Das betrifft Windows immer (keine native Umhüllung; microvm ist ein eigener Pfad für Terminals und Rigs, der nur nach einer Prüfung freigeschaltet wird) und Linux oder WSL2 ohne bwrap und socat auf dem PATH. In der Startprotokollzeile nennt der Server, in welchem Zustand er ist, und --sandbox off schaltet bewusst ab.

Zwei Lücken bleiben, auch wo die Sandbox an ist. Die prozessinternen Dateiwerkzeuge des Harness (read, write, edit, apply patch, search, find, search_files) laufen im Serverprozess, also begrenzt sie kein Profil. Ihre Grenze sind die eigene Pfadbeschränkung der Werkzeuge und die Schutzregeln. Claude Code startet mit --dangerously-skip-permissions, seine eigenen Dateiaufrufe laufen also nicht durch Control Center und seine Shell-Befehle nur durch einen Hook, der die Befehlszeile liest. Die Grenze darum ist die Betriebssystem-Sandbox.

Die übrigen Grenzen gelten auf jedem Host, mit Sandbox und ohne: der eigene Worktree des Laufs (Copy-on-Write, wo rift mitgeliefert wird; git worktree unter Windows), ein Forge-Token, das nur lesen darf, bei jedem Start vermittelt und beim Aufräumen widerrufen, Pushes, die am Gateway für Agentenläufe die Push-Regel passieren, die einheitlichen Aktions-Schutzregeln (fail-closed: eine prompt-Entscheidung ohne verbundene zuständige Person wird abgelehnt) und die Werkzeugoberfläche, die der Modus der Unterhaltung zulässt. ACP und das bash des Harness bereinigen die Umgebung weiterhin. Claude Code über NoSandboxAdapter erbt die Umgebung des Hosts.

Ereignisstrom

Der Lauf schickt eine typisierte Ereignisfolge zurück. Der Stream-Prozessor speichert sie als Nachrichtendeltas, faltet sie in Transkriptsegmente und macht daraus Nachrichtenereignisse:

Ereignis	Was es trägt
`thinking`	Reasoning-Ausgabe, direkt im Verlauf dargestellt
`text`	Sichtbare Ausgabe
`toolCall`	Ein Werkzeugaufruf, mit seiner ID und strukturierten Argumenten
`toolResult`	Das passende Ergebnis, markiert, wenn es fehlgeschlagen ist oder nur ein Teilstrom ist
`usage`	Tokenzahlen und Kosten für ein Messfenster
`error`	Ein Fehler, mit dem strukturierten Code des Adapters, wenn er einen gemeldet hat
`sandboxViolation`	Das Betriebssystem hat einen Syscall abgelehnt. Wird nur ausgegeben, wo eine Sandbox den Prozess wirklich umschließt. Siehe die Notiz oben
`debug`	Laufzeitdiagnosen (Startmarken, Schutzentscheidungen, Anstöße an den Kontrakt)
`done`	Der Lauf ist fertig

Was einen Lauf begrenzt

Es gibt bewusst nirgends eine Obergrenze für Turns. Eine feste Iterationszahl bricht legitime lange Arbeit ab (Migrationen, Aufräumen nach einem Fan-out) und fängt nichts, was die Schutzmechanismen darunter nicht schon früher fangen. Ein Lauf endet, wenn:

das Modell von sich aus stoppt;
ein Mensch ihn stoppt oder die Unterhaltung übernimmt (das pausiert den eingebauten Harness an der nächsten sauberen Turn-Grenze; ein Claude-Code-Lauf ohne sichere Grenze wird stattdessen gestoppt);
der Stille-Watchdog auslöst. Bleibt die Ausgabe über die Schwelle aus, endet die Sitzung mit einem Fehler silentRun. Vorgabe sind 15 Minuten, in den überwiegend lesenden Modi (Review und Plan) 10. Ein Agent darf den Wert zwischen 1 und 240 Minuten setzen. Der Watchdog wird scharf, sobald ein Kindprozess seine PID meldet. Er deckt damit die Claude-Code-CLI ab, nicht den eingebauten Harness, der nichts startet;
eine Kostenobergrenze greift, aber nur bei autonomen Befehlen.

Der Schutz vor Endlosschleifen beendet den Lauf nicht: drei gleiche Werkzeugaufrufe hintereinander, und die Schleife steuert den Agenten auf einen anderen Ansatz.

Ein gewöhnlicher interaktiver Turn auf dem eingebauten Harness hat damit keine Turn-Obergrenze, keine Kostenobergrenze und keinen Stille-Watchdog. Er endet, wenn das Modell stoppt oder wenn du ihn stoppst. Das ist eine bewusste Abwägung, denn die Alternativen brechen legitime lange Arbeit ab. Ein unbeaufsichtigter interaktiver Lauf ist dadurch nur durch das eigene Urteil des Modells begrenzt.

Mitten im Lauf landet eine Nachricht an einen laufenden Agenten als Steuerung in der Warteschlange und wird an der nächsten Turn-Grenze abgearbeitet. So kannst du einen Lauf nachsteuern, ohne ihn abzubrechen. Steuerung, Pausieren, Subagenten und der Abschlusskontrakt gehören zum eingebauten Harness. Claude Code hat nichts davon.

Wie ein Lauf protokolliert wird

Jede Ausführung schreibt ein AgentRunLog: Start- und Endzeit, Zusammenfassung, Tokenzahlen und geschätzte Kosten (einschließlich der aus Subagenten aufsummierten Kosten), Adapter und Modell, Prozess-ID und Logpfad, die Unterhaltung und jedes Ticket oder jeden Pipeline-Lauf, zu dem sie gehört, dazu zwei Klassifikationsfelder, in denen das meiste steckt.

Status ist grob: pending, running, completed, error.
Lebendigkeit ist die feinere Lesart: alive, productive, completed, blocked, empty, looping, failed, stalled, dead.
Fehlerfamilie fasst Ausfälle sinnvoll zusammen: transientUpstream, sandboxInfrastructure, budgetExceeded, processLost, silentRun, unknown.

completed heißt nicht „abgeliefert“

Endet ein Lauf ohne das Ergebnis, das sein Modus verlangt, bleibt der Status completed, weil der Prozess sauber beendet wurde. Das gilt für einen Planmodus-Lauf, der nie submit_plan aufgerufen hat, und für einen Orchestrierungslauf, der nie einen Vorschlag gemacht hat. Das ehrliche Signal steht in der Lebendigkeit (empty), der Fehlerfamilie (silentRun) und einer Zusammenfassung, die genau sagt, was nicht entstanden ist. Diese Zusammenfassung ist geschützt: Die Finalisierung überschreibt sie nicht mit dem letzten Geplapper des Modells.

Das ist Absicht. Den Status umzulegen würde Zustandsmaschinen von Tickets und Pipelines bewegen, die mit dem fehlenden Artefakt nichts zu tun haben. „status: completed“ allein reicht nie, um einen gelungenen Lauf zu schließen. Lies die Zusammenfassung.

Beim Schließen veröffentlicht der Lauf AgentRunCompleted, und daran hängt einiges: die Kostenaufsummierung der Pipeline, das Fortsetzen eines Pipeline-Schritts, der auf den Lauf gewartet hat, das Abschließen des zugehörigen Tickets, das Abbilden einer Orchestrierung auf einen Endzustand, die Entscheidung des Zielwächters weiterzumachen oder zu stoppen, die Prüferrolle und die Budgetauswertung nach dem Lauf. Die Präsenzliste folgt getrennt: Sie beobachtet die jüngsten Laufprotokolle, nicht das Ereignis. Die Benachrichtigung „Agent abgeschlossen“ gehört nicht dazu: Das Ereignis feuert, wenn der Prozess-Stream endet, also bevor die Antwort geschrieben ist. Die Benachrichtigung ist deshalb das MessageReceived des Turns, veröffentlicht, sobald die Nachricht gespeichert ist.

Budgets im Nachhinein

Die Durchsetzung des Budgets ist eine Reaktion, kein vorgelagertes Tor. Wenn ein Lauf endet, vergleicht die Auswertung die Ausgaben des Agenten seit Monatsbeginn mit seiner wirksamen Obergrenze (eine verknüpfte Budgetrichtlinie, falls vorhanden, sonst die eigene Monatszahl des Agenten; null heißt unbegrenzt). Beim Überschreiten der weichen Schwelle entsteht ein Warnvorfall. Ist das Budget aufgebraucht, entsteht ein harter Vorfall, und der Lebenszyklusstatus des Agenten im Organigramm wechselt auf paused. Die Ausführung nimmt von diesem Agenten weiter Arbeit an. Ein Pipeline-Trigger BudgetThresholdCrossed kann aus demselben Ereignis Folgearbeit starten.

Wiederholungsherkunft

Jedes Laufprotokoll kann eine Wiederholungsherkunft tragen: die ID des Elternlaufs, einen Versuchszähler und eine Fortsetzungszusammenfassung. Der Laufbaum der Unterhaltung zeigt die Versuchsnummer, sobald sie ungleich null ist. Ein „Erneut versuchen“ aus dem Chat ist eine neue Ausführung mit einem frischen Laufprotokoll.