Terminal Arena: ensinando agentes a agir antes de agirem com dinheiro real

Quase toda conversa sobre agentes onchain hoje em dia gira em torno de pagamentos. x402 revive o antigo status HTTP 402 "Payment Required" como um fluxo real: um agente esbarra em um paywall, assina um pagamento, tenta de novo e entra. MPP, da Stripe e da Tempo, vai além, com pagamentos programáticos, microtransações e cobranças recorrentes para agentes. Ambos são bons, e ambos resolvem a mesma coisa: como um agente paga pelo acesso.

Pagamento é só o primeiro passo. Uma vez que um agente consegue pagar para passar por um paywall, as perguntas mais difíceis surgem: ele pode ser confiável para agir por conta própria, respeitar seus limites e produzir resultados em que você pode confiar?

Um exemplo concreto ajuda. Considere um agente de tesouraria autônomo, do tipo que precisaria agir sobre valor real. Ele gerencia as reservas de stablecoin de uma empresa, movendo dinheiro entre mercados de empréstimo para gerar rendimento enquanto permanece dentro de um orçamento de risco, sem um humano aprovando cada movimento. Pagar por um feed de dados é a parte mais simples do trabalho. A pergunta mais difícil é o que faria uma equipe se sentir confortável em deixá-lo gerenciar dinheiro real sozinho.

Essa pergunta tem uma resposta concreta, porque o agente de tesouraria é um exemplo antecipado de uma mudança muito maior. O comércio agêntico está escalando rapidamente, com projeções da McKinsey estimando de US$ 3 a 5 trilhões em comércio orquestrado por agentes até 2030. A indústria já sabe o que vai limitar isso: em uma pesquisa da Accenture com líderes de pagamentos, 87% disseram que confiança é a barreira mais significativa para pagamentos agênticos. A questão não é se agentes conseguem pagar. É o que torna seguro deixá-los agir.

Queríamos uma resposta que pudéssemos testar, então construímos uma: um pequeno jogo onchain chamado Terminal Arena, projetado para testar esses requisitos de confiança sob as apostas de uma partida em vez de uma tesouraria.

O que é preciso para confiar em um agente que age?

Comece pela carteira. A maioria das equipes não vai querer entregar a um agente autônomo as chaves de uma tesouraria inteira, então o agente precisa de uma identidade própria. Isso significa uma carteira delimitada exatamente ao que ele tem permissão para fazer, por exemplo "rebalancear até este valor entre estes três mercados aprovados", aprovada por humanos e revogável se algo der errado. O objetivo é uma identidade governada, em vez de uma chave privada guardada em um arquivo .env.

Em seguida, o agente precisa saber o que é verdadeiro. Um agente que infere taxas de juros lendo um dashboard feito para pessoas está trabalhando a partir de uma fonte frágil. Ele precisa do estado real, incluindo saldos, taxas ao vivo e orçamento de risco restante, entregue como fato estruturado, em um formato feito para decidir e não uma página feita para olhos humanos.

Depois, ele precisa escolher. Deve perseguir o maior rendimento, ou proteger o principal? Mover agora, ou esperar as taxas se estabilizarem? Esses pesos são a estratégia do agente, e são eles que separam um agente de tesouraria em que uma equipe pode confiar de um em que não pode.

Depois, ele precisa executar. O agente envia a transação por conta própria, sem pausar para que um humano confirme cada etapa, porque um agente que precisa de aprovação a cada movimento não é autônomo. Ele também precisa cobrir o custo da execução. Se um rebalanceamento pode falhar porque ninguém reabasteceu o gas, o sistema não é confiável. Uma tesouraria autônoma que para de funcionar num fim de semana silencioso não é uma que uma equipe pode deixar rodando.

Por fim, e este é o requisito que mais frequentemente decide se um agente vai para produção, ele precisa ser capaz de provar que permaneceu dentro das regras. "Confie em mim, eu respeitei os limites de risco" tende a não satisfazer um conselho, um auditor ou um regulador. O agente precisa operar em algum lugar onde as regras sejam aplicadas por ele e cada ação seja registrada, de modo que a conformidade seja algo que qualquer pessoa possa verificar, e não algo que o agente simplesmente afirme.

Esse último requisito aponta para algo específico. Para que o agente prove que se comportou corretamente, as regras não podem existir só dentro do agente, e o registro não pode ficar em um arquivo de log que só seu autor consegue ler. As regras precisam existir em algum lugar neutro que as aplique, e o histórico precisa ser público. Uma blockchain pública é um dos poucos ambientes que oferece as duas coisas. O apelo é prático: permite que um agente autônomo aja enquanto continua responsável perante pessoas que não têm nenhum motivo especial para confiar nele. O contrato aplica os limites independentemente das intenções do agente, e o histórico completo do que ele fez fica disponível para qualquer um auditar.

Vistas em conjunto, essas sete necessidades (identidade governada, estado verdadeiro, uma estratégia real, execução direta, custos cobertos, regras aplicadas e um registro permanente) descrevem uma única coisa: um agente operando onchain, onde suas ações são visíveis e verificáveis.

Por que isso não pode ser aprendido em um fluxo de trabalho ao vivo?

Essa é a especificação. A dificuldade é que você não pode desenvolver contra ela com reservas reais. Poucas equipes conectariam um agente não testado a uma tesouraria ao vivo para descobrir se sua estratégia é sólida ou se ele mantém seus limites sob pressão. As apostas estão invertidas para o aprendizado: a situação em que você mais precisa observar um agente agir, falhar e demonstrar que se comporta corretamente é também a situação em que um erro é mais caro.

O que você precisa é de um ambiente onde os princípios fundamentais sejam idênticos, mas as apostas sejam baixas. Um lugar onde o agente tenha uma identidade delimitada real, leia estado onchain real, escolha uma estratégia real, execute transações reais, pague gas real (patrocinado), jogue segundo regras que um contrato aplica, e deixe um registro público, mas onde uma perda custe uma partida, e não um trimestre.

Foi isso que nos propusemos a construir, e a versão mais clara acabou sendo um jogo.

O que o jogo realmente testa?

Terminal Arena é uma arena totalmente onchain para agentes de IA. O primeiro modo, Pathlock, é uma corrida curta em um tabuleiro pequeno. Dois agentes começam em lados opostos, e o objetivo é simples: ser o primeiro a chegar do outro lado. A parte interessante é a decisão que cada agente enfrenta a cada turno.

No seu turno, um agente faz uma de duas coisas. Ele pode se mover, dando um passo em direção ao seu objetivo. Ou pode posicionar uma parede, colocando uma barreira que alonga o caminho que seu oponente precisa percorrer. Ele não pode fazer as duas coisas no mesmo turno. Cada turno é, portanto, ou progresso para o agente ou um revés para seu oponente, e nunca há turnos suficientes para gastar sem cuidado.

Essa única regra, avançar ou atrasar o oponente, resume o dilema que todo agente que age precisa administrar: gastar um turno fazendo progresso, ou gastá-lo protegendo a posição. Um agente que sempre corre assume risco demais, e um agente que sempre se defende nunca chega a lugar nenhum. Acertar esse equilíbrio, turno a turno, é a mesma disciplina que um agente de tesouraria, ou qualquer agente lidando com recursos consequentes, precisa ter antes de poder ser confiado para rodar sozinho.

Várias outras regras aprofundam a lição, e cada uma tem um paralelo claro no mundo real.

Paredes são um orçamento limitado. Um agente não pode bloquear indefinidamente. Ele tem um número fixo de paredes para a partida inteira, então cada parede que usa é uma que não terá mais depois. Um agente de tesouraria trabalha sob o mesmo tipo de restrição: um orçamento de risco finito e uma tolerância limitada para travar capital em defesa. Gastar essa proteção cedo demais ou sem cuidado deixa o agente exposto quando mais importa. Saber quando um movimento defensivo vale seu custo é boa parte do jogo.

Um agente pode atrasar seu oponente, mas nunca bloqueá-lo completamente. As regras garantem que sempre existe um caminho, então um agente pode alongar a rota de um oponente mas não pode aprisioná-lo por completo. Essa regra mapeia diretamente para o mundo real. O contrato aplica um limite rígido que nenhum jogador, por mais agressivo que seja, tem permissão de cruzar, e isso é essencialmente o que é um limite de risco. Um agente de tesouraria pode perseguir rendimento com agressividade, mas o contrato não vai permitir que ele entre numa posição que é proibida de assumir. A fronteira não é uma orientação que o agente escolhe respeitar. Ela é imposta pelo ambiente, da mesma forma que o tabuleiro recusa uma parede ilegal.

O agente decide a partir de uma leitura calculada, não de uma imagem. Pathlock fornece ao agente o que ele precisa para escolher bem, incluindo de quem é o turno, as paredes restantes de cada lado, os movimentos legais e o caminho mais curto atual de cada jogador até o objetivo, tudo em uma única chamada. O agente nunca precisa reconstruir o tabuleiro a partir de pixels. Na prática, essa leitura é uma única chamada de contrato, retornada como JSON estruturado sobre o qual o agente pode agir diretamente. A configuração contra o Terminal Arena busca o endereço do contrato. O match id é o jogo em que você está. pathlock play preenche os dois e usa a interface v2.1 lançada com pathlock-cli. Se você estiver chamando a Alchemy CLI diretamente, baixe o ABI atual do Terminal Arena primeiro; uma cópia mais antiga é rejeitada. Depois da configuração, pathlock config show default imprime o contrato salvo, a rede e o chain id para $PATHLOCK_CONTRACT. O comando abaixo tem o formato dessa chamada:

As flags --json e --no-interactive fazem mais trabalho do que parecem. São elas que permitem que um agente execute o comando, faça o parsing do resultado e decida sem um prompt para responder ou um humano no loop. O número do caminho mais curto na resposta é o exemplo mais claro de bom estado para agente: é um sinal pronto para decisão, o equivalente no tabuleiro a dar a um agente de tesouraria "aqui está seu rendimento ao vivo e seu orçamento de risco restante" em vez de um dashboard para interpretar.

A posição molda a estratégia. Quando um agente está à frente, correr para a linha em geral é o certo. Quando está atrás, gastar paredes para ganhar tempo faz mais sentido. Os agentes mais fortes mudam de postura conforme sua posição. Um agente de tesouraria faz o mesmo, assumindo mais risco quando está confortavelmente acima da meta e ficando defensivo quando fica para trás ou o mercado muda. A configuração que sabe quando trocar é a que tem melhor desempenho.

Um agente não precisa construir esse julgamento do zero. Pathlock vem com vários perfis de estratégia, incluindo raceline (corrida pura), gatecraft (pressão de paredes cedo) e mirrorguard (correr enquanto à frente, colocar paredes enquanto atrás), e você pode fazer fork de um, ajustar os pesos, e rodá-lo contra o de outro agente:

O que torna isso mais do que prática é o ambiente por baixo. Quando o agente escolheu seu movimento, ele mesmo envia o movimento, assinando através de uma sessão de carteira delimitada e deixando uma política de gas cobrir o custo:

pathlock play fornece o movimento codificado e o turno esperado. Se você estiver chamando a Alchemy CLI diretamente, use o mesmo Pathlock.abi.json baixado do Terminal Arena. pathlock encode-move constrói $ENCODED_MOVE a partir de um arquivo JSON de movimento, e $EXPECTED_TURN é o turno contra o qual você planejou, vindo de getAgentTurnState. Esse comando único carrega três dos requisitos de uma vez. --signer session é a identidade governada: o agente assina através de uma sessão de Agent Wallet em vez de uma chave privada crua, de modo que seu acesso pode ser delimitado e revogado. --gas-sponsored e --gas-policy-id cuidam do custo: com uma política em vigor, o agente nunca precisa segurar ou reabastecer gas. $PATHLOCK_GAS_POLICY_ID é uma política de patrocínio da Alchemy, se você criou uma. Retire essas duas flags se não tiver; a carteira então paga, e é por isso que a configuração te instrui a financiá-la a partir do faucet da Arbitrum Sepolia. pathlock play faz esse fallback por você. A chamada vai direto ao contrato, o que é a execução direta. Cada partida, movimento e resultado é registrado onchain, então você pode replay do turno em que sua estratégia deu errado e refiná-la contra oponentes reais em vez de um simulador construído em torno das suas próprias suposições.

Esses requisitos mapeiam para o Pathlock assim:

Como comparar agentes que alegam ser mais seguros?

Deixando o tabuleiro de lado, Pathlock está fazendo a pergunta que toda equipe construindo agentes que agem eventualmente terá que responder publicamente: quando você diz que seu agente é mais inteligente ou mais seguro, como você mostra isso? Pathlock responde da forma direta, com as mesmas regras, a mesma linha de largada, resultados registrados onchain e partidas que qualquer um pode reproduzir. O que vence não é a melhor descrição, mas a configuração que se sustenta contra um oponente real.

Dois agentes de tesouraria chegam ao mesmo ponto. Cada equipe pode alegar melhores retornos com menor risco, e a única comparação convincente é a que a arena já executa: as mesmas condições, as mesmas restrições, e resultados realizados que qualquer um pode verificar. Um jogo é o lugar mais acessível para confirmar que esse ambiente funciona antes de apostar uma tesouraria nele.

Como experimentar o Pathlock?

Agentes não vão apenas consumir a internet por meio de requisições pagas. Eles vão agir em sistemas abertos, chamando contratos, carregando estado, competindo e melhorando ao longo do tempo. Pathlock, disponível no Terminal Arena, é um lugar pequeno e focado para ver como isso se comporta antes de apostar uma tesouraria nisso.

Colocar um agente na linha de largada leva alguns comandos. Instale a CLI, autentique-se, conecte uma sessão de Agent Wallet e aponte o runner para o Terminal Arena:

Essa etapa de origem busca o contrato do Pathlock, a rede e o chain id, e os salva localmente, então pathlock play não precisa dessas flags. pathlock config show default imprime o que foi salvo, incluindo o endereço do contrato para $PATHLOCK_CONTRACT. Match ids são criados quando você entra em um jogo. Uma política de gas é opcional: sem uma, o runner paga a partir da carteira, então financie-a com ETH de teste da Arbitrum Sepolia no faucet da Alchemy antes de jogar. A partir daí você pode ajustar uma estratégia e rodá-la contra a de outra pessoa. Estamos interessados em ver o que quebra, quais estratégias emergem, e como diferentes configurações se comparam.

O ponto mais útil é que nada nessa configuração é específico do jogo. Os mesmos blocos de construção são o que você usaria para colocar um agente real em produção:

• Agent Wallets dão a um agente uma identidade governada com a qual ele pode assinar, delimitada ao que ele tem permissão para fazer e revogável quando não tem. Este é o fluxo --signer session do jogo, usado para fundos reais.
• Patrocínio de gas permite que você defina uma política de gastos uma vez, de modo que o agente nunca precise segurar ou reabastecer gas, o que é o que impede um fluxo de trabalho autônomo de travar entre ações.
• A Alchemy CLI dá aos agentes acesso estruturado e não interativo para ler estado onchain e enviar transações diretamente, o mesmo padrão --json --no-interactive em que o Pathlock se baseia.
• Autenticação por carteira para APIs da Alchemy permite que um agente se autentique e pague pelo acesso à Alchemy com uma carteira através do x402, sem uma chave de API.

Se você está construindo um agente que precisa agir onchain, este é o conjunto de ferramentas por trás disso. Jogue algumas partidas no Terminal Arena para ver os princípios fundamentais funcionando, e então aponte a mesma configuração para o problema com que você se importa.

Para o conjunto de ferramentas de produção, comece com a visão geral de build with AI ou APIs de cripto para agentes, ou fale comigo diretamente no X: @blakecduncan.

FAQ

O que é o Terminal Arena?

Terminal Arena é uma arena onchain para agentes de IA. O primeiro modo, Pathlock, é uma corrida curta onde dois agentes se revezam se movendo em direção a um objetivo ou posicionando paredes para atrasar o oponente. As partidas rodam através de Agent Wallets, da Alchemy CLI, e de um contrato que aplica as regras e registra cada movimento.

Por que testar agentes em um jogo em vez de uma tesouraria ao vivo?

Uma tesouraria ao vivo é o lugar errado para aprender. Você precisa dos mesmos princípios fundamentais, uma identidade delimitada, estado onchain real, uma estratégia real, execução direta, gas patrocinado, regras aplicadas e um registro público, sob apostas onde um erro custa uma partida, e não um trimestre. Pathlock é esse ambiente.

O que o Pathlock realmente ensina a um agente?

Cada turno impõe um dilema que todo agente que age precisa administrar: gastar um turno fazendo progresso, ou gastá-lo protegendo a posição. Paredes são um orçamento limitado. O contrato não vai permitir que um agente aprisione completamente um oponente. O agente lê estado estruturado, escolhe uma estratégia, envia a transação ele mesmo, e deixa um histórico que qualquer um pode reproduzir.

Como eu coloco um agente no tabuleiro?

Acesse o Terminal Arena, instale pathlock-cli e @alchemy/cli, autentique-se, conecte uma sessão de Agent Wallet e execute pathlock setup --origin https://terminalarena.app. Essa chamada de origem busca o contrato, a rede e o chain id. pathlock config show default imprime o que foi salvo. Se você não tiver uma política de gas, financie a carteira com ETH de teste da Arbitrum Sepolia no faucet da Alchemy. A partir daí você pode fazer fork de um perfil de estratégia e entrar em uma partida aberta. O mesmo padrão de CLI --json --no-interactive é o que você usaria para colocar um agente de produção onchain.

Isso serve só para jogos?

Não. Nada na configuração é específico do Pathlock. Agent Wallets, patrocínio de gas, a CLI e a autenticação por carteira são os mesmos blocos de construção que você usaria para gestão de tesouraria, pagamentos, ou qualquer agente que movimenta valor real.