🏗️ Arquitetura especializada — Kernel estendido
O paper LiteCUA (arxiv 2505.18829) propõe estender o kernel AIOS para computer-use sem rasgar nada. LLM Core, Context Manager e Memory Manager continuam iguais. O Tool Manager é o que é redesenhado para incorporar VM Controller e MCP Server. Esse design preserva o modelo mental — agente continua emitindo ToolCall, só que agora algumas tools controlam VMs inteiras.
💡 Por que essa arquitetura
- •Mantém semântica do AIOS — não inventa novo paradigma.
- •Sandbox via VM = isolamento real, não apenas processo.
- •MCP padroniza ações (click, type, screenshot).
- •Reutiliza Scheduler — fairness se aplica também a computer-use.
🔒 VM Controller — Sandbox real
O VM Controller é o componente que orquestra máquinas virtuais (KVM, QEMU, ou microVM como Firecracker). Ele resolve o problema #1 de computer-use: como impedir que o agente, ao clicar "errado", apague o disco do servidor.
📊 Operações suportadas
- Start/Stop — sobe e derruba VM por agente
- Snapshot — congela estado atual (para rollback)
- Restore — volta a um snapshot anterior
- Screenshot — captura framebuffer
- Input injection — clicks, teclado, scroll
💡 Dica
Snapshot antes de cada ação destrutiva. Se agente faz besteira, restore em 100ms — mais barato que reinstalar VM.
🛰️ MCP Server — Computer como tool set
O AIOS hospeda um servidor MCP (Model Context Protocol) que expõe as ações da VM como tools padronizadas. O agente vê isso como "tools normais" — não precisa saber que tem VM por baixo.
# Tools expostas pelo MCP Server (esquema)
- computer.screenshot() -> image
- computer.click(x, y, button)
- computer.type(text)
- computer.scroll(direction, amount)
- computer.key_press(key)
- computer.wait(seconds)
- computer.read_clipboard()💡 MCP é padrão indústria
MCP foi originalmente da Anthropic, mas virou padrão de fato. Qualquer agente que entende MCP fala com a VM AIOS — incluindo agentes de outros stacks.
🌍 OSWorld — Ambiente virtualizado
Subir VM do zero (Ubuntu + GUI + apps) demora dias e é frágil. OSWorld (xlang-ai/OSWorld) entrega imagens prontas de VM com GUI, ferramentas comuns instaladas e suite de benchmarks para computer-use.
📊 O que OSWorld traz
- Imagem Ubuntu com xfce4 (leve) ou GNOME
- Apps pré-instalados: Firefox, LibreOffice, terminal, VSCode
- Benchmark de tarefas de computer-use
- Suporte a KVM, QEMU e Docker
- Scripts de provisioning reproduzíveis
🔁 Fluxo de execução — Loop perceive-decide-act
Computer-use no AIOS implementa o ciclo clássico de agente em ambiente real: perceber (screenshot), decidir (LLM Core analisa imagem e contexto), agir (ToolCall via MCP). Repete até a tarefa estar concluída.
Perceber — screenshot
Agente emite ToolCall computer.screenshot(). VM Controller captura framebuffer e devolve PNG.
Decidir — LLM multimodal
Agente envia imagem + objetivo para LLM Core (GPT-4o / Claude Sonnet multimodal). Recebe próxima ação.
Agir — ToolCall
Agente emite ToolCall (ex: computer.click(420, 380)). VM Controller executa na VM. Loop volta para passo 1.
💡 Custos do loop
Cada ciclo paga 1 screenshot + 1 LLM call + 1 ação na VM. Tarefa típica de 20-50 ciclos. Custo pode escalar — limite passos máximos.
🎨 Casos de uso GUI — Onde computer-use ganha
Computer-use é caro e lento (multimodal por ciclo). Só vale a pena onde API não existe ou onde a UI é a única interface estável.
✓ Faz sentido
- ✓Apps legados Windows/Linux sem API
- ✓Suites pesadas (Excel, PowerPoint) com fluxos complexos
- ✓Web apps que bloqueiam scraping/auto
- ✓Demos visuais para stakeholders
✗ Não vale
- ✗Tem API REST/GraphQL disponível
- ✗Volume alto (cada operação ~5-20s + caro)
- ✗Latência crítica em UX
- ✗Dados sensíveis sem sandbox isolada
✅ Resumo do Módulo
Próximo módulo:
6.2 — 🚀 Roadmap e ecossistema. A-MEM, LSFS, agent hub, Rust e como contribuir.