O que é o Okami Agent
O Okami é um public alpha de agente de codificação open source. A tese é clara: a inteligência mora no harness, não no modelo. O modelo é uma função estreita e troc…
O modelo mental
A maioria dos agentes joga tudo no modelo — planejar, lembrar, emitir tool-calls perfeitos — e reza para o modelo ser forte o bastante. O Okami inverte isso: o harness decompõe a tarefa, restringe a saída, verifica cada efeito e compensa o que falta. Quanto mais fraco o modelo, mais o harness trabalha — por isso um modelo local pequeno chega perto de um modelo de ponta em tarefas bem gateadas.
Comece pelo objetivo
| quero | leia primeiro | próximo passo |
|---|---|---|
| testar no terminal | Instalação + Quickstart | okami chat e okami task em workspace descartável |
| automatizar com evidência | Recipes executáveis | exitCriteria, events e replay |
| rodar bot/API | Canais & gateway | Self-hosting + Runbooks |
| configurar provider | Exemplos de config | Providers & auth + doctor |
| avaliar tecnicamente | Comparação técnica | Arquitetura + versão gerada |
| contribuir com o alpha | Roadmap & changelog | abrir issue, PR ou relato de provider |
| estender capacidades | Skills overview | Tools overview + MCP |
O que “compensar o que falta” quer dizer, na prática
Um modelo fraco tende a (a) declarar conclusão sem ter feito o trabalho, (b) repetir a mesma ação em loop e (c) emitir um tool-call com JSON quebrado. O harness neutraliza os três por construção: a conclusão só vale com exitCriteria verificados mecanicamente; um detector de fingerprint/ciclo corta a repetição; e o decoding restrito (GBNF/json_constrained) impede o JSON inválido. O modelo só precisa propor o próximo passo — o piso de qualidade vem do verificador.
É por isso que a mesma tarefa roda com um modelo local pequeno ou um modelo de ponta sem reescrever nada: o tier e o capability profile do provider dizem ao harness quanto decompor, qual modo de tool-call usar e quando escalar — o resto do andaime é idêntico.
As duas dores que deram origem
Cada capacidade do projeto nasce de uma destas falhas concretas, observadas em outros agentes:
- Harness não-confiável: o agente diz “vou fazer” e não age; cobrado, diz “pera, tô fazendo” e nunca conclui. Falta invariante de ação e detecção real de conclusão.
- Não adere a skills / design system: você pede ShadCN/HeroUI e ele inventa CSS feio. A skill vira sugestão, não gate. Não há verificação mecânica.
run, task ou chat?
Três pontos de entrada, do mais cru ao mais completo. Escolha pelo que precisa:
| comando | o que é | quando usar |
|---|---|---|
| okami run | uma ida-e-volta crua ao provider | testar um prompt, pipe/script simples |
| okami task | harness completo até os exitCriteria | automação verificável (CI, cron, scripts) |
| okami chat | TUI interativa com sessão persistente | trabalhar junto, iterar, conversar |
| okami gateway | bots de canal (Telegram, Paperclip…) | deixar o agente trabalhando remoto |
Anatomia do agente
O pacote okami/ é organizado por domínio — cada peça é plugável e segue as mesmas invariantes:
core/ harness · tools · approval ❤️ o motor (máquina de estados)
llm/ providers · transports · oauth acesso a modelos + roteamento
agents/ load_agents · Router · group multi-agente + grupo
gateway/ run_gateway · sessions control plane / chat
channels/ telegram · paperclip · slack… adapters de canal
learning/ reflect · taste · persona auto-aprimoramento
memory/ sqlite_fts5 · holographic · honcho
skills/ load_skills · skill_security skills + scanComo ler estes docs
A documentação é organizada por intenção. Se você quer fazer algo, vá aos Guias; se quer entender como funciona, aos Conceitos; se quer o detalhe exato de um comando ou chave, à Referência.