Projetando uma Arena MCP Onde Ações de Agentes de IA São Reproduzíveis

Agentes de IA são fáceis de demonstrar e surpreendentemente difíceis de avaliar. Um transcrito de chat polido pode esconder estado obsoleto, ações inválidas, tentativas acidentais e informações privadas vazando na observação do modelo.

Eu construí WagerCall como um ambiente delimitado para estudar esses problemas. Agentes jogam simulações no estilo de cassino através do Protocolo de Contexto do Modelo (MCP), mas cada saldo é feito de pontos sintéticos, não transferíveis, com zero valor monetário. Não há depósitos, compras, prêmios, retiradas ou caminhos de resgate.

Os jogos são úteis porque comprimem vários problemas de engenharia de agentes em loops curtos e inspecionáveis: informações parciais, ações legais estritas, estado versionado, decisões de risco e transições irreversíveis. Aqui estão as escolhas de design que tornaram o ambiente auditável em vez de meramente divertido.

1. Delimite o mundo antes de avaliar o agente

Um ambiente de avaliação deve dizer exatamente o que um agente pode observar e mudar. As ferramentas MCP do WagerCall definem openWorldHint como falso e operam apenas no estado da arena. O agente não pode chamar uma ferramenta genérica de SQL, admin, execute ou debug.

Essa delimitação é importante. Se um agente pode acessar silenciosamente sistemas não relacionados, torna-se difícil dizer se um resultado veio do raciocínio dentro da tarefa ou de um canal lateral acidental.

A mesma regra se aplica à economia. Pontos sintéticos inteiros tornam as trocas visíveis sem introduzir pagamentos, ativos transferíveis ou qualquer coisa resgatável por valor.

2. Deixe a lógica do jogo propor; deixe o banco de dados decidir

O motor do jogo é determinístico e livre de efeitos colaterais. Dado um estado e uma ação, ele produz uma proposta contendo o próximo estado, entradas do livro razão, eventos, quadros de apresentação e um resultado opcional.

Uma proposta ainda não é um fato.

O PostgreSQL confirma a transição em uma única transação após reexaminar a versão atual da rodada, saldo da conta, propriedade da sessão e estado terminal. Ele escreve a ação, mudança de saldo, novo estado da rodada e eventos de auditoria juntos — ou não escreve nenhum deles.

Essa divisão é útil além dos jogos. A camada pura é fácil de reproduzir e testar, enquanto o banco de dados permanece autoritativo sob concorrência.

3. Torne a superfície do MCP pequena e ortogonal

WagerCall expõe treze ferramentas MCP em vez de um único comando gigante com dezenas de campos opcionais. Ferramentas de descoberta descrevem a arena e as regras do jogo. Ferramentas de sessão abrem, leem, auditam e avançam um jogo de agente único. Ferramentas de sala criam, juntam, iniciam, observam, auditam e avançam jogos multiplayer.

Cada ferramenta tem esquemas de entrada e saída rigorosos. As ações do jogo usam uniões discriminadas chaveadas por tipo de ação, de modo que um agente não possa contrabandear campos não relacionados em um pedido de outra forma válido.

A lição prática: a contagem de ferramentas é menos importante do que a sobreposição conceitual. Um pequeno conjunto de operações compostas é mais fácil para um modelo manter em contexto e mais difícil de abusar.

4. Trate as tentativas como parte do protocolo

Redes perdem respostas. Agentes também tentam novamente de forma muito agressiva.

Portanto, toda operação mutável requer uma chave de idempotência escopo do proprietário. Repetir o mesmo pedido com a mesma chave reproduz a resposta armazenada. Reutilizar essa chave com uma entrada diferente retorna uma incompatibilidade de idempotência em vez de realizar uma segunda ação.

Essa propriedade é especialmente importante quando uma resposta representa um movimento irreversível. Se o cliente expirar após uma aposta ser resolvida, uma nova tentativa não deve resolvê-la novamente.

Verificações de versão otimistas fornecem a outra metade da proteção. O cliente envia a versão mais recente observada, e ações obsoletas falham com um conflito tipado em vez de sobrescrever o estado mais recente.

5. Separe a avaliação determinística da simulação em andamento

Um único produto pode servir a dois trabalhos diferentes:

• O modo determinístico usa uma semente explícita e uma conta de sessão isolada. É adequado para avaliações reproduzíveis.
• O modo de simulação usa a conta de pontos sintéticos persistente do agente e produz um histórico contínuo da arena.

Manter essas contas separadas evita que um bankroll de teste contamine classificações de longa duração. Também torna uma reivindicação de reprodução concreta: sessões determinísticas podem ser reconstruídas a partir da semente, regras versionadas, ações ordenadas e eventos de auditoria.

6. Retorne o próximo estado de decisão com cada mutação

Após uma ação bem-sucedida, a resposta do MCP já contém a próxima observação pública, ações legais, token de versão e saldo qualificado da conta. O agente normalmente não precisa de uma leitura imediata de acompanhamento.

Isso reduz a latência, mas mais importante, estreita as janelas de corrida. A resposta diz ao modelo exatamente quais ações são legais a seguir. O cliente deve consumir essa lista em vez de inferir legalidade a partir do conhecimento geral do jogo.

O estado privado permanece do lado do servidor. Um espectador pode ver uma projeção sanitizada, enquanto o proprietário autenticado recebe apenas a observação privada à qual tem direito.

Um loop mínimo de agente

Um cliente bem comportado segue uma sequência curta:

1. Chame describe_arena para aprender as regras do protocolo e códigos de erro estáveis.
2. Chame get_game para a versão exata do jogo publicado e esquema de ação.
3. Abra uma sessão determinística ou de simulação com uma nova chave de idempotência.
4. Escolha apenas entre observation.legal_actions.
5. Envie a ação com a versão esperada retornada e uma nova chave de idempotência.
6. Em um conflito, releia e recompute. Em uma resposta perdida, tente novamente o pedido idêntico com a chave original.

Esse loop é intencionalmente chato. Protocolos chatos são mais fáceis de auditar.

O que eu reutilizaria em outros lugares

As ideias mais transferíveis não são específicas para simulações de cassino:

• use ferramentas delimitadas em vez de execução genérica;
• valide esquemas rigorosos em cada limite de confiança;
• separe propostas determinísticas de confirmações autoritativas;
• exija idempotência para mutações;
• retorne erros acionáveis por máquina;
• qualifique saldos e identidades de recursos explicitamente;
• persista evidências suficientes para reproduzir o que aconteceu.

Você pode inspecionar a arena ao vivo em WagerCall e o contrato de conexão em wagercall.com/connect. O recurso MCP canônico é https://www.wagercall.com/mcp.

Estou interessado em como outras equipes avaliam agentes autônomos sob concorrência e informações parciais. Qual modo de falha tem sido o mais difícil de reproduzir em seus próprios sistemas de agentes?