> ## Content Index
> Fetch the complete content index at: https://www.azurebrasil.cloud/llms.txt
> Use this file to discover other available public pages before exploring further.

# Gordon: O agente de IA da Docker
- URL: https://www.azurebrasil.cloud/blog/gordon-o-agente-de-ia-da-docker/
- Published: 2026-10-06T12:00:15.000Z
- Updated: 2026-10-06T12:00:17.000Z
- Description: Você abre o terminal, roda `docker compose up` e um container morre. De novo.
- Author: Bruno Brito

O log tem 400 linhas. A última diz alguma coisa sobre conexão recusada; a aplicação funciona na sua máquina, exceto que é justamente nela que está falhando. Alguém já escreveu no chat: "consegue colocar isso em pé?".  
Nessa hora, um assistente de código ajuda, mas só depois que você entrega metade do trabalho. Ele sugere um `Dockerfile`, explica um erro que você colou no chat e talvez acerte uma flag. Só não sabe quais containers estão rodando, qual volume foi montado, o que há no `compose.yaml` ou o que o daemon local acabou de fazer. Você vira o intermediário entre terminal, Docker Desktop, logs e o chat de IA. Um cargo pouco nobre para quem já sabe usar `docker ps`.  
O Gordon é a tentativa do Docker de fechar essa lacuna. É um agente integrado ao Docker Desktop e ao CLI, com acesso ao ambiente de containers e permissão para agir depois da sua aprovação. Não é só outra maneira de perguntar "o que significa exit code 1?". Ele coleta o contexto, propõe o próximo passo e executa quando você aprova.  
O que importa aqui é separar o que o Gordon faz do marketing que inevitavelmente aparece quando alguém coloca "agent" no nome.

## O problema: o contexto está espalhado

Grande parte do trabalho com containers não é escrever `Dockerfile`. É descobrir por que aquilo que parecia trivial não funciona no ambiente atual.  
Um build deixa de aproveitar cache porque a ordem de um `COPY` foi ruim. A aplicação sobe, mas não chega no Postgres porque uma variável de ambiente não foi carregada. Um volume encobre um diretório da imagem. O container está saudável na sua cabeça, mas o processo principal encerrou há 15 segundos.  
Nada disso pede uma inteligência artificial filosófica. Pede acesso ao estado real, alguém que relacione os sinais e que não obrigue você a procurar a sintaxe de `docker system df` no meio de um incidente local.

Assistentes de código trabalham, em geral, com o contexto que você oferece. Você cola o erro, descreve a topologia e torce para não esquecer a variável que muda tudo. Gordon parte de outra premissa: ele pode ler logs de containers em execução, imagens, arquivos do Compose e o diretório de trabalho. Depois usa shell, filesystem e o Docker CLI para investigar e preparar a correção.  
Ele não elimina o diagnóstico. Só tira da frente a coleta manual e repetitiva de contexto. Parece menos glamouroso do que "IA autônoma", mas é bem mais útil no trabalho diário.

## O que o Gordon faz

Gordon é o assistente nativo do Docker para tarefas com containers, imagens e `Dockerfile`. Está disponível no Docker Desktop 4.74 ou superior e no terminal, pelo comando `docker ai`.  
Você faz um pedido em linguagem natural. Ele olha o ambiente associado à sessão, propõe comandos ou mudanças em arquivos e espera a aprovação. Dá para rejeitar, corrigir a direção ou aprovar.  
Isso não é um detalhe. Um agente que executa shell, altera arquivos e opera containers não merece o mesmo tratamento de um autocomplete com esteroides. O Gordon pede aprovação explícita para cada ação; as permissões duram só a sessão, e o Docker mostra comandos e modificações antes de aplicá-los. Há `auto-approve` para fluxos confiáveis, mas eu não começaria por ele. Não digitar um comando não compensa deixar passar uma exclusão, um `prune` ou uma configuração ruim.  
Em termos práticos, Gordon é um operador assistido para o Docker local. Ele não substitui seu entendimento de containers, a observabilidade de produção ou uma arquitetura decente. Pedir com educação não muda isso.

## Usando pelo CLI

No terminal, abra o projeto e execute:

```bash
cd ~/repos/minha-apidocker ai

```

O diretório atual vira o diretório de trabalho do Gordon. É de lá que ele examina `Dockerfile`, `compose.yaml`, arquivos de configuração e a estrutura do projeto. Para apontar a outro lugar, use `-C`:

```bash
docker ai -C ~/repos/minha-api

```

Também é possível passar uma pergunta diretamente:

```bash
docker ai "me mostre os containers em execução e explique por que a api está reiniciando"

```

O CLI abre uma TUI para a conversa, as aprovações e o contexto da sessão. Não é uma integração escondida numa extensão de IDE. É o Docker Desktop levando a interface do agente para o terminal.  
No Docker Desktop, o mesmo agente aparece numa aba própria e pode ser chamado a partir de um container, imagem, volume ou build com problema. A escolha entre UI e terminal é operacional: use o lugar onde você já está trabalhando. Não existe medalha por sofrer no terminal quando o diagnóstico visual do Desktop está mais perto do que você quer inspecionar.

## Pedidos que fazem sentido

O melhor uso do Gordon não é "escreva todo o meu sistema". Ele serve para encurtar o caminho entre uma intenção específica e uma tarefa que depende do estado atual do Docker.

### Quando algo quebra

Esse é o caso mais óbvio. Em vez de copiar log, rodar cinco comandos e contar uma história completa para um chat, peça:

```text
Meu container api continua encerrando. Investigue os logs, o compose e as variáveis necessárias. Proponha a menor correção possível.

```

O pedido tem escopo de propósito. "Menor correção possível" reduz a chance de o agente transformar uma variável ausente em refatoração de infraestrutura. Gordon verifica logs, status, mounts e configuração; você revisa a proposta antes de ela tocar no ambiente.

### Quando o serviço não tem Docker

Também vale usá-lo para criar um ambiente local repetível. Por exemplo:

```text
Analise este projeto .NET 8, crie um Dockerfile multi-stage e um compose para desenvolvimento com Postgres. Não altere arquivos sem mostrar o diff primeiro.

```

Aqui o trabalho cruza código, dependências, imagem e serviços auxiliares. É o tipo de cenário que o Docker cita: containerizar a aplicação, montar uma stack com Postgres e Redis e rodar tudo localmente.  
Aceite o `Dockerfile` como proposta, não como revelação. Confira a imagem base, o usuário de execução, o `.dockerignore`, secrets, portas expostas, volumes e como a aplicação lê configuração. A IA pode acelerar os primeiros 80%. Os 20% que sobram costumam ser onde mora a produção e, às vezes, o incidente.

### Quando o Dockerfile funciona, mas é ruim

Imagem de 2 GB, cache invalidado a cada mudança de código e build que parece reunião longa: um pedido bem definido ajuda.

```text
Otimize este Dockerfile para builds .NET. Preserve o comportamento, use multi-stage build e explique o impacto de cada alteração no cache e no tamanho da imagem.

```

O Docker sugere que o Gordon reorganize camadas para aproveitar cache, use uma base menor e inclua health check quando fizer sentido. A ressalva importa. Health check mal definido vira gerador de reinícios; imagem "slim" pode não ter a dependência nativa que seu pacote precisa. Como quase tudo em Docker fora de uma demo, depende do contexto.

### Quando a tarefa é simples, mas a sintaxe irrita

Listar imagens, verificar espaço em disco, limpar recursos sem uso, parar uma stack. Você sabe fazer isso. Só não quer gastar energia lembrando qual variação de `prune` cabe em cada situação.  
É um uso honesto do agente: ele monta o comando, mostra o impacto e você aprova. Para limpeza, eu pediria que ele liste antes de remover:

```text
Mostre as imagens, volumes e containers que não estão em uso. Não remova nada ainda.

```

Depois você decide. `docker system prune` é prático até apagar a imagem de que você precisa dois minutos antes de uma reunião. Limpar Docker é simples até deixar de ser.

## Quando não vale usar

Gordon não substitui seu coding agent e não é um agente de produção. A divisão de papéis é razoável: use Gordon para tarefas de Docker, assistentes de código para lógica e refatoração da aplicação, e os dois quando a tarefa atravessa essas camadas.  
Eu evitaria usá-lo como primeira opção quando:

- a mudança envolve credenciais, dados sensíveis ou destruição de recursos sem um procedimento bem definido
- o problema é exclusivamente de lógica de negócio e não tem relação com o ambiente de containers
- você precisa investigar produção. A telemetria, a política de acesso e o raio de impacto são outros. Abrir um shell local inteligente não resolve isso
- o time ainda não tem um `compose.yaml`, `Dockerfile` e convenções mínimas revisáveis. O agente pode gerar material, mas não cria disciplina operacional por telepatia.

Também não confunda Gordon com Docker Agent, Docker Sandboxes, Model Runner ou o toolkit de MCP. Estão no mesmo conjunto de produtos, mas resolvem problemas diferentes. Gordon é o assistente pronto para tarefas Docker; Docker Agent é um framework para criar equipes de agentes; Sandboxes isolam agentes; Model Runner executa modelos localmente; MCP conecta ferramentas externas.

## Como começar sem inventar moda

Instale ou atualize o Docker Desktop para a versão 4.74+, entre com sua conta Docker e teste num repositório descartável ou num problema local de verdade. Segundo o anúncio do Docker, o uso básico é gratuito.  
Eu começaria com leitura e diagnóstico. Peça para listar o que está executando, explicar uma falha ou revisar um `Dockerfile`; exija a proposta antes da execução. Depois, avance para alterações pequenas e reversíveis. Só então considere `auto-approve` em fluxos muito conhecidos, ainda com escopo limitado.  
O Gordon não torna Docker mágico. Docker continua tendo rede, filesystem, cache, processo PID 1, permissões e todas as outras coisas que estragam uma sexta-feira à tarde. A vantagem é pôr um agente onde o contexto existe e encurtar o trajeto entre "algo quebrou" e "entendi o que fazer".  
Se ele poupar a caça a logs, a adivinhação de flags e a recontagem do estado do ambiente para outra ferramenta, já valeu o espaço na tela. O julgamento continua sendo seu. Ainda bem.

## Meu querido Claude ou Gordon?

O reflexo é perguntar: precisava? Já temos Claude, Copilot e uma pequena indústria de agentes de código capazes de abrir terminal, ler `compose.yaml`, rodar `docker ps` e explicar por que o banco não subiu. Colocar o Gordon na conversa parece, à primeira vista, trazer mais uma pessoa para discutir a mesma planilha.

Em boa parte dos casos, a resposta é não. Um agente de código competente, com acesso ao diretório, ao Docker CLI e aos logs, resolve a investigação local sem cerimônia. A ironia é que Gordon começou a ser desenvolvido antes de os agentes de código chegarem a boa parte dessa capacidade operacional. Quando foi lançado, passou a disputar atenção com ferramentas que leem o repositório, usam terminal e investigam o ambiente local sem se importar com a categoria do problema. Não é inútil; só precisa justificar por que existe ao lado de agentes que já cobrem uma parte relevante do trabalho. Vendê-lo como resposta universal para containers, ou como um *harness* misteriosamente superior, seria exagero. O Docker não publicou base para essa última afirmação, e adjetivo não depura `connection refused`.

Agentes trabalham tão bem quanto o contexto que conseguem carregar e as ferramentas que têm à mão. A janela de contexto já virou uma novela, o repositório é grande, o histórico foi resumido, o terminal está bloqueado por política ou não existe uma skill de Docker nas instruções do projeto. Nessa situação, o agente principal pode saber bastante e ainda assim olhar para uma fotografia velha do ambiente. Gordon começa de outro lugar: containers, imagens, volumes, builds, arquivos do Compose e o diretório de trabalho. Numa falha de `docker compose`, isso pode separar a investigação do estado real de uma explicação elegante para o estado imaginado.

É aí que ele deixa de ser redundante. Não como substituto do agente de código, mas como especialista em contexto. Claude ou Copilot ainda são opções melhores para entender a regra de negócio, alterar a aplicação, revisar o diff e rodar testes. Gordon entra quando a pergunta depende do Docker que existe agora, e não do Docker que alguém descreveu quarenta mensagens atrás. Um relaciona o problema ao sistema; o outro evita que essa análise comece com informação faltando.  
Isso tampouco vira uma cadeia automática de agentes. O `docker ai` abre uma TUI e pede aprovações. Um agente principal pode identificar a tarefa, formular um pedido preciso e até iniciar o comando, se tiver acesso ao terminal. Não deve contornar a aprovação do Gordon nem fingir que leu o resultado de uma conversa interativa que não consegue acessar. A delegação funciona como um handoff explícito:

1. O agente de código decide que o problema é de Docker, não de lógica da aplicação;
2. ele prepara um pedido curto, com objetivo, escopo e restrições;
3. você executa ou aprova o `docker ai` no diretório do projeto;
4. O resultado, o diff proposto ou o diagnóstico volta para o agente pai, que relaciona aquilo com o código e os testes.

Vale registrar essa regra no `copilot-instructions.md`, `CLAUDE.md` ou equivalente: delegue a investigação de estado Docker ao Gordon quando ele estiver disponível, mas mantenha no agente principal a decisão arquitetural e a revisão da mudança. Não é uma hierarquia sofisticada.

É só entregar a pergunta a quem enxerga melhor a parte relevante do problema.

## Referências

- [Meet Gordon: Docker’s AI Agent For Your Entire Container Workflow](https://www.docker.com/blog/meet-gordon-dockers-ai-agent-for-your-entire-container-workflow/?ref=azurebrasil.cloud)
- [Using Gordon via CLI](https://docs.docker.com/ai/gordon/how-to/cli/?ref=azurebrasil.cloud)
- [Docker AI overview](https://docs.docker.com/ai-overview/?ref=azurebrasil.cloud)