💻 computer science

ATM: CID-Brokered Pre-Write Admission for Multi-Agent Code Co-Synthesis

Este artigo apresenta o AI-Atomic-Framework (ATM), um sistema de governança mediado por CID que garante uma co-síntese de código multiagente segura, auditável e recuperável ao mediar a admissão de escrita por meio de atomização semântica e gestão neutra antes de aplicar mutações compartilhadas.

Autores originais: Eagl Huang

Publicado 2026-07-02

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Eagl Huang

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine um canteiro de obras de alta tecnologia e movimentado, onde dezenas de construtores robóticos (agentes de IA) trabalham juntos para construir um único e massivo arranha-céu (um projeto de software).

No passado, se dois robôs tentassem pintar a mesma parede ou instalar uma janela no mesmo lugar ao mesmo tempo, eles colidiriam uns com os outros, sobrescreveriam o trabalho um do outro ou deixariam um edifício bagunçado e quebrado. Eles só perceberiam o erro depois que a tinta secasse ou a janela fosse estilhaçada.

Este artigo apresenta o ATM (AI-Atomic-Framework), um novo "Sistema de Controle de Tráfego" para esses construtores robóticos. Ele não diz aos robôs o que construir ou como construir. Em vez disso, ele atua como um porteiro rigoroso que decide quem tem permissão para tocar em cada parte do edifício antes que qualquer trabalho físico come a ser feito.

Aqui está como funciona, dividido em conceitos simples:

1. O Problema: O Cenário de "Muitos Cozinheiros"

Quando múltiplos agentes de IA tentam editar os mesmos arquivos de computador, eles frequentemente não sabem o que os outros estão fazendo.

O Jeito Antigo: O Agente A começa a escrever código em um arquivo. O Agente B começa a escrever no mesmo arquivo. Ambos salvam seu trabalho. O resultado é uma bagunça de códigos conflitantes (um "conflito de merge") que os humanos precisam corrigir mais tarde.
O Jeito ATM: Antes de o Agente A ou o Agente B tocar no arquivo, eles devem levantar a mão e perguntar ao Corretor CID (o Guarda de Trânsito).

2. O Guarda de Trânsito: O Corretor CID

O Corretor CID é o tomador de decisão central. Ele não adivinha; ele verifica um livro de regras rigoroso.

O Cartão de Identidade (CID): Cada pedaço de código ou dado possui um cartão de identidade exclusivo.
O Mapa (Mapa de Átomos): O sistema possui um mapa que divide o edifício em pequenos cômodos gerenciáveis chamados "Átomos". Um átomo pode ser uma única função, uma configuração específica ou uma linha de texto.
A Decisão: Quando dois agentes querem trabalhar, o Corretor verifica seus mapas:
- Luz Verde (Paralelismo Seguro): "Você está pintando a cozinha e você está pintando a garagem. Vocês podem trabalhar ao mesmo tempo!"
- Luz Amarela (Serial): "Vocês dois querem consertar a porta da frente, mas de formas diferentes. Um de vocês deve esperar até que o outro termine."
- Luz Vermelha (Falha Fechada): "Vocês estão tentando mudar o mesmo parafuso no mesmo motor, e não conseguimos descobrir como combinar suas ideias com segurança. Pare imediatamente. Não toque no motor."

3. O Truque do "Átomo Virtual"

Às vezes, o mapa não é perfeito. O Corretor pode ver dois agentes trabalhando em um arquivo, mas ainda não consegue ver exatamente em qual minúsculo "cômodo" (átomo) eles estão.

A Metáfora: Imagine que os agentes estão trabalhando em uma sala escura. O Corretor não consegue ver os móveis claramente.
A Solução: O Corretor cria um "Átomo Virtual". É como colocar uma caixa temporária e brilhante ao redor da área bagunçada apenas para dizer: "Ok, sabemos que este ponto específico está sendo trabalado. Vamos tratar esta caixa como uma única unidade até que possamos ver os detalhes." Isso evita que os agentes pisem na bola uns dos outros enquanto o sistema descobre os detalhes.

4. O Mordomo Neutro

Este é uma regra de segurança crucial no artigo.

A Regra: Os agentes de IA (os construtores) nunca têm permissão para salvar suas próprias alterações diretamente no edifício compartilhado.
O Processo: O agente propõe uma mudança -> O Corretor aprova a mudança -> Um Mordomo Neutro (um robô separado e imparcial) realmente aplica a mudança.
Por quê? Isso garante que, mesmo que um agente fique confuso ou tente trapacear, ele não possa quebrar o edifício. O Mordomo faz uma dupla checagem para garantir que o edifício não tenha mudado desde que o Corretor deu a permissão (como verificar se a porta não foi trancada por outra pessoa nesse meio tempo).

5. O Que o ATM Afirma Fazer (e o Que Não Faz)

O artigo é muito específico sobre seus limites. Não é uma varinha mágica que resolve todos os problemas do universo.

✅ Ele FAZ:
- Impede que os agentes colidam uns com os outros antes de fazerem uma bagunça.
- Permite o trabalho paralelo seguro quando os agentes estão trabalhando em partes diferentes do mesmo arquivo.
- Cria um rastro claro e auditável de quem tentou fazer o quê e por que isso foi permitido ou bloqueado.
- Funciona dentro de um único "domínio" (como um servidor de computador específico ou uma pasta de projeto específica).
❌ Ele NÃO FAZ:
- Corrigir conflitos que acontecem entre dois computadores completamente diferentes ou ramos (branches) diferentes de um projeto (isso ainda é tarefa de ferramentas padrão como o Git).
- Garantir que o código seja correto (ele pode impedir que dois agentes briguem, mas não pode impedir um agente de escrever um código ruim que compila, mas não funciona).
- Substituir a necessidade de revisão humana ou testes.

Resumo da Analogia

Pense no ATM como um sistema de semáforo em um cruzamento movimentado.

Os Agentes são os carros.
O Código é a estrada.
O Corretor é o semáforo.
O Mordomo é a equipe de construção que realmente move as barreiras da estrada.

O semáforo não dirige os carros, nem conserta a estrada. Ele apenas garante que dois carros não tentem passar pelo mesmo cruzamento ao mesmo tempo, evitando um acidente antes que ele ocorra. Se a luz estiver vermelha, o carro espera. Se a luz estiver verde, o carro passa, mas um membro neutro da equipe ainda coloca a barreira final para garantir que a estrada esteja segura.

O artigo prova que este sistema funciona para cenários específicos e controlados, mantendo o canteiro de obras ordenado sem precisar que um humano grite "Pare!" toda vez que dois robôs chegam perto um do outro.

Resumo Técnico: ATM – Admissão de Pré-Escrita Mediada por CID para Co-Síntese de Código Multi-Agente

1. Declaração do Problema

O artigo aborda uma lacuna específica em sistemas de modelos de linguagem de grande escala (LLM) multi-agente: a falta de um mecanismo de governança para adjudicar intenções de escrita dentro de um único sistema de arquivos controlado, worktree ou domínio de serviço antes que qualquer mutação compartilhada seja aplicada.

Embora benchmarks existentes (ex: RepoBench, Commit0) demonstrem que agentes podem gerar código em múltiplos arquivos, e sistemas como CodeTeam ou CoAgent gerenciem planejamento e concorrência ao nível de ferramentas, um gargalo crítico permanece. Quando múltiplos agentes formam intenções de escrita visando os mesmos recursos compartilhados (ex: o mesmo arquivo, registro ou artefato), o sistema deve determinar, antes da execução, quais intenções podem prosseguir em paralelo, quais exigem composição determinística ou serialização, e quais devem ser bloqueadas. Sem essa camada de admissão de pré-escrita, os agentes correm o risco de condições de corrida (race conditions), sobrescritas silenciosas e conflitos de mesclagem (merge conflicts) ingovernáveis downstream em fluxos de trabalho de Git ou Pull Request.

O artigo distingue explicitamente seu escopo de:

CRDTs de nível de caractere: Que lidam com a convergência de texto, mas deixam conflitos semânticos residuais.
Cross-clone/Git Merge: Que operam após as mudanças terem sido aplicadas.
Grafos Semânticos Globais: Que exigem a elevação de todos os artefatos para um AST universal antes da governança.

O ATM foca na fronteira de admissão de pré-escrita de domínio único, concentrando-se em decisões auditáveis feitas antes da mutação de estado compartilhado governada.

2. Metodologia: O Framework ATM

O ATM (AI-Atomic-Framework) é um substrato de governança baseado em especificações que vincula a intenção da tarefa, o escopo do repositório, a admissão de escrita, a validação e as obrigações de evidência em uma única cadeia de governança. Sua arquitetura central consiste em três planos e um fluxo de admissão mediado.

2.1 Substrato de Governança de Três Planos

O framework opera em três planos distintos definidos por um Contrato de Tarefa ( $\mathcal{T} = \langle g, A, F, S, D, V, E, \epsilon \rangle$ ):

Plano de Contrato de Tarefa: Define o que um agente está autorizado a fazer (arquivos permitidos, regras proibidas, caminhos de escopo, entregáveis e obrigações de evidência). Ele impõe Contenção de Escopo (G1) e Estabilidade de Direção (G2).
Plano de Admissão de Mutação: O mecanismo central onde o Mediador de CID avalia se uma mutação compartilhada governada pode ocorrer. Ele utiliza átomos, Identificadores de Conteúdo (CIDs), Chaves de Conflito (ConflictKeys) e conjuntos de leitura/escrita para tomar decisões de admissão determinísticas.
Plano de Fechamento de Evidência: Garante que uma tarefa só seja marcada como concluída se os validadores passarem, os entregáveis forem satisfeitos e todas as escritas percorrerem o caminho de governança (G3).

2.2 Mecanismos Centrais

Atomização Guiada por Adaptadores: Em vez de exigir um AST universal, o ATM usa Adaptadores específicos de linguagem (ex: para TypeScript, Python, JSON) para declarar "átomos" (as menores unidades governáveis, como funções, classes ou chaves JSON).
O Mapa de Átomos: Um índice semântico conectando átomos a proprietários, validadores, dependências e superfícies compartilhadas.
Átomos Virtuais: Quando o mapa de átomos persistente é incompleto ou muito grosseiro, o mediador materializa Átomos Virtuais (unidades de transição baseadas em encerramentos sintáticos ou intervalos de linhas) para permitir comparação de região delimitada e contenção de falha fechada (fail-closed).
Mediador de CID & Steward Neutro:
- O Mediador (Broker) é o único nó de serialização. Ele recebe intenções de escrita estruturadas, mapeia-as para átomos/átomos virtuais e emite vereditos (Seguro para Paralelismo, Necessita de divisão física, SERIAL ou Bloqueado).
- O Steward Neutro é a única entidade autorizada a aplicar planos admitidos ao worktree compartilhado. Ele realiza uma verificação de Compare-And-Swap (CAS) de hash de base antes de aplicar as mudanças para evitar deriva (drift).

2.3 Portão de Admissão de Sete Camadas

O mediador avalia as intenções através de um portão progressivo de sete camadas para estreitar a superfície de conflito:

Identidade de CID: Verifica se as intenções visam o mesmo átomo ou candidato a CID.
Superfície Compartilhada: Verifica sobreposição em registros, geradores ou superfícies de intenção ativa.
Dependências de Leitura/Escrita: Detecta perigos de leitura-após-escrita ou escrita-após-leitura.
Intervalo de Arquivo / Átomo Virtual: Determina se as mudanças no mesmo arquivo são disjuntas via átomos conhecidos ou refinamento de átomo virtual.
Chave de Conflito + canMerge: Avalia chaves de artefato estruturadas e capacidades de mesclagem.
CAS Base-Hash: Verifica se o estado alvo mudou desde a admissão.
Trava de Arquivo de Contingência (Fallback): Uma trava de arquivo inteiro conservadora se a evidência for insuficiente.

Se uma intenção falha em um portão, ela é direcionada para um caminho de falha fechada (preservando a intenção, mas bloqueando a aplicação direta), uma fila SERIAL ou um caminho de composição determinística.

3. Principais Contribuições

O artigo apresenta três contribuições primárias, enquadradas como um reestruturamento do problema, em vez de um orquestrador de propósito geral:

Admissão de Pré-Escrita de Sete Camadas com Fallback de Átomo Virtual: Um portão de admissão rígido que avalia intenções multi-agente através de identidade de CID, superfícies compartilhadas, dependências e refinamento de átomo virtual. Ele transforma a contenção grosseira de nível de arquivo em decisões de admissão auditáveis sem assumir um mapa de átomos completo desde o início.
Substrato de Governança de Especificação-para-Evidência: Um vínculo formal de intenção de tarefa, escopo e obrigações de evidência em um contrato estruturado. Isso evita que o desvio de especificação, o desvio de escopo e o desvio de estado se tornem mutações não governadas.
Abstração de Atomização Extensível: Uma interface que permite que diferentes linguagens/formatos exponham átomos candidatos e chaves de conflito via adaptadores sem exigir tradução para um AST universal.

4. Resultados e Avaliação

O artigo apresenta uma pilha de evidências em camadas, em vez de um único benchmark comparativo contra todos os sistemas existentes.

Fixtures Determinísticas: Uma matriz de design de 12 cenários valida a superfície de decisão. Três cenários principais (B-02, B-08, B-13) foram executados com executores determinísticos e arquivados.
Evidência de Campo (Fronteiras de Mesmo Arquivo):
- POS2: Um caso positivo onde o refinamento permitiu a admissão para uma edição no mesmo arquivo.
- B-12 & BLOCK: Casos que demonstram modos de falha onde o mediador corretamente bloqueou ou serializou intenções devido a evidências insuficientes ou sobreposição não resolvida.
Estudo de Adoção (npc-brain): Um estudo externo de três semanas (maio–junho de 2026) envolvendo 15 agentes em 37 cartões de tarefa.
- Resultado: 0 erros de admissão não recuperados. O sistema canalizou com sucesso a contenção e as falhas de validador para caminhos recuperáveis.
- Carga de Trabalho: 320 commits governados no projeto host 3KLife durante o estudo.
Forense de Auto-Hospedagem: O framework governou seu próprio desenvolvimento (aproximadamente 1.372 commits), expondo lacunas na cobertura de atomização (pontuação de 95/100) e validando os mecanismos de recuperação.
AdmissionBench: Um perfil de benchmark (v0.2) cobrindo 20 cenários únicos e 42 comparações de nível de modo, congelando o substrato para garantir reprodutibilidade.

Limitações Reconhecidas:

O ATM não substitui o merge do Git nem aborda a governança cross-clone/cross-PR.
Não garante identidade semântica entre linguagens (ex: cliente TypeScript vs. backend Python).
Não fornece consenso distribuído ou garantias de vivacidade (starvation é possível).
Não é um orquestrador multi-agente de propósito geral, mas sim uma camada específica de admissão de pré-escrita.

5. Significância e Alegações

O artigo alega viabilidade dentro de cenários observados de domínio único para uma camada de admissão de pré-escrita implementável, auditável e incrementalmente extensível.

Sua significância reside em deslocar o ponto de governança para mais cedo no fluxo de trabalho. Ao lidar com intenções de escrita paralelas dentro do mesmo worktree controlado antes que as mudanças entrem no Git ou na integração de PR subsequentes, o ATM visa reduzir a "pressão de conflito de mesclagem" documentada em sistemas como AgenticFlict. Ele não pretende eliminar todos os conflitos semânticos ou substituir o controle de versão existente; em vez disso, fornece um portão determinístico que converte intenções de escrita subespecificadas em evidência de admissão estruturada e auditável, garantindo que as mutações compartilhadas sejam aplicadas apenas quando satisfizerem as restrições de governança declaradas.