Resumo Técnico: PatchOptic para Fluxos de Trabalho de LLM com Estado Compartilhado

Declaração do Problema

Em fluxos de trabalho agênticos que operam sobre um estado estruturado e compartilhado, existe um descompasso fundamental entre as janelas de contexto limitadas dos Grandes Modelos de Linguagem (LLMs) e os requisitos de validade global do sistema. Para gerenciar o contexto, os sistemas empregam a divulgação progressiva, expondo apenas o fragmento de estado necessário para um passo específico (por exemplo, via RAG ou consultas AST). Embora isso gerencie o lado da leitura, o lado da escrita permanece vulnerável.

Quando um agente propõe uma atualização baseada apenas em um fragmento local, ele carece do contexto global necessário para validar a atualização contra o estado completo. Isso leva a duas famílias primárias de falhas:

1. Vazamento de Segredos (Secret Leakage): Valores protegidos irrelevantes para o passo atual entram na visão do agente e são inadvertidamente divulgados na saída.
2. Falhas de Legalidade de Commit (Commit-Legality Failures): Agentes propõem patches que são malformados, violam restrições de fase, escrevem fora de escopos autorizados ou derivam valores de caminhos de estado não autorizados (fontes ocultas).

Controles existentes, como validadores de esquema ou decodificação restrita, abordam a sintaxe ou estrutura local, mas falham ao verificar a procedência dos valores de estado ou a validade global de uma transição. Há uma carência de um "contrato" que conecte reescritas locais à validade global e se componha através de fluxos de trabalho multi-passo e multi-agente.

Metodologia: Design do PatchOptic

O artigo introduz o PatchOptic, uma interface inspirada em óticas que acopla leituras projetadas com atualizações estruturadas verificadas. O mecanismo central baseia-se em um contrato de passo definido por uma tríade de autoridade $(O_s, W_s, P_s)$:

• $O_s$ (Leitura Projetada): Uma projeção do estado compartilhado total $x$ em uma visão local $O_s(x)$ visível ao ator.
• $W_s$ (Região de Escrita): O conjunto de caminhos de estado que o ator está autorizado a modificar.
• $P_s$ (Região de Fonte do Patch): O conjunto de caminhos do estado atual que o ator está autorizado a ler durante a aplicação do patch (por exemplo, para operações de copy, move ou test em JSON Patch).

Verificação em Tempo de Execução (Runtime Enforcement)

O caminho de execução opera da seguinte forma:

1. Projeção: O ator recebe apenas a visão projetada $O_s(x)$, ocultando campos sensíveis.
2. Proposta: O ator gera uma proposta de mutação (implementada como um JSON Patch).
3. Verificação: Antes do commit, um verificador checa a proposta contra o estado total $x$ usando quatro portões:
   • Escopo: Garante que os alvos de escrita e os caminhos de fonte do patch (incluindo caminhos from para move) permaneçam dentro de $W_s$ e $P_s$.
   • Fase: Valida se o passo é permitido na fase atual do fluxo de trabalho.
   • Esquema: Verifica a validade estrutural e os contratos de saída.
   • Invariantes: Verifica se os invariantes do fluxo de trabalho se mantêm pós-mutação.
4. Commit/Rejeição: O estado só sofre mutação se todos os portões passarem; caso contrário, a proposta é rejeitada e o estado permanece inalterado.

Álgebra de Pegada Estática (Static Footprint Algebra)

Além do tempo de execução, a declaração do passo gera uma pegada estática $(R_s, W_s, P_s)$ (onde $R_s$ é a região de leitura realizada). Isso permite análise estática antes da execução dos atores:

• Restrição: Suporta delegação ao estreitar as pegadas para sub-atores.
• União: Suporta composição de pares ao combinar pegadas.
• Certificado de Comutação: Permite o reordenamento seguro de passos independentes dentro do mesmo passo. Dois passos podem ser reordenados se suas regiões de escrita forem disjuntas e nenhum deles ler o que o outro escreve ($W_A \perp W_B$, $R_A \perp W_B$, $R_B \perp W_A$).

Principais Contribuições

1. Mecanismo de Tempo de Execução: Um sistema que acopla visões projetadas com escritas de JSON Patch verificadas sobre estado compartilhado, produzindo traços estruturados de visões, propostas e decisões do verificador.
2. Álgebra de Pegada: Um formalismo para regiões declaradas de leitura, escrita e fonte de patch que suporta delegação, composição e certificados estáticos para reordenamento de passos independentes.
3. PatchBench: Um benchmark de 46 casos criados manualmente em seis domínios (finanças, marketing, medicina, ciência, software, suporte). Ele avalia o design separando execuções de atores vivos de testes "sem modelo" usando artefatos comprometidos.

Resultados Empíricos

A avaliação foi conduzida usando um ator forte (GPT-5-mini) e um ator mais fraco (Mistral 7B) em seis configurações (Sem Restrições, Apenas Esquema, FSM+ACL, Apenas Visão, Apenas Verificação, PatchOptic).

• Redução de Vazamento: Leituras projetadas reduziram significativamente o vazamento relatado. Sob o GPT-5-mini, configurações de estado total apresentaram uma taxa de vazamento de ~31,5%, enquanto o PatchOptic reduziu isso para 0,2% (a média de execuções com vazamento caiu de ~14,5 para 0,1 por rodada).
• Eficiência de Tokens: Configurações de leitura projetada usaram 11–13% menos tokens por execução em comparação com as configurações de estado total.
• Qualidade de Saída: Sob o ator forte, as leituras projetadas não degradaram a qualidade da saída aceita (o Score de Conteúdo permaneceu em ~0,927). Consequentemente, a taxa de Passagem Semântica (qualidade + sem vazamento) subiu de ~0,61 (Sem Restrições) para 0,78–0,80 (PatchOptic).
• Eficácia da Verificação: A verificação em tempo de execução bloqueou com sucesso violações de contrato declaradas (erros de fase e escopo) antes do commit. No teste de estresse "sem modelo", o PatchOptic e o "Apenas Verificação" rejeitaram 100% dos artefatos comprometidos que tentavam citar caminhos de fonte ocultos, enquanto configurações sem verificações de fonte de patch (ex: FSM+ACL) aceitaram 8/9 desses artefatos.
• Comportamento do Ator Mais Fraco: Para o ator mais fraco, Mistral, o PatchOptic alcançou a maior Taxa de Passagem Semântica (0,690) ao combinar projeção (que evitou vazamentos) com verificação (que bloqueou patches inválidos), compensando a menor qualidade intrínseca do modelo.

Significância e Alegações

O artigo alega que o PatchOptic fornece um "contrato" necessário entre ações locais de modelos e a validade global do sistema. Sua significância reside em:

• Desacoplamento da Observação da Comissão: Ele separa explicitamente o que o ator pode observar (visão projetada) do que o tempo de execução irá cometer (patch verificado), evitando que o modelo precise carregar obrigações de segurança globais.
• Componibilidade: A álgebra de pegada permite a verificação estática de delegação, composição e reordenamento, permitindo a escala segura de fluxos de trabalho multi-agente.
• Defesa em Profundidade: Ao combinar projeção (impedindo que o ator veja segredos) com a aplicação de força de fonte de patch (impedindo que o patch leia segredos mesmo se o ator estiver comprometido ou o artefato for injetado), o sistema aborda tanto riscos de injeção de prompt quanto riscos de artefatos comprometidos.

Os autores reconhecem limitações, observando que o sistema confia no autor da política (se o contrato estiver errado, o sistema aplicará o contrato errado) e não impede erros semânticos ou divulgações autorizadas pela política. No entanto, eles postulam que o PatchOptic estabelece uma camada de controle fundamental para a implantação segura de agentes de LLM em grandes sistemas de estado compartilhado.