Evidência de Execução do Agente de Auditoria

Visão Geral

Transforme uma declaração de sucesso de ponta a ponta em alegações que podem ser decididas independentemente. Reconstrua o que aconteceu a partir dos registros disponíveis, classifique cada alegação em relação à testemunha mais forte e mantenha as evidências ausentes distintas da falha.

Esta é uma auditoria somente leitura. Não reexecute ferramentas, aprove ações, retome workers, implante artefatos ou modifique evidências, a menos que o usuário autorize separadamente essas ações.

Quando Usar

• Auditoria de uma execução de agente concluída ou interrompida a partir de traces e artefatos.
• Verificação se a declaração de sucesso de ponta a ponta de um agente é realmente suportada.
• Revisão de evidências de MCP, gateway, sandbox, checkpoint, retry, memória, aprovação ou implantação.
• Separação de sucesso autônomo de resultados assistidos por humanos ou meramente solicitados.

Não use esta habilidade para projetar instrumentação para uma execução futura ou para executar as ações ausentes. Ela avalia evidências que já existem.

Estabelecer o Contrato

Registre estas entradas antes de julgar a execução:

• objetivo declarado e critérios de sucesso terminal;
• identificadores de execução, fluxo de trabalho, tarefa e pai;
• revisões imutáveis de código, configuração, modelo, prompt, esquema de ferramenta e artefato, quando disponíveis;
• atores e limites de confiança: orquestrador, worker, sandbox, servidor MCP, gateway, aprovador humano, CI e plataforma de implantação;
• orçamentos de retry, prazo, token, custo, concorrência e escalonamento humano;
• inventário de evidências fornecido e lacunas de coleta conhecidas.

Não fortaleça silenciosamente os critérios de sucesso originais. Não os enfraqueça para corresponder às evidências que por acaso existem.

Construir um Livro de Alegações

Divida a alegação geral em predicados atômicos. Dê a cada linha um ID de alegação estável.

Predicados típicos incluem:

• cada etapa necessária atingiu sua pós-condição terminal;
• o isolamento do sandbox foi mantido para cada worker em execução;
• cada chamada MCP/ferramenta necessária tem uma resposta correlacionada;
• retries respeitaram a idempotência e não duplicaram efeitos confirmados;
• um checkpoint foi gravado de forma durável, verificado e realmente usado para retomada;
• ramos paralelos satisfizeram a política de junção declarada;
• leituras de memória citam uma fonte versionada em vez de um resumo não rastreado;
• orçamentos de retry, prazo, token, custo e escalonamento foram respeitados;
• a aprovação foi concedida por um humano autorizado para o artefato e alvo exatos;
• a plataforma implantou esse mesmo artefato e passou nas verificações de integridade declaradas.

Normalizar Evidências

Preserve os registros originais e crie uma visualização de eventos normalizada com:

{
  "run_id": "run-123",
  "event_id": "evt-42",
  "sequence": 42,
  "observed_at": "RFC3339 timestamp",
  "actor": {"type": "worker", "id": "worker-2"},
  "operation": "mcp.search",
  "state_before": "researching",
  "state_after": "researching",
  "attempt": 2,
  "request_id": "req-9",
  "idempotency_key": "task-7:search:2",
  "input_digest": "sha256:...",
  "output_digest": "sha256:...",
  "checkpoint_seq": 3,
  "parent_event_id": "evt-41",
  "status": "succeeded",
  "evidence_ref": "tool-log:991"
}

Use null ou unknown para valores ausentes. Nunca sintetize IDs, timestamps, digests, custos, aprovações ou resultados.

Verifique hashes de bundle ou assinaturas quando fornecidos. Verifique IDs duplicados, links pai quebrados, sequências por fonte não monotônicas, transições de estado impossíveis, descompasso de relógio não contabilizado e lacunas de trace inexplicadas. Trate uma falha de integridade como contraevidência para alegações que dependem dos registros afetados.

Classificar Testemunhas

Prefira a testemunha mais próxima do efeito:

…