Um desabafo aleatório sobre o ponto em que nos encontramos com os agentes de IA:
Algumas pessoas não os chamam de agentes, mas "agentes de fluxo de trabalho" com fluxos determinísticos estão por toda parte e funcionam. Qualquer pessoa pode criar agentes de fluxo de trabalho simples, mesmo começando com ferramentas sem código como Zapier e n8n. Agentes de fluxo de trabalho complexos exigem muito mais planejamento para serem construídos de forma confiável e eficiente. Um fluxo de trabalho complexo para um caso de uso comum e valioso, com integrações relevantes já incorporadas, pode funcionar como um negócio independente e também como uma ótima estratégia de entrada no mercado para expansão posterior para outros fluxos de trabalho ou tarefas mais autônomas.
Agentes mais dinâmicos/autônomos estão começando a funcionar e são úteis para pesquisa (especialmente se forem baseados na web) e programação. Tornam-se menos confiáveis quando se adicionam mais fontes de dados (como APIs). Agentes somente leitura parecem seguros e fáceis de testar, mas permitir que agentes autônomos tomem medidas (escrevam) é assustador. (Uma ideia aleatória: seria legal se ferramentas como um CRM permitissem criar um "fork" de um repositório de desenvolvimento e executar experimentos de automação que pudessem ser revertidos ou mesclados de volta ao repositório original.)
Agentes dinâmicos funcionam bem quando conseguem (1) criar e acompanhar um bom plano e (2) executar tarefas corretamente, enquanto (3) encontram o contexto adequado para cada etapa (tanto no planejamento quanto em cada tarefa). Finalmente, precisam (4) refletir ao longo do processo (com ou sem intervenção humana) para que possam ajustar o plano adequadamente e também melhorar a execução de tarefas falhas ou com baixo desempenho.
Planejamento de tarefas: capacidades de raciocínio de LLM Funcionam bem para listas de tarefas simples que não exigem contexto privado (como pesquisas aprofundadas, apenas uma série de buscas na web com resumos). Se você precisa pesquisar muitas entidades, a pesquisa aprofundada não funciona tão bem porque o gerenciamento da lista de tarefas é relativamente básico. Ferramentas de IA baseadas em planilhas funcionam melhor para pesquisar muitas entidades porque você efetivamente transfere o gerenciamento de tarefas para a planilha, já que passar longas listas de tarefas entre prompts não funciona nesse caso. O gerenciamento de tarefas em agentes de codificação funciona bem com problemas simples, código simples ou quando você está começando do zero. Ao lidar com projetos preexistentes mais complexos, eles se tornam menos confiáveis — e os desenvolvedores aumentam a confiabilidade documentando como seu código funciona e está organizado (arquivos .md), o que permite que o agente crie listas de tarefas mais bem informadas. Códigos complexos exigem mais documentos e, eventualmente, a extração dinâmica apenas do contexto relevante desses documentos. Muitas pessoas/empresas têm opiniões fortes e não documentadas sobre a ordem/abordagem/ferramentas corretas para lidar com um projeto, e precisamos de mais maneiras de documentar isso antecipadamente e em tempo real. Outro motivo pelo qual os agentes de pesquisa baseados em programação e na web funcionam bem é que todos eles usam o mesmo conjunto de ferramentas, portanto, não há necessidade de "aprender" a usar essas ferramentas (falaremos mais sobre isso a seguir).
Execução de tarefas: as tarefas geralmente envolvem chamadas de API (que exigem autenticação e compreensão de como usar a API e a estrutura de dados subjacente, que pode ser única, como em um CRM ou banco de dados com tabelas/colunas personalizadas), raciocínio LLM (por exemplo, resumo), uma combinação de ambos e até mesmo agentes de fluxo de trabalho*. Um agente de pesquisa é basicamente uma busca na web e sumarização em um loop. Os agentes de codificação são operações CRUD na sua base de código e talvez buscas na web para aprender APIs. A autenticação e o acesso básico à API parecem resolvidos (os MCPs se encaixam aqui), mas eu gostaria de ver mais informações sobre o contexto específico da ferramenta (perguntar ao usuário, mas também analisar na conexão inicial, investigar os dados existentes para entender como a ferramenta é usada, como os dados são estruturados, para quais cenários/projetos usamos a ferramenta). Erros, reflexões e feedbacks precisam se transformar em aprendizados organizados que são retroalimentados como contexto quando relevantes. As mesmas ferramentas podem ser usadas para diferentes propósitos e de maneiras diferentes entre organizações, e precisamos capturar/documentar isso de alguma forma para executar as tarefas corretamente.
Contexto: imagine ser um novo funcionário em uma empresa. Você aprende muito durante o processo de integração (e quanto melhor a integração, mais eficaz você se torna desde o início), e depois há o aprendizado prático, que se divide em aprender com a experiência da organização ("é assim que fazemos as coisas") e aprender com a própria experiência – o primeiro sendo mais predominante em grandes organizações. O gerenciamento de contexto é semelhante. Existem camadas de contexto, como metadados (usuário/empresa), contexto específico do projeto/departamento, contexto específico da tarefa, contexto específico da ferramenta, etc. Evoluímos de simples prompts do sistema para estratégias híbridas RAG (vetor, palavra-chave, grafo), mas além de termos os dados/contexto, precisamos de orientação sobre quando e como recuperar o contexto, algo que vemos em versões iniciais hoje em dia – mas com muito espaço para melhorias. Este não é apenas um problema técnico, mas também uma questão de negócios – já que você basicamente precisa criar um documento de integração que cubra todos os cenários esperados. À medida que os projetos se tornam mais complexos, é necessário mais cuidado para filtrar corretamente o contexto, de modo que apenas as informações relevantes sejam incluídas no prompt, minimizando o contexto irrelevante.
Reflexão: temos ferramentas de monitoramento de agentes que cobrem os custos de LLM/API e observação, mas atribuir sucesso/falha é um desafio. Uma área em que os agentes de codificação têm vantagem sobre outros é a maneira determinística de detectar falhas (por meio de testes do código). Para muitas outras tarefas de agentes, ainda estamos descobrindo a maneira correta de coletar feedback humano para melhorar os resultados futuros. Pelo que sei, a reflexão hoje envolve humanos no circuito, onde o feedback é amplamente fornecido aos desenvolvedores humanos para aprimorar o agente, mas o diferencial surge quando descobrimos como transformar a reflexão em autoaperfeiçoamento — onde o agente extrai insights de falhas na geração da lista de tarefas e na execução de tarefas para se sair melhor na próxima vez. Basicamente, a reflexão precisa se transformar em um contexto bem organizado que possa ser usado em prompts quando e somente quando relevante. Isso evolui para o ajuste fino de partes do agente e, em seguida, para ambientes de RL de agentes — ainda parece que estamos em um estágio inicial.
*Mencionei anteriormente a delegação de tarefas para agentes de fluxo de trabalho, o que começa a fazer sentido quando seu agente se beneficiaria de não ter outros agentes de fluxo de trabalho como ferramentas (em vez de ter que descobrir uma lista de tarefas conhecida a cada vez) ou quando seu sistema é complexo o suficiente para que agentes especializados, com contexto e ferramentas especializadas, tenham um desempenho melhor. Ou ainda se você estiver utilizando agentes criados por outras pessoas (um padrão que tenho observado aqui são endpoints de API em linguagem natural para facilitar a colaboração entre agentes).
Se tivéssemos a qualidade de modelo atual com janela de conteúdo infinita (sem degradação de qualidade), poder computacional infinito, armazenamento infinito, acesso via navegador e um método de pagamento, um único loop LLM provavelmente seria suficiente para realizar muita coisa. O objetivo da observação aparentemente irrelevante acima (nada é infinito) é mostrar que a orquestração de agentes se concentra principalmente em gerenciar limitações, arquitetando maneiras de descarregar o trabalho do LLM por meio de estrutura e código.
Os agentes em produção podem ser de vários tipos: como ferramentas internas, como um produto independente que combina várias ferramentas e integrados como um recurso a uma ferramenta principal. Eles podem ser genéricos ou especializados. Agentes de chat, voz e em segundo plano parecem ser as interfaces de usuário mais comuns para acionar fluxos de agentes.
O que mais estou esquecendo?