Commande /goal : Automatisation Codex et Claude en Agents Autonomes 24/7

Chaque grand laboratoire d'IA a livré la même primitive au cours des six dernières semaines. Anthropic a ajouté /goal à Claude Code. OpenAI l'a intégré dans Codex CLI et l'application de bureau Codex. Nous Research l'a câblé dans Hermes. La dénomination est cohérente à dessein ; c'est l'industrie qui s'accorde sur une interface partagée pour une seule chose : un agent qui fonctionne en boucle fermée jusqu'à ce qu'un état final mesurable soit atteint, sans vous demander d'autorisation à chaque étape.

Si vous avez effectué la danse manuelle « approuver, envoyer l'invite, dire à l'agent de continuer, répéter », /goal est la commande slash qui y met fin. Vous donnez une cible à l'agent, il travaille en fonction de cette cible, et il revient lorsque la cible est atteinte.

Ce guide est destiné aux développeurs et aux créateurs d'API. Nous aborderons ce que /goal fait réellement en coulisses, comment le configurer dans Codex et Claude Code, une structure d'invite qui produit des résultats concrets au lieu de boucles infinies, et comment intégrer le tout dans votre flux de travail API en utilisant Apidog.

Téléchargez Apidog gratuitement si vous souhaitez suivre les exemples d'API plus tard dans ce guide.

Ce que /goal fait réellement

En une phrase : /goal permet à un agent IA de boucler sur une tâche jusqu'à ce qu'une condition d'arrêt se déclenche, sans vous demander d'approbation à chaque aller-retour.

Le mécanisme sous-jacent est simple. Un petit modèle de validation rapide s'exécute après chaque étape effectuée par l'agent principal et répond à une question : « L'objectif a-t-il été atteint ? » Si non, le modèle principal continue. Si oui, la boucle se ferme et l'agent fait son rapport. C'est le même schéma que la « boucle Ralph » popularisée début 2026, sauf qu'elle est désormais livrée comme une commande de première classe dans les outils officiels.

Le contraste avec l'utilisation normale d'un agent :

• Sans /goal : vous êtes la boucle. Vous lisez la sortie, décidez si elle est correcte, lancez l'étape suivante, approuvez l'appel d'un outil, et ainsi de suite. Chaque itération vous coûte de l'attention.
• Avec /goal : l'agent gère la boucle. Il planifie, exécute, s'auto-valide et ne se manifeste que lorsqu'il a terminé, atteint une contrainte ou épuisé son budget.

Un exemple concret : dire à Claude Code /goal create a landing page déclenche la recherche, l'échafaudage, le style, le débogage et une prévisualisation finale, le tout en une seule exécution continue. Vous vous éloignez, revenez, et soit vous le livrez, soit vous itérez.

Pourquoi c'est soudainement partout

La raison pour laquelle /goal est déployé chez tous les fournisseurs en ce moment est que les tâches d'agent à long terme échouaient de deux manières prévisibles :

1. Dérive. Sans un validateur vérifiant par rapport à l'objectif initial, les modèles s'éloignaient et produisaient des résultats erronés mais confiants.
2. Surveillance constante. Même lorsque le modèle pouvait faire le travail, les utilisateurs devaient chaperonner chaque itération, ce qui allait à l'encontre du principe d'un agent.

Un deuxième modèle de validateur corrige les deux problèmes. Il est peu coûteux (petit modèle, invite ciblée) et il donne à la boucle une condition d'arrêt stricte. C'est tout le truc. Une fois que les laboratoires ont réalisé que ce modèle fonctionnait, ils l'ont tous livré sous le même nom à quelques semaines d'intervalle.

Configurer /goal dans Codex

L'interface en ligne de commande (CLI) de Codex vous offre le plus de contrôle. Voici la configuration minimale :

1. Activer les objectifs dans l'application de bureau : ouvrez Codex desktop, allez dans Paramètres → Configuration, et définissez goals = true. La CLI hérite de ce paramètre.
2. Lancez la CLI en mode entièrement automatique pour ne plus voir les invites d'approbation :

codex --approval-mode full-auto

3. Définissez un objectif :

/goal [your goal here]

C'est tout. Codex affichera une confirmation que l'objectif est enregistré, puis commencera à s'exécuter.

Si vous n'êtes pas technique, commencez dans l'application de bureau Codex plutôt que dans la CLI. La fonctionnalité est la même, mais vous disposez d'une interface utilisateur pour mettre en pause, effacer et surveiller l'utilisation des jetons.

Configurer /goal dans Claude Code

La CLI de Claude Code fonctionne presque de la même manière. Lancez la CLI, tapez /goal, puis la description de la tâche. La documentation officielle se trouve sur le site de documentation de Claude Code.

Si vous rencontrez des erreurs de configuration ou d'installation lors du lancement de Claude Code, la solution pour la configuration d'entreprise custom3p invalide couvre le mode de défaillance le plus courant. Pour un examen plus approfondi de la façon de piloter Claude Code avec des flux de travail multi-agents et /goal, consultez notre analyse de Ruflo, une couche multi-agents au-dessus de Claude Code.

Un conseil facile à manquer : /goal vous montre le nombre de jetons en direct et une barre de progression pour la tâche en cours dans Claude Code. Surveillez le nombre de jetons, pas seulement la sortie. Un objectif qui brûle des jetons sans progression est un signe que le validateur ne parvient pas à converger, et vous devriez appuyer sur /pause ou /goal clear.

La structure d'invite qui fonctionne réellement

La syntaxe de /goal est triviale. La partie difficile est d'écrire une invite qui produit un résultat utilisable au lieu d'un agent qui tourne pendant deux heures et vous donne quelque chose de subtilement faux.

Chaque invite /goal efficace comporte trois composants :

1. Le travail : ce que vous voulez faire, en une ligne.
2. L'état final mesurable : à quoi ressemble « terminé », sous une forme que le validateur peut vérifier.
3. Les contraintes : règles qui doivent être respectées tout au long.

Le squelette :

/goal [do the work] until [measurable end state] without [constraints that must hold]

Un exemple réel pour une tâche de codage :

/goal fix every failing test until npm test exits 0 without modifying any file outside the /auth directory

L'état final est vérifiable (code de sortie npm test), et la contrainte est une limite stricte que le validateur peut faire respecter à chaque itération. L'agent ne peut pas simuler l'achèvement car le validateur exécute la commande de test.

Pour les tâches ambiguës (« rendre cette interface utilisateur moderne »), /goal fonctionne mal car l'état final n'est pas mesurable. Soit réécrivez l'objectif pour qu'il soit mesurable (« jusqu'à ce que le score d'accessibilité Lighthouse soit de 90+ »), soit restez avec une invite normale.

Structure avancée pour les tâches plus longues

Pour les objectifs plus importants, développez le squelette en quatre blocs :

/goal
Objective: [one-line goal]
Success criteria:
  - [measurable criterion 1]
  - [measurable criterion 2]
Constraints:
  - [boundary 1]
  - [boundary 2]
Context:
  - [files, repos, API keys the agent should know about]

Ce format donne au validateur des éléments concrets à vérifier à chaque itération de la boucle. Sans critères de succès, le validateur se rabat sur une correspondance sémantique floue, ce qui entraîne la dérive.

Exemples à reprendre

/goal n'est pas seulement pour écrire du code. Quelques schémas qui fonctionnent bien :

Recherche

/goal collect every public benchmark for Claude Opus 4.7 published since April 2026, save sources, and produce a markdown table sorted by date until the table covers at least 10 distinct benchmarks

Maintenance de dépôt

/goal find dead code, unused dependencies, and stale files in this repo, then propose a PR description listing safe removals until every item has a justification

Documentation

/goal rewrite README.md so a new contributor can install, run, test, and understand the project until each of those four steps has a working command and an expected output

Développement de fonctionnalité

/goal add a dark/light theme toggle, persist the choice in localStorage, update styles for both themes, and verify in the browser until the toggle works without a page reload and survives a refresh

Le schéma commun : chaque exemple définit un état final vérifiable. C'est la ligne entre un objectif qui se termine et un objectif qui tourne en rond.

Associer /goal aux workflows de développement API

Jusqu'à présent, la plupart des articles sur /goal concernent des tâches de codage génériques. Le cas d'utilisation le plus intéressant pour les ingénieurs backend et plateforme est le travail API, où l'état final est presque toujours testable.

Les points d'accès API sont parfaits pour /goal car « terminé » est sans ambiguïté : la requête retourne 200, le schéma de réponse correspond et le contrat est documenté. Vous pouvez écrire un objectif qui dit « faire en sorte que ce point d'accès passe ses tests » et le validateur aura un signal concret à lire.

Un workflow qui tient la route en pratique :

1. Concevez le contrat d'abord dans Apidog. Définissez le point d'accès, le schéma de requête, le schéma de réponse et les exemples de charges utiles dans Apidog. Cela devient la source de vérité.
2. Exportez la spécification. Apidog exporte OpenAPI 3.x, que vous transmettez à Codex ou Claude Code comme contexte.
3. Exécutez /goal. Dites à l'agent : « implémentez le point d'accès jusqu'à ce que chaque cas de test Apidog passe. »
4. Le validateur vérifie l'exécuteur de tests. À chaque itération de boucle, le validateur exécute les tests de la CLI Apidog contre le service en cours d'exécution. L'agent ne termine que lorsque tous les cas sont au vert.

C'est nettement mieux que de laisser l'agent inventer ses propres tests, car le contrat est déjà verrouillé. L'agent ne peut pas livrer une suite de tests réussie qui manquerait les cas limites couverts par la spécification.

Si vous n'avez jamais utilisé Apidog auparavant, la plateforme API combine la conception, le mocking, les tests et la documentation dans un seul outil, ce qui est important ici car /goal fonctionne mieux lorsque le validateur n'a qu'une seule commande à exécuter pour vérifier l'état. Notre guide de workflow API axé sur la conception couvre la configuration contract-first en détail, et l'aperçu de l'outil de test API pour les ingénieurs QA montre comment structurer les cas de test contre lesquels l'agent itérera.

Si vous travaillez avec des serveurs MCP (le protocole que la plupart des outils de codage IA utilisent désormais pour appeler des outils externes), le même schéma s'applique. Consultez le test de serveur MCP avec Apidog pour la configuration qui permet aux agents /goal de s'exécuter en toute sécurité contre votre serveur MCP local.

Conseils de pro tirés de l'utilisation de /goal en production

Quelques éléments que l'on n'apprend qu'après avoir utilisé /goal dans des situations réelles :

• Un objectif à la fois. Codex et Claude Code vous limitent à un seul objectif actif. Essayer de les empiler produit un état étrange. Utilisez /goal clear entre les exécutions.
• Associez avec /plan. Un workflow utile est d'utiliser /plan d'abord, de revoir le plan, puis /goal avec le plan comme contexte. Cela réduit de moitié le nombre d'itérations car l'agent ne redessine pas l'approche en plein milieu de la boucle.
• Utilisez des fichiers markdown comme brouillons. Demandez à l'agent de maintenir un fichier progress.md. Vous obtenez un historique d'audit lisible et l'agent obtient un contexte persistant à travers les itérations.
• Laissez le modèle écrire son propre objectif. Insérez votre idée générale dans une invite normale et demandez au modèle de la transformer en une invocation /goal avec des critères de succès. Le modèle rédige de meilleures invites d'objectif que vous, car il sait ce que le validateur peut réellement vérifier.
• Surveillez le validateur, pas le modèle principal. Si la boucle ne se ferme pas, le problème est presque toujours que les critères de succès ne sont pas mesurables. Resserrez les critères, ne réessayez pas le même objectif.
• /goal est pour les tâches à long terme. Pour un refactoring d'une seule ligne, une invite normale est plus rapide. La boucle autonome a une surcharge.

Quand /goal vous décevra

Limitations honnêtes à garder à l'esprit :

• Coût. Une boucle qui tourne pendant une heure consomme plus de jetons que la même tâche effectuée manuellement. Fixez un budget.
• Tâches sans signal. Le polissage de l'UX, le ton de la prose, le goût du design ; aucun de ceux-ci n'a de validateur clair. L'agent abandonnera ou inventera une fausse condition d'arrêt.
• Effets secondaires externes. Un objectif impliquant l'envoi d'e-mails, l'effectuation de paiements ou l'appel d'API de production nécessite des contraintes strictes. L'agent n'inférera pas la prudence par lui-même. Si vous êtes encore en train de construire le contrôle d'accès autour des agents IA appelant vos API, l'article sur l'utilisation et la facturation de l'API GitHub Copilot pour les équipes explique comment les principaux fournisseurs gèrent cela.
• Contexte obsolète. Les objectifs à long terme peuvent s'écarter de la spécification originale si la base de code change en cours de boucle. Mettez en pause et réinitialisez plutôt que de le laisser continuer avec un ancien contexte.

Ce que cela signifie pour la façon dont vous construisez avec l'IA

/goal est le passage de « l'IA comme auto-complétion » à « l'IA comme un travailleur que vous briefez et surveillez ». Le changement d'interface est minime (une seule commande slash), mais l'implication est grande : le travail que vous effectuez en tant que développeur évolue vers la rédaction de meilleurs critères de succès et de contraintes, et s'éloigne de la saisie des lignes de code réelles.

Les équipes qui en tirent le meilleur parti sont celles qui disposent déjà de contrats testables, d'une CI solide et de spécifications claires. Si votre API possède un document OpenAPI défini et une suite de tests, vous pouvez confier un point d'accès et une date limite à un agent /goal. Si votre API n'existe que dans l'esprit de quelqu'un, l'agent n'a rien à valider et la boucle se désintègre.

C'est là que les plateformes API deviennent une infrastructure porteuse pour les workflows d'IA. Apidog est conçu autour du développement API axé sur la conception, et cela devient beaucoup plus utile lorsque l'agent effectuant l'implémentation peut lire votre spécification et vérifier son propre travail par rapport à vos cas de test. Téléchargez Apidog si vous souhaitez configurer le workflow contract-first décrit ci-dessus.

FAQ

Est-ce que /goal fonctionne dans l'application web Codex ? Oui. Il fonctionne dans Codex CLI, Codex desktop, l'application Codex et Claude Code CLI. Hermes prend également en charge la même commande. La parité des fonctionnalités entre les fournisseurs est l'objectif.

En quoi /goal est-il différent d'une invite normale ? Une invite normale s'exécute une fois et s'arrête. /goal fonctionne en boucle fermée avec un modèle de validation qui vérifie la condition d'arrêt après chaque étape. L'agent décide quand s'arrêter, pas vous.

L'agent peut-il contourner les contraintes que je définis ? Le validateur applique les contraintes à chaque itération, donc l'agent ne devrait pas les violer. En pratique, plus la formulation de la contrainte est lâche, plus l'agent a de marge pour l'interpréter. Soyez explicite : « sans modifier aucun fichier en dehors de /auth » est applicable ; « sans rien casser » ne l'est pas.

Est-ce que /goal coûtera plus cher qu'une session Claude ou Codex normale ? Oui. Attendez-vous à dépenser plus de jetons. Le validateur fonctionne sur un modèle moins cher et plus petit, mais le modèle principal continue de faire le travail, et il en fait plus de manière autonome. Fixez un budget ou utilisez /pause pour contrôler les dépenses.

Et si je veux tester la sortie de l'agent par rapport à une vraie API ? Utilisez un outil comme Apidog pour verrouiller le contrat API et exécuter des cas de test réels par rapport à l'implémentation. Le validateur de l'agent peut appeler la CLI Apidog, ce qui vous donne un état final mesurable. Consultez le guide de l'API Claude gratuite si vous démarrez un service basé sur Claude avec un budget limité.