Goals

Ein Goal hält Qwen Code über mehrere Turns hinweg am Arbeiten, bis eine genannte Bedingung erfüllt ist. Setze eines mit /goal <objective>, und die Session läuft von alleine weiter. Jeder Turn wird als Beleg aufgezeichnet; wenn das Modell vorschlägt, dass das Ziel erledigt oder blockiert ist, beurteilt ein unabhängiger Verifier diesen Vorschlag ausschließlich anhand der Belege. Die Session stoppt, wenn der Verifier akzeptiert, oder wenn das Goal pausiert, gelöscht oder durch ein Limit gestoppt wird.

Befehle

Das Erstellen, Bearbeiten oder Fortsetzen eines Goals erfordert einen vertrauenswürdigen Workspace (/trust). Die Headless-Nutzung wird in Headless-Modus behandelt.

Sobald ein Goal einen Turn abgerechnet hat, zeigen die Footer-Pille und jede Statuskarte, was es gegen das erlaubte Fenster verbraucht hat, als 1.2k/30.0m. Die Zahl zählt die Modellaufrufe, die das Goal in seinen eigenen Turns macht; Subagenten und die eigenen Checks des Verifiers sind nicht enthalten. Das Fenster wird von model.goalTokenBudget gesetzt; das Fortsetzen eines Goals, das sein Fenster verbraucht hat, gewährt ein weiteres oben auf das bereits verbrauchte, sodass die Zahl 30.0m/60.0m anzeigt, statt von vorne zu beginnen. Ein Goal ohne Budget zeigt nur, was es verbraucht hat. Ein Goal, das noch keinen Turn abgerechnet hat, zeigt überhaupt keine Zahlen.

Zwei weitere Fenster sind verfügbar und standardmäßig ausgeschaltet: model.goalMaxTurns begrenzt, wie viele Turns ein Goal abschließen darf, einschließlich vom Benutzer gesteuerte Goal-Turns, und model.goalMaxActiveMinutes begrenzt die Echtzeit, während es in einem laufenden Prozess aktiv bleibt, einschließlich Warte- und Leerlaufzeit zwischen Turns. Zeit, während das Goal pausiert, blockiert oder gestoppt ist, zählt nicht gegen das zweite, ebenso wenig wie Ausfallzeit über einen Neustart hinweg; ein Prozess, der lediglich suspendiert ist, wird weiterhin belastet. Welches Fenster zuerst erschöpft ist, das Goal bekommt denselben einzigen Wind-Down-Turn zur Übergabe und stoppt dann, bis du es fortsetzt, und das Fortsetzen autorisiert ein weiteres Fenster oben auf das bereits verbrauchte. Nur das erschöpfte Fenster bewegt sich; die anderen bleiben, wo sie waren, und der -1-Opt-Out nimmt ebenfalls nur eine Obergrenze von einem Goal, das sie bereits verbraucht hat. Das Zeitfenster wird zwischen Turns gelesen statt durch einen Timer erzwungen, sodass ein Goal weit über es hinauslaufen kann, bevor es stoppt: ein bereits laufender Turn wird niemals unterbrochen, und ein Fenster, das erschöpft ist während kein Turn läuft, wird erst beim Ende des nächsten Turns bemerkt. Aktive Zeit wird zwischen aufgezeichneten Übergängen gezählt, sodass Zeit in einem Turn, den ein Neustart unterbrochen hat, nicht belastet wird. Änderungen an beiden Einstellungen wirken nach einem Neustart. Beide Fenster scharfen nur bei einem Goal, das nach der Änderung erstellt wurde, daher bedeutet die Begrenzung eines bereits protokollierten Goals, es durch /goal set zu ersetzen — ein neues Goal bei Revision 1, mit zurückgesetzten Turn-, Token- und Aktivzeit-Messern und seinem Beleg-Fenster, das bei der Ersetzung beginnt, sodass Belege, die das alte Goal aufgezeichnet hat, nicht mehr zitierbar sind — oder es zu löschen und von vorne anzufangen. Ein Fortsetzen oder Bearbeiten fügt niemals eine Obergrenze hinzu, die bei der Erstellung nicht scharf gemacht wurde.

Jeder Turn, den die Session selbstständig ausführt, berichtet, was das Goal bisher verbraucht hat, wie viele Turns dahinterliegen und — außer das Goal läuft unbegrenzt — das erlaubte Fenster. Jeder solcher Turn außer der letzten Wind-Down-Übergabe trägt auch ständige Anweisungen, den Workspace erneut zu prüfen, statt den Berichten früherer Turns zu vertrauen, auf den Endzustand hinzuarbeiten, den das Ziel verlangt, etwas anderes zu tun, wenn der vorherige Turn nichts geändert hat (ab dem zweiten Turn, sobald es einen vorherigen Turn zu beurteilen gibt), und jede Anforderung gegen zitierbare Belege zu prüfen, bevor vorgeschlagen wird, dass das Goal erledigt ist.

Ein langes Goal komprimiert periodisch die aufgezeichneten Belege mit einem Side-Model-Check in Checkpoint-Claims, damit spätere Turns und der Verifier sie noch zitieren können. Der Check wird durch model.goalCheckpointTimeoutSeconds begrenzt, standardmäßig 180 Sekunden. Wenn seine Claims das aggregierte Byte-Budget überschreiten oder ein Claim das Zeichenlimit pro Claim überschreitet, macht er einen korrektiven Modell-Call und beide Calls teilen sich diese Obergrenze. Ein Check, der nicht rechtzeitig fertig wird, wird als inconclusive aufgegeben; er zählt nur dann zum Checkpoint-Stall-Limit, wenn das Beleg-Fenster überlaufen ist, während ein nicht überlaufender Check die Streak beibehält und in einem späteren Turn erneut versucht wird. Die Calls werden gestreamt, sodass der Transport-Timeout pro Anfrage nur Connect und erste Antwort begrenzt, und die Obergrenze selbst stoppt bei der 15-Minuten-Lebensdauer-Kappe der Stream-Guards, weil jenseits davon der Guard und nicht die Einstellung den Check beendet. Dieses 15-Minuten-Limit der Einstellung ist fest, und das Anheben der eigenen Kappe des Stream-Guards hebt es nicht an.

Ein Goal unterbrechen

Das Abbrechen eines Goal-Turns pausiert das Goal. Drücke Esc, während das Modell antwortet oder seine Tools noch laufen, und der Turn stoppt, das Goal wechselt zu paused, und die Karte und /goal sagen beide, warum es gestoppt wurde. Nichts läuft weiter, bis du /goal resume ausführst.

Eine Nachricht zu tippen, während ein Goal aktiv ist, pausiert es nicht. Deine Nachricht läuft als der nächste Goal-Turn, also nutze sie, um die Arbeit zu steuern; nutze /goal pause oder /goal clear, um es zu stoppen.

Jede Pause gibt ihren Grund an: dass du es unterbrochen hast, dass du /goal pause ausgeführt hast, dass das Session-Token-Limit die nächste Modellanfrage blockiert hat, dass der Turn fehlgeschlagen ist oder dass drei Turns hintereinander nichts aufgezeichnet haben, was der Verifier beurteilen könnte, und kein Vorschlag — Goal-Bookkeeping-Reads (get_goal, update_goal) zählen nicht als Fortschritt. Ein durch ein Limit gestopptes Goal behält stattdessen den Grund für dieses Limit.

Wie ein Goal beurteilt wird

Der Verifier führt niemals selbst Befehle aus oder liest Dateien. Er sieht nur, was bereits im Transkript steht:

• Sichtbare Assistant-Ausgaben und Tool-Ergebnisse zählen als Belege. Der Zieltext, deine Prompts und die versteckten Reasoning-Ausgaben des Modells nicht.
• Gedruckter Text beweist nur, dass Text gedruckt wurde. Eine Behauptung, dass Tests bestanden, eine Datei geändert oder ein Remote aktualisiert wurde, benötigt das entsprechende Tool-Ergebnis im Transkript.
• Eine Behauptung, dass du etwas bestätigt, ausgewählt oder genehmigt hast, benötigt eine echte Nachricht von dir; der Verifier weist Vorschläge zurück, die das voraussetzen.
• Wenn Belege fehlen, lautet das Urteil “noch nicht”, nicht “erledigt”. Eine Bedingung, die niemand belegen kann, hält die Schleife am Laufen, bis ein Limit sie stoppt.

Das Ziel muss den Agenten also dazu bringen, Belege zu produzieren: den genannten Check ausführen und die entscheidende Ausgabe zeigen.

Ein gutes Ziel formulieren

Setze diese Bestandteile in das Ziel, in dieser Reihenfolge:

Halte es bei einem Ziel. /goal set und /goal edit akzeptieren beliebige Länge, aber bleibe ungefähr unter 1.200 Zeichen: das Ziel wird bei jedem Goal-Turn erneut gesendet. Ein Ziel, das das Modell über propose_goal vorschlägt, ist auf 1.500 Zeichen begrenzt. Beide Befehle klappen Zeilenumbrüche zu Leerzeichen zusammen, also nummeriere die Elemente, statt dich auf Zeilenumbrüche zu verlassen.

Budget ist eine Anweisung an das Modell, wann es aufgeben und einen Blocker melden soll; das Modell kann sie befolgen oder auch nicht. Um die Runtime selbst bei einer Turn-Anzahl oder Dauer stoppen zu lassen, setze model.goalMaxTurns oder model.goalMaxActiveMinutes. Beides in das Ziel zu schreiben konfiguriert diese nicht und ändert nicht das Token-Budget des Goals.

/goal-draft schreibt es für dich

/goal-draft <was erledigt werden soll> ist ein gebündelter Skill, der das oben Beschriebene für dich erledigt. Er liest nur genug vom Workspace, um den Umfang und die echten Verifizierungsbefehle zu ermitteln, ohne Tests auszuführen, zu bauen, Abhängigkeiten zu installieren oder Services zu starten. Er stellt höchstens eine Runde Fragen, wenn wesentliche Entscheidungen unklar sind, und schreibt dann ein kompaktes Ziel, normalerweise mit 3–5 Completion-Checks (weniger, wenn genug). Explizite Anforderungen werden beibehalten; er fügt keine Checks hinzu, nur um eine Anzahl zu erreichen.

Für ein Audit bedeutet Completion, die vereinbarten Szenarien abzudecken und Belege zu melden, einschließlich Reproduktionsschritte für bestätigte Defekte. Keine Defekte zu finden ist ein gültiges Ergebnis. Der Draft sollte keine Mindestanzahl an Szenarien, Belegdateien, Explorationsrunden oder Defekten erfinden.

Wenn ein Erfolgskriterium, Befehl, Eingabepfad oder eine wesentliche Entscheidung nicht ermittelt werden kann, gibt der Skill einen Draft zurück, der mit “Needs clarification” und <TODO: …>-Elementen markiert ist. Er bietet diesen Draft nicht zur Genehmigung an und gibt keinen ausführbaren /goal set- oder /goal edit-Befehl aus. Unwesentliche Defaults sind mit [ASSUMPTION] markiert; sie ersetzen keine fehlenden Erfolgskriterien.

Sobald das Ziel fertig ist, kann eine interaktive Terminal- oder WebShell-Session den unten beschriebenen propose_goal-Genehmigungsdialog anzeigen. Clients ohne Goal-Proposal-Unterstützung, Headless-Runs, Sessions mit deaktiviertem Tool und Sessions mit einem aktiven Goal erhalten stattdessen einen Befehl zum manuellen Ausführen. Die Übergabe sagt, dass der Draft nicht angewendet wurde. Der Skill beginnt niemals die Arbeit selbst, und ohne deine Genehmigung wird nichts gesetzt.

Übergib ein bestehendes Ziel, um es zu straffen: /goal-draft all tests pass and the lint is clean. Für ein aktives Goal erzeugt eine explizite Anfrage zum Straffen /goal edit; eine Ersetzung verwendet /goal set. Wenn die beabsichtigte Operation unklar ist, beinhaltet der Skill diese Wahl in seiner einzigen Fragerunde.

Ein vom Modell vorgeschlagenes Goal genehmigen

In einer interaktiven Terminal- oder WebShell-Session mit angehängtem Client hat das Modell ein propose_goal-Tool. Wenn /goal-draft fertig ist oder wenn du ein Ergebnis anforderst, das sich über mehrere Turns erstreckt, kann es das Ziel vorschlagen, anstatt eine /goal set …-Zeile zum Kopieren auszugeben. Der Vorschlag erscheint als Genehmigungsdialog, der das vollständige Ziel anzeigt. Ihn zu genehmigen setzt das Goal genau wie /goal set, sobald der aktuelle Turn endet (das Modell bestätigt und stoppt; der erste Goal-Turn startet dann automatisch), und ihn abzulehnen setzt nichts — das Modell sieht nur, dass der Tool-Aufruf nicht erlaubt wurde, und seine Anweisungen sagen ihm, nicht nach dem Grund zu fragen und nicht dasselbe Ziel erneut vorzuschlagen. Die Genehmigung ist an den Turn gebunden, der sie angefordert hat: Wird dieser Turn abgebrochen oder erreicht sonst nicht sein Ende, wird die Genehmigung verworfen, statt unter einer späteren Nachricht oder einem automatisierten Turn angewendet zu werden. Keine Berechtigungsregel oder Genehmigungsmodus (einschließlich YOLO) überspringt diesen Dialog, und das Tool verweigert die Ausführung, während ein anderes Goal aktiv ist, im Plan-Modus und in nicht vertrauenswürdigen Ordnern; Subagenten wird es niemals angeboten. WebShell nutzt sein bestehendes Allow/Reject-Berechtigungspanel. Ein gestopptes Goal kann nur ersetzt werden, wenn es noch der zur Genehmigung angezeigten Version entspricht; Änderungen machen den Vorschlag ungültig. Headless-Runs, WebShell-Channel-Deliveries und automatische Turns sowie ACP-Clients ohne die erforderliche Genehmigungs- und Turn-Lifecycle-Unterstützung behalten die gedruckte /goal set-Übergabe.

Schalte es aus mit goals.modelProposed: "disabled" in deinen Benutzer-Einstellungen. Da die Einstellung entscheidet, ob das Modell dich fragen darf, eine autonome Schleife zu starten, wird sie nur aus Benutzer- und System-Scope berücksichtigt; ein Wert in einer Workspace-.qwen/settings.json wird mit einer Warnung ignoriert.

Der Skill ist angewiesen, schreibgeschützt zu arbeiten, und nur seine nicht-mutierenden Tools werden automatisch genehmigt (get_goal, read_file, glob, grep_search). ask_user_question ist absichtlich nicht automatisch genehmigt, sodass sein Fragedialog angezeigt wird, bevor der Skill aus deinen Antworten entwirft. Wie bei anderen gebündelten Skills überschreibt ein Projekt- oder persönlicher Skill namens goal-draft ihn, und skills.disabled kann ihn ausschalten. Siehe Skills, wie gebündelte Skills entdeckt werden.