Construindo o MatchDay AI: Um piloto automático com memória para viagens de eventos

Construindo o MatchDay AI: um piloto automático com memória para viagens de eventos

Eu construí o MatchDay AI para o Qwen Cloud Global AI e o OpenAI Build Week Hackathon e o submeti apenas ao Track 4: Autopilot Agent*. Suas capacidades de memória persistente também se alinham ao Track 1, mas são o diferencial dentro de uma única submissão do Track 4 — não uma entrada em dois tracks. O avanço central é o fluxo de trabalho completo: entender uma solicitação confusa, relembrar preferências relevantes, invocar ferramentas tipadas, detectar um conflito que quebra a viagem, reparar o plano e verificar o resultado de forma independente.

\Ver a Demonstração\

[Ver a Arquitetura]

arquitetura

arquitetura-frontend

arquitetura-memória

arquitetura-autopilot

O problema e seu valor

A pesquisa de viagens não é o mesmo que um planejamento confiável de viagem. Um voo pode parecer barato, mas chegar tarde demais quando se aplica o tempo de traslado ao aeroporto e a margem de segurança de um torcedor. Uma preferência familiar pode desaparecer entre sessões. Um link de vendedor desatualizado pode retornar zero resultados. Uma estimativa de rota pode ser confundida com uma tarifa, ou dados incompletos de provedor podem se tornar uma alegação de reserva injustificada.

Para um evento de alto risco, essas não são falhas cosméticas: uma recomendação ruim pode tornar a viagem inteira inútil. O MatchDay transforma isso em restrições explícitas, estados de evidência e verificações de validação antes de mostrar um plano como completo.

Como o MatchDay funciona

O caminho de produção é:

\\`text

Torcedor → Next.js no Vercel → fachada de servidor assinada → Alibaba ECS

→ Caddy + FastAPI + PostgreSQL + trabalhadores duráveis

→ Qwen Cloud + ferramentas tipadas de viagem/contexto

→ normalizar → ranquear → detectar conflito → reparar → verificar

→ versão de viagem imutável e compartilhamento seguro de privacidade

\\`

O \qwen3.7-plus\ do Qwen Cloud é o controlador de planejamento em produção. Ele interpreta linguagem natural, classifica cada turno, resolve ambiguidades, seleciona ferramentas tipadas, propõe mudanças fundamentadas na memória, escolhe entre candidatos de reparo em lista de permissões e explica o resultado. O gateway limitado é implementado em \`[qwen.py\](../backend/matchday/qwen.py), enquanto o loop de ferramentas durável está em [\agent.py`](../backend/matchday/agent.py).

O modelo nunca certifica sua própria resposta. O código determinístico é dono dos esquemas, vinculação de fixtures, validação de evidências, aritmética de pacotes, imposição de restrições, detecção de conflitos, aplicação de reparos e o contrato de liberação independente de 14 verificações em \`[safety.py`](../backend/matchday/safety.py). Esta foi a decisão de arquitetura mais importante: use o modelo para julgamento, mas use o código para a verdade*.

A memória persistente segue o mesmo princípio. Fatos explícitos do usuário e comportamentos verificados repetidos entram em uma única fonte de verdade com escopo do proprietário, mas uma viagem incomum não se torna silenciosamente uma preferência permanente. O comportamento é promovido apenas após reforço em viagens-raiz distintas. A memória suporta recall limitado, namespaces por viagem, precedência da mensagem atual, correção, expiração, substituição, exclusão, desativação e reutilização auditável em \`[memory.py`](../backend/matchday/memory.py).

A autonomia é durável, não ilimitada. Leases do PostgreSQL, tokens de fencing, checkpoints, retentativas, cancelamento, idempotência e limites cumulativos de tempo/modelo/ferramenta/custo permitem que o trabalho interrompido seja retomado sem rodar para sempre ou gastar o mesmo orçamento duas vezes. O runtime está em \`[runs.py\](../backend/matchday/runs.py), e a implantação na Alibaba inicia serviços separados de API, run-worker, atualização de fixtures, PostgreSQL e Caddy em [\docker-compose.yml`](../deploy/alibaba/docker-compose.yml).

Onde o Codex acelerou o trabalho

O Qwen é a inteligência de runtime do MatchDay. O Codex com a configuração GPT-5.6 Sol Max foi meu acelerador de engenharia. Usei uma versão híbrida limitada do loop estilo Peter do OpenClaw — definir, construir, atacar, verificar, corrigir — em fatias pequenas e independentemente verificáveis.

O Codex acelerou o rastreamento de arquitetura, implementação, geração de testes de regressão, análise de causa raiz, revisão adversarial, QA de navegador e verificação de implantação. Ajudou a expor problemas que uma demonstração de caminho feliz perderia: divergência de fonte de verdade da memória após edições manuais, recall incorreto entre sessões, repasses de voos desatualizados ou com zero resultados, injeção de prompt e indireta, SSRF e redirecionamentos inseguros, ataques de replay, isolamento de tenant, condições de corrida, checkpoints desatualizados e renderização de mapa ou 3D degradada.

As principais decisões de produto permaneceram explícitas: escolhi o limite de confiança entre Qwen e determinístico, o limiar de promoção de memória de duas viagens, a taxonomia de evidências, checkpoints humanos para alegações não suportadas ou de alto risco e um limite de liberação sem compra. O Codex encurtou o ciclo de feedback e atacou cada alegação; não substituiu essas decisões de produto e segurança.

Como isso se alinha aos critérios de avaliação

• Inovação e criatividade em IA: O MatchDay combina memória entre sessões com um Autopilot durável, reparo com verificação de evidências e um verificador independente. O trilho visível `Lembrado → Conflito detectado → Plano reparado → Resultado verificado} torna essa arquitetura inspecionável, em vez de escondê-la atrás de uma resposta de chat.

• Profundidade técnica e engenharia: O Qwen Cloud direciona decisões tipadas; o Alibaba ECS executa o plano de controle e execução FastAPI/PostgreSQL; o Vercel fornece o limite de frontend assinado. O repositório inclui avaliações cegas à fonte, testes de contrato de provedor, verificações de concorrência do PostgreSQL e jornadas Playwright no Chromium, Firefox e WebKit.

• Valor do problema e impacto: O produto B2C atual protege torcedores que planejam viagens caras e críticas em termos de tempo. O caminho B2B futuro é um agente de planejamento incorporável ou white-label para agências de viagens, usando seu inventário, políticas, regras de aprovação e canais de clientes. A arquitetura de provedor AGPL-3.0 também suporta adoção em código aberto.

• Apresentação e documentação: Os jurados podem testar o aplicativo ao vivo sem credenciais, inspecionar o rastreamento de decisão factual, usar o mapa e a lente ilustrativa do estádio com limites explícitos de evidência, assistir à demonstração curta e regenerar cada diagrama de arquitetura a partir de sua fonte Graphviz.

O MatchDay está atualmente focado no planejamento de viagens para a Copa do Mundo e não realiza compras de viagens. Evidências comerciais ao vivo dependem de acesso configurado ao provedor; preços, inventário, disponibilidade ou termos de reembolso ausentes permanecem visivelmente desconhecidos. Viagens para eventos mais amplos e incorporação em agências são direções de produto, não alegações sobre a versão atual.

O objetivo é simples: um agente de viagem autônomo não deve apenas produzir uma resposta — deve lembrar com responsabilidade, agir dentro das evidências, reparar o que é inseguro e provar o plano final.#QWEN #ALIBABA #CODEX #OPENAI #HACKATHON #CLOUD