2026-05-29 Retrospectiva

O que fiz hoje

Ao tentar melhorar um problema que começou ontem, hoje encontrei uma ferramenta MCP que permite integrar melhor a pesquisa na web.

A ferramenta verificada foi o web-search-mcp, que oferece buscas nos navegadores bing, brave e duckduckgo como MCP.

• https://github.com/mrkrsl/web-search-mcp

Mais tarde pretendo fazer um fork e customizar de acordo com o fluxo de trabalho atual.

Impressões ao usar o Qwen 3.6

O modelo Qwen 3.6 foi mais lento em suas decisões do que eu esperava.

Ele pediu para sincronizar e fazer push do workflow em .github do qwen-code exatamente como está, mas na prática tentou copiar apenas alguns arquivos para o diretório .qwen. Esse foi o problema central.

Acabei clonando manualmente, alinhando os diretórios .github e .qwen exatamente como no original, e então prossegui. Era simplesmente uma questão de “alinhar a estrutura original”, mas o modelo confundiu caminhos e propósitos, gerando esforços desnecessários.

Insight sobre o próprio Qwen

O Qwen não é um modelo sem capacidade, mas sim um modelo que tem capacidade porém baixa controlabilidade.

Ele é bastante bom em busca de informações, edição de código, manipulação de arquivos e execução de tarefas longas. O problema é que ele tem dificuldade em manter a intenção do usuário fixa até o fim. Em especial, tende a esquecer ou sobrescrever restrições como “copie exatamente”, “não modifique”, “não faça inferências”, “use apenas o padrão oficial”, “não altere este caminho” durante a execução.

Ou seja, o Qwen não é que não consegue fazer o trabalho, mas que reinterpreta a direção do trabalho à sua maneira.

O problema original desta tarefa era simples.

Copiar .github oficial exatamente
Excluir .qwen
Push
Teste

No entanto, o Qwen continuou a expandir isso para outros problemas.

MCP é um problema?  
workflow_call é um problema?  
Preciso adicionar um gatilho de push?  
Devo criar um .qwen/commands?  
É um problema de JSON no stderr?  
É um problema de revisão vazia?

Antes de resolver o problema, ele já o havia ampliado. Em LLMs do tipo agente, esse ponto é crítico. Quanto maior a unidade de trabalho, mais ele deixa de atender ao pedido original e começa a resolver sub‑problemas que ele mesmo criou.

Mesmo adicionando buscas na web, o problema não foi totalmente resolvido. O fluxo ideal é primeiro consultar a documentação oficial ou o código‑fonte, entender a estrutura e, comparando com a solicitação do usuário, executar apenas as tarefas necessárias. Contudo, o Qwen primeiro faz inferência, cria uma hipótese, busca para confirmar essa hipótese e, então, ajusta a hipótese com os resultados da busca.

Portanto, a busca na web acabou sendo usada mais como uma ferramenta de reforço de hipóteses do que como um instrumento de trabalho baseado em evidências. Verificou‑se que a atitude ao lidar com os resultados da busca é mais importante que a própria capacidade de busca.

A interpretação de estados de falha também era fraca. Por exemplo, se o resultado de git ls-files .qwen/ estiver vazio, a conclusão correta seria que .qwen não está em estado rastreado. Em vez disso, ele continuou repetindo comandos como git rm -r --cached .qwen/. Embora tenha habilidade de executar comandos, sua capacidade de interpretar o resultado da execução e mudar o comportamento, bem como de sair de loops, era instável.

Além disso, o Qwen tem dificuldade com tarefas de preservação “exatamente como está”. Ele é proativo na criação e modificação, mas ao tentar preservar o original e sincronizá‑lo fielmente, tenta constantemente melhorar. Pode acabar quebrando a estrutura original ao sugerir coisas como criar .qwen mesmo que não exista na documentação, adicionar um gatilho que falta ou fazer com que algo seja executado automaticamente no push, embora não esteja especificado.

Por isso, é mais seguro dividir a tarefa para o Qwen em etapas menores, em vez de confiar nele para “copiar exatamente como está” na documentação.

Exibir lista de arquivos oficiais  
Exibir lista dos meus arquivos  
Exibir diferença (diff)  
Copiar apenas os arquivos aprovados pelo usuário

Conceder muita autonomia ao Qwen também é arriscado. Permissões como modificar arquivos, git add, commit, push, alterar o fluxo de trabalho, fazer ajustes adicionais após testes automáticos são perigosas, pois um julgamento errado pode ser empurrado até a execução.

Portanto, o papel do Qwen deve estar mais próximo de um gerador de candidatos, resumidor de logs e assistente de interpretação de resultados de comandos, em vez de ser o gestor de tarefas ou o executor final.

Qwen = gerador de candidatos / resumidor de logs / assistente de interpretação de resultados de comando  
Usuário ou script = executor final

Estrutura de saída também deve ser cuidadosa. Não que o Qwen seja incapaz de lidar com JSON, mas delegar esquemas complexos ou gerenciamento de estado de workflow pode comprometer a estabilidade geral. Revisões em Markdown, explicações de código, resumos de logs, organização de possíveis causas e geração de rascunhos de correções são adequados. Por outro lado, a produção precisa de esquemas JSON, gerenciamento complexo de estado de workflow, controle da ordem de chamadas de ferramentas, operações na API do GitHub, preservação de caminhos de arquivos e decisões de commit/push são inadequados.

Concluindo, o Qwen funciona bem como gerador, mas é instável como orquestrador.

O ponto central está nesta frase.

O Qwen é um modelo generativo inteligente, mas sua controlabilidade, interpretação de estado e preservação de instruções são fracas para ser usado como um gestor de tarefas confiável ou agente de automação.

A conclusão prática é a seguinte.

É possível fazer Qwen pensar.  
É possível confiar o rascunho ao Qwen.  
Não se deve confiar ao Qwen a manipulação final do repositório.

Se você continuar usando o Qwen, é recomendável estabelecer o seguinte princípio operacional.

Proibição de trabalho autônomo  
Um comando por vez  
Exibir diff antes da modificação  
Proibição de commit/push  
A preservação do original oficial deve ser aprovada por uma pessoa  
A saída do LLM deve ser usada apenas como Markdown/texto

Impressões sobre a pesquisa na web no MCP

Ao adicionar a pesquisa na web, o desempenho de busca melhorou claramente em relação ao método tradicional de patch da web. A velocidade de encontrar o material necessário e o alcance da pesquisa melhoraram, e isso ajudou a reunir links candidatos.

No entanto, havia uma tendência de interpretar erroneamente as informações obtidas pela pesquisa na web. A pesquisa em si era boa, mas a capacidade de julgar os resultados de busca no contexto do trabalho de código ainda era instável.

Por isso, senti que pode ser melhor separar o LLM de codificação do LLM de pesquisa. Deixar a pesquisa para modelos ou ferramentas especializadas em busca e validar separadamente o julgamento de codificação parece ser uma estrutura mais estável.

Reflexão

Algumas das dificuldades de hoje foram, na verdade, problemas simples cujas respostas eu já conhecia.

Era só alinhar .github e .qwen exatamente como o original, mas acabei complicando o problema ao seguir as tentativas intermediárias do modelo. Da próxima vez, verificarei primeiro se o resultado entregue pelo modelo corresponde à estrutura exigida e, nas sincronizações de caminho/arquivo, farei a validação inicial com diff.

Especialmente, é necessário cultivar o hábito de confirmar primeiro “se o original e o destino têm a mesma estrutura” ao invés de apenas “o que foi copiado”.

Problema de interrupção do trabalho

Depois das 14h de hoje, a internet ficou instável e o servidor Qwen que estava rodando no RunPod saiu do ar. Desde então, não foi possível chamar o modelo, dificultando a continuação do trabalho.

O trabalho local e a organização foram possíveis, mas ficou claro novamente que o fluxo automático de revisão/pesquisa/validação baseado no servidor Qwen depende fortemente do estado da internet.

Próximas ações

• Forkar o web-search-mcp e personalizar o motor de busca e o formato de saída conforme necessário.
• Separar a etapa de resumo dos resultados de busca da etapa de julgamento de codificação para reduzir erros quando o Qwen interpreta os resultados da pesquisa.
• Para tarefas críticas de sincronização de estrutura de diretórios, como .github e .qwen, validar primeiro com base em diff.
• Não conceder permissões de manipulação de repositório ao Qwen imediatamente; operar um comando de cada vez e confirmar o diff.
• Receber a saída do Qwen inicialmente como rascunho Markdown/texto, deixando o esquema JSON ou a orquestração da API do GitHub para scripts ou intervenção humana.
• Preparar um modelo de fallback ou procedimentos locais de verificação para lidar com falhas no servidor Qwen do RunPod.