O Ciclo de Controlo de Agentes de IA: Construir para Produção

O ciclo de controlo de agentes de IA é onde os desenhos de whiteboard encontram a realidade. No quadro é uma caixa para o modelo, setas para as ferramentas, uma linha de volta ao início. Na prática, em produção, é prompt drift à terceira iteração, uma chamada de ferramenta que devolve lixo em silêncio e nenhuma condição de parada em sítio nenhum.

4

Fases do ciclo, e juntar duas delas quebra a validação

3

Modos de falha que explicam a maioria dos incidentes

3

Pontos onde os guardrails têm de estar

2

Vias de monitorização, offline e em produção

Este artigo trata da engenharia interna e não da estratégia. Para o âmbito, a escolha de frameworks e o ciclo de vida mais amplo, o nosso processo de desenvolvimento de agentes de IA cobre a perspetiva de ambientes regulados, e o guia como construir um agente de IA trata da escolha entre no-code e code-first. Segue-se, portanto, a parte que decide se algo disto sobrevive ao tráfego real.

O ciclo de controlo de agentes de IA tem quatro fases, não duas

Pensar, planear, agir, observar. O agente raciocina sobre o estado atual da tarefa, escolhe uma ferramenta e constrói a chamada, executa-a e depois atualiza o contexto com o que voltou, antes de repetir o ciclo.

Deslize a tabela para o lado para ver todas as colunas.

Ora, esse atalho é o mais comum de todos, quase sempre feito por causa da latência, e é o que transforma um erro recuperável numa corrupção silenciosa. Em contrapartida, manter as fases separadas custa algumas centenas de milissegundos e, em troca, dá-lhe um ponto de validação.

ReAct e Reflexion: duas formas de correr o ciclo

O ReAct é a implementação prática para fluxos com muitas ferramentas. Intercala traços de raciocínio com chamadas de ação, pelo que o caminho de decisão fica inspecionável em cada passo e não apenas no fim. Assim, quando algo corre mal, consegue ler o que o agente acreditava no momento em que escolheu mal, o que é a diferença entre um sistema depurável e um palpite.

O Reflexion estende o mesmo ciclo com uma fase de reflexão após a observação, usando sinais de avaliação externos para refinar a estratégia antes da iteração seguinte. Custa tokens e latência, por isso justifica-se em tarefas onde o agente tem mais do que uma tentativa e a qualidade importa mais do que a velocidade. No entanto, em tarefas de tentativa única é apenas peso morto.

Três modos de falha do ciclo de controlo de agentes de IA

1. 01
   Uso indevido de ferramentas com argumentos errados

   O agente constrói uma chamada plausível mas inválida. Correção: registe cada ferramenta com um esquema de argumentos estrito e configure-a para rejeitar campos desconhecidos. De facto, rejeitar na fronteira é melhor do que uma ferramenta que aceita disparates e devolve algo que se parece com sucesso.
2. 02
   Ciclos infinitos por falta de condição de parada

   Correção: um limite rígido de iterações, mais deteção de ausência de progresso que compara o estado entre ciclos e para quando nada mudou. Contudo, o limite por si só não basta, porque um agente consegue gastar todas as iterações a repetir a mesma chamada falhada.
3. 03
   Perda de contexto em tarefas longas

   Correção: guarde o estado num armazenamento externo em vez de confiar apenas na memória em contexto, e adicione checkpoints para que um agente de longa duração retome entre sessões sem perder a tarefa. Ou seja, o estado em contexto é uma cache e não uma base de dados.

Os três vêm da mesma raiz: um ciclo escrito para funcionar no caminho ideal, sem resposta explícita para o que acontece quando um passo falha. Por isso, trate limites de iteração, deteção de ausência de progresso e orçamento de tokens como obrigatórios, não como reforço a acrescentar depois.

Ferramentas e estado em volta do ciclo de controlo de agentes de IA

Esquemas estritos são o ganho de fiabilidade mais barato que existe. Na prática, uma ferramenta que rejeita campos desconhecidos evita uma classe inteira de erros em execução, aquela em que o agente inventa um parâmetro, a ferramenta ignora-o e todos os passos seguintes raciocinam sobre um resultado que respondeu a outra pergunta.

Duas práticas na camada de dados contam tanto como os esquemas, e ambas pertencem à infraestrutura, não a uma checklist de revisão.

• Masque dados pessoais onde os dados passam, não depois. Os campos sensíveis devem ser mascarados ou redigidos ao nível do esquema antes de qualquer coisa circular entre componentes ou sair para uma ferramenta externa. Além disso, fazer isto depois significa auditar todos os caminhos de chamada que já construiu.
• Trate todos os documentos recuperados como não confiáveis. Remova texto com forma de instrução do conteúdo recuperado e etiquete os fragmentos com metadados de proveniência, para que as verificações de política a jusante saibam de onde veio uma afirmação antes de agir sobre ela.

Ainda assim, o ponto da proveniência é fácil de saltar e caro de acrescentar mais tarde. Uma camada de política que não distingue se o texto veio da sua base de conhecimento ou de um PDF carregado por um utilizador não consegue decidir nada de útil sobre ele.

Guardrails no ciclo de controlo de agentes de IA: três pontos

Antes de tudo, segurança não é um filtro no output. São três responsabilidades separadas em três momentos separados do ciclo.

A linha do meio é a que as equipas saltam, e é onde vive o padrão de confirmação em dois passos: o agente propõe uma ação, uma camada de validação separada aprova ou rejeita, e só as ações aprovadas executam. Note-se que a lógica de aprovação fica fora do modelo, e é esse o ponto. Um modelo a quem se pede que se fiscalize a si mesmo é juiz em causa própria.

Quando escalar para revisão humana

Ações de alto risco precisam de aprovação humana em vez de execução autónoma: pagamentos, eliminações, qualquer coisa que partilhe dados para fora. Portanto, codifique esse limite na camada de política em vez de deixar o modelo julgar caso a caso. Esses pontos de revisão também geram o feedback etiquetado que melhora o agente mais tarde, por isso o controlo não é puro custo.

Para agentes que operam na União Europeia, o enquadramento do Regulamento da IA determina que obrigações de documentação e supervisão se aplicam, o que vale a pena ler contra a sua própria classificação de risco antes de fechar o desenho dos guardrails.

Deploy e monitorização de um ciclo de controlo de agentes de IA

O caminho de deploy não tem nada de especial, e é isso que interessa: infraestrutura como código para ambientes reproduzíveis, CI/CD para releases repetíveis, runtime em contentor para portabilidade, e testes completos em sandbox antes de qualquer tráfego real chegar ao agente. Naturalmente, existem opções geridas se preferir não manter esta camada, embora as capacidades das plataformas mudem depressa o suficiente para valer a pena confirmar com o fornecedor e não com um artigo.

A monitorização corre em duas vias, e ambas são necessárias.

• Avaliação offline corre o agente sobre um conjunto de cenários curado antes de cada release, apanhando regressões antes dos utilizadores. É o seu conjunto de testes, e um agente sem ele entra em produção às cegas.
• Monitorização em produção observa o tráfego real à procura de violações de política, degradação da qualidade do output e anomalias de comportamento: padrões inesperados de chamadas, picos de latência, contagens de iteração a subir.

Por fim, vale a pena tornar uma ligação explícita. Se o objetivo que escreveu no início era suficientemente específico para ser medido, as métricas de monitorização mapeiam diretamente para ele e a monitorização torna-se um ciclo de feedback em vez de um alarme. Caso não mapeiem, o objetivo era vago, e isso é um problema da primeira fase a aparecer na última.

Perguntas Frequentes

Construa bem o ciclo e o resto resolve-se

A maioria dos agentes que falha em produção não falha pela qualidade do modelo. Falha por um ciclo sem condição de parada, uma ferramenta que aceitou um argumento inválido, ou um guardrail que só verificava o output. Nenhum destes é, na verdade, um problema difícil. São apenas os que ficam para depois, porque o caminho ideal já impressiona numa demo.

Assim, comece com um fluxo com inputs claros, outputs definidos e um critério de sucesso mensurável. Separe as quatro fases, deixe os esquemas estritos, o estado externo e os guardrails nos três pontos.

Dado que cada lição se transfere, um agente único construído assim é o caminho mais rápido para um sistema multiagente, porque cada lição transfere-se intacta. Sobre instruções e esquemas de ferramentas, o nosso artigo sobre boas práticas na criação de agentes de IA cobre o que não se consegue acrescentar depois, e há também o guia sobre agentes de IA no desenvolvimento de software.