Módulo 3 · Parte B de 3

O agente OpenClaw

O Módulo 3a conectou o navegador a um runtime persistente. O OpenClaw é o harness do agente dentro dessa stack do NemoClaw: combina um modelo e ferramentas com uma sessão mantida no servidor e um workspace em arquivos.

O NemoClaw fornece o blueprint que reúne esse harness, o OpenShell e a política de implantação. Em vez de depender de outro orquestrador em Python, o OpenClaw conduz cada turno e incorpora os arquivos do workspace ao contexto ativo. Você inspecionará esses arquivos, comparará duas personas e salvará uma memória que persiste além da chamada ao modelo.

O layout do diretório é a configuração, então editar um arquivo muda como o próximo turno lê.

O workspace, do ponto de vista do agente

Cada arquivo da pasta fornece uma parte diferente do prompt. Como esse mapeamento é estável, você pode prever qual comportamento uma edição afetará.

.openclaw/workspace/ SOUL.md persona, limites, tom, valores AGENTS.md instruções e regras de funcionamento IDENTITY.md nome, criatura, vibe, emoji USER.md quem é o humano, preferências TOOLS.md notas de utilização por ferramenta HEARTBEAT.md lista periódica de tarefas autônomas memory/ registros diários, um arquivo por dia 2026-06-11.md notas brutas adicionadas durante o trabalho MEMORY.md memória de longo prazo selecionada (somente sessão principal) skills/ pacotes Markdown por skill (próxima página)

A memória tem dois níveis. Enquanto trabalha, o agente adiciona notas brutas a um arquivo datado em memory/. Depois, seleciona o que deve persistir e grava em MEMORY.md. O runtime carrega MEMORY.md na sessão principal, mas não em contextos compartilhados ou de grupo, preservando a privacidade das notas pessoais. Daqui a pouco, você lerá os dois diretamente no sandbox ativo.

Trate o autorrelato como evidência, não como prova. Pergunte ao agente o que seu prompt contém e compare a resposta com o workspace ativo no Passo 1b:

Passo 1 · Peça ao agente para se descrever

Em um turno, a célula abaixo pede ao OpenClaw que liste os arquivos do próprio workspace e explique a função de cada um. A resposta reflete tanto o que o harness incorpora ao prompt quanto o que as ferramentas conseguem ler. Edite um arquivo e execute novamente para alterar o relatório.

Como o gateway incorpora a pasta ao prompt antes de cada turno, editar um arquivo muda a resposta seguinte.

O mesmo runtime do Kickstart. Estas células reutilizam o launchable conectado em 3a. O curso expõe o gateway, não a rota interna /v1/chat/completions. Se uma célula registrar ⚠ DEGRADED ou parar de responder, execute Recuperar uma vez para a instância nova. Em uma implantação local, use o playbook de configuração do NemoClaw e preserve o mesmo contrato do gateway.

Aplicado · OperadorVerificar o workspace a partir do plano do operador?

Passo 1b · Leia o workspace você mesmo

O Passo 1 pediu ao agente que descrevesse os arquivos; você não precisa aceitar apenas o relato. Até aqui, seu único canal foi o gateway que leva mensagens ao agente.

O launchable também expõe um terminal do operador: um shell no host, acima do sandbox do agente, protegido pelo Cloudflare. O helper helpers.terminal() abre esse shell pela página de duas formas:

  • helpers.terminal("bash") abre o shell da VM do host, onde você pode executar openshell sandbox list.
  • helpers.terminal("openshell sandbox connect <agent>") entra dentro do sandbox em que o agente é executado e onde fica o workspace.

O OpenShell fornece o sandbox no nível do kernel que contém o agente. Por enquanto, trate-o como o limite entre operador e agente; o Módulo 4 define e testa esse limite. O nome usado no comando de conexão vem de GET /api/agent, a mesma chamada usada pelo Kickstart para descobrir o launchable.

A célula abaixo entra no sandbox e lê três arquivos da instância ativa: SOUL.md, a memória diária e o MEMORY.md selecionado. Edite a lista de comandos e execute novamente para explorar outros arquivos.

O launchable tem dois planos de autoridade. O terminal opera acima do limite do sandbox e pode ler todos os arquivos e listar os sandboxes. O agente ocupa o segundo plano. Ele compartilha a máquina com o terminal, mas é executado sob a política mais restrita do OpenShell, testada no Módulo 4.

Passo 2 · Dois cenários, lado a lado

Como a persona é um arquivo, trocar a definição em SOUL.md muda a voz do agente. O mecanismo real é simples: grave outra persona no arquivo; o turno seguinte passa a usá-la.

Uma edição real demora para ser demonstrada. Por isso, a célula abaixo simula a troca: envia duas sessões identificadas, e o launchable associa cada chave a uma variante pronta de SOUL.md. Assim, duas configurações respondem à mesma pergunta sem exigir uma edição sua.

O roteamento por chave de sessão é um recurso exclusivo deste laboratório. A imagem do NemoClaw contém variantes prontas de SOUL.md e associa cada sufixo de chave a uma delas, apenas para mostrar duas vozes em um clique. Fora do laboratório, o gateway não contém essas variantes: duas chaves leriam o mesmo SOUL.md e produziriam respostas com a mesma persona. Em uma implantação real, altere a persona editando SOUL.md.

Cenário A · Padrão SOUL.md

OpenClaw padrão: amigável, conciso e disposto a usar qualquer ferramenta permitida pela política; uma configuração adequada ao desenvolvimento.

Ao resumir um documento, produz uma síntese curta e indica quais ferramentas usaria em seguida.

Cenário B · "Auditor" SOUL.md

Uma persona voltada à revisão de código: recusa-se a executar código antes de identificar a superfície de risco e cita o arquivo analisado em cada afirmação.

Ao resumir o mesmo documento, produz uma lista de riscos e perguntas diretas sobre o que não está documentado.

A voz está no arquivo. As respostas diferem porque o runtime incorporou outra definição de SOUL ao prompt de cada sessão. Para alterar a persona de verdade, edite esse arquivo ou adicione um pacote de skill; o próximo turno verá a mudança. No Passo 1b, você leu o SOUL.md ativo no sandbox. Editá-lo percorre o mesmo caminho no sentido inverso.

Passo 3 · O agente edita o próprio contexto

Peça ao agente que grave uma preferência em MEMORY.md e pergunte por ela no turno seguinte. O modelo não possui estado persistente. A segunda resposta só é possível porque o runtime mantém o histórico da sessão e porque o agente salvou MEMORY.md.

Esses meios têm alcances diferentes. O histórico pertence a uma sessão. Um fato salvo em MEMORY.md pode chegar a uma nova sessão cuja transcrição começa vazia.

Essa separação afeta diretamente a segurança. Como o agente pode reescrever o próprio contexto, a camada de contenção precisa impedir que uma gravação indevida cause danos reais. O OpenClaw modifica os arquivos Markdown do workspace, enquanto o sandbox do OpenShell impede que essa gravação alcance:

No próximo módulo, um agente deliberadamente privilegiado demais tentará cruzar esse limite.

Referências

Lista completa em Próximos passos · Referências.

Experimente · chat com o seu agente ao vivo

Toda a página converge neste painel: uma conversa real com o agente OpenClaw executado no launchable. Peça uma das ações abaixo e observe os indicadores de ferramenta durante o trabalho:

Edite um arquivo workspace, e a próxima resposta do agente muda.

← Módulo 3a: Ligar NemoClaw