Um Esquema de Evidência Versionado para Habilidades de Agentes: Proveniência, Permissões, Ajuste de Tarefa e Status de Teste

Divulgação de assistência de IA: Eu usei IA para ajudar a redigir e editar este artigo. Verifiquei as alegações técnicas e continuo responsável pelo texto final. Também mantenho o repositório de código aberto descrito aqui, portanto, esta não é uma revisão independente.

As capacidades dos agentes estão se tornando mais fáceis de empacotar e descobrir. Mas catalogar uma Habilidade, servidor MCP ou plugin não é o mesmo que provar que funciona para uma tarefa específica.

Eu tenho explorado um pequeno projeto de código aberto chamado Agent Catalog Seed. Seu propósito não é criar mais um ranking de popularidade. O experimento é tornar as evidências ausentes explícitas e versionadas.

A máquina de estados importa

Para uma capacidade de agente, esses estados são diferentes:

catalogado
  -> verificado estaticamente
  -> instalação observada
  -> execução observada
  -> aceitação da tarefa registrada

Cada seta requer novas evidências. Um parser aceitando SKILL.md não prova que um host pode instalá-lo. Uma chamada de ferramenta retornando 200 OK não prova que a tarefa comercial está correta. Uma execução bem-sucedida em um host não prova compatibilidade em outro.

O catálogo deve, portanto, armazenar tipos de evidência em vez de achatá-los em uma única pontuação.

Um registro versionado mínimo

O seed atualmente usa um esquema JSON estrito. O exemplo abaixo é simplificado, mas mostra a separação de preocupações:

{
  "schema_version": "0.1.0",
  "id": "urn:agent-catalog-seed:entry:release-note-checklist-demo",
  "kind": "skill",
  "installable": false,
  "provenance": {
    "origin": "ai-assisted-original",
    "synthetic": true,
    "description": "Exemplo de catálogo sintético; não é um pacote de terceiros"
  },
  "requested_permissions": {
    "filesystem_read": [],
    "filesystem_write": [],
    "network": false,
    "network_destinations": [],
    "data_destinations": []
  },
  "compatibility": [{
    "host": "unverified-host",
    "status": "unknown",
    "evidence": []
  }],
  "evaluation": {
    "status": "not_evaluated",
    "independent_review": false,
    "evidence": []
  },
  "conflicts": {
    "maintainer_is_author": true,
    "disclosure": "Exemplo sintético de autoria do mantenedor"
  }
}

O seed atual deliberadamente torna as entradas não instaláveis e não avaliadas. É mais seguro publicar um unknown honesto do que converter um roteiro ou alegação de autor em um resultado.

1. Proveniência antes da recomendação

Um registro útil deve identificar:

• URL de origem e mantenedor;
• lançamento, revisão ou digest de conteúdo;
• artefatos realmente inspecionados ou testados;
• licença e base de redistribuição;
• relação entre avaliador e autor.

A identidade da versão é essencial. Quando uma dependência muda, precisamos saber quais evidências ainda são aplicáveis.

2. Permissões solicitadas não são permissões aplicadas

O catálogo pode registrar requisitos de sistema de arquivos, rede, execução de comandos, credenciais e destinos de dados. Mas não deve fingir que os metadados aplicam um sandbox.

O host, usuário, provedor de identidade e serviço remoto ainda controlam a autorização. A documentação estática pode estar errada ou incompleta. A observação em tempo de execução pode revelar comportamentos, mas continua restrita ao ambiente testado.

É por isso que "segurança" não deve ser um único campo Booleano. No mínimo, separe proveniência e integridade, permissões solicitadas e concedidas, descobertas estáticas, observações em tempo de execução e riscos não resolvidos.

3. A evidência da tarefa precisa de um contrato de aceitação

Antes de testar, defina o cenário e os critérios de aceitação. Em seguida, registre:

• host, modelo, adaptador, dependência e versões de configuração;
• limite de entrada e se os dados são sintéticos ou autorizados;
• tentativas planejadas, reintentos, intervenções humanas e timeouts;
• cada passagem, falha, interrupção e resultado indeterminado;
• base de tempo e custo;
• quem aceitou a saída.

Não remova uma execução falha porque um reintento foi bem-sucedido.