Fazer com que diferentes sistemas de software se comuniquem entre si é um desafio clássico para os desenvolvedores. Durante anos, usamos APIs com regras bem definidas para que isso acontecesse. Mas agora, os modelos de linguagem ampla (LLMs) estão mudando o jogo, oferecendo uma nova maneira de os sistemas interagirem com base na compreensão da linguagem, não apenas em formatos rígidos. Isso abre possibilidades interessantes, mas também apresenta um novo conjunto de problemas a serem resolvidos, provando mais uma vez que o trabalho de um desenvolvedor nunca está realmente concluído!
Vamos explorar o que isso significa para os desenvolvedores.
Como costumávamos conectar sistemas: APIs tradicionais
Pense em como geralmente conectamos sistemas. Usamos coisas como:
- APIs REST: Geralmente usando JSON, talvez com uma especificação OpenAPI (Swagger), as APIs explicam exatamente quais dados entram e saem de um sistema, incluindo tipos de dados (como cadeias de caracteres ou números).
- RPC (Chamada de procedimento remoto): Ferramentas como o gRPC permitem que os sistemas chamem funções uns dos outros por meio de coisas como buffers de protocolo para definir exatamente o que uma função precisa e retorna.
- SOAP/WSDL: esse é um método mais antigo, mas também se baseia em uma descrição detalhada (WSDL) do serviço.
- Filas de mensagens (por exemplo, Kafka, RabbitMQ): Esses sistemas enviam mensagens para frente e para trás, geralmente seguindo um formato específico e acordado.
O ponto principal aqui é que esses métodos dependem de regras e formatos explícitos. As máquinas verificam se os dados correspondem à estrutura predefinida (o esquema ou a definição de tipo). Os desenvolvedores leem os documentos para entender o que as APIs fazem e, em seguida, escrevem o código para chamá-las na ordem em que precisam, processando os dados que elas retornam. Essa é uma dança que os desenvolvedores vêm fazendo desde o advento da computação.
Paradigmas emergentes: MCP, estruturas de agentes e APIs complementadas por prompts
A jornada das APIs tradicionais rigidamente definidas para as interações fluidas e orientadas por linguagem dos LLMs nem sempre é um salto direto para a linguagem natural pura e irrestrita de cada componente do sistema. Em vez disso, estamos vendo o surgimento de paradigmas e estruturas intermediárias poderosas projetadas para preencher essa lacuna, permitindo que os sistemas existentes e os novos serviços se tornem "consumíveis por LLM".
No centro dessas abordagens emergentes está o conceito de APIs complementadas por prompts. Em vez de exigir que um LLM intua a funcionalidade do zero ou que um desenvolvedor escreva um código adaptador complexo, nós "decoramos" ou "envolvemos" nossas APIs - sejam elas serviços REST veneráveis ou novos endpoints gRPC - com descrições ricas em linguagem natural. Essas descrições funcionam como um manual do usuário específico para um LLM, explicando a finalidade da API, como chamá-la, quais parâmetros ela espera (e em que formato) e o que ela retorna.
O MCP (Model Context Protocol), por exemplo, exemplifica uma maneira mais estruturada de expor um conjunto diversificado de recursos a um plano de controle baseado em LLM. Os sistemas podem declarar seus serviços e as ações que eles suportam, juntamente com metadados e descrições de linguagem natural. Um LLM pode, então, consultar esse "menu" de recursos declarados e orquestrar chamadas para esses serviços subjacentes com base em solicitações de usuários ou objetivos de nível superior, compreendendo o que eles fazem e como usá-los por meio de suas interfaces declaradas e semelhantes a prompts.
Isso está intimamente ligado ao mundo em rápida evolução das estruturas de agentes. Essas estruturas geralmente fornecem os andaimes para a criação de um agente de controle principal, alimentado por LLM. Esse agente central atua como um orquestrador ou um "cérebro", capaz de raciocinar, planejar e delegar tarefas. O verdadeiro poder vem quando esse agente de controle tem acesso a um conjunto de "ferramentas" ou subagentes.
Esses subagentes podem variar significativamente:
- Alguns podem ser outros agentes especializados baseados em LLM, projetados para tarefas específicas, como análise de dados complexos ou geração de conteúdo criativo.
- Outros podem ser módulos de software mais simples ou, o que é mais importante, invólucros de APIs tradicionais existentes. Nesse cenário, um desenvolvedor cria um wrapper leve em torno de, por exemplo, uma API interna de gerenciamento de pedidos. Esse invólucro não expõe apenas os pontos de extremidade técnicos; ele inclui prompts cuidadosamente elaborados que descrevem as funções da API em linguagem natural: "Esta ferramenta permite que você obtenha o status do pedido. Ela requer um 'order_id' como entrada e retornará o status atual, a data de entrega estimada e os itens do pedido."
A linha comum desses paradigmas é clara: a API, seja um microsserviço totalmente novo ou um sistema legado exposto por meio de um wrapper, não é mais apenas um contrato técnico. Ela é complementada por uma camada de prompts descritivos. Isso permite que um LLM consumidor (normalmente um agente de controle) descubra, compreenda e utilize dinamicamente uma vasta gama de ferramentas e recursos. O LLM não precisa conhecer os intrincados detalhes de implementação de cada ferramenta; ele só precisa entender a descrição baseada em prompts de como usá-la. Essa mudança altera fundamentalmente a forma como pensamos sobre a integração do sistema e dá uma ênfase ainda maior à clareza, precisão e abrangência desses prompts descritivos, que exploraremos mais adiante.
O futuro é... diferente
Passar de APIs rígidas e baseadas em formato e até mesmo dessas interfaces emergentes com prompt aumentado para interações baseadas em linguagem realmente difundidas com LLMs é uma grande mudança. Como desenvolvedor, acostumei-me com o fato de ter uma definição clara das possíveis entradas, saídas e mensagens de erro. Trabalhar com LLMs traz uma enorme quantidade de recursos que nunca tivemos. Mas também está prestes a redefinir a forma como você tem interagido com outros sistemas. Como desenvolvedores, entender como criar prompts precisos e abrangentes para descrever os recursos está se tornando cada vez mais importante, especialmente à medida que criamos sistemas em que vários agentes de IA podem precisar colaborar.
Comentários