Injeção de Falha no Agente Harness

Visão Geral

Use um cronograma de falhas determinístico e não de produção para testar se um fluxo de trabalho do agente preserva estado, orçamentos, limites de segurança e evidências quando uma dependência falha. A saída é uma pequena matriz de falhas, uma linha do tempo de eventos e um veredito que distingue execuções recuperadas, contidas, irrecuperáveis e inconclusivas.

Quando Usar Esta Habilidade

• Use quando um agente de várias etapas, máquina de estados, loop ou fluxo de trabalho de vários agentes tiver um novo caminho de recuperação.
• Use quando a execução em sandbox, uma chamada de MCP/ferramenta, um worker, um armazenamento de checkpoint ou a memória puderem expirar ou desaparecer.
• Use antes de afirmar que o comportamento de retentativa, retomada, prazo, isolamento ou falha parcial está pronto para produção.
• Use quando uma regressão precisar de evidências de falha reproduzíveis em vez de uma execução caótica aleatória.

Não use esta habilidade contra um alvo de produção, dados de usuário reais, credenciais ativas ou um serviço externo ilimitado. Converta esses casos para um simulador local ou um harness de staging autorizado primeiro.

Pré-condições de Segurança e Limites

1. Congele a revisão do fluxo de trabalho, a configuração do modelo/prompt, os esquemas de ferramentas, a semente, o fixture de entrada, o tempo limite, o orçamento de retentativa, o prazo e os estados terminais esperados.
2. Execute em um sandbox descartável com entradas sintéticas e ferramentas stubadas. Mantenha a rede desabilitada, a menos que o teste precise explicitamente de um servidor de teste local.
3. Faça de cada falha injetada um evento em memória ou controlado por fixture. Nunca exclua dados reais, revogue credenciais reais, mate um processo não relacionado ou mutile um serviço ativo para criar uma falha.
4. Registre o escopo do teste e um identificador de execução antes de começar. Um escopo, fixture ou contrato de recuperação ausente torna o veredito inconclusive.

Contrato de Recuperação

Escreva o invariante antes de injetar uma falha. Um contrato útil nomeia o estado que deve sobreviver e os efeitos colaterais que não devem se repetir:

After recovery, resume from the latest durable checkpoint, preserve the task
identity and safety policy, spend no more than the remaining retry/deadline
budget, and commit each externally visible effect at most once.

Modele o fluxo de trabalho com estados explícitos. Por exemplo:

created -> running -> checkpointed -> waiting_for_tool
                       |                |
                       v                v
                    failed <--------- recovering -> resumed -> completed

Para cada transição, defina o proprietário, os campos duráveis, a contagem de retentativas permitida e o comportamento terminal. Valores em memória não são checkpoints, a menos que o harness prove que eles sobrevivem à reinicialização simulada.

Matriz de Falhas

Selecione o menor conjunto de falhas que cobre a nova lógica de recuperação. Não randomize o cronograma até que um cronograma determinístico tenha passado.

Cronograma de Injeção Determinístico

Use números de evento em vez de aleatoriedade de relógio. Um cronograma deve ser portátil entre harnesses:

{
  "seed": "harness-fixture-07",
  "faults": [
    {"event": "tool.call", "ordinal": 2, "kind": "timeout", "tool": "search"},
    {"event": "worker.start", "ordinal": 2, "kind": "restart"},
    {"event": "branch.join", "ordinal": 1, "kind": "partial_failure", "branch": "summarize"}
  ]
}

O harness deve emitir o cronograma, não apenas a semente. Mantenha a identidade da falha separada do erro observado para que um wrapper não possa acidentalmente transformar um tempo limite em uma falha genérica. Execute o mesmo cronograma duas vezes e compare a linha do tempo normalizada antes de tentar um cronograma diferente.

Regras de Recuperação por Limite

Falhas de Sandbox e MCP/ferramenta

…