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 conjunto de dados, LLM como juiz, suítes de regressão, estruturas 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.
LangChain oferece ferramentas de teste. Nunca te diz o que testar, em que ordem, ou quando terminar.
Não existe um fluxo de trabalho 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 duplicatas
- agora faça um teste de fumaça
- 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 a estrutura que escolheram provavelmente deu a eles uma academia sem um plano de treino.
A maior parte da "confiabilidade" de agentes de IA é baseada em vibes. Ajustes de prompt. Mensagens de sistema maiores. Encantamentos do tipo "por favor, não alucine". Essas coisas decaem no momento em que a conversa fica complexa. As estruturas que levantaram centenas de milhões de dólares para resolver isso te deram painéis de monitoramento e ajudantes de teste unitário e disseram "boa sorte."
Meu agente errou duas vezes esta semana. Nenhuma falha pode acontecer de novo. Não porque pedi educadamente. Porque 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, quase dez anos atrás, enterrada em algum lugar do 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 → bloqueado (muito antigo).
- Tentou busca no e-mail → resultados ruidosos, nada conclusivo.
- Tentou a API de calendário novamente com parâmetros diferentes → ainda bloqueado.
- Cinco minutos depois, pesquisou minha base de conhecimento local e encontrou instantaneamente.
A resposta estava nos meus próprios dados o tempo todo. 3.146 arquivos de calendário abrangendo 2013 a 2026. Já indexados. Já locais. A um grep de distância.
O agente simplesmente não olhou lá primeiro.
Na estrutura que venho escrevendo (thin harness, fat skills) existe uma distinção chave entre trabalho que exige julgamento e trabalho que exige precisão. Eu os chamo de latente e determinístico. O grep de calendário é determinístico. Mesma entrada, mesma saída, sempre. 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 e 2)
No thin harness / fat skills, uma skill é um procedimento em Markdown que ensina o modelo como abordar uma tarefa. Não o que fazer (o usuário fornece o "o quê"). A skill fornece o processo. Pense como uma chamada de método: mesmo procedimento, resultados radicalmente diferentes dependendo do que você passa.
Aqui está a skill que surgiu dessa falha:
nome: calendar-recall descrição: "Busca histórica de calendário primeiro no cérebro. SEMPRE use isso antes de qualquer API ao vivo para eventos que não sejam no futuro ou nas últimas 48 horas."
E a regra rígida dentro dela:
APIs de calendário ao vivo são APENAS para eventos no FUTURO ou nas ÚLTIMAS 48 HORAS. Tudo histórico passa 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 busca no calendário é trabalho determinístico e gerou um script para lidar com isso:
$ node scripts/calendar-recall.mjs search "Singapore"
Encontrado(s) 2 dia(s) correspondente(s): ── 2016-05-07 ── Voo para Cingapura, 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 é inicialização do Bun; o grep real é submilissegundo). 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 burro.
O caminho de falha antigo se torna estruturalmente inalcançá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 e 2 novamente)
Mesmo dia. O agente diz: "Sua próxima reunião é em 28 minutos."
Realidade: 88 minutos de distância. O agente tinha feito a conversão de fuso horário UTC→PT de cabeça e errou por exatamente uma hora.
O problema é que já existia um script (context-now.mjs) que produz isso:
{ "now": "2026-04-21T07:38:12-07:00", "upcomingEvents": [{ "summary": "App Ops Sprint Planning", "minutesUntil": 88 }] }
Código que roda em cerca de 50 milissegundos. Zero ambiguidade. O agente simplesmente não o executou.
Mesmo formato 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 declaraçã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. Mesmo formato. 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 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 de 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 no cérebro
Um recurso 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 depois usa). Mas antes de percorrer os oito passos restantes, quero mostrar como o skillify se parece no uso diário, porque não é apenas uma resposta a falhas. Virou um verbo.
Skillify como 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 se parece. Estou conversando com meu agente em linguagem natural. Construímos algo juntos em conversa. Eu testo. Funciona. Então digo uma palavra:
Garry:
caramba, funcionou. Você pode lembrar disso como uma skill de webhook e aplicar o skillify? Da próxima vez que precisarmos de webhooks, já temos. Por que foi tão difícil acertar isso? De qualquer forma, está bom agora. Faça o DRY também.
Essa foi uma integração de webhook OAuth. Passamos uma hora fazendo funcionar. Depois "skillify it" transformou a sessão ad-hoc em uma skill durável com testes, uma entrada de resolver e documentação. Da próxima vez que eu precisar de um webhook, a skill existe. O agente a lê. O conhecimento conquistado naquela hora é permanente.
Outro exemplo. Descobrimos que nosso contêiner precisa de um navegador headless para certas tarefas e um navegador com interface gráfica no meu desktop para outras:
Garry:
ótimo! Então devemos 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 interface, devemos pedir ao usuário para executar gstack browser e nos dar um código de par de agente. Aplique 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 será roteada automaticamente para a ferramenta certa.
Ou esta. Percebi que o agente ficava 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ê mesmo deve fazer um curl para garantir que o endpoint está aberto e o túnel funciona? Aplique 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 uma reserva dupla às 11h. Crie uma skill, torne-a determinística para verificar esse tipo de coisa.
Uma frase. Código, skill, testes, entrada de resolver, auditoria de alcançabilidade. A lista de verificação de 10 passos em uma única respiração. Meu OpenClaw sabe, faz, e agora é um hábito. Já fiz isso dezenas de vezes. Não consigo viver sem.
O padrão é sempre o mesmo: prototipar em conversa, ver funcionar, dizer "skillify", e o protótipo se torna infraestrutura permanente. Não escrevo especificações. Não abro tickets. Falo 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 estrutura perderam. Não as primitivas de teste. Não as ferramentas de avaliação. O fluxo de trabalho. O momento em que um humano diz "isso funcionou, agora torne 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 de resolver, avaliação de resolver, auditoria DRY, teste de fumaça, arquivamento no cérebro. Dez passos. Uma palavra.
Aqui está como os oito passos restantes se parecem 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 localização. 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 confiantemente a coisa errada.
Para context-now, testes unitários verificam a formatação de fuso horário, detecção de horário de silêncio e o cálculo de minutesUntil em transições 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 nos 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 muito limpos. Dados reais têm linhas de eventos malformadas, campos de fuso horário ausentes, arquivos de calendário com quebras de linha do Windows, eventos que cruzam 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 exigem julgamento para avaliar. "Este resumo de calendário é útil?" não é uma pergunta sim/não que um script pode responder. Então eu uso 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 a 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 tempo sozinho, a avaliação falha.
Outra avaliação dá ao agente um timestamp UTC e pergunta "que horas são 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 "que porra". Esses são os casos de teste que estão faltando.
Passo 6: Gatilho de resolver
Um resolver é uma tabela de roteamento para contexto: quando o tipo de tarefa X aparecer, 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 esse 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 realmente roteia.
Minha suíte de avaliação de resolver tem mais de 50 casos de teste como este:
{ intent: 'verificar minhas assinaturas', expectedSkill: 'executive-assistant' }, { intent: 'quem é Pedro Franceschi', expectedSkill: 'brain-ops' }, { intent: 'salvar este artigo', expectedSkill: 'idea-ingest' }, { intent: 'que horas é minha reunião', expectedSkill: 'context-now' }, { intent: 'encontrar minha viagem de 2016', expectedSkill: '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ã" deve 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 um deles. 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 (dado esse intent, 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 construindo, eu tinha mais de 40 skills. Algumas criadas em resposta a incidentes específicos, outras geradas por subagentes executando crons. Ninguém estava mantendo a tabela de resolver. Skills estavam nascendo, mas não registradas.
Então construí o check-resolvable. Um meta-teste que percorre toda a cadeia: resolver em AGENTS.md → SKILL.md → script/cron. Se um script existe que faz trabalho útil mas não tem caminho a partir do resolver, ele é 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 no escuro.
- 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 skill tem descrições de gatilho sobrepostas que causariam roteamento ambíguo.
A auditoria DRY roda junto. Você acaba com quinze skills que meio que fazem a mesma coisa se não tomar cuidado, e o resolver escolhe aquela em que o dado cair. Para calendar-recall:
Quatro skills no mesmo domínio. Zero sobreposição. Cada uma tem sua pista. 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 pista 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 fui a 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 isso e improvisar. O teste de fumaça pega isso.
Passo 10: Regras de arquivamento no cérebro
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 política vai em cívico/. Peguei 10 de 13 skills de escrita cerebral arquivando no diretório errado porque cada uma tinha 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ê deveria adotá-lo do meu Pacote de Skills GBrain
O padrão skillify não é específico do OpenClaw ou de qualquer harness em particular. Ele está incorporado no GBrain. GBrain é o motor de conhecimento de código aberto que escrevi e que fica abaixo de qualquer harness que você use. 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/Hermes Agent para fazer isso. É assim que habilidades e capacidades que escrevi para meu OpenClaw/Hermes Agent podem ser adicionadas automaticamente ao SEU OpenClaw — incluindo toda a saída do skillify em 10 passos, empacotada para que você possa colocá-la em seu OpenClaw/Hermes Agent e simplesmente funcionar.
A lista de verificação skillify anterior não é uma sugestão. É o que o gbrain doctor realmente verifica.
gbrain doctor --fix repara automaticamente violações de 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 Hermes Agent não é suficiente por si só
Hermes Agent 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 conclui uma tarefa complexa ou se recupera de um erro, ele propõe uma skill e a escreve no disco. Essa é a memória processual que o agente ganha por conta própria. Divulgação progressiva (carregue um índice de skills 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 ocultam automaticamente 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 de resolver para verificar o roteamento. Sem check-resolvable para encontrar skills escuras. Sem auditoria DRY para pegar duplicatas. Sem verificação de saúde diária que fica vermelha quando algo se desvia.
Os modos de falha que vi se acumularem em qualquer sistema de skill não testado:
- Agente cria deploy-k8s na segunda. Na quinta, cria kubernetes-deploy de uma conversa diferente. Ambos existem. Ambos disparam com 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 silenciosamente retorna lixo até que um humano perceba.
- Uma skill criada autonomamente tem um gatilho fraco que nunca corresponde. Torna-se órfã, 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. Hermes lida com a criação lindamente. 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 deveriam 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á novamente. A falha do fuso horário não acontecerá novamente. E quando a próxima falha aparecer (e vai aparecer, porque este é um jogo adversarial contra entropia e gosto), ela também será skillificada.
O agente com quem trabalharei daqui a um ano será moldado por cada erro que cometeu no ano anterior. Isso não é um "bônus". Essa é a tese inteira.
Ferva o oceano. Faça seu agente fazer algo, depois aplique skillify. Você faz isso todos os dias e tem um OpenClaw incrivelmente inteligente que faz tudo o que você quer.
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/Hermes Agent github.com/garrytan/gbrain
