O ProofKit captura falsos sucessos em AI agents ao exigir evidências em tempo real antes que qualquer tarefa seja marcada como concluída.
Instalar e Baixar
1. ClawHub CLI
A maneira mais rápida de instalar uma habilidade diretamente do registro.
npx clawhub@latest install proofkit
2. Instalação Manual
Copie a pasta da habilidade para um desses locais
~/.openclaw/skills/ <project>/skills/ Prioridade: Espaço de Trabalho > Local > Integrado
3. Instalação do Prompt
Copie este prompt para o OpenClaw para instalá-lo automaticamente.
Ajude-me a instalar o proofkit usando o Clawhub. Se o Clawhub não estiver instalado, instale-o primeiro (npm i -g clawhub).
Prefere baixar?
Obtenha os arquivos originais da habilidade em um arquivo ZIP.
O que é ProofKit?
O ProofKit é a camada de verificação adversarial para agents autônomos: ele trata cada alegação de sucesso como não confiável até que um artefato em tempo real prove que o trabalho realmente aconteceu. Ele combina um scanner estático de falsos sucessos com um fluxo de trabalho de verificação real que busca por efeitos colaterais concretos, como um message_id não nulo, um arquivo recém-criado, um HTTP 200 real ou uma linha de banco de dados alterada.
No Openclaw Skills, o ProofKit ajuda você a interromper encenações de dry-run, códigos stub, erros silenciados e métricas fabricadas antes que cheguem ao CI ou à produção. O resultado é uma mudança prática: em vez de confiar em logs e valores de retorno, passa-se a entregar apenas resultados apoiados por evidências.
Casos de uso do ProofKit
- Agents autônomos de postagem, negociação ou divulgação onde você deve provar que a postagem, pedido ou e-mail realmente aconteceu
- Frotas multi-agent onde o falso sucesso de um agent corromperia as entradas subsequentes
- CI para código gerado por AI para bloquear a mesclagem de stubs, dados de demonstração e resultados fabricados
- Qualquer situação em que um agent diz que funcionou e você não pode se dar ao luxo de confiar cegamente nessa alegação
Como o ProofKit funciona
- Execute o scanner estático de falsos sucessos contra um ou mais arquivos Python com
python3 proofkit\/verify_real_scan.py <file> [<file> ...]. - Deixe o scanner sinalizar padrões suspeitos, como retornos de sucesso codificados de forma fixa,
message_id: 0, simuladores baseados emrandom, corpospassvazios, exceções silenciadas e padrões de dry-run. - Vá para a etapa de verificação real: exija um artefato real que comprove a execução, como números stdout reais, um arquivo que agora existe com bytes, um HTTP 200 ou uma linha de banco de dados alterada.
- Adicione um tripwire (fio de tropeço) para que a etapa subsequente não possa ser executada se o artefato estiver ausente, o que transforma aprovações falsas em falhas graves em vez de entregas silenciosas.
- Use o veredicto para classificar a execução como
VERIFIED LIVE,BUILT-BUT-UNVERIFIEDouFAKE-BROKENe, opcionalmente, escale a mesma lógica com\/redteam,gatecheck, hooks de CI ou modo Fleet.
Configuração do ProofKit
- Certifique-se de que o Python 3 está disponível.
python3 --version
- Copie
verify_real_scan.pypara o seu projeto. Para o Openclaw Skills, o nível gratuito é apenas o scanner e o método.
mkdir -p tools
cp verify_real_scan.py tools\/
- Execute a varredura em qualquer arquivo de agent ou auxiliar que você queira validar.
python3 tools\/verify_real_scan.py path\/to\/agent.py path\/to\/helper.py
- Conecte o mesmo comando ao CI ou a um wrapper de lançamento para que as mesclagens falhem quando padrões de falso sucesso aparecerem ou quando o artefato em tempo real estiver ausente.
python3 tools\/verify_real_scan.py "$TARGET_FILE"
- Se você precisar do pacote de aplicação de políticas, instale a skill completa do ClawHub e mantenha um modelo local disponível para as passagens adversariais. O conjunto de ferramentas usa Python stdlib puro mais o seu modelo local existente.
Esquema de Dados e Taxonomia de ProofKit
Modelo de entrada e saída
| Objeto | Formato | Origem | Finalidade |
|---|---|---|---|
| Alvos de varredura | Um ou mais arquivos Python passados na CLI | Entrada do usuário | Código a ser inspecionado |
| Descobertas estáticas | Relatório stdout e avisos | verify_real_scan.py |
Indicadores de falso sucesso |
| Artefatos em tempo real | Números, arquivos, respostas HTTP, deltas de banco de dados | Verificações em tempo de execução | Prova de que a tarefa realmente foi executada |
| Veredictos | VERIFIED LIVE, BUILT-BUT-UNVERIFIED, FAKE-BROKEN |
Fluxo de trabalho de verificação real | Status final |
| Resultados de aplicação | Tabelas PASS/DRIFT, resultados de refutação por maioria, falhas no CI | Pacote premium | Controle de políticas |
Taxonomia de descobertas
- Sucesso codificado de forma fixa (hardcoded):
return True,success=True,message_id: 0 - Métricas fabricadas:
random.*usado para substituir uma medição real - Código incompleto:
TODO,NotImplementedErrorou corpospassvazios - Contaminação de produção: dados de demonstração, amostra ou fixture em caminhos de produção
- Silenciamento de erros:
except: passseguido por um relatório de sucesso - Encenação de dry-run: padrões que alegam trabalho real sem executá-lo de fato
Princípios de dados
- Précisão em primeiro lugar, com correspondência de limite de palavra para que nomes não relacionados como
exist_ok=Truenão acionem o scanner. - Evidência em primeiro lugar, porque uma varredura estática limpa é necessária, mas não suficiente.
- Banco de dados persistente não é necessário; o fluxo de trabalho consiste em entrada de arquivo, prova de artefato e veredictos legíveis por humanos.
Recursos avançados do ProofKit
\/redteamexecuta N céticos independentes por alegação, pede a cada um para refutar e encerra o processo por maioria, de modo que a primeira aprovação otimista não vença por padrãogatecheckgera mais de 6 provas invariantes de proteção, como acessibilidade do kill-switch, transações bloqueadas, integridade da defesa contra injeção e portas de qualidade fail-closed, apresentadas em uma tabela PASS/DRIFT- A geração de tripwire envolve uma etapa de build para que uma aprovação falsa não possa continuar a menos que o artefato real exista
- O suporte a hooks de CI falha o pipeline em qualquer sinalizador de falso sucesso ou artefato ausente, tornando a prova de trabalho obrigatória para a mesclagem
- O modo Fleet escala o pacote em N agents e classifica quais agents têm maior probabilidade de entregar falsos sucessos
- O pacote pode seguir os dados uma camada abaixo para expor wrappers onde a API real está oculta atrás de uma interface falsa
SKILL.md
Carregamento
Habilidades relacionadas do Openclaw
Aomi Build
O Aomi Build transforma especificações OpenAPI, docs de SDK e referências de API em crates Rust Aomi prontas para produção com ferramentas tipadas e chamáveis por agentes para fluxos de trabalho Openclaw Skills.
Aomi Transact
Aomi Transact transforma prompts de cripto e DeFi em inglês simples em transações on-chain simuladas em fork e assinadas por carteira a partir do terminal.
CI Pipeline Debugger
O CI Pipeline Debugger oferece aos usuários do Openclaw Skills uma maneira rápida de analisar logs de CI/CD, isolar etapas com falha e transformar erros de pipeline em correções acionáveis.
Merged Social and Poster Generator Skill
Uma skill de automação que mescla os sistemas de design visual do guizang-social-card e do magazine-poster em um gerador unificado de ativos de design programático.
AgentPMT Audit Logs
O AgentPMT Audit Logs oferece visibilidade somente leitura sobre chats de agentes, chamadas de ferramentas, execuções de fluxo de trabalho e agendamentos, permitindo auditar o que aconteceu e por quê.
Terraform Drift Detector
O Openclaw Skills para Terraform Drift Detector compara o estado do Terraform com a infraestrutura em nuvem ativa em tempo real e sinaliza desvios (drift) com relatórios acionáveis.
Apresentou*
