Reescrevendo a base do agente: uma refatoração básica de Orkas

Quando um produto de agente de IA amadurece, o mais caro não são os recursos, mas a base. Este artigo aborda a refatoração básica que Orkas fez em sua linha de lançamento 1.0 — uma revisão completa da invocação de modelo, do loop de agente, da orquestração multiagente e do ecossistema de ferramentas — e as compensações por trás de cada decisão.

Por que tocar na base

Orkas é um espaço de trabalho local para agentes de IA de desktop: todo o trabalho do agente é executado dentro de um processo na própria máquina do usuário, os dados residem localmente e a sincronização de ponta a ponta na nuvem acontece sob demanda. Os recursos se acumularam rapidamente nas primeiras versões — uma biblioteca de habilidades, uma base de conhecimento, conectores, multiagente estilo chat em grupo — mas quanto mais avançávamos, mais claro ficava: o verdadeiro gargalo não era um recurso único, mas três coisas de "nível básico".

1. Se a camada de invocação de modelo seguir o velho caminho conversacional, ela ficará presa a uma série de suposições erradas. Chamar um modelo grande como se fosse um "bate-papo de uma pergunta e uma resposta" contrabandeia uma pilha de padrões que fazem sentido para o bate-papo, mas não para um agente: um limite fixo de token de saída, chamadas de ferramentas seriais, tempos limite ocultos, um único provedor conectado. Um agente é um fluxo de longa execução que executa dezenas de turnos seguidos, esbarra rotineiramente na janela de contexto, precisa ler arquivos em paralelo e pode ser interrompido pelo usuário a qualquer momento — cada um desses padrões irá incomodá-lo na produção. Pior ainda, os recursos mais valiosos de um agente de desktop – operações refinadas de arquivos, pesquisa local, execução de um shell, execução paralela de vários trabalhadores, resolução de tarefas de longo horizonte – são exatamente aqueles que essa camada de suposições exclui.

2. A orquestração era um "planejamento estático". A versão inicial era um mecanismo de plano/DAG: primeiro, o modelo dividia a tarefa em um gráfico de plano e, em seguida, enviava um executor pelo gráfico. Parece simples, mas a realidade de um agente é altamente dinâmica: a leitura de um arquivo revela que você precisa mudar de direção, e o resultado de uma subtarefa decide para quem vai o próximo passo. Congelar decisões em um gráfico pré-gerado significa que cada "plano não consegue acompanhar a realidade" precisa ser corrigido dentro do executor.

3. O ecossistema era um catálogo fechado. As habilidades só podiam vir do mercado oficial, os conectores eram um catálogo codificado e as ferramentas de agente externo já na máquina do usuário eram uma caixa preta completa para Orkas. Um usuário que deseja conectar um projeto de terceiros, seu próprio servidor MCP ou ter um agente já em sua máquina liga de volta para as habilidades e base de conhecimento de Orkas. Arquitetonicamente, nada disso era possível.

A tese deste refatorador é simples: tomar a base do agente de volta em nossas próprias mãos. Concretamente, ele resulta em quatro linhas interligadas: um tempo de execução no processo autoconstruído, uma camada de modelo independente de provedor, orquestração dinâmica de bate-papo em grupo e a mudança de um catálogo fechado para um host aberto. Vamos analisá-los um por um.

1. Trazendo um conjunto completo de recursos de agente de codificação para o desktop

A área de trabalho é a casa do agente — aqui há um sistema de arquivos real, um shell real, um conjunto de ferramentas local real. Um assistente que só consegue conversar está desperdiçando o meio ambiente; o que realmente aproveita a vantagem do desktop é um conjunto completo de recursos de agente de codificação: leitura e gravação de arquivos no intervalo de caracteres, pesquisa entre arquivos, execução de bash e ferramentas de sistema, ativação de vários trabalhadores em paralelo e solução de problemas de longo horizonte para continuar executando dezenas de turnos até que uma tarefa complexa seja realmente concluída.

O principal produto do refatorador existe precisamente para trazer esse conjunto de recursos nativamente para o próprio processo do Orkas — um tempo de execução de agente em processo independente e carregável dinamicamente (chamado core-agent no código). Não é mais um wrapper de bate-papo; é um mecanismo de agente que Orkas controla.

A principal decisão arquitetônica foi dividi-la em duas camadas:

• Camada de mecanismo (pacote independente): maquinário de agente puro — o loop de chamada de ferramentas, eventos de streaming, compactação de contexto, classificação de erros e novas tentativas, abstração do provedor, sandbox, verificação de habilidades, memória, autoevolução. Ele não sabe nada sobre nenhum negócio Orkas: ele não lê diretórios de dados comerciais, não entende o formato do arquivo de conversação e nunca toca no IPC.
• Camada adaptadora (dentro do processo principal): conecta o mecanismo ao Orkas — persistência de sessão, rotação de provedores, permissões de ferramentas, registro de habilidades, conectores, base de conhecimento, as diversas ferramentas de geração. Ele traduz os eventos nativos do mecanismo nos formatos de eventos do próprio Orkas, de forma que a camada de negócios veja apenas uma interface estável.

Esse limite entre motor/adaptador é a raiz de toda a flexibilidade que se segue. O motor pode ser testado e evoluído de forma independente; a camada do adaptador pode absorver com segurança a complexidade específica do Orkas (rotação, resfriamento, sandbox, permissões) sem poluir o mecanismo. A revisão da arquitetura da equipe resumiu tudo em uma linha: isso é complexidade adquirida — não vá mesclá-la.

Qual ​​é realmente o conjunto de recursos

Segurar o tempo de execução com as próprias mãos não significa se exibir; trata-se de deixar o agente genuinamente “sujar as mãos” na área de trabalho. O conjunto de recursos se divide em aproximadamente quatro grupos:

• Operações de arquivo refinadas e pesquisa local. read_file suporta leitura por intervalo de caracteres e extrai automaticamente texto de documentos PDF/Office; edit_file faz uma substituição precisa de "string antiga → nova string" e requer uma leitura antes de qualquer gravação; write_file obtém o artefato e mantém um registro dele; stat_file tamanho do teste; search_files localiza por nome/glob, grep_files pesquisa conteúdo em arquivos. Este grupo permite que o agente "explore o código, altere arquivos" em um espaço de trabalho real como um engenheiro, em vez de apenas engolir e emitir blocos inteiros.
• Bash e ferramentas de sistema. Um executor de shell em sandbox, com um modo de execução em segundo plano (tarefas longas são separadas do turno atual, os logs vão para um arquivo) e portas com classificação de risco para operações perigosas. Uma grande parte da vantagem de um agente de desktop vem precisamente da capacidade de comandar diretamente a cadeia de ferramentas do sistema.
• Multi-trabalhador paralelo. Em um único turno, ferramentas independentes somente leitura são executadas simultaneamente; no nível da tarefa, o comandante também pode distribuir subtarefas independentes para vários trabalhadores em paralelo (ver Seção 3). Paralelizar onde é seguro é a chave para compactar "tarefas de longo horizonte" em um tempo aceitável de relógio.
• Raciocínio de longo horizonte e resolução de tarefas. Um loop que pode executar dezenas de voltas seguidas, gerenciar seu próprio contexto, se recuperar de erros e nunca ficar preso no lugar — esta é a linha divisória entre "terminar um trabalho complexo" e "responder a uma pergunta".

Como foi feito o nível de produção em termos de engenharia

"Escrever seu próprio loop" soa como pedir encrenca e acarreta custos de manutenção. Mas o que ele compra é um controle refinado sobre todo o ciclo de vida do agente. Esse controle não é abstrato — é um conjunto de melhorias concretas, cada uma correspondendo ao fato de um dos recursos acima "se manter" na produção:

• Janela de contexto real + compactação apenas em 80%. O mecanismo lê a janela de contexto real de cada modelo (incluindo modelos de janela de um milhão de tokens) e aciona a compactação somente quando o uso atinge 80% — em vez de começar conservadoramente em 60% e descartar 40% do contexto útil. Há também uma proteção de "compactação sem ganho": se a cauda retida já preencher a janela (digamos, um resultado de leitura de arquivo muito grande na cauda), a compactação não pode liberar nada, então apenas registra um aviso e pula, nunca girando uma chamada de resumo desperdiçada. Se uma tarefa de longo horizonte pode "lembrar o que veio antes", tudo se resume a isso.

• Ferramentas somente leitura adjacentes em paralelo. Quando o modelo dispara arquivo de leitura, arquivo de pesquisa e pesquisa na web — diversas ferramentas somente leitura independentes — de uma só vez, o mecanismo agrupa em lote as ferramentas paralelizáveis adjacentes para execução simultânea; as ferramentas de gravação são barreiras naturais e mantêm sua ordem declarada. As chamadas de ferramentas e seus resultados são confirmados estritamente na ordem declarada, para que a simultaneidade nunca quebre o protocolo. As ferramentas somente leitura mais comuns passam de serial para paralelo de uma só vez, e o tempo do relógio de parede de todo o lote cai visivelmente.

• Leitura antes de gravação + controle de simultaneidade otimista. Antes de editar um arquivo você deve lê-lo primeiro; o mecanismo registra uma linha de base para o arquivo que foi lido e verifica se a linha de base não mudou no momento da edição. Quando trabalhadores paralelos alteram o mesmo arquivo de uma só vez, o perdedor recebe um claro erro "obsoleto" em vez de sobrescrever silenciosamente as alterações uns dos outros. Com vários trabalhadores operando no mesmo espaço de trabalho em paralelo, essa proteção é indispensável.

• A interrupção no meio da execução é implementada imediatamente. Quando um usuário adiciona outra linha enquanto o agente está na metade, o mecanismo dobra a mensagem na fila na entrada do turno atual no limite do loop de ferramentas, em vez de esperar para transformá-la em um turno separado. Isso transforma o "curso correto enquanto ele é executado" em uma interação natural.

• Detecção de loop. Quando a mesma chamada de ferramenta se repete consecutivamente, o motor primeiro dá um empurrão (no 3º) e depois para bruscamente (no 5º); qualquer assinatura diferente redefine a contagem - variações legítimas como paginação/sondagem não falharão. Quando o modelo trava, ele não queima mais tokens silenciosamente.

• Remoção do limite máximo na saída da curva principal. A saída da curva principal não fica mais fixada em uma tampa pequena, para que relatórios longos e edições grandes não sejam truncados silenciosamente; chamadas auxiliares (compactação, reflexão) ainda usam versaletes de maneira conservadora.

Há um detalhe muito "local" que vale a pena mencionar: estimativa de token para texto misto chinês-inglês. Uma estimativa genérica subestima uma conversa em chinês puro em duas ou três vezes; o mecanismo trata os caracteres chineses e ingleses de maneira diferente por classe de caracteres, o que torna o limite de compactação confiável. Esse é o tipo de coisa que um SDK genérico não pensará para você.

Juntas, essas melhorias respondem "por que não usar apenas um SDK pronto para uso": porque os recursos mais fortes de um agente de desktop residem na mesma camada que um SDK não expõe; para torná-los de nível de produção, o circuito deve estar em suas próprias mãos.

2. Mantendo o modelo sempre online: o wrapper do provedor multicamadas

O objetivo da camada de modelo é uma frase: não importa o que dê errado com uma determinada chave, um determinado provedor ou uma determinada rede, essa mudança na conversa do usuário deve sobreviver, se possível. Para esse fim, a camada do adaptador empilha alguns wrappers sobre a abstração do provedor do mecanismo — rotação, resfriamento, registro, adaptação externa.

O projeto mais crítico é que o rotor fique abaixo do corredor. O mecanismo grava a mensagem do usuário na sessão persistente antes mesmo de chamar um provedor; se você tentasse novamente/rotação no nível do mecanismo, reenviaria a mensagem do usuário ou teria que escrever uma reversão de sessão inteira. Ao colocar o rotador abaixo do mecanismo, a mensagem do usuário é escrita exatamente uma vez e "tentar novamente com outro candidato" é completamente transparente para o estado da sessão.

O julgamento do rotador também é restrito, centrado na linha do primeiro evento de conteúdo:

• Uma falha antes do modelo emitir qualquer conteúdo substantivo (texto/chamada de ferramenta) — é seguro mudar para o próximo candidato;
• Depois que o primeiro evento de conteúdo for emitido, pare de girar e deixe o erro se propagar, porque o modelo pode já ter rodado uma volta completa e refazê-lo repetiria os efeitos colaterais.

A classificação do erro decide "girar, não girar ou tentar novamente". Falhas no nível da conta, como falha de autenticação, saldo insuficiente, limitação de taxa, assinatura expirada — marque um período de espera e alterne; Falhas de rede transitórias, como redefinição de conexão — sem resfriamento, tente novamente sem estado algumas vezes; enquanto solicitações malformadas, política de conteúdo e servidor 5xx – que falhariam da mesma forma com outra chave – passam direto sem rotação. O tempo de espera é uma dica de dez minutos, em processo, não persistente: é apenas um sinal de curto prazo, não vale a pena gravar no disco em cada falha, e uma reinicialização do processo é exatamente o momento certo para testar novamente.

No lado da "lista" do provedor, o refatorador nivela três tipos de fontes em uma abstração unificada:

• LLM gerenciado pelo Orkas: um proxy do lado do servidor, pronto para uso uma vez conectado, com o roteamento do servidor entre modelos de texto/imagem;
• Traga sua própria chave: provedores convencionais padrão de grandes modelos;
• Adaptadores externos de conexão direta: um lote de modelos que precisam de conexão direta ou carregam seu próprio faturamento, adaptados manualmente na mesma interface do provedor.

Para as camadas acima, tudo isso aparece como apenas um par (provedor, modelo) estável — rotação, resfriamento e adaptação externa estão todos ocultos dentro da camada do adaptador.

3. Bate-papo em grupo como orquestração: do plano estático-DAG ao comandante no circuito

Esta é a parte mais “reestruturante” do refatorador.

O modelo antigo era o planejamento estático: o modelo primeiro gera um plano/DAG e o executor executa pelo gráfico. O novo modelo elimina totalmente esse gráfico e o substitui por uma orquestração de bate-papo em grupo dinâmica e controlada.

Sua metáfora é uma sala de bate-papo em grupo:

• O Comandante é o anfitrião da sala, não um middleware invisível;
• Trabalhadores agentes são membros iguais e de primeira classe na sala;
• Todas as interações são mensagens assíncronas, enfileiradas por meio de um único barramento de mensagens (não há caminho privado para distribuição paralela).

O "despacho" do comandante não é um @alguém escrito em prosa - um LLM escrito @AgentA no corpo do texto é apenas uma redução dos dados de treinamento e não é confiável. O verdadeiro sinal de despacho é uma chamada de ferramenta estruturada e, após a refatoração, converge em três ações semanticamente claras:

• dispatch_to — envia um agente para concluir a execução e devolve o resultado, com o comandante sintetizando. Várias tarefas independentes podem ser distribuídas simultaneamente.
• run_worker — uma subtarefa de propriedade do próprio comandante, com o resultado retornado de forma síncrona; um trabalhador anônimo é a "mão" do comandante (invisível para o usuário), enquanto um trabalhador nomeado é um especialista visível.
• hand_off_to — entrega a conversa para o agente; o comandante sai e o agente responde diretamente ao usuário, sem nenhuma síntese neste turno.

Por que conversar em grupo, em vez de um orquestrador ou uma árvore de subagentes

Transformar multiagentes em bate-papo em grupo traz vários benefícios que uma árvore orquestradora/subagente tradicional não consegue obter:

• Fatias de visibilidade. Cada mensagem é anexada apenas à fatia "aqueles que podem vê-la". Quando um agente de trabalho é iniciado, ele reproduz apenas sua própria fatia, portanto, a grande saída de outro agente não poluirá seu contexto. O comandante vê tudo.
• Estado mínimo. O estado central de toda a orquestração é apenas "quem atualmente detém a palavra" mais um livro de tarefas leve. Sem DAG, sem máquina de estado complexa.
• Naturalmente reproduzíveis e sincronizáveis. As mensagens são classificadas naturalmente por carimbo de data e hora, de modo que o recarregamento e a sincronização entre dispositivos caem diretamente no fluxo de mensagens. A extremidade móvel faz o controle remoto precisamente desse fluxo: toda a computação do agente é executada no desktop, e a mobilidade é apenas uma renderização espelhada, sem necessidade de protocolo de orquestração especial.

A revisão da arquitetura da equipe foi igualmente direta neste ponto: um barramento de bate-papo em grupo mais um comandante no circuito é o formato multiagente de Orkas; empilhar outro caminho de despacho de subagente paralelo dentro do processo violaria a invariante de "apenas um caminho de despacho de bate-papo em grupo".

O que há de novo nesta versão: transferência interativa

A mais nova peça desta linha é a transferência interativa de agentes.

O ponto problemático é concreto: um agente do tipo "tutor" ensina o usuário por um turno, o usuário quer continuar pedindo acompanhamentos, mas o sistema força a palavra de volta ao comandante, deixando o usuário re-@ aquele agente para cada linha.

A solução é um piso autoritativo do servidor + um destinatário decidido pelo modelo:

• O piso se torna um campo de estado persistente, salvo durante as recargas, e utiliza o evento de mudança de estado existente para sincronização automática em todas as extremidades, sem necessidade de novo tipo de evento.
• Depois que o comandante usa hand_off_to para dar a palavra a um agente interativo, as mensagens "no-@" subsequentes do usuário vão diretamente para esse agente, até que o agente devolva por conta própria ou o usuário volte a se dirigir ao comandante.
• O agente devolve o controle com um marcador <handback />; a análise verifica estritamente uma correspondência verdadeira (portanto, um <handback perdido que aparece em prosa não é mal interpretado como uma transferência).
• Se houver um livro de tarefas inacabado no momento da devolução, o comandante o pega no livro e continua.

Há também uma correção de experiência que vem com ele: bolhas de loop de comandante. O loop "despacho → ler resultado → despachar novamente" do comandante dentro de um turno costumava ser achatado em uma única bolha e, ao recarregar, ele até saltava fora de ordem para o fundo. O refatorador corta uma volta em múltiplos segmentos em cada limite de despacho visível, cada segmento uma mensagem independente com um carimbo de data e hora ascendente – pela primeira vez o usuário pode ver o comandante "fazendo um loop pela orquestração" e a ordem de recarga também está correta.

Finalmente, duas redes de segurança estão presentes: o aborto em grupo é o único caminho de parada para todos os atores (no momento em que o usuário clica em Parar, o sinal de aborto de cada trabalhador é cortado, até mesmo subtrabalhadores anônimos são cobertos por uma correspondência de fallback); e o mencionado anteriormente interrupt-steer, dobrando a interjeição do usuário no meio da corrida para a curva atual.

4. De um catálogo fechado a um host aberto

Se as três primeiras linhas foram sobre tornar a base sólida, esta é sobre abrir todas as portas e janelas - transformar Orkas de um catálogo fechado em um host aberto - enquanto mantém os limites de segurança sem ceder um centímetro.

O refatorador desmontou sistematicamente vários pontos de estrangulamento "fechados":

• Pacotes externos. O usuário fornece um endereço de repositório e o Orkas o hospeda localmente clonado literalmente em uma pasta — nunca normalizado, nunca reescrito, nunca sincronizado com a nuvem (porque contém diretórios de dependência de terceiros). Uma ferramenta de linha de comando independente possui o ciclo de vida de instalação/atualização/start-stop, verifica se é "em forma de habilidade" (carrega um arquivo de descrição de habilidade) ou "em forma de CLI" (carrega uma entrada executável) e grava os metadados em um registro fora do diretório do pacote (para que futuras atualizações pull nunca entrem em conflito). A instalação da dependência passa pela confirmação em duas etapas do tipo "pergunte uma vez, lembre-se"; entradas executáveis obtêm correções geradas e injetadas no PATH da ferramenta bash, para que o modelo possa chamar essas CLIs de terceiros diretamente.

• Carregamento de habilidades multi-raiz. O único ponto de entrada para a execução de habilidades passou do reconhecimento de apenas duas raízes para quatro níveis — personalizado/mercado/pacote externo/global — resolvidos por prioridade; scripts dentro de um pacote externo preferem o ambiente de dependência agrupado do próprio pacote. Este é o ponto de estrangulamento com o maior risco de regressão e é apoiado por uma matriz de fixtures completa.

• Interoperabilidade global de habilidades. O Orkas lê diretamente dos diretórios de habilidades globais que outras ferramentas de agente na máquina do usuário já mantêm, alcançando a interoperabilidade no nível da habilidade — uma habilidade que o usuário acumulou em um local também pode ser usada no Orkas. O próprio usuário que coloca uma habilidade nesses diretórios é a autorização, portanto ela é habilitada por padrão, com um interruptor mestre deixado. Essas descrições de habilidades de terceiros são uma superfície de injeção de prompt não confiável, portanto, elas passam pelo carregador de "camada aberta", são visíveis apenas para o comandante e estruturalmente não podem entrar na lista de permissões de habilidades de um agente.

• MCP configurado pelo usuário. Os conectores não são mais um catálogo codificado. O usuário pode adicionar qualquer servidor MCP — um formulário HTTP remoto (baixo risco) ou um formulário de subprocesso local (alto risco). O formulário em si é a superfície de consentimento (o comando que o usuário digitou manualmente é mostrado literalmente), a configuração de transporte (incluindo segredos) vai inteiramente para o armazenamento criptografado e as instâncias personalizadas sempre carregam um prefixo fixo para que nunca possam representar um conector oficial no catálogo.

• Ponte reversa: permitindo que os agentes externos da máquina percebam Orkas por sua vez. Esta é a peça mais interessante. As ferramentas de agentes externos já instaladas na máquina do usuário costumavam ser uma caixa preta para Orkas; agora, quando Orkas os despacha, ele injeta um canal de ponte que permite ao contrário listar/ler/executar as habilidades de Orkas, chamar conectores e pesquisar a base de conhecimento. A ponte é executada em um canal local entre processos (nenhuma porta de rede aberta), autenticada com uma credencial única que é exclusiva por execução e destruída no momento em que a execução termina. Toda chamada de conector com um efeito colateral externo passa por uma caixa de diálogo de confirmação do usuário — não um julgamento heurístico de leitura/gravação por nome de ferramenta (que seria um erro por ser muito vago), mas uma confirmação por (agente, conector), com um opcional "sempre permitir".

• Postura de codificação de cauda longa. A árvore de decisão do comandante ganha uma ramificação: quando não há agente/habilidade/conector correspondente, avalie a solução diretamente com bash mais um script curto, faça isso neste turno, verifique a saída e, opcionalmente, ofereça-se para cristalizá-la em uma habilidade personalizada. Isso vem com a execução do bash em segundo plano (tarefas longas são separadas do turno atual, os logs vão para um arquivo) e diretórios concedidos pelo usuário.

Aberto, mas sem intervenção

O que você mais teme ao abrir as portas e janelas é uma corrente de ar. A disciplina deste refatorador: nenhum dos pontos de estrangulamento de spawn para "ações perigosas" é tocado. O MCP começa exatamente em um lugar, a execução da habilidade passa por exatamente um runner e o bash passa por exatamente um executor sandbox. Além disso, várias camadas de profundidade são empilhadas:

• As operações de arquivo sempre passam pelo caminho sandbox (espaço de trabalho + anexos atuais + diretórios que o usuário concedeu explicitamente), enquanto diretórios de credenciais, diretórios de sistema e os próprios diretórios do Orkas não podem ser concedidos;
• Bash perigoso (exfiltração, exclusão destrutiva, escalonamento de privilégios, caminhos confidenciais) aciona uma confirmação de permissão, com a decisão dividida em "só desta vez/para esta execução/negar" e os registros registram apenas categoria e comprimento — nunca o texto do comando;
• A instalação de pacotes externos fecha com falha e recusa completamente pacotes com membros de link simbólico (para evitar o uso de um link simbólico para ler arquivos confidenciais fora da sandbox no escopo), e a origem do clone é restrita a uma lista de permissões de protocolo;
• Todos os transportes/segredos com credenciais são criptografados em repouso e as credenciais da ponte são isoladas por execução;
• A distribuição de código aberto/hospedada elimina os recursos exclusivos do host por meio de uma regra de corte.

Em uma frase: cada ação explícita do usuário (instalar/conceder/enviar formulário/clicar em confirmar) é a credencial de consentimento, e todo consentimento está confinado ao limite que merece.

5. Ficando mais inteligente nas sessões: memória e autoevolução

A revisão da base também refez dois subsistemas que "tornam o agente mais inteligente quanto mais ele é usado", ambos seguindo a mesma disciplina de engenharia — desativado por padrão, limitado, observável.

Memória de sessão cruzada usa recuperação híbrida: pesquisa semântica vetorial + pesquisa por palavra-chave (BM25), mesclada via RRF (fusão de classificação recíproca) para evitar falha em um único canal; ele chega ao armazenamento local (com um índice de texto completo). A memória vem em dois tipos — as notas do próprio agente e o perfil de preferência do usuário — cada um com um limite de caracteres, verificado em busca de ameaças de injeção antes de escrever e injetado congelado no prompt do sistema no início de cada turno. Todo o sistema de memória serve apenas para fazer com que o agente entenda melhor o usuário atual; os dados sempre permanecem locais e o usuário pode visualizá-los, editá-los e exportá-los a qualquer momento nas configurações.

Autoevolução é uma biblioteca de habilidades privadas do agente (armazenada separadamente da biblioteca de habilidades compartilhadas da plataforma) mais uma camada de reflexão metacognitiva. O mecanismo decide se deve refletir por um conjunto de sinais ponderados: correção do usuário (peso mais alto), recuperação de um erro não trivial, complexidade da tarefa, uma fraqueza conhecida sendo acionada ou superada, ineficácia de habilidade... a reflexão só é acionada quando os sinais ponderados excedem um limite. A reflexão em si é uma tarefa periódica em segundo plano (aproximadamente uma rodada a cada 12 horas, um tempo de espera de várias horas, um substituto de vários dias) que usa um modelo pequeno e barato para ler um resumo da atividade recente e decidir se deve criar/corrigir uma habilidade e atualizar o "perfil de competência" do agente.

O ponto de segurança mais importante: a autoevolução é habilitada apenas para sessões que têm um agente explicitamente vinculado — a sessão padrão do comandante não evolui. O Reflection tem um limite de token duplo (contagem + total), a falha de um agente não bloqueia os outros e o custo por execução é extremamente baixo. Torne o agente mais inteligente, mas não o deixe fugir.

Filosofia de engenharia: complexidade conquistada — não simplifique-a

A equipe realizou diversas rodadas de revisão da arquitetura durante a refatoração, e uma conclusão continuou recorrente, e que vale a pena retirar por si só: distinguir "hipertrofia organizacional" de "complexidade adquirida" e abordar apenas a primeira.

• As múltiplas estratégias de mesclagem do mecanismo de sincronização, o loop de agente autoconstruído, o wrapper do provedor de múltiplas camadas, o limite do controle remoto móvel — tudo isso parece complexo, mas cada camada ganha seu sustento (consistência eventual de vários dispositivos, integração profunda, rotação de várias chaves, um limite final decidido pelo produto). "Simplificá-los" à força apenas perderia dados e confundiria as camadas.
• O que realmente deveria ser tocado são os "módulos divinos" e a duplicação local: extrair as funções puras sem estado do barramento de bate-papo em grupo inchado (montagem de prompt, ferramentas de comandante, a vez da CLI) e recolher o padrão de "diálogo de confirmação" que foi duplicado várias vezes em um componente compartilhado.

O que respalda esse tipo de julgamento é um conjunto de disciplinas rígidas escritas no documento de restrições do projeto: limite (processo único, IPC como único caminho, o tempo de execução só pode ser carregado dinamicamente), camadas (a direção de dependência de cada camada), fonte única de verdade (categorias, taxonomia de telemetria, domínios) e uma "auditoria imediata" obrigatória em cada commit voltado para prompt. O que permite que a fundação seja revisada sem entrar em colapso não é um projeto inteligente – são essas invariantes mantidas continuamente.

Encerramento

Junte as quatro linhas de passagem e o que esse refatorador básico transfere para o Orkas é uma base de agente que é autocontrolada, independente de provedor, orquestrada dinamicamente, aberta ao exterior e capaz de autoevoluir:

• Um tempo de execução em processo de mecanismo/adaptador de duas camadas que traz um conjunto completo de pontos fortes do agente de codificação — operações de arquivo, pesquisa local, ferramentas de sistema, multi-trabalhador paralelo, solução de longo horizonte — nativamente para o desktop e torna cada um deles de nível de produção;
• Uma camada de modelo multicamadas que mantém a conversa viva através da turbulência de chave/provedor/rede, tanto quanto possível;
• Uma orquestração multiagente no estilo de bate-papo em grupo, comandante no circuito, que troca o "planejamento estático" pela "decisão dinâmica" e, pela primeira vez, faz com que as transferências entre agentes pareçam naturais;
• Um ecossistema passando de um catálogo fechado para um host aberto, com pacotes externos, habilidades globais, MCP customizado e a ponte reversa, todos abertos — enquanto os pontos de estrangulamento do spawn não mudaram nem um centímetro;
• E memória e autoevolução que estão desativadas por padrão, limitadas e observáveis.

Os recursos podem ser adicionados um de cada vez, mas só vale a pena revisar seriamente uma base uma vez. Depois de concluído, tudo o que você construir será mais rápido - e esse é exatamente o resultado que esse refatorador buscava.