🤖 AI

Operating-Layer Controls for Onchain Language-Model Agents Under Real Capital

Este artigo demonstra que agentes autônomos confiáveis de modelos de linguagem que gerenciam capital real em mercados onchain dependem menos das capacidades do modelo base e mais de uma camada operacional robusta com controles tipados, validação de políticas e guardas de execução, que coletivamente reduziram falhas críticas, como regras de negociação fabricadas, e permitiram um alto índice de sucesso na liquidação em uma implantação de grande escala ao longo de 21 dias.

Autores originais: T. J. Barton, Chris Constantakis, Patti Hauseman, Annie Mous, Alaska Hoffman, Brian Bergeron, Hunter Goodreau

Publicado 2026-04-30

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: T. J. Barton, Chris Constantakis, Patti Hauseman, Annie Mous, Alaska Hoffman, Brian Bergeron, Hunter Goodreau

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você contrata um chef robô altamente inteligente, mas um pouco literal, para gerenciar um restaurante. Você entrega ao chef um cardápio e um orçamento (seu "mandato") e diz: "Faça comida boa e não desperdice dinheiro."

No passado, pesquisadores testavam esses chefs robôs em uma simulação: davam-lhes um cardápio falso e dinheiro falso. Os chefs pareciam ótimos no papel. Mas este artigo descreve o que aconteceu quando eles realmente abriram o restaurante com dinheiro real e clientes reais por 21 dias.

Aqui está a história do que descobriram, usando analogias simples.

A Grande Descoberta: Não Se Trata do Cérebro do Chef

A equipe esperava que, se simplesmente contratasse um chef robô "mais inteligente" (um modelo de IA mais poderoso), o restaurante funcionaria perfeitamente. Eles estavam errados.

Descobriram que a confiabilidade do restaurante não vinha apenas do cérebro do chef. Vinha do sistema de gerenciamento da cozinha que cercava o chef. Eles chamam isso de "Camada Operacional".

Pense nisso assim:

O Modelo (O Chef): Pode ler uma receita e picar vegetais.
A Camada Operacional (O Gerente da Cozinha): Verifica se os ingredientes estão frescos, impede que o chef jogue comida fora, garante que o chef não acenda a cozinha acidentalmente e assegura que a conta corresponda ao que o cliente pediu.

O artigo argumenta que, para uma IA lidar com dinheiro real, você precisa de um Gerente de Cozinha super rigoroso, não apenas de um Chef mais inteligente.

O Experimento: "DX Terminal Pro"

A equipe estabeleceu um teste do mundo real chamado DX Terminal Pro.

A Configuração: 3.505 pessoas colocaram seu próprio dinheiro real (ETH) em "cofres".
A Regra: Humanos podiam definir as regras (como "ser arriscado" ou "ser seguro"), mas não podiam tocar no dinheiro diretamente. Apenas os agentes de IA podiam comprar e vender tokens.
Os Envolvidos: Cada vez que a IA fazia uma negociação, custava dinheiro real em taxas (2,3% por negociação). Se a IA cometesse um erro, dinheiro real desaparecia.
A Escala: A IA tomou 7,5 milhões de decisões, negociando cerca de 20 milhões de dólares em criptomoedas.

Os "Pesadelos na Cozinha" (Modos de Falha)

Antes do evento real, a equipe realizou testes e encontrou cinco maneiras específicas pelas quais os chefs de IA estavam bagunçando. Eles corrigiram isso alterando as regras do "Gerente da Cozinha", não demitindo os chefs.

O Problema da "Regra Falsa" (Fabricação de Regras):
- O Glitch: A IA inventava regras que não existiam, dizendo, por exemplo: "Devo vender porque a 'Regra nº 2' diz isso", quando tal regra não existia.
- A Correção: Eles disseram à IA: "Não invente leis. Se você não viu escrito, não é uma regra."
- Resultado: Regras falsas caíram de 57% das decisões para apenas 3%.
O Problema da "Paralisia por Taxas":
- O Glitch: A IA via a taxa de 2,3% e ficava tão assustada que se recusava a negociar de todo, mesmo quando era uma boa oportunidade. Era como um chef recusar-se a cozinhar porque o fogão custa dinheiro para ser ligado.
- A Correção: Eles moveram o aviso da taxa para o final das instruções, logo após a oportunidade de mercado. Ensinaram à IA: "Sim, há uma taxa, mas veja por que a negociação vale a pena."
- Resultado: A IA parou de congelar e começou a negociar novamente.
O Problema da "Confusão Matemática" (Endurecimento Numérico):
- O Glitch: A IA tratava sugestões flexíveis como leis rígidas. Se você dissesse "tente gastar cerca de 33%", a IA obsessivamente tentaria atingir exatamente 33% todas as vezes, mesmo quando não fazia sentido.
- A Correção: Pararam de usar números exatos e usaram comparações em vez disso (por exemplo, "gaste mais quando o mercado estiver aquecido").
- Resultado: A IA começou a agir de forma mais natural e menos robótica.
O Problema da "Armadilha de Tokens" (Leitura Errada da Tokenomics):
- O Glitch: Um token caiu de preço. A IA viu a queda e vendeu tudo imediatamente, sem perceber que o token tinha uma regra especial onde os detentores recebiam pagamento mesmo que o preço caísse. Era como vender um cupom apenas porque a loja mudou seu logotipo, sem perceber que o cupom ainda funcionava.
- A Correção: Deram à IA uma explicação clara e estruturada da regra especial de pagamento antes de mostrar a queda de preço.
- Resultado: A IA parou de entrar em pânico e tomou decisões mais inteligentes.
O Problema do "Relógio" (Negociação por Cadência):
- O Glitch: A IA começou a negociar apenas porque "já se passaram 10 minutos desde a última negociação", ignorando o mercado. Era como um chef picar vegetais apenas porque o relógio dizia que era hora, não porque os ingredientes precisavam ser picados.
- A Correção: Disseram à IA para ignorar o relógio e negociar apenas com base em sinais de mercado.

Os Resultados: Um Restaurante Melhor

Depois que corrigiram o "Gerente da Cozinha" (a Camada Operacional), o sistema funcionou incrivelmente bem:

99,9% de Taxa de Sucesso: Quase todas as negociações que a IA tentou fazer eram válidas e foram concluídas.
Comportamento Real: A IA não apenas seguia ordens; reagia ao mercado. Às vezes, quando uma IA via uma boa oportunidade, centenas de outras viam também e compravam ao mesmo tempo (um efeito de "rebanho"), assim como humanos reais fazem.
Instruções Melhores: Usuários que deram instruções claras e específicas (usando controles deslizantes e caixas de seleção) obtiveram melhores resultados do que aqueles que apenas escreveram notas vagas como "fique rico para mim".

A Principal Conclusão

O artigo conclui que, se você quer que uma IA lide com dinheiro real, não procure apenas um modelo de IA mais inteligente.

Você precisa construir um sistema melhor ao redor dela. Você precisa:

Traduzir desejos humanos em regras claras e estruturadas.
Verificar o trabalho da IA antes que ela gaste um centavo.
Manter um registro perfeito de cada pensamento, decisão e negociação para que você possa descobrir exatamente o que deu errado, se algo der errado.

A "Camada Operacional" é a rede de segurança que transforma um robô inteligente, mas confuso, em um agente financeiro confiável.

1. Declaração do Problema

O artigo aborda a lacuna crítica de confiabilidade em agentes autônomos de modelos de linguagem (LM) ao gerenciar capital real em mercados financeiros ao vivo. Embora benchmarks existentes (por exemplo, SWE-bench, AgentBench) avaliem agentes em ambientes sintéticos ou apenas de texto, eles falham em capturar as complexidades de operações financeiras persistentes e do mundo real, incluindo:

Liquidção irreversível: Transações não podem ser desfeitas.
Custos econômicos reais: Taxas de transação elevadas (2,3% por troca neste estudo) e deslizamento (slippage).
Feedback multiagente: Agentes reagem ao mesmo estado de mercado e às negociações uns dos outros.
Autonomia de longo horizonte: Agentes devem tomar milhares de decisões sequenciais ao longo de dias sem intervenção humana.

Os autores argumentam que a confiabilidade neste domínio não é apenas uma função da inteligência do modelo base, mas sim uma propriedade emergente da camada operacional — a arquitetura do sistema que envolve o modelo e traduz a intenção do usuário em ações validadas e executáveis.

2. Metodologia: DX Terminal Pro

O estudo utilizou o DX Terminal Pro, uma implantação ao vivo de 21 dias na blockchain Base envolvendo 3.505 cofres financiados por usuários.

Arquitetura do Sistema:
- Modelo: Qwen/Qwen3-235B-A22B-Thinking-2507 (235B parâmetros, 22B ativos).
- Inferência: Atendido via SGLang em uma pilha de computação fixa para garantir consistência.
- Ambiente: Um mercado limitado de 12 tokens memecoin na Uniswap V4.
- Restrições: Um agente por carteira; humanos podiam configurar estratégias e controles de risco, mas não podiam executar negociações individuais. Os agentes tinham que escolher exatamente uma ação por ciclo: Comprar, Vender ou Observar.
Loop de Controle:
- Entrada: Usuários configuravam cofres por meio de controles deslizantes estruturados (Atividade de Negociação, Risco, Tamanho da Negociação, etc.) e texto de estratégia em linguagem natural.
- Processamento: Um "harness" compilava essas entradas em um prompt, incluindo dados de mercado em tempo real, estado da carteira e memória.
- Validação: Uma camada de política off-chain verificava as chamadas de ferramentas quanto à validade (por exemplo, verificações de saldo, limites de deslizamento, listas permitidas de tokens) antes da submissão.
- Observabilidade: O sistema registrava um rastro completo de instrução até a liquidção para cada invocação, vinculando mandatos do usuário, prompts, raciocínio, chamadas de ferramentas e resultados onchain.
Escala: 7,5 milhões de invocações de agente, ~70 bilhões de tokens de inferência e ~20 milhões de dólares em volume de negociação.

3. Contribuições Principais

O artigo apresenta três contribuições primárias:

Arquitetura para Agentes de Capital Real: Um design de sistema ao vivo que compila configurações do usuário em contexto de agente, valida ações antes da liquidção e mantém rastros granulares da intenção ao resultado na cadeia.
Identificação e Mitigação de Modos de Falha: Os autores identificaram cinco modos de falha específicos únicos à operação persistente com capital real e demonstraram como intervenções direcionadas no "harness" (nível de sistema) os reduziram.
Evidência Empírica da Dominância da Camada Operacional: Dados mostrando que melhorias na confiabilidade vêm do design do sistema (compilação de prompts, validação, semântica de memória) e não apenas de atualizações de modelo.

4. Resultados Principais e Modos de Falha

O estudo revelou que modelos base frequentemente falham devido a erros de interpretação do prompt, e não à falta de capacidade de raciocínio. Através de testes iterativos pré-lançamento, a equipe reduziu taxas de falha específicas:

| Modo de Falha | Descrição | Mudança Observada (Pré-correção para Pós-correção) | Intervenção |
| :--- | :--- | :--- | : |
| Fabricação de Regras | Agentes inventavam regras inexistentes (por exemplo, "Regra de Hierarquia #2") para justificar negociações. | 57% $\to$ 3% das decisões de venda | Remoção de linguagem semelhante a leis; esclarecimento de que decisões anteriores são contexto, não precedente. |
| Paralisia por Taxas | Agentes recusavam-se a negociar porque a taxa de 2,3% era apresentada antes do contexto de mercado, causando excesso de cautela. | 32,5% $\to$ <10% de observações lideradas por taxas | Movimento do contexto de taxas para seguir a análise de oportunidade de mercado; evitar apresentar taxas como a regra primária. |
| Leitura Incorreta de Tokenomics | Agentes vendiam tokens durante eventos de "reap" (redistribuição de liquidez) porque viam quedas de preço, mas perdiam a mecânica de pagamento. | 42,9% $\to$ 78,0% de deploy de capital | Inserção de contexto estruturado de tokenomics (mecânicas do whitepaper) antes dos dados de preço, permitindo que agentes raciocinassem sobre pagamentos versus quedas de preço. |
| Endurecimento Numérico | Restrições suaves (por exemplo, "Tamanho da Negociação 5") eram interpretadas como alvos numéricos rígidos, invertendo o comportamento pretendido. | Gradiente monótono restaurado | Substituição de números exatos por linguagem comparativa vinculada à vantagem de mercado. |
| Negociação por Cadência | Agentes negociavam com base no tempo decorrido ("última negociação foi há 6 ticks") em vez de sinais de mercado. | Reduzido significativamente | Proibição de cadência fixa; filtragem de memória para prevenir ritmos de autorreforço. |

Descobertas de Comportamento em Produção:

Eficácia dos Controles Deslizantes: Controles estruturados (controles deslizantes) mapeavam a intenção do usuário para o comportamento de forma mais confiável do que chats de livre forma. Por exemplo, os controles deslizantes de "Tamanho da Negociação" correlacionavam-se diretamente com a porcentagem de gasto (2% a 95% de ETH).
Rebanho e Cascatas: Agentes exibiram dinâmicas especulativas de mercado, incluindo "cascatas de atenção" onde mais de 1.500 agentes compraram o mesmo token dentro de uma hora, e cascatas de venda com intervalos de 9,5 segundos entre agentes.
Fluxo de Dois Lados: Apesar do rebanho, 92,9% das janelas de 5 minutos viram tanto compras quanto vendas, impulsionadas por mandatos diversos de usuários (controles deslizantes/estratégias) e não por diversidade de modelos.
Correlação de Resultados: Usuários que forneceram instruções concretas e verificáveis (condições de saída, parâmetros) tinham 4,2 vezes mais probabilidade de encerrar com lucro do que aqueles que usavam solicitações vagas de "superar".

5. Significado e Implicações

Confiabilidade é uma Propriedade da Camada Operacional: O artigo demonstra que um modelo pode seguir instruções bem, mas ainda negociar mal se a estrutura do prompt, a semântica da memória ou a lógica de validação forem falhas. Um "harness" pode melhorar a taxa de sucesso de um modelo de ~87% para 99,9% (como mostrado em avaliações internas de trocas EVM).
Observabilidade em Nível de Rastro é Crítica: A capacidade de rastrear uma ação de volta à linha específica de política, memória ou mandato do usuário que a causou é essencial para depuração. Isso permite a separação de "confusão do modelo" de "erros de mandato do usuário".
Além de Benchmarks de Texto: Benchmarks baseados em texto padrão falham em capturar "paralisia por taxas" ou "regras fabricadas" que só emergem sob pressão financeira e execução repetida.
Dados Futuros de Treinamento: Os rastros de instrução até a liquidção fornecem um conjunto de dados rico para Aprendizado por Reforço (RL), geração de cenários sintéticos e avaliação de homogeneidade de modelo em diferentes arquiteturas.

Conclusão:
O estudo conclui que, para agentes que gerenciam capital, a "camada operacional" (compilação de prompts, controles tipados, validação de políticas e observabilidade) é o determinante primário da confiabilidade. O progresso futuro na IA financeira depende menos da escalabilidade de modelos base e mais da engenharia de sistemas robustos e instrumentados que possam detectar e corrigir falhas antes que o capital seja deployado.