Comando /goal: Como Executar Codex e Claude como Agentes Autônomos 24/7

Todos os principais laboratórios de IA lançaram a mesma funcionalidade primitiva nas últimas seis semanas. A Anthropic adicionou /goal ao Claude Code. A OpenAI o lançou dentro do Codex CLI e do aplicativo de desktop Codex. A Nous Research o integrou ao Hermes. A nomenclatura é consistente de propósito; a indústria está se estabelecendo em uma interface compartilhada para uma coisa: um agente que funciona em um ciclo fechado até que um estado final mensurável seja atingido, sem pedir sua permissão a cada passo.

Se você tem feito a dança manual de "aprovar, enviar prompt, dizer ao agente para continuar, repetir", o comando /goal é o comando de barra que encerra isso. Você entrega um alvo ao agente, ele trabalha em função desse alvo e retorna quando o alvo é atingido.

Este guia é para desenvolvedores e construtores de API. Abordaremos o que /goal realmente faz nos bastidores, como configurá-lo no Codex e no Claude Code, uma estrutura de prompt que produz resultados reais em vez de loops infinitos, e como integrar tudo isso ao seu fluxo de trabalho de API usando Apidog.

Baixe o Apidog gratuitamente se quiser acompanhar os exemplos de API mais adiante no guia.

O que /goal realmente faz

Em uma linha: /goal permite que um agente de IA execute uma tarefa em loop até que uma condição de parada seja acionada, sem precisar de aprovação sua a cada rodada.

O mecanismo subjacente é simples. Um modelo validador pequeno e rápido é executado após cada passo que o agente principal dá e responde a uma pergunta: "O objetivo foi atingido?". Se não, o modelo principal continua. Se sim, o loop se fecha e o agente reporta. Este é o mesmo padrão que o "Ralph loop" popularizou no início de 2026, exceto que agora ele é fornecido como um comando de primeira classe dentro das ferramentas oficiais.

O contraste com o uso normal de agentes:

• Sem /goal: você é o loop. Você lê a saída, decide se está correta, solicita o próximo passo, aprova uma chamada de ferramenta e assim por diante. Cada iteração custa sua atenção.
• Com /goal: o agente possui o loop. Ele planeja, executa, autovalida e só aparece quando termina, atinge uma restrição ou fica sem orçamento.

Um exemplo concreto: dizer ao Claude Code /goal create a landing page aciona pesquisa, scaffolding, estilização, depuração e uma prévia final, tudo em uma execução contínua. Você se afasta, volta e então lança ou itera.

Por que isso está subitamente em todo lugar

A razão pela qual o /goal está sendo lançado por vários fornecedores agora é que as tarefas de agente de longo horizonte estavam falhando de duas maneiras previsíveis:

1. Desvio. Sem um validador verificando o objetivo original, os modelos se desviavam e produziam resultados confiantes, mas incorretos.
2. Babá. Mesmo quando o modelo conseguia fazer o trabalho, os usuários tinham que acompanhar cada iteração, o que anulava o propósito de um agente.

Um segundo modelo validador resolve ambos os problemas. É barato (modelo pequeno, prompt estreito) e fornece uma condição de parada rígida para o loop. Esse é todo o truque. Assim que os laboratórios perceberam que esse padrão funcionava, todos o lançaram com o mesmo nome em poucas semanas uns dos outros.

Configurando /goal no Codex

O Codex CLI oferece o maior controle. Aqui está a configuração mínima:

1. Habilite objetivos no aplicativo de desktop: abra o Codex desktop, vá para Configurações → Configuração e defina goals = true. O CLI herda essa configuração.
2. Inicie o CLI no modo totalmente automático para que você pare de ver prompts de aprovação:

codex --approval-mode full-auto

3. Defina um objetivo:

/goal [seu objetivo aqui]

É isso. O Codex imprimirá uma confirmação de que o objetivo está registrado e, em seguida, começará a ser executado.

Se você não é técnico, comece no aplicativo de desktop Codex em vez do CLI. A funcionalidade é a mesma, mas você obtém uma interface de usuário para pausar, limpar e observar o uso de tokens.

Configurando /goal no Claude Code

O Claude Code CLI funciona quase de forma idêntica. Inicie o CLI, digite /goal e siga com a descrição da tarefa. A documentação oficial está no site de documentação do Claude Code.

Se você estiver enfrentando erros de configuração ou instalação ao iniciar o Claude Code, a correção para a configuração empresarial custom3p inválida aborda o modo de falha mais comum. Para uma análise mais aprofundada de como impulsionar o Claude Code com fluxos de trabalho multiagentes juntamente com /goal, consulte nossa análise de Ruflo, uma camada multiagente sobre o Claude Code.

Uma dica fácil de perder: /goal mostra a contagem de tokens ao vivo e uma barra de progresso para a tarefa em execução dentro do Claude Code. Observe a contagem de tokens, não apenas a saída. Um objetivo que está queimando tokens sem progresso é um sinal de que o validador está falhando em convergir, e você deve pressionar /pause ou /goal clear.

A estrutura de prompt que realmente funciona

A sintaxe para /goal é trivial. A parte difícil é escrever um prompt que produza um resultado utilizável em vez de um agente que funcione por duas horas e lhe entregue algo sutilmente errado.

Todo prompt /goal eficaz tem três componentes:

1. O trabalho: o que você quer que seja feito, em uma linha.
2. O estado final mensurável: como "feito" se parece, em uma forma que o validador pode verificar.
3. As restrições: regras que devem ser mantidas durante todo o processo.

O esqueleto:

/goal [fazer o trabalho] até que [estado final mensurável] sem [restrições que devem ser mantidas]

Um exemplo real para uma tarefa de codificação:

/goal consertar todos os testes falhando até que npm test saia com 0 sem modificar nenhum arquivo fora do diretório /auth

O estado final é verificável (código de saída de npm test), e a restrição é um limite rígido que o validador pode impor a cada iteração. O agente não pode simular a conclusão porque o validador executa o comando de teste.

Para tarefas ambíguas ("fazer esta interface de usuário parecer moderna"), o /goal tem um desempenho ruim porque o estado final não é mensurável. Ou reescreva o objetivo para ser mensurável ("até que a pontuação de acessibilidade do Lighthouse seja 90+"), ou use um prompt normal.

Estrutura avançada para tarefas mais longas

Para objetivos maiores, expanda o esqueleto em quatro blocos:

/goal
Objetivo: [objetivo de uma linha]
Critérios de sucesso:
  - [critério mensurável 1]
  - [critério mensurável 2]
Restrições:
  - [limite 1]
  - [limite 2]
Contexto:
  - [arquivos, repositórios, chaves de API que o agente deve conhecer]

Este formato fornece ao validador coisas concretas para verificar em cada iteração do loop. Sem critérios de sucesso, o validador retorna a uma correspondência semântica imprecisa, que é de onde vem o desvio.

Exemplos que valem a pena copiar

/goal não serve apenas para escrever código. Alguns padrões que funcionam bem:

Pesquisa

/goal coletar todos os benchmarks públicos para Claude Opus 4.7 publicados desde abril de 2026, salvar as fontes e produzir uma tabela markdown ordenada por data até que a tabela cubra pelo menos 10 benchmarks distintos

Manutenção de repositório/goal encontrar código morto, dependências não utilizadas e arquivos obsoletos neste repositório, então propor uma descrição de PR listando remoções seguras até que cada item tenha uma justificativa

Documentação

/goal reescrever README.md para que um novo colaborador possa instalar, executar, testar e entender o projeto até que cada um desses quatro passos tenha um comando funcionando e uma saída esperada

Trabalho de funcionalidade

/goal adicionar um alternador de tema claro/escuro, persistir a escolha no localStorage, atualizar estilos para ambos os temas e verificar no navegador até que o alternador funcione sem recarregar a página e sobreviva a uma atualização

O padrão comum: cada exemplo define um estado final verificável. Essa é a linha entre um objetivo que termina e um objetivo que roda em círculos.

Emparelhando /goal com fluxos de trabalho de desenvolvimento de API

A maioria das coberturas de /goal até agora tem sido sobre tarefas genéricas de codificação. O caso de uso mais interessante para engenheiros de backend e plataforma é o trabalho com APIs, onde o estado final é quase sempre testável.

Os endpoints de API são perfeitos para /goal porque "pronto" é inequívoco: a requisição retorna 200, o esquema de resposta corresponde e o contrato é documentado. Você pode escrever um objetivo que diz "fazer este endpoint passar em seus testes" e o validador tem um sinal concreto para ler.

Um fluxo de trabalho que se sustenta na prática:

1. Projete o contrato primeiro no Apidog. Defina o endpoint, o esquema de requisição, o esquema de resposta e os exemplos de payloads dentro do Apidog. Isso se torna a fonte da verdade.
2. Exporte a especificação. O Apidog exporta OpenAPI 3.x, que você entrega ao Codex ou Claude Code como contexto.
3. Execute /goal. Diga ao agente: "implemente o endpoint até que todos os casos de teste do Apidog passem."
4. O validador verifica o executor de testes. A cada iteração do loop, o validador executa os testes do Apidog CLI contra o serviço em execução. O agente só termina quando todos os casos estão verdes.

Isso é materialmente melhor do que deixar o agente inventar seus próprios testes, porque o contrato já está travado. O agente não pode enviar um pacote de testes que passa, mas que perde casos de borda cobertos pela especificação.

Se você nunca usou o Apidog antes, a plataforma de API combina design, mocking, teste e documentação em uma única ferramenta, o que importa aqui porque o /goal funciona melhor quando o validador precisa executar apenas um comando para verificar o estado. Nosso guia de fluxo de trabalho de API design-first aborda a configuração contrato-primeiro em detalhes, e a visão geral da ferramenta de teste de API para engenheiros de QA mostra como estruturar os casos de teste contra os quais o agente irá iterar.

Se você está trabalhando com servidores MCP (o protocolo que a maioria das ferramentas de codificação de IA agora usa para chamar ferramentas externas), o mesmo padrão se aplica. Veja teste de servidor MCP com Apidog para a configuração que permite que agentes /goal executem com segurança em seu servidor MCP local.

Dicas profissionais de execução do /goal em produção

Algumas coisas que você só aprende depois de colocar o /goal para funcionar de verdade:

• Um objetivo por vez. Tanto o Codex quanto o Claude Code restringem você a um único objetivo ativo. Tentar empilhá-los produz um estado estranho. Use /goal clear entre as execuções.
• Combine com /plan. Um fluxo de trabalho útil é /plan primeiro, revisar o plano e, em seguida, /goal com o plano como contexto. Isso reduz pela metade o número de iterações porque o agente não redesenha a abordagem no meio do loop.
• Use arquivos Markdown como rascunhos. Peça ao agente para manter um arquivo progress.md. Você obtém um registro de auditoria legível e o agente obtém contexto persistente entre as iterações.
• Deixe o modelo escrever seu próprio objetivo. Coloque sua ideia aproximada em um prompt normal e peça ao modelo para transformá-la em uma invocação /goal com critérios de sucesso. O modelo escreve prompts de objetivo melhores do que você, porque sabe o que o validador pode realmente verificar.
• Observe o validador, não o modelo principal. Se o loop não estiver fechando, o problema é quase sempre que os critérios de sucesso são imensuráveis. Aperte os critérios, não tente o mesmo objetivo novamente.
• /goal é para trabalhos de longo horizonte. Para uma refatoração de uma linha, um prompt normal é mais rápido. O loop autônomo tem sobrecarga.

Quando o /goal irá te decepcionar

Limitações honestas a serem consideradas:

• Custo. Um loop que roda por uma hora queima mais tokens do que a mesma tarefa feita manualmente. Defina um orçamento.
• Tarefas sem sinal. Polimento de UX, tom da prosa, gosto de design; nenhum destes tem um validador claro. O agente ou desistirá ou inventará uma condição de parada falsa.
• Efeitos colaterais externos. Um objetivo que envolve enviar e-mails, fazer pagamentos ou chamar APIs de produção precisa de restrições rígidas. O agente não inferirá cautela por conta própria. Se você ainda está construindo o controle de acesso em torno de agentes de IA chamando suas APIs, o artigo sobre uso e cobrança do GitHub Copilot para equipes API aborda como os principais fornecedores lidam com isso.
• Contexto obsoleto. Objetivos de longa duração podem se desviar da especificação original se a base de código mudar no meio do loop. Pause e reinicie em vez de deixá-lo continuar contra o contexto antigo.

O que isso significa para como você constrói com IA

/goal é a mudança de "IA como autocompletar" para "IA como um trabalhador que você instrui e verifica". A mudança na interface é pequena (um comando de barra), mas a implicação é grande: o trabalho que você faz como desenvolvedor se move em direção a escrever melhores critérios de sucesso e restrições, e para longe de digitar as linhas de código reais.

As equipes que mais tiram proveito disso são aquelas que já possuem contratos testáveis, CI forte e especificações claras. Se sua API tem um documento OpenAPI definido e um conjunto de testes, você pode entregar a um agente /goal um endpoint e um prazo. Se sua API existe apenas na cabeça de alguém, o agente não tem nada para validar e o loop se desfaz.

É aqui que as plataformas de API se tornam infraestrutura de suporte para fluxos de trabalho de IA. O Apidog é construído em torno do desenvolvimento de API design-first, e isso se torna muito mais útil quando o agente que faz a implementação pode ler sua especificação e verificar seu próprio trabalho contra seus casos de teste. Baixe o Apidog se você quiser configurar o fluxo de trabalho contrato-primeiro descrito acima.

FAQ

/goal funciona no aplicativo web do Codex? Sim. Funciona no Codex CLI, no desktop Codex, no aplicativo Codex e no Claude Code CLI. Hermes também suporta o mesmo comando. A paridade de recursos entre os fornecedores é o objetivo.

Como /goal é diferente de um prompt regular? Um prompt regular executa uma única vez e para. /goal executa em um loop fechado com um modelo validador verificando a condição de parada após cada passo. O agente decide quando parar, não você.

O agente pode quebrar as restrições que eu defini? O validador impõe restrições a cada iteração, então o agente não deve violá-las. Na prática, quanto mais frouxa a frase da restrição, mais espaço o agente tem para interpretá-la. Seja explícito: "sem modificar nenhum arquivo fora de /auth" é aplicável; "sem quebrar nada" não é.

O /goal custará mais do que uma sessão normal do Claude ou Codex? Sim. Espere gastar mais tokens. O validador roda em um modelo menor e mais barato, mas o modelo principal ainda está fazendo o trabalho, e faz mais dele autonomamente. Defina um orçamento ou use /pause para controlar os gastos.

E se eu quiser testar a saída do agente contra uma API real? Use uma ferramenta como Apidog para bloquear o contrato da API e executar casos de teste reais contra a implementação. O validador do agente pode chamar o Apidog CLI, o que lhe dá um estado final mensurável. Consulte o guia de API Claude gratuita se você estiver inicializando um serviço alimentado por Claude com um orçamento limitado.