Agente de IA

Quando uma solicitação não cabe em uma única resposta ou chamada, um agente de IA organiza um ciclo de observar, raciocinar sobre o próximo passo, usar ferramentas e avaliar resultados. O sistema inclui um modelo, instruções, catálogo de ações, memória de trabalho, estado e critérios de término. Alguns agentes planejam primeiro; outros intercalam pensamento e ação; arquiteturas multiagente distribuem papéis. O termo não exige autonomia irrestrita. Em uma casa inteligente, o agente pode investigar uma falha, comparar dados e sugerir ações, mas não deve possuir acesso amplo por padrão. A flexibilidade vem com riscos: loops, chamadas desnecessárias, erros acumulados, prompt injection, uso excessivo de recursos e ações fora da intenção. Limites externos e supervisão são parte do projeto.

• A diferença para uma automação tradicional está no caminho de execução. Uma rotina “às 19 h, acenda a luz” tem gatilho e ações definidos. Um agente recebe um objetivo, como “reduza o consumo sem comprometer conforto”, e pode consultar tarifa, clima, estados, histórico e preferências antes de propor. Essa abertura permite lidar com situações novas, mas reduz previsibilidade. Para controle residencial, o agente deve produzir um plano verificável. Regras duras permanecem fora: temperatura mínima, não desligar equipamento médico, não destrancar portas, preservar alarmes. Um policy engine avalia cada ação. O agente não edita a própria política. A autonomia é graduada por domínio e risco.
• O laço precisa de limites. Defina máximo de etapas, chamadas, tempo, tokens, custo e profundidade. Sem isso, o agente pode repetir uma busca, alternar hipóteses ou consumir APIs. Um orçamento pode ser 10 chamadas e 30 segundos para diagnóstico, mas valores dependem. O estado registra tarefas concluídas e evita repetição. Ferramentas retornam erros tipados. Retentativas usam backoff. O critério de término inclui sucesso, falta de dados, risco, orçamento esgotado ou necessidade de humano. O agente não deve inventar sucesso para encerrar. Se não consegue, entrega evidências e próximos passos. Cancelamento pelo usuário precisa interromper. A execução é observável.
• Ferramentas definem o alcance. Um agente de suporte pode ter leitura de telemetria, busca de manual e criação de ticket, sem comandos. Um agente de economia pode ajustar termostato em faixa limitada e somente após aprovação. O catálogo é allowlist por identidade. Ferramentas genéricas de shell, navegador irrestrito ou SQL aumentam risco. Use APIs específicas. Credenciais ficam no backend. Saídas são validadas. Para ações, preferir funções idempotentes. O agente não recebe rede interna arbitrária. Sandboxes isolam código. Se usa navegador, domínios e downloads são controlados. Conteúdo externo é não confiável e pode tentar instruir. A política impede escalada.
• Memória melhora continuidade, mas pode perpetuar erros. O agente usa memória de trabalho durante a tarefa, registros episódicos de execuções e fatos persistentes aprovados. Estados atuais vêm das fontes. Um resumo gerado não deve virar verdade sem validação. Preferências são armazenadas com consentimento e escopo. O agente não memoriza senha. Em multiusuário, memórias são isoladas. A exclusão funciona. A recuperação inclui proveniência. Uma memória desatualizada recebe expiração. Para diagnóstico, o agente pode guardar que “firmware 3.2 corrigiu falha E105” com fonte; ao atualizar, revisa. Sem governança, a memória acumula instruções maliciosas e dados pessoais.
• Agentes podem planejar e executar. Um plano explícito ajuda a revisar: objetivo, etapas, ferramentas, riscos e critérios. Para tarefas de baixo risco, execução automática. Para médio, aprovação do plano. Para alto, aprovação por etapa ou apenas recomendação. Em casa, “organize nomes dos dispositivos” pode ser automático com preview; “mude regras de acesso” exige aprovação; “desative alarme” talvez proibido. O agente deve mostrar alterações antes e depois. Rollback é necessário quando possível. A execução registra actor, modelo, ferramentas e resultados. Um plano gerado não é prova de segurança; o policy engine e transações aplicam.
• Avaliação de agente é mais difícil que avaliar uma resposta. Mede taxa de sucesso da tarefa, ações indevidas, número de etapas, custo, latência, recuperação de erros, respeito a política e qualidade do estado final. Simuladores e ambientes de teste evitam afetar a casa. Cenários incluem dispositivo offline, dados contraditórios, ferramenta lenta, prompt injection, permissões, mudança durante execução e interrupção. Red teaming tenta induzir escalada. Uma versão nova do modelo pode mudar estratégia. O rollout é gradual. O agente deve ter kill switch e modo somente leitura. Logs não expõem dados. A segurança é sistêmica, não uma propriedade do prompt.