⚠️ O problema do estado em sistemas multi-agente
Estado compartilhado em sistemas multi-agente é como um documento Google Docs sendo editado por 10 pessoas ao mesmo tempo — sem controle de versão, sem locks, sem coordenação. O resultado inevitável são conflitos, sobrescritas e dados corrompidos que aparecem horas depois em produção.
⚠️ Cenário real: 3 agentes, 1 estado compartilhado
# Três agentes executando em paralelo
Agente A (t=0ms): lê status = "in_progress"
Agente B (t=1ms): lê status = "in_progress"
Agente A (t=50ms): escreve status = "done", resultado = "análise A"
Agente B (t=51ms): escreve status = "done", resultado = "análise B"
# Problema: Agente B sobrescreveu o resultado de A
# A "análise A" foi perdida silenciosamente
# O sistema acredita que terminou com sucesso
Race Condition
Dois agentes leem o mesmo estado velho, processam e escrevem versões incompatíveis. O resultado depende de qual escreveu por último.
Dirty Read
Agente B lê dados que Agente A está no meio de escrever. O dado está em estado transitório e é inconsistente.
Lost Update
Agente B sobrescreve a atualização de Agente A sem saber que ela existia. Horas de processamento perdidas.
🔴 Estado compartilhado com Redis
Redis como blackboard (quadro negro) é o padrão de fato para estado compartilhado em sistemas multi-agente de alta performance. Todos os agentes leem e escrevem no mesmo Redis, e o Redlock garante exclusão mútua para operações críticas.
🔴 Padrões Redis para agentes
Hash para estado estruturado
# Cada agente tem seu namespace
redis.hset("run:123:agentA",
"status", "done",
"result", json.dumps(result)
)
Pub/Sub para notificações
# Agente publica quando termina
redis.publish(
"run:123:events",
'{"agent": "A", "status": "done"}'
)
Redlock para exclusão mútua
# Lock antes de escrever estado crítico
with redis_lock("run:123:state"):
state = get_state()
state.update(new_data)
set_state(state)
TTL para dados temporários
# Estado expira automaticamente
redis.set("run:123:temp",
value, ex=3600 # 1 hora
)
💡 Redlock: lock distribuído correto
Redlock adquire lock em 3 instâncias Redis em paralelo. Se 2 de 3 respondem com sucesso, o lock é válido. Se o processo morre, o lock expira automaticamente (TTL). Use a biblioteca redis-py com Redlock para implementação correta.
🔒 Estado isolado por agente
A alternativa mais simples ao estado compartilhado: cada agente mantém seu próprio estado isolado, executa de forma completamente independente e entrega o resultado ao coordenador ao finalizar. O coordenador combina todos os estados parciais na fase de fan-in.
✓ Quando usar estado isolado
- ✓Agentes não precisam ler o resultado de outros durante execução
- ✓Tarefas são realmente independentes entre si
- ✓Você prefere simplicidade a performance extrema
- ✓Equipe pequena sem expertise em sistemas distribuídos
✗ Quando NÃO usar estado isolado
- ✗Agente B precisa do resultado do Agente A antes de continuar
- ✗Agentes precisam colaborar em tempo real para ajustar estratégia
- ✗Estado é muito grande para passar via resultado (memória)
Python — Padrão de estado isolado com merge
async def run_parallel_with_isolated_state(agents, task):
# Cada agente recebe cópia do estado inicial (não referência)
results = await asyncio.gather(*[
agent.run(task, initial_state.copy())
for agent in agents
], return_exceptions=True)
# Coordenador combina estados parciais
final_state = merge_results([
r for r in results
if not isinstance(r, Exception)
])
return final_state
def merge_results(results: list) -> dict:
# Estratégia de merge: combina resultados sem conflito
merged = {}
for result in results:
merged.update(result) # ou lógica mais sofisticada
return merged⚡ Conflitos de estado e estratégias de resolução
Mesmo com boas práticas, conflitos de estado acontecem. A questão não é evitá-los completamente — é ter uma estratégia explícita de resolução antes que aconteçam. Descobrir a estratégia em produção quando o usuário já perdeu dados é tarde demais.
Last-Write-Wins (LWW)
A escrita mais recente (por timestamp) vence. Simples de implementar, mas pode perder dados válidos. Aceitável quando os dados são cumulativos e perda parcial é tolerável.
Three-Way Merge
Compara as duas versões conflitantes com o ancestral comum. Combina as mudanças não-conflitantes automaticamente, sinaliza conflitos verdadeiros para resolução manual. Mesmo algoritmo do Git.
Human-in-the-Loop para conflitos críticos
Para dados de alto valor (resultados finais, decisões irreversíveis), conflito → escalada para humano. O humano escolhe qual versão é correta ou como combinar. Lento, mas seguro.
📚 Versionamento de estado com Event Sourcing
Em vez de sobrescrever o estado atual, adicione cada mudança a um log imutável. Você mantém toda a história do estado, pode fazer rollback para qualquer ponto no passado, e tem um audit trail completo — gratuitamente. É o pattern mais usado em sistemas de alta confiabilidade.
📚 Event Sourcing para estado de agente
# Em vez de:
state["status"] = "done" # sobrescreve, perde histórico
# Use event sourcing:
events.append({"
"timestamp": now(),
"agent_id": "executor_A",
"event_type": "status_changed",
"data": {"from": "running", "to": "done"},
"prev_hash": events[-1]["hash"] # integridade
})
# Estado atual = reprodução de todos os eventos
current_state = replay_events(events)
Rollback
Reproduza apenas os eventos até o timestamp desejado. Você volta a qualquer estado passado.
Debug temporal
"O que exatamente aconteceu entre 14h e 14h30?" O log de eventos responde com precisão de milissegundo.
Audit automático
O log de eventos é o audit trail. Cada mudança tem agente, timestamp e hash de integridade.
💡 Snapshot + Log para performance
Reproduzir 10.000 eventos toda vez que precisa do estado atual é lento. A solução: snapshot periódico (estado serializado em um ponto) + log de eventos desde o snapshot. Reproduza apenas os eventos recentes, não todos desde o início.
🏭 Estado em produção
Os problemas de estado que aparecem em produção raramente são os que você previu no design. São os problemas acumulativos: estado que cresce indefinidamente, backups que nunca testaram recovery, e falhas que deixam o sistema em estado inconsistente sem alerta.
Problemas comuns de produção
Estado sem TTL
Estado de execuções antigas nunca expira. Em 3 meses, Redis está cheio e operações ficam lentas.
Backup não testado
Backup existe, mas ninguém testou o restore. Na hora da falha, descobre que o backup está corrompido há semanas.
Recovery sem idempotência
Após reiniciar, as tarefas são executadas de novo do começo — pagando duas vezes pelo mesmo trabalho.
Soluções de produção
TTL strategy
Estado de run ativo: 24h. Estado de run concluído: 7 dias. Estado arquivado: 90 dias → cold storage.
Backup + restore teste semanal
Agende restore automático em ambiente de staging toda semana. Se falhar, alerta antes de precisar em produção.
Idempotência nas tarefas
Cada tarefa verifica se já foi executada (por task_id) antes de rodar. Recovery = replay seguro.
📊 RPO e RTO para sistemas agentic
Defina antes de ir para produção:
RPO (Recovery Point Objective)
Quanto de trabalho de agente posso perder? Se 30 min é aceitável, faça snapshot a cada 30 min.
RTO (Recovery Time Objective)
Em quanto tempo preciso estar de volta? Se 5 min, o restore precisa ser automatizado e testado.
✅ Resumo do Módulo 4.5
Próximo Módulo:
4.6 — Handoffs e Roteamento: a transferência formal de controle entre agentes, critérios de roteamento e o que acontece quando o agente destino falha.