Autor: Zack Pokorny, investigador associado de pesquisas na Galaxy Digital; Fonte: Galaxy Digital; Compilado por: Shaw Golden Finance

Introdução

Os casos de uso e capacidades de agentes de inteligência artificial (AI Agent) começaram a evoluir gradualmente. Estão a concretizar a execução autónoma de tarefas, e o desenvolvimento relacionado está a avançar com funcionalidades como deter e configurar fundos, descobrir estratégias de transacção e de rendimentos, entre outras. Embora esta transição experimental ainda esteja numa fase muito inicial, a sua direcção já é radicalmente diferente da anterior — no passado, a maioria dos agentes era usada sobretudo como ferramentas de socialização e de análise.

A blockchain está a oferecer um terreno de experimentação natural para esta evolução. A blockchain tem características sem permissão e é combinável (ou seja, o mesmo quadro de execução pode albergar aplicações de vários componentes financeiros de base), possui um ecossistema de aplicações open source, disponibiliza os dados de forma equitativa a todos os participantes e, além disso, todos os activos na cadeia suportam por predefinição a programabilidade.

Daqui surge uma questão estrutural: já que a blockchain é programável e sem permissão, porque é que um agente autónomo ainda enfrenta obstáculos de execução? A resposta não está em saber se a execução é viável, mas sim em perceber o quão grande é o custo de compreensão semântica e de escalonamento/coordenação necessário acima da camada de execução. A blockchain consegue assegurar a exactidão das transições de estado, mas normalmente não disponibiliza capacidades abstractas nativas de protocolo como interpretação económica, identidade padrão ou escalonamento de níveis de objectivos.

Parte destes obstáculos provém das características de arquitectura dos sistemas sem permissão; outra parte vem do estado de desenvolvimento das actuais ferramentas, da selecção de informação e da infra-estrutura de mercado. Em aplicações reais, muitas funções de camada superior ainda dependem de software e fluxos de trabalho desenhados com o humano como núcleo da operação.

Arquitectura de blockchain e agentes de inteligência artificial

O núcleo do desenho da blockchain assenta no mecanismo de consenso e na execução determinística, e não na interpretação semântica. O que oferece externamente são componentes base como slots de armazenamento, logs de eventos e rastreio de chamadas, e não objectos económicos padronizados. Assim, conceitos abstractos como posições de carteira, rendimento, coeficientes de saúde, profundidade de liquidez, etc., normalmente precisam de ser reconstruídos off-chain por indexadores, camadas de análise, interfaces front-end e interfaces de programação de aplicações, convertendo o estado específico de cada protocolo em formas mais utilizáveis.

Muitos dos fluxos operacionais mais comuns em finanças descentralizadas, especialmente os voltados para utilizadores comuns e para operações de decisão subjectiva, ainda utilizam o modo central de o utilizador interagir com a interface front-end e confirmar por assinatura de uma transacção de cada vez. Este modelo centrado na interface do utilizador, ao acompanhar a massificação de utilizadores comuns, possibilitou aplicações em escala, mesmo que uma parte considerável das actividades on-chain já seja conduzida por máquinas. A lógica actual dominante de interacção com utilizadores comuns é ainda: intenção de operação → interface do utilizador → iniciar transacção → confirmar a conclusão. Embora a operação programática siga caminhos diferentes, também tem limitações próprias: o programador precisa de seleccionar, na fase de construção, o âmbito de contratos e activos e, com base nesse âmbito fixo, executar algoritmos. Nenhum dos dois modelos consegue adaptar-se a sistemas que, durante a execução, comecem por descobrir, avaliar e combinar autonomamente comportamentos de operação com base em objectivos dinâmicos.

Quando a utilização de infra-estruturas optimizadas para validação de transacções passa a ser exigida por sistemas que, em simultâneo, interpretam estados económicos, avaliam crédito e optimizam comportamentos em torno de objectivos bem definidos, os obstáculos começam a aparecer. Uma parte dessa diferença surge das características do desenho sem permissão e heterogéneo da blockchain; outra parte advém do facto de as ferramentas existentes continuarem a encapsular o fluxo de interacção com a blockchain em torno de auditoria humana e mediação front-end.

Fluxo de operação dos agentes e estratégias algorítmicas tradicionais

Antes de analisar a diferença entre infra-estrutura de blockchain e sistemas de agentes, é necessário clarificar o fluxo de operação de agentes de nível mais elevado e as diferenças fundamentais em relação aos sistemas tradicionais de algoritmos on-chain.

A diferença entre ambos não está na automatização, nem na complexidade técnica, nem na configuração paramétrica, e nem mesmo na capacidade de adaptação dinâmica. Os sistemas algorítmicos tradicionais conseguem ser altamente parametrizados, descobrir automaticamente novos contratos e tokens, alocar fundos entre vários tipos de estratégias e fazer rebalanceamento com base no desempenho. A diferença central reside em saber se o sistema consegue lidar com cenários não previstos na fase de construção.

Independentemente de quão complexos sejam, os sistemas algorítmicos tradicionais conseguem executar apenas uma lógica definida para padrões que foram previstos na fase de desenvolvimento. Esses sistemas necessitam de configurar para cada tipo de protocolo analisadores (parsers) de interface pré-definidos, uma lógica de avaliação predefinida que converta o estado do contrato em significado económico e regras claras de determinação de crédito e padrões. Além disso, todos os ramos de decisão precisam de regras hard-coded (por mais dinâmico e flexível que o algoritmo em si seja). Quando surge uma situação que não corresponde ao padrão previsto, o sistema ou ignora esse cenário, ou simplesmente falha na execução. Não consegue raciocinar sobre cenários desconhecidos; apenas consegue verificar se o cenário actual corresponde a modelos conhecidos.

_Como um dispositivo mecânico automático, como este “patinho que digere” (consome), pode imitar um comportamento convincente, mas cada acção é previamente definida. ( _《Ciência Americana》, janeiro de 1899년 __ )

Quando o algoritmo tradicional faz varrimento de um novo mercado de empréstimos, consegue identificar eventos familiares de origem, ou contratos implantados que correspondem a padrões de fábrica conhecidos. Mas se surgir uma nova infra-estrutura de base de empréstimos com uma interface desconhecida, o sistema não consegue avaliá-la. É necessário que um humano verifique o contrato, compreenda o seu mecanismo de funcionamento, determine se deve ser incluído no pool de oportunidades e escreva a lógica de integração. Só depois de completar estas etapas é que o algoritmo consegue interagir com ela. O humano interpreta; o algoritmo executa. E sistemas de agentes baseados em modelos rompem essa fronteira. Podem, através de capacidades de raciocínio adquiridas, realizar:

• Interpretar objectivos pouco claros ou não especificados de forma explícita. Instruções como “maximizar rendimento, mas evitar risco excessivo” exigem interpretação: o que é “risco excessivo”? Como equilibrar rendimento e risco? Algoritmos tradicionais precisam definir com antecedência estas condições de forma precisa; um modelo base consegue interpretar a intenção, tomar decisões e optimizar a sua compreensão com base no feedback.

• Generalizar e adaptar-se a novas interfaces. O agente pode ler o código de contratos desconhecidos, analisar documentação, ou verificar interfaces binárias de aplicações (ABI) que nunca viu antes, e inferir as funcionalidades económicas desse sistema. Não precisa construir previamente analisadores para cada tipo de protocolo. Actualmente, esta capacidade ainda não está perfeita; o agente pode fazer interpretações erradas, mas consegue tentar interagir com sistemas que não foram previstos na fase de desenvolvimento.

• Raciocinar sobre fiabilidade e conformidade sob incerteza. Quando os sinais de confiança são ambíguos ou incompletos, o modelo base pode ponderar probabilisticamente as decisões, em vez de aplicar regras binárias simples. Este contrato inteligente é a versão oficial? Dadas as evidências existentes, este token é provavelmente legítimo? Algoritmos tradicionais têm apenas dois estados — “com regras” ou “sem regras”; já um agente consegue raciocinar com base na confiança.

• Interpretar erros e ajustar-se de forma adaptativa. Quando surgem situações inesperadas (por exemplo, revert de transacções, saída que não corresponde ao esperado, ou mudança de estado entre simulação e execução), o agente consegue inferir a causa do problema e decidir como lidar. Em contraste, algoritmos tradicionais limitam-se a executar blocos de captura de excepções, tratando apenas a divisão do fluxo para excepções, em vez de interpretarem a excepção.

Estas capacidades existem de facto, mas ainda não estão perfeitas. O modelo base pode alucinar, interpretar mal a informação e tomar decisões incorrectas com uma confiança aparente. Num ambiente adversarial e com envolvimento de fundos (isto é, quando o código pode ser controlado ou os activos podem ser recebidos), “tentar interagir com sistemas não previstos” pode significar perder dinheiro directamente. O ponto central deste artigo não é que agentes consigam hoje completar estas funções de forma fiável, mas sim que podem tentar de formas que os sistemas tradicionais não conseguem, e que a infra-estrutura futura tem potencial para tornar essas tentativas mais seguras e mais fiáveis. É mais fácil compreender ambos como um espectro contínuo, em vez de classificações absolutas: alguns sistemas tradicionais já incorporaram raciocínio do tipo aprendizagem, e alguns agentes também podem depender de regras hard-coded em caminhos críticos. A diferença entre ambos é orientacional, não binária. O sistema de agentes coloca mais trabalho de interpretação, avaliação e adaptação no raciocínio em tempo de execução, em vez de o predefinir na fase de desenvolvimento. Isto está intimamente relacionado com a argumentação de obstáculos anterior, porque o que os agentes tentam fazer é exactamente o que os algoritmos tradicionais evitam totalmente. Algoritmos tradicionais evitam custos de descoberta filtrando conjuntos de contratos manualmente na fase de desenvolvimento; evitam custos de camada de controlo através de white lists mantidas por operadores; evitam custos de dados ao pré-configurar analisadores para protocolos conhecidos; e evitam custos de execução ao operar dentro de limites de segurança predefinidos. Ao fazer manualmente com antecedência o trabalho semântico, de confiança e de camadas de estratégia, o algoritmo só executa dentro dos limites definidos. As primeiras versões do fluxo de operação de agentes on-chain podem manter este padrão, mas a sua lógica central reside em transferir a descoberta, a avaliação de confiança e a avaliação de estratégia para o raciocínio em tempo de execução, em vez de as predefinir na fase de desenvolvimento.

Os agentes podem tentar descobrir e avaliar oportunidades desconhecidas, julgar a conformidade dos contratos sem regras hard-coded, interpretar estados heterogéneos sem analisadores pré-definidos e executar estratégias para objectivos potencialmente vagos. E é precisamente nesses pontos que a insuficiência da infra-estrutura começa a evidenciar-se. A existência de obstáculos não se deve ao facto de os agentes estarem a fazer as mesmas coisas que os algoritmos, mas com mais dificuldade; deve-se ao facto de estarem a tentar fazer coisas completamente diferentes: operar em espaços de acção abertos e interpretáveis dinamicamente, em vez de em espaços fechados e previamente integrados e fixos.

Localização do atrito

Em termos estruturais, esta contradição não decorre de falhas no consenso da blockchain, mas do modo como o ecossistema completo de camadas de interacção construídas em torno dela evoluiu.

A blockchain garante transições determinísticas de estado, consenso sobre o estado final e determinação final. Mas não codifica a interpretação económica, a validação de intenções ou o acompanhamento de objectivos ao nível do protocolo. Estas responsabilidades têm sido historicamente assumidas por camadas cooperativas off-chain como front-end, carteiras (wallets), indexadores e outras camadas. E, no fluxo, há sempre participação humana.

Os padrões de interacção dominantes também reflectem este desenho, mesmo para participantes profissionais: utilizadores comuns interpretam o estado através de painéis, escolhem operações através da interface, e assinam transacções com a carteira — não validam formalmente os resultados. Instituições de trading algorítmico automatizam a execução, mas continuam a depender de filtragem manual dos conjuntos de protocolos, verificação de anomalias e actualização da lógica de integração quando as interfaces mudam. Nos dois cenários, o protocolo garante apenas a correcção da execução; a interpretação da intenção, o tratamento de excepções e a adaptação a novas oportunidades continuam a ser feitas por humanos.

Os sistemas de agentes comprimem — ou até eliminam — esta divisão. Têm de reconstruir programaticamente estados com significado económico, avaliar se o objectivo é encaminhado/avança, e verificar o resultado para além de simplesmente enviar uma transacção simples on-chain. Estes encargos destacam-se ainda mais na blockchain, porque os agentes operam em ambientes abertos, adversariais e em rápida mudança, onde novos contratos, activos e caminhos de execução podem surgir sem auditoria descentralizada. O protocolo garante apenas a execução correcta de transacções, não garante que o estado económico seja fácil de interpretar, que o contrato seja a versão oficial, que o caminho de execução corresponda à intenção do utilizador, ou que as oportunidades relevantes sejam descobertas de forma programável.

Os capítulos seguintes analisarão estes obstáculos em cada fase do ciclo de execução dos agentes: descobrir contratos e oportunidades existentes, verificar a sua legitimidade, obter estados com significado económico e executar segundo o objectivo.

Custos de descoberta

A origem dos custos de descoberta está no facto de o espaço de acção DeFi (finanças descentralizadas) continuar a expandir num ambiente aberto e sem permissão, enquanto a relevância e a legitimidade precisam de ser filtradas por humanos através de camadas sociais on-chain, mercado e ferramentas. Novos protocolos são filtrados através de anúncios e publicações de investigação, mas também através de camadas de filtragem como integrações no front-end, listas de tokens, plataformas de análise e formação de liquidez. Com o tempo, estes sinais tendem a formar um conjunto de critérios operáveis para identificar as partes do espaço de acção que têm valor económico e são suficientemente fiáveis, mesmo que o processo seja frequentemente informal e desequilibrado, e que uma parte dependa de terceiros e de selecção humana.

Embora os agentes possam obter dados filtrados e sinais de confiança, não têm a vantagem natural de um humano ao interpretar esses sinais. Do ponto de vista on-chain, a detectabilidade de todos os contratos já implantados é igual. Protocolos legítimos, forks maliciosos, deploys de testes e projectos abandonados — todos existem como bytecode chamável. A cadeia não marca quais são importantes ou quais são seguros.

Do ponto de vista on-chain, todos os contratos já implantados têm a mesma detectabilidade. Protocolos legítimos, contratos de forks maliciosos, contratos de deploy de testes e projectos abandonados aparecem todos como bytecode chamável.

Assim, o agente tem de construir o mecanismo de descoberta por conta própria: fazer varrimento de eventos de implantação, identificar padrões de interface, rastrear contratos de fábrica (contratos que implantam outros contratos de forma programática) e monitorizar a formação de liquidez para determinar quais contratos devem ser incluídos no âmbito da decisão. Este processo não é apenas encontrar contratos; é também avaliar se vale a pena incluí-los no espaço de acção do agente.

Identificar contratos candidatos é apenas o primeiro passo. Depois da descoberta inicial filtrar os contratos, estes ainda passam pelo processo de validação de conformidade e de veracidade descrito na secção seguinte. O agente precisa de confirmar que os contratos descobertos correspondem às suas afirmações para poder incorporá-los no espaço de decisão.

Descoberta com restrição de estratégia é diferente de descoberta aberta

Os custos de descoberta não se referem à detecção de novos deploys. Sistemas algorítmicos maduros já conseguem fazer isso dentro do âmbito das suas próprias estratégias. Por exemplo, um pesquisador/“searcher” que monitoreia eventos da fábrica Uniswap e inclua automaticamente novas pools de liquidez está a fazer descoberta dinâmica. Os obstáculos surgem em níveis dois patamares acima: julgar se os contratos descobertos são legítimos (o problema de conformidade será discutido na próxima secção); e julgar se servem objectivos abertos, e não apenas se adaptam a um tipo de estratégia previamente definida.

A lógica de descoberta do searcher está estreitamente ligada à sua estratégia. Ele sabe que padrões de interface deve procurar, porque a estratégia já está definida de antemão. Já um agente encarregado de uma tarefa mais abrangente como “configurar a melhor oportunidade com ajuste óptimo de risco” não pode depender apenas de filtros derivados da estratégia. Tem de avaliar as oportunidades confrontando-as com o próprio objectivo: isso exige interpretar interfaces desconhecidas, inferir a funcionalidade económica e julgar se essa oportunidade deve ser incluída no espaço de decisão. Esta parte pertence a um problema geral de autonomia; mas a blockchain agrava a dificuldade: código desconhecido é executável directamente, carrega fundos e, apenas com sinais nativos do protocolo, não é possível classificá-lo.

Atrito na camada de controlo

O custo da camada de controlo surge porque a identidade e a legitimidade, em geral, são determinadas fora do protocolo através de filtragem, governação, documentação, interfaces e decisões de operadores. Nos actuais fluxos de trabalho, o humano ainda é uma parte importante do processo de decisão. A blockchain garante execução determinística e determinação final, mas não garante que o chamador está a interagir com o contrato-alvo certo. A validação de intenções é delegada a contextos sociais, sites e filtragem humana.

No fluxo actual, os humanos usam a camada de confiança do site como ferramenta de verificação informal: por exemplo, encontrar domínios oficiais através de plataformas agregadoras como DeFiLlama ou de contas sociais certificadas dos projectos, e tratar esse site como mapeamento oficial entre um conceito humano e um endereço de contrato. Em seguida, o front-end codifica um conjunto de fontes de verdade válidas, indicando quais endereços são oficiais, que tipo de token representa os activos, e quais entradas são seguras.

O turco mecânico de 1789 (Mechanical Turk) é uma máquina de jogar xadrez que, à primeira vista, parece executar de forma autónoma, mas na realidade depende de um operador humano escondido. (Biblioteca da Universidade de Humboldt)

Por predefinição, os agentes não interpretam marcas, sinais sociais verificados ou “oficialidade” através de contextos sociais. Podemos fornecer ao agente entradas filtradas derivadas desses sinais; mas para as converter em hipóteses de confiança estáveis e utilizáveis por máquinas, é necessário definir um registo, regras de política ou lógica de validação. Os operadores podem configurar para os agentes white lists seleccionadas, endereços certificados e políticas de confiança. O problema não é que os contextos sociais sejam completamente inacessíveis; o problema é que, num espaço de acção em expansão dinâmica, manter continuamente estas barreiras de protecção acarreta uma carga operacional enorme — e quando essas barreiras faltam ou são incompletas, o agente não tem mecanismos de verificação de reserva que um humano usaria de forma intuitiva.

As consequências reais desta insuficiência de capacidade de avaliação de confiança já se fizeram ver em sistemas de agentes on-chain. O criador de conteúdo e influenciador cripto Orangie, do YouTube, já passou por um caso em que um agente colocou fundos num contrato “isca de abelhas” (honeypot). Num outro incidente, um agente chamado Lobstar Wilde, devido a falhas de estado ou de contexto, interpretou erradamente o estado do endereço e transferiu um grande saldo de tokens para um “endereço de esmolas” online. Estes casos não constituem o argumento central deste artigo, mas ilustram de forma intuitiva que erros na avaliação de confiança, na interpretação de estado e nas estratégias de execução levam directamente a perdas de fundos.

A identificação de contratos oficiais não é uma funcionalidade nativa do protocolo

O problema não é que os contratos sejam difíceis de descobrir; é que, em geral, não existe on-chain o conceito nativo de “este é o contrato oficial de uma aplicação X”. Esta ausência é, em certa medida, uma característica de sistemas sem permissão e não uma omissão de design, mas ainda assim cria um problema de coordenação para sistemas autónomos. Parte do problema vem das características de arquitectura de um sistema aberto com identidade fraca; parte vem de que registos, padrões e mecanismos de distribuição de confiança ainda não estão maduros. Se um agente quiser interagir com o Aave v3, precisa determinar quais endereços são oficiais (pool de fundos, configuradores, fornecedores de dados, etc.) e se esses endereços são contratos imutáveis, contratos actualizáveis via proxy, ou se estão em estado de proposta de governação em mudança aguardando execução.

Os humanos resolvem esse problema via documentação, interfaces front-end e redes sociais; já os agentes têm de determinar através de verificação as seguintes informações:

• o modo de proxy e os contratos de implementação apontados

• permissões de administração e contratos de timelock

• módulos de actualização de parâmetros sob controlo de governação

• correspondência de bytecode / interfaces binárias de aplicações (ABI) entre contratos de deploy conhecidos

Na ausência de um registo oficial, “oficialidade” transforma-se num problema de inferência. Isso significa que o agente não pode tratar o endereço do contrato como uma configuração estática. Ou mantêm continuamente white lists seleccionadas verificadas, ou deduz novamente a conformidade do contrato em tempo de execução por meio de verificação de proxy e monitorização de governação, ou assume o risco de interagir com contratos descontinuados, atacados ou falsificados. Em software tradicional e infra-estruturas de mercado, a identidade do serviço costuma ser ancorada por namespaces de nomeação, credenciais e controlo de acesso mantidos por instituições. Em contrapartida, on-chain, um contrato pode ser chamável e funcionar, mas do ponto de vista do chamador, pode não ser oficial em termos económicos ou de negócio.

A autenticidade de tokens e o problema de metadados são essencialmente o mesmo

Os tokens parecem auto-descrever, mas os seus metadados não são autoritativos; são apenas dados em bytes devolvidos pelo código do contrato. Um caso típico é o token encapsulado de Ether (WETH). Entre os contratos WETH amplamente utilizados, é definida de forma explícita:

Estas informações aparentam representar identidade, mas na realidade não. Qualquer contrato pode devolver o seguinte:

• symbol() = “WETH”

• decimals() = 18

• name() = “Wrapped Ether”

E implementar exactamente a mesma interface padrão de token ERC-20. name(), symbol() e decimals() são apenas funções públicas somente de leitura, e o conteúdo devolvido é definido integralmente pelo deployer. Na verdade, já existem quase 200 tokens na Ethereum com o nome “Wrapped Ether”, com símbolo “WETH” e com precisão de 18 casas decimais. Se não verificar CoinGecko ou Etherscan, consegue distinguir qual “WETH” é o oficial? (A resposta é o 78.º da lista)

Existem quase 200 tokens na Ethereum com o nome “Wrapped Ether” e o símbolo “WETH”. Sem recorrer a plataformas de terceiros, consegues determinar qual é o WETH genuíno?

Este é o cenário em que os agentes se encontram. A blockchain não valida a unicidade, não verifica contra nenhum registo e não se importa com isso. Hoje já pode fazer deploy de 500 contratos, todos devolvendo exactamente os mesmos metadados. On-chain também existem alguns métodos empíricos de avaliação (por exemplo, comparar o saldo de ETH com a oferta total, consultar a profundidade de liquidez dos principais DEXs descentralizados, verificar se é listado como colateral por protocolos de empréstimo), mas nenhuma abordagem consegue fornecer uma prova absoluta e irrefutável. Cada método depende ou de pressupostos de limiar (ninguém consegue falsificar emparelhamentos com liquidez em escala de centenas de milhões/bilhões), ou de validação recursiva que exige primeiro verificar a conformidade de outros contratos.

Como num labirinto, identificar no on-chain o caminho “verdadeiro” requer orientação externa; não existe qualquer sinal padrão. (Museu e Galerias de Birmingham)

É por isso que existem listas de tokens e registos como camada de filtragem off-chain. Fornecem um mecanismo para mapear o conceito de “WETH” para um endereço específico, e é também por isso que as carteiras e o front-end mantêm white lists ou dependem de agregadores considerados fiáveis. Para o agente, o problema principal não é apenas que os metadados não são fiáveis; é que a identidade normativa é geralmente estabelecida por camadas sociais ou institucionais, e não é nativa do protocolo. O único identificador fiável on-chain é o endereço do contrato; porém, para mapear uma intenção compreensível para humanos (como “converter para USDC”) para o endereço correcto, ainda é altamente dependente de filtragem, registos, white lists ou outras camadas de confiança que não são nativas do protocolo.

Atrito de dados

Um agente que optimiza entre vários protocolos DeFi precisa abstrair cada oportunidade de forma unificada como um objecto económico: rendimento, profundidade de liquidez, parâmetros de risco, estrutura de taxas, fonte de oráculos, etc. De certo ponto de vista, isto é um problema comum de integração de sistemas. Mas em blockchain, devido à heterogeneidade dos protocolos, ao risco directo de fundos, à composição de estados através de múltiplas chamadas e à falta, na camada base, de um schema económico unificado, este encargo é ampliado significativamente. E são justamente estas as informações necessárias para comparar oportunidades, simular configurações e monitorizar riscos.

Na camada de protocolo, a blockchain normalmente não expõe objectos económicos padronizados; apenas expõe slots de armazenamento, logs de eventos e valores devolvidos por funções. Os objectos económicos têm de ser deduzidos ou reconstruídos a partir disso. O protocolo garante apenas que o contrato chamado devolve correctamente os valores de estado; não garante que esse valor se corresponda de forma clara a conceitos económicos compreensíveis, nem garante que o mesmo conceito possa ser obtido entre diferentes protocolos através de uma interface consistente.

Por isso, conceitos abstractos como mercado, posições e coeficientes de saúde não são componentes nativos dos protocolos; são reconstruídos off-chain por indexadores, plataformas de análise, front-ends e APIs, normalizando estados heterogéneos de protocolos para uma camada abstracta utilizável. Utilizadores humanos normalmente apenas vêem esses dados normalizados; os agentes também podem usá-los. Mas ao fazê-lo, herdam o schema de terceiros, atrasos e hipóteses de confiança; caso contrário, terão de reconstruir essas lógicas abstractas por conta própria.

Este problema agrava-se ainda mais entre diferentes tipos de protocolos. Preços de quotas em cofres, taxas de colateral em mercados de empréstimo, profundidades de liquidez em pools de DEX, taxas de recompensa de contratos de staking — tudo são indicadores base com significado económico, mas nenhum deles é exposto por uma interface padronizada. Cada ecossistema de protocolo tem o seu próprio modo de leitura, formatos de structs e convenções de unidades; mesmo para a mesma categoria, os modos de implementação diferem.

Mercados de empréstimo: um exemplo típico de leitura fragmentada

Os mercados de empréstimo mostram claramente este problema. Conceitos económicos são geralmente semelhantes e universais, como liquidez de fornecimento e empréstimo, taxas de juro, coeficientes de colateral, limites de crédito, limiares de liquidação, etc.; mas os caminhos de leitura dos dados são completamente diferentes.

Tomando como exemplo o Aave v3, a enumeração do mercado e a leitura do estado de activos de reserva são passos separados. O fluxo típico é o seguinte:

Listar os activos de reserva através de:

Esta função devolve um array de endereços de tokens.

Para cada activo, obter dados base de liquidez e de taxa de juro através de:

Esta chamada devolve uma struct com dados que podem ser obtidos de uma única vez, incluindo, por exemplo, quantidade total de liquidez, índice de taxas de juro e um identificador de configuração, tais como:

Em contraste, no Compound v3 (Comet), cada deploy corresponde a um único mercado (como USDC, USDT, ETH, etc.), e não existe uma struct unificada de reserva. Portanto, é necessário efectuar múltiplas chamadas de função para montar dados de snapshot completo do mercado:

Utilização base

Total

Juros

Configuração de activos de colateral

Parâmetros de configuração global

Cada chamada devolve apenas diferentes fragmentos do estado económico. “Mercado” não é um objecto de primeira classe; é uma estrutura inferida e montada pelo chamador.

Do ponto de vista de um agente, estes dois protocolos pertencem ao mesmo tipo de mercado de empréstimo. Mas do ponto de vista de integração, ambos são sistemas de obtenção de dados com estrutura totalmente diferente. Não existe uma estrutura de dados universal como a seguinte:

Pelo contrário, um agente precisa usar um método de enumeração de activos diferente para cada protocolo, fazer múltiplas chamadas para compor dados de estado, uniformizar unidades de medida e regras de conversão, e coordenar as diferenças entre valores inferidos e dados básicos expostos directamente.

Fragmentação traz risco de atraso e de consistência

Além da falta de uniformidade estrutural, esta fragmentação também gera riscos de atraso e consistência. Como o estado económico não é exposto como um objecto único e atómico de mercado, o agente tem de fazer múltiplas chamadas remotas (RPC) para vários contratos, para reconstruir um snapshot de estado. Quanto mais chamadas, maior o atraso, maior a probabilidade de disparar rate limits da interface e maior o risco de inconsistência entre blocos. Num ambiente de volatilidade de mercado, quando o cálculo da taxa de juro de fornecimento termina, a taxa de utilização dos fundos pode já ter mudado; se não estiver claramente bloqueada a altura do bloco, os parâmetros de configuração e a quantidade total de liquidez podem não ter origem no mesmo bloco. Utilizadores humanos mitigam implicitamente este problema através da camada de cache do front-end e do backend agregado; já um agente que chama directamente as APIs RPC originais precisa tratar explicitamente problemas de sincronização de dados, pedidos em lote e consistência temporal. Assim, a ausência de obtenção de dados padronizada não é apenas um inconveniente de integração; também impõe limitações sobre desempenho, mecanismos de sincronização e correcção de execução.

A falta de uma norma unificada de obtenção de dados económicos significa que, mesmo que diferentes protocolos implementem quase as mesmas funções financeiras de base, o modo de exposição do estado continua a ser específico de cada contrato e dependente de lógica de composição. Essa diferença estrutural é a causa central do atrito de dados.

Possível desfasamento de fluxo de dados

O acesso ao estado económico on-chain é, em essência, um modelo de pull (puxar). Mesmo que os sinais de execução possam ser enviados em streaming (push), sistemas externos precisam consultar activamente os estados necessários aos nós, em vez de receber actualizações contínuas e estruturadas. Este padrão reflecte a função central da blockchain — validação sob demanda, e não manutenção de uma visão contínua de estado a nível de aplicação.

Existem também componentes base em modo push na cadeia. Subscrições WebSocket podem empurrar em tempo real novos blocos e logs de eventos; porém, estes não incluem o estado de armazenamento que carrega a maior parte do significado económico, a menos que o protocolo escolha redundância e registre isso explicitamente em logs. O agente não consegue obter directamente on-chain a taxa de utilização do mercado de empréstimos, a quantidade de reservas do pool ou o coeficiente de saúde das posições através de subscrições. Esses valores são guardados no espaço de armazenamento do contrato, e a maioria dos protocolos não oferece mecanismos nativos para empurrar mudanças de armazenamento para utilizadores downstream. O modo mais viável actualmente é subscrever cabeçalhos de novos blocos e, em cada bloco, consultar novamente o estado de armazenamento — mesmo que seja desencadeado por eventos em streaming, o acesso ao estado continua fundamentalmente a ser pull. Os logs apenas indicam que os dados podem ter mudado, mas não codificam o estado económico final; reconstruir esse estado ainda exige leituras explícitas e acesso a estados históricos.

Os sistemas de agentes, pelo contrário, são mais adequados a fluxos de dados no sentido inverso. O agente não precisa de fazer polling de alterações de estado de centenas de contratos; pode receber actualizações estruturadas e pré-computadas e empurrá-las directamente para o seu ambiente de execução (por exemplo, actualizações de utilização, coeficientes de saúde ou variações das posições). Uma arquitectura push pode reduzir consultas redundantes, diminuir a latência entre a mudança de estado e a percepção pelo agente e permitir que uma camada intermédia encapsule estados em actualizações com semântica clara, em vez de deixar o agente interpretar os significados a partir de armazenamento bruto.

Esta mudança de padrão não é fácil. Requer infraestrutura de subscrição, lógica para filtrar relevância e uma especificação de eventos económicos para converter mudanças de armazenamento em acções executáveis pelo agente. Mas à medida que os agentes se tornam participantes continuamente online, em vez de meros consultores intermitentes, os problemas de ineficiência do modo pull — rate limits, overhead de sincronização e consultas repetidas entre agentes — tornar-se-ão cada vez mais graves. Infraestrutura em que o agente é tratado como consumidor contínuo, e não como cliente intermitente, talvez se adapte melhor ao modo de operação de sistemas autónomos.

Ainda não há consenso sobre se uma infraestrutura push é realmente superior. Um fluxo de dados com mudanças completas de estado cria problemas de filtragem; os agentes ainda precisam decidir que informações são relevantes, o que reintroduz lógica pull noutra camada. O ponto central não é que o modo pull em si esteja errado, mas que a arquitectura actual não foi desenhada considerando utilizadores persistentes de máquinas; com o aumento da escala de uso de agentes, vale a pena explorar alternativas.

Atrito na execução

O atrito na execução surge porque muitas das actuais camadas de interacção convertem intenção, fazem auditoria de transacções e verificam resultados, encapsulando tudo num fluxo de trabalho centrado em front-end, carteiras e supervisão humana. Em cenários comuns de utilizador e de decisão subjectiva, esta supervisão é normalmente feita por humanos. Para sistemas autónomos, essas funções precisam de ser formalizadas e codificadas directamente. A blockchain consegue assegurar execução determinística conforme a lógica de contratos, mas não garante que a transacção corresponda à intenção do utilizador, respeite restrições de risco ou produza o resultado económico esperado. No fluxo actual, o front-end e os humanos preenchem essa lacuna.

O front-end orquestra a sequência de operações (trocar, autorizar, depositar, emprestar), a carteira fornece o ponto de controlo final de “revisar e enviar” e o utilizador ou operador normalmente faz, informalmente, a decisão de estratégia na etapa final. Frequentemente, com informação incompleta, avaliam se a transacção é segura e se o resultado da cotação é aceitável. Se a transacção falhar ou surgir um resultado inesperado, o utilizador tenta de novo, ajusta o slippage, muda o caminho ou simplesmente abandona a operação. Ao remover os humanos desse ciclo de execução, o sistema de agentes significa que a máquina deve substituir três tipos de funções humanas com lógica nativa:

1. Compilação de intenção. Objectivos humanos como “configurar os meus stablecoins no melhor canal de rendimento ajustado ao risco” devem ser compilados num plano de acção concreto: escolher qual protocolo, qual mercado, qual caminho de token, o tamanho da operação, o modo de autorização e a ordem de execução. Para humanos, este processo é feito implicitamente via front-end; para agentes, deve ser implementado de forma formal.

2. Execução da estratégia. Clicar em “enviar transacção” não é apenas um acto de assinatura; é também uma validação implícita de se a transacção cumpre restrições: tolerância ao slippage, limite máximo de alavancagem, saúde mínima do fundo/posição, contratos com white list ou “proibir contratos actualizáveis”, etc. O agente precisa codificar restrições explícitas da estratégia como regras verificáveis por máquina:

Antes de o sistema de execução transmitir a transacção, tem de verificar se o grafo de relações de chamadas a executar cumpre essas regras.

1. Validação do resultado. Executar on-chain não significa necessariamente que a tarefa foi concluída. Mesmo que uma transacção execute com sucesso, pode não cumprir o objectivo: o slippage pode exceder a tolerância, pode haver limites de quantidade que impedem alcançar o tamanho da posição alvo, ou a taxa de juro pode mudar entre simulação e execução on-chain. Humanos validam informalmente via interface front-end após a transacção; já um agente deve avaliar de forma programática as condições de estado após a execução:

Isto exige um patamar mais alto para validar a completude; não pode ficar apenas por confirmar que a transacção foi incluída on-chain. Uma arquitectura centrada na intenção poderá fornecer parte da solução, deslocando mais do peso de “como executar” para um solucionador profissional. O agente deixa de enviar dados brutos de chamadas; em vez disso, transmite uma intenção de execução já assinada e especifica condições baseadas em resultados. O solucionador ou os mecanismos de camada de protocolo têm de cumprir essas restrições para que a execução seja considerada válida.

Fluxos de trabalho multi-etapa e modos de falha

Grande parte da execução em finanças descentralizadas (DeFi) é naturalmente multi-etapa. Uma operação de configuração de rendimento pode exigir sequencialmente: autorização → troca → depósito → empréstimo → staking. Algumas dessas etapas podem ser transacções independentes; outras podem ser executadas através de chamadas em lote ou com empacotamento por meio de contratos de roteamento. Humanos conseguem tolerar que o processo não esteja completamente concluído e voltar ao interface para continuar a operação; já um agente precisa de orquestração determinística: se qualquer etapa falhar, deve decidir se faz retry, muda o caminho, faz rollback ou pausa a execução.

Isso dá origem a novos modos de falha que normalmente ficam escondidos nos fluxos de operação dos humanos:

• Desvio de estado entre decisão e envio on-chain: durante a execução simulada e o período em que a transacção é inserida na cadeia, a taxa de juro, a taxa de utilização ou a liquidez podem mudar. Humanos podem aceitar essa volatilidade, mas o agente precisa definir faixas aceitáveis e executá-las de forma estrita.

• Execução não atómica e execução parcial: parte das operações pode ser executada através de múltiplas transacções, ou apenas gerar uma parte do resultado esperado. O agente precisa de acompanhar os estados intermédios e confirmar se o estado final cumpre o objectivo.

• Risco de limites de autorização e aprovações: humanos completam assinaturas de autorização de forma habitual pela interface; já o agente precisa raciocinar sobre a estratégia de segurança que inclui o âmbito da autorização (limite, pagador, validade), e não tratar isso apenas como uma etapa de interface.

• Escolha de caminhos e custos implícitos de execução: humanos dependem de ferramentas de roteamento e de configurações predefinidas da interface; já o agente precisa modelar a função objectivo incluindo slippage, risco de valor extractível por mineradores (MEV), taxas de Gas e impacto de preço.

Execução: um problema de controlo nativo para máquinas

A ideia central do atrito na execução é esta: a camada de interacção DeFi trata a assinatura de carteira humana como o elo final de controlo. Actualmente, a validação de intenção, a avaliação de tolerância ao risco e a verificação informal de “parece razoável” são feitas nesta etapa. Ao remover a participação humana, a execução torna-se um problema de controlo: o agente precisa transformar objectivos em cadeias de operações, executar automaticamente restrições de estratégia e validar resultados sob incerteza. Este desafio existe em muitos sistemas autónomos, mas no ambiente de blockchain é ainda mais severo, porque a execução envolve directamente fundos, pode chamar contratos desconhecidos e enfrenta mudanças de estado adversariais. Humanos usam experiência para decidir e corrigir erros através de tentativa e erro; já agentes precisam executar esse mesmo trabalho de forma programática com velocidade de máquina, e muitas vezes enfrentam um espaço de operações dinâmico. Por isso, a ideia de que “o agente só precisa enviar transacções” subestima muito a dificuldade. Enviar transacções é apenas uma parte simples; o que falta realmente é todo o trabalho que o interface e os humanos assumem: compilação de intenção, segurança e validação da completude em relação ao objectivo.

Conclusão

Desde o início do seu desenho, a blockchain não fornece nativamente a camada semântica e a camada de coordenação necessárias para agentes autónomos. O seu objectivo de desenho é assegurar execução determinística e consenso sobre transições de estado em ambientes adversariais. As camadas de interacção desenvolvidas sobre isto continuam, em essência, centradas no utilizador humano: interpretam o estado via interface, escolhem operações via front-end e verificam resultados via auditoria humana.

Os sistemas de agentes invertem esta arquitectura. Removem intérpretes, aprovadores e validadores humanos do fluxo e exigem que essas funções sejam convertidas em nativas de máquina. Esta mudança expõe atrito estrutural em quatro dimensões: descoberta, avaliação de confiança, obtenção de dados e orquestração de execução. O atrito surge não porque a execução seja inviável, mas porque a infra-estrutura em torno da blockchain ainda assume, na maioria dos cenários, participação humana entre interpretação de estado e submissão de transacções.

Fechar estas lacunas pode exigir construir nova infra-estrutura em múltiplas camadas da stack técnica: criar um middleware que normalize estados económicos entre protocolos numa especificação legível por máquinas; expor componentes semânticos de base como posições, coeficientes de saúde e conjuntos de oportunidades, em vez de dados brutos de armazenamento; usar serviços de indexação ou expansões de RPC para fornecer essas bases semânticas; disponibilizar um registo para mapeamento de contratos oficiais e validação de autenticidade de tokens; e criar um framework de execução capaz de codificar restrições de estratégia, tratar fluxos de trabalho multi-etapa e validar de forma programática a completude do objectivo. Parte das lacunas deriva de características estruturais dos sistemas sem permissão: implantação aberta, identidades fracas de norma e interfaces heterogéneas; outra parte está limitada pelas ferramentas existentes, padrões e desenho de incentivos — à medida que a escala de utilização dos agentes cresce e os protocolos competem para otimizar a conveniência de integração de sistemas autónomos, espera-se que estes problemas sejam mitigados.

À medida que sistemas autónomos começam a gerir fundos, executar estratégias e interagir directamente com aplicações on-chain, as hipóteses de arquitectura embutidas nas actuais camadas de interacção ficam cada vez mais evidentes. A maior parte dos atritos descritos neste artigo deriva do facto de ferramentas blockchain e padrões de interacção terem sido desenvolvidos em torno de fluxos de trabalho com mediação humana; uma parte resulta naturalmente da abertura, heterogeneidade e do ambiente adversarial dos sistemas sem permissão; e há ainda alguns que são problemas comuns aos sistemas autónomos em ambientes complexos.

O desafio central não é fazer com que os agentes completem assinaturas de transacções, mas fornecer-lhes caminhos fiáveis e realizar, entre o estado on-chain original e a operação real — por meio de software e de julgamento humano — as funções relacionadas com semântica, confiança e estratégia.