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

A maioria dos assistentes de IA é do tipo "use e esqueça". Corrija um hábito hoje e o assistente repetirá o mesmo erro amanhã; ensine-lhe o fluxo de trabalho específico da sua equipa numa semana e, na semana seguinte, age como se nunca tivesse ouvido falar dele. Todas as conversas começam do zero e, por mais inteligente que seja o modelo, continua a ser uma pessoa inteligente com amnésia.

O Orkas procura outra coisa: deixar o agente aprender com a sua própria utilização diária, destilando experiências recorrentes para que possa aplicá-las por iniciativa própria da próxima vez. Simplificando: torna-se mais útil quanto mais o utiliza, e essa "utilidade" cresce à medida de si, das suas preferências, do seu domínio, em vez de ser algo que o fornecedor do modelo predefiniu para todos.

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

O mais importante primeiro: tudo o que se segue — toda a "observação", "gravação" e "reflexão" — acontece inteiramente no seu próprio dispositivo. Os dados de execução, as competências, a compreensão que o agente tem de si próprio — tudo isto reside localmente em ficheiros comuns. Nada disto é enviado para os servidores do Orkas e nada é usado para análise entre utilizadores ou treino de modelos. "Autoevolução" significa um programa ler os seus próprios registos de execução localmente e melhorar-se localmente - sem recolher os seus dados. Esta experiência nunca sai da máquina e serve apenas a si, nesta máquina.

O ciclo, 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 deste ciclo tem as suas subtilezas. Os pontos em que é mais fácil errar são precisamente as duas etapas que parecem mais simples à primeira vista: quando refletir e o que registar depois de o fazer. Comecemos pelo início.

Etapa 1: observar-se com um custo quase nulo

Para aprender com a experiência, primeiro é preciso ter “experiência” para analisar. No final de cada execução do agente, o programa contabiliza — localmente, no próprio dispositivo — alguns dados simples 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 utilizador o corrigiu na altura. Apenas algumas contagens e indicadores, todos calculados na máquina, sem chamar qualquer modelo nem serem enviados para lado nenhum.

Isto é importante porque não acrescenta custos de utilização do modelo. Estes dados são contabilizados diretamente a partir do registo da conversa do turno atual; não é necessário fazer uma chamada adicional ao modelo apenas para "se analisar". Se cada turno exigisse outra chamada ao modelo para introspeção, o custo e a latência seriam insuportáveis e o mecanismo nunca chegaria a ser lançado.

A parte "corrigido ou não" é um pouco interessante. Trata-se de uma avaliação local puramente heurística, estimada pela correspondência de algumas expressões na mensagem no seu dispositivo, como "não está certo", "deveria ser" ou "volte a fazer", além de termos como wrong, actually e instead. 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; nenhum sinal determina a decisão por si só.

Etapa 2: quando realmente vale a pena refletir

Esta é a parte de todo o mecanismo que, na minha opinião, revela mais engenho.

A abordagem ingénua é "refletir depois de acumular N ocorrências". Mas isso é pouco rigoroso: três tempos limite de rede seguidos e três correções do utilizador seguidas não são, obviamente, a mesma coisa e não devem ser tratados da mesma forma. O Orkas usa pontuação multissinal ponderada: cada fenómeno digno de nota é um sinal com um peso; somam-se os pesos dos sinais ativados neste turno e só se reflete se o total ultrapassar um limiar (0,7 por predefinição).

Os principais sinais são mais ou menos assim:

Por exemplo: um turno com uma correção do utilizador (0,9) e alguma complexidade (0,5) soma 1,4, bastante acima de 0,7, pelo que desencadeia a reflexão; um turno que é apenas um pouco complexo (0,5) fica abaixo do limiar e é descartado. A ponderação também reflete uma avaliação – uma correção direta do utilizador recebe o peso mais elevado, 0,9, porque é o feedback com a melhor relação sinal-ruído que existe: o utilizador disse claramente que o agente está errado, pelo que provavelmente vale a pena registar.

Aquela exceção crucial

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

Tempos limite de rede, quebras de ligação, limites de frequência — estes são problemas do ambiente, não deficiências na capacidade do próprio agente. Se não forem excluídos, acontece algo indesejável: uma ferramenta falha devido a um problema pontual de rede e o mecanismo de reflexão regista isso como "esta ferramenta não é fiável, use-a menos" - ou até deturpa ou elimina uma competência perfeitamente válida. A partir daí, o agente aprendeu uma lição errada, e esse erro acompanha-o.

Por isso, os sinais "recuperação de um erro", "competência ineficaz" e "atingiu um ponto fraco conhecido" excluem explicitamente os erros puramente transitórios. O prompt de reflexão também repete o lembrete: os erros de rede são problemas do ambiente, não os registe como pontos fracos, não altere as competências relacionadas. O que um sistema de autoaperfeiçoamento mais deve temer não é aprender lentamente – é aprender na direção errada. Esta exceção protege precisamente contra isso.

Etapa 3: a reflexão ocorre em segundo plano, sem interromper

Uma armadilha fácil: assim que detetar que chegou a “hora de refletir”, parar e refletir imediatamente. Isso dá a sensação de que o agente se engasga de vez em quando, divagando para "pensar na vida" - uma má experiência.

O Orkas passa a reflexão para segundo plano, a uma cadência fixa. As regras de agendamento são, aproximadamente:

• Inicie um ciclo de reflexão de vez em quando (por exemplo, a intervalos da ordem de mais de uma dúzia de horas).
• Imponha um tempo de espera mínimo entre duas reflexões do mesmo agente (algumas horas), para que a reflexão não seja executada com demasiada frequência.
• Mas, se não tiver havido uma reflexão há muito tempo (por exemplo, há mais de uma semana), force uma, para que não seja adiada indefinidamente.
• Limite o número de agentes escolhidos por ciclo, para que a reflexão não se disperse demasiado de uma só vez.

Há um pequeno detalhe de conceção de que gosto, chamado verificação de alterações pendentes: quando um ciclo começa, verifique primeiro se este agente tem algo novo desde a última reflexão – novos sinais ou registos de conversa atualizados. Se não houver qualquer atividade nova, salte esta vez e não desperdice uma reflexão (com custos de utilização do modelo). É simples, mas poupa muito na prática.

Etapa 4: como a reflexão realmente funciona

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

O pacote tem um orçamento: selecione, no máximo, algumas conversas recentes, adicione algumas classes de eventos do sistema, intercale tudo cronologicamente e mantenha o total abaixo de um limite de tokens (por exemplo, mais de dez mil). Nem todo o histórico é incluído - não caberia e a relação sinal-ruído seria má.

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

✗ "A resposta do agente é por vezes demasiado detalhada; esteja atento."

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

✗ "O utilizador parece preferir resultados concisos."

✓ "Ao responder num contexto de family office, apresente sempre primeiro o resultado final e depois o raciocínio."

O prompt orienta explicitamente o modelo para estruturas "nunca/sempre/quando-então" com condições de ativação concretas. A razão é prática: uma nota que diz “tenha cuidado para ser conciso” não dá ao agente nenhuma indicação que possa executar da próxima vez que a ler, enquanto “nunca exceda 5 pontos” pode ser seguido diretamente. Para que o autoaperfeiçoamento seja útil, o que é destilado tem de ser uma instrução certeira - e não um lugar-comum correto.

Depois de refletir, o modelo pode fazer algumas coisas: criar ou modificar uma competência, atualizar a compreensão que tem de si próprio ou — se realmente não houver nada que valha a pena registar neste intervalo — dizer apenas "nada para guardar". Permitir-lhe não fazer nada é, por si só, uma escolha importante de conceção: não force um resultado de aprendizagem, para não acumular uma pilha de ruído inútil.

Destilado em duas coisas

O resultado da reflexão fica em dois sítios.

Um deles são as competências. Cada competência é um documento Markdown com metadados — um bloco frontmatter que regista o nome, a descrição, as datas de criação e atualização, quantas vezes foi corrigida e quando foi utilizada pela última vez — seguido dos passos concretos ou pontos-chave:

---
name: "Weekly Report Export"
description: "Compile this week's data into the standard weekly-report format"
createdAt: "2025-01-01T00:00:00Z"
updatedAt: "2025-01-08T00:00:00Z"
patchCount: 2
lastUsedAt: "2025-01-09T10:00:00Z"
---

## Steps
1. ...
2. ...

Guardar competências em ficheiros é uma escolha pragmática: uma pessoa pode lê-las e editá-las diretamente, sem ficarem fechadas numa base de dados opaca.

O outro é a compreensão de si próprio. Esta parte assemelha-se a um memorando que o agente escreve para si próprio, em duas partes: uma regista "aquilo em que sou bom e onde tenho tendência a tropeçar", a outra regista "as estratégias que desenvolvi para este utilizador e este domínio". Ambas têm um limite de comprimento, que obriga à concisão - não é a quantidade que conta, mas a veracidade. No início da conversa seguinte, este conteúdo é inserido no prompt do sistema, para que o agente entre com "uma compreensão de si próprio".

As competências não são apenas escritas

Se apenas criar competências, acabará por acumular uma sucata com o tempo. Por isso, as competências têm um ciclo de vida completo.

Além da criação, a operação mais comum é, na verdade, aplicar patches: alterar uma pequena parte de uma competência existente em vez de a desmontar e reescrever. Cada patch incrementa um contador e atualiza a data de atualização. Isto permite que uma competência cresça gradualmente com a experiência, em vez de ser reescrita a cada passo.

Também existe um limite máximo de quantidade. O número total de competências é limitado (por exemplo, 200); quando o limite é atingido, adicionar uma nova implica remover uma antiga através de LRU (utilizada há mais tempo) para libertar espaço. A remoção tem uma preferência: elimine primeiro as que nunca foram utilizadas desde a criação — uma competência que nunca foi lida provavelmente nunca foi destilada corretamente, e é melhor dar lugar a outra.

Sempre que o agente lê uma competência, a sua "hora da última utilização" é atualizada. Este carimbo de data/hora serve de base à decisão de remoção por LRU e permite ao mecanismo local identificar que competências estão realmente em uso e quais estão apenas a ocupar espaço.

Como saber se uma competência é realmente útil

Esta é a etapa que muitos sistemas de "aprendizagem automática" ignoram por preguiça: aprenderam alguma coisa - mas será que é boa? O Orkas traduz isso em algumas métricas, localmente. Estas métricas são calculadas para uso do próprio mecanismo de evolução na máquina - para decidir que competência rever ou eliminar - e também nunca saem desta máquina.

O mecanismo: no início de cada turno, as competências disponíveis aparecem no índice do prompt do sistema — isso é uma "impressão"; se o agente ler efetivamente uma competência nesse turno, isso é uma “invocação”. Compare os dois valores e obterá a primeira métrica —

• Taxa de invocação = invocações/impressões. Uma competência que permanece ali dia após dia sem interessados tem uma taxa de invocação baixa, o que significa que é inútil ou está descrita de uma forma que não permite perceber quando utilizá-la.
• Taxa de edição após invocação = a proporção de vezes em que uma competência foi invocada, mas o utilizador editou o resultado manualmente. Um valor elevado significa que o resultado produzido pela competência não corresponde exatamente ao gosto do utilizador.
• Taxa de ineficácia = a proporção de vezes em que uma competência foi invocada, mas o turno terminou com um erro (não transitório). Um valor elevado sugere que pode haver algo de errado com a própria competência.

Aqui volta a ver-se o efeito daquela exceção: ao calcular a taxa de ineficácia, os erros transitórios não contam, nem as interrupções manuais do utilizador a meio — não se pode penalizar uma competência perfeitamente válida por causa de um problema de rede.

Com estes poucos números, as competências passam de “algo que se acumula numa caixa preta” para “algo que pode ser avaliado e otimizado”. A escolha da competência a rever ou eliminar deixa de ser uma decisão instintiva.

Fechar o ciclo

Juntando os elementos acima, um ciclo completo funciona assim:

O agente trabalha em tarefas reais, registando os dados de execução localmente e assinalando os sinais à medida que avança. Quando chega a altura do ciclo de reflexão em segundo plano, o mecanismo escolhe os agentes que têm atividade nova e cujo tempo de espera já terminou, organiza a atividade recente de cada um num pacote e pede ao modelo que a reveja à luz da sua autocompreensão atual – combinando o que deve ser combinado, retirando o que deve ser retirado e destilando o que deve ser destilado em novas competências. O resultado da revisão transforma-se em competências e autocompreensão. Na conversa seguinte, essas competências entram no índice do prompt e a autocompreensão entra no prompt do sistema, e o agente regressa com o que aprendeu no ciclo anterior. Este ciclo produz então novas métricas e sinais, que regressam ao início.

O ciclo continua, volta após volta. Nem todas as voltas trazem um salto dramático, mas a direção é sempre a mesma: compreendê-lo melhor e repetir menos os mesmos erros.

Alguns compromissos que vale a pena mencionar

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

A introspeção deve ser barata. A própria observação usa métricas sem custos de utilização do modelo; a reflexão realmente dispendiosa passa para segundo plano, é executada com pouca frequência e depende primeiro da verificação de alterações pendentes. Mantenha a parte "cara" sob controlo rigoroso e todo o mecanismo poderá realmente funcionar.

É melhor não aprender do que aprender errado. A exceção dos erros transitórios, a possibilidade de a reflexão "não guardar nada", a escrita de imperativos executáveis em vez de descrições vagas - tudo aponta para o mesmo princípio: para um sistema que se aperfeiçoa, aprender na direção errada é muito mais perigoso do que aprender lentamente.

O que foi aprendido deve ser visível, editável e estar nas suas mãos. As competências são ficheiros de texto simples, a autocompreensão é um memorando de texto simples, a eficácia das competências pode ser verificada através de métricas — e todos esses ficheiros ficam na sua própria máquina, não na nuvem. Nenhuma caixa preta em lado nenhum; uma pessoa pode abrir tudo e ajustá-lo a qualquer momento.

Ponha travões à aprendizagem. Limites de quantidade, remoção por LRU, limites de comprimento — sem isto, a "aprendizagem contínua" transforma-se, mais cedo ou mais tarde, num "inchaço contínuo". Esquecer, abandonar e podar importa tanto como lembrar.

Para concluir

A autoevolução do Orkas consiste, no fundo, em adicionar um ciclo lento ao agente: o ciclo rápido é a resposta imediata de cada conversa; o ciclo lento olha periodicamente para trás e destila a experiência em algo utilizável da próxima vez. A parte difícil não é "fazer o modelo lembrar-se" - são as decisões de engenharia facilmente esquecidas: como saber que experiências vale a pena registar, como evitar ser prejudicado por uma falha pontual, como tornar o que foi aprendido verdadeiramente executável e como o podar antes que inche.

Estas decisões, tomadas em conjunto, transformam "fica mais útil quanto mais o utiliza" de uma frase de marketing num mecanismo que realmente funciona. Um assistente que aprende consigo (e não aprende as coisas erradas) pode estar mais próximo do que a maioria das pessoas realmente deseja do que um que seja apenas mais inteligente.

Para ver os agentes especializados em que este ciclo lento se apoia, conheça a equipa de agentes do Orkas.