Phase 16 - Lesson 13

Memória Compartilhada e Padrões de Quadro Negro

This lesson includes a graded coding exercise that runs in your browser, unlocked with lifetime access.

Duas abordagens coexistem nos sistemas multiagentes de 2026: o pool de mensagens (todos veem as mensagens de todos, como no AutoGen GroupChat ou MetaGPT) e o quadro negro com assinatura (agentes se inscrevem em eventos relevantes, como no Context-Aware MCP ou no framework Matrix). Ambos representam a única parte com estado (stateful) de um sistema multiagente — o que significa que é onde vivem os bugs mais interessantes. O modo de falha de referência é o envenenamento de memória: um agente alucina um "fato", outros agentes o tratam como verificado e a precisão cai gradualmente de uma forma que é muito mais difícil de depurar do que uma falha imediata. Esta lição constrói ambas as estruturas usando a biblioteca padrão (stdlib), injeta um ataque de envenenamento e mostra as três mitigações que realmente funcionam em produção.

Tipo: Aprenda + Construa Linguagens: Python (stdlib, threading) Pré-requisitos: Phase 16 · 04 (Primitive Model), Phase 16 · 09 (Parallel Swarm Networks) Tempo: ~75 minutos

Problema

Sistemas multiagentes precisam de um local para compartilhar fatos. Uma opção literal é "passar tudo em mensagens" — mas isso reinventa o estado compartilhado com cópias extras desnecessárias. Outra opção é "fornecer a todos um log global" — mas logs globais crescem sem limites e são facilmente envenenados. Uma terceira opção é "projetar uma visualização por agente" — escalável, mas exige esquemas rígidos.

Quando um dos agentes alucina e grava a alucinação no estado compartilhado, cada agente downstream que lê esse estado adota a alucinação como fato. No momento em que o humano percebe, a cadeia de raciocínio já está com cinco etapas de profundidade e a causa raiz foi a terceira mensagem escrita. Depurar o declínio de precisão em sistemas multiagentes é mais difícil do que depurar uma falha crítica imediata.

Esse fenômeno é o envenenamento de memória. É a segunda família de falhas mais documentada na taxonomia MAST (Cemri et al., arXiv:2503.13657) e é de natureza estrutural: qualquer design de memória compartilhada sem proveniência e sem um verificador não gravável apresentará esse problema eventualmente.

Conceito

As duas topologias principais

Pool de mensagens completo (Full message pool). Cada agente lê cada mensagem. O AutoGen GroupChat e o MetaGPT usam essa abordagem. É simples, transparente e inspecionável, mas não escala além de aproximadamente 10 agentes porque o contexto de cada agente fica saturado com o trabalho dos outros.

agent-A ──write──▶ ┌────────────────┐ ◀──read── agent-D
                    │ message pool   │
agent-B ──write──▶ │                │ ◀──read── agent-E
                    │ (global log)   │
agent-C ──write──▶ └────────────────┘ ◀──read── agent-F

Quadro negro com assinatura (Blackboard with subscription). Os agentes declaram interesse em tópicos; o substrato roteia apenas as mensagens relevantes. O CA-MCP (arXiv:2601.11595) e o framework descentralizado Matrix (arXiv:2511.21686) usam essa abordagem. Escala mais longe, mas exige o design prévio de esquemas para tornar as assinaturas úteis.

                    ┌─ topic: prices ──┐
agent-A ──pub────▶ │                  │ ──▶ agent-D (subscribed)
                    ├─ topic: orders ──┤
agent-B ──pub────▶ │                  │ ──▶ agent-E (subscribed)
                    ├─ topic: alerts ──┤
agent-C ──pub────▶ │                  │ ──▶ agent-F (subscribed)
                    └──────────────────┘

Quando cada uma vence

• O pool completo vence quando os agentes são poucos (< 10), heterogêneos, e a conversa possui um horizonte curto. Raciocinar sobre quem disse o quê é trivial quando todos veem tudo.
• O quadro negro vence quando os agentes são muitos, homogêneos em papéis, mas numerosos em instâncias (swarms/enxames), e a conversa é de longa duração. O roteamento economiza custos de tokens e evita a poluição do contexto.

Os sistemas de produção frequentemente combinam ambos: um pequeno pool completo no topo (camada de planejamento) e quadros negros abaixo (camada de execução).

Envenenamento de memória, em um cenário prático

Três agentes trabalham em uma tarefa de pesquisa. O Agente A é de recuperação de dados. O Agente B é um sumarizador. O Agente C é um analista.

1. A busca uma página e grava uma mensagem no estado compartilhado: "O estudo relata uma melhoria de precisão de 42%."
2. A página recuperada na verdade dizia "melhoria de 4,2%." O Agente A alucinou uma vírgula decimal.
3. B, ao ler o estado compartilhado, grava: "Grande ganho de precisão de 42% relatado (fonte: A)."
4. C, ao ler o estado compartilhado, grava: "Recomendo a adoção — ganho de 42% é transformador."
5. O relatório final cita um número de 42% que nunca existiu.

Nenhum agente falhou. Nenhum teste acusou erro. O sistema "funcionou". A alucinação passou do contexto de um agente para o raciocínio de todos os agentes downstream por meio do estado compartilhado.

Por que isso é estrutural

Sem o estado compartilhado, a alucinação do Agente A permaneceria em seu contexto. Os agentes downstream teriam que recuperar ou deduzir os dados novamente e poderiam detectar o erro. Com o estado compartilhado ingênuo, o contexto do Agente A torna-se o contexto de todos, e a alucinação é convertida em fato.

O problema não é o estado compartilhado em si — é o estado compartilhado sem proveniência e sem um verificador independente. Três mitigações abordam isso:

1. Atribuir proveniência em cada escrita. Cada entrada no estado compartilhado registra quem a escreveu, quando, sob qual prompt e (se aplicável) qual fonte o agente citou. Os agentes downstream leem com um ceticismo ajustado a essa proveniência.
2. Versionar as escritas; tratá-las como somente anexação (append-only). Uma correção é uma nova entrada que substitui a antiga, não uma atualização no local. A trilha de auditoria é preservada.
3. Manter pelo menos um agente que não possa escrever no estado compartilhado. Um agente verificador somente leitura analisa amostras das entradas, busca novamente as fontes e sinaliza inconsistências. Como não pode escrever no pool, ele não pode ser envenenado por ele.

Precedente do Quadro Negro (Hayes-Roth, 1985)

O padrão de quadro negro precede os agentes baseados em LLM em quatro décadas. Hayes-Roth (1985, "A Blackboard Architecture for Control") descreveu Fontes de Conhecimento especialistas que observam um quadro negro global, contribuem com soluções parciais e acionam outras fontes. O quadro negro de 2026 (CA-MCP, Matrix) é o mesmo padrão, com agentes LLM como Fontes de Conhecimento e dados JSON como soluções parciais. A literatura antiga traz soluções documentadas para disputa de escrita, controle oportunista e consistência que os sistemas modernos estão redescobrindo.

Projeção vs visualização completa

Um quadro negro puro dá a cada assinante a mesma projeção (delimitada ao tópico). Um design mais agressivo é a projeção por agente: cada agente recebe uma visualização personalizada para seu papel. Os redutores de estado do LangGraph são a implementação canônica de 2026 — a função redutora condensa o estado global em uma fatia específica de cada papel.

A projeção por agente escala mais longe, mas precisa de um esquema. Sem ele, reconstrói-se uma projeção ad-hoc no prompt de cada agente.

Padrões de disputa de escrita

Vários agentes gravando simultaneamente é um problema de concorrência, não apenas de LLM. Três padrões funcionam:

• Escritor sequencial (produtor único). Todas as escritas passam por um único agente coordenador que as serializa. Simples, mas cria um gargalo.
• Concorrência otimista com versionamento. Cada entrada tem uma versão; os escritores falham ao tentar gravar com incompatibilidade de versão e reintentam. Técnica clássica de banco de dados.
• Particionamento por tópicos. Diferentes agentes possuem tópicos diferentes. Sem disputa entre tópicos. Requer limites de partição projetados.

A maioria dos frameworks de 2026 adota como padrão o escritor sequencial porque as chamadas de LLM são lentas o suficiente para que a disputa seja rara e o gargalo não prejudique.

O verificador não gravável

A mitigação mais robusta é o verificador somente leitura. Regras de implementação:

• O verificador compartilha o estado com a equipe (lê o quadro negro ou o pool).
• O verificador não tem permissão de escrita no estado compartilhado — apenas em um canal de verificação separado.
• O verificador busca de forma independente as fontes citadas nas escritas. Sinaliza discordâncias.
• As saídas do próprio verificador são direcionadas a um humano ou a um agente de decisão separado, nunca reinseridas no pool.

Sem essa separação, as saídas do verificador tornam-se novas entradas no pool, o que significa que um pool envenenado envenena o verificador, o que consequentemente envenena suas verificações.

Construa

code/main.py implementa ambas as topologias na biblioteca padrão do Python, além de um ataque de envenenamento e três mitigações.

• MessagePool — log de somente anexação thread-safe com leitura completa.
• Blackboard — pub/sub baseado em tópicos com assinaturas por agente.
• ProvenanceEntry — cada escrita registra (writer, timestamp, prompt_hash, source_uri).
• PoisoningScenario — executa uma tarefa de pesquisa de três agentes onde o agente A alucina um decimal. Imprime o relatório final.
• Verifier — um agente somente leitura que busca novamente as fontes e sinaliza inconsistências. Executa o mesmo cenário com o verificador ativo.

Execute:

python3 code/main.py

Saída esperada:

• Execução 1 (sem verificador): o valor alucinado de 42% propaga-se até o relatório final.
• Execução 2 (com verificador): o verificador sinaliza a inconsistência, o pool é rotulado como "flagged" (sinalizado) e o relatório final inclui uma retratação.

Use

O outputs/skill-memory-auditor.md é uma habilidade que audita o design de memória compartilhada de qualquer sistema multiagente quanto à proveniência, versionamento e separação do verificador. Execute-o em novas arquiteturas multiagentes antes da produção.

Coloque em Produção

Para qualquer design de memória compartilhada:

• Registre a proveniência em cada escrita: (writer, timestamp, prompt_hash, tool_calls_cited, source_uri).
• Torne o log somente de anexação. Correções são novas entradas que referenciam a anterior substituída.
• Implante pelo menos um agente verificador somente leitura com acesso independente às fontes.
• Roteie a saída do verificador para um canal separado, não de volta para o pool compartilhado.
• Monitore a proporção de escritas que são substituições — uma proporção crescente é indício precoce de padrões de alucinação.

Exercícios

1. Execute code/main.py. Confirme que a execução 1 propaga a alucinação e a execução 2 a detecta.
2. Adicione uma segunda alucinação: o Agente B inventa o tamanho de um conjunto de dados. O verificador deve capturar ambas sem ser ajustado manualmente para nenhuma delas.
3. Altere o pool completo para um quadro negro com partições de tópicos (prices, summaries, analyses). Quais cenários de envenenamento o particionamento de tópicos torna mais difíceis de ocorrer, e com quais ele não ajuda?
4. Leia Hayes-Roth (1985, "A Blackboard Architecture for Control"). Identifique dois padrões de controle do artigo não discutidos nesta lição dos quais os sistemas de 2026 se beneficiariam.
5. Leia o CA-MCP (arXiv:2601.11595). Mapeie seu Shared Context Store para a classe MessagePool ou Blackboard no code/main.py. Quais primitivas o CA-MCP adiciona por cima?

Termos-Chave

Leituras Adicionais

• Cemri et al. — Why Do Multi-Agent LLM Systems Fail? — taxonomia MAST; envenenamento de memória é uma subfamília de falhas de coordenação
• CA-MCP — Context-Aware Multi-Server MCP — Shared Context Store para servidores MCP coordenados
• Matrix — decentralized multi-agent framework — quadro negro baseado em fila de mensagens sem um orquestrador central
• LangGraph state and reducers — o padrão de projeção por agente em produção
• Anthropic — How we built our multi-agent research system — notas sobre proveniência e verificação de uma implantação em produção