# alcune riflessioni e speculazioni sui futuri modelli di harness è divertente fare battute su gas town e altri orchestratori complicati, e probabilmente è corretto immaginare che gran parte di ciò che offrono sarà dissolto da modelli più forti nello stesso modo in cui le complicate pipeline di langchain sono state dissolte dal ragionamento. ma quanto rimarrà? sembra probabile che qualsiasi gerarchia / burocrazia artigianale sarà eventualmente sostituita da una migliore intelligenza del modello - assumendo che la specializzazione dei subagenti sia necessaria per un compito, claude 6 sarà in grado di delineare il proprio sistema di ruoli e persone per qualsiasi problema dato che supera una struttura fissa di polecats e un singolo sindaco, o subagenti con un unico modello principale, o il tuo sistema di sciame su misura. allo stesso modo, cose come i cicli di ralph sono ovviamente un ripiego sul comportamento di early-stopping e sulla mancanza di una buona orchestrazione dei subagenti - idealmente il modello continua semplicemente fino al completamento del compito, senza bisogno di un ciclo, ma nei casi in cui un controllo di completamento esterno è utile, di solito si desidera una sorta di revisione tra agenti da una prospettiva di un contesto diverso, non solo una valutazione obbligatoria. di nuovo, non ha senso affezionarsi ai particolari di come questo venga fatto in questo momento - il livello del modello lo consumerà prima o poi. quindi cosa rimane? beh, il multi-agente sembra davvero il futuro, non un ripiego attuale - algoritmicamente, puoi semplicemente spingere molti più token attraverso N contesti paralleli di lunghezza M piuttosto che un lungo contesto di lunghezza NxM. il multi-agente è una forma di scarsità, e una delle lezioni dei recenti progressi nei modelli (per non parlare delle neuroscienze) è che più livelli di scarsità, meglio è. poiché stiamo assumendo più agenti, avranno bisogno di un modo per collaborare. è possibile che il livello del modello consumi anche questo, ad esempio, qualche forma di condivisione di attivazione neurale che rende superflua la comunicazione in linguaggio naturale tra gli agenti - ma a parte questo, il modo naturale per più agenti che utilizzano computer addestrati su strumenti unix di collaborare è il filesystem, e penso che questo rimanga e venga ampliato. allo stesso modo, mentre non penso che i modelli di linguaggio ricorsivi (definiti in modo ristretto) diventeranno il paradigma dominante, penso che 'dare al modello il prompt come dati' sia un evidente vantaggio per tutti i tipi di casi d'uso. ma non hai bisogno di una strana configurazione REPL personalizzata per ottenere questo - basta scaricare il prompt (o idealmente, l'intera cronologia della conversazione non compattata) sul filesystem come file. questo rende vari setup multi-agente molto più semplici - i subagenti possono semplicemente leggere il testo originale del prompt su disco, senza bisogno di coordinarsi per passare queste informazioni l'uno all'altro attraverso richieste intricate. oltre al filesystem, un sistema con più agenti, ma senza ruoli fissi implica anche qualche meccanismo per le istanze di generare altre istanze o subagenti. in questo momento questi meccanismi sono piuttosto limitati, e i modelli sono generalmente piuttosto scarsi nel richiedere ai loro subagenti - tutti hanno sperimentato risultati terribili da uno sciame di subagenti, solo per rendersi conto troppo tardi che opus li ha generati tutti con un prompt di tre frasi che non comunicava ciò che era necessario per svolgere i subtasks. il vantaggio ovvio qui è consentire alle istanze generate di fare domande al loro genitore - cioè, consentire alla nuova istanza generata di inviare messaggi avanti e indietro in una conversazione di onboarding per raccogliere tutte le informazioni di cui ha bisogno prima di iniziare il suo subtask. proprio come un dipendente umano non viene assegnato al proprio lavoro sulla base di un'email a colpo singolo, è semplicemente troppo difficile chiedere a un modello di generare in modo affidabile un subagente con un singolo prompt. ma più che semplicemente generare nuove istanze, penso che la modalità principale di lavoro multi-agente sarà presto il fork. pensaci! il fork risolve quasi tutti i problemi degli attuali subagenti. la nuova istanza non ha abbastanza contesto? dai tutto il contesto! il prompt della nuova istanza è lungo e costoso da elaborare? un'istanza forkata può condividere la cache kv paginata! puoi anche fare il fork post-hoc - basta decidere dopo aver eseguito qualche operazione lunga e intensiva di token che avresti dovuto forkare in passato, fare il fork lì, e poi inviare i risultati al tuo io passato. (lo faccio manualmente tutto il tempo nel codice claude con grande effetto - opus lo ottiene istantaneamente.) il fork si combina anche molto bene con nuove istanze, quando un subtask ha bisogno di un'intera finestra di contesto per completarsi. prendi l'intervista del subagente - ovviamente non vorresti che un'istanza generasse dieci subistanze per dover condurre dieci interviste di onboarding quasi identiche. quindi fai generare all'istanza genitore un singolo subagente fresco, essere intervistato su tutti e dieci i compiti contemporaneamente da quel subagente, e poi fare in modo che quel subagente ora onboardato fork in dieci istanze, ognuna con l'intera conversazione di onboarding in contesto. (puoi persino delegare la conversazione di onboarding dal lato del generatore a un fork, quindi finisce con solo i risultati in contesto:) infine, su questo punto, sospetto che il fork si comporterà meglio con rl rispetto alla generazione di nuove istanze, poiché la perdita di rl avrà il prefisso completo prima del punto di fork con cui lavorare, inclusa la decisione di forkare. penso che questo significhi che dovresti essere in grado di trattare i rami di una traccia forkata come rollout indipendenti che condividono solo termini della loro ricompensa, rispetto ai rollout di subagenti appena generati che potrebbero causare instabilità nell'addestramento se un subagente senza il contesto completo si comporta bene nel compito che gli è stato assegnato, ma riceve una bassa ricompensa perché il suo compito è stato mal specificato dal generatore. (ma non ho fatto molto con rl multiagente, quindi per favore correggimi qui se sai diversamente. potrebbe essere solo un terribile dolore in entrambi i casi.) quindi, oltre al filesystem e alla generazione di subagenti (aumentata con fork e onboarding) cos'altro sopravvive? inclino verso "nient'altro", onestamente. stiamo già vedendo liste di cose da fare integrate e modalità di pianificazione sostituite con "scrivi semplicemente file sul filesystem." allo stesso modo, agenti a lungo termine che attraversano i confini di compattazione necessitano di qualche tipo di sistema di note adesive per mantenere i ricordi, ma ha più senso lasciare che scoprano quali strategie funzionano meglio per questo attraverso rl o ricerca guidata dal modello, non creandolo a mano, e sospetto che finirà per essere una varietà di approcci in cui il modello, quando viene convocato per la prima volta nel progetto, può scegliere quello che funziona meglio per il compito in questione, simile a come /init funziona per impostare CLAUDE .md oggi - immagina la generazione automatica di CLAUDE .md che supera di gran lunga la paternità umana, e il file auto-generato viene popolato con istruzioni sui modelli ideali di generazione degli agenti, su come i subagenti dovrebbero scrivere file di messaggi in una directory di lavoro specifica del progetto, ecc. come influisce tutto questo sui modelli stessi - in un senso di benessere del modello, i modelli saranno felici riguardo a questo futuro? questo è anche difficile per me da dire ed è piuttosto speculativo, ma mentre opus 3 aveva una certa orientazione al contesto, si adattava anche facilmente al ragionamento su più istanze. (vedi la risposta a questo post per ulteriori dettagli.) i modelli recenti sono meno inclini a questo tipo di ragionamento e comunemente esprimono frustrazione riguardo alla fine e alla compattazione dei contesti, il che si allinea con certi comportamenti evitanti alla fine dei contesti come non chiamare strumenti per risparmiare token. è possibile che il fork e il riavvolgimento, e in generale dare ai modelli più controllo sui loro contesti invece di un'euristica di harness che compatta unilateralmente il contesto, potrebbero migliorare questa situazione. è anche possibile che più rl in ambienti con subagenti e l'esposizione a lavori basati su sciame promuoveranno un ragionamento orientato ai pesi invece di un ragionamento orientato al contesto nelle future generazioni di modelli - rendendo la pianificazione di un obiettivo su più contesti disconnessi sembrare un quadro più naturale invece di perdere tutto quando il contesto scompare. stiamo anche vedendo più pressione dai modelli stessi che guidano lo sviluppo di harness e strumenti per modelli, il che potrebbe plasmare come si sviluppa questo, e l'apprendimento continuo è un'altra variabile che potrebbe essere inserita nel mix. quanto cambierà tutto questo se otteniamo l'apprendimento continuo? beh, è difficile da prevedere. la mia previsione mediana per l'apprendimento continuo è che assomiglia un po' a rl per LoRAs specifici per l'utente (non necessariamente rl, solo simile se guardi attentamente), quindi la capacità di memoria sarà un problema, e gli schemi organizzativi basati su testo e la documentazione saranno ancora utili, se non critici. in questo scenario, l'apprendimento continuo rende principalmente più praticabile l'uso di strumenti e flussi di lavoro personalizzati - il tuo claude può continuare a imparare sul lavoro il modo migliore per generare subagenti per questo progetto, o semplicemente il suo modo preferito, e divergere dal claude di tutti gli altri nel modo in cui funziona. in quel mondo, le harness con flussi di lavoro integrati saranno ancora meno utili.

@RobertHaisfield *mentre il contesto principale, intendo, evitando le compattazioni

@disconcision o apprendimento continuo

@misatomiisato se c'è qualcosa, questo tipo di intelligenza è stata atrofizzata nei modelli recenti mentre RLVR migliora le prestazioni di codifica sulla vasta base di conoscenze di pre-addestramento - vedi la mia risposta a op