Vocabulário de IA Agentiva para DevOps: 12 Termos que Você Já Opera Sob Outro Nome

Há um gênero de infográfico circulando no momento: doze termos essenciais de IA agente, um guia do líder para a linguagem dos agentes. Eles são direcionados a executivos, e para esse público estão adequados. O problema é o que acontece a seguir, que é o executivo trazer o vocabulário para a equipe de plataforma e perguntar em quanto tempo um agente pode ter acesso à produção.

Se você gerencia infraestrutura, a leitura honesta dessa lista não é que doze novas coisas chegaram. É que dez delas são conceitos que você já opera, sob nomes que você já usa, e duas delas são genuinamente novas e são as que vão te prejudicar. Um loop de agente é um loop de reconciliação. Guardrails são controle de admissão. Sandboxing é o que você tem feito com cargas de trabalho não confiáveis desde cgroups.

Este post é a tabela de tradução, e então a parte que os infográficos deixam de fora: exatamente onde cada analogia quebra. As quebras são a parte interessante. Se um agente fosse apenas um controlador, você já saberia como executar um.

TLDR

• Dez dos doze termos se mapeiam claramente para primitivos de infraestrutura que você já opera: loops de controle, IAM, sandboxes, políticas de admissão, portões de mudança, agendadores.
• O loop de agente é um loop de reconciliação com um controlador não determinístico. Mesma forma, e toda suposição operacional que depende de "mesmo input, mesmo output" deixa de ser válida.
• O uso de ferramentas é uma questão de IAM, não uma questão de IA. O raio de ação de um agente é exatamente a união das credenciais que você entregou às suas ferramentas. Nada sobre o modelo muda isso.
• A injeção de prompt é uma escalada de privilégio com um payload de conteúdo em vez de um binário, e sua telemetria é um canal de entrega para isso.
• As duas coisas genuinamente novas são não determinismo e custo de tempo de execução não limitado. Nenhuma delas tem um bom análogo na infraestrutura que você já opera.
• Faça a pergunta sobre o raio de ação antes da pergunta sobre o modelo. Quais credenciais, quais ambientes e o que o registro de auditoria realmente registra.

Pré-requisitos

• Familiaridade prática com containers e algum orquestrador, provavelmente Kubernetes
• Alguma exposição a IAM ou RBAC, em qualquer nível de entusiasmo
• Ter lido uma explicação sobre IA agente e sair sem saber o que realmente estava sendo afirmado

A tabela de tradução

Comece aqui. Este é todo o argumento em uma tela.

Dez desses doze são re-rotulações. Isso não é uma crítica ao vocabulário. É a razão pela qual as pessoas de infraestrutura estão incomumente bem equipadas para raciocinar sobre agentes, e incomumente mal atendidas por explicações direcionadas a executivos.

Agora as partes que valem a pena serem exploradas adequadamente.

O loop de agente é um loop de reconciliação com uma diferença crucial

Todo explicador de agente desenha o mesmo ciclo: perceber, planejar, agir, observar, repetir. Se você escreveu um controlador Kubernetes, você desenhou esse ciclo você mesmo e o chamou de outra coisa.

O mesmo loop, duas vezes

1. Observar assistir à API, ou ler o contexto
2. Diferença atual vs desejado, ou planejar um passo
3. Agir chamar a API, ou chamar uma ferramenta
4. Verificar ler o status, ou observar o resultado

A forma é idêntica. Um controlador observa o servidor API, compara o estado real com a especificação, age para fechar a lacuna e observa o resultado. Um agente lê seu contexto, planeja um passo, chama uma ferramenta e observa a saída. Se você quiser os detalhes da mecânica do primeiro, Escreva um Operador Kubernetes Simples constrói um do zero, e tudo nele se transfere. Para o loop do lado do agente, incluindo por que a coisa que julga o trabalho deve ser separada da coisa que o faz, veja Pare de Sugerir, Comece a Loopar.

Aqui está a diferença, e não é uma pequena. Um controlador é determinístico e um agente não é.

Dê a um controlador o mesmo estado de cluster duas vezes e ele produz a mesma ação duas vezes. Essa única propriedade é fundamental para quase tudo que você sabe sobre operar loops de controle. É por isso que você pode testar um controlador, por que pode raciocinar sobre uma reconciliação travada, por que uma nova execução é uma ferramenta diagnóstica em vez de uma aposta, e por que "ele fez algo diferente desta vez" é um relatório de bug em vez de um comportamento esperado.

Um agente dado entradas idênticas pode seguir um caminho diferente. Não geralmente um caminho radicalmente diferente, mas diferente o suficiente para que o seguinte deixe de ser confiável:

• Reproduzindo uma falha. Executá-lo novamente não é um experimento controlado.
• Cobertura de teste. Passar uma vez não estabelece que o caminho é seguro.
• Análise pós-incidente. "Por que ele fez isso" pode não ter uma resposta melhor do que "ele amostrou um token diferente".

Tudo o mais neste post segue dessa única propriedade. As analogias de infraestrutura se mantêm até que dependam do determinismo, e então elas param.

O uso de ferramentas é um problema de IAM com um novo chapéu

Este é o termo que causa a conversa mais confusa, e é aquele com a resposta mais clara.

Um agente não pode fazer nada exceto através de uma ferramenta. O modelo produz texto. O texto se torna uma ação apenas quando algo do seu lado pega esse texto e chama uma API. Portanto, a pergunta "o que este agente pode fazer na minha infraestrutura" tem uma resposta exata, e não é uma pergunta sobre o modelo de forma alguma:

O raio de ação de um agente é a união das permissões detidas por cada ferramenta que você deu a ele.

Isso é uma auditoria IAM, e você já sabe como fazer uma. Se o agente tem uma ferramenta que chama kubectl com um kubeconfig vinculado a cluster-admin, então o agente é cluster-admin. Nenhuma quantidade de instrução em um prompt de sistema muda isso, da mesma forma que dizer a um estagiário para ter cuidado não é um mecanismo de controle de acesso.

O prático c