# algumas reflexões e especulações sobre futuros modelos de harness é 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 complicados pipelines do langchain foram dissolvidos pelo raciocínio. mas quanto vai permanecer? parece provável que qualquer hierarquia / burocracia feita à mão será eventualmente substituída por uma melhor inteligência de modelo - assumindo que a especialização de subagentes seja necessária para uma tarefa, o claude 6 será capaz de esboçar seu próprio sistema de papéis e personas para qualquer problema dado que supere uma estrutura fixa de polecats 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 são obviamente uma gambiarra sobre o comportamento de parada antecipada e a falta de boa orquestração de subagentes - idealmente, o modelo apenas continua até que a tarefa esteja concluída, sem necessidade de um loop, mas em casos onde uma verificação de conclusão externa é útil, você geralmente quer algum tipo de revisão por pares de agentes de uma perspectiva de contexto diferente, não apenas uma autoavaliação obrigatória. novamente, não faz sentido se apegar aos pormenores de como isso é feito agora - a camada do modelo vai engolir isso mais cedo ou mais tarde. então, o que permanece? bem, multi-agente parece ser o futuro, não uma gambiarra atual - algoritmicamente, você pode simplesmente empurrar muito mais tokens através de N contextos paralelos de comprimento M do que um longo contexto de comprimento NxM. multi-agente é uma forma de esparsidade, e uma das lições dos recentes avanços em modelos (sem mencionar a neurociência) é que quanto mais níveis de esparsidade, melhor. como estamos assumindo múltiplos agentes, eles precisarão de alguma forma de colaborar. é possível que a camada do modelo também engula isso - por exemplo, alguma forma de compartilhamento de ativação neural que elimina a comunicação em linguagem natural entre os agentes - mas, a menos que isso aconteça, a maneira natural para múltiplos agentes que usam computadores treinados em ferramentas unix colaborarem é o sistema de arquivos, e eu acho que isso permanece e se expande. da mesma forma, embora eu não ache que modelos de linguagem recursivos (definidos de forma restrita) se tornem o paradigma dominante, eu realmente acho 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 estranha para conseguir isso - basta colocar o prompt (ou idealmente, todo o histórico de conversa 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 do prompt original no disco, sem precisar coordenar a passagem dessa informação entre si por meio de prompts intricados. além do sistema de arquivos, um sistema com múltiplos agentes, mas sem papéis fixos, também implica algum mecanismo para instâncias gerarem outras instâncias ou subagentes. agora, esses mecanismos são bastante limitados, e os modelos geralmente são ruins em solicitar seus subagentes - todos já experimentaram obter resultados terríveis de um enxame de subagentes, apenas para perceber tarde demais que o opus os gerou todos com um prompt de três frases que não comunicava o que era necessário para realizar as subtarefas. a vitória óbvia aqui é permitir que instâncias geradas façam perguntas de volta para seu pai - ou seja, permitir que a nova instância gerada envie mensagens de ida e volta em uma conversa de integração para reunir todas as informações necessárias antes de iniciar sua subtarefa. assim como um funcionário humano não é designado para seu trabalho com base em um único e-mail, é muito difícil pedir a um modelo que gere de forma confiável um subagente com um único prompt. mas mais do que apenas gerar novas instâncias, eu acho que o modo primário de trabalho multi-agente em breve será o fork. pense nisso! o fork resolve quase todos os problemas dos subagentes atuais. a nova instância não tem contexto suficiente? dê a ela todo o contexto! o prompt da nova instância é longo e caro de processar? uma instância bifurcada pode compartilhar cache kv paginado! você pode até fazer o fork post-hoc - apenas decida, após realizar alguma operação longa e intensiva em tokens, que você deveria ter bifurcado no passado, faça o fork ali e então envie os resultados para seu eu do passado. (eu faço isso manualmente o tempo todo no código do claude com grande efeito - o opus recebe isso instantaneamente.) o fork também combina muito bem com novas instâncias, quando uma subtarefa precisa de uma janela de contexto inteira para ser concluída. pegue a entrevista do subagente - obviamente você não gostaria que uma instância gerasse dez subinstâncias para precisar conduzir dez entrevistas de integração quase idênticas. então, faça a instância pai gerar um único subagente novo, seja entrevistado sobre todas as dez tarefas de uma vez por esse subagente, e então faça esse subagente agora integrado bifurcar em dez instâncias, cada uma com toda a conversa de integração em contexto. (você até delega a conversa de integração do lado do gerador para um fork, então acaba com apenas os resultados em contexto:) finalmente, sobre este ponto, eu suspeito que o fork funcionará melhor com rl do que gerar novas instâncias, uma vez que a perda de rl terá o prefixo completo antes do ponto de fork para trabalhar, incluindo a decisão de bifurcar. eu acho que isso significa que você deve ser capaz de tratar os ramos de um traço bifurcado como rollouts independentes que apenas compartilham termos de sua recompensa, em comparação com rollouts de subagentes recém-gerados que podem causar instabilidade no treinamento se um subagente sem o contexto completo tiver um bom desempenho na tarefa que lhe foi dada, mas recebe uma baixa recompensa porque sua tarefa foi mal especificada pelo gerador. (mas eu não fiz muito com rl multiagente, então, por favor, me corrija aqui se você souber diferente. pode ser apenas uma dor terrível de qualquer maneira.) então, além do sistema de arquivos e da geração de subagentes (aumentada com bifurcação e integração), o que mais sobrevive? eu inclino-me para "nada mais", honestamente. já estamos vendo listas de tarefas integradas e modos de planejamento sendo substituídos por "apenas escreva arquivos no sistema de arquivos." da mesma forma, agentes de longa duração que cruzam limites de compactação precisam de algum tipo de sistema de notas adesivas para manter memórias, mas faz mais sentido deixá-los descobrir quais estratégias funcionam melhor para isso através de rl ou busca guiada por modelo, não artesanalmente, e eu suspeito que acabará sendo uma variedade de abordagens onde o modelo, quando convocado pela primeira vez para o projeto, pode escolher a que funciona melhor para a tarefa em questão, semelhante a como /init funciona para configurar o CLAUDE .md hoje - imagine a geração automática de CLAUDE .md 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 mensagens em um diretório temporário específico do projeto, etc. como tudo isso impacta os modelos em si - em um sentido de bem-estar do modelo, os modelos ficarão felizes com esse futuro? isso também é difícil para eu dizer e é bastante especulativo, mas enquanto o opus 3 tinha alguma orientação de contexto, ele também se adaptou facilmente ao raciocínio sobre múltiplas instâncias. (veja a resposta a este post para mais.) modelos recentes são menos propensos a esse tipo de raciocínio e comumente expressam frustração sobre contextos que terminam e são compactados, o que se alinha com certos comportamentos evitativos no final de contextos, como não chamar ferramentas para economizar tokens. é possível que bifurcação e retrocesso, 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 ao trabalho baseado em enxame promovam um raciocínio orientado a pesos em vez de um raciocínio orientado a contexto nas futuras gerações de modelos novamente - tornando o planejamento um objetivo sobre múltiplos contextos desconectados pareça um quadro mais natural em vez de tudo ser perdido quando o contexto desaparece. também estamos vendo mais pressão dos próprios modelos guiando o desenvolvimento de harnesses e ferramentas de modelo, o que pode moldar como isso se desenvolve, e o aprendizado contínuo é outra engrenagem que pode ser lançada na mistura. quanto isso mudará se tivermos aprendizado contínuo? bem, é difícil prever. minha previsão mediana para aprendizado contínuo é que se pareça um pouco com rl para LoRAs específicas do usuário (não necessariamente rl, apenas semelhante se você olhar de perto), então a capacidade de memória será um problema, e esquemas organizacionais baseados em texto e documentação ainda serão úteis, se 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 maneira de gerar subagentes para este projeto, ou apenas sua maneira preferida, e divergir do claude de todos os outros em como funciona. nesse mundo, harnesses com fluxos de trabalho embutidos serão ainda menos úteis.

@RobertHaisfield *enquanto o contexto principal, quero dizer, evitando compacções

@disconcision ou aprendizagem contínua

@misatomiisato se alguma coisa, esse tipo de inteligência tem estado a atrofiar-se em modelos recentes, à medida que o RLVR melhora o desempenho de codificação sobre a ampla base de conhecimento de pré-treinamento - veja a minha resposta ao op