Um agente que melhora por conta própria: por dentro da autoevolução de Orkas

A maioria dos assistentes de IA são do tipo "use e esqueça". Corrija um hábito hoje e ele repetirá o mesmo erro amanhã; ensine a ele o fluxo de trabalho específico de sua equipe na semana passada e esta semana ele age como se nunca tivesse ouvido falar dele. Toda conversa começa do zero e, por mais inteligente que seja o modelo, ainda é uma pessoa inteligente com amnésia.

Orkas está buscando outra coisa: deixar o agente aprender com seu próprio uso diário, destilando experiências recorrentes para que ele possa aplicá-las por conta própria na próxima vez. Simplificando: ele se torna mais útil quanto mais você o usa, e essa "utilidade" cresce para você, suas preferências, seu domínio, em vez de algo que o fornecedor do modelo predefiniu para todos.

Este artigo explica como esse mecanismo é construído. Não é tão simples como “fazer o modelo se lembrar da conversa” – por trás disso há um ciclo completo: observar a si mesmo → decidir se deve refletir → realmente refletir → escrever as conclusões em algo reutilizável → usá-lo novamente na próxima vez. Analisaremos uma parte de cada vez.

A coisa mais importante primeiro: tudo abaixo — toda a "observação", "gravação" e "reflexão" — acontece inteiramente em seu próprio dispositivo. Execute dados, habilidades, a compreensão que o agente tem de si mesmo — tudo isso reside localmente como arquivos comuns. Nada disso é carregado nos servidores do Orkas e nada é usado para análise entre usuários ou treinamento de modelo. "Autoevolução" significa um programa lendo seus próprios registros de execução localmente e melhorando-se localmente - sem coletar seus dados. Essa experiência nunca sai da máquina e serve apenas a você, nesta máquina.

O loop, de ponta a ponta

uso real, repetidamente
      │ registrado localmente: quais ferramentas foram chamadas, erros ou não, corrigidas ou não
      ▼
   sinais se acumulam
      │ sinais extraídos da conversa no local, todos mantidos no dispositivo
      ▼
  decidir se refletirá
      │ pontuação ponderada entre sinais, dispara apenas além de um limite; soluços de rede não contam
      ▼
   refletir no fundo
      │ não em todos os turnos — periodicamente, escolhendo os agentes qualificados
      ▼
  destilado em duas coisas
      │ ① "habilidades" reutilizáveis ② uma "compreensão" de si mesmo
      ▼
  transportado automaticamente no próximo turno
      └──────────► voltar ao topo, continuar rolando

Cada etapa desse ciclo tem suas sutilezas. Os pontos mais fáceis de errar são exatamente as duas etapas que parecem mais simples à primeira vista: quando refletir e o que registrar depois de fazer isso. Vamos começar pela frente.

Etapa 1: observar a si mesmo com custo quase zero

Para aprender com a experiência você primeiro precisa de “experiência” para olhar. No final de cada execução do agente, o programa conta — localmente, no local — alguns fatos leves sobre a execução: aproximadamente quantas ferramentas foram chamadas neste turno, se houve algum erro, se foi um erro transitório (como um problema de rede) ou real, e se o usuário o corrigiu no local. Apenas algumas contagens e sinalizadores, todos computados na máquina, sem chamar nenhum modelo e não serem enviados a lugar nenhum.

Isso é importante porque não custa nada nos gastos do modelo. Estes são contados diretamente do registro da conversa do turno atual; não há necessidade de fazer uma chamada extra de modelo apenas para "analisar-se". Se cada curva exigisse outro modelo de introspecção, o custo e a latência seriam insuportáveis ​​e todo o mecanismo nunca seria lançado.

A parte "corrigido ou não" é levemente interessante. É um julgamento local puramente heurístico, estimado pela correspondência de algumas frases na mensagem em seu dispositivo, como "não está certo", "deveria ser" ou "refaça", além de termos como errado, na verdade e em vez disso. Não pretende ser preciso — é apenas um sinal, não um veredicto, e os falsos positivos ocasionais são aceitáveis, porque mais tarde são ponderados juntamente com outros sinais; nada é decidido sozinho.

Etapa 2: quando realmente vale a pena refletir

Essa é a parte de todo o mecanismo que acho que mostra mais habilidade.

A abordagem ingênua é "refletir depois de acumular N ocorrências". Mas isso é grosseiro: três tempos limite de rede seguidos e três correções de usuário seguidas obviamente não são a mesma coisa e não devem ser tratados da mesma forma. Orkas usa pontuação multissinal ponderada: cada fenômeno digno de nota é um sinal que carrega um peso; some os pesos dos sinais acionados neste turno e reflita apenas se o total ultrapassar um limite (0,7 por padrão).

Os principais sinais são mais ou menos assim:

Por exemplo: uma curva com correção do usuário (0,9) e alguma complexidade (0,5) soma 1,4, bem além de 0,7, então reflete; uma curva que é apenas um pouco complexa (0,5) falha e é abandonada. A ponderação também reflete um julgamento – uma correção direta do usuário recebe o peso mais alto, 0,9, porque é o feedback sinal-ruído mais alto que existe: o usuário disse claramente que você está errado, então provavelmente vale a pena registrar.

Aquela isenção crítica

Em toda a lógica de pontuação, há uma regra que considero o divisor de águas para saber se esse mecanismo "aprende as coisas certas": erros transitórios nunca contam.

Tempos limite de rede, queda de conexões, limites de taxa — estes são problemas ambientais, não deficiências na capacidade do próprio agente. Deixar de excluí-los e algo ruim acontece: uma ferramenta falha devido a um soluço de rede casual, e o mecanismo de reflexão registra isso como "esta ferramenta não é confiável, use-a menos" - ou até mesmo deturpa ou exclui uma habilidade perfeitamente boa. A partir de então, o agente aprendeu uma lição errada, e esse erro o acompanha.

Portanto, os sinais "recuperado do erro", "habilidade ineficaz" e "atingir uma fraqueza conhecida" mantêm explicitamente os erros transitórios puros fora. O prompt de reflexão também repete o lembrete: erros de classe de rede são ambientais, não os registre como pontos fracos, não toque nas habilidades relacionadas. O que um sistema de autoaperfeiçoamento mais deveria temer não é aprender lentamente – é aprender na direção errada. Essa isenção é o que protege exatamente contra isso.

Etapa 3: a reflexão ocorre em segundo plano, não na sua cara

Uma armadilha fácil: no momento em que você detectar “hora de refletir”, pare e reflita ali mesmo. Isso faz com que o agente sinta que gagueja de vez em quando, vagando para "pensar sobre a vida" - uma experiência ruim.

Orkas move o reflexo para o fundo, em uma cadência fixa. As regras de agendamento, aproximadamente:

• Inicie um ciclo de reflexão de vez em quando (digamos, na ordem de mais de uma dúzia de horas).
• Imponha um tempo de espera mínimo entre duas reflexões para o mesmo agente (algumas horas), para que ele não seja executado com muita frequência.
• Mas se não for refletido há muito tempo (digamos, mais de uma semana), force um, para que não se arraste indefinidamente.
• Limite o número de agentes escolhidos por ciclo, para que não se espalhe muito. de uma vez.

Há um pequeno design que eu gosto chamado de portão sujo: quando um ciclo começa, primeiro verifique se este agente tem algo novo desde sua última reflexão – quaisquer novos sinais, quaisquer registros de conversa atualizados. Se não houver nenhum movimento, pule desta vez e não desperdice uma reflexão (de custeio do modelo). Simples, mas economiza muito na prática.

Etapa 4: como a reflexão realmente funciona

Quando chegar a hora de refletir, o fluxo é: primeiro organize a atividade recente em um "pacote", depois combine-a com um prompt cuidadosamente escrito e entregue-o ao modelo para leitura e resumo.

O pacote tem um orçamento: pegue no máximo algumas conversas recentes, adicione algumas classes de eventos do sistema, intercale-as cronologicamente e limite o total abaixo de um limite de tokens (digamos, mais de dez mil). Nem toda a história incluída - ela não caberia e a relação sinal-ruído seria ruim.

O que realmente importa é o prompt. Requer que o modelo produza não "descrições", mas imperativos executáveis. A diferença parece pequena e é enormemente importante. Comparar:

✗ "A resposta do agente às vezes é muito detalhada; esteja atento."

✓ "Ao responder perguntas do family office, nunca exceda 5 marcadores."

✗ "O usuário parece preferir resultados concisos."

✓ "Ao responder em um contexto de family office, sempre forneça primeiro o resultado final e depois o raciocínio."

O prompt direciona explicitamente o modelo para estruturas "nunca/sempre/quando-então" com condições de acionamento concretas. A razão é prática: uma nota que diz “tenha cuidado para ser conciso” não diz ao agente nada acionável na próxima vez que a ler, enquanto “nunca exceda 5 marcadores” pode ser seguido diretamente. Para que o autoaperfeiçoamento seja útil, o que é destilado tem que ser uma instrução que acerte - e não um lugar-comum correto.

Depois de refletir, o modelo pode fazer algumas coisas: criar ou modificar uma habilidade, atualizar seu entendimento de si mesmo ou — se realmente não houver nada que valha a pena registrar nesta janela — apenas dizer "nada para salvar". Deixá-lo não fazer nada é em si uma escolha importante de design: não force um resultado de aprendizagem, para não acumular uma pilha de ruído inútil.

Destilado em duas coisas

A saída da reflexão fica em dois lugares.

Uma delas são as habilidades. Cada habilidade é um documento Markdown com metadados — um bloco frontmatter registrando o nome, a descrição, os tempos de criação e atualização, quantas vezes foi corrigido e quando foi usado pela última vez — seguido pelas etapas reais ou pontos-chave:

---
nome: "Exportação de relatório semanal"
description: "Compile os dados desta semana no formato padrão de relatório semanal"
criado em: "2025-01-01T00:00:00Z"
atualizadoEm: "2025-01-08T00:00:00Z"
contagem de patches: 2
últimoUsadoEm: "2025-01-09T10:00:00Z"
---

## Etapas
1. ...
2. ...

Armazenar habilidades como arquivos é uma escolha pragmática: uma pessoa pode lê-las diretamente e editá-las diretamente, e não trancá-las em algum banco de dados opaco.

A outra é a compreensão de si mesmo. Esta parte é mais como um memorando que o agente escreve para si mesmo, em duas partes: uma anota "no que sou bom e onde tenho tendência a tropeçar", a outra anota "as jogadas que elaborei para este usuário e este domínio". Ambos têm um limite de comprimento, forçando-os a serem concisos - não mais é melhor, mas mais verdadeiro é melhor. No início da próxima conversa, esse conteúdo é injetado no prompt do sistema, para que o agente entre com "uma compreensão de si mesmo".

Habilidades não são apenas escritas

Basta criar habilidades e você acumula um ferro-velho com o tempo. Portanto, as habilidades têm um ciclo de vida completo.

Além da criação, a operação mais comum é, na verdade, aplicar patches: alterar uma pequena extensão de uma habilidade existente em vez de desmontá-la e reescrevê-la. Cada patch supera um contador e atualiza o tempo de atualização. Isso permite que uma habilidade cresça gradualmente com a experiência, em vez de ser reescrita a cada passo.

Também existe um limite máximo de contagem. O número total de habilidades é limitado (digamos, 200); uma vez cheio, adicionar um novo despeja um antigo via LRU (usado menos recentemente) para liberar espaço. O despejo tem uma preferência: primeiro expulse aqueles que nunca foram usados ​​desde a criação — uma habilidade que nunca foi lida provavelmente nunca foi destilada corretamente, e é melhor abrir caminho.

Cada vez que o agente lê uma habilidade, seu "horário da última utilização" é atualizado. Este carimbo de data/hora alimenta a decisão de despejo da LRU e permite que o mecanismo local diga quais habilidades estão realmente em uso e quais estão apenas ocupando espaço.

Como você sabe se uma habilidade é realmente útil

Esta é a etapa que muitos sistemas de "aprendizagem automática" ignoram preguiçosamente: eles aprenderam alguma coisa - mas será que é bom? Orkas transforma isso em algumas métricas, localmente. Essas métricas são calculadas para uso próprio do mecanismo de evolução na máquina - decidindo qual habilidade revisar ou excluir - e da mesma forma nunca sai desta máquina.

O mecanismo: no início de cada turno, as habilidades disponíveis aparecem no índice do prompt do sistema — essa é uma "impressão"; se o agente realmente ler uma habilidade naquele turno, isso será uma “invocação”. Compare os dois e você obterá a primeira métrica —

• Taxa de invocação = invocações/impressões. Uma habilidade que permanece lá dia após dia sem compradores tem uma baixa taxa de invocação, o que significa que é inútil ou descrita de forma que ninguém sabe quando usá-la.
• Taxa de edição após acerto = a proporção de vezes que uma habilidade foi invocada, mas o usuário editou o resultado manualmente. Alto significa que a habilidade produzida não é exatamente do gosto do usuário.
• Taxa ineficaz = a proporção de vezes que uma habilidade foi invocada, mas o turno terminou com um erro (não transitório). Alto sugere que algo pode estar errado com a habilidade em si.

Aqui você vê a sombra dessa isenção novamente: ao calcular a taxa ineficaz, os erros transitórios não contam, nem as interrupções manuais do usuário no meio do caminho — você não pode colocar uma marca preta em uma habilidade perfeitamente boa por causa de um problema de rede.

Com esses poucos números, as habilidades passam de “acumular em uma caixa preta” para “algo que pode ser avaliado e otimizado”. Qual habilidade revisar ou excluir não é mais uma decisão instintiva.

Fechando o ciclo

Juntando os itens acima, um ciclo completo é assim:

O agente trabalha em tarefas reais, registrando os dados da execução localmente e marcando os sinais à medida que avançam. Quando o ciclo de reflexão em segundo plano chega ao vencimento, ele escolhe os agentes que têm novo movimento e já passaram do tempo de espera, organiza a atividade recente de cada um em um pacote e faz com que o modelo os revise em relação à sua autocompreensão atual – mesclando o que deveria ser mesclado, retirando o que deveria ser retirado, destilando o que deveria ser destilado em novas habilidades. O resultado da revisão torna-se habilidades e autocompreensão. Na próxima conversa, essas habilidades vão para o índice de prompt e a autocompreensão vai para o prompt do sistema, e o agente volta carregando o que aprendeu na última rodada. Em seguida, esta rodada produz novas métricas e sinais, que são transmitidos desde o início.

O loop continua, rodada após rodada. Nem toda rodada traz um salto dramático, mas a direção é unidirecional: entender você melhor e repetir menos dos mesmos erros.

Algumas compensações que vale a pena mencionar

Olhando para trás, algumas decisões nesse mecanismo são fundamentais.

A introspecção deve ser barata. A própria observação usa métricas de custo de modelo zero; o reflexo genuinamente caro é movido para segundo plano, executado com pouca frequência e primeiro bloqueado pela verificação suja. Aperte com força a parte "cara" e todo o mecanismo poderá realmente funcionar.

É melhor não aprender do que aprender errado. A isenção de erros transitórios, permitindo que a reflexão "não salve nada", escrevendo imperativos executáveis ​​em vez de descrições vagas - todos apontam para o mesmo julgamento: para um sistema que se aperfeiçoa, aprender na direção errada é muito mais perigoso do que aprender lentamente.

O que você aprendeu deve estar visível, editável e estar em suas mãos. As habilidades são arquivos de texto simples, a autocompreensão é um memorando de texto simples, a eficácia das habilidades pode ser verificada por meio de métricas — e todos esses arquivos ficam em sua própria máquina, não na nuvem. Nenhuma caixa preta em lugar nenhum; um ser humano pode abri-lo e ajustá-lo a qualquer momento.

Coloque freios no aprendizado. Limites de contagem, despejo de LRU, limites de comprimento — sem isso, o "aprendizado contínuo", mais cedo ou mais tarde, torna-se um "inchaço contínuo". Esquecer, abandonar e podar importa tanto quanto lembrar.

Concluindo

A autoevolução de Orkas é, no fundo, adicionar um loop lento ao agente: o loop rápido é a resposta imediata de cada conversa; o loop lento periodicamente olha para trás e destila a experiência em algo utilizável na próxima vez. A parte difícil não é "fazer o modelo lembrar" - são os julgamentos de engenharia facilmente esquecidos: como saber quais experiências valem a pena registrar, como não ser prejudicado por uma falha casual, como tornar o que foi aprendido genuinamente executável e como podá-lo antes que inche.

Esses julgamentos, tomados em conjunto, transformam "fica mais útil quanto mais você o usa" de uma linha de marketing em um mecanismo que realmente funciona. Um assistente que aprende com você (e não aprende as coisas erradas) pode estar mais próximo do que a maioria das pessoas realmente deseja do que aquele que é apenas mais inteligente.