🗺️ Visão em camadas — SO clássico vs AIOS
A maior virada conceitual do AIOS é tratar o agente como um processo de SO. No SO clássico você tem aplicações → glibc → kernel → hardware. No AIOS é equivalente: agentes → Cerebrum SDK → AIOS kernel → providers de LLM/storage/tool. Quando você enxerga esse paralelo, todo o resto faz sentido sozinho.
💡 As 3 camadas do AIOS
- •Application Layer — agentes (seu código, ou AutoGen, OpenAGI, MetaGPT).
- •Kernel Layer — AIOS kernel com 6 módulos centrais.
- •OS Layer — Linux/macOS/Windows + GPU/CPU/rede.
📊 Paralelo Linux × AIOS
- Aplicações Linux ↔ Agentes AIOS
- glibc / musl ↔ Cerebrum SDK
- Linux Kernel ↔ AIOS Kernel
- Hardware ↔ Providers + GPU + disco
- Syscall
read()↔ Syscallllm.chat()
💡 Dica mental
Quando estiver perdido, pergunte: "se isso fosse Linux, em que camada estaria?". A resposta quase sempre te leva ao módulo certo do AIOS.
🛡️ Kernel como abstração — O que ele esconde
O kernel age como abstraction layer sobre os recursos do agente. Você não chama "OpenAI" — você chama "LLM Core" e o kernel resolve o provider. Você não escreve em "disco" — você grava no "Storage Manager". Essa indireção é o que dá multi-provider, isolamento e auditoria de graça.
✓ O que o kernel esconde
- ✓Qual provider de LLM está sendo chamado
- ✓Onde a memória está fisicamente
- ✓Qual scheduler está rodando
- ✓Se a tool roda local ou via MCP
- ✓Qual GPU/CPU está executando
✗ O que continua exposto
- ✗Latência real do LLM
- ✗Custo por token
- ✗Limite de context window
- ✗Erros específicos do provider
- ✗Qualidade do modelo escolhido
💡 Abstração não é mágica
AIOS abstrai onde dá. Características inerentes ao modelo (latência, qualidade, contexto máximo) continuam responsabilidade do agente entender. Não confunda abstração de interface com abstração de comportamento.
🌉 Cerebrum SDK — A ponte do agente
Cerebrum é a biblioteca Python que seu agente importa para falar com o kernel. Paper aceito na NAACL 2025. Oferece classes-base de agente, wrappers de syscall e helpers para tools/memory. Sem Cerebrum, você teria que codar o protocolo de syscall na mão.
# Estrutura típica de uso (esquema)
from cerebrum import Agent, LLMCall, MemoryRead, ToolCall
class ResearchAgent(Agent):
def run(self, query):
# syscall: leitura de memória persistente
ctx = MemoryRead(scope="long_term", query=query).execute()
# syscall: chamada de LLM
plan = LLMCall(model="claude-sonnet-4", prompt=f"{ctx}\n\n{query}").execute()
# syscall: execução de tool (registrada no Tool Manager)
result = ToolCall(name="web_search", args={"q": plan.steps[0]}).execute()
return result📊 O que o SDK te dá
- Agent base class — ciclo de vida padrão
- Syscall wrappers — uma classe por tipo (LLM, Memory, Tool, Storage)
- Decorators — para registrar tools e expor ao kernel
- Helpers de testing — mock kernel para rodar fora de prod
- Agent hub client — publicar/baixar agentes da hub
📞 Syscalls do agente — A interface fundamental
Toda comunicação agente→kernel passa por syscall. É unidade de trabalho — entra na fila do Scheduler, é despachada para o módulo certo, retorna ao agente. Pensar em syscalls (e não em chamadas diretas) muda como você estrutura o agente: tudo vira request explícito, auditável, schedulável.
| Syscall | Módulo destino | Uso típico |
|---|---|---|
LLMCall | LLM Core | Geração de texto, raciocínio |
MemoryRead/Write | Memory Manager | Cache rápido por agente |
StorageRead/Write | Storage Manager | Persistência em disco |
ToolCall | Tool Manager | Executar ferramenta registrada |
ContextSwitch | Context Manager | Salvar/restaurar agente |
💡 Custo de pensar em syscalls
Os primeiros dias parecem verboso. Depois fica natural: cada ação importante vira uma linha clara, auditável, schedulável. Vale o investimento.
⛓️ Chain de syscalls — Como uma query vira N módulos
Uma query do usuário raramente vira uma syscall. Vira uma cadeia: LLM → Tool → Storage → LLM → resposta. Cada elo é uma syscall agendada pelo Scheduler. Ver essa cadeia no log de execução é a forma mais rápida de debugar comportamento estranho do agente.
Cadeia típica de "Faça pesquisa X"
LLMCall — planejar
Agente envia query ao LLM Core pedindo um plano. Recebe lista de passos.
MemoryRead — checar contexto
Recupera histórico de pesquisas anteriores da Memory Manager.
ToolCall — buscar
Executa web_search via Tool Manager. Resultado volta como JSON.
StorageWrite — persistir
Salva resultados brutos no Storage Manager para reuso futuro.
LLMCall — sintetizar
Segunda chamada ao LLM consolida resultados em resposta final.
💡 Visualizar a cadeia
Ative log verbose no kernel. Cada syscall aparece com timestamp, agente origem e módulo destino. Esse log é o "strace" do AIOS — indispensável para entender o que está acontecendo.
🖥️ Terminal UI vs Web UI — Duas portas de entrada
AIOS já vem com duas interfaces oficiais. Terminal UI via scripts/run_terminal.py é a entrada de dev — texto puro, rápido, ótima para debugar. Web UI é a entrada de produção — você expõe pra quem não vai mexer em shell.
# Subir o kernel
$ python -m aios.kernel & # background
$ tail -f kernel.log # observa syscalls em tempo real
# Falar via terminal UI
$ python scripts/run_terminal.py
> me explique como funciona o Scheduler
# Servir Web UI (porta padrão)
$ python scripts/run_web.py
# abra http://localhost:8000Terminal UI — Quando usar
- Validar setup rapidamente
- Debugar cadeia de syscalls
- Pipelines automatizados
- Sessão pessoal de pesquisa
Web UI — Quando usar
- Usuário final não-técnico
- Demonstrações
- Multi-usuário concorrente
- Integração com SSO
💡 Recomendação
Em desenvolvimento, viva no Terminal UI — ele te força a ler o log e entender o sistema. Migre para Web UI só quando for entregar pra outra pessoa.
✅ Resumo do Módulo
Próximo módulo:
2.2 — 🧩 Os 6 módulos do kernel. LLM Core, Memory, Storage, Tool, Scheduler e Context Manager por dentro.