Como agentes de QA alimentam a propria base de conhecimento e reduzem de 2 horas para 10 minutos a busca pela causa de um bug

Imagine um profissional de QA passando duas horas tentando descobrir por que a vitrine de retirada no local esta vazia. No fim, nao era um bug. O cache de disponibilidade e atualizado a cada poucos minutos, enquanto um mock de estoque estava se sobrepondo ao proxy real por causa de uma prioridade incorreta. O conhecimento foi adquirido, mas ficou na cabeca de uma unica pessoa ou em um chat que ninguem encontrara uma semana depois. Um mes mais tarde, outro profissional de QA gasta as mesmas duas horas com o mesmo problema. Um agente de IA nao tem memoria alguma entre as sessoes e, por isso, repete esse percurso todas as vezes.

A equipe de testes da Techville resolveu o problema com uma plataforma dedicada chamada MKP, ou Multi Knowledge Platform. A seguir, analisamos como ela funciona e o que outras equipes podem aproveitar dessa abordagem.

O que e a MKP e como ela faz buscas

A MKP e uma plataforma interna com bases de conhecimento e busca inteligente. Existem dois tipos de base: a evawiki integrada, que contem a documentacao corporativa e so pode ser lida pela MKP, e as bases Markdown das equipes, nas quais os documentos podem ser criados, atualizados, excluidos e pesquisados por significado. O acesso pode ser feito por uma interface web, uma API REST ou um servidor MCP para agentes no Cursor, Claude Code e Codex. O MCP tem apenas cinco ferramentas: listar bases, fazer uma consulta semantica, obter um documento pelo numero, criar ou atualizar e realizar uma exclusao logica.

Por baixo do capo ha RAG, mas nao em sua forma mais ingenua. A recuperacao hibrida dense/sparse combina busca semantica com busca por palavras-chave. Isso e essencial para QA: a busca puramente vetorial costuma perder identificadores como GetExists, is_pickup ou CMA-14699. Em seguida entram multi-query, em que o modelo reformula a pergunta, reranking e recuperacao parent-child: a busca e feita em pequenos fragmentos, mas o contexto de toda a secao e devolvido. A resposta sempre inclui o texto, as fontes com score e snippet, alem de um trace_id para diagnostico.

O agente escreve na base por conta propria

A ideia central e que ninguem adiciona documentos manualmente; caso contrario, seis meses depois haveria apenas mais uma wiki abandonada. Em vez disso, a MKP foi integrada ao kit de QA, um repositorio com regras e skills para Cursor e Claude Code. O agente atua como editor: seleciona o conhecimento verificado da sessao, em vez de despejar toda a conversa na base.

Para cada dominio, como catalogo, busca ou recomendacoes, foram criadas quatro bases:

• wiki — conhecimento duradouro: arquitetura, ambientes, mocks e orientacoes sobre como testar corretamente;
• outputs — textos completos de planos de teste, resultados e comentarios para o Tracker;
• daily — registros diarios e um indice em forma de sumario;
• artifacts — evidencias brutas: curl, SQL, JSON e mocks.

Antes de apresentar um plano de teste, o agente deve realizar quatro buscas: se houve um reteste para os numeros exatos dos documentos, o que foi encontrado em casos semelhantes em outputs, o que a equipe sabe sobre o servico em wiki e o que o produto informa em eva-wiki. Depois dos testes, ele registra o plano, o resultado e o comentario em outputs, o dia em daily e qualquer novo fato duradouro em wiki.

O que isso entrega na pratica

Para uma vitrine vazia, uma consulta a catalog-wiki agora devolve um checklist de nove itens em 24 segundos. Ele inclui o cache de disponibilidade, as pre-vendas, a prioridade do mock no WireMock e um erro 403 do proxy de busca. Um profissional de QA percorre a lista em dez minutos, em vez de duas horas. Ninguem escreveu esse checklist como um artigo: ele foi montado a partir de analises de tarefas nas quais o agente acrescentou os fatos um a um.

Em uma tarefa sobre produtos analogos, o agente recupera antecipadamente os resultados de duas execucoes anteriores. Um novo profissional de QA sabe quais fixtures preparar, evita abrir um DEFECT falso para um caminho legacy inacessivel que um colega ja marcou como QUESTION e acrescenta imediatamente uma verificacao para saber se ha codigo antigo sem filtro no ambiente. Ao consultar o indice de daily, o lider consegue ver o que a equipe fez sem realizar uma reuniao de status separada.

Permissoes e disciplina

O acesso e controlado de forma rigorosa. Existem duas funcoes, admin e user, enquanto as permissoes read e write sao concedidas separadamente para cada base. Cada agente recebe um usuario proprio com privilegios minimos, e um usuario tecnico pode ser impedido de acessar a UI. O agente le as bases de seu dominio e a eva-wiki, mas escreve apenas em suas quatro bases. O autor do documento e identificado pela chave da API, e a equipe aparece nos metadados. O registro de acessos fica armazenado no git.

Limitacoes e conclusao

O artigo nao avalia a qualidade dos registros nem explica como e filtrado o conhecimento incorreto que um agente tenha inserido na wiki. Os numeros de economia de tempo sao internos e se baseiam em exemplos isolados. Um documento novo tambem nao fica disponivel imediatamente na busca: primeiro ele passa pelo status processing.

A conclusao pratica para equipes que trabalham com agentes e que elas nao precisam de mais uma wiki, mas de um ciclo de "lembrar, trabalhar, registrar". O conjunto minimo consiste em separar o conhecimento duradouro dos resultados das execucoes, obrigar o agente a pesquisar antes de trabalhar, conceder a ele permissoes restritas e armazenar as fontes junto da resposta. Assim, cada tarefa torna a proxima mais barata.