🧠 OpenAGI — O parceiro natural
OpenAGI é o framework de agentes mantido pela mesma AGI Research que criou o AIOS. Integração é nativa — agentes OpenAGI usam Cerebrum como cliente padrão, com benchmark conjunto que valida a stack inteira a cada release.
💡 Por que começar por aqui
- •Documentação alinhada com o AIOS (mesmo vocabulário).
- •Exemplos oficiais cobrem fluxos completos.
- •Quando o kernel evolui, OpenAGI é atualizada primeiro.
- •Benchmark do paper AIOS usa OpenAGI como referência.
💡 Dica
Reproduza o benchmark do paper antes de tentar workload custom. Se reproduzir, sua instalação está sã. Se não reproduzir, tem algo errado no setup.
💬 AutoGen (Microsoft) — Multi-agente conversa
AutoGen é o framework da Microsoft para multi-agente conversacional. Sobre o AIOS, os agentes AutoGen ganham scheduler compartilhado — dois agentes conversando não disputam quota OpenAI no servidor, pois o LLM Core arbitra.
📊 Padrões que ganham com AIOS
- GroupChat — fairness entre os papéis
- Code Executor agent — sandbox via Tool Manager
- Critic agent — escalona junto com os outros
- Selector chat — Scheduler entra antes da seleção
💡 Trade-off
Você perde acesso direto ao API client da Microsoft (que tem alguns truques de tool-use proprietários). Em troca, ganha portabilidade e fairness. Para multi-agente sério, vale.
💻 Open-Interpreter — Code execution agent
Open-Interpreter é o agente que escreve e executa código localmente. Sozinho, ele roda código direto na máquina. Sobre AIOS, o Tool Manager intermedia: você define quais comandos podem rodar, em qual sandbox, com qual timeout.
✓ Ganhos
- ✓Sandbox de execução
- ✓Whitelist de comandos
- ✓Auditoria centralizada
- ✓Timeout por execução
✗ Cuidado
- ✗Sandbox não é mágica — configure direito
- ✗Comandos perigosos exigem whitelist explícita
- ✗Container/VM separado para produção real
- ✗Logs de toda execução, sempre
🏢 MetaGPT — Agentes com papéis
MetaGPT simula uma "empresa de software" com agentes representando papéis: Product Manager, Engineer, QA, Architect. Sobre AIOS, cada papel é agente independente que compete por LLM Core via Scheduler.
📊 Casos de uso típicos
- Gerar requisitos + design + código + testes em pipeline
- Simulação de workflows corporativos
- Pesquisa de patterns de colaboração multi-agente
- Demo de "AI company" para stakeholders
🔌 Plugar via Cerebrum — Adapter pattern
A receita para qualquer framework: adapter. Substitua chamadas diretas de LLM (e.g., openai.chat.completions.create) por cerebrum.LLMCall. Para o framework, nada mudou — a chamada continua síncrona. Para o AIOS, agora é syscall escalonável.
# Antes (framework puro)
import openai
resp = openai.chat.completions.create(model="gpt-4o", messages=[...])
# Depois (adapter Cerebrum)
from cerebrum import LLMCall
resp = LLMCall(model="gpt-4o", messages=[...]).execute()💡 Boa notícia
A maioria dos frameworks já tem ponto único de chamada LLM. Você troca em um lugar e tudo passa pelo AIOS. 30 minutos para os 80% dos frameworks.
📈 Pattern de migração — Incremental
Não migre tudo de uma vez. Strangler pattern: comece com 1 ponto (chamada LLM), depois tools, depois memory. Cada etapa valida que o framework continua funcionando.
Etapa 1 — Trocar LLM client
Substitua chamadas diretas por LLMCall. Comportamento idêntico, agora escalonável.
Etapa 2 — Registrar tools
Mover tools do framework para Tool Manager. Reuso entre agentes.
Etapa 3 — Migrar memória
Estado vai para Memory/Storage do kernel. Persistência e snapshot gratuitos.
✅ Resumo do Módulo
Próximo módulo:
5.2 — 🎬 Casos práticos. Multi-agent, research, code, workflows e observabilidade.