Ao contrário dos modelos tradicionais de IA que respondem a instruções únicas (como o modo de perguntas e respostas básicas do ChatGPT), os agentes da IA podem planejar, raciocinar e executar tarefas de várias etapas, interagindo com ferramentas, fontes de dados, APIs ou mesmo outros agentes.
Parece abstrato? Isso é porque é. Embora a maioria possa concordar com essa definição ou expectativa para o que a IA Agentic pode fazer, é tão teórico que muitos agentes de IA disponíveis hoje não tornariam a nota.
Como observou meu colega Sean Falconer, os agentes da IA estão em uma “fase de pré-padrões”. Embora possamos concordar amplamente com o que eles deve ou poderia Os agentes de IA de hoje não têm a interoperabilidade de que precisam não apenas fazer algo, mas na verdade o trabalho que importa.
Pense em quantos sistemas de dados você ou seus aplicativos precisam acessar diariamente, como Salesforce, páginas wiki ou outros CRMs. Se esses sistemas não estiverem atualmente integrados ou não possuem modelos de dados compatíveis, você acabou de adicionar mais trabalho à sua programação (ou perdido tempo gasto na espera). Sem comunicação padronizada para agentes de IA, estamos apenas construindo um novo tipo de silo de dados.
Não importa como a indústria mude, ter a experiência para transformar o potencial da pesquisa de IA em sistemas de produção e resultados de negócios o diferenciará. Vou dividir três protocolos abertos que estão emergindo no ecossistema do agente e explicará como eles poderiam ajudá-lo a criar agentes úteis de IA-agentes viáveis e sustentáveis para problemas complexos do mundo real.
O estado atual do desenvolvimento do agente de IA
Antes de entrarmos nos protocolos de IA, vamos revisar um exemplo prático. Imagine que estamos interessados em aprender mais sobre a receita de negócios. Poderíamos fazer uma pergunta simples ao agente usando este prompt:
Dê -me uma previsão para a receita do terceiro trimestre para o nosso produto em nuvem.
Do ponto de vista da engenharia de software, o programa Agentic usa seus modelos de IA para interpretar essa entrada e criar um plano de execução autonomamente em relação à meta desejada. Como ele atinge esse objetivo depende inteiramente da lista de ferramentas às quais tem acesso.
Quando nosso agente despertar, ele procurará primeiro as ferramentas no diretório /ferramentas. Este diretório terá arquivos orientadores para avaliar o que está dentro de seus recursos. Por exemplo:
/ferramentas/lista
/Planejador
/Gensql
/EXECSQL
/Juiz
Você também pode olhar para ele com base neste diagrama:
Confluente
O agente principal que recebe o prompt atua como um controlador. O controlador possui recursos de descoberta e gerenciamento e é responsável por se comunicar diretamente com suas ferramentas e outros agentes. Isso funciona em cinco etapas fundamentais:
- O controlador chama o agente de planejamento.
- O agente de planejamento retorna um plano de execução.
- O juiz analisa o plano de execução.
- O controlador aproveita o GensQL e o EXECSQL para executar o plano.
- O juiz analisa o plano final e fornece feedback para determinar se o plano precisa ser revisado e executar novamente.
Como você pode imaginar, existem vários eventos e mensagens entre o controlador e o restante dos agentes. É a isso que nos referiremos como comunicação do agente de IA.
Protocolos iniciantes para comunicação do agente de IA
Uma batalha está furiosa na indústria pela maneira certa de padronizar a comunicação do agente. Como facilitamos o acesso aos agentes de IA, comunicados a outros agentes ou processar interações humanas?
Hoje, temos o Model Context Protocol (MCP), o protocolo Agent2AGENT (A2A) e o protocolo de comunicação de agentes (ACP). Vamos dar uma olhada em como esses protocolos de comunicação do agente de IA funcionam.
Modelo Protocolo de contexto
O Model Context Protocol (MCP), criado pela Anthrópico, foi projetado para padronizar como os agentes e modelos de IA gerenciam, compartilham e utilizam o contexto entre tarefas, ferramentas e raciocínio em várias etapas. Sua arquitetura cliente-servidor trata os aplicativos de IA como clientes que solicitam informações do servidor, que fornecem acesso a recursos externos.
Vamos supor que todos os dados sejam armazenados nos tópicos do Apache Kafka. Podemos construir um servidor Kafka MCP dedicado, e Claude, o modelo AI da Anthropic, pode atuar como nosso cliente MCP.
Neste exemplo, no Github, de autoria de Athavan Kanapuli, Akan pede a Claude que se conecte ao seu corretor Kafka e liste todos os tópicos que ele contém. Com o MCP, o aplicativo cliente da Akan não precisa saber como acessar o corretor Kafka. Nos bastidores, seu cliente envia a solicitação ao servidor, que cuida da tradução da solicitação e da execução da função Kafka relevante.
No caso de Akan, não havia tópicos disponíveis. O cliente pergunta se Akan gostaria de criar um tópico com um número dedicado de partições e replicação. Assim como na primeira solicitação de Akan, o cliente não requer acesso às informações sobre como criar ou configurar tópicos e partições Kafka. A partir daqui, Akan pede ao agente que crie um tópico de “países” e mais tarde descreva o tópico Kafka.
Para que isso funcione, você precisa definir o que o servidor pode fazer. No projeto Akan de Athavan Kanapuli, o código está no arquivo Handler.go. Este arquivo mantém a lista de funções que o servidor pode manipular e executar. Aqui está o CreateTopic exemplo:
// CreateTopic creates a new Kafka topic
// Optional parameters that can be passed via FuncArgs are:
// - NumPartitions: number of partitions for the topic
// - ReplicationFactor: replication factor for the topic
func (k *KafkaHandler) CreateTopic(ctx context.Context, req Request) (*mcp_golang.ToolResponse, error) {
if err := ctx.Err(); err != nil {
return nil, err
}
if err := k.Client.CreateTopic(req.Topic, req.NumPartitions, req.ReplicationFactor); err != nil {
return nil, err
}
return mcp_golang.NewToolResponse(mcp_golang.NewTextContent(fmt.Sprintf("Topic %s is created", req.Topic))), nil
}
Embora este exemplo use o Apache Kafka, uma tecnologia de código aberto amplamente adotado, antropal generaliza o método e define hosts. Os hosts são os aplicativos de modelo de idioma grande (LLM) que iniciam conexões. Todo host pode ter vários clientes, conforme descrito no diagrama de arquitetura MCP da Anthropic:

Antrópico
Um servidor MCP para um banco de dados terá todas as funcionalidades do banco de dados expostas através de um manipulador semelhante. No entanto, se você deseja se tornar mais sofisticado, pode definir modelos de prompt existentes dedicados ao seu serviço.
Por exemplo, em um banco de dados de saúde, você pode ter funções dedicadas para dados de saúde do paciente. Isso simplifica a experiência e fornece proteção rápida para proteger informações sensíveis e privadas do paciente, garantindo resultados precisos. Há muito mais a aprender, e você pode se aprofundar no MCP aqui.
Protocolo Agent2agent
O protocolo Agent2AGENT (A2A), inventado pelo Google, permite que os agentes da IA se comuniquem, colabore e coordenem diretamente entre si para resolver tarefas complexas sem estruturas ou bloqueio de fornecedores. O A2A está relacionado ao kit de desenvolvimento de agentes do Google (ADK), mas é um componente distinto e não faz parte do pacote ADK.
A2A resulta em comunicação opaca entre aplicativos agênticos. Isso significa que os agentes em interação não precisam expor ou coordenar sua arquitetura ou lógica interna para trocar informações. Isso oferece a diferentes equipes e organizações a liberdade de construir e conectar agentes sem adicionar novas restrições.
Na prática, a A2A exige que os agentes sejam descritos por metadados em arquivos de identidade conhecidos como cartões de agente. Os clientes A2A enviam solicitações como mensagens estruturadas para os servidores A2A para consumir, com atualizações em tempo real para tarefas de longa duração. Você pode explorar os conceitos principais no repositório A2A Github do Google.
Um exemplo útil de A2A é este caso de uso de assistência médica, onde os agentes de um provedor usam o protocolo A2A para se comunicar com outro provedor em uma região diferente. Os agentes devem garantir a criptografia de dados, a autorização (OAuth/JWT) e a transferência assíncrona de dados de saúde estruturados com Kafka.
Mais uma vez, confira o repositório A2A Github se quiser saber mais.
Protocolo de comunicação do agente
O Protocolo de Comunicação do Agente (ACP), inventado pela IBM, é um protocolo aberto para comunicação entre agentes, aplicações e seres humanos de IA. De acordo com a IBM:
No ACP, um agente é um serviço de software que se comunica através de mensagens multimodais, impulsionadas principalmente pela linguagem natural. O protocolo é agnóstico à forma como os agentes funcionam internamente, especificando apenas as suposições mínimas necessárias para a interoperabilidade suave.
Se você dar uma olhada nos conceitos principais definidos no repositório do ACP Github, notará que o ACP e A2A são semelhantes. Ambos foram criados para eliminar o bloqueio do fornecedor do agente, acelerar o desenvolvimento e usar metadados para facilitar a descoberta de agentes criados pela comunidade, independentemente dos detalhes da implementação. Há uma diferença crucial: o ACP permite a comunicação para os agentes, alavancando a estrutura de código aberto do BEAI da IBM, enquanto A2A ajuda agentes de diferentes estruturas a se comunicarem.
Vamos dar uma olhada mais profunda na estrutura do BEAI para entender suas dependências. A partir de agora, o projeto BEAI tem três componentes principais:
- Plataforma BEAI – para descobrir, executar e compor agentes de IA;
- BEAI Framework – para agentes de construção em Python ou TypeScript;
- Protocolo de comunicação do agente-para comunicação agente para agente.
O que vem a seguir em Agentic AI?
Em um nível alto, cada um desses protocolos de comunicação aborda um desafio ligeiramente diferente para a construção de agentes autônomos de IA:
- O MCP de antropia conecta agentes a ferramentas e dados.
- A2A do Google padroniza a colaboração agente para agente.
- O ACP da IBM se concentra na colaboração do BEEAI Agent.
Se você estiver interessado em ver o MCP em ação, confira esta demonstração sobre a consulta tópicos de Kafka com linguagem natural. Tanto o Google quanto o IBM lançaram seus protocolos de comunicação de agentes apenas recentemente em resposta ao projeto MCP bem -sucedido da Anthrópica. Estou ansioso para continuar essa jornada de aprendizado com você e ver como a adoção e a evolução deles progredem.
À medida que o mundo da IA agêntica continua a se expandir, recomendo que você priorize o aprendizado e a adoção de protocolos, ferramentas e abordagens que economizam tempo e esforço. Quanto mais adaptáveis e sustentáveis seus agentes de IA, mais você pode se concentrar em refiná-los para resolver problemas com o impacto no mundo real.
Adi Polak é diretor de consultoria e engenharia de experiência em desenvolvedores da Confluent.
–
Insights generativos de IA Fornece um local para os líderes de tecnologia – incluindo fornecedores e outros colaboradores externos – para explorar e discutir os desafios e oportunidades da inteligência artificial generativa. A seleção é ampla, desde mergulhos profundos da tecnologia a estudos de caso até opinião de especialistas, mas também subjetivos, com base em nosso julgamento de quais tópicos e tratamentos melhor atenderão ao público tecnicamente sofisticado do Infoworld. O Infoworld não aceita garantia de marketing para publicação e se reserva o direito de editar todo o conteúdo contribuído. Contato [email protected].
