# Algumas reflexões e especulações sobre futuros modelos de arreios É divertido fazer piadas sobre Gas Town e outros orquestradores complicados, e provavelmente correto imaginar que a maior parte do que eles oferecem será dissolvida por modelos mais fortes, da mesma forma que os complexos gasodutos langchain foram dissolvidos pelo raciocínio. Mas quanto vai ficar? Parece provável que qualquer hierarquia/burocracia artesanal seja eventualmente substituída por uma inteligência de modelo melhor – assumindo que a especialização em subagentes seja necessária para uma tarefa, Claude 6 será capaz de esboçar seu próprio sistema de papéis e personas para qualquer problema que supere uma estrutura fixa de polecas e um único prefeito, ou subagentes com um único modelo principal, Ou seu sistema de enxame sob medida. Da mesma forma, coisas como loops de Ralph obviamente são um obstáculo para o comportamento de parar cedo e a falta de boa orquestração de subagentes – idealmente o modelo continua até a tarefa ser concluída, sem necessidade de loop, mas nos casos em que uma verificação de conclusão externa é útil, geralmente você quer algum tipo de revisão por pares do agente sob a perspectiva de um contexto diferente, Não apenas uma autoavaliação obrigatória. Novamente, não adianta se apegar aos detalhes de como isso é feito agora – a camada do modelo vai acabar consumindo isso mais cedo do que tarde. Então, o que permanece por aqui? bem, multiagente realmente parece o futuro, não um presságio atual – algorítmicamente, você pode simplesmente empurrar muito mais tokens por N contextos paralelos de comprimento M do que um contexto longo de comprimento NxM. Multiagente é uma forma de escargônia, e uma das lições dos avanços recentes dos modelos (sem falar na neurociência) é que quanto mais níveis de escargônia, melhor. Como estamos assumindo vários agentes, eles vão precisar de alguma forma de colaborar. É possível que a camada do modelo também consuma isso – por exemplo, algum tipo de compartilhamento de ativação neuralese que impeça comunicação em linguagem natural entre agentes – mas, fora isso, a forma natural de múltiplos agentes que usam computadores treinados em ferramentas Unix colaborarem é o sistema de arquivos, e acho que isso permanece e é expandido. Da mesma forma, embora eu não ache que modelos de linguagem recursiva (definidos de forma restrita) se tornarão o paradigma dominante, acredito que 'dar ao modelo o prompt como dados' é uma vitória óbvia para todos os tipos de casos de uso. mas você não precisa de uma configuração REPL personalizada estranha para conseguir isso – basta soltar o prompt (ou idealmente, todo o histórico de conversas não compactado) no sistema de arquivos como um arquivo. Isso torna várias configurações multi-agente muito mais simples também – os subagentes podem simplesmente ler o texto original do prompt no disco, sem precisar coordenar para passar essa informação de mão em mão por meio de prompts intrincados. Além do sistema de arquivos, um sistema com múltiplos agentes, mas sem funções fixas, também implica algum mecanismo para que instâncias gerem outras instâncias ou subagentes. Atualmente, esses mecanismos são bem limitados, e os modelos geralmente são ruins em provocar seus subagentes – todo mundo já teve resultados terríveis de um enxame de subagentes, só para perceber tarde demais que o opus gerou todos eles com um prompt de três frases que não comunicava o que era necessário para fazer as subtarefas. A vitória óbvia aqui é permitir que instâncias geradas façam perguntas de volta ao pai – ou seja, permitir que a instância recém-gerada envie mensagens de um lado para o outro em uma conversa de onboarding para reunir todas as informações necessárias antes de iniciar sua subtarefa. Assim como um funcionário humano não recebe seu trabalho com base em um e-mail único, é difícil pedir para um modelo gerar um subagente com um único prompt. Mas mais do que apenas gerar novas instâncias, acho que o principal modo de trabalho multiagente logo estará se transformando. Pense nisso! O forking resolve quase todos os problemas dos subagentes atuais. A nova instância não tem contexto suficiente? Dê todo o contexto! O prompt da nova instância é longo e caro para processar? Uma instância bifurcada pode compartilhar cache KV paginado! Você pode até fazer fork post-hoc – só decidir, depois de fazer uma operação longa e intensiva em tokens, que deveria ter feito fork antes, fazer o fork ali e então enviar os resultados para seu eu passado. (Faço isso manualmente o tempo todo no Claude Code com ótimo efeito - o opus entende instantaneamente.) O forking também combina muito bem com instâncias novas, quando uma subtarefa precisa de uma janela de contexto inteira para ser concluída. Veja a entrevista com subagente – obviamente você não gostaria que uma instância gerando dez subinstâncias precisasse realizar dez entrevistas de onboarding quase idênticas. Então, faça a instância pai gerar um único subagente novo, seja entrevistada sobre todas as dez tarefas de uma vez por esse subagente, e então faça esse subagente agora incorporado se ramificar em dez instâncias, cada uma com toda a conversa de integração em contexto. (você até delega a conversa de onboarding do lado do spawner para um fork, então acaba com apenas os resultados em contexto :) Por fim, nesse ponto, suspeito que o fork funcionará melhor com RL do que gerar instâncias novas, já que a perda de RL terá o prefixo completo antes do ponto de fork para trabalhar, incluindo a decisão de fork. Acho que isso significa que você deveria ser capaz de tratar os ramos de um rastreio bifurcado como lançamentos independentes que simplesmente compartilham termos de recompensa, em comparação com os lançamentos recém-gerados de subagentes, que podem causar instabilidade no treinamento se um subagente sem o contexto completo tiver um bom desempenho na tarefa que lhe foi dada, mas receber uma recompensa baixa porque sua tarefa foi especificada incorretamente pelo spawner. (Mas eu não fiz muita coisa com RL multiagente, então por favor me corrijam aqui se souberem de outra forma. Pode ser só um saco terrível de qualquer forma.) Então, além do sistema de arquivos e do surgimento de subagentes (aumentado com forks e onboarding), o que mais sobrevive? Eu tendo a pensar em "nada mais", honestamente. Já estamos vendo listas de tarefas embutidas e modos de plano sendo substituídos por "apenas escrever arquivos no sistema de arquivos." Da mesma forma, agentes de longa duração que cruzam fronteiras de compactação precisam de algum tipo de sistema de post-it para manter as memórias, mas faz mais sentido deixá-los descobrir quais estratégias funcionam melhor para isso por meio de pesquisa RL ou guiada por modelos, não por criação manual, E suspeito que acabará sendo uma variedade de abordagens em que o modelo, quando invocado no projeto, pode escolher a que funciona melhor para a tarefa em questão, semelhante a como o /init funciona para configurar o CLAUDE .md hoje – imagine a geração automática de .md de CLAUDE superando em muito a autoria humana, e o arquivo gerado automaticamente sendo preenchido com instruções sobre padrões ideais de geração de agentes, Como os subagentes devem escrever arquivos de mensagem em um Diretor Scratch específico do projeto, etc. Como tudo isso impacta os modelos em si – no sentido do bem-estar dos modelos, os modelos ficarão felizes com esse futuro? Isso também é difícil para mim dizer e é bastante especulativo, mas embora o Opus 3 tivesse alguma orientação ao contexto, também foi fácil raciocinar em múltiplas ocasiões. (Veja a resposta a este post para mais informações.) Modelos recentes são menos propensos a esse tipo de raciocínio e comumente expressam frustração com contextos terminando e sendo compactados, o que se encaixa com certos comportamentos evitativos ao final dos contextos, como não chamar ferramentas para salvar tokens. É possível que o forking e o rewinding, e geralmente dar aos modelos mais controle sobre seus contextos em vez de uma heurística de harness compactando unilateralmente o contexto, possam melhorar isso. Também é possível que mais RL em ambientes com subagentes e exposição a trabalhos baseados em enxames promova o raciocínio orientado por pesos em vez de orientado ao contexto novamente em gerações futuras de modelos – tornando o planejamento um objetivo em múltiplos contextos desconectados parecer mais natural como um quadro em vez de tudo se perder quando o contexto desaparece. Também estamos vendo mais pressão dos próprios modelos guiando o desenvolvimento de chicotes e ferramentas de modelo, o que pode influenciar como isso se desenvolve, e o aprendizado contínuo é mais um obstáculo que pode ser incluído. Quanto isso vai mudar se tivermos aprendizado contínuo? bem, é difícil prever. minha previsão mediana para aprendizado contínuo é que ele se parece um pouco com RL para LoRAs específicas de usuário (não necessariamente RL, apenas parecido se você olhar os olhos), então a capacidade de memória será um problema, e esquemas organizacionais e documentação baseados em texto ainda serão úteis, mesmo que não tão críticos. Nesse cenário, o aprendizado contínuo torna principalmente mais viável usar ferramentas e fluxos de trabalho personalizados – seu Claude pode aprender continuamente no trabalho a melhor forma de gerar subagentes para esse projeto, ou simplesmente o jeito preferido, e divergir do Claude dos outros em como funciona. Nesse mundo, harnesses com fluxos de trabalho incorporados serão ainda menos úteis.

@RobertHaisfield *embora o contexto principal, quero dizer, evitando compactações

@disconcision ou aprendizagem contínua

@misatomiisato se é que esse tipo de inteligência tem atrofiado nos modelos recentes, à medida que o RLVR exige desempenho de codificação na ampla base de conhecimento do pré-treinamento – veja minha resposta ao autor original