DEV Community

Cover image for /ziel Befehl: Codex und Claude Code als autonome 24/7 Agenten ausführen
Emre Demir
Emre Demir

Posted on • Originally published at apidog.com

/ziel Befehl: Codex und Claude Code als autonome 24/7 Agenten ausführen

Jedes große KI-Labor hat in den letzten sechs Wochen dieselbe primitive Funktion ausgeliefert: Anthropic hat /goal zu Claude Code hinzugefügt, OpenAI hat es in die Codex CLI und die Codex Desktop-App integriert, Nous Research hat es in Hermes eingebaut. Die Namensgebung ist bewusst konsistent: Die Branche einigt sich auf eine gemeinsame Schnittstelle für Agenten, die in einer geschlossenen Schleife arbeiten, bis ein messbarer Endzustand erreicht ist.

Probieren Sie Apidog noch heute aus

Wenn Sie bisher den manuellen Ablauf „Genehmigen, Prompt senden, Agenten zum Fortfahren auffordern, wiederholen“ genutzt haben, ist /goal der Slash-Befehl, der diese Schleife automatisiert. Sie definieren ein Ziel, der Agent arbeitet darauf hin und meldet sich erst zurück, wenn das Ziel erreicht ist, eine Grenze ausgelöst wurde oder das Budget erschöpft ist.

Dieser Leitfaden richtet sich an Entwickler und API-Builder. Sie lernen, was /goal unter der Haube macht, wie Sie es in Codex und Claude Code einrichten, wie Sie robuste Ziel-Prompts schreiben und wie Sie den Workflow mit Apidog in API-Entwicklung und Tests einbinden.

Wenn Sie die API-Beispiele später nachvollziehen möchten, können Sie Apidog herunterladen.

Was /goal tatsächlich tut

Kurz gesagt: /goal lässt einen KI-Agenten eine Aufgabe iterativ bearbeiten, bis eine Abbruchbedingung erfüllt ist.

Der Ablauf sieht typischerweise so aus:

  1. Sie definieren ein Ziel.
  2. Das Hauptmodell plant und führt Arbeitsschritte aus.
  3. Ein kleineres Validator-Modell prüft nach jedem Schritt: „Ist das Ziel erreicht?“
  4. Falls nein, läuft der Agent weiter.
  5. Falls ja, beendet der Agent die Schleife und meldet das Ergebnis.

Der Unterschied zur normalen Agentennutzung:

  • Ohne /goal: Sie sind die Schleife. Sie lesen Ausgaben, prüfen Zwischenergebnisse, geben neue Anweisungen und genehmigen Tool-Aufrufe.
  • Mit /goal: Der Agent besitzt die Schleife. Er plant, führt aus, validiert sich selbst und stoppt erst bei Erfolg, Fehler, Grenze oder Budgetende.

Beispiel:

/goal create a landing page
Enter fullscreen mode Exit fullscreen mode

Ein solcher Befehl kann Recherche, Gerüstbau, Styling, Debugging und Vorschau in einem kontinuierlichen Durchlauf auslösen. Entscheidend ist aber: Je messbarer das Ziel, desto zuverlässiger wird der Lauf.

Warum /goal plötzlich überall ist

Lang laufende Agentenaufgaben scheitern häufig an zwei Punkten:

  1. Drift: Das Modell entfernt sich vom ursprünglichen Ziel und produziert selbstbewusste, aber falsche Ergebnisse.
  2. Babysitting: Der Benutzer muss jede Iteration überwachen, obwohl der Agent eigentlich autonom arbeiten soll.

Ein Validator-Modell reduziert beide Probleme. Es prüft bei jeder Iteration gegen ein festes Ziel und gibt der Schleife eine klare Abbruchbedingung.

Der praktische Nutzen entsteht vor allem dann, wenn der Endzustand maschinell überprüfbar ist:

  • Tests laufen erfolgreich durch.
  • Ein Build beendet sich mit Exit-Code 0.
  • Ein API-Endpunkt gibt 200 zurück.
  • Ein Antwortschema entspricht der Spezifikation.
  • Eine Datei enthält definierte Abschnitte oder Beispiele.

/goal in Codex einrichten

Die Codex CLI bietet die meiste Kontrolle.

1. Ziele in Codex Desktop aktivieren

Öffnen Sie Codex Desktop und gehen Sie zu:

Einstellungen → Konfiguration
Enter fullscreen mode Exit fullscreen mode

Setzen Sie dort:

goals = true
Enter fullscreen mode Exit fullscreen mode

Die CLI übernimmt diese Einstellung.

2. CLI im Full-Auto-Modus starten

Damit Sie nicht bei jeder Iteration Genehmigungsaufforderungen sehen:

codex --approval-mode full-auto
Enter fullscreen mode Exit fullscreen mode

3. Ziel setzen 

/goal [Ihr Ziel hier]
Enter fullscreen mode Exit fullscreen mode

Codex bestätigt, dass das Ziel registriert wurde, und beginnt mit der Ausführung.

Codex CLI mit einem registrierten /goal Befehl

Wenn Sie lieber mit einer Oberfläche arbeiten, starten Sie in Codex Desktop statt in der CLI. Die Funktionalität ist ähnlich, aber Sie können Ziele einfacher anhalten, löschen und die Token-Nutzung überwachen.

/goal in Claude Code einrichten

Claude Code funktioniert ähnlich:

  1. Claude Code CLI starten.
  2. /goal eingeben.
  3. Aufgabenbeschreibung ergänzen.

Beispiel:

/goal alle fehlschlagenden Tests beheben, bis npm test erfolgreich mit Exit-Code 0 beendet wird
Enter fullscreen mode Exit fullscreen mode

Die offizielle Dokumentation finden Sie auf der Claude Code Dokumentationsseite.

Claude Code CLI mit dem /goal Befehl und einer Live-Token-Anzeige

Wenn beim Start von Claude Code Konfigurationsfehler auftreten, hilft der Leitfaden zur Behebung ungültiger custom3p Enterprise-Konfigurationsfehler. Für Multi-Agenten-Workflows mit Claude Code und /goal siehe die Analyse zu Ruflo, einer Multi-Agenten-Schicht über Claude Code.

Wichtig: Claude Code zeigt bei /goal eine Live-Token-Anzahl und einen Fortschrittsbalken. Beobachten Sie nicht nur die Textausgabe. Wenn viele Tokens verbraucht werden, aber kein Fortschritt sichtbar ist, konvergiert der Validator wahrscheinlich nicht. Nutzen Sie dann:

/pause
Enter fullscreen mode Exit fullscreen mode

oder:

/goal clear
Enter fullscreen mode Exit fullscreen mode

Die Prompt-Struktur, die funktioniert

Die Syntax ist einfach. Die Herausforderung ist, einen Prompt zu schreiben, der nicht in einer Endlosschleife landet.

Ein guter /goal-Prompt enthält drei Teile:

  1. Aufgabe: Was soll erledigt werden?
  2. Messbarer Endzustand: Woran erkennt der Validator „fertig“?
  3. Einschränkungen: Welche Grenzen darf der Agent nicht überschreiten?

Grundform:

/goal [Aufgabe erledigen] bis [messbarer Endzustand] ohne [Einschränkungen]
Enter fullscreen mode Exit fullscreen mode

Beispiel:

/goal alle fehlschlagenden Tests beheben, bis npm test mit Exit-Code 0 beendet wird, ohne Dateien außerhalb des Verzeichnisses /auth zu ändern
Enter fullscreen mode Exit fullscreen mode

Warum das gut funktioniert:

  • npm test liefert ein klares Signal.
  • Exit-Code 0 ist eindeutig.
  • /auth ist eine überprüfbare Grenze.
  • Der Agent kann Erfolg nicht einfach behaupten.

Schwaches Gegenbeispiel:

/goal diese Benutzeroberfläche moderner machen
Enter fullscreen mode Exit fullscreen mode

Besser:

/goal die Benutzeroberfläche überarbeiten, bis der Lighthouse-Accessibility-Score mindestens 90 beträgt und keine bestehenden E2E-Tests fehlschlagen
Enter fullscreen mode Exit fullscreen mode

Struktur für längere Aufgaben

Für größere Ziele lohnt sich ein strukturierter Prompt:

/goal
Ziel: [Einzeiliges Ziel]

Erfolgskriterien:
  - [Messbares Kriterium 1]
  - [Messbares Kriterium 2]
  - [Messbares Kriterium 3]

Einschränkungen:
  - [Grenze 1]
  - [Grenze 2]

Kontext:
  - [Relevante Dateien]
  - [Relevante Befehle]
  - [Spezifikationen oder API-Verträge]
Enter fullscreen mode Exit fullscreen mode

Beispiel für ein Backend-Feature:

/goal
Ziel: Implementiere den POST /auth/login Endpunkt.

Erfolgskriterien:
  - npm test beendet sich mit Exit-Code 0
  - Der Endpunkt gibt bei gültigen Credentials HTTP 200 zurück
  - Der Endpunkt gibt bei ungültigen Credentials HTTP 401 zurück
  - Die Response entspricht dem vorhandenen OpenAPI-Schema

Einschränkungen:
  - Keine Änderungen außerhalb von /src/auth und /tests/auth
  - Keine Änderung am bestehenden User-Modell
  - Keine neuen Produktionsabhängigkeiten ohne Begründung

Kontext:
  - OpenAPI-Spezifikation: ./openapi.yaml
  - Tests: ./tests/auth/login.test.ts
  - Startbefehl: npm run dev
Enter fullscreen mode Exit fullscreen mode

Dieses Format gibt dem Validator konkrete Prüfpunkte.

Beispiele, die Sie direkt übernehmen können

Forschung 

/goal alle öffentlichen Benchmarks für Claude Opus 4.7 sammeln, die seit April 2026 veröffentlicht wurden, Quellen speichern und eine nach Datum sortierte Markdown-Tabelle erstellen, bis die Tabelle mindestens 10 verschiedene Benchmarks abdeckt
Enter fullscreen mode Exit fullscreen mode

Repo-Wartung 

/goal toten Code, ungenutzte Abhängigkeiten und veraltete Dateien in diesem Repo finden, dann einen PR-Beschreibungsvorschlag mit sicheren Entfernungen erstellen, bis jeder Punkt eine Begründung hat
Enter fullscreen mode Exit fullscreen mode

Dokumentation 

/goal README.md so umschreiben, dass ein neuer Mitwirkender das Projekt installieren, ausführen, testen und verstehen kann, bis jeder dieser vier Schritte einen funktionierenden Befehl und eine erwartete Ausgabe hat
Enter fullscreen mode Exit fullscreen mode

Feature-Arbeit 

/goal einen Dark-/Light-Theme-Umschalter hinzufügen, die Auswahl in localStorage speichern, Stile für beide Themes aktualisieren und im Browser überprüfen, bis der Umschalter ohne Seitenneuladen funktioniert und einen Refresh überlebt
Enter fullscreen mode Exit fullscreen mode

Das gemeinsame Muster: Jedes Ziel enthält einen überprüfbaren Endzustand.

/goal mit API-Entwicklungs-Workflows kombinieren

API-Entwicklung eignet sich besonders gut für /goal, weil der Endzustand meist eindeutig testbar ist:

  • Endpunkt erreichbar
  • Statuscode korrekt
  • Response-Schema korrekt
  • Fehlerfälle abgedeckt
  • Vertrag dokumentiert
  • Tests grün

Ein praxistauglicher Workflow:

1. Vertrag zuerst in Apidog entwerfen

Definieren Sie in Apidog:

  • Endpunkt
  • Request-Schema
  • Response-Schema
  • Beispiel-Payloads
  • Fehlerfälle
  • Testfälle

Dieser Vertrag wird zur Quelle der Wahrheit.

2. Spezifikation exportieren

Exportieren Sie die OpenAPI-3.x-Spezifikation und legen Sie sie im Repository ab, zum Beispiel:

./openapi.yaml
Enter fullscreen mode Exit fullscreen mode

3. /goal mit Spezifikation und Tests starten

Beispiel:

/goal
Ziel: Implementiere den in openapi.yaml definierten POST /orders Endpunkt.

Erfolgskriterien:
  - Der Service startet mit npm run dev
  - Alle relevanten Apidog-Testfälle bestehen
  - Die Response entspricht dem OpenAPI-Schema
  - npm test beendet sich mit Exit-Code 0

Einschränkungen:
  - Keine Änderungen an bestehenden öffentlichen API-Feldern
  - Keine Breaking Changes an anderen Endpunkten

Kontext:
  - OpenAPI-Spezifikation: ./openapi.yaml
  - Apidog-Testfälle sind die Quelle der Wahrheit
Enter fullscreen mode Exit fullscreen mode

4. Validator gegen den Test-Runner prüfen lassen

Der Agent sollte nicht selbst definieren, wann die API „fertig“ ist. Lassen Sie ihn gegen vorhandene Testfälle laufen. Bei jeder Iteration prüft der Validator den Test-Runner und beendet die Schleife erst, wenn die Tests grün sind.

Das ist besser, als den Agenten eigene Tests erfinden zu lassen. Der Vertrag steht bereits fest, und der Agent muss gegen diesen Vertrag implementieren.

Wenn Sie Apidog noch nicht genutzt haben: Die Plattform kombiniert API-Design, Mocking, Testing und Dokumentation. Das ist für /goal nützlich, weil der Validator idealerweise nur einen Befehl ausführen muss, um den Status zu prüfen.

Weiterführend:

Praktische Tipps für /goal im Einsatz

Ein Ziel nach dem anderen

Codex und Claude Code arbeiten jeweils mit einem aktiven Ziel. Löschen Sie alte Ziele vor dem nächsten Lauf:

/goal clear
Enter fullscreen mode Exit fullscreen mode

Erst planen, dann ausführen

Ein guter Ablauf:

/plan
Enter fullscreen mode Exit fullscreen mode

Plan prüfen, dann:

/goal [Plan umsetzen, bis messbare Kriterien erfüllt sind]
Enter fullscreen mode Exit fullscreen mode

Das reduziert unnötige Iterationen.

Fortschritt in einer Datei speichern lassen

Weisen Sie den Agenten an, eine Datei zu pflegen:

progress.md
Enter fullscreen mode Exit fullscreen mode

Beispiel:

/goal alle fehlschlagenden Tests beheben, bis npm test erfolgreich ist, und währenddessen progress.md mit erledigten Schritten, offenen Problemen und ausgeführten Befehlen aktualisieren
Enter fullscreen mode Exit fullscreen mode

Das gibt Ihnen einen auditierbaren Verlauf und dem Agenten stabileren Kontext.

Ziel vom Modell formulieren lassen

Wenn Sie nur eine grobe Idee haben, starten Sie mit einem normalen Prompt:

Formuliere daraus einen robusten /goal-Prompt mit messbaren Erfolgskriterien und klaren Einschränkungen:
[meine Idee]
Enter fullscreen mode Exit fullscreen mode

Danach verwenden Sie die generierte Version als /goal.

Validator-Signal verbessern statt erneut laufen lassen

Wenn ein Ziel nicht endet, ist meist nicht der Agent das Problem, sondern das Erfolgskriterium.

Schlecht:

bis die API gut funktioniert
Enter fullscreen mode Exit fullscreen mode

Besser:

bis alle Tests in tests/api erfolgreich sind und GET /health HTTP 200 zurückgibt
Enter fullscreen mode Exit fullscreen mode

Wann /goal nicht gut funktioniert

/goal ist nicht für jede Aufgabe geeignet.

Hohe Token-Kosten

Lang laufende Schleifen verbrauchen mehr Tokens als ein normaler Prompt. Setzen Sie ein Budget und pausieren Sie bei Bedarf.

/pause
Enter fullscreen mode Exit fullscreen mode

Kein klares Validierungssignal

Aufgaben wie UX-Geschmack, Tonalität oder „mach es schöner“ sind schwer validierbar. Verwenden Sie /goal nur, wenn Sie klare Kriterien definieren können.

Externe Nebeneffekte

Seien Sie vorsichtig bei Zielen, die Folgendes auslösen könnten:

  • E-Mails senden
  • Zahlungen ausführen
  • Produktions-APIs aufrufen
  • Daten löschen
  • Benutzerkonten verändern

Definieren Sie harte Grenzen und nutzen Sie nach Möglichkeit Mock- oder Staging-Umgebungen.

Wenn Sie Zugriffskontrolle und Abrechnung für KI-Agenten in API-Teams betrachten, hilft der Artikel zur GitHub Copilot Nutzungs- und Abrechnungs-API für Teams.

Veralteter Kontext

Wenn sich die Codebasis während eines langen Laufs ändert, kann der Agent auf veraltetem Kontext weiterarbeiten. In solchen Fällen besser pausieren, Kontext aktualisieren und neu starten.

Was /goal für KI-gestützte Entwicklung bedeutet

/goal verschiebt KI-Entwicklung von „Autovervollständigung“ zu „delegierter Arbeit mit überprüfbaren Kriterien“.

Ihre Aufgabe als Entwickler wird dadurch weniger:

  • jede Codezeile selbst schreiben
  • jede Iteration manuell überwachen
  • den Agenten ständig weiter prompten

Und mehr:

  • Erfolgskriterien definieren
  • Einschränkungen formulieren
  • Tests und Verträge bereitstellen
  • Ergebnisse prüfen

Teams mit klaren Spezifikationen, CI und API-Verträgen profitieren am meisten. Wenn Ihre API ein OpenAPI-Dokument und eine Testsuite hat, kann ein /goal-Agent gegen echte Kriterien arbeiten. Wenn die API nur implizit im Kopf eines Entwicklers existiert, fehlt dem Validator das Signal.

Hier werden API-Plattformen zur Infrastruktur für KI-Workflows. Apidog unterstützt Design-First API Development. Das wird besonders nützlich, wenn ein Agent die Spezifikation lesen und seine Implementierung gegen Ihre Testfälle prüfen kann.

Wenn Sie diesen Contract-First-Workflow ausprobieren möchten, können Sie Apidog herunterladen.

FAQ

Funktioniert /goal in der Codex Web-App?

Ja. /goal funktioniert in der Codex CLI, Codex Desktop, der Codex App und der Claude Code CLI. Hermes unterstützt ebenfalls denselben Befehl.

Wie unterscheidet sich /goal von einem normalen Prompt?

Ein normaler Prompt läuft einmal und stoppt. /goal läuft in einer geschlossenen Schleife. Ein Validator-Modell prüft nach jedem Schritt, ob die Abbruchbedingung erfüllt ist.

Kann der Agent meine Einschränkungen verletzen?

Der Validator prüft Einschränkungen bei jeder Iteration. In der Praxis hängt die Zuverlässigkeit davon ab, wie konkret Sie formulieren.

Gut:

ohne Dateien außerhalb von /auth zu ändern
Enter fullscreen mode Exit fullscreen mode

Schlecht:

ohne etwas kaputt zu machen
Enter fullscreen mode Exit fullscreen mode

Kostet /goal mehr Tokens?

Ja. Rechnen Sie mit höherem Token-Verbrauch, weil der Agent mehrere Iterationen durchläuft und zusätzlich validiert wird. Setzen Sie Budgets und nutzen Sie /pause, wenn ein Lauf nicht konvergiert.

Was ist, wenn ich gegen eine echte API testen möchte?

Nutzen Sie ein Tool wie Apidog, um den API-Vertrag und echte Testfälle festzulegen. Der Agent kann gegen diese Tests iterieren, statt Erfolg selbst zu behaupten.

Wenn Sie einen Claude-gestützten Dienst mit begrenztem Budget aufsetzen möchten, siehe den Leitfaden zur kostenlosen Claude API.

Top comments (0)