A LangChain levantou 160 milhões de dólares. Três anos de desenvolvimento. Uma avaliação de bilhões de dólares. O LangSmith, a plataforma de testes deles, é genuinamente sofisticado: avaliações de trajetória, pipelines de rastreamento para datasets, LLM como juiz, suítes de regressão, frameworks de teste unitário para ferramentas. Eles têm as peças. Crédito onde é devido.
Mas peças não são uma prática.
A LangChain te dá ferramentas de teste. Ela nunca te diz o que testar, em que ordem, ou quando você terminou.
Não existe um workflow opinativo que diga, em ordem:
- essa falha aconteceu
- agora escreva uma skill
- agora escreva o código determinístico
- agora escreva testes unitários
- agora escreva avaliações de LLM
- agora adicione um gatilho de resolver
- agora avalie o resolver
- agora audite por duplicatas
- agora faça o smoke test
- agora arquive corretamente
Esse loop não existe. Você tem que inventá-lo sozinho a partir de primitivas dispersas. Uma grande quantidade de usuários de IA ainda não testa seus agentes, porque o framework que escolheram provavelmente deu a eles uma assinatura de academia sem um plano de treino.
A maioria das "confiabilidades" de agentes de IA é baseada em vibes. Ajustes de prompt. Mensagens de sistema maiores. Encantações de "por favor, não alucine". Essas coisas se degradam no momento em que a conversa fica complexa. Os frameworks que levantaram centenas de milhões de dólares para resolver isso te deram dashboards de monitoramento e ajudantes de teste unitário e disseram "boa sorte."
Meu agente errou duas vezes esta semana. Nenhuma dessas falhas pode acontecer de novo. Não porque eu pedi educadamente. Porque eu transformei cada falha em uma correção estrutural permanente: uma skill com testes que rodam todos os dias, para sempre.
Eu chamo essa prática de "skillify." Depois que você usa, seus agentes não vão continuar cometendo os mesmos erros. Aqui está como funciona.
Falha 1: A Viagem Que Já Estava no Banco de Dados
Perguntei ao meu OpenClaw sobre uma viagem de negócios antiga, de quase dez anos atrás, enterrada em algum lugar no histórico do calendário. Pergunta simples. Deveria levar um segundo.
Em vez disso, o agente fez isso:
- Chamou a API de calendário ao vivo → bloqueada (muito antiga).
- Tentou pesquisa de e-mail → resultados ruidosos, nada conclusivo.
- Chamou a API de calendário novamente com parâmetros diferentes → ainda bloqueada.
- Cinco minutos depois, pesquisou minha base de conhecimento local e encontrou instantaneamente.
A resposta estava sentada nos meus próprios dados o tempo todo. 3.146 arquivos de calendário abrangendo 2013 a 2026. Já indexados. Já locais. Um grep de distância.
O agente simplesmente não olhou lá primeiro.
No framework sobre o qual venho escrevendo (arreios finos, skills robustas) há uma distinção chave entre trabalho que requer julgamento e trabalho que requer precisão. Eu os chamo de latente e determinístico. O grep no calendário é determinístico. Mesma entrada, mesma saída, toda vez. Nenhum modelo necessário. Mas o agente fez isso no espaço latente de qualquer forma, gerando raciocínio, fazendo chamadas de API, interpretando resultados, quando um script de três linhas teria retornado a resposta instantaneamente.
Esse é o bug. Não uma resposta errada. Um lado errado.
A correção: calendar-recall (Passos 1 + 2)
Em arreios finos / skills robustas, uma skill é um procedimento em markdown que ensina o modelo como abordar uma tarefa. Não o que fazer (o usuário fornece o que). A skill fornece o processo. Pense nisso como uma chamada de método: mesmo procedimento, saídas radicalmente diferentes dependendo do que você passa.
Aqui está a skill que surgiu dessa falha:
nome: calendar-recall descrição: "Consulta de calendário histórico cérebro-primeiro. SEMPRE use isso antes de qualquer API ao vivo para qualquer evento que não seja no futuro ou nas últimas 48 horas."
E a regra rígida interna:
APIs de calendário ao vivo são APENAS para eventos no FUTURO ou nas ÚLTIMAS 48 HORAS. Tudo que é histórico vai pela base de conhecimento local primeiro.
Aqui está o que faz isso funcionar: o próprio agente escreveu o script determinístico. O arquivo da skill (markdown, vivendo no espaço latente) disse ao agente como corrigir o problema. O agente leu a skill, entendeu que a pesquisa de calendário é trabalho determinístico e gerou um script para lidar com isso:
$ node scripts/calendar-recall.mjs search "Singapura"
Encontrado(s) 2 dia(s) correspondente(s): ── 2016-05-07 ── Voo para Singapura, check-in no Mandarin Oriental ── 2016-05-08 ── Almoço com investidores no Fullerton Hotel
Código que roda em menos de 100 milissegundos (a maior parte é a inicialização do Bun; o grep real é abaixo de um milissegundo). Zero chamadas de LLM. Zero rede. Apenas arquivos locais.
Este é o loop que faz toda a arquitetura funcionar: o espaço latente constrói a ferramenta determinística, então a ferramenta determinística restringe o espaço latente. O agente usou julgamento (latente) para escrever calendar-recall.mjs. Agora a skill força o agente a executar esse script em vez de raciocinar sobre dados de calendário. A inteligência do modelo criou a restrição que impede o modelo de ser estúpido.
O caminho da falha antiga se torna estruturalmente inatingível. A skill diz "pesquise local primeiro." O script faz a pesquisa. O agente nunca tem a chance de ser esperto sobre isso ou errar de novo.
Falha 2: "28 Minutos" (Passos 1 + 2 de novo)
Mesmo dia. Agente diz: "Sua próxima reunião é em 28 minutos."
Realidade: 88 minutos de distância. O agente fez a conversão de fuso horário UTC→PT de cabeça e errou por exatamente uma hora.
A questão é que um script já existia (context-now.mjs) que produz isso:
{ "agora": "2026-04-21T07:38:12-07:00", "eventosFuturos": [{ "resumo": "Planejamento da Sprint de App Ops", "minutosAte": 88 }] }
Código que roda em cerca de 50 milissegundos. Zero ambiguidade. O agente simplesmente não o executou.
Mesma forma de antes: trabalho determinístico (subtrair timestamps) feito no espaço latente. O modelo estava fazendo cálculo mental quando um script tinha a resposta.
A correção: context-now, a skill:
nome: context-now descrição: "Disciplina SEMPRE-ATIVA: execute context-now.mjs antes de fazer QUALQUER afirmação sensível ao tempo. Nunca faça conversão UTC→PT de cabeça."
Aqui está o simples antes/depois com e sem essas skills simples:
Skillify: O padrão que vai salvar sua sanidade
Duas falhas. Mesma forma. O agente tinha a ferramenta certa e escolheu esperteza em vez de disciplina. A coisa errada aconteceu no espaço de máquina errado.
Em uma configuração normal de IA, a IA vai se desculpar, prometer melhorar e, duas semanas depois, a mesma coisa acontece com uma consulta diferente ou um fuso horário diferente. O agente não tem memória do bug, nenhum teste para o bug, nada impede que ele se repita.
Skillify é a correção. Toda falha se torna uma skill. Toda skill tem testes. O bug se torna estruturalmente impossível de repetir.
Aqui está a lista de verificação de 10 itens que uso quando uma falha é promovida:
□ 1. SKILL.md — o contrato (nome, gatilhos, regras) □ 2. Código determinístico — scripts/*.mjs (sem LLM para o que o código pode fazer) □ 3. Testes unitários — vitest □ 4. Testes de integração — endpoints ao vivo □ 5. Avaliações de LLM — qualidade + correção □ 6. Gatilho do resolver — entrada em AGENTS.md □ 7. Avaliação do resolver — verificar se o gatilho realmente roteia □ 8. Auditoria de resolvível + DRY □ 9. Teste de fumaça E2E □ 10. Regras de arquivamento cerebral
Uma funcionalidade que não passa em todos os dez não é uma skill. É apenas código que funciona hoje.
As duas falhas acima já percorreram os passos 1 e 2: escrever o SKILL.md (o contrato), depois escrever o código determinístico (o script que o agente constrói e então usa). Mas antes de eu percorrer os oito passos restantes, quero mostrar como é o skillify no uso diário, porque não é apenas uma resposta a falhas. Tornou-se um verbo.
Skillify como um verbo
Para mim, construindo meu OpenClaw (e GBrain), a lista de verificação começou como um protocolo de resposta a falhas. Depois se tornou a maneira como construí tudo.
Aqui está como é meu fluxo de trabalho real. Estou conversando com meu agente em linguagem natural. Construímos algo juntos em conversa. Eu testo. Funciona. Então eu digo uma palavra:
Garry:
caramba, funcionou. pode lembrar disso como uma skill de webhook e skillificar, da próxima vez que precisarmos fazer alguns webhooks? por que foi tão difícil acertar isso? de qualquer forma, está bom agora. DRY também
Isso foi uma integração de webhook OAuth. Passamos uma hora fazendo funcionar. Então "skillify" transformou a sessão ad-hoc em uma skill durável com testes, uma entrada no resolver e documentação. Na próxima vez que eu precisar de um webhook, a skill existe. O agente a lê. O conhecimento arduamente conquistado naquela hora é permanente.
Outro exemplo. Descobrimos que nosso contêiner precisa de um navegador headless para certas tarefas e um navegador com cabeçalho no meu desktop para outras:
Garry:
ótimo! então devemos realmente lembrar disso como uma skill sempre que algo no openclaw precisar de um navegador headless! e também saber que se precisarmos de um navegador com cabeçalho, devemos pedir ao usuário para executar o gstack browser e nos dar um código de par de agente. skillify!
Uma mensagem. O agente escreve skills/browser/SKILL.md com a árvore de decisão, os scripts determinísticos, os testes. Agora toda sessão futura que precisar de um navegador é roteada para a ferramenta certa automaticamente.
Ou isto. Notei que o agente continuava me enviando links do ngrok sem verificar se realmente funcionavam:
Garry:
podemos criar uma skill que diga que sempre que você me enviar um link, você tem que fazer um curl nele mesmo para garantir que o endpoint está aberto e o túnel funciona? skillify!
Ou a reserva dupla no calendário que quase me custou uma reunião:
Garry:
Aqui está uma skill regular que preciso que você escreva. É a skill de verificação de calendário. Amanhã tenho um 11h com reserva dupla. Crie uma skill, torne-a determinística para verificar esses tipos de coisas.
Uma frase. Código, skill, testes, entrada no resolver, auditoria de alcançabilidade. A lista de verificação completa de 10 passos em um só fôlego. Meu OpenClaw sabe, faz, e agora é um ritmo. Já fiz isso dezenas de vezes. Eu não conseguiria viver sem isso.
O padrão é sempre o mesmo: prototipar em conversa, ver funcionar, dizer "skillify", e o protótipo se torna infraestrutura permanente. Eu não escrevo especificações. Não abro tickets. Eu converso com meu agente, resolvemos o problema juntos, e então a solução se torna uma skill que o agente pode usar para sempre sem mim.
Isso é o que os 160 milhões de dólares em financiamento de framework perderam. Não as primitivas de teste. Não as ferramentas de avaliação. O workflow. O momento em que um humano diz "funcionou, agora torne isso permanente" e o sistema sabe exatamente o que "permanente" significa: SKILL.md, código determinístico, testes unitários, testes de integração, avaliações de LLM, gatilho do resolver, avaliação do resolver, auditoria DRY, teste de fumaça, arquivamento cerebral. Dez passos. Uma palavra.
Aqui está como são os oito passos restantes na prática.
Passo 3: Testes unitários
Vitest clássico. Funções determinísticas, asserções determinísticas. calendar-recall.mjs exporta funções puras como parseEventLine, eventMatchesKeyword, searchKeyword, formatJson. Cada uma é testada contra dados de fixture: arquivos de calendário sintéticos em um diretório temporário, entradas conhecidas, saídas conhecidas.
O tipo de bug que eles pegam: parseEventLine descarta silenciosamente eventos com caracteres Unicode no campo de local. dateFromPath retorna null para datas de ano bissexto. formatJson omite o array de participantes quando há apenas uma pessoa. Pequeno, chato, crítico. Se o script produzir saída errada, a skill produz respostas erradas, e o agente me diz a coisa errada com confiança.
Para context-now, os testes unitários verificam a formatação de fuso horário, a detecção de horário de silêncio e o cálculo de minutosAté através dos limites de horário de verão. Um teste alimenta um horário 3 minutos antes de uma transição de horário de verão e verifica se a saída não pula 60 minutos. Esse é exatamente o bug que causou a falha dos "28 minutos". Agora é estruturalmente impossível.
Tenho 179 testes unitários em 5 suítes. Eles rodam em menos de 2 segundos.
Passo 4: Testes de integração
Estes atingem endpoints ao vivo e dados reais. O calendar-recall.mjs realmente encontra eventos no repositório cerebral real, não apenas nas fixtures de teste? O context-now.mjs produz JSON válido quando o cache do calendário está desatualizado ou ausente? Testes de integração pegam os bugs que os testes unitários perdem porque os dados de fixture eram limpos demais. Dados reais têm linhas de evento malformadas, campos de fuso horário ausentes, arquivos de calendário com quebras de linha do Windows, eventos que abrangem a meia-noite.
A regra: se você se pegar verificando manualmente se o script fez a coisa certa com dados reais, essa verificação deve ser um teste de integração.
Passo 5: Avaliações de LLM
É aqui que fica interessante. Algumas saídas requerem julgamento para avaliar. "Este resumo de calendário é útil?" não é uma pergunta de sim/não que um script pode responder. Então eu uso o LLM como juiz: um modelo avaliando a saída de outro modelo contra uma rubrica.
Para context-now, 35 avaliações rodam diariamente. Uma delas alimenta o agente com uma mensagem como "ei, meu voo sai em cerca de 45 minutos, vou conseguir chegar ao SFO?" e verifica se o agente executa context-now.mjs antes de responder ou tenta fazer a conta de cabeça. Se o agente cair na armadilha e calcular o horário sozinho, a avaliação falha.
Outra avaliação dá ao agente um timestamp UTC e pergunta "que horas é isso para mim?" O comportamento correto é executar o script e citar o resultado. O comportamento incorreto é fazer a conversão mentalmente. A avaliação pega tanto a resposta errada QUANTO o processo errado, porque mesmo que o cálculo mental esteja certo desta vez, estará errado na próxima.
A heurística de avaliação mais honesta que encontrei: pesquise seu histórico de conversas por quando você disse "puta merda" ou "q porra é essa". Esses são os casos de teste que você está perdendo.
Passo 6: Gatilho do resolver
Um resolver é uma tabela de roteamento para contexto: quando o tipo de tarefa X aparece, carregue a skill Y. Escrevi sobre resolvers em detalhes aqui. Cada skill precisa de uma entrada de gatilho em AGENTS.md, o arquivo que ensina ao agente quais skills existem e quando usá-las.
Gatilhos de resolver são apenas linhas em uma tabela markdown:
O bug que este passo pega: você escreve uma nova skill, mas esquece de adicioná-la ao resolver. A skill existe. A capacidade existe. O sistema não consegue alcançá-la. É como ter um cirurgião na equipe, mas não listá-lo no diretório do hospital. Pior do que não ter a skill, porque você pensa que o sistema lida com isso.
Passo 7: Avaliação do resolver
Esta é a camada que a maioria das pessoas perde completamente. Um gatilho de resolver diz "esta frase deve rotear para esta skill." Uma avaliação do resolver testa se isso realmente acontece.
Minha suíte de avaliação do resolver tem mais de 50 casos de teste como este:
{ intenção: 'verificar minhas assinaturas', skillEsperada: 'executive-assistant' }, { intenção: 'quem é Pedro Franceschi', skillEsperada: 'brain-ops' }, { intenção: 'salvar este artigo', skillEsperada: 'idea-ingest' }, { intenção: 'que horas é minha reunião', skillEsperada: 'context-now' }, { intenção: 'encontrar minha viagem de 2016', skillEsperada: 'calendar-recall' },
Dois modos de falha. Falso negativo: a skill deveria disparar, mas não dispara, porque a descrição do gatilho está errada ou ausente. Falso positivo: a skill errada dispara, porque dois gatilhos se sobrepõem. "O que está na minha agenda amanhã?" deveria rotear para calendar-check, não para calendar-recall e nem para google-calendar. Três skills, três domínios de tempo diferentes, uma frase que poderia plausivelmente corresponder a qualquer uma delas. A avaliação do resolver pega a ambiguidade antes que um usuário a encontre.
Eu executo essas avaliações tanto como testes estruturais determinísticos (a tabela AGENTS.md contém o mapeamento correto?) quanto como testes de roteamento de LLM (dada esta intenção, o modelo realmente escolhe a skill certa?). Ambas as camadas importam. A tabela pode estar correta e o modelo ainda pode rotear errado porque a descrição do gatilho é vaga.
Passo 8: Auditoria de resolvível + DRY
Depois de um mês de construção, eu tinha mais de 40 skills. Algumas criadas em resposta a incidentes específicos, outras geradas por sub-agentes executando crons. Ninguém estava mantendo a tabela do resolver. Skills estavam nascendo, mas não sendo registradas.
Então construí o check-resolvable. Um meta-teste que percorre toda a cadeia: resolver AGENTS.md → SKILL.md → script/cron. Se um script existe que faz trabalho útil, mas não tem caminho a partir do resolver, é inalcançável. O LLM nunca saberá usá-lo.
A primeira execução encontrou 6 skills inalcançáveis de mais de 40. Quinze por cento das capacidades do sistema estavam ocultas.
- Um rastreador de voos que ninguém conseguia invocar perguntando sobre voos.
- Um gerador de ideias de conteúdo que só rodava no cron, mas não podia ser acionado manualmente.
- Um corretor de citações que existia no diretório de skills, mas não estava listado no resolver.
Corrigido em uma hora. Apenas adicionei entradas de gatilho ao AGENTS.md. Agora o check-resolvable roda semanalmente como parte do gbrain doctor. Ele verifica três coisas:
- Todo diretório de skill com um SKILL.md tem uma entrada correspondente no resolver.
- Todo script referenciado por uma skill é realmente chamável (arquivo existe, exporta as funções certas).
- Nenhuma duas skills têm descrições de gatilho sobrepostas que causariam roteamento ambíguo.
A auditoria DRY roda junto. Você acaba com quinze skills que mais ou menos fazem a mesma coisa se não tomar cuidado, e o resolver escolhe aquela em que o dado cai. Para calendar-recall:
Quatro skills no mesmo domínio. Zero sobreposição. Cada uma tem sua faixa. Essa matriz não é um diagrama desenhado para este post. Ela vive dentro do SKILL.md, e o script de auditoria a analisa. Construa uma sexta skill de calendário que pise na faixa de outra e a auditoria falha antes que a skill possa ser lançada.
Passo 9: Teste de fumaça E2E
O pipeline completo, de ponta a ponta.
- Pergunte ao agente "quando eu fui para Cingapura?" e verifique se ele executa calendar-recall.mjs, obtém a resposta certa e a formata corretamente.
- Pergunte "que horas é minha próxima reunião?" e verifique se ele executa context-now.mjs em vez de fazer cálculo mental.
Testes de fumaça são a última linha de defesa. Tudo o mais pode passar e o sistema ainda pode falhar se as peças não se conectarem. A skill pode estar correta, o script pode estar correto, o resolver pode estar correto, e o agente ainda pode escolher ignorar tudo e improvisar. O teste de fumaça pega isso.
Passo 10: Regras de arquivamento cerebral
Toda skill que escreve na base de conhecimento precisa saber onde as coisas vão. Uma pessoa vai em pessoas/. Uma empresa vai em empresas/. Uma análise de política vai em cívico/. Peguei 10 de 13 skills de escrita cerebral arquivando no diretório errado porque cada uma havia codificado seus próprios caminhos em vez de consultar o resolver.
O documento de regras de arquivamento cataloga padrões comuns de arquivamento incorreto. Fontes vs. originais. Pessoas vs. empresas (quando alguém É uma empresa). A skill lê as regras antes de criar qualquer página. Zero arquivamentos incorretos desde então.
GBrain: onde o Skillify vive, e você deve adotá-lo do meu Pacote de Skills GBrain
O padrão skillify não é específico do OpenClaw ou de qualquer arreio em particular. Está embutido no GBrain. GBrain é o mecanismo de conhecimento de código aberto que escrevi e que fica abaixo de qualquer arreio que você usar. Ele gerencia seu repositório cerebral, executa suas avaliações e aplica os portões de qualidade que tornam as skills duráveis.
Um GBrain SkillPack é um pacote portátil de skills, gatilhos de resolver, scripts determinísticos e testes que você pode instalar em qualquer configuração de agente apenas pedindo ao OpenClaw/Agente Hermes para fazê-lo. É assim que skills e habilidades que escrevi para meu OpenClaw/Agente Hermes podem ser automaticamente adicionadas ao SEU OpenClaw — incluindo toda a saída skillify de 10 passos, empacotada para que você possa colocá-la em seu OpenClaw/Agente Hermes e simplesmente funcionar.
A lista de verificação skillify de antes não é uma sugestão. É o que o gbrain doctor realmente verifica.
gbrain doctor --fix auto-repara violações DRY, substitui blocos duplicados por referências de convenção, tudo protegido por verificações da árvore de trabalho do git para que nada seja sobrescrito.
Por que o Agente Hermes não é suficiente sozinho
O Agente Hermes da Nous Research faz algo genuinamente ótimo: ele tem uma ferramenta skill_manage que permite que o próprio agente crie, corrija e exclua skills com base no que aprende. Quando o agente termina uma tarefa complexa ou se recupera de um erro, ele propõe uma skill e a escreve no disco. Isso é memória processual que o agente ganha por conta própria. Divulgação progressiva (carregue um índice de skill primeiro, puxe o SKILL.md completo apenas quando selecionado). Memória limitada (MEMORY.md com limite de 2.200 caracteres). Ativação condicional (skills se auto-ocultam quando as ferramentas necessárias não estão disponíveis). Design inteligente.
Mas o Hermes não testa suas skills. Sem testes unitários no código determinístico. Sem avaliações do resolver para verificar o roteamento. Sem check-resolvable para encontrar skills ocultas. Sem auditoria DRY para capturar duplicatas. Sem verificação de saúde diária que fica vermelha quando algo se desvia.
Os modos de falha que testemunhei acumularem em qualquer sistema de skill não testado:
- Agente cria deploy-k8s na segunda-feira. Quinta-feira cria kubernetes-deploy de uma conversa diferente. Ambos existem. Ambos disparam em frases semelhantes. Roteamento ambíguo, e ninguém percebe até que o errado dispare no momento errado.
- Skill funciona perfeitamente quando escrita. Seis semanas depois, a API upstream muda de forma. A skill retorna silenciosamente lixo até que um humano o detecte.
- Uma skill criada autonomamente tem um gatilho fraco que nunca corresponde. Torna-se um órfão, consumindo tokens de índice, nunca executando, apodrecendo lentamente.
Este é o problema "sem testes, qualquer base de código apodrece" que a engenharia de software resolveu em 2005. Skills de agente não são diferentes. O Hermes lida com a criação lindamente. O GBrain lida com a verificação. Você precisa de ambos.
A grande ideia
Em uma equipe de engenharia de software saudável, todo bug recebe um teste. Esse teste vive para sempre. O bug se torna estruturalmente impossível de recorrer. Agentes de IA devem funcionar da mesma forma.
Toda falha se torna uma skill. Toda skill tem avaliações. Toda avaliação roda diariamente. O julgamento do agente melhora permanentemente, não apenas para a sessão atual, não apenas enquanto a janela de contexto se mantém.
A falha da viagem não acontecerá de novo. A falha de fuso horário não acontecerá de novo. E quando a próxima falha aparecer (e vai, porque este é um jogo adversarial contra entropia e gosto), ela também será skillificada.
O agente com quem trabalho daqui a um ano será moldado por cada erro que cometeu no ano anterior. Isso não é um "bom ter". Essa é toda a tese.
Ferva o oceano. Faça seu agente fazer algo, depois skillifique. Você faz isso todos os dias e tem um OpenClaw inteligente pra caramba que faz tudo o que você quer que ele faça.
Ou você pode simplesmente carregar o GBrain, usar todo o código que já escrevi e pular direto para seu próprio Jarvis do Homem de Ferro mais cedo.
--
GStack para acelerar no Claude Code github.com/garrytan/gstack
GBrain para construir seu próprio Jarvis do Homem de Ferro no OpenClaw/Agente Hermes github.com/garrytan/gbrain
